Before fixing a slow website, identify whether the delay comes from downloading files, running JavaScript, rendering the layout, or waiting for the server. Browser DevTools shows all four without installing another service.
Use this pass as a diagnosis, not a score chase. You want one or two clear bottlenecks that explain what visitors feel.
Open a fresh test
Open the page in an incognito window so extensions and old cached files do not change the result. Then open DevTools and switch to the Network panel.
Enable Disable cache while DevTools is open and reload the page. This creates a first-visit view: every stylesheet, script, font, image, and API request has to load again.
Read the Network waterfall
The waterfall is a timeline of every request. Each row is one file or response. Start with these columns:
- Name: the requested file or URL.
- Type: image, script, stylesheet, font, document, fetch, or another resource type.
- Size: how much data moved over the network.
- Time: how long the request took.
- Waterfall: when the request started and what it waited on.
Sort by Size first. If a 3.8 MB JPEG, a large video thumbnail, or several heavy font files sit at the top, the page has a download-weight problem.
Sort by Time next. A small file can still slow the page if the server takes too long to respond or the browser waits on a third-party domain before rendering.
Check what blocks rendering
Slow downloads are not the only issue. A page can finish its downloads and still feel stuck because JavaScript occupies the main thread.
Open the Performance panel, start a recording, reload the page, wait a moment, and stop. Look for long yellow sections. Those represent JavaScript work. A long block near the start of the load can delay first paint, scrolling, and button input.
Common sources include:
- analytics and tag-manager bundles
- chat widgets and popups
- A/B testing scripts
- large theme or framework bundles
- custom scripts that run before the page is usable
If the Network panel looks fine but Performance shows long JavaScript work, move to the third-party scripts guide.
Find unused code
Open Coverage from the DevTools command menu or More tools. Reload the page with Coverage recording.
Coverage shows how much CSS and JavaScript loaded but did not run on the first page view. A high unused percentage does not mean you can delete the file today, but it does show where page weight is hiding.
For example, 70% unused JavaScript in a theme bundle tells you the browser downloads and parses code that the first screen does not need.
Test the mobile path
Desktop tests can hide the problem. Use device emulation or a real phone, then apply a slower network profile. Watch what appears first:
- Does the header appear but the main content stays blank?
- Does the hero image arrive late?
- Does text shift when a font loads?
- Does the page respond slowly after it looks loaded?
Those observations matter because mobile visitors feel CPU and network costs sooner than a laptop does.
Turn the diagnosis into a fix
Map the evidence to the next step:
- Big image downloads: fix dimensions, format, and compression in the image guide.
- Long JavaScript tasks: audit first-party and third-party scripts in the scripts guide.
- Late or unstable first screen: adjust loading order in the loading guide.
- Repeat visits keep downloading the same files: check cache headers in the caching guide.
Do one change, test again, and keep the before-and-after trace. The goal is not a perfect report. The goal is a page whose slow part you can name.
