Expose CLS (cumulative layout shift) value

[paulirish]

Currently there's a layoutShift entry in the _chromeUserTiming object, but the value refers to the timestamp.

  "_chromeUserTiming.domContentLoadedEventEnd": 7315,
  "_chromeUserTiming.LayoutShift": 11822,
  "_chromeUserTiming.LargestContentfulPaint": 10763,

Of course, in the case of CLS, the timestamp isn't really important but you want the cumulative score.

Since _chromeUserTiming is entirely populated from trace events (and not via a performanceobserver), you can pull the args.data.cumulative_score of the last layout shift event. (that's basically what lighthouse does)

cc @brendankenny and lhissue

[pmeenan]

We could also add a section to the JSON that tracks each layout shift and the size so it can be used in the filmstrip and waterfall.

[paulirish]

SGTM!

[pmeenan]

Turns out it was easier than I expected (and no agent changes required). We were already storing the raw events with every test and the processing was done on the php side. I just needed to have the php extract the cumulative score (for the main frame) from the trace events.

That means we also already have all of the raw data we need for using the events in the filmstrip if we decide to.

For now CLS is only exposed in the HAR/JSON results and not in the UI. I'll have to freshen up the UI to use it as well as to switch the TTI metric to TBT.

https://www.webpagetest.org/jsonResult.php?test=200320_8S_f2aca4cc72b034a7ffe7650ea016f1f9&pretty=1

"chromeUserTiming.CumulativeLayoutShift": 0.0078584738

For now it is assuming a 0.0 as a starting value if there are no "LayoutShift" events in the main frame.

[pmeenan]

Probably worth mentioning, the data will be in the April HTTP Archive crawl if you're looking for it there since the March crawl is just finishing up.