Gah beat me to it! 😭

Obviously love this, the only thing really different in my take was that I added explicit little subclauses to opportunities and diagnostics that they don't affect the score, just to really hammer it in :)

lol I was literally just writing this comment:

We also know from experience that people don't read all the explanatory text, so maybe we also want to augment the opportunity and diagnostic descriptions so it's clear wherever users are looking? We could do something like

These optimizations can speed up your page load and may improve the performance score.

or go even more explicit

These optimizations are not a direct part of the performance score calculation, but can speed up your page load and improve the score.

or something

These optimizations are not a direct part of the performance score calculation, but can speed up your page load and improve the score.

👍 I had it flipped in my branch (These optimizations can speed up your page load but do not directly affect your performance score.) but I like this a lot too :)

These optimizations are not a direct part of the performance score calculation, but can speed up your page load and improve the score.

"These are generalized web performance optimizations, they do not directly contribute to the Lighthouse Performance score."

Just ideas 🤔

So trying out these variations:

Opportunities - These optimizations can speed up your page load but do not directly affect your performance score.

Opportunities - These optimizations can speed up your page load; they do not directly contribute to the Performance score.

express what we mean, but they also take up a (relatively) lot of visual space to explain what the opportunities are not, which is UI noise and it kind of undercuts the perceived usefulness of the opportunities right before we ask users to pay attention to them :)

Another option (kind of mentioned above) is phrasing positively, though that makes the score disclaimer more implicit. Something like:

Opportunities - These optimizations can speed up your page load, improving the scored performance metrics.

So maybe today (so we can ship 5.2), pick one of:

• pick one of the above if you feel it really captures things
• propose a variation of one of the above if you feel it's close but not quite there
• propose something completely different if you have a flash of insight right now
• let's punt on the opps/diagnostic string change

Opportunities - These optimizations can speed up your page load; they do not directly contribute to the Performance score.

👍👍 I'm also fine with the version with 'but' in there. I think some version of this should be shipped.

Opportunities - These optimizations can speed up your page load, improving the scored performance metrics.

I think this moves us in the wrong direction. This makes it sounds like the opportunities are a direct factor of the score to me.

I'd be disappointed if we punted. This is one of the few things I tell pretty much every single person I introduce lighthouse to and, IMO, is central to reacting appropriately to the opportunities (treating them as a guide but not freaking out over a single resource showing up there you can't control).

Opportunities - These optimizations can speed up your page load; they do not directly contribute to the Performance score.

👍👍 I'm also fine with the version with 'but' in there. I think some version of this should be shipped.

so my issues are

• half of it is telling you what opportunities can't do, which makes them seem less useful
• the half that tells you what they can do is super vague
• we say these can speed up page load and we say metrics make up the performance score, but we don't make explicit why you should care about opportunities then: these were chosen to help you improve the metrics.

Opportunities - These optimizations can speed up your page load, improving the scored performance metrics.

I think this moves us in the wrong direction. This makes it sounds like the opportunities are a direct factor of the score to me.

I can kind of see that, but is it a matter of phrasing or is it fundamental to the approach? :)

I'd be disappointed if we punted. This is one of the few things I tell pretty much every single person I introduce lighthouse to and, IMO, is central to reacting appropriately to the opportunities (treating them as a guide but not freaking out over a single resource showing up there you can't control).

totally agree on all this, I meant ship the first part because everyone seems fine enough on it and so we have something and then we can reconvene on the second part.

Opportunities - These optimizations can speed up your page load; they do not directly contribute to the Performance score.

👍👍 I'm also fine with the version with 'but' in there. I think some version of this should be shipped.

so my issues are

• half of it is telling you what opportunities can't do, which makes them seem less useful
• the half that tells you what they can do is super vague
• we say these can speed up page load and we say metrics make up the performance score, but we don't make explicit why you should care about opportunities then: these were chosen to help you improve the metrics.

example report with this string to see it in context. Maybe the negative thing is just me :)

https://pumped-dash.glitch.me/

what about something under Metrics ala: Performance score is based only on these values, then you could drop the negative statement in Opportunities.

what about something under Metrics ala: Performance score is based only on these values, then you could drop the negative statement in Opportunities.

that's in there :)

See #9355 (comment) for why we might want more

Hi all! Elizabeth forwarded this thread to me to see if I could weigh in (for those who don't know me, I'm a UXW for Chrome – hello!).

I like the general consensus where everyone is heading: we're offering useful insight while transparently mitigating user expectations. With the currently proposed drafts, one small nudge is that we typically put the positive factors first; so, it should be ordered from 'speed up' → 'score impact': "These optimizations can help your page load faster, but they don't directly impact the Performance score."

To address Brendan's feedback directly:

• "half of it is telling you what opportunities can't do, which makes them seem less useful" ⇒ This is true, but mitigating expectations is valuable for user trust! It's much worse for someone to stop trusting Lighthouse because they spent tons of time on fixing the list of opportunities and then they didn't see any improvement to their score
• "the half that tells you what they can do is super vague" ⇒ I agree! Can we be more explicit and call out exactly which metrics are most likely to be positively impacted?
• "we say these can speed up page load and we say metrics make up the performance score, but we don't make explicit why you should care about opportunities then: these were chosen to help you improve the metrics" ⇒ From a string perspective, this looks like a fundamental contradiction: these actions will not improve your score, but they will improve your metrics? Any chance you can flesh that out so I can better help out?

Thanks for the valuable insight @meggynw!!

Can we be more explicit and call out exactly which metrics are most likely to be positively impacted?

The primary reason it's so vague is that each opportunity affects different aspects of load performance. Some will affect "FCP", others will affect "TTI", still others will not directly reflect in our set of metrics but still positively impact the amount of time taken for the entire page to download. We had thrown around in years past the idea of directly stating what each opportunity does, but it's certainly a UX challenge for information overload and more on this in the next response...

this looks like a fundamental contraction: these actions will not improve your score, but they will improve your metrics? Any chance you can flesh that out so I can better help out?

One of the main challenges with the opportunities is that they can impact the page in many different ways. While we are definitely prioritizing them by their estimated overall impact (and hiding them completely if we think they're not worthwhile), it's not an exact science and promising an exact score increase would be overpromising (and as you so excellently put it, jeopardize user trust).

Another mismatch with the opportunities:score relationship is that we construct our incentives around the score while opportunities are always meant to be just helpful advice. Example: if you're doing really well on a particular metric, we might give you a great score there to incentivize moving on to another metric, but there still might be room for improvement we found, so an opportunity could still be visible (albeit low priority). On the flip side, there are cases where the score is very low but there are few automatically identifiable opportunities for improvement. Disconnecting the score from the opportunities goes a long way IMO to helping users better interpret the information we're giving.

Thanks for the thorough answer :) That all makes a lot of sense.

Based on my understanding, I've tweaked our string to the following. I propose "suggestions" instead of "optimizations" as it makes the noun is less redundant with "page load faster"; it also emphasizes that these are nice-to-haves instead of priority items. I've tried to use "directly related" in the 2nd sentence to clarify that, while there may be a minor positive impact, devs can't rely on opportunities for score improvements.

"These suggestions can help your page load faster. They aren't directly related to Performance metrics or the total score."

Reactions? Open to feedback :)

"These suggestions can help your page load faster. They aren't directly related to Performance metrics or the total score."

Reactions! :)

• I like "suggestions" here 👍
• I don't love saying they're not related to "performance metrics" at large. All of the opportunities are computed on some performance metric, is just might not help your score due to our weighting and score curves.

My tweak might be:

These suggestions can help your page load faster. They do not directly affect the overall performance score.

I personally like "affect" compared to "relate" since I think it gets at the heart of people's fears that the opportunity result is negatively affecting their score.

That string LGTM! I'd just use the contraction "don't" for a more
conversational tone. Also, another alternative to "affect" is "impact," but
I don't have a strong preference.

I think one nuance that was lost in the end here was that Opportunities actually are Lighthouse's best current advice for how users can impact their score. The distinction is hard to communicate :)

A lot of users interpret it as "my score is bad because I'm not doing the things in this list", when really it's "your score is bad because the metrics showed the page loaded slowly; here's a list of things we think should (but won't necessarily) improve the page load and thus the metrics and thus your score".

They can do everything in that list and still have a slow page (the opportunities and the metrics aren't exhaustive), or they could not do everything in the list and have a fast page (if you have a 2s opportunity on a 1s page load that's a bug but some form of this does happen).

Anyway, the fact that we don't add up the opportunities to make a score is what we'd like to clear up. If we land too far on the conservative side ("here is some random trivia about your page that will never ever have anything to do with your score" :), that's probably ok for a while.

on calling out optimizations+scoring in the report:

I think it's unnecessary.

I like the new "disclaimer" text for metrics and the long-awaited link to scoring docs. The prominent link directs people to a page that should communicate clearly that about the relationship of opportunities results & score.

We can start with adding just that metrics disclaimer sentence along with refreshed scoring docs.

Trying to represent @exterkamp and myself:

we should just go with the (perhaps too) strongly worded warning. In an ideal world we could do just the metrics warning change and see if confusion drops, but our feedback routes for this are too tenuous and hard to quantify. If confusion continues, a likely outcome is that we'll just continue to debate the few signals we get from it and do nothing about it until the next UI change.

Instead, it doesn't do much harm to go overboard on waving people off opportunities, and the fact that we will be seeing it in the report every day means that if we do find it doesn't express the situation well we'll be more likely to revise in the future.

(though for the record I still 100% agree with everything I wrote above :)

@paulirish sounds like he can live with this if directly affect is a link to an entry in the scoring docs explaining exactly what that means :)

updated with strings. Links are in progress (going to link to update from google/WebFundamentals#7724)