If browsers were slightly better at asking users, maybe we'd all have our three favourite fonts and background-, text- and link-colours instead of what someone else prefers we stare at all day.
> If not inlined, subresources can fail to load for all kinds of network reasons.
Also, it's commonly recommended to load fonts asynchronously/deferred without blocking the main page render. But I HATE it when the page jumps around as it cycles through different fonts before the real one loads. I'd rather get dinged on PageSpeed insights with "Requests are blocking the page's initial render, which may delay LCP. Deferring or inlining can move these network requests out of the critical path." rather than have everything popping about for the first second. Is it just me?
This drove me crazy on one of my (very lightweight) static sites... even on incredibly fast connections you'd always see that FOUT. I managed to solve it with font-display: fallback.
I also had to make sure I was preloading my fonts properly... not sure if this is the same guide I followed, but it's close. The only difference is that I swapped that "&display=swap" to "&display=fallback":
These days you can have an LLM code you up python to custom match visual metrics from your preferred web fonts to the likely user fonts across your statistical user base.
What the hell.
Just now I learned of "font-family: monospace, monospace" hack. Indeed, browsers will render the font smaller with just one "monospace".
I've never run into it before because setting explicit font-size in pt or px avoids that weirdness.
So basically just use monospace, serif, or sans-serif because you can't 100% be sure it'll render correctly?
Fuck that. I don’t want my website to look ugly because 99.9% of users don’t bother to change the defaults.
If browsers were slightly better at asking users, maybe we'd all have our three favourite fonts and background-, text- and link-colours instead of what someone else prefers we stare at all day.
This is not at all what the article recommends. I recommend actually reading it.
> 3. Strongly consider using only a generic family
Seems clear enough.
> If not inlined, subresources can fail to load for all kinds of network reasons.
Also, it's commonly recommended to load fonts asynchronously/deferred without blocking the main page render. But I HATE it when the page jumps around as it cycles through different fonts before the real one loads. I'd rather get dinged on PageSpeed insights with "Requests are blocking the page's initial render, which may delay LCP. Deferring or inlining can move these network requests out of the critical path." rather than have everything popping about for the first second. Is it just me?
This drove me crazy on one of my (very lightweight) static sites... even on incredibly fast connections you'd always see that FOUT. I managed to solve it with font-display: fallback.
https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/A...
I also had to make sure I was preloading my fonts properly... not sure if this is the same guide I followed, but it's close. The only difference is that I swapped that "&display=swap" to "&display=fallback":
https://dev.to/pilcrowonpaper/preloading-google-fonts-37h1
> FOUT
https://en.wikipedia.org/wiki/Flash_of_unstyled_content
Def not just you!
These days you can have an LLM code you up python to custom match visual metrics from your preferred web fonts to the likely user fonts across your statistical user base.
But why?