Lighthouse: Audit: false positive for preconnect/dns-prefetch suggestion

[ebidel]

OMG. Finally moved off tumblr.com for my blog! I built a dope site but want to make The House the happiest it can be.

I'm using `link rel=preconnect" for a couple of domains, but LH re-suggests that to me as an improvement :\

Provide the steps to reproduce

1. Run LH 3.0.3 on https://ericbidelman.com

What is the current behavior?

Perf > Opportunities says that I should use dns-prefetch and/or connect to reduce RTTs to origins:

What is the expected behavior?

I'm already using preconnect for both these origins:

Not sure if the audit already does this, but we we could look at the DOM for link rel=preconnect|dns-prefetch and remove any origins users are already preconnecting to.

Environment Information

• Lighthouse version: 3.0.3

Related issues

Report:
https://googlechrome.github.io/lighthouse/viewer/?gist=4bd3bf89ce0ac69319db6cf1e9b94a83

[patrickhulce]

Good find thanks @ebidel :)

[wardpeet]

I've found a few things i'm not sure if we should fix it.

1) you're not preconnecting fonts.googleapis.com but you are preconnecting https://fonts.gstatic.com https://fonts.gstatic.com is used for the woff file and fonts.googleapis.com for the css file.
2) https://www.google-analytics.com should indeed be preconnected but somehow on a cold chrome it isn't. When running it through cli I get these origins as flagged but from devtools or extension I do not.

When going into chrome://net-internals/ and clear all caches I have the same issue as cli with devtools & extension. So the only fix is to check the DOM and HTTP-headers to see if they are marked as preconnected. This would make the audit easier to read too. WDYT to write a gatherer for this?

[gja]

I'm able to reproduce this bug from the command line if i use --chrome-flags="--headless". When I run lighthouse in normal mode, it seems to preconnect normally.

[wardpeet]

@patrickhulce what do you think of making a gatherer of preconnect tags?

[patrickhulce]

@wardpeet in general I'm not a fan of going the static analysis route for these especially since it's hard to determine what's worth the effort to be "extra safe" and what's not. Also because it's difficult to know that you've done preconnect right! i.e. if you correct crossorigin value such that the connection can be reused. It'd be difficult for us to know that it required crossorigin="use-credentials" for example.

I think we should try to investigate why it's not being preconnected to google-analytics and solve that bug before resorting to manual static overrides.

[stephen-last]

I think I'm seeing the same. The report has Lighthouse 4.0.0-alpha.1 at the top.

I'm using the Lighthouse Chrome ext:

I have some preconnect link's in the HTML:

But Lighthouse is suggesting I add them:

[patrickhulce]

@wardpeet are you working on this or can I steal it from you? :)

[patrickhulce]

FWIW, my investigation on #6676 has sufficiently convinced me your static analysis route is worth it, so if you already had something along those lines be my guest!

[wardpeet]

@patrickhulce feel free to take over. I haven't done anything yet

[patrickhulce]

hey @ebidel FYI I think LH might be right here, it looks like we don't want the crossorigin attribute on the google-analytics preconnect, removing it starts properly connecting for me on a test page.

Without crossorigin
https://www.webpagetest.org/result/181207_Z3_0bfcc9e3542a8c4f9dda1f9395e27268/1/details/

With crossorigin
https://www.webpagetest.org/result/181207_H7_63d41425c12253f21a0963c2af5ca01b/1/details/

[nicolaskopp]

@patrickhulce I think this is not solved, because I get inconsistent behaviour with the integrated Chrome "audits", Lighthouse as standalone a Chrome extension and Pagespeed Insights results.

I get this inconsistent behaviour across various sites, not only one one domain. Furthermore, sometimes the hint to preconnect to required origins does show up, sometimes it does not, and it does especially not show up when the site is _fast enough with out preconnects_ (say, 90 score or better)

I think the hints should show up independently on how fast the site is. Also, Lighthouse / Google Audits should give hints on what's wrong and what's working - so if a "crossorigin" is required or not for a certain domain, because trial & error is very cumbersome and yields inconsistent reports.

The way I implemented it and i think it is correct that way is like this, for example on this Domain:

https://www.lifta.co.za

<link rel="preconnect dns-prefetch" href="https://in.hotjar.com" crossorigin>
<link rel="preconnect dns-prefetch" href="https://vars.hotjar.com" crossorigin>
<link rel="preconnect dns-prefetch" href="https://script.hotjar.com" crossorigin>
<link rel="preconnect dns-prefetch" href="https://stats.g.doubleclick.net" crossorigin>
<link rel="preconnect dns-prefetch" href="https://www.google-analytics.com" crossorigin>
<link rel="preconnect dns-prefetch" href="https://www.google.com" crossorigin>
<link rel="preconnect dns-prefetch" href="https://www.google.de" crossorigin>
<link rel="preconnect dns-prefetch" href="https://www.facebook.com" crossorigin>
<link rel="preconnect dns-prefetch" href="https://connect.facebook.net" crossorigin>
<link rel="preconnect dns-prefetch" href="https://al01.adia.tv" crossorigin>
<link rel="preconnect dns-prefetch" href="https://www.googletagmanager.com" crossorigin>

<link rel="preload" as="font" href="https://www.lifta.co.za/wp-content/plugins/accordions/assets/global/webfonts/fa-solid-900.woff2" crossorigin type="font/woff2">
<link rel="preload" as="font" href="https://www.lifta.co.za/wp-content/uploads/2016/12/328A8C_1_0.woff" crossorigin type="font/woff">
<link rel="preload" as="font" href="https://www.lifta.co.za/wp-content/uploads/2016/12/328A8C_6_0.woff" crossorigin type="font/woff">
<link rel="preload" as="font" href="https://www.lifta.co.za/wp-content/themes/Avada/includes/lib/assets/fonts/icomoon/icomoon.woff" crossorigin type="font/woff">
<link rel="preload" as="script" href="https://www.google-analytics.com/analytics.js">
<link rel="preload" as="script" href="https://static.hotjar.com/c/hotjar-1161180.js?sv=5">
<link rel="preload" as="script" href="https://www.googletagmanager.com/gtm.js?id=GTM-K4LRQK">

Google Audits does not show a hint to preconnect, Google Lighthouse does show a hint, Pagespeed insights does not show a hint. very weird.

[patrickhulce]

Furthermore, sometimes the hint to preconnect to required origins does show up, sometimes it does not, and it does especially not show up when the site is fast enough with out preconnects

This is working exactly as intended then :) The goal of the opportunities is to highlight lowest hanging fruit that will have a measurable impact on your performance, so in cases where they wouldn't have a noticeable impact, they should not be showing up.

Lighthouse / Google Audits should give hints on what's wrong and what's working - so if a "crossorigin" is required or not for a certain domain, because trial & error is very cumbersome and yields inconsistent reports.

I agree and in an ideal world this would be great addition. Unfortunately, the need for that attribute is controlled by the specific way in which it's requested/used which isn't always visible to us from the network headers alone.

It might be possible to piece together the entire picture from other element information on the page though, and exploration of what is possible here would be a really cool feature request if you wanted to open a separate issue :)

[jitendravyas]

I am having the same false positive issue

[JohnnyWalkerDesign]

Google Audits does not show a hint to preconnect, Google Lighthouse does show a hint, Pagespeed insights does not show a hint. very weird.

I'm having this issue. The same page can sometimes complain that a preconnect will help, other times the same page will not flag it. Same page, same code. It's inconsistent and will sometimes complain when you do put a preconnect in place that it isn't used :-/

[connorjclark]

I'm having this issue. The same page can sometimes complain that a preconnect will help, other times the same page will not flag it. Same page, same code.

Lighthouse isn't knocking your score for lack of preconnect - complain is the wrong word here, but instead this is a suggestion from Lighthouse that, at least for that page load, preconnect would have helped.

It's inconsistent and will sometimes complain when you do put a preconnect in place that it isn't used :-/

That seems odd. Do you have a link so we can investigate? If so, please open a new issue with it.

[dawsbot]

I'm seeing a false positive for preconnect. Luckily, we have a great system setup to document, so you can view the lighthouse report and the live site! Could I get some eyes on this @connorjclark @patrickhulce ? Thanks for helping make a great test tool!

Lighthouse report: https://everipedia-lighthouses.now.sh/2020-02-07/lighthouse.html
Live site: https://epdev123.org/

Here's the DOM:

Here's the lighthouse false positive:

Sourced

All of this came from an automated test using https://www.webpagetest.org/lighthouse then doing a wget on the page response. Saving that locally and deploying it to https://everipedia-lighthouses.now.sh/2020-02-07/lighthouse.html

EDIT: I just ran a lighthouse test on the latest Brave browser via the Lighthouse chrome extension and did NOT see this warning. Perhaps this is an issue with the lighthouse version they're running over at https://www.webpagetest.org/lighthouse ?

[patrickhulce]

@dawsbot in this WebPageTest result (https://webpagetest.org/result/200207_1J_c1f01a929bb96dde1265c14cd44ffd56/1/details/#waterfall_view_step1) without Lighthouse involved, those origins were not preconnected, so it would appear that Lighthouse is correctly flagging this situation. It's worth noting that Chrome started ignoring preconnect directives in slow network conditions when there too many, so we've changed our advice to only preconnect to the 2 most important origins in the upcoming release of Lighthouse. I'd guess this is the situation we find ourselves in now and why Brave might be still preconnecting if it's a Chrome-specific trial.