Page load speed: how to check what’s slowing your site down and in what order to fix it

Why page load speed matters

Yandex states this directly: “Page load speed is one of the important indicators of a site’s quality.” Slow loading reduces trust in a site and affects whether a user stays or leaves for a competitor.

Google ties speed to “page experience” — the overall experience of using a page — and notes that this aligns with what the core ranking systems seek to reward. At the same time, Google doesn’t state the exact weight of this factor relative to other ranking criteria: a fast site doesn’t guarantee high rankings by itself.

Speed also has a narrower side — three specific Google metrics (LCP, INP, CLS) with their own “good” and “poor” thresholds. That’s a separate, more detailed topic that we don’t cover here; instead we look at speed as a whole — how to measure it and what to do about it.

How to measure load speed

Lab data vs. field data: what’s the difference

Speed-measurement tools use two different data sources:

• Lab data is collected by tools such as Lighthouse in a controlled environment: the same emulated set of network and device conditions every time. It’s useful for diagnosing specific problems because it’s reproducible.
• Field data is anonymized statistics from real users on different devices and networks, collected by the Chrome User Experience Report (CrUX). It’s a historical record of how a page actually loaded for real visitors, not a simulation.

The difference in conditions means the lab and field results for the same page almost always differ — and that’s normal, not a sign of a measurement error.

Tools: what they show and how to read the result

PageSpeed Insights shows both kinds of data for one page at the same time: a lab run and — if the page has enough real visits — field statistics from CrUX. If there isn’t enough field data, the tool shows only the lab result.

Yandex Metrica (Yandex’s web analytics platform, roughly the counterpart of Google Analytics) provides a separate “Page load time” report. It breaks loading down into stages: DNS lookup time, HTTP redirect time (if any), time spent waiting for a connection to the server, server response time (from the request to receiving the page content), the full DOM load time including all its components, and the time until the page starts rendering in the browser. To see the load time for one specific page rather than the site on average, you can set up a segment using the “URL viewed” condition.

The values in this report are given as a quantile: the 50th quantile means that in half of cases the load doesn’t exceed the stated time; the 90th quantile means it doesn’t exceed that time in nine cases out of ten. This is a different methodology from the 75th percentile that Google uses to evaluate individual Core Web Vitals metrics — comparing numbers directly between Google and Yandex isn’t worthwhile, since they use different measurements and different samples.

What most often keeps a site from loading quickly

Yandex’s official recommendation on speeding up a site describes the main areas to work on. Below are the same points as a table of causes worth looking at first:

Cause	How to see it	Who usually fixes it
Many separate HTTP requests (small CSS, JS and image files that aren’t bundled)	Lab report (Lighthouse/PageSpeed Insights), the page’s list of requests	Developer
Scripts and styles that block page rendering	Render-blocking resources diagnostic in lab data	Developer
Unoptimized images (large file size, no compression)	Page weight in the lab report	Developer, content manager
No caching and no Gzip compression	Checking server response headers	Developer, server administrator
No CDN for static assets (images, CSS, JS)	Comparing response speed from different regions	Developer, server administrator
Slow server-side code or the infrastructure itself	Server response time in Yandex Metrica, TTFB in lab data	Developer, server administrator
Unnecessary redirects before the browser reaches the target page	Redirect chain in the lab report	Developer, SEO specialist (redirect plan)

All of these points are areas the source of the recommendations itself names; the table doesn’t rank them by how often they occur — we don’t have that kind of statistics.

What order to check and fix things in

1. Get the overall picture: lab and field data for key pages (the homepage, a service or product page, a popular article).
2. Check the server response time — if it’s high, the other optimizations will have less effect.
3. Check the page’s and images’ weight — this is usually the most noticeable part of the lab report.
4. Check that rendering isn’t blocked by unnecessary scripts and styles.
5. Check redirect chains on key pages.

Load speed depends on the server, the code and third-party scripts. The SEO specialist finds and describes such problems as part of technical SEO — what exactly is getting in the way and why it matters — but changes to the code and the server are made by the developer.

Where SEO comes in

Technical SEO lowers the barriers to crawling and indexing — including performance problems that keep a crawler from processing a page correctly. But on its own it doesn’t guarantee higher rankings: speed is one of many factors, not the only one.

If you’re interested in more than just speed — a broader check of the site — see what gets checked in an SEO audit of a site. An SEO audit covers more parameters than load speed alone.

Frequently asked questions

Why does the speed in PageSpeed Insights differ from what real site visitors see?

Because the tool shows two different data sets: lab (one emulated run under controlled conditions) and field (real visitor statistics from CrUX). These figures measure different situations, and they don’t have to match.

How do you check the load speed of one specific page rather than the whole site?

In Yandex Metrica — set up a segment using the “URL viewed” condition in the “Page load time” report and specify the address of the page you need. PageSpeed Insights, by default, also shows data for the one specific address you’re checking.

What does the 90th quantile mean in the “Page load time” report?

It means the load time doesn’t exceed the stated value in nine out of ten of the measured loads. The 50th quantile shows the median value — half of the cases.

Does a fast site guarantee higher search rankings?

No. Google describes good page experience scores as something that aligns with what ranking systems seek to reward, but it doesn’t call this a guarantee and doesn’t disclose the factor’s exact weight. Speed is one of many signals, not the only one.

Who should speed up the site — the SEO specialist or the developer?

Different tasks. The SEO specialist finds bottlenecks and describes them in terms development can act on: what to check, what to change, and why it matters for crawling and indexing. Changes to the code, server and infrastructure are made by the developer.