October 6th, 2019

Lordy, that’s good! webpagetest.org/video/compare.…

What’s your font loading strategy? I have similar times to you, but they would be even faster if the browser wasn’t waiting for the font CSS to load before rendering.

Looks like preloaded self-hosted fonts. Quite fast. You can async your less critical css to get the browser to render without it being loaded. Or, a new way, load the non-critical css with a link tag in body. That will render flush before block-loading

For clearleft.com the font-loading strategy is to self-host woff2 with link rel="preload" as="font" in the HTML and font-display: fallback in the CSS. For adactio.com the font-loading strategy is to not use web fonts. 🙂 adactio.com/notes/15938

For clearleft.com the font-loading strategy is to self-host woff2 with link rel="preload" as="font" in the HTML and font-display: fallback in the CSS. For adactio.com the font-loading strategy is to not use web fonts. 🙂 adactio.com/notes/15938

I tried the clearleft solution and it was causing FOIT after load. Does it require a polyfill for preload you prevent that?

Are you sure you had font-display in there? Fallback or optional would be good values to try

Look at using fontfaceobserver- I’ve found that so far to be the best balance of speed and lack of unneeded repaints (looking at you Chrome)

I did that now. I’m seeing this on older, lower powered devices.

I’m using document.fonts.load() to add a class after the font loads. I shouldn’t be seeing what I’m seeing… hmm.

Did you use font-display? developer.mozilla.org/en-US/docs/Web… I’d be happy to look at your page to see what can be done