By Greg Nowak. Updated 4 November 2026.
A mobile menu that ignores the first tap, a campaign page loaded with scripts, and a CMS that rebuilds the same content can arrive as three separate audit findings. For the business, they belong in the same conversation: where are customers waiting, and what unnecessary work does the website keep repeating?
That is why Interaction to Next Paint (INP), technical SEO and greener web delivery deserve a shared backlog. A business owner needs a spending decision; an operations lead needs clear ownership; an agency needs tickets it can estimate and deliver. Joining the evidence helps all three.
Share the backlog, keep the measures separate
INP describes responsiveness to clicks, taps and keyboard interactions throughout a page visit. The web.dev optimisation guide sets a good threshold at 200 milliseconds or less, assessed at the 75th percentile separately for mobile and desktop.
For this backlog, “green SEO” means improving search journeys while reducing avoidable resource use. It is not a separate Google ranking metric. Google confirms that Core Web Vitals inform its ranking systems, but good scores do not guarantee top rankings.
Keep three outcomes visible: customer responsiveness, delivery efficiency and search performance. A smaller image can reduce transfer without fixing a delayed menu. Removing unused JavaScript may help both. Neither a lower byte count nor a better INP score establishes a measured carbon reduction.
Start with the journey that matters
Choose a journey such as requesting a quote, filtering products or completing an account task. Record the affected page, device class and action. “Mobile navigation responds late during loading” gives a developer somewhere to start; “improve performance” leaves the investigation undefined.
The Chrome UX Report API provides aggregated field data at URL and origin level over a rolling 28-day window. Check which level you are viewing: an origin average can hide differences between templates. A missing URL report is a reason to gather more evidence, not a clean bill of health.
Where available, use real-user monitoring to identify the slow interaction, then reproduce it on a representative device and capture a browser performance trace. Collect technical context without recording form contents or unnecessary personal identifiers.
Separate the delay into waiting for an event handler to start, time spent running handlers, and waiting for the next frame. This distinction prevents a team from optimising downloads when the real problem is browser processing.
Use the evidence to choose the next fix
| Evidence | First investigation | Acceptance check |
|---|---|---|
| Tap waits before handlers run | Long browser tasks, startup scripts and third parties | Repeat the interaction during loading |
| Handlers or rendering take too long | Excessive updates, large layouts and forced layout | Compare interaction traces before and after |
| Visitors repeatedly download large assets | Media sizes, unused assets and cache behaviour | Compare transfer on first and repeat visits |
| CMS requests repeat expensive work | Duplicate queries and missed cache reuse | Compare query counts and cache behaviour |
Prioritise by customer impact, frequency, confidence in the diagnosis, delivery effort and risk. A recurring delay on an enquiry form may deserve attention before a larger transfer saving on an obscure page. Shared template problems deserve particular attention because one change can reach several journeys.
Give each finding one owner. If an agency controls the theme and another supplier controls the consent platform, identify who coordinates the investigation before either team starts changing code.
Write a ticket someone can actually deliver
Use a concrete brief: “On mobile, opening navigation during loading is delayed. Capture the trace, identify the blocking work, and move nonessential work out of the interaction path where appropriate.” Treat the suspected cause as a hypothesis until the trace confirms it.
Add the affected templates, baseline evidence, proposed scope, acceptance criteria and regression check. For navigation, acceptance should cover visible response, working links and keyboard access. Agree the performance target from the baseline and intended users rather than attaching an arbitrary score to every ticket.
Also record what could break. Deferring a script may affect consent handling or measurement. Changing caching may affect personalised content. Reviewing those dependencies is part of estimating the fix.
Follow repeated work back into the CMS
For Drupal and WordPress, compare cold and warm caches and distinguish anonymous from authenticated visits. Look for assets attached to every template, repeated queries and content rebuilt unnecessarily. Check that caching preserves permissions, personalisation and freshness.
The W3C Web Sustainability Guidelines, published as a Group Note Draft on 16 October 2026, recommend removing unused code, reusing retrieved data and setting measurable resource goals. They remain work in progress. Use them to guide improvements and describe what you measured, rather than claiming environmental savings from a performance score.
Drupal teams can use Gander performance tests to track database queries, cache operations and asset counts. With functional JavaScript tests and the documented Gander services configured, run this test group from the Drupal web directory inside the test environment:
../vendor/bin/phpunit -c core --group OpenTelemetryThis runs the configured OpenTelemetry test group; it does not audit an arbitrary live site. Add checks for the affected journey. Stable counts can make useful regression assertions, while timings need allowances for environmental variation. WordPress teams can apply the same principle with application profiling and suitable automated checks.
Close the ticket with evidence
Verify the change immediately with the same journey and comparable test conditions. Then review field data as new visits accumulate; CrUX's rolling window will initially mix visits from before and after release. Track responsiveness, transfer and server work separately so the next review can show which outcome improved.
If separate SEO, performance and sustainability reports are competing for budget, I can help you agree priorities, brief the delivery team and define acceptance checks. Talk to Greg about managing your digital backlog.
Related on GrN.dk
- Why Your Website’s Third-Party Stack Needs a Real Owner
- JavaScript-Heavy Service Pages Still Lose Leads: What to Audit in 2026
- AI Crawler Control for Business Websites: Protect Content Without Losing Search Visibility
Need help with this kind of work?
Talk to Greg about your digital backlog Get in touch with Greg.
