core(scoring): tweak scoring thresholds based on HTTPArchive data #5022
Conversation
| @@ -37,9 +37,11 @@ class CacheHeaders extends Audit { | |||
| */ | |||
| static get defaultOptions() { | |||
| return { | |||
| // see https://www.desmos.com/calculator/zokzso8umm | |||
| // 50th and 75th percentiles HTTPArchive -> 50 and 75 | |||
| // https://bigquery.cloud.google.com/table/httparchive:lighthouse.2018_04_01_mobile?pli=1 | |||
There was a problem hiding this comment.
are there links for any of these in https://httparchive.org/reports? Nicer experience than just a link to the bigquery table, but not sure if @rviscomi has one for each LH audit
There was a problem hiding this comment.
I can link to the state of javascript/byte weight when we do that, but yeah if there are premade ones that'd be even better :D
There was a problem hiding this comment.
I also thought I remembered httparchive having # dom elements but I couldn't find the report where I expected and ended up querying ours instead
There was a problem hiding this comment.
The legacy site tracks average DOM element count: https://legacy.httparchive.org/trends.php#bytesHtmlDoc&numDomElements.
If there are any stats you'd like to see added to the redesigned site, please file an issue and consider contributing, I'd be happy to help with the setup.
yeah I had already done the metric ones for our meeting to propose it, and there really aren't that many others so programmatic seemed like overkill at that point |
tweaks all the metric scoring points according to our agreed upon scheme, 90th percentile becomes a 75, 75th percentile becomes a 50. Pretty much everything got much harsher except for speedIndex.
I also updated 2 non-metric numeric audits, long-cache-ttl and dom-size which were insanely out of whack with the distributions, for them I picked the quantiles which still seemed reasonable (i.e. the real 75th percentile for dom-size was like 30 nodes, or something ridiculously low)
I didn't update bootup-time/mainthread since something seemed fishy with the data, like ~30% of values are 0, which seems impossible that that many sites have 0ms of javascript on mobile.
ref #4629 #4333 #5008