When can INP value decrease when reportAllChanges is set to true?

[Lihe97]

Based on my understanding, when reportAllChanges is true, during the first 50 interactions the reported INP value should always correspond to the slowest interaction observed so far (i.e., it should only increase if a slower interaction appears).

The p98 position should only shift when the interaction count crosses the boundary (like 49 -> 50, 99 -> 100). Is this understanding correct?

However, based on my observations, I noticed that the reported INP value can decrease even before reaching 50 interactions. Why does this happen..?
When can INP value decrease when reportAllChanges is set to true?

value	delta	timestamp
248	248	1/20/2026, 11:56:29.623 AM
288	40	1/20/2026, 12:04:19.63 PM
248	-40	1/20/2026, 12:04:35.087 PM
256	8	1/20/2026, 12:04:44.243 PM
248	-8	1/20/2026, 12:07:59.964 PM
256	8	1/20/2026, 12:08:14.498 PM
264	8	1/20/2026, 12:08:16.979 PM
256	-8	1/20/2026, 12:08:20.924 PM
264	8	1/20/2026, 12:09:27.452 PM
256	-8	1/20/2026, 12:09:46.898 PM

[tunetheweb]

Your understanding is mostly correct with one two important caveats:

1. reportAllChanges only reports changes to the metric, not all new entries. So new events lower than the current metric value will not be reported (as they didn't change the overall INP metric). This means there can be many events between each reported change to the metric as noted in the README:

   [!IMPORTANT] > reportAllChanges only reports when the metric changes, not for each input to the metric. For example, a new layout shift that does not increase the CLS metric will not be reported even with reportAllChanges set to true because the CLS metric has not changed. Similarly, for INP, each interaction is not reported even with reportAllChanges set to true—just when an interaction causes an increase to INP.

   For example, if you emit 248, 200, 200, 200... , 288 then only the 248 and 288 will be reported as only those resulted in a change to the metric as all the 200 values in between didn't change the metric. Therefore it may look like there are few interactions, but on a highly interactive page, you there may be many but they are just not being reported. And the volume may mean you are crossing multiple boundaries (50, 100, 150, 200...etc.), each of which may filter out a previously highest INP values and so lower the INP metric. You can't presume this only happens on every 50 visible callbacks the library reports.

2. The other caveat is similar in that not all events will meet the minimum reporting threshold.

   The Event Timing API only emits events above is 104ms by default. This library [lowers this to 40ms](The default threshold, after the library is initialized, is 40 milliseconds) to capture more events, and it also allows this to optionally be changed to another value using the durationThreshold option. However, the minimum value is 16ms.

   This may mean, similar to above that you get the following events 248, 4, 4, 4... , 288 and again only the 248 and 288 will be reported by the library (because the others are not even emitted by the library and so are not even seen!). However the browser does keep track of these and so the interaction count on the next one (the 288) will have increased and so the library knows these events have happened and so again knows if we've crossed another 50 threshold and so may filter out a previously highest INP values and so lower the INP metric. Again, you can't presume this only happens on every 50 visible callbacks the library reports.

However, saying all that, I would not expect the values to alternate so predictably between two values as you are showing with 256 and 264. Is this just an example or something you're really seeing reported on a real page?

[Lihe97]

Thanks! I understand and agree with everything you mentioned. However, this is the real data from the integration, and I genuinely don’t understand why the INP metric would decrease....

After reading a large amount of the source code, my expectation was that it would only ever increase. The only situations where I would expect a decrease are when crossing boundaries like 50 or 100 interactions.

Intergation code was pretty simple:

export function enableINPReporting() {
    logger.trace('Start Listening to INP metric');
    onINP((metric: INPMetricWithAttribution) => {
        const inpData = {
            id: metric.id,
            value: metric.value,
            delta: metric.delta,
            target: metric.attribution.interactionTarget,
            type: metric.attribution.interactionType,
            loadState: metric.attribution.loadState,
            interactionTime: metric.attribution.interactionTime.toFixed(0),
            inputDelay: metric.attribution.inputDelay.toFixed(0),
            presentationDelay: metric.attribution.presentationDelay.toFixed(0),
            processingDuration: metric.attribution.processingDuration.toFixed(0),
            navigationType: metric.navigationType,
        };
        logger.event(`INP reported: ${metric.value}`, inpData);
    }, {
        // Report when the metric is detected with a larger value than previous one.
        reportAllChanges: true,
        // Report when the eventTiming duration (only for `event` type) is larger than 104ms (rounded to the nearest of 8ms).
        // The `first-input` event will be reported no matter what the duration is.
        durationThreshold: 104,
    });
}

[tunetheweb]

Hmmm... I'm at a loss to explain this myself.

I would suggest you log all the Event Timing entries and see if that helps you understand more:

new PerformanceObserver((entryList) => {
  for (const entry of entryList.getEntries()) {
    if (entry.interactionId) {
      console.log('Event Timing entry:', entry.startTime, entry.duration, performance.interactionCount, entry.name);
    }
  }
}).observe({type: 'event', buffered: true, performance.interactionCount});