-
Notifications
You must be signed in to change notification settings - Fork 9.4k
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(uses-rel-preconnect): warn on 3+ preconnects #9903
core(uses-rel-preconnect): warn on 3+ preconnects #9903
Conversation
Thanks for your pull request. It looks like this may be your first contribution to a Google open source project (if not, look below for help). Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). 📝 Please visit https://cla.developers.google.com/ to sign. Once you've signed (or fixed any issues), please reply here with What to do if you already signed the CLAIndividual signers
Corporate signers
ℹ️ Googlers: Go here for more info. |
@googlebot I signed it! |
CLAs look good, thanks! ℹ️ Googlers: Go here for more info. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thanks very much @piotrzarycki!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure if I understand the root issue in #9894. From my reading of uses-rel-preconnect
, the audit will currently suggest that you preconnect to all preconnectable origins. If someone adds preconnects to all those origins, reruns Lighthouse, and gets a new set of suggested preconnect origins in the next page load, that means they're all new origins, and it seems likely the preconnected origins added in the last round aren't actually being used.
It seems like a warning that preconnects aren't being used (like we do in uses-rel-preload
) would be more useful in that case, since going over a browser preconnect limit is really the second order effect and would actually be hiding the fact that the browser is wasting time connecting to origins that don't need it.
However, for a site like the one in #9894, I don't know how we avoid getting into a cycle of recommending adding preconnects and then recommending removing those preconnects in the next Lighthouse run. Are we sure they're all worthy of being preconnected?
We definitely don't want to say this :)
We do in fact do this already.
No we're not and that's kinda the point of showing all of them instead of just a couple. We don't really know for the particular site which origins are worth preconnecting to because if the analytics script fires like 300 ms earlier, who cares? But maybe there's another third party script thats for the customer support widget that the user actually came here for that's much more important. That's up to them, and I'm not sure we should try to distinguish anything there. |
That's for origins that a resource was loaded from but didn't take advantage of an attempted preconnect. But if I had a preconnect for |
Oh like you completely stopped making requests to that origin entirely? We wouldn't flag that right now, but we don't wouldn't flag that in preload either and you asked for "like we do in uses-rel-preload" ;) (not sure it's even possible for preload requests?) |
Co-Authored-By: Brendan Kenny <[email protected]>
@patrickhulce @brendankenny |
@piotrzarycki I think @brendankenny would feel more comfortable with this change if we still returned the Is this right @brendankenny ? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM after one last small change - just a comment change.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thanks!
closes #9894