INP and Green SEO Share a Backlog: Cut the Work Every Visit Repeats
By Greg Nowak. Last updated 2026-08-03.
Slow interactions and inefficient pages often have the same root cause: the site is making the browser, network or server do more work than the experience needs. Run separate INP and green SEO audits, and you can easily end up with two reports competing for space in the same development queue.
It is more useful to build one backlog around unnecessary, repeated work. Page weight and Interaction to Next Paint are not interchangeable measures, but many changes can improve responsiveness while reducing data transfer and infrastructure demand.
Find the work hiding behind the INP score
INP measures responsiveness across qualifying interactions during a visit. The web.dev guidance defines a good result as 200 milliseconds or less at the 75th percentile, assessed separately for mobile and desktop.
The headline score tells you whether there is a problem. The useful detail comes from splitting each measured interaction into input delay, processing duration and presentation delay.
Input delay is the wait before an event handler can begin, often because scripts, timers or other tasks are occupying the main thread. Processing duration covers the work performed by the event callbacks. Presentation delay is the time between those callbacks finishing and the browser painting the next frame.
Each points to a different kind of ticket. Long input delay may require less JavaScript at startup or fewer competing tasks. Heavy processing may call for smaller callbacks, deferred secondary work or more frequent yielding to the main thread. Presentation delay can lead the investigation towards DOM updates, style calculation and layout.
That distinction matters in a working backlog. “Improve INP” gives a developer very little to act on. “Remove the main-thread task blocking the mobile menu interaction” is specific enough to investigate, estimate and test.
Use page weight as a clue, not a verdict
The 2025 Web Almanac reports that the median home page reached approximately 2.9 MB on desktop and 2.6 MB on mobile, continuing the year-over-year increase. Its field-data analysis also found lower Core Web Vitals pass rates as page weight rose. For home pages below 1 MB, 70% passed on desktop and 57% on mobile. At 5 MB or more, those figures fell to 38% and 30%.
That is correlation, not proof that every extra byte damages INP. A well-optimized image can increase transfer weight without blocking an interaction. A much smaller JavaScript bundle can still tie up the main thread with expensive work.
Page weight remains a useful prompt, though. What is the site transferring, parsing, executing, rendering or downloading again without delivering enough value to justify the cost?
| What the team sees | Repeated work to check | A useful ticket might be | How to keep it fixed |
|---|---|---|---|
| Long input delay | Startup scripts, timers or third-party code holding the main thread | Remove unused JavaScript, delay non-essential code or load embeds on demand | Track the INP trend and trace important interactions |
| Long processing duration | Event callbacks doing work that the next frame does not need | Shrink callbacks, split long tasks and defer secondary updates | Profile interactions in a representative user journey |
| Long presentation delay | Large DOM changes, style recalculation or layout work | Reduce the rendering scope and avoid layout thrashing | Set DOM and rendering-work budgets for key templates |
| High transferred bytes | Oversized media, weak compression or short cache lifetimes | Resize and compress assets, improve caching and stop repeat downloads | Set budgets for bytes, requests and cache lifetimes |
| Slow CMS response | Repeated PHP, database or cache work before delivery | Trace expensive paths, improve caching and simplify repeated queries | Monitor server timings and run automated performance tests |
Let field data decide where profiling begins
Lab tests are valuable, but an occasional test cannot show how the full audience experiences every template and device class. The Chrome UX Report API provides aggregated real-user data at URL and origin level. That makes it useful for routine monitoring: origin data can reveal a broad shift, while eligible URL-level data can help narrow the problem to a particular page type.
CrUX will not usually tell you which button, filter or form caused a slow interaction. For that level of detail, the web.dev guidance recommends contextual real-user monitoring, followed by lab reproduction and browser profiling. Consistent with the W3C sustainability guidance, that instrumentation should collect only the information needed for a defined purpose and respect applicable privacy and data-protection requirements.
A sensible investigation has four stages:
- Monitor field performance by device class and, where data is available, by origin or important URL.
- Identify the templates and user journeys linked to a regression or persistently weak result.
- Reproduce representative interactions in the browser, separating input, processing and presentation delay.
- Compare the trace with transfer, third-party, server, cache and CMS evidence before writing implementation tickets.
This order avoids reaching for generic script or compression fixes before anyone has established what is delaying the user. It also helps separate a platform-wide problem from one expensive component that appears on a single template.
Follow the work beyond the browser
The delivery path belongs in the same backlog as the main thread. The W3C’s May 2026 sustainability draft addresses efficient code, appropriate media, caching, compression, infrastructure monitoring, performance testing and measurable budgets. It also notes that reducing system-resource requirements can lower energy and hardware use while saving money.
On a Drupal or WordPress site, browser findings can be matched with server timings, cache analysis and CMS tracing. Front-end execution may be the problem, but a slow page can also expose uncached rendering, repeated database work or an unnecessarily expensive application path.
Edge caching and compression can reduce repeated delivery work. They should not become a way to hide heavy templates or inefficient code.
The aim is not to apply every optimization that an audit can find. The stronger candidates have credible evidence across several business and technical considerations: how often the problem occurs, how badly it affects users, how much transfer or infrastructure work could be removed, and what the change costs or risks. Those are tickets a product team can prioritise, rather than a catalogue of technical ideals.
Keep the backlog from growing back
A clean-up project has a short shelf life if the next release can restore the same costs. The W3C draft recommends baselines, performance and environmental budgets, release-cycle testing and measurable evidence of improvement. Depending on the site, controls might cover JavaScript and image weight, request counts, cache expectations, interaction thresholds and important server-side metrics.
Drupal teams also have a platform-specific option. Gander has been included in Drupal core since version 10.2 and adds performance measurements to functional testing. It can compare metrics over time, assess a change against a baseline and fail a test when a selected threshold is exceeded. Documented metrics include TTFB, rendering milestones, database-query counts and cache requests.
A WordPress stack or another CMS may use different tools, but the operating principle is the same: make the expected improvement testable. A budget needs to be precise enough to affect a release decision, have a clear owner and be reviewed when product requirements genuinely change.
For Greg, the useful role is to connect the evidence across CrUX or privacy-conscious real-user monitoring, browser profiles, server timings, cache behaviour and CMS traces. That produces a focused backlog: remove unused JavaScript, defer a costly embed, optimize media, improve PHP or database paths, adjust edge caching and compression, then add the checks that stop the waste returning.
INP and green SEO meet in one practical question: what work does each visit repeat, and how much of it is actually necessary? Answering that question can make the site respond faster, transfer less unnecessary data and accumulate performance debt more slowly.
Related on GrN.dk
- Not Every AI Job Needs an Instant Answer: Batch the Backlog
- AI agents need a browser policy before they start clicking around
- If the Facts Need JavaScript, AI Search May Miss the Full Page
Need help with this kind of work?
Turn performance evidence into a focused backlog Get in touch with Greg.