You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
// If the LoAF starts after the given end time, ignore it and all
// subsequent pending LoAFs (because they're in time order).
if(loaf.startTime>end)break;
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.
The text was updated successfully, but these errors were encountered:
#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)
), thependingLoAFs
array is now ordered by how values were inserted intoloafsToKeep
. This is bad becausependingLoAFs
is assumed to be instartTime
order bygetIntersectingLoAFs
, 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
, butgetIntersectingLoAFs
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 theloafsToKeep
Set. But they're now (potentially) out of order in that batch, spreading the disorder throughout thependingLoAFs
array.Fix: don't do that :) e.g. sort or filter from the existing sorted array.
The text was updated successfully, but these errors were encountered: