By Greg Nowak. Updated 3 September 2026.
A slow menu, an oversized campaign page and an uncached CMS query may appear in three different audits. For the customer, they are one problem: the website is doing too much work before responding.
That is why Interaction to Next Paint (INP), technical SEO and sustainable web work often belong in the same backlog. They are not interchangeable measures, and a lighter page is not automatically more responsive or environmentally efficient. But looking for unnecessary browser, network and server work can reveal changes that benefit all three.
Start with the user problem, not the score
INP measures responsiveness across qualifying interactions during a visit. Current web.dev guidance defines 200 milliseconds or less at the 75th percentile as good, assessed separately for mobile and desktop.
The headline number is a warning light, not a development brief. A measured interaction contains three parts:
- Input delay: the browser is busy before the event handler can start.
- Processing duration: the event callbacks themselves take too long.
- Presentation delay: updating and painting the next frame is slow.
“Improve INP” leaves a developer guessing. “Stop the analytics and personalization scripts from blocking the mobile navigation after page load” identifies an interaction, suspected cause and place to investigate.
Keep the SEO promise equally precise. Google recommends good Core Web Vitals and uses them in its ranking systems, but explicitly says that good scores do not guarantee high rankings. Relevance, content quality and the wider page experience still matter. Treat INP as evidence of customer friction, not as a shortcut to guaranteed traffic.
Use field data to decide where to investigate
The Chrome UX Report (CrUX) API supplies aggregated real-user data at origin and eligible URL level. Its results use a rolling 28-day collection period and can be segmented by device class. That makes CrUX useful for detecting a broad regression or identifying an affected page type.
CrUX normally cannot tell you that the product filter, consent dialog or checkout button caused the delay. For that, use privacy-conscious real-user monitoring that records the affected interaction and enough context to reproduce it. Collect only what the investigation needs; avoid capturing entered text, personal data or unnecessary identifiers.
Once a problematic journey is known, reproduce it on a representative device and connection. Use the browser performance trace to separate input, processing and presentation delay. Then compare that trace with transferred resources, third-party activity, cache behaviour and server timings.
| Evidence | Likely repeated work | Actionable backlog ticket | Regression check |
|---|---|---|---|
| Long input delay | Startup scripts, timers or third parties occupying the main thread | Remove unused code; defer non-essential scripts; load costly embeds on demand | Field INP trend plus a trace of the affected interaction |
| Long processing duration | Event handlers recalculating more data than the next frame needs | Simplify the handler, split long work and defer secondary updates | Journey-level interaction test |
| Long presentation delay | Large DOM updates, style recalculation or synchronous layout | Reduce the rendering scope and batch DOM changes | DOM and rendering budget for the component |
| Large repeat transfer | Oversized media, weak compression or ineffective cache lifetimes | Resize assets, version static files and correct cache headers | Byte, request and cache-policy budgets |
| Slow CMS delivery | Cache misses, repeated queries or expensive rendering paths | Trace the request, remove duplicate queries and improve page or fragment caching | Server timing, query and cache assertions |
Prioritise work the business can understand
A performance audit can generate dozens of technically valid recommendations. They should not all receive equal attention. For each candidate, assess:
- how frequently customers encounter the affected page or interaction;
- whether it blocks a valuable journey such as finding, enquiring, buying or publishing;
- how much browser, transfer or infrastructure work the change removes;
- the strength of the evidence and the delivery risk;
- whether the improvement can be protected with a reliable test or budget.
This makes trade-offs visible to owners and operations leads. It also gives an agency a defensible scope. A recurring delay in checkout deserves different treatment from a small saving on a rarely visited page, even if the second ticket is easier.
Follow the waste through the CMS and delivery stack
The August 2026 W3C Web Sustainability Guidelines remain a Draft Note, but their practical direction is useful: set measurable resource goals, remove unused code, defer non-critical resources, reduce repeated database queries, and use caching and compression where appropriate.
For Drupal or WordPress, that means looking beyond the front end. Inspect page and fragment caches, PHP execution, database calls, generated markup, asset aggregation and CDN behaviour. A CDN can reduce repeated delivery, but it cannot make an unnecessarily complex template efficient.
Drupal teams can use Gander, included in core since Drupal 10.2, to monitor TTFB, rendering metrics, database queries, cache operations and asset counts. Deterministic values such as query and cache-operation counts can become CI assertions. Timing metrics need more care because noisy thresholds can create unreliable failures. To run the documented OpenTelemetry test group in a configured project:
../vendor/bin/phpunit -c core --group OpenTelemetryGander does not replace field INP monitoring. Pair CMS-side checks with browser and real-user evidence. WordPress and other platforms can follow the same principle using their own tracing, application monitoring and automated test stack.
Make every ticket include its guardrail
A clean-up project has a short shelf life if the next campaign, plugin or redesign restores the cost. Give every accepted ticket a definition of done that covers both the change and its protection: an interaction test, a transfer budget, an approved third-party list, a cache expectation or a server-side assertion.
The shared question is simple: what work does every visit repeat, and how much of it creates real customer value? Answer it with field evidence and an end-to-end trace, and the backlog becomes smaller, clearer and easier to fund.
If several audits are competing for attention, Greg can help your team turn the evidence into one practical delivery backlog.
Related on GrN.dk
- Why Your Website’s Third-Party Stack Needs a Real Owner
- Google’s 2026 AI Search Guidance: SEO Still Matters, but Reporting Has Changed
- Optimizing Drupal: A Practical Performance Checklist
Need help with this kind of work?
Turn the evidence into a practical delivery backlog Get in touch with Greg.
