Why Your Traffic Looks Fine but Your Rankings Are Slipping: 5 Website Performance Metrics That Impact Your Google Rankings & Conversions in 2026

It's Monday morning. You open Google Analytics, scroll through visits and bounce rate, and everything looks fine. Traffic's steady. Nothing's on fire. You close the tab and get on with your day. Three weeks later, your rankings have quietly slipped, your quote form submissions are down, and you have no idea why. The numbers you were watching show what happened. They never show why.
A different set of numbers shows the why, and in 2026 they matter more than ever most NZ businesses have never looked at them.

Here's how that plays out in practice. Imagine a Hawke's Bay-based building supplies wholesaler calling them a typical mid-market NZ site. Their product pages were loading in 4.8 seconds on mobile, LCP included, and their INP sat around 340ms because of a stacked-up chat widget and two analytics scripts. Nothing was broken, the site worked, orders came through, nobody filed a complaint. But over two quarters, their ranking for their highest-value commercial search terms slid from position 4 to position 11, and their organic quote requests dropped by roughly a third. Nobody connected the dots to page speed until an SEO audit did.

That's the pattern behind almost every unexplained ranking drop in 2026: not a penalty, not a content problem, but a set of website performance metrics quietly drifting into “Poor” territory while everything on the surface looks normal.

Why 2026 Changed the Rules: The Evolution of Google's Performance Signals

In March 2026, Google rolled out a core algorithm update that gave performance signals real weight in how pages rank. At the same time, the thresholds for Core Web Vitals Google's own performance benchmarks got tighter. The combined effect: sites that were coasting on “good enough” performance are now visibly losing ground.

This isn't just a ranking story, either. The link between site speed and conversion is no longer a theory it's measurable, and it's blunt. A one-second delay in load time costs roughly 7% of conversions, according to a Deloitte study of 37 major retail sites. Portent's analysis of over 100 million page views found e-commerce pages loading in one second convert up to 2.5x higher than pages taking five. And 53% of mobile visitors abandon a site outright if it hasn't loaded within three seconds, per Google's own research.

Those aren't edge cases in a report somewhere. That's a customer on their phone, on your site, right now, deciding whether to stay.

We've written before about why page speed matters for SEO rankings. The short version is that Google now treats speed as a proxy for quality, and so do your visitors.

So here's the story worth knowing five metrics, told in the order a visitor actually experiences them, from the moment your page starts loading to the moment they either convert or leave.

The First Impression: Largest Contentful Paint (LCP)

A visitor lands on your page. LCP measures how long it takes for the biggest, most important thing on that page, usually your hero image or headline to actually appear. It's the moment the page starts to feel real to them.

The 2026 bar: under 2.0 seconds tightened from 2.5 seconds in 2024.

When LCP is slow, people don't wait around to find out if the rest of the page is worth it. They hit back and click the next result. Google notices that pattern happening across many visitors, and your ranking for that search term slides.

What's usually behind it

• A hero image that's too large or isn't preloaded

• Slow server response (technically, TTFB above 600ms more on that below)

• CSS and JavaScript that block the page from painting

• Fonts that load late, so text appears after everything else

How it gets fixed

• Preload the hero image and mark it as high priority

• Serve images as AVIF or WebP 30–50% smaller than JPEG at the same quality

• Move to hosting with faster response times, ideally on an Australian edge node

• Strip render-blocking scripts out of the critical path

Track it in Google Search Console's Core Web Vitals report for real visitor data, and PageSpeed Insights for both lab and field scores they often disagree with, and it's worth checking both.

For the full playbook on getting LCP under that 2-second mark, see our guide on how to build a website that loads in under 2 seconds.

Quick check: Run your homepage through PageSpeed Insights now 30 seconds, free, and it'll show you your actual LCP score.

The Moment They Click: Interaction to Next Paint (INP)

The page has been loaded. Now your visitor taps a button, a link, a form field and INP measures how quickly the page visibly responds. This is the metric quietly failing on most NZ websites right now.

The 2026 bar: under 200 milliseconds.

Google made INP a core ranking signal back in 2024, and the March 2026 update gave it even more weight. The usual culprit is JavaScript chat widgets, analytics scripts, A/B testing tools, tracking pixels all fighting for the same processing time. When someone clicks, the browser has to finish whatever it's already doing before it can respond to them.

A 300ms lag doesn't sound like much on paper. But it's the difference between a site that feels sharp and one that feels broken and visitors notice, even if they can't name what's wrong.

What's usually behind it

• Too many third-party scripts competing on the main thread

• Long JavaScript tasks that block input

• Heavy WordPress plugins running scripts on every page load

• Bloated pages with 5,000+ HTML elements

How it gets fixed

• Audit every third-party script does it earn its place?

• Break long tasks into smaller chunks the browser can schedule around

• Load heavy widgets (like chat) only once the user actually interacts with them

• Simplify page structure to cut down DOM size

Track it via Search Console's Core Web Vitals report, or in Chrome DevTools' Performance tab, where tasks over 50ms show up flagged in red.

The Moment It Moves: Cumulative Layout Shift (CLS)

This is the one people feel before they can explain it. A visitor goes to tap “Book Now,” and right at that moment the page shifts and a banner loads in and they tap the wrong thing entirely. CLS measures exactly how much a page unexpectedly moves while it loads.

The 2026 bar: under 0.1.

Above that, Google treats the page as visually unstable and so does the person trying to use it, even if they never file a complaint. They just leave, mildly annoyed, and don't come back.

What's usually behind it

• Images or embeds with no reserved width and height

• Ads or banners injected above content that's already loaded

• Web fonts that swap in and shift character spacing

• Cookie banners or chat bubbles that push content down instead of overlaying it

How it gets fixed

• Always set explicit width and height on images

• Reserve space in the layout for ad slots before they load

• Prioritise stable text rendering over instant web-font display where the two conflict

• Make banners and popups overlay the page rather than push it down

Chrome DevTools' Rendering panel will show you exactly which elements are shifting, down to the pixel useful when you need to hand a specific fix to a developer.

The Foundation Nobody Sees: Time to First Byte (TTFB)

Before any of the above can happen, the browser has to hear back from your server at all. TTFB measures that first response, and while it isn't officially a Core Web Vital, it's the floor everything else is built on.

The target: under 400ms, ideally under 200ms.

If your server takes 800ms just to respond, you've already burned 40% of your LCP budget before a single pixel appears. TTFB is entirely a hosting and infrastructure question no amount of CSS tweaking fixes it. It comes down to where your server sits, how it's cached, and how well it's built.

What's usually behind it

• Shared hosting instead of managed cloud infrastructure

• A server located far from your NZ audience, adding 150–250ms in network latency

• No caching, so WordPress rebuilds every page from scratch on every visit

• Running an older PHP version

How it gets fixed

• Move to managed cloud hosting with an Australian or NZ edge node

• Turn on full-page and object caching at the server level

• Upgrade to a current PHP version

• Use a CDN to serve cached content from the location closest to each visitor

PageSpeed Insights breaks TTFB out in its Diagnostics section, and it's also visible directly in Chrome DevTools' Network tab against the first HTML request.

Most of the fixes above are hosting and configuration work, which is exactly what our website performance optimisation services handle end to end.

The Warning Sign: Total Blocking Time (TBT)

TBT is the lab test that predicts INP before real visitors ever hit your site. It adds up every stretch of time your page's main thread is too busy to respond every JavaScript task longer than 50ms counts against you.

The target: under 200ms, with under 150ms considered excellent.

A high TBT score is your early warning: it tells you exactly how much JavaScript is going to cause problems, before a single real user has clicked anything.

What's usually behind it

• Large, unoptimised JavaScript bundles

• Third-party scripts (chat, analytics, testing tools) executing heavily on load

• WordPress plugins running unnecessary scripts on every page load

• Code loaded upfront that could be deferred until it's needed

This is usually where a site's plugin stack catches up with it which is why custom WordPress website development built with a lean, intentional plugin count tends to sidestep this problem entirely, rather than needing it fixed after the fact.

How it gets fixed

• Code-split JavaScript so each page loads only what it needs

• Tree-shake dependencies to remove unused code

• Delay third-party scripts until after the user interacts with the page

• Drop polyfills for browsers older than two to three years

Lighthouse (via PageSpeed Insights) and WebPageTest both surface TBT, with WebPageTest breaking it down by your code versus third-party scripts handy for working out who to chase.

How This Story Ends: The Business Outcomes

Strip away the technical labels and this is really one story, told five times a visitor arrives, and something quietly gets in their way before they can do what they came to do:

• Slow LCP on mobile: visitors bounce before the page finishes loading, and Google ranks you lower for that search
• Failing INP: someone starts filling out a quote form, every tap lags, and they give up without you ever knowing
• CLS above 0.1: a visitor taps “Book Now,” the page shifts, they hit the wrong thing, and leave confused
• High TTFB: every other metric is already behind before the page has painted a single pixel
• High TBT: the page looks loaded but feels sluggish, and visitors quietly associate that with a site they don't trust

None of these show up as a support ticket. They show up as a slowly declining conversion rate and a ranking that drifts down over a few months which is exactly why they go unnoticed for so long.

Back to the Hawke's Bay wholesaler: once LCP dropped from 4.8 seconds to 1.7 seconds and INP came down under 200ms, their commercial search terms recovered from position 11 back to position 3 within ten weeks, and organic quote requests climbed past where they'd started. Nothing else about the business changed, no new content, no new backlinks. Just the key metrics for website performance getting fixed.

Website Performance Metrics Tools: What to Use, and For What

There's no shortage of website performance metrics tools out there, and most NZ businesses don't need more than three or four of them. Here's what each one is actually for:

One mix-up worth clearing up first: searching “website performance metrics Google Analytics” usually means someone's looking in the wrong tool. GA4 shows you the after-effects of poor performance bounce rate, drop-off, revenue by landing page but it doesn't measure LCP, INP, or CLS directly. For the metrics themselves, Search Console and PageSpeed Insights are the source; GA4 is where you see what those metrics cost you.

A quick note on uptime, since it's a different problem to slow performance: if your site goes down entirely, even briefly, Googlebot can fail to crawl it and repeated downtime does affect how much Google trusts and crawls your site over time. Cloudflare Analytics and most hosting dashboards include basic uptime monitoring for free; dedicated uptime tools add instant alerting if you need to know within minutes rather than finding out from a customer.

Run PageSpeed Insights on your homepage, your busiest service page, and your contact page once a month. Anything sitting in “Needs Improvement” or “Poor” is worth fixing before it costs you rankings.

If that monthly check isn't something you want to own yourself, our Core Web Vitals monitoring runs it for you as part of ongoing maintenance, flagging the moment any metric drifts out of the “Good” zone, before it shows up in your rankings.

Final Thoughts

Five metrics. All measurable. All fixable. All directly tied to your search rankings and your ability to turn visitors into customers.

If you haven't reviewed your Core Web Vitals recently, there's a good chance at least one of these metrics is quietly holding your website back. The good news is that performance issues aren't random; they have identifiable causes and practical solutions.

A technical SEO audit is one of the fastest ways to uncover which performance metrics need attention, understand how they're affecting your rankings and conversions, and prioritise the improvements that will have the greatest impact.