core(scoring): apply v6 score weightings #9949
Conversation
|
updated. go/lh-perf-v6 is updated as well. once landed i will ship a 6.0 beta. |
| {id: 'largest-contentful-paint', weight: 25, group: 'metrics'}, | ||
| {id: 'interactive', weight: 15, group: 'metrics'}, | ||
| {id: 'total-blocking-time', weight: 25, group: 'metrics'}, | ||
| {id: 'cumulative-layout-shift', weight: 5, group: 'metrics'}, |
There was a problem hiding this comment.
are we generally still going to try to stick to the "ship in a release without weight" before we can ship in a breaking change with weight in the future/do we still plan to do that here with cherry-picking? or is this our new policy moving forward?
There was a problem hiding this comment.
Generally, the ideal flow for introducing a new metric is:
- add metric (invisible or visible)
- cut a minor release
- Do these ~simultaneously:
- gather HA/LR data to inform calibration
- if not already: flip metric to visible & cut a minor release, then....
- ship minor release to increase user familiarity with the metric.
- if necessary, recalibrate score curve
- add weighting
- optionally, ship a beta
- ship a major rls
while we didnt get to follow this pattern here, i'd like to use that plan going forward. hows that sound?
There was a problem hiding this comment.
great! yeah agreed.
I still think we can follow part of that pattern here if we wanted to cherry-pick those metrics into a 5.7.0 or something, so folks can play with them without jumping to a new major. I guess that was the root of my question that just was leading in an unintended direction :)
| {id: 'cumulative-layout-shift', weight: 5, group: 'metrics'}, | ||
| // intentionally left out of metrics group so they won't be displayed | ||
| {id: 'first-cpu-idle', weight: 0}, | ||
| {id: 'max-potential-fid', weight: 0}, |
There was a problem hiding this comment.
so this is being killed afterall? I thought we brought up in a recent LH meeting that this was going to stay even if it wasn't weighted but the discussion in the doc suggests this is gone gone.
There was a problem hiding this comment.
it's still in the JSON but not visible anymore.
We've long wanted to add Top Long Tasks as a diagnostic and I think that will end up being more helpful than keeping the mpFid metric.
There was a problem hiding this comment.
it's still in the JSON but not visible anymore.
right, but with the intention of removing from the JSON in the future?
I know the support was overwhelming for killing in the doc discussion but I still think it's going to be really unfortunate to have no FID-like equivalent for lab when it's like half our performance story in field.
There was a problem hiding this comment.
aside: i wouldn't want to remove this from json. but further I'd prefer a average FID metric (instead of just a max one - actually this is just EIL)
|
test failure for config number of audits though :) |
| @@ -44,8 +44,9 @@ class CumulativeLayoutShift extends Audit { | |||
| */ | |||
| static get defaultOptions() { | |||
| return { | |||
| // TODO(paulirish): Calibrate these | |||
| scorePODR: 0.05, | |||
| // Calibrated to assure 0.1 gets a score of 0.9. | |||
There was a problem hiding this comment.
maybe a note in here or in the PR description or in the scoring doc on where these came from? As we've discovered it can be very difficult to figure out our motivation for some of these curves later on :)
watch out, scores.
also #10446