Online speed tools are convenient, but every one of them tests from somewhere else, on a machine you never see. Sometimes you just want to open your own site in your own browser and watch what it downloads: which files, how big, from where, and in what order. Chrome already has a tool for that built in, free, no account needed. It is the Network tab in DevTools.
This guide shows you how to check page load in Chrome DevTools step by step, using the Network panel the way a developer does when someone says “the site feels slow”. Chrome’s interface changes now and then, so some labels may look a little different on your version; the features described here have been part of DevTools for a long time.
Step 1: open DevTools on the right page
Go to the page you want to check. Then open DevTools in one of these ways:
- Press F12, or Ctrl+Shift+I on Windows and Linux, or Cmd+Option+I on a Mac.
- Or right-click anywhere on the page and choose Inspect.
A panel opens, docked to the side or bottom of the window. Along its top is a row of tabs: Elements, Console, Sources, Network and others. Click Network. If you do not see it, the tab row may be collapsed behind a double arrow.
One important point before going further: use an incognito window if you run a WordPress site. If you are logged in, you will see the slower logged-in version of the page, which often bypasses the cache, rather than what visitors get.
Step 2: set up a fair test
Three settings near the top of the Network panel decide whether what you see means anything.
Disable cache
Tick Disable cache. If you have visited before, Chrome is holding on to copies of most files, and an ordinary reload would quietly reuse them. With this ticked, Chrome fetches everything again, as a first-time visitor’s browser would. It only applies while DevTools is open, so it does not affect your normal browsing.
Preserve log
Preserve log keeps the list when the page navigates or redirects. Leave it off for a simple page check; turn it on if you are following a journey such as adding to cart and going to checkout, or chasing a redirect.
Throttling
Next to those is a throttling menu, usually set to “No throttling”. It offers presets that slow the connection to imitate slower mobile networks. Your office broadband or home fibre is far quicker than what many phone users get, and some problems only appear on a slower connection. Pick a slower mobile preset for at least one round of checks, and remember to switch it back afterwards, or every site will feel slow to you.
This throttles the network only. Your laptop’s processor is still much faster than a budget phone. The Performance panel has a separate CPU throttling setting if you want to explore that, but the Network tab alone is enough for most checks.
Step 3: reload and read the summary
With DevTools open and the Network tab selected, reload the page (Ctrl+R or Cmd+R). The list fills with every request as it happens. When it settles, look at the status bar along the bottom of the panel. It shows roughly:
- Requests: how many files the page asked for.
- Transferred: how much data actually came over the network, after compression.
- Resources: how much those files add up to once uncompressed.
- Finish: when the last request finished. This includes late tracking calls, so do not mistake it for “when the page appeared”.
- DOMContentLoaded and Load: when the HTML was parsed, and when the page’s main load event fired. They also appear as coloured vertical lines in the waterfall column.
Write these down. They are your baseline for this page in this browser on this connection.
Step 4: sort and filter to find the heavy items
Sort by size
Click the Size column header to sort the list by size. The biggest files rise to the top. On a typical small business site you will often find an oversized image or two, a large JavaScript bundle from a page builder or slider, a video, or a font file. Those top rows are where reducing page weight starts.
The Size column can show two figures per row when you switch to larger request rows (there is a setting for this in the panel): the amount transferred and the actual size of the file. A small transferred figure and a large actual size means the file is compressed in transit, which is good. Two similar large figures on a text file such as CSS or JavaScript can mean compression is not switched on.
Sort by time
Click the Time column to see which requests took longest. A large file that takes long is expected. A small file that takes long is more interesting: it usually means a slow server, often a third party, or a request that had to wait for a new connection.
Filter by type
The filter bar lets you show only one type of file: Doc (the HTML), CSS, JS, Img, Font, Media, and Fetch/XHR for background data requests. Click Img and sort by size to see your heaviest images in one place. Click Font to count how many font files load; several weights of two or three families add up quickly.
Add the Domain column
Right-click any column header and you can add more columns. Add Domain. Now sort by it and you can see at a glance how many requests go to other companies’ servers: analytics, fonts, maps, chat, ads, review widgets. Each new domain usually means a fresh connection before anything downloads.
Look at the Initiator
The Initiator column tells you what caused each request: the HTML itself, a stylesheet, or a script. If a single script is the initiator of dozens of other requests, you have found something that pulls in a lot more than its own file, and that is often a tag manager, an ad script or a widget.
Step 5: inspect a single request
Click any row to open its details. The tabs there include Headers, showing the full URL, the status code, and response headers such as cache-control and content-encoding, and Timing, which breaks the request into phases: queueing, connection setup, waiting for the server’s first byte, and downloading.
The first row, the HTML document, is the most useful to inspect. Its timing tells you how long the server took to start answering. If that wait is long, the server or its caching is the first thing to look at, before images or scripts. The waterfall column in the main list shows the same timing visually; if you want a refresher on reading those bars and patterns, our guide to reading a waterfall chart applies here too.
Step 6: test what happens without a file
DevTools can block a specific request so you can see the page without it. Right-click a request and look for the option to block its URL or its whole domain. Reload, and the page loads without that file.
This is a quick, safe experiment. Block the chat widget’s domain and reload: does the page appear noticeably sooner? Block a slider script: does anything visible break? The live site is untouched; the block only affects your own browser while DevTools is open. Remember to remove the block when you are done.
Step 7, briefly: the Coverage tool
DevTools has a Coverage tool, opened from the three-dot menu under “More tools” or by searching for “Coverage” in the command menu (Ctrl+Shift+P or Cmd+Shift+P). Start recording, reload, and it lists each CSS and JavaScript file with how much of it was actually used on that page.
It is common to see themes and builders loading large stylesheets where most of the code is unused on any one page. That does not mean you should start deleting it, because other pages or interactions may need it. Removing unused code safely is its own job, covered in our post on reducing unused CSS. For now, Coverage helps you see which files are the biggest offenders.
After you check page load in Chrome DevTools: what to note
A quick check like this should end with a short list, for example:
- Total requests and transferred size, with throttling on and cache disabled.
- Server wait on the HTML document.
- The three heaviest files and where they come from.
- The number of outside domains and which tools they belong to.
- Anything odd: 404 errors, the same library loaded twice, redirects at the start.
Repeat the same check after a change, with the same settings, and compare. That simple habit is the core of the method in our guide on testing website speed properly. For background on how all these factors fit together, see the website loading speed guide, and Google’s own reference for this panel is the Network panel documentation.
Frequently asked questions
Why does the Network tab show different results each time I reload?
Each reload is a separate page load, so server response, network conditions and third-party files vary a little. If Disable cache is not ticked, your browser also reuses stored files, which makes reloads look faster than a first visit. Keep the settings the same, reload a few times, and look at the typical result rather than a single one.
Is the Finish time how long my page takes to load?
Not really. Finish is when the very last request completed, and that often includes analytics beacons, chat widgets or ad calls that arrive long after the page is visible and usable. For what a visitor feels, look at when the main content appeared, using the screenshots in a Performance panel recording or a lab tool such as Lighthouse.
Can I use the Network tab on my phone?
Not directly in the mobile browser. You can connect an Android phone to a computer by USB and use Chrome’s remote debugging to inspect pages loading on the phone, and Safari offers something similar for iPhones with a Mac. For most checks, the throttling presets in desktop Chrome are a practical stand-in.
Does disabling cache in DevTools affect my visitors?
No. The Disable cache option only changes how your own browser behaves while DevTools is open. It does not change any setting on your website or server, and your visitors’ browsers keep caching files exactly as before. The same is true of request blocking and throttling in DevTools.
Finding a heavy script is the easy half; removing it without breaking a form or a menu is the harder one. If you would rather hand that part over, our website speed optimisation service does it and shows you the same Network tab figures before and after.
Next in this series: How to Monitor Website Speed Over Time
