Description
#487 introduced a bug that we didn't notice that reduces (often significantly) the number of INPs that get LoAF attribution.
The extra loop added to keep LoAFs that happened after all known events
web-vitals/src/attribution/onINP.ts
Lines 201 to 210 in 5b91b76
works as expected and is only additive to the LoAFs kept for potential attribution before #487. The problem is that it adds to the loafsToKeep
set as a second batch of LoAFs, after the first loop through the LoAFs.
When the new array of LoAFs is created from this set (pendingLoAFs = Array.from(loafsToKeep)
), the pendingLoAFs
array is now ordered by how values were inserted into loafsToKeep
. This is bad because pendingLoAFs
is assumed to be in startTime
order by getIntersectingLoAFs
, which will quit looking for intersecting LoAFs early if it thinks it's reached the end of possible intersections:
web-vitals/src/attribution/onINP.ts
Lines 233 to 235 in 5b91b76
All the correct LoAFs are in pendingLoAFs
, but getIntersectingLoAFs
gives up before seeing them. I believe this tends to get worse for busier or longer-lived pages because LoAFs that happened after any known interaction events get put last in this array initially, then they get paired with some event group as events come in so get put into the first batch of LoAFs in the loafsToKeep
Set. But they're now (potentially) out of order in that batch, spreading the disorder throughout the pendingLoAFs
array.
Fix: don't do that :) e.g. sort or filter from the existing sorted array.