Your services page is slower than your homepage

In 2025, home pages reached good mobile Interaction to Next Paint 80% of the time. Secondary pages managed 69%. That reversed the prior year's pattern, and it matters because almost nobody submits an enquiry from a homepage.

Your homepage is the page everyone tests, everyone reviews, and everyone optimises. Your service pages are where the money is, and they are eleven percentage points worse.

Why the gap exists

Four reasons, and they compound.

Secondary pages carry the interactive furniture. Filters, accordions, tabbed specification panels, image galleries, calculators, comparison tables, enquiry forms. Every one of those is JavaScript that runs on click, and every one is a candidate for the slowest interaction on the page.

Secondary pages inherit the homepage's script payload and add to it. Whatever global bundle loads everywhere still loads here, plus whatever this template needs. Nobody ships a lighter build for the deeper pages.

Secondary pages carry the third parties nobody wanted on the homepage. Chat widgets get added to service pages because that is where enquiries happen. Session recording gets pointed at high-intent pages. Both are main-thread work landing exactly where interaction matters most.

And secondary pages get no attention. The homepage gets reviewed by executives, tested before launch and audited quarterly. A service page written eighteen months ago and last touched by a content editor does not.

The reporting problem underneath it

Google's field dataset reports at origin level and at URL level. Most dashboards, and most people glancing at Search Console, look at the origin.

Origin-level data is an aggregate weighted by traffic. Your homepage usually carries the largest share of visits, so a fast homepage pulls the origin number up and hides the pages behind it. You can pass at origin level while your three highest-value service pages fail individually.

Google uses page-level data when there is enough of it, and falls back to origin-level when there is not. So the pages you cannot see in your own reporting may well be graded on their own numbers.

Pull URL-level data for your top ten landing pages by conversion, not by sessions. That list is different from your traffic list, and it is the list that matters.

Where to look on each page

Work through this in order, because the first item finds the problem most of the time.

INP attribution in your field data. It names the element. If your slowest interaction on a service page is a filter toggle or an accordion header, you have the answer in thirty seconds.

Accordions and tabs. These are the quiet offenders. A poorly built accordion re-renders a large block, forces a layout recalculation and animates height, all inside the click handler. The fix is to render the content up front, hide it with CSS, and animate transform rather than height.

The chat widget. Check whether it is loading on page load or on interaction. Loading on demand, triggered by a click or a scroll depth, removes it from the critical path entirely and costs almost nothing in conversations started.

Form field handlers. Validation that runs on every keystroke against a large regular expression, or an address autocomplete firing a request per character, will produce a bad interaction on the exact element where the enquiry happens.

Long tasks during load. If someone clicks while a 400ms script is executing, their interaction queues behind it. Break long tasks up with the scheduler yield method, which is now supported in Chrome and Firefox, or at minimum yield to the main thread between chunks of work.

The template argument to have internally

The right unit of performance work is the template, not the page.

A site with a homepage template, a service template, a case study template and a contact template has four things to fix, and fixing the service template fixes forty pages. Teams that work page by page never finish, because content keeps producing new pages against an unfixed template.

So pick your two highest-value templates, fix them properly, and set a rule that any new interactive component added to those templates has its interaction latency measured before it ships. That rule is cheap to enforce and it stops the slow drift that produced this gap in the first place.

What the numbers are worth

Interaction latency is not a ranking abstraction. A filter that takes 350ms to respond feels broken, and people press it again, which queues another interaction and makes it worse. On a specification-heavy service page, that is the moment someone decides your business is not as sharp as your homepage suggested.

Test the pages people buy from, not the page people land on.