45 comments

[ 5.1 ms ] story [ 104 ms ] thread
This article is a little bit outdated; should probably add "(2016)" to the title. These days you can use "font-display: fallback" and that's a fairly reasonable trade-off between all the various things:

1. Wait very briefly (100ms) for the font to load, don't render anything yet.

2. If the font hasn't loaded then use a system font and render the page visibly, keep loading the font for another 3 seconds.

3. Substitute the font once it's loaded, or just continue with the system font if it's not.

If the webfont is small enough (~16k on my site, times three for italics and bold, ~50k in total) then this works quite well even on slower 2G connections.

One thing I also do is remove unused codepoints, which can reduce the size quite a bit. In my case, it reduced the size from ~150k to ~50k. I have a little script that just scans all text files in a directory and removes and codepoints that don't exist: https://github.com/arp242/ttftrim

>this works quite well

if you consider swapping a font and potentially the layout after the viewer has already started reading the intial load as working quite well, then we definitely have different definitions. the only thing more annoying would be if the layout changed because you threw an ad at me after intial layout

Personally I'm not annoyed if it's only in the first couple seconds. And on only the first page load.

But these days font-display: optional works just about everywhere too.

Also on firefox you can configure the 3 seconds to be something else.

For a lot of visitors the page will just render fine in the 100ms, and 3 seconds is a reasonable timeout (it should never change the layout after that). Orienting yourself on the site before actually reading anything takes ~3s anyway, so it shouldn't change fonts in the middle of reading a paragraph.

You can also configure this timeouts in your browser (hidden settings, but that's how it is these days) if you really don't like it.

if you think not showing anything until a font loads is acceptable then I guess you and I just have nothing in common!
of course not. before you show any text, you have to download and display all of the ads first silly.
(comment deleted)
You can dodge a surprising amount of loading time and design cruft by blocking the Google fonts static loading domain.
(comment deleted)
I wonder how much bandwidth could be saved if Chrome just included Googles most common fonts. The way a single fonts.googleapis.com url can include varying families and sizes makes caching somewhat more difficult.

And to the author, if I was traveling and on low bandwith networks I'd probably just block all fonts, not sure how effective or what might break but its gotta be better than nothing.

I am not sure why this has become a browser function: Your browser is perfectly capable of using fonts on your local system. The problem is websites are refusing to use them in favor of loading them from the cloud.

At least in the website I adjusted the fonts of, I set it to use the font locally if you had it, otherwise distributing it selfhosted style so not to send data to another service.

Doesn't the set of available system fonts contribute a lot towards fingerprinting?
Yes. Although I don't know if it's an issue on phones/tablets or not.

Also Firefox has an option to ignore CSS specified fonts.

If Google shipped the entirety of their webfonts in Chrome, it would cause everyone to have them.
I'm seeing some unloaded font in the bullet points at the top of the page. So talking about web fonts not loading on 2G is particularly amusing.
That's a joke, it's intentionally missing to make the point.
- phantom underlines. isn't this amaaaaaazing. - i love waiting for 8 seconds and seeing this. - look at it. srsly. looooookat it.
And for users this is solved by disabling webfonts and forcing your chosen system font on all pages.

It's even an option in Firefox. And not something that's hidden in about:config. one of the benefits of Firefox over Chrome.

Only thing that breaks is when developers abuse fonts to display random icons in non-standard ways (other than unicode symbols/emoji/...).

> And for users this is solved by disabling webfonts and forcing your chosen system font on all pages.

Overriding everything to font-display: optional also forcefully solves the problem but with much less collateral damage.

"Damage"

In many cases, I just want to read it.

Discussions like this sometimes make me wonder what the value really is. Of course, it is hard to know. For everyone like me, there are others who lose value when presentation is too coarse.

And don't get me wrong. I love well presented material, type, layout all done well. These things do matter. Same with visuals, graphs, animations...

I am not sure damage is the right word.

Less "wonkiness caused by things working differently than intended by the designer and being in a possibly untested configuration", then?
Maybe.

Pain seems apt. Just wanted to share perspective.

Heh, I wonder if there has been an Overton window shift here.

You're making me wonder if having an option to load pages in "readability mode" by default might be a way to go, going forward. That should work great for the majority of content linked from HN at any rate.

The advantage is that you get one consistent view of the web tailored to your preferences. (putting the user back in control, like in early browsers in the 90s).

Maybe! That resonates with me.

I am inclined to give that a try myself. Maybe simulate it with a quick hack, or just enter the mode on some new links as I encounter them to see how it feels.

Here's a similar discussion:

The move to standardize one space after period at end of sentence.

I hate it. Many others love it, and I sometimes wonder at just how differently we appear to value things.

Input on mobile is a mess because there is no longer any way to differentiate between a period marking an abbreviation and one at end of sentence.

The autocorrect function, intended to help with touch input is a mess now too.

And when I use Voice input, I get a lot of randomly capitalized Words because of how this has played out. When I reset my mobile dictionary, that goes away, but so does all the benefit of the "learned words" function.

To me, that seems more like real damage.

Yet when I go to discuss this with people, I get a similar response to what we saw here. Your Overton Window point resonates!

And I'm only making this one to just kind of illustrate the minor struggle in these kinds of things, and that there are a lot of these little Struggles kind of just dragging us down on many fronts, and I don't think we notice all of them.

Safari (all versions) lets you set domains to load in readability mode. 'Auto Reader View' extension adds the same thing to Firefox.

It looks like Safari for Mac can make readability mode the default for all sites, if you go into Preferences > Websites > Reader and set "When visiting other websites" to On.

https://addons.mozilla.org/en-US/firefox/addon/auto-reader-v...

Interesting, I guess that works when font-family has only webfont and no fallback?

While you're at it, do you have any tips for disabling all font-weights < 400 and force them to 400? :)

Something like:

    min-font-weight: 400 !important;
And I'll be one very happy web user.

I'm forced to do it with a userscript currently, which is less than optimal.

Yeah. I use web browsers to read text. My system has perfectly good fonts available. There's no need to go around downloading new (usually less readable) ones.
In order to save my users’ bandwidth, I only use web fonts at the lightest weights, usually < 300.
Jokes aside, I would be amazed if there is any correlation between the font "weight" and the compressed font size.
Totally.

Usually all weights have the equivalent nodes and curves in their bezier paths, so that intermediate weights can be interpolated between masters. The only delta in size you would get is if the joining/flattening of these paths resulted in different nodes in the exported fonts. As different weights typically include the same open type feature code and glyph set, I’m not sure anything else would cause much variation in size.

I assume it depends on your audience, and that in some mobile-heavy use cases 200 might be a better upper bound?
I'd like to question 12 MB JS-framework-that-everyone-bandwagoned-because-everyone-else-thinks-its-hip before we ever touch webfonts. Webfonts atleast provide a sense of utility - athough now that I think of it - typography is horribly misused and abused by designers. If your headline takes 40% of the screen with a giant 96 pt typeface and the bottom 20% is taken up by a cookie banner, you need help.
If you care about first load time, then the web font will have a significant impact. However there are no "web safe fonts" eg. fonts that exist on The top 95% most common systems. You can choose between sans-serif or serif (non fancy, or fancy), and monospace... but you can't really know what font your web page will be displayed in, so better use font-settings (size, etc) that works for most fonts. Never assume an element will have a static with. 800x600 used to be the standard, but now with so many devices the width of the page can be anything... What I usually do is resize the window width using the mouse back and forth, as well as zooming in and out, to see if there are nay issues anywhere, like things looking bad. Assuming the user can use anything from a smartwatch to an 80 inch wide TV.
(comment deleted)
it's not just fonts.

I wish more devs/designers/managers/whatever realized how many people access the internet either on a slow connection or a slow device or both. even in the first world, most areas outside of city limits is spotty 3G territory.

also, nobody gives a fuck about all the fancy bullshit. how many top websites look like something from awwwards?

I think it would be hell to be assigned to handle font rendering if I worked on a browser. I hope the people that are responsible for it enjoy their jobs, otherwise my condolences, it seems like a thankless task.
Something I implemented recently is using rel="preload" to start getting font files before the css file asks for them. Definitely made a difference for me.
I probably fall into the minority category where I really wish custom fonts would go away in the browser. I've never seen a website where a custom font added any value over what ships with the OS.
I haven't missed them, that's for sure. I've been blocking custom fonts (and only allowing whitelisted JS) with uBlock for a very long time. It's insane how bloated, janky, and slow things have become.
Just use "body { font-family: sans-serif; }" and call it a day. Is it really that hard? Who do web fonts benefit, anyway?