Coverage report

This PR does not seem to contain any modification to coverable code.

I've been looking at this. Have a few questions, writing them up as a review comment.

Getting the same warnings as @thekaveman on Mac OS/Firefox and Mac OS/Chrome:

Safari, renders the same (fallback font) but no error/warning message in console.

Thanks for the comments @machikoyasuda and @thekaveman!

I re-tested using macOS/Firefox, macOS/Chrome, and macOS/Safari and found a few things (in addition to the crossorigin="anonymous" attribute) that I had overlooked. Here's a summary of the changes:

• Replaced type="text/css" with as="font" following the optimization docs in 2b25225. Previously, I had mistakenly kept both attributes.
• Moved the Google font url from the CSP style-src directive to a (new) font-src directive in 9ae7973 (since the Roboto font tag changed from a text/css type to a font type) to avoid this issue reported by Chrome and Safari (not sure why Firefox didn't show an issue):
  
• All 3 browsers reported this same issue (The resource https://fonts.googleapis.com/css?family=Roboto:400,500,700&display=swap was preloaded using link preload but not used within a few seconds from the window's load event.) but the description in Chrome was the most specific:
  
  Maybe this means that currently we aren't benefiting too much from preload, but I would guess it's still a good optimization to have.

I'm looking at the MDN docs for rel="preload", and specifically What types of content can be preloaded?:

• font: Font file.
• ...
• ...

Note: font... preloading requires the crossorigin attribute to be set; see CORS-enabled fetches below.

• Replaced type="text/css" with as="font" following the optimization docs in 2b25225. Previously, I had mistakenly kept both attributes.

https://fonts.googleapis.com/css?family=Roboto:400,500,700&display=swap is a CSS file that loads font files, so I don't think using as="font" is correct.

The documentation linked by #2492 is pretty general and assumes you're loading actual font files.

I found some resources more specific to loading resources from the Google Fonts API, which is what we're doing to load Roboto.

• https://stackoverflow.com/questions/50824181/preloading-google-fonts
• https://www.cdnplanet.com/blog/faster-google-webfonts-preconnect

I think it could help to look at the network waterfall chart in the devtools before and after making changes to see if changes are working as intended.

Thanks @angela-tran!
That's a good point about the as attribute. Reading this mdn doc I thought that setting as="font" was appropriate (since it mentions it applies to CSS @font-face) but I agree with you, other docs such as this web.dev doc show that as="font" is meant for preloading font files, not CSS. Also, setting as="style" has the added benefit that I don't need to make any changes to our Django-CSP configuration 🙂 and I think that's a cleaner solution.

I'm still looking at this because even though the GET Google font was successful (I can see it in the Network tab of devtools), the page isn't rendering with Roboto, it's falling back to the System font. However, if I implement this:

<link rel="preload" as="style" href="https://fonts.googleapis.com/css?family=Roboto:400,500,700&display=swap" crossorigin="anonymous">
<link href="https://fonts.googleapis.com/css?family=Roboto:400,500,700&display=swap" rel="stylesheet" type="text/css">

the page renders using Roboto. I just want to make sure that having both <link> tags is correct, it's just that from the documentation I had the impression that only the first <link> tag was needed.

I just want to make sure that having both <link> tags is correct

We should only need a single tag here right? This doesn't make sense to me.

I just want to make sure that having both <link> tags is correct

We should only need a single tag here right? This doesn't make sense to me.

The first link tells the preload scanner about the resource but doesn't actually download it yet. From MDN docs on preload:

Even though the name contains the term load, it doesn't load and execute the script but only schedules it to be downloaded and cached with a higher priority.

The second link actually causes the download of the resource.

Doh, thank you @angela-tran 🙏

@lalver1 What you're seeing makes sense with the docs on preload and also with these two StackOverflow answers to the question I linked in #2639 (comment) :

• https://stackoverflow.com/a/62219966
• https://stackoverflow.com/a/56845961

After more testing (running scenarios 10 times and calculating the median) and reading more about the difference between preconnect and preload, I decided to make some changes to how I initially implemented this performance improvement.

In summary, we now warm up the connection to the Roboto web font using preconnect and still use display=swap to display the content immediately without waiting for the web font to download:

<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin="anonymous">
<link href="https://fonts.googleapis.com/css?family=Roboto:400,500,700&display=swap"
rel="stylesheet" type="text/css">

The Largest Contentful Paint (LCP) (sec) is 0.13 and we see no warnings in the browser's console.

There are several reasons (informed by article 1, and article 2) why I ended up going this route:

• The Google Fonts HTML snippet uses preconnect (I made slight modifications to not use their v2 API update)
  

• I noticed that the LCP was actually worse using preload:

<link rel="preload" as="style" href="https://fonts.googleapis.com/css?family=Roboto:400,500,700&display=swap" crossorigin="anonymous">
<link href="https://fonts.googleapis.com/css?family=Roboto:400,500,700&display=swap" rel="stylesheet" type="text/css">

LCP (sec): 0.17

• Both Chrome and Firefox reported several warnings when using preload
  
  

• The Google font stylesheet is loaded twice when using preload (although it seems that concurrently)
  

My only remaining concern is that Chrome's Lighthouse analysis gives main a score of 97 and this branch a score of 91. But this contradicts what I am seeing using other metrics