The most reliable free tool for a site speed test is Google's PageSpeed Insights: you enter a page address and it shows, for mobile and desktop, both a lab measurement and the values real users experienced. The three values to look at are the Core Web Vitals: how long the largest content takes to appear (LCP, under 2.5 seconds is good), how quickly the page responds to interaction (INP, under 200 milliseconds) and how much the page shifts while loading (CLS, under 0.1). The score out of 100 is a summary of these; track the three values, not the score.
Why Speed Is Measured by Value, Not Score
The PageSpeed score for the same page can come out at 72 and 85 five minutes apart; the measurement depends on the current load of Google's test server and its network simulation. Saying "we sped up the site" based on the score is therefore misleading. Core Web Vitals values are more stable, and what Google takes into account for ranking is these values, not the score. What the three mean:
When the largest element on screen (usually the main image or headline) appeared. Under 2.5 seconds is good, above 4 is poor. The moment the user says "the page is open".
How quickly the screen reacted when the user tapped something. Under 200 milliseconds is good, above 500 is poor. It replaced the old FID metric in 2024.
How much content shifted while loading. Under 0.1 is good, above 0.25 is poor. The "I was about to press the button, an ad loaded, I pressed something else" problem.
Google evaluates these values at the 75th percentile: the page counts as "good" if three quarters of users are under the threshold. So it is not the average that matters but the majority of slow users; a site that opens fast on the office fibre connection can still be poor if most users are on a mobile network.
Lab Data and Field Data
PageSpeed Insights shows two separate results, and they often disagree. The "Discover what your real users are experiencing" section at the top is field data collected from Chrome users over the last 28 days; it tells you how your site really opens but appears only for pages with enough traffic. The "Diagnose performance issues" section below is a lab measurement: Google's server opens the page once over a throttled mobile connection. The lab measurement is for diagnosing what is slow; field data is for knowing whether it is actually slow.
Which Pages to Test
Testing the home page and stopping there is the most common mistake. Most visitors do not arrive via the home page but land directly on a product or article page from search results. Measure three page types separately: the home page, a category page and the product or blog page with the most traffic. If the same problem shows on all three, the source is the template and one fix improves the whole site; if it shows on only one, it is specific to that page.
The Core Web Vitals report in Search Console does this in bulk: it sorts your site's pages into good, needs improvement and poor groups and lists sample addresses in each. If the number of pages in the "poor" group is growing, it is time to stop measuring and start fixing.
Free Tools and How They Differ
| Tool | What it measures | What it is for |
|---|---|---|
| PageSpeed Insights | Field + lab, mobile and desktop | First stop; Core Web Vitals and the improvement list |
| Chrome Lighthouse | Lab, from your own computer | Measuring unpublished pages and the effect of changes |
| Search Console CWV report | Field, whole site | Seeing which page group is poor |
| WebPageTest | Lab, detailed timeline | Examining second by second which request loaded when |
Results differ across all four tools, because they measure from different places under different conditions. Do not compare them with each other; compare the same tool under the same conditions over time. The definitions and thresholds are explained in detail on Google's Web Vitals page.
The Five Things That Slow a Site Most on Mobile
After hundreds of site measurements, the list barely changes:
- Uncompressed images. A 3 MB product photo alone pushes LCP above 4 seconds on mobile. WebP format and versions scaled to screen size are the first and most effective fix.
- Third-party scripts. Chat tools, marketing pixels, A/B testing tools, review plugins. Each wants to load before the page opens. Loading them only after cookie consent is the right route for both privacy and speed.
- Fonts. A custom font in four weights keeps text invisible while waiting, or shifts the page once it loads. Two weights and the "swap" setting are enough for most sites.
- Images and ad slots without dimensions. Because no space is reserved, the page shifts as content loads; the main cause of CLS.
- Server response time. On shared hosting, if the first byte arrives in 1.5 seconds, LCP will not get under 2.5 whatever you do with the rest.
Why Speed Matters Separately for Ad Traffic
If an organic visitor waits for a slow page, the cost is time; if a visitor from an ad does not wait, the cost is a paid click. A click bought for 8 TRY that bounces because the page took 5 seconds to open is an unmeasured loss of budget and appears nowhere in the ad panel; it shows up only in the conversion rate. Google Ads also reflects landing page experience in Quality Score: a slow page means a higher click cost for the same position. That is why speed improvement is not only the SEO team's topic but also the concern of whoever manages the ad budget.
In What Order to Fix
PageSpeed's improvement list feels long; there is no need to do all of it. By impact and ease, the order is:
LCP first
Compress the main image and load it with priority, measure server response time, use a CDN if you have one. On most sites this alone moves LCP to the "good" threshold.
Then CLS and INP
Give images a width and height, simplify fonts; defer heavy scripts until after interaction. A few hours of work with the technical team.
Seeing the payoff of a fix takes patience: field data is a 28-day window, and improvement reaches the reports within weeks. The lab measurement changes the same day; track the two separately.
AdsLuma's Site Crawl screen lists speed and Core Web Vitals values for crawled pages together with the other technical findings; the crawl is queued and pages are processed up to the plan limit. Having slow pages sit on the same screen as the click loss in Search Console makes it easier to decide which page to fix first.
Frequently Asked Questions About Site Speed
Which tool is used for a site speed test?
Google PageSpeed Insights is the first choice: it is free and shows field and lab data together. Lighthouse in Chrome, the Core Web Vitals report in Search Console and WebPageTest are complementary tools.
What are Core Web Vitals?
The three values Google uses to measure page experience: LCP (loading, under 2.5 seconds is good), INP (interaction response, under 200 milliseconds is good) and CLS (visual stability, under 0.1 is good). A page counts as good if 75% of users are under the threshold.
What should the PageSpeed score be?
The score is not a ranking factor and changes from measurement to measurement. Above 90 is considered good, but the real goal is for the three Core Web Vitals values to show as "good" in field data. A page scoring 70 with good values is in better shape than one scoring 95 with poor field data.
How much does site speed affect SEO?
Core Web Vitals are one of Google's ranking signals but come after content and links; a slow site can rank with good content. The real effect shows in conversions: on a page that opens slowly on mobile the user does not wait, which means wasted ad spend.
AdsLuma crawls your pages and ranks Core Web Vitals values alongside the other SEO findings by importance; with Search Console data it shows which slow page is losing traffic.
Book a demo
