1419848 - webfont loading with <link rel=preload ...> appears not to work on https://clearleft.com/

Status: RESOLVED DUPLICATE of bug 1626997

(Core :: DOM: Core & HTML, defect, P2)

Description

[Jonathan Kew [:jfkthame]]

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?)

Comment 1

[Jonathan Kew [:jfkthame]]

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?

Comment 2

[Dragana Damjanovic [:dragana]]

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?

Comment 3

[Jonathan Kew [:jfkthame]]

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.

Comment 4

[Jonathan Kew [:jfkthame]]

(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?

Comment 5

[Dragana Damjanovic [:dragana]]

(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)?

Comment 6

[Firefox Bug Husbandry Bot]

See bug 1547409. Moving webcompat whiteboard tags to project flags.

Comment 7

[Wellington Torrejais da Silva]

Hi, Just dropping here other example: https://bac.hotsoft.com.br/
I'm using preload and other link tricks.

The load process is very different than the other browser engines.

Thanks!

Comment 8

[Honza Bambas (:mayhemer)]

I believe this will be fixed with enabling network.preload by default now, on Nightly; modulo bug 1637671.

(In reply to Wellington Torrejais da Silva from comment #7)

Hi, Just dropping here other example: https://bac.hotsoft.com.br/
I'm using preload and other link tricks.

The load process is very different than the other browser engines.

Thanks!

It's been 4 months; I can't see any major difference in how Chrome and Firefox Nightly (both with and without preload) renders the site. More specific explanation of unexpected symptoms would help. I don't FOUT.

This can likely be duplicated to bug 1626997.