Your Website Loads Fast. It Still Feels Slow. Google Now Punishes That.

Your website loads fast. It still feels slow. Google has decided that is now a ranking problem.

I get a version of this conversation roughly every fortnight. A business owner pulls up PageSpeed Insights on their phone, points at a green score in the high eighties, and asks why their Google rankings have started slipping. The answer is short. Loading fast is not the same as responding fast. And in 2026, Google measures both.

What Google Actually Changed

For most of the last decade, page speed meant one thing: how quickly the visible content showed up. Google's Largest Contentful Paint metric (LCP) measures exactly that, and a 2.5 second threshold gets you marked as "good". Most managed WordPress sites pass it. That part of the conversation is largely settled.

What changed is the metric Google added in March 2024 and started weighting more aggressively in the March 2026 core update. It is called Interaction to Next Paint, or INP, and it replaced an older metric called First Input Delay. INP measures something LCP never did: how quickly your site responds when a customer actually tries to use it. Tap a menu. Click a product. Submit a contact form. INP measures the gap between that interaction and the screen visibly responding.

Google's own web.dev documentation pegs the "good" threshold at 200 milliseconds or less. Slower than that and you are in "needs improvement" territory. Above 500ms is "poor". According to data Google publishes from the Chrome User Experience Report, the dataset Google itself uses for ranking, somewhere around a third of mobile sites pass all three Core Web Vitals at once, though that proportion shifts meaningfully by sector and device class. INP is the metric that fails most often.

That is the bit most small business owners have not registered yet.

Loading Fast Is Not the Same as Feeling Fast

Picture a customer on the school run, pulling out their phone to find a plumber. Your site loads in two seconds. Looks great. They tap the call button. The screen freezes for the better part of a second while a third-party analytics script finishes its work. They tap again. Nothing happens. They give up and ring the next listing.

That is INP. The page is technically there. The page does not respond. The customer leaves.

Loading speed is the front door. INP is whether the lights work once you are inside. Google has Think with Google research going back years showing that mobile bounce rates jump roughly 123 percent when load times go from one second to ten. The same logic applies to interaction delays. A frozen interface tells the customer your business is broken, and they treat it accordingly. They do not file a bug report. They ring the next listing.

Why Most Small Business Sites Are Failing This

Here is the uncomfortable bit.

Loading speed is mostly a hosting and content problem: small images, fast servers, decent caching. Most managed WordPress hosts can deliver an LCP score under 2.5 seconds without breaking a sweat. INP is different. It punishes script bloat, and almost every cheap WordPress install I have audited in the last two years is buried in it.

The page builder that ships with twelve embedded JavaScript libraries. The third-party live chat that loads its full SDK on every page. The marketing pixels nobody removed when the campaign ended three years ago. The popup plugin that fires on every interaction. The cookie banner that re-runs its entire consent flow every time someone touches the screen.

Each of these scripts ties up the browser's main thread. While the main thread is busy, the customer's tap is just a tap into a frozen screen. Multiply by ten or fifteen scripts, none of them individually catastrophic, and you have a site that scores green for loading and red for usability. That is the trap most cheap shared-hosting WordPress sites are sitting in right now, and the picture I have seen across the broader Irish failure rates on Core Web Vitals is consistent with that.

I will admit my own miscalculation here. I told a Galway retailer two years ago that their site was "fast enough" because their PageSpeed score sat at 89. When INP became a Core Web Vital, their field data dropped them straight into "needs improvement" because of three scripts I had never properly looked at. The scripts had been there the whole time. I had not been looking for them. I would not make that call again.

Where Hosting Actually Matters

Some of this is a WordPress configuration problem. But infrastructure carries more of the load than people realise.

INP times depend on how quickly your server responds to follow-up requests, on whether the browser can fetch additional resources without waiting on a slow database query, and on whether your hosting stack actually serves cached responses or rebuilds the page on every visit. A properly configured managed WordPress stack with the right caching layers takes serious pressure off the front-end. Object caching with Redis means logged-in interactions and dynamic queries do not hammer the database on every click. FastCGI page caching means most responses come from memory, not from PHP rebuilding the page from scratch. None of this is glamorous. It is the difference between a customer feeling like the site is broken and a customer completing a booking.

That is also where the value of proper managed WordPress infrastructure shows up. The Web60 stack runs Nginx, Redis object cache, and FastCGI page cache out of the box for €60/year, but the principle applies regardless of who hosts you: if your server is slow to respond, no amount of front-end tweaking will save your INP score. The wider point is that WordPress performance is more than a single setting. It is the stack as a whole, configured properly.

Where This Genuinely Does Not Matter

There is one honest scenario where INP is mostly irrelevant.

If you are running a static brochure site with no interactive elements (no shop, no booking, no live chat, no quote calculator) then INP is largely a non-issue. Google still measures it, but if customers do not interact in any meaningful way, the metric defaults to good for lack of data to be poor on. A solicitor's office with a phone number, an address, and a one-page biography may genuinely never need to think about this metric in particular.

For everyone else, and that is most local firms with a website that actually does work, the gap between "loads fast" and "feels fast" is now a measurable ranking factor. Google's developer documentation confirms INP as a page experience signal in mobile search.

What To Do About It

Three things, in order.

First, audit your scripts. Open PageSpeed Insights, run your homepage, and look at the JavaScript execution time. Anything over 1.5 seconds of main-thread work is a problem worth fixing. Most of it will be plugins or third-party tags you forgot you installed.

Second, verify on real data, not lab estimates. PageSpeed Insights gives you a synthetic lab score. The Core Web Vitals report inside Google Search Console gives you real-world field data from actual Chrome users. The Search Console number is the one Google uses for ranking. Check it.

Third, fix the stack underneath. Page caching, object caching, opcode caching. If your hosting provider does not configure these for you, you are paying for shared hosting and being told it is managed.

A sync reality check is in order. INP measures interaction, but Core Web Vitals are not the only ranking factor Google uses. A site scoring 100 on every metric still loses to a site with better content, more authoritative links, and clearer search intent. Pass the threshold. Do not obsess past it.

Conclusion

What changed is not what "fast" means. What changed is what Google measures. Loading speed is still a real ranking factor. Responsiveness sits next to it now. Both are measurable. Both decide who wins the search result.

The shop that responds when a customer walks in has always done better than the shop where nobody is at the till. Google now ranks the digital version of that distinction. The first useful step is opening Search Console and looking at the field data report. Most business owners have never checked it. Half an hour with that report tells you more about your site than most agency pitches will.

Sources

Defining Core Web Vitals thresholds (web.dev)

Understanding Core Web Vitals and Google search results (Google Search Central)

New Industry Benchmarks for Mobile Page Speed (Think with Google)

Chrome User Experience Report release notes (Chrome for Developers)

Frequently Asked Questions

What is INP and how is it different from page speed?

INP (Interaction to Next Paint) measures how quickly your site responds when someone interacts with it: taps, clicks, types. Page speed traditionally meant how quickly the page first loaded. INP became a Core Web Vital in March 2024 and now sits next to LCP and CLS as a ranking signal Google uses for mobile search.

Does INP affect Google rankings?

Yes. INP is one of three Core Web Vitals that Google's documentation confirms as page experience ranking signals. Sites that fail the 200 millisecond threshold can lose ranking position to sites that pass it, particularly on mobile.

How do I check my INP score?

The most accurate measurement is the Core Web Vitals report inside Google Search Console, which shows real-world data from actual Chrome users. PageSpeed Insights also reports INP, but with synthetic lab estimates that can differ meaningfully from field data.

Why is my INP score bad even though my page loads fast?

INP measures responsiveness, not loading. Sites with heavy JavaScript such as page builders, third-party trackers, marketing pixels and popup plugins can load fast but freeze the browser when a user interacts. Reducing third-party scripts and main-thread work usually fixes it.

Can I fix INP without rebuilding my site?

Often yes. Audit your plugins and third-party scripts, remove anything you do not actively use, and switch to a hosting stack with proper caching layers. If your site is built on a heavy page builder with poor performance, sometimes the right call is rebuilding on a leaner stack.