Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

core(metrics): switch to speedIndex from perceptualSpeedIndex #4980

Merged
merged 5 commits into from
Apr 19, 2018

Conversation

patrickhulce
Copy link
Collaborator

@patrickhulce patrickhulce commented Apr 17, 2018

  1. Rename speed-index-metric audit to speed-index
    This was inconsistent with the names of all our other metric audits
  2. Use speedIndex instead of perceptualSpeedIndex
    While perceptual speed index was a nice experiment that had a few nice properties, it's not worth it.
    • Perceptual speed index has some glaring issues that speed index does not (Use SSIM as progress without normalization paulirish/speedline#52 (comment))
    • Speed Index is relatively well known compared to perceptual speed index and we frequently have ended up saying "it's basically the same" so the cognitive complexity of it being different is unnecessary
    • Most importantly, speed index is actually better at predicting which pages people feel load faster. Creator of perceptual speed index did research and while pSI when thrown into a fancy ML model with other parameters can outperform SI, regular SI matches people's perception 10% more than pSI. source.
    • Bonus (not real reason): it's super confusing with PSI (PageSpeed Insights) and we can start just using SI :D
  3. Adds the computed artifact version of speed index
    Regular change that was coming anyhow, but consequences are the extendedInfo has moved to the metrics mega-audit.

});
}).catch(err => {
if (/No screenshots found in trace/.test(err.message)) {
throw new LHError(LHError.errors.NO_SCREENSHOTS);
}

throw err;
}).then(speedline => {
if (speedline.frames.length === 0) {
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this was done just in the audit, but it makes sense to be doing this everywhere speedline is needed, moved the test as well

@paulirish
Copy link
Member

I'd like to add that the mentioned paper considers suggests speed index up to onload to be a potential improvement. While we can see the value in using that to weed out the carousel/modal problem, it would face some challenges with edge cases like the polymer shop (which fires onload very early, way. before the page has finished)

@patrickhulce
Copy link
Collaborator Author

I'd like to add that the mentioned paper considers suggests speed index up to onload to be a potential improvement. While we can see the value in using that to weed out the carousel/modal problem, it would face some challenges with edge cases like the polymer shop (which fires onload very early, way. before the page has finished)

yeah definitely would love to explore this in the future, but agreed there are too many thorny issues to jump to without thorough investigation

@@ -50,6 +56,23 @@ class Metrics extends Audit {
metrics.push({metricName, timing, timestamp});
}

// Include some visual metrics from speedline
metrics.push({
metricName: 'traceFirstVisualChange',
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I feel like these aren't from the trace so i think we want a diff prefix.

Copy link
Collaborator Author

@patrickhulce patrickhulce Apr 18, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

open to ideas, I'd like to be consistent here on the fact that these are the raw observed values compared to the (potentially) simulated metric values

WDYT about observedMetricName

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hmm okay. maybe we use 'observed' prefix?
(don't tell me i suggested we use 'trace' instead of 'observed' 😨 )

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

no no you're 😎 I originally had raw haha which was just worse, I didn't think to suggest observed until now :)

* @return {Promise<LH.Artifacts.Metric>}
*/
async computeObservedMetric(data, artifacts) {
const speedline = await artifacts.requestSpeedline(data.trace);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should we just collapse these 2 into 1?

not sure if we use speedline for non-speedindex purposes.
i guess if we'd want firstVC or lastVC but no speedindex computed?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd like to keep them separate for exactly that reason, also if we want to do other stuff with the frames

Copy link
Member

@paulirish paulirish Apr 18, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

aiight groovy. 🕺

metrics.push(Object.assign({metricName}, values));
metrics.push({
metricName,
timing: Math.round(values.timing),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nice

"timestamp": 185608110912
},
{
"metricName": "traceSpeedIndex",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this duplicates "metricName": "speedIndex",

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it won't in simulated cases (just like FCP/FMP)

@patrickhulce
Copy link
Collaborator Author

@paulirish was that all you had? I know blinkon is messing up the works

Copy link
Member

@brendankenny brendankenny left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can wait for @paulirish, but LGTM2

@brendankenny
Copy link
Member

except whatever happened to the tests :) I won't miss safeGet if that part was on purpose.

@patrickhulce
Copy link
Collaborator Author

except whatever happened to the tests :) I won't miss safeGet if that part was on purpose.

not sure what you mean, which tests what about them? haha I have so many ❓s :)

@brendankenny
Copy link
Member

brendankenny commented Apr 19, 2018

I meant "LGTM except for whatever made the tests start failing" :) And one of the failures is eslint complaining about safeGet no longer being used, which would be 🎉

@patrickhulce
Copy link
Collaborator Author

ooooh, yes I probably need to update some stuff from rebase

@paulirish paulirish merged commit cc56516 into master Apr 19, 2018
@paulirish paulirish deleted the speed_index branch April 19, 2018 20:10
kdzwinel pushed a commit to kdzwinel/lighthouse that referenced this pull request Aug 16, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants