Speed is the foundation everything else on your site stands on. A beautiful site that loads slowly is a beautiful site nobody waits for.
The speed rules that matter for rankings in 2026 come down to three numbers, called Core Web Vitals. They measure how fast your main content appears (LCP), how fast the page reacts when someone taps (INP), and how much the layout jumps around while it loads (CLS). Pass all three for real visitors and you have taken a handbrake off your rankings and your revenue. Fail them and every dollar you spend on content and ads is working uphill.
Below is what each number means, how Google measures it, and the short list of fixes that do most of the work.
The three numbers to obsess over
- LCP (Largest Contentful Paint), your main content should render within 2.5 seconds. This is the "is anything happening?" metric.
- INP (Interaction to Next Paint), replaced FID in March 2024 and measures real responsiveness. Aim for 200ms or less.
- CLS (Cumulative Layout Shift), keep it at 0.1 or below so nothing jumps under the user's finger.
Each one maps to a feeling your visitor has, whether they could name it or not. LCP is patience: "is this thing broken?" INP is control: "did my tap register?" CLS is trust: "why did I just hit the wrong button?" A site that fails any one of them feels cheap, even when the design is gorgeous.
INP changed what counts. The old metric only measured the delay on the very first interaction. INP observes every tap, click and keypress across the whole visit and reports one of the slowest. So the chunky mega menu, the filter panel on your shop page and the booking widget three screens down all count now.
Most sites still fail. The HTTP Archive's 2025 Web Almanac found only 48% of mobile sites pass all three. LCP is the hardest on phones, with 62% of sites rated good. INP shows the widest gap between devices: 97% of sites pass it on desktop and 77% on mobile.
How Google scores you
This part causes the most confusion.
There are two kinds of speed data. Lab data is what you get when you run a test tool like Lighthouse: one simulated visit, on one simulated device, at one moment. Field data is what real people experience on real phones over real connections, collected from Chrome users who have usage statistic reporting switched on.
Core Web Vitals are field metrics. Google describes them as a measure of real-world user experience, and that is what its ranking systems look at. Your Lighthouse score is a diagnostic. You can hit 100 in the lab on your office wifi and still fail in the field because half your customers are on a mid-range Android in a car park with one bar of signal.
Google also judges each metric at the 75th percentile of visits. In plain English, three out of four visits need to hit the target. Your fastest visitors don't rescue you. Your slowest quarter decides it. So testing on your own new laptop tells you very little about how the site feels to the people paying you.
Where to look: Google Search Console has a Core Web Vitals report that sorts groups of similar URLs into good, needs improvement and poor, using field data. PageSpeed Insights shows both field and lab results for a single URL. Start with Search Console, because it tells you which templates are failing across the whole site instead of one page at a time.
What moves these numbers
In our view, most "optimisation" advice is noise. The moves that matter are boring:
Ship less JavaScript. Serve images in next-gen formats. Reserve space for everything before it loads.
Edge caching, WebP and AVIF images, font preloading and code-splitting will not make a headline, but they are where the gains are. Speed also compounds. Faster pages convert better, which funds more traffic. And on very large sites, Google says its crawl limit goes up when a site responds quickly.
Fixing a slow LCP
Your largest element is usually the hero image, a hero video poster or a big headline. Find out which one it is first, because the fix depends on it.
- Serve the hero image as WebP or AVIF, sized for the screen it's shown on. A 4000 pixel photo squeezed into a phone screen is wasted download.
- Never lazy-load the hero. Lazy loading is for images below the fold. Tell the browser to fetch the hero early by setting its fetchpriority attribute to high.
- Cut the server response time. Cache pages at the edge so the HTML arrives from a data centre near your visitor instead of one server on the other side of the world.
- Stop render-blocking. A stylesheet in the head holds up everything after it until it has loaded.
Fixing a slow INP
INP is usually a JavaScript problem. When someone taps, the browser can't respond while the main thread is busy running other scripts.
- Audit your third-party scripts. Chat widgets, heatmaps, review badges and old tracking pixels pile up for years, and each one competes for the main thread.
- Break up long tasks. Code that runs in one big chunk blocks every tap until it's done. Split it so the browser can breathe between pieces.
- Give instant feedback. Show the button pressed or the menu opening straight away, then do the heavy work after the paint.
Fixing a bad CLS
- Give every image and video a width and height so the browser reserves the space before the file arrives.
- Reserve room for ads, embeds and cookie banners instead of letting them shove content down.
- Preload your fonts and pick a fallback with similar proportions, so text doesn't reflow when the web font lands.
Your one-week Core Web Vitals audit
You don't need a developer to find out where you stand. An afternoon and some honesty will do it. Go in this order.
- Open Search Console's Core Web Vitals report. Note which URL groups are poor on mobile. Start there, because mobile pass rates trail desktop.
- Pick your three money pages. Usually the homepage, your top service or product page, and the landing page your ads point at. Run each through PageSpeed Insights.
- Identify the failing metric per page. Don't try to fix everything. Find the one number in the red on each page.
- Find the culprit element. PageSpeed Insights tells you which element is the LCP, which scripts are hogging the main thread and which elements shifted.
- List every third-party script. Ask who uses the data from each one and when they last looked at it. Delete what nobody can defend.
- Fix, then wait. PageSpeed Insights reports field data over the previous 28-day collection period, so improvements show up gradually. Don't panic when nothing changes on day two.
The business case
Even tiny delays cost money. Deloitte's Milliseconds Make Millions study, commissioned by Google, found a 0.1 second improvement in mobile site speed lifted retail conversions by 8.4%. When we rebuild a site for performance, we aren't chasing a green Lighthouse score for bragging rights, we are recovering revenue that was leaking out the back door the entire time.
Here is a hypothetical. Say you run a Brisbane physio clinic spending $4,000 a month on Google Ads, all pointed at a booking page that takes five seconds to show anything useful on a phone. Some of the people you paid to click leave before the page appears. You paid for the click, Google counted it, and the patient went to the clinic down the road whose page loaded first.
Now fix the page so it loads in under two seconds. The ads and the $4,000 budget are untouched. You've stopped losing people in the gap between the click and the content, and every visitor you keep is one you already paid for. Speed work makes the money you're already spending work harder.
It can also lower what you pay for traffic in the first place. Google counts ad and landing page quality in Ad Rank and says higher quality ads can often lead to lower costs per click. A slow, jumpy page is a poor experience by any definition. We break down the full cost of a sluggish site in why a slow website is a silent business killer.
Common mistakes that waste the budget
Chasing the lab score. It is easy to burn weeks turning a Lighthouse 88 into a 97 while the field data doesn't move. Fix what real users experience.
Adding a speed plugin on top of a bloated build. A caching plugin on a page builder theme loaded with sliders, animation libraries and six font families is a bandage on a broken leg. Sometimes the honest answer is a rebuild, which is the trap we unpack in the real cost of a cheap website.
Testing on desktop. The Web Almanac figures above have 56% of sites passing on desktop against 48% on mobile, so your desktop result is probably the flattering one. Test on the device your customers hold.
Treating it as a one-off. Speed decays. Each tracking pixel, marketing embed and "quick" homepage carousel adds weight. Without someone guarding it, a fast site drifts back to slow.
Autoplaying heavy video in the hero. Video sells, but a full-weight file loading before anything else hits LCP hard. Show a light poster image first, compress the file hard, and host it on infrastructure built for video.
Speed is a habit you keep
Core Web Vitals won't win you rankings on their own. Great content and clear answers still do the heavy lifting. But passing them removes a tax you're paying on every page and every campaign.
Treat speed like hygiene. Before a new feature ships, ask what it costs in load time and whether it is worth that. Keep asking and the site stays fast for years.
Speed matters most on the pages where money changes hands. If your ads land on a slow page, fix that page first. We cover how to build those pages properly in the anatomy of a landing page that prints money.
If you'd rather hand the whole thing to people who build for speed from the first line of code, that's what our web development team does. We build lean, we test on real phones, and we measure what your customers actually feel, not what a lab simulator guesses.
Frequently asked questions
Do Core Web Vitals still affect Google rankings in 2026?
Yes. Google says Core Web Vitals are used by its ranking systems, and they are measured on field data from real Chrome users. They won't outrank better content on their own, because Google puts relevance first. Where several pages answer the query well, a faster, more stable page can help. They also affect conversions directly, which matters even more than rankings.
What is a good INP score?
Aim for 200 milliseconds or less, measured on real visits. INP tracks the delay between a tap, click or keypress and the next visual update, across the whole visit. Heavy JavaScript and piles of third-party scripts are the usual suspects, so start your audit there.
Why is my PageSpeed score good but Search Console says my pages are poor?
The PageSpeed performance score is lab data from one simulated visit. Search Console uses field data from real visitors, judged at the 75th percentile. If your slowest quarter of visitors are on older phones or weak connections, you can look fast in the lab and still fail in the field. Core Web Vitals are scored on the field.
How long does it take to see Core Web Vitals improvements?
Field data covers the previous 28 days, so after you ship a fix the reported numbers improve gradually over about a month. Your conversion rate can respond much sooner, because real visitors get the faster page from the first day. Measure both, and give each change time before judging it.