Open your website right now on your phone, on mobile data rather than your home wifi. Count the seconds until you can actually read something. If you get past three, you have a problem, and it is not a design one.
More than half of visitors leave a page that takes over three seconds to open. They leave before seeing what you sell, before the phone number, before any of it. And Google knows: it measures your site's real speed using data from actual visitors and uses it to decide whether to put you above or below your competition.
The good news is it can nearly always be fixed, and it rarely means rebuilding the site. Here is why it happens, how it is really measured, and what we do to make a site fast. Fair warning, there is a technical stretch in the middle: if you care about the outcome rather than the how, read the first section and the last.
First things first: lab is not reality
It's the most common confusion and worth clearing up immediately.
PageSpeed Insights gives you two different things. At the top, if your site has enough traffic, you get real-user data (CrUX): what people actually experience, and what Google uses as a ranking signal. Below that comes the Lighthouse test: a simulation under controlled conditions, at that instant.
The practical consequence: a Lighthouse 100 is the necessary condition, not the result. Real-user data takes weeks to reflect your changes because it's calculated over a 28-day window. So reaching 100 today and seeing the improvement in Search Console a month later is normal behaviour, not a fault.
Second consequence: never measure against the development server. In dev mode Next.js disables a good part of its optimisations. An npm run dev scores terribly and means nothing. Always measure against npm run build + npm run start, or against production directly.
The four categories, and which one really matters
Lighthouse scores four things. They don't carry equal weight for your business:
| Category | What it measures | SEO impact |
|---|---|---|
| Performance | Core Web Vitals and load times | Direct: a ranking factor |
| Accessibility | Contrast, labels, semantics, keyboard navigation | Indirect, but legally relevant |
| Best practices | HTTPS, console errors, correct images | Low, but cheap to fix |
| SEO | Metadata, indexability, crawlable links | Direct, and very easy to take to 100 |
The smart working order is the reverse of what people do by instinct: SEO and accessibility first (fast, low-risk fixes that move the scoreboard a lot for little effort), performance next (it's the one that needs several passes), and best practices last, because it usually resolves itself as a side effect.
Core Web Vitals: the three metrics that count
LCP — Largest Contentful Paint
How long the largest element on the initial screen takes to paint. Almost always the hero image or the big headline. Target: under 2.5 seconds.
In Next.js, the causes and their fixes:
- —Unoptimised hero image. Use
next/imagewithpriorityon the hero image, and only on that one. Marking ten images as priority is the same as marking none. - —Blocking fonts. Load typefaces with
next/fontinstead of a link to Google Fonts. They get self-hosted at build time, the external request disappears, andfont-display: swapapplies by default. - —High server response time. If the HTML is slow to arrive, nothing else matters. Prerender whatever you can: static pages are served from the CDN and come back practically instantly.
- —A client component wrapping half the page. A
"use client"high up the tree drags everything inside it into the browser bundle. Push"use client"as close as possible to where interactivity is genuinely needed.
CLS — Cumulative Layout Shift
How much the content moves while loading. It's the metric that annoys users most (you go to tap a button and it shifts) and the easiest to fix. Target: under 0.1.
- —Every image with declared width and height, or with
fillinside a container that has dimensions. Without that, the browser doesn't reserve the space. - —Fonts with a matched fallback.
next/fonthandles this; if you load the typeface by hand, the font swap causes a text jump. - —Nothing injected above the content after load: banners, cookie notices, promo bars. Reserve their height from the start, or overlay them instead of pushing the layout down.
INP — Interaction to Next Paint
How long the page takes to respond when the user touches something. It replaced FID in 2024. Target: under 200 ms.
- —Less JavaScript. That's the answer to 90% of INP problems. Review which components are client-side without needing to be.
- —Defer the heavy stuff. A map, a carousel, a chat widget:
next/dynamicwithssr: false, loaded when it enters the viewport or when the user asks for it. - —Third-party scripts through
next/scriptwith the right strategy:afterInteractivefor analytics,lazyOnloadfor chats and pixels.
The fixes that pay the most, in order
After a good number of audits, the distribution of points is surprisingly repeatable. This is the order by return on effort:
- —Images outside
next/image. A loose<img>in a shared component is penalising every page at once. Converting it is the most profitable fix there is. - —External fonts without
next/font. One less request to another domain and one less text jump. - —Missing metadata. Every page with its own title and description in the
metadataobject. It takes the SEO category to 100 almost by itself. - —Missing alt text. Accessibility and SEO at the same time, and it's pure attribute filling.
- —Third-party scripts in the head without async/defer. They block the first paint. Move them to
next/script. - —A bloated JavaScript bundle. This is where you have to think: what's client-side that shouldn't be, which library weighs 200 kB to do something twenty lines would solve.
- —Insufficient colour contrast. The only fix here that can change how the site looks, so it gets decided with the client, not on your own.
A note on point 7: if a brand colour falls short of the WCAG minimum, the solution isn't to change the visual identity, it's to propose the closest shade that does pass and decide it deliberately. Nobody should discover their corporate colour was changed for one Lighthouse point.
The working cycle: measure, fix, measure again
Optimising blind burns hours. The cycle is always the same:
- —Baseline against production. Measure the home page and the three or four pages that matter most to the business (contact, the flagship service, the highest-traffic landing page), on mobile and desktop. Save the numbers.
- —Locate the problem in the code. Lighthouse tells you what is failing; the code tells you where. Look for the concrete patterns:
<imgwithoutnext/image,fonts.googleapis.com, a<scriptin the layout,"use client"on components that don't need it. - —Fix in blocks, not everything at once. And check nothing broke functionally after each block: a Lighthouse 100 with a broken contact form isn't a success, it's a new problem.
- —Production build, then measure locally again. Compare against the baseline.
- —Iterate only on what's still failing. Don't repeat work already done.
When to stop. When you hit the target, or when two consecutive iterations improve by less than a point in total. That last one means what's left is structural — hosting response time, a third-party widget the business needs — and pushing further starts doing more harm than good.
One exception worth saying out loud: widgets the business needs don't get deleted for performance. The chat, the map, the conversion pixel: they get deferred, loaded on demand, served when the user asks. But they don't get removed to gain five points.
Why this comes out better on Next.js than elsewhere
Almost everything above is an architecture decision, not a trick. Next.js puts the optimisations on the default path: server rendering, static prerendering, automatic code splitting, optimised images and self-hosted fonts come as standard.
On an installation with many plugins, each one adds its own CSS and its own JavaScript to every page, and the work becomes fighting that accumulation instead of starting from zero. It's the difference between optimising and de-optimising less. We compare it in detail in Next.js vs WordPress for local SEO.
Frequently asked questions
Does Google really penalise a slow website? Penalise isn't quite the word. Core Web Vitals are a real ranking factor, but a tie-breaking one: if your content is clearly the best answer to a query, you won't drop to position 40 over a 3-second LCP. Where it shows is in competitive searches — and local searches are nearly all competitive. Between two equivalent businesses in the same city, the fast site wins.
Do I need exactly 100? No. 100 is the ideal; the reasonable target is 95 or above on average across the four categories, on mobile and desktop. Going from 95 to 100 is usually more work than going from 60 to 95, with far less return.
Why does my score change every time I measure? Because Lighthouse simulates network and CPU, and there's natural variance. Five points between two runs is normal. Watch the trend and the specific warnings, not the exact number.
Mobile or desktop? Mobile. Google's indexing is mobile-first and the mobile score is always lower because it simulates a modest device on a slow network. Fix mobile and desktop comes free.
It's already fast on my computer — why does it score badly? Because you open it on fibre, with a powerful laptop and a warm cache. The test runs on a mid-range phone with no cache. That's your prospective customer's scenario, not yours.
Conclusion
Reaching 100 on PageSpeed isn't about tricks, it's about method: measure in production, find the concrete pattern in the code, fix it without touching the design, and measure again until the curve flattens.
And since performance is only one of the four blocks Google weighs, there's little point optimising it on a site whose technical SEO is broken. If you don't know the state of the rest, start with the local SEO audit checklist.
If you want your site's numbers before deciding anything, we'll give them to you: we measure your real Core Web Vitals on mobile and desktop and tell you what's costing points and how much work it takes to fix.
Do you want your business to appear on Google?
We discuss your business, your competition, and what you really need. No obligation. We'll respond in less than 48 hours with clear guidance and a fixed quote.
Schedule Free Consultation
