Lighthouse: Lighthouse sometimes complains, sometimes it doesn't about link rel="preconnect" tags

Created on 4 Feb 2020  路  7Comments  路  Source: GoogleChrome/lighthouse

Hey guys,

First of all, thank you for all the work you are doing on Lighthouse. It helps us a lot to improve overall website performance.

Initially I wanted to mark this as a bug, but I wasn't sure so I hope this is a better categorization of my issue.

We have an SSR React app with client-side hydration. On the initial request, we respond send an HTML representation of our DOM.

We are using Lighthouse via a multitude of environments: CI, Treo.sh, Chrome Dev Tools Audits, and there's an issue which gets flagged inconsistently in the form of link rel="preconnect" tags.

These link preconnect tags get constantly flagged by Treo, but inconsistently by Chrome Dev Tools Lighthouse.

Lighthouse audit run locally:

image

If I run the audit again it doesn't flag anything about the previous preconnect tags.

image

(We know about those new origins, that flagging is valid as we didn't treat those origins yet)

These are the settings under which Treo.sh is running Lighthouse audits. Treo is constantly flagging the preconnect tags.

image

Are we doing something wrong?

Is it a Chrome Lighthouse false-positive?

image
(my local Lighthouse settings. Running Chrome Version 79.0.3945.130 (Official Build) (64-bit) )

Are we adding the links to the HTML source in a poor way (we've done HTML validations and they all check out)?

Because of this flaky flagging, we are not sure what actions should we take to make this right.

Let me know if you need any other info.

needs-priority pending-close question

Most helpful comment

There aren't any formal web.dev documents on this particular subject since the findings were relatively new (late 2019), but here's a Chromium bug where the results of the experiment were discussed.

tl;dr - ignoring excessive preconnect requests reduced overall FCP times by ~0.5%, data usage by ~0.1%, and abort rates on slow networks by ~4%

All 7 comments

Thanks very much for filing with such detail @gnechita-toptal!

For this audit specifically, we're actually adjusting the advice in 6.0.0 to make sure you're not attempting to preconnect to too many origins for the precise reason that many will go unused by Chrome (and not only lead to these annoying warnings but also waste effort and network bandwidth!). For now you can trim down your preconnect links to just the most important 2 origins and safely ignore the other results until latest Lighthouse is published in all channels.

@patrickhulce thanks for the info.

Could you please answer me another question or point me to a web.dev article or something if you can?

When you say "but also waste effort and network bandwidth", is this affecting in any way website performance (TTI, overall page speed, etc)? or does it affect the end-user (generate more data usage, etc)?

I might have some gaps in my understanding and I wanted to make sure I have the full picture.

There aren't any formal web.dev documents on this particular subject since the findings were relatively new (late 2019), but here's a Chromium bug where the results of the experiment were discussed.

tl;dr - ignoring excessive preconnect requests reduced overall FCP times by ~0.5%, data usage by ~0.1%, and abort rates on slow networks by ~4%

@patrickhulce thank you very much for the help!

@patrickhulce Sorry for re-opening this, I just had one more question to "bury" this issue of using preconnect links.

Would be wise to replace a bunch of "rel preconnect" link tags with "rel dns-prefetch" just to cover at least the DNS resolution, even though that resource might not get used eventually?

Let's say you are prefetching the DNS for a bunch of 3rd-party domains but not all will be used to download js scripts eventually.

Ideally, you would only DNS prefetch what you end up using, but let's say that wouldn't be feasible to maintain technically in the long term, and this list of domains needing to be prefetched is constantly changing.

@gnechita-toptal that makes sense to me especially since the cost of a DNS prefetch for an already cached DNS lookup should be virtually 0 compared to the expensive TCP handshake that preconnect would always trigger.

I can't really speak with authority or data on the effects of unnecessarily dns-prefetching unused domains though. It certainly should have fewer negative effects than preconnect, but I would expect if you're on a very constrained connection and there are too many unused prefetches that it would start to interfere again. If anyone watching this issue knows of data in this area, that'd be awesome to share :)

@patrickhulce thanks! :D

Closing this for good now!

Was this page helpful?
0 / 5 - 0 ratings

Related issues

motiejuss picture motiejuss  路  3Comments

timj2 picture timj2  路  3Comments

dkajtoch picture dkajtoch  路  3Comments

bitttttten picture bitttttten  路  3Comments

mohanrohith picture mohanrohith  路  3Comments