1862939 - Add telemetry for LCP

Status: RESOLVED FIXED

(Core :: Performance Engineering, enhancement)

Description

[Bas Schouten (:bas.schouten)]

Now that bug 1722322 is fixed and we are reporting LCP, we should make sure to also report it to telemetry.

Comment 1

[Bas Schouten (:bas.schouten)]

Attachment: Bug 1862939 - Part 1: Add LCP to nsDOMNavigationTiming. r=sefeng

Comment 2

[Bas Schouten (:bas.schouten)]

Attachment: Data review request

Comment 3

[Bas Schouten (:bas.schouten)]

Attachment: Bug 1862939 - Part 2: Add LCP information to the Pageload Event. r=dpalmeiro,chutten

Depends on D192689

Comment 4

[Bas Schouten (:bas.schouten)]

Attachment: Bug 1862939 - Part 3: Add Glean histogram telemetry for LCP, mirrored to legacy telemetry. r=sefeng,chutten

Depends on D192695

Comment 5

[Chris H-C :chutten]

Comment on attachment 9361855 [details]
Data review request

PRELIMINARY NOTES:

Did you know that ./mach data-review can be used to help generate your data review request form for Glean collections? Doing so can save you time and make for a more consistent experience for Data Stewards.

DATA COLLECTION REVIEW RESPONSE:

Is there or will there be documentation that describes the schema for the ultimate data set available publicly, complete and accurate?

Yes.

Is there a control mechanism that allows the user to turn the data collection on and off?

Yes. This collection can be controlled through the product's preferences.

If the request is for permanent data collection, is there someone who will monitor the data over time?

Yes, Bas and the performance team are responsible.

Using the category system of data types on the Mozilla wiki, what collection type of data do the requested measurements fall under?

Category 1, Technical.

Is the data collection request for default-on or default-off?

Default on for all channels.

Does the instrumentation include the addition of any new identifiers?

No.

Is the data collection covered by the existing Firefox privacy notice?

Yes.

Does the data collection use a third-party collection tool?

No.

---

Result: datareview+

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/760ac18ef7af
Part 1: Add LCP to nsDOMNavigationTiming. r=sefeng
https://hg.mozilla.org/integration/autoland/rev/bf0b11e52166
Part 2: Add LCP information to the Pageload Event. r=dpalmeiro
https://hg.mozilla.org/integration/autoland/rev/cfad60e16bc9
Part 3: Add Glean histogram telemetry for LCP, mirrored to legacy telemetry. r=sefeng

Comment 7

[Cristian Tuns]

https://hg.mozilla.org/mozilla-central/rev/760ac18ef7af
https://hg.mozilla.org/mozilla-central/rev/bf0b11e52166
https://hg.mozilla.org/mozilla-central/rev/cfad60e16bc9

Comment 8

[Chris H-C :chutten]

perf.largest_contenful_paint_from_response_start has now popped in the FOG Monitoring dashboard as having a lot of InvalidOverflow. Looking at the Timing Distribution docs this happens whenever any given sample is larger than max value for the specified unit. For lcpfrs, the time_unit is millisecond which means that the samples are longer than 19 years. Which seems to indicate a bug.

This is happening to about a third of all clients in Nightly only. (Doesn't show up as a problem in Beta).

Here's a sql.tmo query to fork if SQL is your thing: https://sql.telemetry.mozilla.org/queries/96355/source#237893

Comment 9

[Bas Schouten (:bas.schouten)]

We have noticed this and are currently in the process of figuring out what's going on here. It's not clear to me how this could happen very often but I haven't had time yet to debug it.

You are right though, this is a bug, and it is on our radar.

Comment 10

[Chris H-C :chutten]

Is there a separate bug where we can keep up with updates? (this continues to dominate our monitoring dashboards)

Comment 11

[Sean Feng [:sefeng]]

I re-run the SQL to get latest data and it looks like lcpfrs wasn't the only one with this problem. There were a few other ones, and all of them were improved since around Mar 21~22. I think this indicates that there's a fundamental problem? Maybe there's an edge case where the time duration got overflowed.

I also wrote a patch in bug 1889737 to ensure we don't collect overflowed TimeDuration, and hopefully can verify this is the case.

Comment 12

[Benjamin De Kosnik [:bdekoz]]

can't hurt to error check this. If it goes in and the overflow goes away, then responseStart can be probed