Run your site through PageSpeed Insights and you get a number out of 100 in a coloured circle. It is satisfying, it is comparable, it fits in an email to a developer, and it feels like an answer.
It is not the number Google ranks on. And for a large share of Canadian small-business websites, the number Google does rank on is not visible in the report at all — the panel where it should appear is simply empty, and most people never notice, because the score below it is right there being green or red and demanding attention.
This article is about that gap. What the score actually measures, why it is not what Google uses, why your field data panel is probably blank, and what to measure instead when it is. The metrics themselves — what LCP, INP and CLS are, what the thresholds mean, how to fix each one — are covered properly in our complete guide to Core Web Vitals and SEO. This piece is about the tool, and specifically about reading it correctly when it is only telling you half of what it was designed to tell you.
PageSpeed Insights is two tools sharing one screen
The single most useful thing to understand about PageSpeed Insights is that the report is not one assessment. It is two entirely separate data sources stacked vertically, produced by different means, measuring different things, on different timescales.
The top panel: what real people experienced
The upper section — headed along the lines of discovering what your real users are experiencing — comes from the Chrome User Experience Report, usually shortened to CrUX. This is aggregated performance data collected from real Chrome users who have not disabled usage reporting, gathered over a rolling 28-day window, and reported at the 75th percentile. It is field data: actual visits, actual devices, actual networks, actual conditions.
This is the data Google uses in its page experience assessment. When Search Console tells you a group of URLs is failing Core Web Vitals, this is where that judgement comes from.
The bottom panel: what happened in one simulated test
The lower section is a Lighthouse run, executed on demand from Google's infrastructure at the moment you pressed the button. It loads your page once, on a simulated mid-tier mobile device on a throttled connection, and measures what happened. It is lab data: repeatable, controlled, and synthetic.
The performance score — the number in the circle — comes entirely from this panel. Nothing about the score is derived from your real visitors.
Side by side
| Field data (CrUX) | Lab data (Lighthouse) | |
| Source | Real Chrome users with reporting enabled | A single synthetic page load from Google’s servers |
| Timescale | Rolling 28 days | The moment you pressed the button |
| Devices | Whatever your visitors actually own | One simulated mid-tier phone on a throttled connection |
| Reported as | 75th percentile — the slowest quarter must also pass | A single run’s measurements |
| Used by Google for ranking | Yes | No |
| Available for every site | No — requires sufficient traffic | Yes, always |
| Responds to a fix | Gradually, over roughly four weeks | Immediately on the next run |
| Good for | Knowing whether you have a real problem | Diagnosing what is causing it |
Neither is better. They answer different questions, and the mistake almost everyone makes is treating an answer to one as an answer to the other.
What the score is, precisely
The performance score is a weighted average of five lab metrics, each converted to a sub-score using a log-normal curve derived from real-world data across the web, then combined.
The weights
| Metric | Weight | What it measures |
| Total Blocking Time (TBT) | 30% | How long the main thread was blocked by long tasks during load. The single heaviest weight, and the one most people ignore |
| Largest Contentful Paint (LCP) | 25% | When the largest element in the viewport finished rendering |
| Cumulative Layout Shift (CLS) | 25% | How much the layout moved unexpectedly during load |
| First Contentful Paint (FCP) | 10% | When the first text or image painted |
| Speed Index (SI) | 10% | How quickly the page visually filled in |
Three things follow from that table, and each one changes what you should do.
TBT, LCP and CLS are eighty percent of the score
If you are trying to move the number, those three are where the points are. A page can paint its first pixel quickly, score well on FCP, and still sit at 55 because the main thread is choked with JavaScript. Improving something weighted at ten percent while ignoring something weighted at thirty is the most common wasted effort in performance work.
Interaction to Next Paint is not in the score
This surprises people, because INP is a Core Web Vital and the score is widely believed to be a Core Web Vitals score. It is not. INP requires a real human interacting with the page, which cannot happen in a synthetic load. Lighthouse uses Total Blocking Time as a lab proxy for the same underlying problem — main thread congestion — and the two correlate reasonably well, but they are different metrics and one is not a measurement of the other.
The practical consequence: a green lab score tells you very little about whether your real users find the page responsive.
The curve means the last points cost the most
Because each metric is scored on a log-normal curve, improvement is not linear. Moving from 60 to 80 is comparatively easy. Moving from 80 to 95 is harder. Moving from 95 to 100 is often a disproportionate amount of engineering for a number that nobody outside your business will ever see. A score of 90 or above already places a page in roughly the top sixth of pages measured.
The score is not a stable measurement
Run the same page three times in a row and you will typically see a spread of five to ten points. This is normal and expected. It reflects network variability, server response variation, the state of third-party services at that moment, and the inherent noise of any single-sample measurement.
Which means a single score is not a fact about your site. It is one draw from a distribution. If you are comparing before and after a change, run each version several times and compare medians, or you will spend an afternoon celebrating an improvement that was noise.
The score is not a ranking factor
Google's page experience assessment uses Core Web Vitals measured from real Chrome users in the field. It does not use the Lighthouse performance score. There is no version of Google's ranking systems that reads the number in the circle.
This is not a technicality. It changes what the score is for. The score is a diagnostic instrument — a fast, free, repeatable way to find out what is slow about a page and why. It is a genuinely good tool for that. It is not a report card, and treating it as one produces a specific and common failure: a site that has been optimised to score well on a simulated mid-tier phone and still delivers a poor experience to real visitors, because the two are only loosely connected.
| CANDOUR PASSAGE — requires brand sign-off before publicationYou will find advice to aim for a score close to 100 almost everywhere, including in older posts on this site. It was reasonable guidance in 2016, when the tool was simpler and the relationship between the score and the underlying experience was more direct. It is not good guidance now, and older articles making that recommendation are on the list to be updated or consolidated. This paragraph is honest and it builds trust, which is exactly why it is worth having. It also publicly states that existing content on the site is out of date. That is a brand decision rather than an editorial one. Remove the second sentence if you would rather not draw attention to it; the point survives without it. |
The better framing is that the score is an early-warning system. A poor score is strong evidence of a real problem. A good score is weak evidence of the absence of one. Those are not symmetrical, and the asymmetry is where most people get caught.
The empty panel: why most small Canadian sites see no field data
Here is the part that almost no guide to this tool addresses properly, and it is the single most important thing for a small business to understand.
Open PageSpeed Insights for a typical Canadian small-business website and, very often, the top panel is not there. There is no field data section, or there is one showing origin-level numbers with a note that URL-level data is unavailable, or there is a partial one showing some metrics and not others. The Lighthouse score below it is present and confident and green or amber, and it is the only number on the screen.
The natural interpretation is that the report is showing you everything there is. It is not. It is showing you the half that is always available, and withholding the half that actually counts, because it does not have enough information to report it responsibly.
Why the data is missing
CrUX only publishes a metric when it has enough qualifying samples to do so without either misleading you or compromising the privacy of individual users. As of 2026 the dataset covers on the order of fifteen million origins, which sounds enormous until you consider how many websites exist.
Eligibility is assessed separately along several dimensions at once, which is why partial data is more common than no data:
- Per URL and per origin. A homepage may have enough traffic while an individual service page does not. Where URL-level data is unavailable, Google falls back to origin-level assessment.
- Per device class. Mobile field data may be published while desktop is not, or the reverse, because the two are reported separately and each needs its own sample.
- Per metric. LCP may appear while CLS or INP does not, because each metric has its own eligibility within the same report. INP in particular requires actual interactions, so a page people read and leave may never accumulate enough.
- Over a 28-day rolling window. A page launched three weeks ago has not accumulated four weeks of history yet, regardless of its traffic.
The traffic threshold itself is commonly estimated at somewhere around a hundred visits per URL per month, but Google does not publish the figure and it is not a single fixed number across all metrics and device classes. Treat any specific threshold you see quoted, including that one, as an approximation rather than a rule.
What an empty panel does and does not mean
| It does not mean | It does mean |
| Your site is fast | Google has insufficient Chrome data about this URL to report on it |
| Your site is slow | Any performance judgement you make will have to come from somewhere other than this tool |
| Something is broken | You are in the majority for a site of your size, and this is ordinary |
| Google is ignoring your site | Where URL-level data is missing, origin-level assessment is used instead |
| Re-running the test will help | Re-running produces a fresh lab result and cannot produce field data that does not exist |
That last row is worth emphasising because it is the most common wasted behaviour. People re-run the report expecting the field panel to appear. It will not. The panel is a function of your traffic over the preceding month, not of how many times you request the report.
| The uncomfortable implicationIf your field panel is empty, you cannot see the numbers Google is using, and the numbers you can see are not the ones Google is using. That is not a reason to ignore performance. It is a reason to measure it somewhere other than here — which is the subject of the next section, and the reason this article exists. |
What to measure when the field panel is blank
There are four practical alternatives, in ascending order of effort and descending order of how many businesses will actually do them. Most small Canadian businesses should do the first two and consider the third.
One: use origin-level data if it exists
Where URL-level data is unavailable, PageSpeed Insights will often still show an origin-level summary — an aggregate across your whole domain. It is blunter than per-page data, because a handful of slow templates can drag the whole origin down while your best pages pass comfortably, and a large volume of fast pages can mask a slow checkout.
But it is real field data about real visitors, which makes it more informative than any lab number. If your origin passes and your lab score is mediocre, your lab score is probably being pessimistic about your actual audience. If your origin fails and your lab score is excellent, believe the origin.
Two: read the Search Console Core Web Vitals report
This is free, you almost certainly already have the account, and it presents the same CrUX data grouped into URL groups by similar templates. That grouping is the point: it can say something useful about a category of pages even when no individual page has enough traffic to be reported alone.
It is also where you will find out whether Google considers you to have a problem, which is a different and more important question than whether a tool considers you to have one. If Search Console reports no data at all, that is itself the finding, and it moves you to the next option.
Three: collect your own field data
This is the option that closes the gap properly, and it is considerably more approachable than it sounds. Google publishes a small JavaScript library that measures the real Core Web Vitals in your visitors' browsers and reports them wherever you choose to send them — typically your existing analytics.
What this gives you that CrUX cannot:
- Data about your site regardless of traffic volume. Fifty visitors a week produces fifty measurements, which is a small sample but an infinitely better one than none.
- All browsers, not just Chrome. CrUX is Chrome-only, which for a Canadian audience means a meaningful share of Safari traffic on iPhones is invisible to it.
- Immediate feedback. No 28-day window. You ship a fix on Tuesday and see the effect on Wednesday.
- Your own segmentation — by page, by province, by device, by traffic source. CrUX aggregates all of that away.
The cost is an afternoon of implementation and a small ongoing volume of analytics events. For any business where the website is commercially important, this is the highest-value item in this article.
Four: run lab tests on a schedule rather than on impulse
Lab data is not a substitute for field data, but scheduled lab data is far more useful than occasional lab data, because a trend line survives the run-to-run noise that makes a single score unreliable.
The minimum viable version: test the same three or four pages, on the same schedule, on the same device setting, and record the median of three runs each time. What you are looking for is not the absolute number but the direction, and the day it moves. A score that drops eleven points in a week tells you something changed — usually a new script, a new plugin, or an image somebody uploaded at full resolution. That is a genuinely useful signal and the score is genuinely good at producing it.
Which to use, by situation
| Your situation | What to rely on |
| URL-level field data present | Field data, with the lab report used only to diagnose the cause |
| Origin-level only | Origin data for the verdict, Search Console for which templates fail, lab for diagnosis |
| No field data anywhere | Your own real-user measurement, plus scheduled lab tests for trend and regression detection |
| Brand new site or page | Scheduled lab tests now; revisit field data after four weeks of traffic |
| You just shipped a fix | Lab immediately to confirm the change took effect; field after roughly four weeks to confirm it mattered |
Reading the rest of the report without being misled
Below the score sit several sections that are more useful than the score itself and receive a fraction of the attention.
Opportunities and their estimated savings
Each opportunity carries an estimated time saving. Two things to know about those estimates.
First, they are estimates of the effect on the lab load, not predictions about your real users, and not predictions about your score. An opportunity promising 1.2 seconds does not translate into a defined number of points, because the points depend on which metric is affected and where you currently sit on that metric's curve.
Second, the savings do not add up. Fixing two opportunities that each claim to save a second will not save two seconds, because they frequently address overlapping causes on the same critical path. Treat them as a ranked list of things worth investigating, not as an arithmetic.
Diagnostics, which is where the useful detail lives
The diagnostics section tells you what the page is actually made of: how much JavaScript is executing and for how long, how large the DOM is, what the main thread spent its time on, which element was the LCP element, which third parties cost what. For anybody trying to understand a page rather than score it, this is the valuable part of the report.
The LCP element identification in particular is worth checking every time. A surprising proportion of pages have an LCP element nobody expected — a background image, a cookie banner, a piece of text that happens to be large — and optimising the wrong element is a common way to spend effort without moving anything.
The other three tabs
Accessibility, Best Practices and SEO are separate scores, computed by entirely separate audits, and none of them feeds the performance number. They are worth reading and they are worth acting on — particularly accessibility, which has both an ethical and an increasingly legal dimension in Canada — but they are automated checks with limited scope. A perfect accessibility score does not mean a page is accessible; it means it passed the subset of checks that can be automated, which is perhaps a third of what matters.
What the tool cannot see at all
Knowing a tool’s blind spots is most of knowing how to use it. PageSpeed Insights has six, and several of them matter more for a small Canadian business than anything the report does cover.
It tests one URL, not a journey
Every report describes a single page loaded in isolation. Your customers do not load pages in isolation — they arrive on one, click to a second, fill something in on a third. A site where every individual page scores well can still feel sluggish to use, because the cost is in the transitions and in whatever the application does between them. Nothing in this report measures that.
It is always a first visit with an empty cache
The lab run arrives with no cached assets, no warm connection and no prior state. That is the correct way to measure a new visitor and a poor way to understand a returning one. For a business whose customers come back — a booking system, a client portal, a shop with repeat purchasers — a substantial share of real sessions look nothing like the one being measured.
It cannot reach anything behind a login
Account pages, checkouts past the first step, dashboards, member areas — the tool cannot authenticate, so it cannot test them. These are frequently the slowest pages on a site, because they are dynamic, uncacheable and database-heavy, and they are also frequently the pages where the money is. They are invisible here and you will need local Lighthouse runs or real-user measurement to see them at all.
It tests an idle server
A single request to a quiet server tells you nothing about the same server serving two hundred concurrent visitors. Performance under load is a different property from performance at rest, and it is the property that matters on the days that matter. A page scoring 95 on a Tuesday morning is not a prediction about that page during a campaign.
It is Chrome, and it is not in Canada
The field data is collected from Chrome users only, which means a meaningful share of Canadian traffic — iPhone users on Safari — contributes nothing to it and is invisible in any Google-sourced performance picture. Separately, the lab run executes from Google’s own infrastructure rather than from your customers’ location, so the network path being measured is not the network path your visitors use.
For a Canadian business this compounds in a specific way. If your origin is in Canada and your visitors are in Canada, the real latency picture may be better than the lab result suggests. If your origin is elsewhere, the lab result may be flattering a path your customers never take. Either way the tool is not measuring Canadian conditions, and a location-aware lab tool is the way to check.
It does not test whether anything works
The report is silent on whether your form submits, your payment step completes, your booking widget loads its calendar, or your search returns results. A page can score 98 and be commercially broken. This sounds obvious written down and is routinely forgotten, because a green circle produces a feeling of having checked something.
| The short versionPageSpeed Insights measures a cold first load of one public page on an idle server from somewhere that is not Canada. That is a genuinely useful measurement. It is also a narrow one, and every gap in it is somewhere a real problem can live undetected. |
Why your mobile score is so much worse than your desktop score
Almost every site shows a markedly lower mobile score than desktop, frequently by thirty points or more, and people reasonably conclude their mobile site is badly broken. Usually it is not. Two separate mechanisms are stacking.
The first is the simulation. The mobile test emulates a mid-tier Android phone on a throttled connection — deliberately modest hardware and deliberately constrained bandwidth. The desktop test assumes a capable machine on a fast connection. The same page genuinely takes longer to load and become interactive under the first set of conditions, so the raw metric values are worse before any scoring happens.
The second is the curve. The scoring curves differ between form factors, and desktop is graded more strictly, because expectations on a desktop are higher. Identical metric values will score lower on desktop than on mobile.
Those two effects push in opposite directions and the first is much larger, which is why mobile ends up lower overall. The practical guidance: compare mobile to mobile over time, and desktop to desktop. A mobile score of 68 and a desktop score of 96 on the same page is an ordinary result and not, on its own, evidence of a mobile-specific defect. If you want to know whether you have one, look at whether your field data differs between form factors — that comparison is between two sets of real users and is meaningful in a way the lab comparison is not.
How PageSpeed Insights compares to the other tools
Most businesses end up with two or three speed tools giving three different answers, and conclude that performance measurement is unreliable. It is not unreliable; the tools are measuring different things under different assumptions and are not meant to agree.
| Tool | What it is | What it is good for |
| PageSpeed Insights | Field data plus a lab run, from Google’s servers | Knowing what Google sees, and a quick diagnostic. The only free tool that shows both data types together |
| Lighthouse in Chrome DevTools | A lab run on your own machine | Iterating on a fix. Faster to re-run, but your laptop and connection affect the result, so the absolute number is not comparable to PSI |
| Chrome DevTools Performance panel | Live profiling | Root-cause work — which script blocked the main thread, for how long, and why. Where you go once you know what is wrong |
| WebPageTest | Lab testing from chosen locations and real devices | Testing from a specific place on a specific device, and filmstrip comparisons. The best option for Canadian regional testing |
| GTmetrix | Lighthouse plus its own presentation and history | Trend tracking and a more readable report. Note it is running Lighthouse underneath, so it is not an independent opinion |
| CrUX Vis and the CrUX API | Field data only, as a trend | Seeing whether field metrics are moving over weeks, which PSI’s single snapshot cannot show |
| Real-user measurement in your analytics | Your own field data | The only approach that works regardless of traffic volume and covers every browser |
Two things worth knowing about the list. Several tools in common use are running Lighthouse internally, which means agreeing with each other is not corroboration — it is the same engine reporting twice. And a number of older recommendations still circulating point at tools that no longer exist: YSlow was retired years ago and Pingdom’s free speed test was discontinued, so any guide recommending them has not been revised in a long time and should be read with that in mind.
The API, which is how you make this routine instead of manual
The recommendation earlier in this article to run scheduled tests rather than impulsive ones raises an obvious objection: nobody is going to open a browser and type in four URLs every month. They will do it twice and stop.
PageSpeed Insights has a free API that removes that problem. It returns the same data the web interface shows — the Lighthouse audit and the field data where it exists — as structured JSON, for any URL you request, on whatever schedule you set. An API key is free to obtain and raises the rate limits; current quotas are published in Google’s documentation and are generous relative to what a small business needs.
What this makes possible, in ascending order of ambition:
- A scheduled job that tests your monitored pages weekly and writes the results to a spreadsheet. Twenty lines of script, and it turns performance from an occasional panic into a trend line.
- Alerting when a score drops by more than a set threshold, which catches the plugin someone installed on Thursday before it has been live for a month.
- Batch testing across many URLs — useful if you run several sites, or if you are an agency, or if you want to compare every page in a template rather than one representative page.
- Pulling field data programmatically where it exists, which lets you build the trend view that the single-snapshot interface cannot give you.
None of this requires a developer on staff. It is the kind of task a competent freelancer completes in a morning, and it is the difference between knowing your performance changed and finding out six weeks later. Some Canadian web hosting provider control panels now include scheduled performance checks of a similar kind; it is worth asking whether yours does before building anything.
Reading a real report: a worked example
An illustrative walkthrough, using a composite typical of a Canadian small-business site — a services business with maybe forty pages and a few hundred visits a week. The specific numbers are illustrative; the pattern is the common one.
What the report shows
| Section | What it says |
| Field data | Not present. No URL-level data; an origin-level summary exists showing LCP as ‘needs improvement’ and CLS as ‘good’, with no INP reported |
| Performance score (mobile) | 64 |
| Performance score (desktop) | 93 |
| Largest Contentful Paint (lab) | 3.8s |
| Total Blocking Time (lab) | 710ms |
| Cumulative Layout Shift (lab) | 0.02 |
| Initial server response time | 1.1s, flagged |
| Top opportunities | Reduce unused JavaScript, eliminate render-blocking resources, properly size images |
How to read it
Start with what is missing. There is no URL-level field data, so nothing here tells you what your actual visitors experienced on this page. The origin-level summary is the only real-user signal available, and it says LCP needs improvement across the site. That is your verdict. Everything else is diagnosis.
Now the score gap. 64 mobile against 93 desktop is a wide spread but not an alarming one, for the reasons covered earlier. Do not treat the desktop number as reassurance; your visitors are mostly on phones, and the origin field data already told you LCP is the weak point.
Next, the server response time. 1.1 seconds is the most consequential line in the whole report and it is buried in diagnostics rather than presented as an opportunity. It sits underneath the 3.8 second LCP, which means roughly a third of that LCP is spent before the browser has received anything at all. No image optimisation touches it. This single item is both the largest available improvement and the one least likely to be actioned, because it does not appear at the top of the list.
Then Total Blocking Time at 710ms. That is thirty percent of the score and it is poor, and unlike TTFB it is fully within the site’s control — it is JavaScript, and the opportunity list has already named the cause. Fixing unused JavaScript here will move the score more than anything else on the page.
Finally, CLS at 0.02 is fine. Leave it alone. A surprising amount of effort gets spent improving metrics that already pass, because they are visible and improvable, and the points are not there.
The resulting plan
- Raise the server response time with whoever operates the server — this is a hosting conversation, not a website one, and it is the item with the widest downstream effect.
- Reduce unused JavaScript to bring Total Blocking Time down, which is the largest single score component and improves real responsiveness at the same time.
- Size the images, which helps LCP and is cheap.
- Implement real-user measurement, because the absence of field data is the reason this entire exercise had to be inferential.
- Ignore CLS and Speed Index for now.
That is five decisions from one report, only one of which is the score, and the most important one is a line item most people scroll past.
The audit items that are your host’s problem, not your website’s
A useful and rarely made distinction: some of what PageSpeed Insights flags is caused by how your pages are built, and some is caused by the server underneath them. They call for completely different responses, and a business that does not separate them ends up asking a designer to fix something only a system administrator can touch.
| Audit item | Where the cause usually sits |
| Initial server response time (TTFB) | Almost always the server, the application, or the database. Rarely front-end code |
| Enable text compression | Server configuration |
| Serve static assets with an efficient cache policy | Server configuration or CDN |
| Use HTTP/2 or HTTP/3 | Server and TLS configuration |
| Avoid multiple page redirects | Server rules, or a migration that was never cleaned up |
| Properly size images | Content workflow — yours, though managed hosting often automates it |
| Eliminate render-blocking resources | Theme and template code |
| Reduce unused JavaScript | Plugins, tag manager, third-party scripts — yours |
| Reduce the impact of third-party code | Yours entirely, and usually marketing’s rather than development’s |
Time to first byte, which is the one that propagates
Server response time deserves separate treatment because it is not one line item among many. It is the floor under everything else. Every millisecond spent waiting for the first byte is a millisecond added to every subsequent metric, and no amount of front-end optimisation recovers it. If your server takes 1.4 seconds to begin responding, your Largest Contentful Paint cannot be better than 1.4 seconds no matter what you do to the images.
Three causes account for most poor TTFB on small business sites:
- A Canadian audience served from a distant origin pays a latency tax on every uncached request. Geography is not negotiable, and a Canadian web hosting provider operating domestic facilities removes it structurally rather than mitigating it. 4GoodHosting, for instance, runs facilities in Vancouver and Toronto, which puts an origin within a short hop of most Canadian visitors.
- On shared hosting your response time depends partly on what other accounts on the machine are doing. This is usually fine and occasionally is not, and the occasions correlate with your busy periods. VPS hosting converts variable performance into predictable performance by allocating resources that are actually yours.
- Work the server should not be doing. An uncached page that runs dozens of database queries to render content that changes weekly is the most common single cause. Server-level caching removes it, and managed WordPress hosting generally applies it without anyone configuring anything.
This is the point at which performance work stops being a website task and becomes an infrastructure decision. The broader relationship between the two — what hosting for SEO actually means in mechanism rather than in marketing — is covered in a separate guide, and is worth reading alongside this one if server response time is where your report is pointing.
What actually moves the number, and what actually moves the experience
These are not the same list, which is the whole argument of this article compressed into one section.
To move the lab score
- Reduce Total Blocking Time. It carries thirty percent of the score and is driven almost entirely by JavaScript execution. Deferring non-critical scripts and removing unused ones is where the points are.
- Fix Cumulative Layout Shift. Twenty-five percent of the score and usually the cheapest fix on the list — explicit width and height on images, reserved space for anything injected after load, fonts that do not cause a reflow.
- Improve Largest Contentful Paint. Twenty-five percent. Identify the actual LCP element first, then stop lazy-loading it, serve it in a modern format at the right size, and preload it if it is critical.
To move what your visitors experience
- Reduce server response time. It sits underneath every metric and is invisible in most front-end work.
- Reduce main-thread work, which improves real Interaction to Next Paint. The lab proxy points in the right direction here, so this is one place where the two lists genuinely overlap.
- Test on real hardware. A mid-range Android phone is not a slower version of your laptop; it is a different class of device with a fraction of the processing capacity.
- Consider where your visitors are. A site fast in Vancouver and slow in Moncton passes most tests and fails a quarter of its audience, which at the 75th percentile threshold is exactly the quarter that decides whether you pass.
The overlap between those two lists is substantial but not total, and the gap is where wasted effort lives. Chasing Speed Index, which carries ten percent of the score, is score work. Fixing TTFB, which carries no direct weight at all, is experience work. The first produces a better screenshot. The second produces better outcomes.
A working routine for a small Canadian business
Realistic for someone who is not a performance engineer and has other responsibilities.
Once, to set up
- Check whether you have field data at all — URL-level, origin-level, or none. This determines everything that follows.
- Connect Search Console if it is not already, and look at the Core Web Vitals report.
- If there is no field data, implement real-user measurement. This is the afternoon that pays for itself.
- Pick three or four pages that matter commercially — usually the homepage, your main service or category page, and whatever converts — and make those your monitored set.
- Record a baseline: median of three lab runs per page, and whatever field data exists.
Monthly, in about twenty minutes
- Re-run the monitored set and compare medians against the baseline. You are looking for direction and for sudden drops, not for absolute values.
- Check Search Console for any change in URL group status.
- If something moved, ask what changed on the site in that period. It is nearly always a new script, a new plugin, or an image.
Quarterly
- Review third-party scripts and remove anything nobody can justify. They accumulate silently and they are the most common cause of gradual decline.
- Check TTFB specifically, separately from the score, and raise it with your host if it has drifted. Any competent Canadian web hosting provider will be able to tell you whether the cause is the plan, the platform or the application.
- Look at your real-user data by device and region rather than in aggregate. The aggregate hides the failing quarter.
Before any peak period
- Test under load rather than at rest. A page that scores 95 when the server is idle is not a prediction about the page when it is not. The preparation sequence for a heavy trading period is a subject of its own and covered separately.
- Ask your host what headroom you actually have. A leading Canadian web hosting provider should be able to answer that with a number rather than a reassurance, and 4GoodHosting’s support team can tell you where your current plan starts to degrade.
The mistakes that recur
Treating the score as the objective
The score exists to point at problems. Optimising the pointer rather than the problem produces sites that test well and feel slow, which is a real and recognisable category of website.
Chasing 100
The curve makes the final points disproportionately expensive, run-to-run variance makes them unstable, and nothing downstream rewards them. Ninety is a good place to stop and redirect the effort somewhere it compounds.
Assuming an empty field panel means everything is fine
It means Google does not have enough data to tell you. Those are different statements and only one of them is reassuring.
Comparing a single run to a single run
A five to ten point spread between identical runs is normal. Before-and-after comparisons on single samples produce confident conclusions about noise.
Expecting field data to respond immediately
The 28-day rolling window means a fix deployed today is diluted by the previous four weeks of worse experience. Judging a fix a week later will usually conclude, wrongly, that it did not work.
Fixing the ten percent metrics first
Speed Index and First Contentful Paint carry ten percent each. Total Blocking Time carries thirty. The order in which the report lists items is not the order of their importance.
Sending the whole report to a developer
Roughly half of what it flags is server configuration and roughly half is front-end. Sending the entire thing to whoever built your theme guarantees that half of it is ignored. Split it using the table above before you ask anyone for anything.
What changes from here
Two things worth watching.
The first is that the gap between lab and field measurement is widening rather than closing, because the metrics Google cares most about are increasingly ones that cannot be simulated. Interaction to Next Paint already requires a real human. Anything measuring sustained responsiveness during a session will too. The long-run direction is that synthetic testing becomes a diagnostic tool exclusively, and anyone who wants to know how their site performs will have to measure their own users. Businesses that set up real-user measurement now are ahead of that rather than behind it.
The second is population-level: roughly half of mobile sites and slightly more desktop sites currently pass all three Core Web Vitals. That means passing is no longer a differentiator and failing is increasingly an outlier. The competitive value has shifted from being fast to not being slow, which is a lower bar and a more reachable one — and it means the return on chasing the last few points of a lab score has fallen further still.
Frequently asked questions
What is a good Google PageSpeed Insights score?
Ninety or above is classed as good and places a page in roughly the top sixth of pages measured. Fifty to eighty-nine needs improvement, and below fifty is poor. The more useful answer is that the score band matters much less than whether you have a real problem, which the score cannot tell you on its own. A page at 72 with passing field data is in better shape than a page at 96 with failing field data.
Is the PageSpeed Insights score a Google ranking factor?
No. Google's page experience assessment uses Core Web Vitals measured from real Chrome users in the field. The Lighthouse performance score is a lab measurement from a single simulated load and is not read by any ranking system. Improving the score often improves the field metrics as a side effect, which is why the confusion persists, but the score itself is a diagnostic number rather than a ranked one.
Why does my PageSpeed Insights report show no field data?
Because the Chrome UX Report does not have enough qualifying samples for that URL, device class or metric over the preceding 28 days. This is ordinary for small sites, new pages and low-traffic templates. Eligibility is assessed separately per URL, per origin, per device class and per metric, which is why partial data is more common than none at all. Re-running the report cannot produce field data that does not exist — the panel depends on your traffic, not on how many times you press the button.
Does an empty field data panel mean my site is fast?
No, and it does not mean it is slow either. It means Google has insufficient data to report on it. Where URL-level data is missing, Google falls back to origin-level assessment. If you have no field data anywhere, the practical response is to measure your own real users rather than to assume the lab score is a proxy for their experience.
How do I measure Core Web Vitals if I have no field data?
Three options in order of effort. Check for origin-level data in PageSpeed Insights, which is blunter than per-page data but still real. Check the Search Console Core Web Vitals report, which groups URLs by template and can report on a group where no single page qualifies. Then implement real-user measurement using Google's web vitals JavaScript library, sending the results to your existing analytics — this works at any traffic level, covers all browsers rather than Chrome only, and gives immediate feedback instead of a 28-day delay.
Why does my score change every time I run it?
A spread of five to ten points between identical runs is normal. It reflects network variability, server response variation, third-party service conditions and the noise inherent in a single-sample measurement. Run three times and use the median, particularly when comparing before and after a change.
Why is my Lighthouse score green but Search Console says my pages are failing?
Because they measure different things. Lighthouse simulates one mid-tier device on a throttled connection; Search Console reports what real users experienced at the 75th percentile over 28 days. Common causes of divergence: your real audience is on slower devices or further from your server than the simulation assumes, Interaction to Next Paint cannot be measured in a lab at all, and the 28-day window means recent fixes have not yet worked through. When the two disagree, the field data is the one describing reality.
Which PageSpeed Insights recommendations are hosting problems?
Initial server response time, text compression, cache policy on static assets, HTTP protocol version and redirect chains are all server-side. Render-blocking resources, unused JavaScript, third-party script impact and image sizing are site-side. Splitting the report along that line before you ask anyone to act on it saves a great deal of misdirected effort, since the two halves go to different people.
Should I aim for a score of 100?
Generally not. Each metric is scored on a log-normal curve, so the final points cost disproportionately more engineering than the earlier ones, and normal run-to-run variance means a 100 is not stable anyway. Ninety is a sensible ceiling for effort. Beyond that, time is better spent on server response time, real-user measurement and the parts of the experience the score does not capture.
Key takeaways
- PageSpeed Insights is two tools on one screen: field data from real Chrome users over 28 days, and a single simulated Lighthouse run. Only the first is used by Google for ranking.
- The performance score comes entirely from the lab panel and is not a ranking factor.
- The score is a weighted average of five metrics: Total Blocking Time at 30%, Largest Contentful Paint and Cumulative Layout Shift at 25% each, First Contentful Paint and Speed Index at 10% each.
- Interaction to Next Paint is not in the score. It cannot be measured in a lab; Total Blocking Time is the proxy.
- A score is one draw from a distribution. A five to ten point spread between identical runs is normal — compare medians, not single runs.
- Most small Canadian business sites have no URL-level field data, because CrUX requires sufficient Chrome traffic per URL, per device class and per metric over a rolling 28 days.
- An empty field panel means Google lacks data, not that the site is fine. Re-running the report will never produce it.
- When field data is absent, use origin-level data, the Search Console report, and your own real-user measurement — which works at any traffic level and covers all browsers.
- Roughly half the report describes server configuration and half describes the site. Split it before acting on it.
- Time to first byte sits underneath every other metric and no front-end work recovers it.
Conclusion
The number in the circle is the most looked-at and least understood figure in small business web performance. It is not a grade, it is not what Google ranks on, it is not stable between runs, and on most small sites it is the only number visible precisely because the more important one is missing.
None of that makes the tool bad. It is an excellent diagnostic and it is free, which is a rare combination. It simply answers a narrower question than people think it answers, and the difference between using it well and using it badly is entirely a matter of knowing which question that is.
If you take one thing from this: find out whether you have field data. If you do, that is your verdict and the lab report is your diagnostic. If you do not, stop treating the score as a verdict it was never designed to deliver, and spend an afternoon measuring your own visitors instead. Every decision after that becomes better informed, and most of them become cheaper.
When the report points at the server
A substantial share of what PageSpeed Insights flags for small business sites resolves to time to first byte, caching and server configuration — the layer beneath the website rather than the website itself. Those items do not respond to front-end work, and they set the ceiling for everything above them.
4GoodHosting runs Canadian infrastructure with data centres in Vancouver and Toronto, which removes the distance component of latency for a Canadian audience rather than mitigating it. If your report keeps pointing at initial server response time and you are not sure whether the cause is the plan, the platform or the application, that is a question worth asking directly.
Talk to 4GoodHosting about your server response time — or compare web hosting in Canada and VPS hosting if contention on a shared plan is what your numbers are describing. What you should expect from a leading Canadian web hosting provider is a specific answer about your TTFB, not a general answer about speed.
