Cách Đọc Network Waterfall Để Chẩn Đoán Hiệu Suất Web

Network waterfall cho biết từng resource được request khi nào, browser chờ bao lâu và response load xong lúc nào. Nhưng câu hỏi hữu ích nhất không đơn giản là “Request nào lớn nhất?”

Câu hỏi hữu ích là: Delay xảy ra ở đâu trong request path, và bước tiếp theo nên điều tra gì?

Waterfall là diagnostic evidence. Nó có thể cho thấy request bắt đầu muộn, thời gian chờ first response byte dài, transfer chậm, dependency chain và third-party activity. Nhưng bản thân nó không thể chứng minh vì sao JavaScript execution đắt hoặc vì sao rendering vẫn bị block sau khi network activity đã hoàn tất.

Network Waterfall Thực Sự Cho Bạn Thấy Điều Gì?

Network waterfall là timeline của browser request.

Trục ngang đại diện cho thời gian.

Mỗi hàng đại diện cho một request được tạo trong lúc page load hoặc chạy.

Tùy request, browser có thể dành thời gian để:

• chờ trước khi request có thể được gửi;
• resolve hostname;
• establish connection;
• gửi request;
• chờ first response byte;
• download response body.

Hãy dùng nó như một phần của root-cause performance investigation rộng hơn.

Hãy Bắt Đầu Với Document Request

Document request là reference point đầu tiên cho phần lớn page-load investigation.

Tìm main HTML request và hỏi:

Nếu document dành nhiều thời gian trong Waiting (TTFB), mọi parser-discovered resource đều bắt đầu từ một baseline muộn hơn.

Nếu document response nhanh nhưng critical image hoặc stylesheet bắt đầu muộn hơn nhiều, investigation chuyển sang discovery hoặc dependency timing.

Hiểu Các Timing Stage Của Một Request

Chrome DevTools có thể hiển thị timing breakdown cho từng request. Không phải request nào cũng có mọi phase vì connection reuse, cache state, Service Worker và protocol behavior có thể làm request path khác nhau.

Queueing và stalled time

Queueing xảy ra trước connection start khi browser delay một request, ví dụ vì có request priority cao hơn, connection availability bị hạn chế hoặc browser scheduling condition khác đang áp dụng.

Stalled có thể xảy ra sau connection start vì lý do scheduling hoặc connection-related tương tự.

Không nên biến queueing dài trực tiếp thành root-cause conclusion. Trước tiên hãy hỏi request đó có critical không và resource nào khác đang cạnh tranh.

DNS, connection và TLS

Request tới origin mới có thể cần một số work trước khi HTTP data bắt đầu truyền.

Các phase liên quan có thể gồm:

• DNS Lookup — resolve hostname;
• Initial connection — establish connection, gồm connection handshake behavior và SSL negotiation;
• proxy negotiation khi relevant.

Nếu existing connection được reuse, một số stage này có thể không xuất hiện lại.

Request sent

Đây là khoảng thời gian request đang được gửi.

Với page resource thông thường, stage này thường nhỏ so với waiting hoặc content download, nhưng request payload và connection condition có thể làm thay đổi.

Waiting for the response

Chrome gắn nhãn phase này là Waiting (TTFB).

Trình duyệt đang chờ first byte của response.

Timing này có thể phản ánh cả round-trip latency lẫn thời gian server hoặc upstream path cần để chuẩn bị response.

Với WordPress-specific server-response diagnosis, xem diagnose high WordPress TTFB.

Content download

Content Download là thời gian dành để nhận response body.

Download dài có thể chỉ tới nhiều hướng:

• large transfer size;
• limited throughput;
• slow network condition;
• origin hoặc CDN delivery constraint;
• browser bận tới mức delay việc đọc response.

Không nên mặc định file size một mình giải thích duration.

Request Start Time Quan Trọng Không Kém Duration

Một resource nhỏ và nhanh vẫn có thể làm user-visible performance kém nếu nó bắt đầu quá muộn.

Điều này đặc biệt quan trọng với critical asset như:

• LCP image;
• critical stylesheet;
• font cần cho visible text;
• script hoặc data cần trước khi important UI có thể xuất hiện.

Với mỗi critical request, hãy kiểm tra cả:

Đây là cầu nối giữa waterfall analysis và late LCP discovery.

Cách Nhận Biết Late Resource Discovery

Hãy hỏi:

So sánh request start time với document timeline.

Possible discovery path gồm:

• HTML → image;
• HTML → stylesheet → background image;
• HTML → JavaScript → component → image;
• HTML → JavaScript → API → UI resource;
• HTML → tag manager → third-party resource.

Waterfall có thể cho thấy một request bắt đầu muộn.

Nhưng thường bản thân waterfall không thể giải thích chính xác vì sao request bắt đầu đúng thời điểm đó.

Đây là lúc initiator trở nên quan trọng.

Dùng Request Initiator Để Hiểu Vì Sao Request Bắt Đầu Muộn

Thông tin request initiator trong Network panel giúp giải thích điều gì đã gây ra request.

Chrome có thể xác định initiator như:

• HTML parser;
• redirect;
• JavaScript;
• browser hoặc navigation activity khác.

Initiator tab cũng có thể cho thấy request initiator chain.

Khi critical request bắt đầu muộn, hãy kiểm tra initiator trước khi mặc định bản thân resource là problem.

Cách Đọc Resource Dependency Chain

Resource thường phụ thuộc vào resource trước đó hoặc application work.

For example:

Mỗi dependency có thể đẩy user-visible critical request lùi về sau trong timeline.

Chrome DevTools có thể cho thấy initiator và dependency của request, giúp lộ ra các relationship này.

Không nên mặc định mọi dependency chain đều xấu.

Câu hỏi quan trọng là dependency đó có delay thứ gì quan trọng với user-visible critical path hay không.

Parallel Và Serial Loading

Waterfalls make request overlap visible.

Parallel loading

Nhiều request overlap theo thời gian.

Serial loading

Một request chỉ bắt đầu sau khi request hoặc dependency khác đạt tới một điểm nhất định.

Serial behavior không tự động là performance problem.

Nó trở nên quan trọng khi serialized dependency kiểm soát:

• critical content;
• LCP resource discovery;
• rendering;
• important user-facing UI.

Cách Tìm LCP Resource Trong Waterfall

Bắt đầu bằng việc identify the LCP element.

Nếu LCP candidate đó dùng network resource, hãy tìm corresponding request trong waterfall.

Sau đó kiểm tra:

• request start time;
• initiator;
• waiting time;
• content download duration;
• completion time.

Điều này giúp trả lời LCP problem liên quan tới:

• document response;
• late discovery;
• slow resource transfer;
• hoặc thứ gì xảy ra sau khi network resource đã sẵn sàng.

Để xem full routing framework, xem diagnose slow LCP.

Pattern 1: High Document TTFB

Pattern:

Điều này cho thấy response path cần investigation.

Nó không chứng minh:

• hosting yếu;
• PHP chậm;
• database chậm;
• CDN misconfigured.

Đó chỉ là hypothesis cần thêm evidence.

Pattern 2: Critical Resource Bắt Đầu Quá Muộn

Pattern:

Điều này chỉ về discovery, dependency hoặc scheduling.

Bước tiếp theo thường là:

1. kiểm tra request start time;
2. kiểm tra initiator;
3. kiểm tra dependency chain;
4. xác định resource có nằm trên user-visible critical path không.

Với LCP-specific case, xem late LCP discovery.

Pattern 3: Resource Download Quá Chậm

Pattern:

Possible investigation direction gồm:

• resource transfer size;
• compression;
• connection throughput;
• origin hoặc CDN delivery;
• responsive resource selection;
• network condition.

Đây là transfer problem hypothesis, không phải automatic image-format recommendation.

Pattern 4: Third-Party Request Chiếm Phần Lớn Network

Bên thứ ba activity có thể hiện ra dưới dạng:

• nhiều external domain;
• request được initiate bởi tag hoặc script;
• late dependency chain;
• analytics, advertising, chat hoặc embedded-media request overlap.

Waterfall có thể cho thấy network cost và request relationship.

Nó không cho thấy full CPU execution cost của third-party JavaScript.

Khi Waterfall Trông Ổn Nhưng Page Vẫn Chậm

Đôi khi important request có vẻ hoàn thành nhanh nhưng page vẫn cảm giác chậm.

Possible direction gồm:

• long JavaScript task;
• style calculation;
• layout;
• rendering work;
• client-side execution;
• interaction processing.

Đây là điểm waterfall đã chạm giới hạn.

Hãy dùng Performance Truy vết và cân nhắc phân biệt network vs CPU bottleneck.

Network Cost Và CPU Cost

Cache Signal Làm Waterfall Thay Đổi

Một request có thể đến từ:

• memory cache;
• disk cache;
• Service Worker;
• CDN hoặc edge cache;
• network hoặc origin.

Cache state khác nhau có thể tạo waterfall rất khác nhau.

Repeat visit với warm browser cache không nên được xem là tương đương first visit với cold cache.

First Load Và Repeat Load

Luôn xác định state bạn đang quan sát.

First load có thể gồm:

• connection setup;
• DNS;
• cold browser cache;
• first-time third-party request;
• uncached resource transfer.

Repeat load có thể reuse:

• connection;
• browser cache;
• Service Worker response;
• cached resource khác.

Dùng một performance baseline xác định để comparison có ý nghĩa.

Di động Và Desktop Waterfall Có Thể Khác Nhau

Desktop waterfall behavior không tự động đại diện mobile.

Khác biệt có thể đến từ:

• network profile;
• device behavior;
• responsive image;
• conditional resource;
• script behavior;
• viewport-driven application path khác.

Khi mobile experience là issue, hãy reproduce và inspect relevant mobile condition thay vì dựa vào desktop-only waterfall.

Dùng Filter Và Sort Để Trả Lời Một Câu Hỏi Cụ Thể

Network panel cho phép filter resource type như:

• document;
• CSS;
• JavaScript;
• image;
• font;
• Fetch/XHR.

Bạn cũng có thể inspect specific domain hoặc sort waterfall theo start time, response time, end time, total duration hoặc latency.

Ví dụ:

• Image request nào bắt đầu muộn nhất?
• Request nào dành nhiều thời gian waiting nhất?
• Bên thứ ba domain nào tạo nhiều request activity nhất?
• Resource nào kết thúc sau thời điểm user-visible critical content lẽ ra đã phải xuất hiện?

Các Câu Hỏi Diagnostic Khi Đọc Waterfall

Waterfall Pattern → Ý Nghĩa → Giới Hạn → Bước Tiếp Theo

Request Stage → Diagnostic Meaning → Câu Hỏi Tiếp Theo

Waterfall Diagnostic Decision Tree Thực Tế

DOCUMENT RESPONSE CÓ MUỘN KHÔNG?
│
├─ CÓ
│  └─ Điều tra TTFB → cache → origin → server / application
│
└─ KHÔNG
   ↓
NGHIÊM TRỌNG RESOURCE CÓ BẮT ĐẦU MUỘN KHÔNG?
│
├─ CÓ
│  └─ Kiểm tra discovery → initiator → dependency chain
│
└─ KHÔNG
   ↓
RESOURCE CÓ DOWNLOAD QUÁ LÂU KHÔNG?
│
├─ CÓ
│  └─ Điều tra transfer size → network → CDN → throughput
│
└─ KHÔNG
   ↓
PAGE VẪN CHẬM SAU KHI RESOURCE HOÀN THÀNH?
│
├─ CÓ
│  └─ Dùng Performance Truy vết → CPU → main thread → rendering
│
└─ KHÔNG
   └─ Tiếp tục dependency / critical-path analysis

Những Sai Lầm Phổ Biến Khi Đọc Network Waterfall

Network Waterfall Không Thể Cho Bạn Biết Điều Gì?

Waterfall mạnh nhưng scope có giới hạn.

Nó không giải thích đầy đủ:

Nếu network trông ổn nhưng page vẫn chậm, hãy tiếp tục với Performance Truy vết.

Nếu document response chậm, hãy tiếp tục với server hoặc application evidence.

Nếu request bắt đầu muộn, hãy tiếp tục với initiator và dependency evidence.

Nên Inspect Evidence Gì Tiếp Theo?

• Request Initiator
• Performance Truy vết
• Network vs CPU Bottleneck
• Diagnose Slow LCP
• Late LCP Discovery
• Identify the LCP Element
• Diagnose High WordPress TTFB
• Performance Baseline
• Kiểm chứng a Performance Change
• Performance Investigation

Điểm Cần Nhớ

Hãy bắt đầu với:

• document request;
• critical request start time;
• Waiting (TTFB);
• Content Download;
• request initiator;
• dependency relationship.

Sau đó xác định bottleneck nằm ở:

• network;
• delivery;
• resource discovery;
• hoặc nằm hoàn toàn ngoài network.

Waterfall là evidence. Chẩn đoán nguyên nhân gốc cần layer proof tiếp theo.