LoAF attribution

[rviscomi]

Are there plans to add experimental LoAF support to the attribution build?

[tunetheweb]

@gilbertococchi 's been asking for this too.

IMHO not until it lands in stable Chrome without being behind a flag. We don't want people to depend on implementations that might change. In same way we're not landing soft navs in main branch until then. We could look at another draft PR and test branch for LoAF support too, but that's more to manage so would rather keep long-lived test branches to a max of 1 at a time.

[rviscomi]

We could look at another draft PR and test branch for LoAF support too

That'd be my preference. Best to give the community something to work with to encourage early adoption, like you mentioned for soft navs. The added maintenance overhead doesn't seem like a huge burden.

If it doesn't work out, maybe someone would be willing to maintain it in a fork.

[tunetheweb]

We also need to figure out what we'd use it for. Presumably you want to link it up to the INP interaction (which is non-trivial at the moment) and then feed back the attribution in analytics?

But I don't want to make assumptions here, so looking for people to document how they would see it being used in web-vitals.js.

[lebreRafael]

I think I would expect the INPAttribution interface to have loafEntries which would be an array of all loaf entries related the current INP based on the timings like what we see on whynp.js.

The only thing that is a bit blurry to me right now is how I would handle these LoAF entries in case INP is reported more than once. I say that because I have seen INP reporting 2 times and the second one had a delta lower than the first.

I don't understand why this happens (and would really appreciate some clarification haha but I know this issue is not a place to discuss that) but in this case I think I would need to do some logic to store the loafEntries for the largest INP entry because I'm trying to report the longest script's origin related to INP.

Not sure if it helps but here are all the fields I'm reporting to my analytics

interface LoafInp {
  'loaf-inp-longest-script-name'?: string;
  'loaf-inp-longest-script-origin'?: string;
  'loaf-inp-longest-script-location'?: string;
  'loaf-inp-longest-script-duration'?: number;
  'loaf-inp-longest-script-execution-start'?: number;
  'loaf-inp-blocking-duration': number;
  'loaf-inp-trashing-duration': number;
  'loaf-inp-render-duration': number;
  'loaf-inp-longest-script-origin-all'?: string;
  'loaf-inp-longest-script-count': number;
}

[tunetheweb]

I say that because I have seen INP reporting 2 times and the second one had a delta lower than the first.

I don't understand why this happens

The value is bigger for the third one. The delta is how much bigger it is to the previously reported highest INP.

In this case, the reported INPs were 8, 88, and 96. The delta was therefore 8, 80 (80-8), and 8 (96-88).

Delta is intended for analytics solutions (like GA) where you can't update the previous value so only want to report the increase.

So this looks like it is working as intended. But let's farm off to a separate issue if you have more questions on this.

Anyway, back to LoAF discussion...

[tunetheweb]

Resolved with #442 and will be included in v4. In future we may iterate further on this to pull out the most relevant data from LoAFs if common patterns emerge that would benefit this.