Cache-busting for kit files and font links with preload attribute generates a FOUT.

[artqvo]

Quick, short summary:

I wanted to tell you about a problem I have encountered with the cache-busting option for kit files.

It has to do with some fonts that I preload. Enabling the cache-busting option also adds a hash to these links and that generates a warning in the console (which does not appear when it is not activated), but it also affects the stability of the layout, something that is especially noticeable in the header with the main menu.

Expected results:

Without activating it, when clicking (it is a «Jamstack» website, just html, css, and js files without any js framework) the loading is fast enough to give the feeling that it is a SPA, the top menu layout and elements remains completely stable between page loads.

Actual results:

However when activating the cache-bust (that add the hash to the fonts links) it seems that the font preload stops working or does it incorrectly and then there is an obvious glitch due to a FOUT. With which I am forced not to use the cache-bust, as it is very evident every time the user navigates through the main menu, regardless of the connection speed.

Exact steps to reproduce:

Add a font link in the header of the html page with the rel attribute as preload and enable cache-busting for .kit files. For example:

<link rel="preload" as="font" crossorigin type="font/woff2" href="/fonts/my-custom-font.woff2">

It would be interesting to have some configurable parameters in relation to the cache-bust as for example to be able to mark if you want to apply it to the links that load fonts or not, especially if they go with preload.

[bdkjones]

A longer-term strategy for dealing with all types of preload assets is probably still a good idea, but fonts are a bit unique because a cache miss will cause a style-jump on page load. I've updated the cache buster to skip .woff and .woff2 URIs. That'll go live in the next release.