What the speed test measures
For each device the report shows the Lighthouse performance score and these lab metrics:
- Largest Contentful Paint (LCP): when the biggest image or text block appears.
- First Contentful Paint (FCP): when anything appears at all.
- Total Blocking Time (TBT): how long scripts keep the browser too busy to respond.
- Cumulative Layout Shift (CLS): how much the layout moves while the page loads.
- Speed Index: how quickly the visible area fills in.
Around the metrics you get a filmstrip of the mobile load, page weight by resource type, and up to eight Lighthouse opportunities per device, such as render-blocking resources, unused JavaScript and CSS, oversized images, short cache lifetimes and heavy third-party code. Sitequiry also times the server's first response (TTFB) on its own request and checks whether the HTML arrives compressed.
How the speed score is calculated
The speed score is 70% the mobile performance score and 30% the desktop score. A page with 52 on mobile and 90 on desktop gets 63 (36.4 + 27, rounded). Mobile weighs more because Google uses the mobile version of a page for indexing and ranking (Google Search Central).
Both device scores stay visible in the report. To read them, use the PageSpeed Insights bands: 90 or above is good, 50 to 89 needs improvement, below 50 is poor.
Lab data and real-user data
The metrics above are lab data: one simulated load, good for finding causes but not a record of what your visitors experienced. Where Google has enough visits from Chrome users, PageSpeed also returns field data from the Chrome UX Report for the previous 28 days. If the URL itself has too few visits, Google falls back to the whole origin; if the origin has too few as well, there is no field data at all (PageSpeed Insights documentation).
The report shows field data when it exists and says plainly when it does not. Missing field data is common on small sites and is not a failing grade. It is also why Interaction to Next Paint (INP) can be absent: it needs real taps and clicks, so it only comes from field data.
The thresholds for each metric and what moves them are in Core Web Vitals explained.
Which part of the report answers which question
| Question | Where to look | Evidence label |
|---|---|---|
| Does the main content appear quickly on a phone? | Mobile LCP, plus field LCP when Google has it | Measured |
| Does the page react when someone taps? | TBT in the lab run; INP only from field data | Measured |
| Does the layout jump while loading? | CLS from the lab run and, when available, from field data | Measured |
| Is the server slow before anything loads? | TTFB from Sitequiry's own request, flagged above about 800 ms | Measured |
| Is the HTML sent compressed? | The content-encoding response header |
Detected |
| What if PageSpeed returns no result? | An estimate from the page structure, capped at 90 and labelled "Estimate — not measured" | Inferred |
Turning a slow result into fixes
Lighthouse names the opportunities. Which one to start with depends on the metric that fails:
- Slow LCP and the LCP element is a large image: serve that image at its displayed size in a modern format, and do not lazy-load it.
- Slow LCP and a high TTFB: the delay starts on the server, so page caching or better hosting helps more than image work.
- High TBT: count the scripts. Theme features, page builders, chat widgets and tag managers are the usual weight; remove or defer whatever the first view does not need.
- High CLS: reserve space for images, embeds and banners before they load.
How to fix SEO audit issues walks through the heavy hero image case step by step, and speeding up a Shopify store deals with themes and apps.
Does page speed affect Google rankings?
Google says Core Web Vitals are used by its ranking systems, but that good results do not mean a page will rank at the top, and that it still shows the most relevant content even when its page experience is weaker (Google Search Central). Fix speed for your visitors first: a page that appears late or jumps around makes it harder for them to reach the offer. Any search benefit comes on top, mostly where several pages answer a query equally well.
Limits, and testing more than one page
The free test covers one URL. Lab scores move by a few points between runs because network and server conditions change, so compare individual metrics rather than chasing one number. Within 24 hours the same address returns the stored result; test again after that to see the effect of a change.
For a whole site, the paid Site Report checks up to 20 key pages and runs PageSpeed on mobile and desktop for the five most important page templates. If you would rather have the speed work done for you, the GE-KO agency takes inquiries.
Frequently asked questions
Is the website speed test free?
Yes. Each analysis checks one page and shows the full result without an account. Payment is only involved if you want many pages checked at once.
Why is my score different from PageSpeed Insights?
PageSpeed Insights shows mobile and desktop separately, while the Sitequiry speed score combines them 70/30. The device scores come from the same Google service, but two separate runs rarely produce identical numbers.
What does "no field data" mean?
Google has not recorded enough Chrome visits to the page or the site in the last 28 days to publish real-user numbers. The lab metrics still show what to fix.
Do I need a score of 100?
No. Aim for good mobile metrics rather than a perfect number. Google itself notes that chasing a perfect score only for SEO may not be the best use of your time.
Can I test a page behind a login?
No. The page has to be publicly reachable, because both Sitequiry and Google PageSpeed fetch it from the internet.
Test your page speed now
Mobile and desktop PageSpeed runs, free, in one report.