Coder Legion - Recent posts tagged inp

INP, the Core Web Vital That Replaced FID: How to Fix It

Sun, 18 Oct 2026 07:09:33 +0000

Interaction to Next Paint tracks how fast a page shows a visible reaction to a click, tap or key press. It took over from First Input Delay as a Core Web Vital on March 12, 2024. Good is 200 milliseconds or less and poor is over 500, measured at the 75th percentile of real visits. Many sites that passed FID easily fail INP because it covers every interaction in a visit and includes running your code and painting the result.

In the guide I explain what counts as an interaction (clicks, taps and key presses, not scrolling or hovering) and the three phases of each one: input delay, processing duration and presentation delay. Knowing which phase is slow tells you which fix applies.

Measurement starts with field data from CrUX, PageSpeed Insights and Search Console, then moves to DevTools with CPU throttling to reproduce problems. The web-vitals library's attribution build tells you which element was slow for real visitors and how long each phase took.

The fixes come in three groups: break up long tasks and yield to the main thread (with scheduler.yield() where supported); cut rendering work by avoiding layout thrashing, keeping the DOM small and using content-visibility; and tame input handlers with debouncing while deferring or removing third-party scripts. I'm clear about limits too: INP isn't a ranking shortcut, field data moves slowly, and a fast spinner doesn't fix slow work.

Key takeaways

Good INP is 200 ms or less at the 75th percentile
Each interaction has input, processing and presentation phases
Use field data first; Lighthouse doesn't measure INP
Break up long tasks and yield to the main thread
Debounce heavy handlers and audit third-party scripts

Related on BuiltToWinWeb: Core Web Vitals explained

Read the full guide on BuiltToWinWeb: The full INP explainer and fixes

A summary by Jacob Campbell of an article first published on built2winweb.com on October 6, 2026.

Interaction to Next Paint Breakdown: Solving first move lag in BareBoard

Fri, 11 Sep 2026 20:33:16 +0000

Interaction to Next Paint Breakdown: Solving first move lag in BareBoard

Background

So I was developing this dumb chess board which only contains presentation logic, emits event when a piece is touched and moved and doesn't have any move calculation/validation logic whatsoever. The idea was to ship it as a web component for the community and use it as the chess board for the project I was developing (known as 8bye8). I noticed that my piece stayed mid air for around half-a-second after I dropped the piece on target square which appeared to me as rendering delay. The solution of the problem led me to the Performance Tab in Chrome Dev Tools to investigate INP Breakdown.

What is INP ?

From web.dev -

When a user interacts with the page, those interactions should be as fast as possible. The amount of time it takes for an interaction to complete—ending when the browser presents the next frame to show the results of the interaction—is known as interaction latency. This is an aspect of page performance that the Interaction to Next Paint metric measures.

The amount of time it takes for the browser to present the next frame in response to a user interaction is known as the interaction's presentation delay. The goal of an interaction is to provide visual feedback in order to signal to the user that something has occurred, and visual updates can involve some amount of layout work in order to achieve that goal.

To understand INP, we'll first need to understand what an interaction is. Simply, for the purposes of INP, only the following interaction types are observed:

Clicking with a mouse.
Tapping on a device with a touchscreen.
Pressing a key on either a physical or onscreen keyboard.

INP consists of three subparts -

Input Delay: The time before any callback for an interaction is handled.
Processing Duration: The time for all the callbacks to execute.
Presentation Delay: The time after the callbacks have been executed until the frame is presented on the user's screen.

The Issue

As you can see in the gif, that I dropped the piece at around 1500ms but it stays in the air until about 1800ms. This resulted in a janky looking interaction when I made the first move.

Starting the Analysis

Step 1: Go to Performance Tab in Chrome

Step 2: In Environment settings, apply CPU throttling to 4x/6x slowdown to ensure consistent reproduction

Step 3: Record (Ctrl+E)

Step 4: Play the Move

Step 5: Stop Recording

With throttling enabled, we are able to get even bigger INP (352ms). For the rest of the article, this will be our basis of investigation.

Interpreting the analysis

Hovering over Interactions shows us that -

the delay is due to Presentation delay.

Clicking on Main shows us the main culprit -

We are using AudioContext to generate a "thud" sound when a piece is dropped. Since I didn't want to increase the size of my bareboard unnecessarily, I thought it would be best to just generate it using Web Audio API. You can read more about it on MDN

Let's look at the code where it happens -

function playMoveSound() {
  if (!props.enableSound) return

  // If the user provided a custom URL, play that
  if (props.moveSoundUrl) {
    const audio = new Audio(props.moveSoundUrl)
    audio.play().catch((err) => console.warn('Audio blocked:', err))
    return
  }

  try {
    const AudioContext = window.AudioContext || (window as any).webkitAudioContext;
    const ctx = new AudioContext();
    const osc = ctx.createOscillator();
    const gainNode = ctx.createGain();

    osc.type = 'sine'; // Deep smooth tone
    osc.frequency.setValueAtTime(150, ctx.currentTime); // Start low
    osc.frequency.exponentialRampToValueAtTime(40, ctx.currentTime + 0.05); // Drop fast for a "thud"

    gainNode.gain.setValueAtTime(1, ctx.currentTime); // Start loud
    gainNode.gain.exponentialRampToValueAtTime(0.001, ctx.currentTime + 0.1); // Fade out instantly

    osc.connect(gainNode);
    gainNode.connect(ctx.destination);

    osc.start();
    osc.stop(ctx.currentTime + 0.1);
  } catch (e) {
    // Silent fail if browser blocks AudioContext
  }
}

On a closer look, we find that this line -

const ctx = new AudioContext();

is causing the issue. If we could somehow not do this operation when dropping the piece for the first time, it should resolve the problem.

The Fix

On first instinct, it appears that we can just shift the initialization to when the user touches the piece instead of when he drops it, but that would be like playing Whack-a-Mole with the INP delay.

A second thought would be that we can do it when the user clicks anywhere on the board, but usually the first click a user makes is on the piece itself, so that wouldn't work as well.

Turns out, the proper solution is to do initialization when the component loads not on first user interaction -

let sharedAudioCtx: AudioContext | null = null;

onMounted(() => {
  if (!props.enableSound || props.moveSoundUrl) return;

  try {
    const AudioContext = window.AudioContext || (window as any).webkitAudioContext;
    sharedAudioCtx = new AudioContext();
    // State is naturally 'suspended' here due to browser policies
  } catch (e) {
    console.warn("Web Audio API not supported", e);
  }
})

function wakeUpAudio() {
  if (sharedAudioCtx && sharedAudioCtx.state === 'suspended') {
    sharedAudioCtx.resume().catch(() => {});
  }
}

There's one issue though, when we were calling new AudioContext() upon user interaction, the browser didn't put it in a suspended state. You can only play sounds using AudioContext upon user interaction (to prevent website from playing annoying sounds to uninterested users).

This fix initializes the audioContext without user interaction hence the browser would put it in a suspended state. This is in accordance with the spec.

Due to this, we need to call resume on the audioContext instance upon user interaction, thankfully that's an instantaneous operation.

function wakeUpAudio() {
  if (sharedAudioCtx && sharedAudioCtx.state === 'suspended') {
    sharedAudioCtx.resume().catch(() => {});
  }
}

<template>
  <div
      class="bareboard-wrapper"
      @pointerdown.capture.once="wakeUpAudio"
  >
...

This ensures that the context is in running state as soon as the user clicks anywhere on the board (whether it is on the piece or not).

Now we only re-use the existing warm instance to play the sound -

function playMoveSound() {
  if (!props.enableSound) return

  if (props.moveSoundUrl) {
    const audio = new Audio(props.moveSoundUrl)
    audio.play().catch((err) => console.warn('Audio blocked:', err))
    return
  }

  try {
    if (!sharedAudioCtx) return;

    const osc = sharedAudioCtx.createOscillator();
    const gainNode = sharedAudioCtx.createGain();
...

Let's check how we are doing now -

The INP is down to 102 ms !! This is well within the limits (200ms) and the onDragEnd function is down to 50ms from around 250ms.

Bonus

You might have notice js-to-wasm::i and generator.wasm in the screenshots. Since the board doesn't contain any calculation or move logic, we provide the valid sqaures on touch of a piece to the Bareboard from our consumer. The consumer in this case is a simple index.html file which imports generator.wasm file which is created by compiling d4d5 (another piece of the puzzle of 8bye8 suite that's written in Go for headless move verification) to wasm. d4d5 is going to run on the server to check if the move played by user is valid. We are compiling the same code to wasm to generate valid moves and to highlight the squares. The valid squares are passed to the BareBoard so that it can highlight the squares and allow a valid move to be played

Let's look at what happens when we touch a piece and drop a piece -

function startDrag(event: MouseEvent, piece: string, rankIndex: number, fileIndex: number) {
  event.preventDefault()

  const isWhitePiece = piece === piece.toUpperCase()
  const isWhiteTurn = activeColor.value === 'w'

  if (isWhitePiece !== isWhiteTurn) {
    return
  }

  activeDrag.value = {
    piece,
    fromRank: rankIndex,
    fromFile: fileIndex,
    x: event.clientX,
    y: event.clientY,
  }

  const fromRank = activeDrag.value.fromRank
  const fromFile = activeDrag.value.fromFile

  emit('pieceTouched', {
    fileIndex: fromFile,
    rankIndex: fromRank,
  })

  window.addEventListener('mousemove', onDragMove)
  window.addEventListener('mouseup', onDragEnd)
}

function onDragEnd(event: MouseEvent) {
  if (!activeDrag.value) return

  window.removeEventListener('mousemove', onDragMove)
  window.removeEventListener('mouseup', onDragEnd)

  const fromRank = activeDrag.value.fromRank
  const fromFile = activeDrag.value.fromFile
  const piece = activeDrag.value.piece
  const path = event.composedPath() as HTMLElement[]
  const squareEl = path.find((el) => el.classList && el.classList.contains('grid__rank__square'))

  activeDrag.value = null

  if (squareEl) {
    const toRank = Number(squareEl.getAttribute('data-rank'))
    const toFile = Number(squareEl.getAttribute('data-file'))
    const sourcePiece = grid.value[fromRank][fromFile]

    if (toRank !== fromRank || toFile !== fromFile) {
      if (isValidMove(toFile, toRank)) {
        if ((sourcePiece === 'P' && toRank === 0) || (sourcePiece === 'p' && toRank === 7)) {
          promotionRank.value = toRank
          promotionFile.value = toFile
          promotionSourceRank.value = fromRank
          promotionSourceFile.value = fromFile
          validMovesSet.value = new Set()
          return
        }

        let movePlayed: Move = {
          sourceSquare: { fileIndex: fromFile, rankIndex: fromRank },
          targetSquare: { fileIndex: toFile, rankIndex: toRank },
        }

        grid.value[fromRank][fromFile] = null
        grid.value[toRank][toFile] = piece

        emit('movePlayed', movePlayed)
        playMoveSound()
      } else {
        grid.value[fromRank][fromFile] = piece
      }
    }
  } else {
    grid.value[fromRank][fromFile] = piece
  }
}

Turns out that in both of these functions, we are emitting an event i.e. pieceTouched and movePlayed. The listeners attached to it are called synchronously. (Wait, What ? Aren't they scheduled onto callback queue ? What about the event loop and asynchronous nature of callbacks ?) Well here's the truth -

An emit (like in Vue, React, or Node's EventEmitter) does not interact with the Event Loop or the Callback Queue at all. It is just a regular, synchronous JavaScript function call in disguise.

When you use a custom event system like Vue's emit('myEvent') or Node's emitter.emit(), you are using the Observer Pattern.

Under the hood, an event emitter is literally just a JavaScript object with an array of functions attached to a string key.

// This is roughly what an EventEmitter looks like under the hood
const fakeEmitter = {
  events: {},
  
  on(eventName, callback) {
    if (!this.events[eventName]) this.events[eventName] = [];
    this.events[eventName].push(callback);
  },

  emit(eventName, data) {
    const listeners = this.events[eventName];
    if (listeners) {
      listeners.forEach(callback => callback(data)); 
    }
  }
};

You can read more on this here

Anyways, what's clear is that we are calling our wasm functions synchronously which was contributing to the presentation delay we faced earlier. To make the interaction seem instantaneous, we can fire the event after the frame has been painted, i.e.

After the user can visually see that the piece has been picked and
After the piece has been placed.

Can you guess what's coming next ?

Let's defer emitting the events to the next iteration of the event loop -

function startDrag(event: MouseEvent, piece: string, rankIndex: number, fileIndex: number) {
  ...
  setTimeout(() => {
    emit('pieceTouched', {
      fileIndex: fromFile,
      rankIndex: fromRank,
    })
  }, 0)
}

function onDragEnd(event: MouseEvent) {
  ...
  setTimeout(() => {
    emit('movePlayed', movePlayed)
    playMoveSound()
  }, 0)
  ...
}

Let's see how we are doing now -

37ms!! That's the best we can pull off for this tiny BareBoard.

Conclusion

Performance optimization on the web is crucial for an open source library adoption, most of the times it is almost always about choreographing when those instructions run. By understanding how the browser’s Event Loop actually interacts with the Call Stack and Web APIs, we were able to turn a janky 350ms freeze into a smooth 37ms interaction.

Github: https://github.com/8bye8/bareboard
Npm: https://www.npmjs.com/package/@8bye8/bareboard

Credits

The Event Loop | Jake Archibald : https://www.youtube.com/watch?v=qz6yDqjMVfw
Optimizing INP | A deep dive: https://www.youtube.com/watch?v=cmtfM4emG5k
Demystifying Asynchronous Programming Part 2: Node.js EventEmitter:
https://www.codementor.io/@simenli/demystifying-asynchronous-programming-part-2-node-js-eventemitter-7r51ivby4
Interaction to Next Paint (INP): https://web.dev/articles/inp
Avoid large, complex layouts and layout thrashing: https://web.dev/articles/avoid-large-complex-layouts-and-layout-thrashing

Understanding INP: The Newest Core Web Vital and Why It Matters

Thu, 23 Apr 2026 22:56:03 +0000

If you have been optimising for Core Web Vitals for a few years, you will remember First Input Delay (FID) as the “interactivity” metric. That role now belongs to Interaction to Next Paint (INP). Google promoted INP to a stable Core Web Vital on 12 March 2024 and retired FID from the programme at the same time. INP is not a minor rename—it measures a fuller slice of the experience, and it is the number you should expect in PageSpeed Insights, Search Console, and any serious performance report.

This article explains what INP is, why the change happened, and what to do about it in day-to-day work—including when you are responsible for many client sites rather than a single product. For step-by-step fixes, pair it with our deeper guide on LCP, INP, and CLS; for the wider CWV picture, start with What Are Core Web Vitals?

What INP measures (in plain terms)

INP captures responsiveness: how long it takes from a user’s discrete action until the browser can paint the next frame that reflects that action. Eligible interactions are clicks, taps, and key presses on the page. Hovering and scrolling are out of scope for INP, which keeps the metric focused on deliberate gestures that expect immediate feedback.

Google’s documentation breaks each interaction into phases that developers actually debug: input delay (waiting for the main thread), processing time (your event handlers), and presentation delay (work before the next paint). The slowest of those phases dominates the interaction’s latency. The page’s reported INP is derived from the interactions observed during the visit—for most pages that is effectively the worst interaction; on very chatty pages, the methodology discounts rare outliers so one freak delay does not drown out an otherwise snappy experience.

Field scoring uses the 75th percentile of page loads (split by mobile and desktop), consistent with other Core Web Vitals. The public thresholds are:

Rating	INP (field)
Good	≤ 200 ms
Needs improvement	200–500 ms
Poor	> 500 ms

Those numbers are not aspirational labels—they are what Google uses when it evaluates real-user experience at scale.

Where INP sits next to LCP and CLS

Core Web Vitals are still a set of three: LCP for loading, INP for responsiveness, CLS for visual stability. They answer different questions. You can ship a fast first paint and still fail INP if the main thread is busy when someone opens a menu; you can pass INP on a lean marketing page and still fail CLS if images without dimensions push content around. In practice, teams prioritise LCP first because it is easy to explain to stakeholders and often tied to hero assets and CDN configuration. INP rewards the same discipline—JavaScript budget, tag governance, framework choices—but shows up in different URLs and flows, especially after hydration. Treat the three metrics as separate dials, not one score.

Why FID was not enough

FID only looked at the first interaction on a page, and only at input delay: time before the browser started handling the event. That made FID useful for catching catastrophic main-thread blocking during load, but it ignored everything that happens after the page is interactive. Google notes that Chrome usage data shows most of a typical visit happens after load; a slow menu, cart step, or client-rendered route change could leave FID looking fine while users still felt a sluggish product.

INP closes that gap by measuring responsiveness across the full session and including processing and presentation, not just the queue in front of the first handler. That is why INP is a better match for modern sites heavy on JavaScript, third-party widgets, and single-page transitions—exactly the stacks agencies ship for clients every week.

Why INP matters for SEO and for users

Core Web Vitals are part of Google’s page experience signals. INP is the responsiveness pillar: poor scores indicate real friction—double taps, abandoned forms, rage clicks—while good scores mean the UI keeps up with input. Search is not the only reason to care; conversion and support tickets follow the same physics.

For teams managing portfolios of sites, INP adds a wrinkle: the worst interactions often sit on templates (navigation, checkout, lead forms) or on third-party scripts shared across properties. One slow pattern can drag INP for every page that uses it. That is less visible in a one-off Lighthouse run than in field data or repeated URL-level checks over time—which is why operational monitoring and regression alerts matter alongside manual audits.

How to see INP in practice

PageSpeed Insights pulls field data from the Chrome User Experience Report (CrUX) when your origin or URL has enough traffic; that is the authoritative place to see whether you pass INP at the 75th percentile. Lab tools do not compute INP directly; Lighthouse’s Total Blocking Time (TBT) is a rough proxy for main-thread contention that often tracks with INP problems, but it is not interchangeable. When CrUX data is missing—common on small or new sites—use real user monitoring (RUM) if you have it, or fall back to manual profiling in Chrome DevTools for representative flows.

Search Console’s Core Web Vitals report surfaces INP (and no longer treats FID as a Core Web Vital) after the March 2024 transition, so keep INP in scope when you triage URL groups and templates.

If you are building a repeatable workflow for clients—baselines, fixes, then proof—our Core Web Vitals monitoring checklist for agencies ties these metrics to review cadence and ownership. For setup across many monitored URLs, How to Set Up Automated PageSpeed Monitoring for Multiple Sites walks through the operational pieces.

What usually hurts INP

These patterns show up repeatedly in audits:

Long tasks on the main thread — parsing and executing large JavaScript bundles, synchronously updating heavy DOM trees, or blocking styles/layout after an interaction.
Third-party tags — analytics, chat, consent banners, and A/B snippets competing for the same thread as your UI handlers.
Large DOMs and expensive selectors — interactions that trigger wide reflows or style recalculations on complex pages.
Client-heavy rendering — SPAs that wait on data or hydration before showing feedback; users perceive that as “nothing happened” even when the network is fast.

A concrete pattern we see on client sites: the first click after load feels fine (FID would have looked healthy), but the fifth interaction—opening a filtered product grid, submitting a multi-step form, or toggling a sticky nav—hits a long task left behind by a tag or a bundle split. INP catches that; FID did not. Embeds deserve attention too: slow interactions inside iframes still count toward the page-level INP users see, while your own JavaScript cannot inspect cross-origin iframe code—so field data and DevTools frame selection matter when CrUX and RUM disagree.

Google’s own guides on optimising long tasks, input delay, and interaction diagnostics are the right next step once you know which interaction is slow.

INP and Apogee Watcher

Apogee Watcher is built to run scheduled PageSpeed-class tests across many sites and routes, surface lab and field signals where the API provides them, and alert you when scores move. INP is fundamentally a field-first metric: fixing it means reproducing real interactions, trimming main-thread work, and re-checking user journeys—not a single synthetic number in isolation. Use Watcher to watch for regressions when you ship framework upgrades, tag managers, or new client themes; pair those signals with DevTools and CrUX for the interactions CrUX cannot explain line-by-line.

If you are not monitoring yet, start with a baseline on your highest-traffic templates, then expand. Create a free account to add sites and budgets without wiring up PSI by hand for every property.

FAQ

When did INP replace FID as a Core Web Vital?

INP became an official Core Web Vital and replaced FID on 12 March 2024, per Google’s Web Vitals programme.

What is a good INP score?

At the 75th percentile of field data, 200 ms or less is “good”, over 500 ms is “poor”, with a band between for “needs improvement”—see Google’s INP documentation.

Does INP include scrolling or hover?

No. INP observes click, tap, and keyboard interactions. Scrolling and hover are not part of the metric, though some gestures may include a click or tap that is measured.

Is INP the same as Total Blocking Time?

No. TBT is a lab proxy related to main-thread blocking during load. INP is a field metric covering full-session interactions. They often move together when JavaScript is the culprit, but they are not identical.

Why should agencies track INP separately from LCP?

LCP measures loading; INP measures responsiveness after content is on screen. A page can have an acceptable LCP and still fail INP because of client-side code, third parties, or heavy UI after load—common on marketing sites and apps your clients maintain for years.

Further reading (Google): Interaction to Next Paint (INP), INP becomes a Core Web Vital — March 12, Optimize Interaction to Next Paint.

Mobile vs Desktop Core Web Vitals: Why You Need to Monitor Both

Mon, 13 Apr 2026 23:52:33 +0000

Most teams treat Core Web Vitals like one scoreboard. They run a quick test, pick a single set of scores, and move on. The problem is that Core Web Vitals are defined per page load; device shows up in how you measure—mobile versus desktop in lab emulation, or in field data grouped by form factor. The same URL can therefore produce different LCP, INP, and CLS results across those contexts. Mobile and desktop travel different routes through your UI, assets, network conditions, and interaction patterns. If you monitor only one side, you will miss regressions that matter—and you will struggle to justify prioritisation when clients ask, “Why did this change?”

The trap: one device, one story

It’s easy to fall into a workflow like this:

Mobile is “important”, so you track mobile CWV only.
Desktop is “nice to have”, so you leave it until later.
When something breaks, you re-run tests and pick the latest scores to explain the incident.

This approach has two predictable failure modes:

Hidden regressions — A fix that improves desktop experience can still leave mobile failing (or vice versa).
Unclear communication — You end up explaining different symptoms with one set of numbers. Clients rightly lose confidence.

If you want monitoring that supports real delivery and client-ready reporting, you need a repeatable paired view: mobile + desktop for the same pages, the same cadence, and the same triage rules.

If you need a quick primer on the metrics themselves, start with What Are Core Web Vitals?.

Why mobile vs desktop Core Web Vitals diverge

Core Web Vitals can look “similar” at a headline level, but the underlying causes often differ. The most common reasons:

Different rendering and loading conditions

Mobile is constrained: less CPU headroom, different caching patterns, and more aggressive resource variation. That shows up strongly in:

LCP (Largest Contentful Paint): often driven by large images, fonts, or other heavy elements on the critical path (the LCP element can also be a text block or a video poster, depending on the page). If those pieces behave differently across breakpoints, LCP will diverge.

Different interaction patterns (INP)

INP captures interaction responsiveness, which often behaves differently by device due to:

Touch vs pointer interactions
Different event targets and UI density
Varying execution cost on lower-end hardware

If you only look at one device’s INP, you can miss “works on desktop” but “feels slow on phones” issues.

Different layout stability (CLS)

CLS is highly sensitive to responsive layout, late-loading elements, and dynamic components that appear only under certain breakpoints (ads, banners, late injected UI, etc.). A page can be stable on desktop and still shift on mobile.

For a deeper explanation of what each metric actually means, see LCP, INP, CLS: What Each Core Web Vital Means and How to Fix It.

What to monitor in practice (beyond the total score)

Monitoring both devices is necessary, but it’s not sufficient by itself.

You also need to monitor the right dimensions:

1. Treat each device as its own budget

Instead of one “CWV target” for the page, define device-specific thresholds for the metrics you care about. A pass on desktop should not automatically compensate for a fail on mobile.

This keeps decisions defensible when you propose fixes to stakeholders.

If you want a structured way to set thresholds, use our Performance Budget Thresholds Template.

2. Compare by change, not by absolute numbers alone

Absolute CWV numbers can vary slightly run-to-run. What should drive action is:

What changed since the last known good period
Which metric moved first (LCP vs INP vs CLS)
Which device changed (mobile-first incidents vs desktop-only issues)

3. Triage using “worst metric per device”

A practical triage rule:

For mobile: focus on the single worst metric (LCP/INP/CLS) and the reason it is failing.
For desktop: do the same.

Then decide whether you have a shared root cause (both devices fail similarly) or breakpoint/device-specific problems.

A practical monitoring workflow for agencies

If you want this to work across clients and pages, keep it repeatable. Here’s a workflow you can run every week:

Choose pages that reflect real funnel risk
- Homepage (first impression)
- Key category or service pages (high intent)
- Conversion pages (where UX pain becomes business cost)
Run paired analysis for the same pages
- Mobile + desktop tests on the same cadence
- Stable analysis conditions (avoid mixing “random checks” with planned ones)
Record findings in the same order
- Mobile: LCP → INP → CLS (and a quick “what it likely affects” note)
- Desktop: LCP → INP → CLS
Assign device-specific priority
- If mobile fails and desktop passes, your “first fix” should usually start mobile unless you have a desktop-only user segment.
Set alerts that match the story
- Budget breaches on a device should trigger the device’s reporting, not just the overall page score.
Deliver client-ready reporting
- Give clients a paired narrative: “what you saw” and “what you changed next”.

For the setup side of automated monitoring across multiple sites, see How to Set Up Automated PageSpeed Monitoring for Multiple Sites.

And if you’re turning this into deliverables, the Client-Ready Core Web Vitals Report Outline helps you package the evidence into something stakeholders actually read.

Interpreting results: three common scenarios

When you review mobile vs desktop CWV together, you’ll usually fall into one of these buckets:

Scenario	What it often means	How you should respond
Mobile failing, desktop ok	Mobile critical path or interactive cost is the bottleneck	Prioritise mobile-first fixes (hero/LCP and interaction latency)
Desktop failing, mobile ok	Desktop-only layout or heavy JS path	Focus on desktop breakpoints, scripts, and layout stability
Both failing consistently	Shared design debt or performance regressions	Treat it as a system-level problem, then verify with paired reruns

The important part is that you avoid the “one score explains everything” habit. Paired monitoring turns CWV from a vanity chart into a decision system.

What your client update should say (example wording)

When clients ask “why are there two scores?”, they usually want a single paragraph that explains what changed and what you will do next.

Here’s a simple template you can reuse:

Mobile-first incident (mobile fails, desktop ok):

“Mobile performance is out of budget right now (LCP/INP/CLS), while desktop is within budget. This pattern usually points to a mobile-specific bottleneck: hero rendering timing, touch interaction cost, or a late-loading component that behaves differently on smaller breakpoints.”
“Next step: we’ll apply a targeted first-fix on the affected mobile path, then re-run the same paired checks to confirm both the device budget and the user-story are improving.”

Shared incident (both devices failing in a similar way):

“Both mobile and desktop are currently out of budget for the same metric area. That usually means a shared component, shared asset, or shared build/deploy change rather than a single device quirk.”
“Next step: we’ll verify what changed in the release window, then test the fix with paired checks to ensure the improvement holds across devices.”

If you include field data (for example, when you do CrUX-aware reporting), keep the wording consistent: explain what your lab checks caught, and how the field view supports the same story. The goal is less debate and more action.

A quick consistency check for every report

Before you send your update, run this quick self-check:

Are you using the same page set for both devices (so the comparison is fair)?
Did you name the first metric to fail on each device (so the triage is clear)?
Does your next step match the device that is failing (or explain why you’re fixing something shared first)?
Did you state how you will verify after changes (re-run paired checks, not “we’ll look later”)?

Client-ready reporting: avoid confusion with one sentence

Clients often ask why you’re reporting two device scores.

Your answer should be simple:

“Mobile and desktop measure different experiences. We monitor both so we catch issues that only appear on one device and so our fixes stay prioritised and verifiable.”

When you present this in a consistent report format, it is easier for stakeholders to focus on the next actions instead of arguing over a single headline score.

Operational checklist for your next report

Pick the same set of pages every reporting cycle
Confirm mobile + desktop are both included in the schedule
Use device-specific thresholds for LCP/INP/CLS
Triage by worst metric per device, then explain likely root cause
Reference a repeatable next step (fix + verify, not just “we will look into it”)
Share a paired narrative that stakeholders can understand in under two minutes

FAQ

Do I need to monitor both mobile and desktop if mobile gets most traffic?
Yes. Even if mobile dominates, desktop still represents business risk for a portion of your audience. More importantly, fixes can improve one device while leaving the other failing. Paired monitoring prevents blind spots.

Which metric should I start with: LCP, INP, or CLS?
Start with the worst metric on each device (mobile and desktop separately). In many audits, improving LCP is the fastest high-impact win, while INP usually surfaces interaction pain and CLS highlights layout instability—but the right first lever depends on what is actually failing.

How often should we review paired CWV?
For most agency workflows, weekly review is a good starting point. For active releases or client campaigns, you may need tighter cadence to verify that fixes actually hold.

What if a page behaves differently by device (e.g. different layout/components)?
That’s exactly why paired monitoring helps. Explain the difference in your report: the breakpoint experience is part of the user journey, and device-specific findings lead to device-specific fixes.

Will paired monitoring slow down the workflow?
It shouldn’t. The operational cost should live in automation, not manual re-checks. If your monitoring is scheduled and your reporting is templated, you get more reliable evidence without extra churn.

If you want a repeatable way to monitor mobile and desktop Core Web Vitals across client portfolios (with paired evidence, budgets, and client-ready reporting), Apogee Watcher is built for that workflow.