Fix & update preconnect / prefetch DNS to improve pagespeed

[Rotzbua]

Change

• preconnect (DNS lookup + TLS connection) to the essential domains for a functional website.
• Use only 3 times preconnect because more can have negative effect and would exceed the current recommendation.
• Use dns-prefetch (DNS lookup) for lower prioritized APIs.
• Both techniques may shorten the delay of the loading process and thus improve the user experience.

Reference

Fixup of #467 .

[gustav87]

I googled a little bit but didn't find a good single source of truth about these options.

Does the current preconnect + dns-prefetch on the BASE_URL (which is https://w3champions.wc3.tools/prod/site and https://w3champions.wc3.tools/test/site for prod and test, respectively) not work? I didn't find any info on what happens when you pass a path like /prod/site as well as a domain.

Is there a before/after comparison of how the website fetches its resources?

Does it improve pagespeed, and if so how much?

Hardcoding the domain like this unfortunately won't work for our test environment https://test.w3champions.com. Even though pagespeed is not important for test, I think it's good to try and keep test and prod as similar as possible.

[Rotzbua]

Does the current preconnect + dns-prefetch on the BASE_URL (which is https://w3champions.wc3.tools/prod/site and https://w3champions.wc3.tools/test/site for prod and test, respectively) not work? I didn't find any info on what happens when you pass a path like /prod/site as well as a domain.

preconnect and dns-prefetch expects a domain.

CanIuse: tl;dr: Firefox does not support both properly (yet?). https://caniuse.com/link-rel-dns-prefetch https://caniuse.com/link-rel-preconnect

Specification by whatwg: https://html.spec.whatwg.org/#link-type-dns-prefetch https://html.spec.whatwg.org/#link-type-preconnect

Is there a before/after comparison of how the website fetches its resources? Does it improve pagespeed, and if so how much?

Example: Request URL: https://website-backend.w3champions.com/api/matches/ongoing?offset=0&gateway=20&pageSize=200&gameMode=1&map=Overall&sort=startTimeDescending

Chrome dev -> Network -> select request -> Timing:

The delay of 40ms for the connection can be avoided. In the waterfall diagram it is moved forward and processed in parallel. In this case the DNS lookup is just 7us because it was cached by the system.

With lighthouse / https://pagespeed.web.dev/ it would the effect would be recognizable by a lower LCP (Largest Contentful Paint).

The performance improvement is just for first time visitors and the improvement is by avoiding potential blocking time than in real time saving.

More to read: https://web.dev/preconnect-and-dns-prefetch/

Hardcoding the domain like this unfortunately won't work for our test environment https://test.w3champions.com. Even though pagespeed is not important for test, I think it's good to try and keep test and prod as similar as possible.

The env.js contains the configuration and is not used while compile time. I guess it is done to change the app configuration without recompiling but leads to this problem.

[gustav87]

env.is is not used at compile time, but https://w3champions.wc3.tools/prod/site and https://w3champions.wc3.tools/test/site is entered in our build process, as you can see here:

[gustav87]

I don't see why the current preconnect wouldn't work. Is it simply missing the crossorigin attribute? I'm also having a lot of trouble seeing the benefit in the chrome dev tools. I don't see Facebook using any preconnect attributes. For me, it's all a bit too vague at the moment to merge.