Email from Jet: > I'm seeing FOUT on https://clearleft.com/ that seems to indicate that stylesheets are loaded but fonts are not. Looks OK on Chromium. I can confirm that I see FOUT on this site (when it's not already in cache). Offhand, I don't see anything about the preload links on the page that should prevent them working. Dragana, can you take a look? (Possibly unrelated, but I can't tell any difference in behavior whether network.preload is set to 'true' or 'false'. Does that pref actually have any effect?)

Interestingly, if I set layout.css.servo.enabled to 'false', the FOUT no longer occurs. Does this mean that switching to stylo is somehow regressing <link rel=preload> behavior? (Or does it mean that with stylo, we're now styling the content so fast that the fonts haven't yet loaded despite the preload request?) Looking at the Network tab in developer tools, it appears that the requests for the (supposedly preloaded) fonts are ending up behind a lot of images used by the page; is this the expected behavior, or should those early <link rel=preload> requests be given higher priority?

Preload is disabled. I do not much about stylo code. Is it not properly disabled when stylo is used? Preload should not influence page load except if there is a something listening for 'onload' events from <link rel=preload> element. Something like bug 1405761. Bug 1405761 will appear only if preload is not properly disabled with stylo. But bug 1405761 does not appear again with stylo. so here we have another problem. What is 'FOUT' where I can see it?

Sorry, "FOUT" is jargon for "flash of unstyled text", meaning that the content appears for a moment with a fallback font, before the webfont is available and it gets repainted with the intended font. (This only happens on the https://clearleft.com/ site when it is loaded with the cache empty; on normal reloading, or returning after having visited it recently, the font files are cached and the flash doesn't happen.) The site is using <link rel="preload" as="font" type="font/woff2" href="/assets/fonts/adellesans-regular-webfont.woff2" crossorigin> <link rel="preload" as="font" type="font/woff2" href="/assets/fonts/gilroy-black-webfont.woff2" crossorigin> to try and avoid this, by asking the browser to load the font resources early, so that they'll be ready by the time the initial paint happens.

(In reply to Dragana Damjanovic [:dragana] from comment #2) > Preload is disabled. I see that network.preload is false by default; if I toggle it to true, should that make preload start working, or is something else required? I don't see any difference in behavior, AFAICT. Or is that pref not related to <link rel=preload> handling?

(In reply to Jonathan Kew (:jfkthame) from comment #4) > (In reply to Dragana Damjanovic [:dragana] from comment #2) > > Preload is disabled. > > I see that network.preload is false by default; if I toggle it to true, > should that make preload start working, or is something else required? I > don't see any difference in behavior, AFAICT. Or is that pref not related to > <link rel=preload> handling? the pref should turn <link rel=preload> on, but it is disabled for a couple of reasons (bug 1394778 - for no-cachable resources it will not work (I think I have seen that this resources are cacheable, so this is not the problem here) and bug 1393540 (this is maybe problem here that speculative load is triggered before preload, i.g. images are fetched earlier. Because of this bug I think we will implement preload in a different way.)). Is it working better with servo=false preload=true than (servo=false preload=false) or (servo=true preload=false/true)?