Editorial illustration; the browser timings and labels are representative, not a live website capture.
A slow website is often described as if it has one problem: “the page takes too long to load.” That sentence is not yet a diagnosis. The delay may come from the server, a database request, a third-party script, a large image, a redirect, or a browser-side task that happens after the document arrives.
Chrome DevTools’ Network panel is useful because it lets you inspect the requests that make up a page. This guide focuses on one practical outcome: identify the request that deserves attention before you install an optimisation plugin or rewrite a working feature.
Summary
- Record a clean reload with the Network panel open and cache disabled for the test.
- Sort by duration, inspect status and timing, and distinguish waiting from downloading.
- Change one likely cause, repeat the same test, and keep the before-and-after evidence.
What problem does this solve?
Use this workflow when a page feels slow but you do not know whether the cause is your server, an asset, or an external service. It is especially useful for a small site where a full monitoring platform is unnecessary for the first investigation.
The intended search questions are “how do I find what is slowing my website?” and “what does the Network tab show?” The useful answer is not a screenshot of every DevTools control. It is a repeatable way to narrow the problem.
Before you measure
Choose one URL and one test condition. Write down whether you are testing a logged-in or logged-out page, whether the page contains personalised content, and which device or network you are using. A page with a warm cache can look healthy while a first-time visitor waits for every asset.
Open the page in Chrome, press F12 or use More tools > Developer tools, then choose Network. Enable Preserve log only when you need to observe redirects or navigation across pages. For a normal page-load test, clear the existing rows and reload.
Do not treat the number shown by one run as a universal score. Network conditions vary. Your first goal is to find a repeatable pattern.
A five-step Network panel workflow
1. Capture the page from the start
Select the Network panel before reloading. Turn on Disable cache while DevTools is open if you want to approximate a first-load investigation. This setting applies to the DevTools session; it is not a production configuration.
Reload once and wait until the page is quiet. Avoid clicking around during the capture. Save the URL, approximate time and whether the browser was mobile-sized so another person can reproduce the test.
2. Find candidates instead of reading every row
The request table usually contains documents, scripts, stylesheets, images, fonts, fetch/XHR calls and third-party resources. Sort by the Time column if available, or look for long horizontal bars in the waterfall.
Start with the longest few requests. A long request is a candidate, not automatically the cause: a large image may be slow because the connection is slow, while a tiny API request may be slow because the server is waiting on a database.
Use the filter box to compare categories such as Img, JS, Fetch/XHR and Doc. If the page is slow before anything is visible, inspect the document request first. If the page appears and then becomes interactive slowly, look at scripts and long tasks as a separate browser investigation.
3. Read the status and size together
Open a candidate request and check its status code, transferred size and response size. A redirect chain can add waiting time. A large transferred response can point to compression, image sizing or an oversized JavaScript bundle. A failed request can trigger retries or leave the interface waiting for content that never arrives.
Do not assume a 200 response means the request is healthy. It may still be returning far more data than the page needs. Conversely, a cached response may be fast because the browser did not download it during this run.
4. Use the Timing tab to name the delay
The Timing tab breaks a request into phases. Names vary slightly by browser version, but the useful questions are stable:
- Is the browser waiting for a connection or socket?
- Is DNS or connection setup unusually long?
- Is Waiting for server response the largest phase?
- Is the response itself large or slow to download?
If server waiting dominates, inspect the endpoint, application logs, database work and upstream calls. If download dominates, inspect response size, compression and delivery location. If a third-party request dominates, decide whether the feature is essential, deferable or removable.
5. Change one thing and repeat
Make the smallest safe test. For example, temporarily remove one analytics script in a local copy, resize one hero image, or test the endpoint without a third-party dependency. Repeat the same URL and conditions, then compare the candidate request and the user-visible result.
Do not make five changes at once. You may get a faster page but lose the ability to explain why it improved or which change created a new failure.
Example: the page is slow after it appears
Suppose the document request finishes quickly, but the page remains busy for several seconds. The Network panel shows a long Fetch/XHR request to a recommendation service and a large JavaScript file loaded by a chat widget.
The next action is not automatically “add caching.” Ask whether the recommendation is required before the visitor can read the page. If not, load it after the main content, reduce the response fields, or remove the feature from low-value pages. Verify that the page still works when the service is unavailable.
Common mistakes
- Measuring a single run and treating it as a permanent benchmark.
- Blaming the biggest file when the slowest phase is actually server waiting.
- Testing while logged in and assuming anonymous visitors see the same response.
- Optimising a third-party script without checking whether the feature is needed.
- Changing cache, images, plugins and code at the same time.
For a broader operational habit, compare this workflow with a small website runbook and a reproducible bug report.
My Take
The Network panel is most valuable as a thinking tool. It replaces “the site feels slow” with a short statement such as “the document waits 1.8 seconds for the server” or “a third-party script loads after the page and delays interaction.” That sentence tells you what to investigate next.
Conclusion
Open Network before reloading, capture a repeatable run, find the longest meaningful request, read its timing phases, and test one change. The result should be a narrower problem and a safer next action—not a random collection of performance tweaks.