How to diagnose slow page speed

“The site is slow” is not a diagnosis, and almost every wasted afternoon of performance work starts by treating it as one. Slow at what? For whom? Slow to show the first pixel, slow to become usable, or fine until you tap something? Those are four different faults with four different fixes, and the tools will tell you which one you have if you ask them in the right order.

Field data versus lab data

Lab data is a synthetic test: one page, one simulated device, one throttled connection, in a data center. Lighthouse and PageSpeed Insights’ “Diagnostics” section are lab data. It is repeatable and it tells you why something is slow, which is exactly what you need when fixing.

Field data comes from real Chrome users on real devices and real networks, aggregated over 28 days. The Chrome UX Report supplies it, PageSpeed Insights shows it at the top, and Search Console’s Core Web Vitals report is built from it. It tells you whether you have a problem and for what share of visits, but not why.

The trap is that your lab score can be poor while real users are fine — a throttled mid-range Android on a simulated 4G connection is a harsher test than most of your audience — or excellent while real users suffer, because your test URL is a cached page and their entry point is a slow search results template. Start with field data so you are solving a problem someone actually has.

Step one: read the field data

Open pagespeed.web.dev and look only at the top section, the one headed with a date range. Three metrics matter:

LCP (Largest Contentful Paint) — when the biggest visible element finished rendering. Good is 2.5s or under. This is the “nothing is on screen yet” complaint.

INP (Interaction to Next Paint) — how long the page takes to visibly respond to a tap or click, across the whole visit rather than just the first interaction. Good is 200ms or under. This is the “I pressed it and nothing happened” complaint. INP replaced First Input Delay in March 2024; any guide still telling you to optimize FID predates that and is worth checking twice on everything else too.

CLS (Cumulative Layout Shift) — how much the content jumps around as it loads. Good is 0.1 or under. This is the “I clicked the wrong thing” complaint, and it is the one users describe as “slow” even though nothing is slow at all.

If no field data appears, the URL has too little Chrome traffic to aggregate. Check whether origin-level data exists instead — it covers the whole site. If neither exists, you are working from lab data only, and should be correspondingly cautious about the numbers.

Step two: split the load into three phases

Every slow LCP is slow in one of three phases, and knowing which one eliminates most of the possible fixes immediately.

Server time. How long before the first byte arrives. If Time to First Byte is over about 800ms, nothing you do to images or JavaScript will help meaningfully — the browser has not started yet. Reducing time to first byte covers this phase on its own, because it has entirely separate causes.

Resource load time. The gap between the HTML arriving and the LCP element being fetched. Usually a hero image that is too large, loaded too late, or discovered too late because it is referenced from CSS or injected by JavaScript rather than sitting in the HTML.

Render delay. The element has arrived but nothing paints, because the main thread is busy parsing JavaScript, or a web font has not loaded and the text is invisible while it waits. This phase is where third-party scripts do their damage.

Chrome DevTools’ Performance panel gives you this breakdown directly. Record a load with the network throttled to “Fast 4G” and CPU throttled 4×, then find the LCP marker and look at what precedes it.

Step three: find the one thing that dominates

Performance is not a list of small improvements that add up. In practice one problem usually accounts for most of the delay, and fixing everything else changes almost nothing until that one is gone.

The usual dominant causes, roughly in order of how often they turn out to be the answer:

An unoptimized hero image. A 2MB PNG where a 90KB WebP would look identical. Check the actual transferred size in the Network panel, not the dimensions.

Render-blocking resources in the head. A stylesheet or synchronous script the browser must fetch and parse before it can paint anything. Each one adds a full network round trip.

Third-party scripts. Analytics, chat widgets, A/B testing, consent managers, ad tags. These are frequently the single largest cost on an otherwise well-built page, and they are the easiest to remove because they are usually somebody’s abandoned experiment. Sort the Network panel by domain and total up everything that is not yours.

Too much JavaScript. Not slow JavaScript — merely a lot of it. Parsing and executing a large bundle occupies the main thread, which delays both painting and responsiveness. This is the usual cause of a poor INP.

Slow server responses. Covered above, and the one most often misdiagnosed as a front-end problem.

Step four: change one thing and re-measure

Change one thing. Re-measure in the lab immediately to confirm the mechanism worked. Then wait for the field data, which moves on a 28-day rolling window and therefore will not confirm anything the same afternoon.

That lag is the hardest part of this discipline and the reason so much performance work is never verified. Deploy the fix, note the date, come back in a month. If the field metric has not moved, the lab improvement was real but irrelevant — which is itself a useful finding, because it means your model of who your visitors are is wrong.

Two mistakes worth avoiding

Chasing the Lighthouse score instead of the metrics. The performance score is a weighted composite that varies between runs on the same page because the throttling is simulated. A 4-point change means nothing. The individual metric values are what to track.

Testing only the homepage. Most visitors arrive on an interior page from search, and interior templates are usually heavier — more images, more third-party embeds, more of whatever the CMS adds. Diagnose the templates that receive the traffic, which Search Console’s pages report will tell you.

Where to start

Run the Core Web Vitals check on your highest-traffic landing page — not your homepage — and see which of the three metrics is failing. That tells you which phase to investigate. Our full site check reports the same metrics alongside the specific render-blocking resources and oversized assets it found, which is the step between “LCP is 4.1 seconds” and knowing what to change.

If your problem turns out to be server-side, go to how to reduce time to first byte. If it is JavaScript-heavy, JavaScript SEO and rendering covers both the speed and the indexing consequences.