Does the page react when somebody touches it

What it measures

Every tap, click and keypress during a visit is timed from the moment of the interaction to the moment the screen visibly updates in response.

The reported figure reflects the worst of those interactions rather than the average, because one bad delay is what a visitor remembers.

It covers the whole visit, not just loading, so a page that becomes sluggish after a minute is caught.

The reported figure reflects the worst interaction rather than the average, because one bad delay is what a visitor remembers.

Why delays happen

A browser does one thing at a time on its main task. If a script is running when somebody taps, the tap waits until the script finishes.

Long uninterrupted pieces of work are the problem. A script doing something for a quarter of a second blocks every interaction during it.

Third party code is the usual source, because it arrives on its own schedule and does work you did not ask for at moments you did not choose.

Third-party code is the usual source, because it arrives on its own schedule and does work you did not ask for at moments you did not choose.

Where it shows up

Menus that take a moment to open. Accordions that pause before expanding. Form fields that lag behind typing. Buttons that appear not to have registered a press.

The visitor response to all of those is to press again, which on a form means duplicate submissions and on a link means a double navigation.

So the measurement is a decent proxy for a genuinely irritating category of fault.

• A menu that takes a moment to open
• An accordion that pauses before expanding
• A form field lagging behind typing
• A button that appears not to have registered a press
• A filter that takes a second to apply
• A page that becomes sluggish after a minute

What to do about it

Remove scripts you do not need, which is the fix for most small business sites and also improves everything else.

For code you do need, break long pieces of work into smaller ones so the browser can respond in between.

Give immediate visual feedback on interaction, even if the real work takes a moment. A button that acknowledges the press stops the second press.

Why static pages do well

A page that is mostly text and links has almost nothing running. There is nothing to block a tap, so responsiveness is effectively instant.

This is one of the strongest practical arguments for keeping a business site simple. The performance comes free rather than being engineered.

It also means the score stays good as the site grows, rather than degrading as features accumulate.

The performance comes free rather than being engineered, and it stays good as the site grows — see third party scripts.

Measuring it

It needs real interactions, so it only exists in field data from actual visitors. A lab test cannot produce it because nobody tapped anything.

Browser tools can simulate interactions and show you where the long pieces of work are, which is how you diagnose rather than measure.

On a small site with few visitors you may have no data at all, and a simple page is very unlikely to have a problem here.

It needs real interactions, so it only exists in field data. A lab test cannot produce it because nobody tapped anything.

How ours behave

Pages here carry a small amount of script and no third party code by default, so there is very little that can occupy the browser when somebody taps.

Controls are real buttons and links, which respond natively rather than waiting for script to notice them.

Every page passes a check that runs before anything publishes, validated against Google Search Essentials and modern web standards.

What counts as a good result, as published

• Interaction to Next Paint is rated good at 200 milliseconds or less web.dev, Core Web Vitals
• Interaction to Next Paint is rated poor above 500 milliseconds web.dev, Core Web Vitals

Figures are from the source named beside each one, as published there. None of them is a claim about this product.