Google Page Speed Score: What It Means for Agency Funnels

What the number is assembled from, why the two panels in PageSpeed Insights disagree, and which fixes actually move it on the funnel pages an agency ships.

What a Google Page Speed Score Is Built From

A Google page speed score is a single number from 0 to 100 that Lighthouse produces after loading one URL on a simulated mid-range phone over a deliberately slowed connection. It is a weighted summary of several separate timings, mapped onto a curve. For an agency shipping funnel pages and client sites, the first thing worth internalising is that the number is an output rather than a measurement: there is nothing inside a page called “score” to optimise, only the timings underneath it.

That distinction decides how the conversation with the client goes. A client who has been told “we need a 90” will ask why the number fell after they dropped a testimonial video into the hero. A client who has been shown which one of three timings is failing, and on which shared template, will approve the single change that lifts every page in the sub-account at once.

Lab data and field data are different numbers, and both are correct

PageSpeed Insights shows two panels for the same URL and they routinely disagree. The upper panel is field data, drawn from the Chrome User Experience Report — an aggregate of what real Chrome users experienced on that URL or origin across a rolling 28-day window. The lower panel is lab data: one Lighthouse run, executed on request, on a synthetic device with the network throttled.

Neither panel is wrong. They answer different questions, and knowing which question you are being asked is what stops you chasing the wrong fix.

The practical consequence for a new funnel is that the field panel stays empty for weeks. A brand-new client sub-account has no history in the report, so lab data is all you have, and it is all you should quote — labelled as a lab test, not as what visitors are living through.

The timings the score is assembled from

Largest Contentful Paint

LCP is the moment the largest element in the opening viewport finishes rendering. On almost every funnel page that element is the hero image or the background of the first section, which is why LCP is the timing an agency can most reliably move: it is usually one file. The published thresholds put a good result at or under 2.5 seconds and a poor one beyond 4 seconds, read at the 75th percentile of visits rather than the average.

Cumulative Layout Shift

CLS scores how much visible content jumps while the page settles. An image or embed with no reserved dimensions is the usual cause: the browser lays out the text, the asset arrives late, and everything below it is shoved down. On a funnel this is worse than an aesthetic problem, because the element that moves is often the button. A visitor who taps where the button used to be rarely tries a second time.

Interaction to Next Paint

INP measures the lag between a visitor’s tap and the next frame the browser manages to draw in response. It is the timing that punishes heavy third-party JavaScript hardest, because a script busy parsing cannot repaint. Every tracking pixel, chat widget and split-test snippet added to a page spends part of the main thread, and INP is where that spending becomes visible.

What actually costs a funnel page its score

Across the pages an agency builds, a small set of causes accounts for most of the loss, roughly in this order:

• The hero image, uncompressed and unsized. A photo exported at full camera resolution and displayed at a fraction of it is still downloaded in full before it is shrunk. Resize it to the width it will actually occupy and let the builder serve a modern format.
• Video embedded rather than deferred. A player embed pulls its own scripts before the visitor has decided to watch anything. Where the section can carry a still image that loads the player on click, it should.
• Fonts pulled from several places. Two families in five weights is a stack of separate requests, each of which can hold text back from painting. Trim the weights down to the ones the design genuinely uses.
• Scripts pasted into the page header. Header code runs before the page paints. Most analytics and pixel snippets are documented to work from the footer, and moving them there costs nothing a visitor can see.
• Embeds with no reserved height. A form or calendar dropped inline sizes itself after it loads, taking the layout with it unless a height is set on the container.

The last one turns up most often on client sites, because the form and the calendar are the point of the page. If you are embedding either, the form and survey scheduling settings are worth reading alongside this: an embed that has expired or been hidden still occupies layout while it works out what to render.

The order to work in

Speed work has a natural sequence, and doing it out of order wastes an afternoon:

1. Fix the template, not the page. Agencies build from snapshots, so a heavy header or an oversized background is duplicated across every funnel cloned from it. Repair the source and the fix travels; repair one page and you will meet it again next month.
2. Deal with the largest element first. One hero image usually outweighs every script on the page combined. Measure its transferred size before you touch anything more subtle.
3. Reserve space before you tune scripts. Setting explicit dimensions on images and embeds is cheap, safe and immediately visible in the layout-shift figure.
4. Audit the third-party list. Ask what each snippet is for and who reads its data. On an inherited client account, some of them answer to nobody.
5. Re-measure on the public URL. A builder preview and a live page do not load the same way. Test the address a visitor will actually reach, after the domain is settled and caching is warm.

Then remember that the page is one step in a sequence. A fast page handing off to a slow follow-up has moved the bottleneck rather than removed it, so the email sequence that fires after the form submit belongs to the same experience the score is trying to describe.

What the score is worth to a client, and what it is not

Page experience is one input among many, and it does not outrank relevance. A page that paints instantly and says nothing persuasive converts nobody, and a slow page with the right offer still takes bookings. The defensible way to use the number is as a floor to clear rather than a target to maximise: get the failing timings into the documented good bands, keep them there when the client adds a new section, and stop.

The honest version of the promise is procedural rather than numerical. You can commit to measuring the shared templates, to fixing the timings that fall outside the published thresholds, and to showing the field panel once there is enough traffic to fill it. You cannot commit to a specific score on a page the client will keep editing, and an agency that quotes one has agreed to be judged on a number it does not control.

See also: Upload Custom Font Builder: Formats, Weights and Fallbacks

Frequently Asked Questions

What counts as a good Google page speed score?

Lighthouse colours the number in three bands: red at the bottom, amber in the middle, and green from 90 upward. Green is a reasonable target for a funnel page because it usually means all three underlying timings are inside their published good thresholds. Treat it as a floor to clear, not a score to keep polishing.

Why does the score change every time I run the test?

A lab run is one load on a simulated device, and the conditions vary slightly each time: network simulation, server response on the day, and which third-party scripts happen to answer quickly. Small movements between runs are normal. Only act on a change you can reproduce across several runs, or on one that shows up in the field panel.

Does the page speed score itself affect search rankings?

The score is not read by search systems. What they use is field measurement of the page experience for real visits, which is the upper panel in PageSpeed Insights rather than the Lighthouse number. Fixing the timings improves both, which is why the score is still a useful working proxy for a page nobody has traffic data on yet.

Why is the mobile score so much lower than desktop?

The mobile test simulates a mid-range phone on a slowed connection, while the desktop test assumes a faster machine and network. The same page will therefore score lower on mobile almost every time. Since most funnel traffic arrives from a phone, the mobile panel is the one worth reporting to the client.

Should an agency promise a client a specific score?

It is a poor commitment, because the client can add a video or a chat widget the next day and move the number without telling you. Commit to the process instead: measure the shared templates, bring the failing timings inside the documented bands, and re-check after any structural change to the page.

Why does PageSpeed Insights show no field data for my new funnel?

Field data is aggregated from real Chrome visits over a rolling window, and a page needs enough of them before anything is reported. A funnel launched last week will usually show lab data only. That is expected, not an error, and it is a good reason to quote lab results as lab results until the field panel fills.

We build your GoHighLevel account for you

CRM, pipelines, funnels, SMS and automation — configured for your business, not left for you to figure out.

• Setup (one-time)$850
• Ongoing (per month)$38.80

Get my free setup quote

No obligation quote · reply within 1 business day

This site is independently operated and is not officially affiliated with, endorsed by, or sponsored by HighLevel LLC. We do not receive referral commissions — this is our own flat-fee implementation service.