Just use the built-in fonts. Use a good fallback list so each platform gets a good option. Specifying custom fonts is largely a waste of bandwidth for a very marginal improvement in aesthetic. The people who care most are the ones making the decision to use that font. The solution, tritely, is they should stop caring about the little details that much.
The bigger details are usually what move the needle. Don't get stuck optimizing a local maxima, which is very easy to do if you're using AB tests. Arguably the point of an AB test is to find the local maxima, but the goal should be to broaden the search space and look for something closer to the global maxima.
There seems to be a reply like this at the top of every font-related thread on HN. I often wonder whether it's coming from designer/developers or from end users.
Web fonts aren't popular just because they're pretty. They continue to be used everywhere because they offer a consistency that's impossible to get otherwise. With a plethora of mobile devices and desktop environments, you can't get a consistent look-and-feel for a site with just installed fonts. For some really basic sites, that's totally okay and even hits a nice quaint aesthetic, but for the kinds of sites that people pay money for, that's not good enough.
Variability in system fonts means that getting consistent paragraph and header widths and spacing is impossible. It means that the text looks too dark sometimes and too light other times. It means that the font appears unreadably small sometimes and obnoxiously large other times. It means having to build a font stack and then keep it updated as preinstalled fonts change. It means spending a lot of time dealing with issues like Helvetica Neue looking okay on MacOS but rendering like ass on somebody else's desktop because they installed a free knock-off of it. It ultimately introduces a lot more complexity and fragility than properly using a locally-hosted web font.
You said it yourself: Users are viewing your site on devices with totally different screen sizes, different resolutions, on different platforms, with displays of varying brightnesses, glare, viewing angles, color spaces, and in environments of varying levels of lighting. Given these constraints, it's not possible to get a consistent look-and-feel.
So don't waste resources trying. You'll create more problems than you'll solve.
Nobody tests their web fonts as thoroughly as the default fonts have been tested on their respective platforms and devices. Web fonts can have odd platform-specific bugs with kerning, hinting, and subpixel rendering. I've had web fonts render without hinting on Edge, but look fine on Chrome & IE on the same system. How does one even begin to write automated tests that detect issues like that? Using the default fonts guarantees you'll never have to worry about such bugs.
The system's installed fonts are guaranteed to work. They improve performance. They prevent re-flows. And they're what the user is accustomed to. These reasons and more are why Facebook, Github, Twitter, Wordpress, and many others use the system fonts.
Web font bugs show up in the weirdest places. Unless you're constantly vigilant and manually test across all the platforms you want to support, some users will see crappy fonts. Hardly anybody goes looking for these bugs, so the bad fonts can be shipped in production for years without anybody at the company noticing. This is what has happened at Apple, Wired, and Medium.
Not that consistency is worth striving for. There's not much consistent about what you can show on both a 6" 4K OLED and a 15" 1366x768 TFT LCD. Certain fonts will look great on the former and be borderline-unreadable on the latter.
The first one is, just like it says, a bug, and apparently a bug that Apple fixed on their website. The second one is Wired using a terrible web font. Neither the possibility of having fixable bugs nor the option of choosing a terrible font strike me as particularly strong arguments against web fonts. You are already free to use system fonts at terrible sizes or contrast ratios, and many sites definitely do that.
I'm the author of that Medium article. The "second one" you referred to isn't the second bug I reported – it's just an aside on Wired's crazy headline font. They've since replaced it with a normal readable font...
I feel like we need some clarification about what "consistent" means here. If we're talking about having the typography shown to user A look exactly the same as that shown to user B, why does that matter? (And why do the major font rendering differences between Windows and macOS not matter?)
If we're talking about having the typography on user A's phone look the same as on user A's desktop, that seems a bit more reasonable, but the rest of the UI is necessarily going to be drastically different save for perhaps the color scheme.
Or is the "consistency" that matters here about making sure the website is pervasively using the same typography as the advertisements?
> If we're talking about having the typography shown to user A look exactly the same as that shown to user B, why does that matter?
Well, I suppose that's a valid question, but it's moving the goalposts. We were talking about having consistent fonts, and I'm claiming it's absolutely possible by using web fonts (after all, that's the reason web fonts exist).
> So don't waste resources trying. You'll create more problems than you'll solve.
This doesn't follow. It's an argument for "put black text on a white background and call it a day because this is too hard". People don't pay money for that.
Web fonts solve an entire class of problems unrelated to whether the user is standing in the sunshine or not.
> Nobody tests their web fonts as thoroughly as the default fonts have been tested on their respective platforms and devices.
This is wrong in fact, given that the most popular fonts are coming from big design houses that probably know more about the details of font rendering than I'll ever know about any subject [1]. It's also wrong in principle because exactly zero people get paid to test platform-default fonts for my application or website. That leaves it up to the developer to test the site on every platform under the sun and moon and, even when they do that, they still have users with goofy font installations that make it look bad or unusable.
> Using the default fonts guarantees you'll never have to worry about such bugs.
Again: it doesn't, because when you do this, you're using whatever fonts are installed on the user's system, and there are a lot of people running around with crappy knock-off fonts installed. Using the default fonts guarantees that this is an issue.
And where are these people coming from that care about inconsistent subpixel rendering in web fonts but don't care about inconsistent layouts from using whatever bag of fonts they happen to have on their system at the time?
> The system's installed fonts are guaranteed to work.
Allow me to repeat myself: a "Consolas" font on one system is not the same as a "Consolas" font on another system. There are no guarantees when relying on a system's default fonts, and that's why web fonts are popular.
> ...Wordpress, and many others use the system fonts.
It's a shame you included this example, because it opens a big door for me.
Let's look at the style.css file for Wordpress's default "twentytwenty" theme [2]. It includes a gnarly font hack near the top along with the following comment:
> Chrome renders extra-wide characters for the Hoefler Text font. This results in a jumping cursor when typing in both the classic editor and block editor. The following font-face override fixes the issue by manually inserting a custom font that includes just a Hoefler Text space replacement
...and right below that it includes two web fonts.
Their twentynineteen theme includes the same hack but no other web fonts.
15 out of the 20 most popular Wordpress themes include web fonts (not counting FontAwesome or other symbols-and-icons fonts). I checked.
Facebook, Github, and Twitter operate at scales that are not relevant to most of the engineers on HN. They are motivated to spend engineering budgets on performance and they're willing to forsake things like typographic consistency if it saves them having to pay for another data center.
The first not-Facebook-scale example you cited is full of web fonts.
> There are no guarantees when relying on a system's default fonts, and that's why web fonts are popular.
Technically true but misleading. There are no guarantees when including custom web fonts on a web page, either. It's the web! No matter how much fancy CSS/JS wizardry you throw in there, it's ultimately up to my browser to put the bits on the screen.
I guarantee most web designers didn't test with any of my 3 main web browser configurations, because a good portion of the time I can't even read the text through their CSS.
Earlier, you pondered:
> There seems to be a reply like this at the top of every font-related thread on HN. I often wonder whether it's coming from designer/developers or from end users.
It's amazing how many designers screw up web fonts -- maybe that's why avoiding them is also so popular.
I was talking about wordpress.com, not Wordpress blog themes or wordpress.org. Of course the themes are going to go wild and use every possible browser API to customize their appearance. That doesn't mean it's a good idea.
I'm surprised you're talking about knock-off fonts, because I think it argues against your position. The portion of users who have installed crappy knock-off fonts is far smaller than the portion of users on slow internet connections (such mobile users), or the users annoyed by the re-flow, or those who run into bugs in the web fonts themselves. Apple, Wired, and Medium have all shipped web fonts that look like garbage on Windows.[1] They didn't notice these bugs for years because they simply don't test on Windows.
So web fonts cause more annoyances and bugs for the majority of users to slightly improve the experience of a tiny fraction of users who have misconfigured their systems. Do you also write code that defends against buggy browser extensions? At some point you have to accept that the user is responsible for their own device. I'm fine admitting that if a user has the gumption to install custom fonts, they also need to be knowledgeable enough to choose good ones.
It's coming from users, of course. If you give a designer a knob, they will tweak it.
End users don't care if they get Arial, Helvetica, Helvetica Neue or system sans-serif -- except in the case where they set it up themselves, and they're rather upset that you aren't using their preferred versions. But that's OK too, because those end users are almost as rare as designers.
All the inconsistency problems you're noting are of your own devising.
> They continue to be used everywhere because they offer a consistency that's impossible to get otherwise.
That sounds backwards to me. Using standard fonts is how you achieve consistency. Using a custom font for just your webpage is not helping me (the user) get consistency at all. That's what 'standard' means.
(Frequently, custom fonts also hurt readability, which is why I hit "reader mode" on nearly every webpage these days. Every single day I run across webpages with custom fonts that I literally struggle to read.)
The situation is just like early versions of Mozilla or Java, where they used the same UI toolkit on all platforms for "consistency". Eventually, programmers realized that users tend to switch between applications more often than they switch operating systems, so the way to achieve consistency for actual users is to match the local environment.
> Variability in system fonts means [...]
Yes, all of those are real problems. That's why I've set up my web browser in a way that results in legible text for me. As per the Pottery Barn Rule, if you use a custom font, you're taking responsibility for all of these issues -- and you're going to screw up at least some of them (or something you didn't think of), and I'll hate your webpage for it.
>Every single day I run across webpages with custom fonts that I literally struggle to read.
Have you considered turning off custom fonts? Firefox lets you do this -- Preferences > General > Fonts and Colors section > Advanced > [ ] Allow pages to choose their own fonts.
I did months ago and it has only improved the web for me. The sole exception is people abusing fonts for icons. But that is thankfully not very common.
> Using standard fonts is how you achieve consistency.
If my web page downloads a font to a browser for that browser to use, every browser capable of downloading that font will use that font.
If my web page specifies a list of fonts that users may or may not have on their system, every browser may display a different font from that list (or even a font not from that list).
I suppose YMMV and all that, but I would say the first case is clearly giving a more consistent result than the second case. That doesn't make the second case "bad," per se, but on my system Hacker News is in Verdana and on different distributions of Linux it's in... shrug emoji? There's a Microsoft Core Fonts package floating around out there, but not everybody has it installed. And lately it's become fashionable to specify a font stack of "default system fonts," so Macs get San Francisco, Windows 7+ users get Segoe UI, etc. That's fine, and maybe it's exactly what you want... but don't call it "consistent."
I almost guarantee you have fonts on your system installed that you will not want me to use on a web page, and I can also almost guarantee you that there are a lot of pages out there that have "custom fonts" that are just fine. They're just fine! Nobody reads a web page set in Charter or Franklin Gothic or any other rational typeface for body text and screams in outrage at its illegibility.
Maybe there are designers out there who want to force terrible horrible no-good custom fonts down your throat because they want to make your reading experience worse. Maybe there are web pages set in Zapfino and Wingdings. I don't know. But when you say "custom fonts," I say "professional high-quality typeface that is consistent across all browsers." That's it. That's all I'm trying to give you.
I'm a designer and I'm very pro system fonts. Then again I don't work for a company with a typography-related identity like NYT or WSJ. For them it's a lot more important, at least in theory.
But if you make like, a productivity tool or some sort of SAAS? just use system fonts.
Edit: then again, I say this as a designer who has worked a lot in companies with heavy emphasis on accessibility and performance, so that may be a bit of my own bias...
> Variability in system fonts means that getting consistent paragraph and header widths and spacing is impossible.
Everyone is on different screen types. From desktop to mobile, different OS, low to high DPI, different resolutions to screen size (1080p on 21in monitor vs 27in monitor), different font sizes, different brightness/colors/contrasts. Most designers I have worked with have never looked at the site on different kinds of screens. Most designers only care about how it looks on mac.
Windows render font differently compare to Mac/Android. Chrome on windows renders font differently compare to Firefox.
You will never be able to render your site perfectly on all the devices.
As an end user, I don't care about your web fonts, and I suspect others think the same. Usually designers push for them with concerns of brand image and consistency between platforms. I couldn't care less that I get a different font on Linux than what you design for on your Mac.
On the other hand, I care about the loading time of web sites and the privacy issues brought by the pervasive use of Google Fonts.
I agree entirely; the clients don't. It's an almost universal question brought up by them during the design phase - "this font looks like everyone else, we want our own". The changes to TypeKit have certainly put a squeeze on their options, but they still almost universally hate the system level fonts. Wish I could convince the business guys to push back, but eh, there are bigger problems we face on a day to day basis.
That might change. Google are changing their search ranking metrics to include the new Core Web Vitals metrics[1]. One of those is "Cumulative Layout Shift", or how much the page changes the layout over time. Using a font that isn't performant will cause the page to render, and then to move around once the page loads, which could push your site down on Google's search results page.
Has anyone ever suggested doing "progressive fonts"? I.e., start the font downloading before the page renders at all; have the font organized so the first thing that's received is the bounding boxes + kerning table + ligatures table (= enough to know how much space an inline flow of graphemes will take up); then load the page, with the page layout already settled, while loading the font itself in the background. Eventually, the text just pops into existence (without disrupting the layout) once the font is available.
Or, if you don't want to make the browser engine understand the intricacies of font formats, just split the font file for each font-family into two new file-subformats, one for layout-description and one for visual-description. Then add a rule to the CSS parser, saying that CSS references to font layout-description files are loaded synchronously (i.e. blocking rendering), while CSS references to font visual-description files are loaded asynchronously (as they always have been.)
This is a great idea. Actually drawing the glyphs can be computationally expensive too. I'm not sure what browsers do, but in the last game I made, it was an enormous win to have a glyph cache for the various combinations of (size,glyph,quantized pixel alignment) rather than rendering each glyph from scratch.
I could imagine quickly getting layout information, then asynchronously getting glyph drawing information and painting from the glyph cache when it becomes available. You could even paint a similar fallback font using the layout information of the real font to avoid redoing layout on the whole page while still being readable until it finishes.
Just HTTP2 Server Pushing a smaller set of fonts will do the job. I have a website with 6 font variants that loads in 200ms. It loads even faster once the fonts are cached.
Couldn’t disagree with this more. Let me share some engineering perspective. Fonts are literally the outlines that allow the vision system to take a 2D shape and convert it to a concept in the limbic system through the semantics of language.
In fact, well engineered fonts are absolutely crucial in any medium, not just electronic. From road signs to tax documents, from web pages to warning labels - fonts are one of the most underrated aspects of graphic design. Why though? Each font has a specific purpose. Mono space fonts are used for things like code and tabulated figures while fonts such as Baskerville excel at prose. There is so much to say, I don’t know what to pick and choose. Honestly, study typography from an engineering take - it is a tool.
Perhaps there is a distaste for gawdy, large and loud typography and all the shenanigans designers do today, but that has nothing to do with why fonts are important.
I think this oversight is highly disappointing because there is bigger fish to fry. Javascript payloads, bloated reactive websites and overall regression in what a great UI should be.
I completely agree. System fonts render Arabic very differently on Windows, on Chrome OS and on Ubuntu, for instance, so differently that you feel you need to adjust the font size depending on the font being used.
> Use a good fallback list so each platform gets a good option. Specifying custom fonts is largely a waste of bandwidth for a very marginal improvement in aesthetic.
If you're content with mediocrity, sure. But if you value your brand you will want the fonts to send the message that you want to be associated with your brand. Also, you'll probably want them to be in line with the rest of the design.
Web fonts are my litmus test for whether I can trust a designer's judgment. Users don't want to see a site's brand in every letter on the page. They want legible text that loads quickly.
The default fonts on Windows, Mac, iOS, and Android are the result of millions of dollars of R&D. Custom fonts are far more likely to have issues with kerning, hinting, or subpixel rendering. They also degrade load times and cause a re-flow when the font is done downloading.
All of these issues can be avoided by using the fonts that are already installed on the user's device. That's what Github, Wordpress, Facebook, and Twitter do. They all have distinct brands without custom fonts.
> Users don't want to see a site's brand in every letter on the page. They want legible text that loads quickly.
The worst cases of this are when a site loads a font that has a few letters re-drawn to match the companies logo, but the font is used as the site's default for body text. That leads to words unrelated to the company's name appearing with pieces of the company logo—very distracting and harmful to legibility.
The system fonts are legible. With web fonts... sometimes they are and sometimes they aren't. And web fonts have that re-flow during page load, which is super annoying when you're reading the first paragraph and lose your place because the web font finally loads and it's a different width than the system font. If that's not an instance of illegibility, I don't know what is.
It's very simple to use font sizes and contrast ratios that are different to read with system fonts too, if you want to do that for some reason. Web fonts aren't unique there. The re-flow is a valid technical problem, and one that ought to be improved.
The default fonts on Windows, Mac, iOS, and Android are the result of millions of dollars of R&D.
For quite some time, Apple was using Helvetica, a typeface that has objectively awful (edit: legibility) properties.
Meanwhile, some of the web fonts you see have had a very large amount of money spent on making them and world class font designers working on them.
So I don't think this argument carries much weight.
Custom fonts are far more likely to have issues with kerning, hinting, or subpixel rendering.
That depends entirely on the quality of the custom font.
As another example, for a long time on Windows you could get strange results with font stacks that used Helvetica/Arial/equivalents, because someone's random printer font would end up taking precedence over the system font you intended and result in your page looking atrocious. If you didn't know that one and used some widely recommended font stacks based on default system fonts, you would get awful results for a significant number of users.
That's what Github, Wordpress, Facebook, and Twitter do. They all have distinct brands without custom fonts.
They all have strong brands without any reference to visual design at all, other than arguably their highly recognisable logos.
However, the other 99.9999% of businesses you'll come across don't. If you're not already a world-famous unicorn brand, a well-designed and consistent look and feel does affect brand recognition and, in some cases, have very practical effects on usability.
> But if you value your brand you will want the fonts to send the message that you want to be associated with your brand.
That's an important point. Unfortunately loading custom fonts slows down the experience and when that happens it does tell me something about the brand.
(It's likely the overhead of loading fonts is drowned out by the overhead of all the trackers, but I have those blocked which speeds the web up enormously. Likely that makes me not the kind of reader you want...so this works out well for both sides).
Unfortunately loading custom fonts slows down the experience
Unless someone has either gone totally overboard on the number of fonts or set their site up very badly, this is largely a non-issue in most markets today.
The total weight of all web fonts on any site/app I've worked on recently was typically less than the largest single image on the home page, and loading those fonts from a well-configured CDN rarely took more than a few tens of milliseconds and happened in parallel with everything else.
Of course you could get a FOUT if you are using an unreliable Internet connection and it drops out at just the wrong time. But then, you could equally well be missing important images or seeing a layout reflow when a stylesheet finally loads in that environment as well.
What an absolutely stupid response to this. Of course, just use something that people would already have, 5head. Let me just ask the designer on my team to stop using anything other than Arial and Times New Roman.
If a typical HN reader had their way, every single webpage on the internet would be text-only, with monospace font, and an RSS feed.
You can make a stack of standard fonts look just fine. I think most of the web would be better off doing that. You can choose the best looking font for Windows, the best one for Mac, and the best looking Linux fonts, and just move along. Your page will load faster, and look more familiar to your users.
you're arguing not to overly optimize and sweat the details, but then prematurely optimizing by recommending against custom fonts.
different fonts give sites different personalities, adding richness to the web (whether you appreciate it or not). for 99.9% of sites, being overly focused on font size/download speed is an unnecessarily trivial optimiztion.
with that said, don't remotely load google fonts because privacy does matter. for most sites, the speed and bandwidth difference doesn't matter. just serve them as first-party, cacheable assets.
The argument in favor of Google Fonts and similar services is that visitors likely already have that font cached from visiting another site that uses the same font. It can also decrease bandwidth costs if that's a bottleneck.
That said, serving from your own domain is a great way to make sure that a third party can't break your fonts, in addition to what you mentioned about privacy.
OP here. Cross-domain caching is a myth[1] so reusing font files won’t work. In fact, it’s literally impossible in Safari[2] and soon to be made impossible in Chrome[3].
Don't get stuck optimizing a local maxima, which is very easy to do if you're using AB tests.
Surely if there is one thing we have learned from the culture of comparative testing in recent years, it is that assumption is the mother of all #$%& ups.
Everyone commenting in this discussion to the effect that all sites should use system default fonts is making a huge assumption that using other fonts does not have a material effect on anything that matters to the user and/or the site owner. And yet, both in industry and in academia, lots of research has been done that did observe changes in outcomes even from relatively subtle (at least to an untrained eye) changes in typography.
If someone wants to argue that they personally do not like web fonts then of course they are free to block them. Any major content blocker on their platform of choice will do this easily enough. But if someone wants to argue that everyone else should avoid web fonts, they had better bring data. In this entire discussion, I don't see much of that, only personal preferences and the odd anecdote about a bug in a specific situation.
For purely aesthetic purposes, this might be a fair point. However, there are many reasons to use custom fonts beyond that. One example is accessibility in a very broad sense. In some circumstances, it reasonable to use a font with more legible type across device types, more support for internationalization (i18n), or better support for uncommon characters (e.g., mathematics).
Another example is alternatives to image assets. Emoji are the common example here, but the private use areas [1] mean that fonts can be used to deliver what would otherwise be raster images or SVGs. A great example is mixing symbols in with text without resorting to images or CSS-via-spans to solve the problem. Think public transit icons, for instance.
"Specifying custom fonts is largely a waste of bandwidth for a very marginal improvement in aesthetic...They should stop caring about the little details that much"
For many websites, the choice of font can make a noticeable difference to the appearance of the site and yes, make it more aesthetically pleasing. Of course, it's best to choose only a minimal number of font weights to keep downloads size to a minimum.
I try to block all the web fonts I encounter. A lot of UI symbols aren't rendered which amusingly sometimes results in overlapping text descriptions. I just can't stand looking at certain fonts or ligatures and refuse to let a website decide how it renders text.
> On this site, in which performance is the only name of the game, I forgo web fonts entirely, opting instead to make use of the visitor’s system font. This is fast, incredibly well suited to the device in question, and has almost zero engineering overhead.
Strongly disagree. You may not consciously notice font choice, but it will certainly effect the way you read the page, how you interpret the the heirarchy of information and tone.
> It’s widely accepted that self-hosted fonts are the fastest option: same origin means reduced network negotiation, predictable URLs mean we can preload, self-hosted means we can set our own cache-control directives, and full ownership mitigates the risks that come with leaving static assets on third-party origins.
This is my general approach now. Feels like a lot of work to keep up with what the ideal remote loading snippet is when local hosting can be simpler and the fastest option. The deep dive into how all the approaches compare is really interesting though.
It's frustrating web developers still need to deal with this complexity just to load a font. I don't think most non-frontend developers realise how much effort it takes to make a nontrivial high performance website. Most of the time in frontend there's many ways to do the same thing, each with their own subtle performance tradeoffs.
> For logo/slogan fonts, one can go ahead even subset the font.
SVG is a nice option for logos. You can inline the SVG file directly into the HTML as well so there's no loading delay - especially useful for logos that need to be rendered immediately at the top of the page.
Would it bloat Chrome significantly if Google included their web fonts in the browser? And, you know... the other browsers can actually download them? I know it doesn't seem like fair play, but... I'm surprised they haven't done it yet.
On allaboutberlin.com, I serve Google Fonts locally. Aside from the benefits mentioned in the article, it also makes HTTP2 server push possible. This means the font is pushed along with the page, without first having to parse the HTML and the CSS. It's significantly faster. There are fewer server round trips.
The website loads from start to finish in 200ms on my end (in Berlin of course). At this point, DNS and server distancs are bigger issues than what's on the page. I find the call for system fonts rather funny, because it's such a pointless sacrifice.
Another significant benefit is privacy. I don't like sending visitor information to third parties. I removed Google Fonts requests, and I'm working on removing Analytics. Once this is done, there won't be any third party requests on the page.
I also removed yesterday the Google Fonts import and just imported them locally. Performance seemed the same in my case, but I finally managed to completely remove Google 3rd party scripts from my site (no more GA, Google Fonts or Google Tag Manager). The only 3rd party left in my case is the chat widget from Tawk.to, but I will soon replace it with a simple contact form, as I am only using it as one anyway.
It's better to block web fonts with uBlock Origin. It would be sweet if someone could add support for these fonts to Decentraleyes as well, which seems to be missing. Seems to be some debate about the merits of doing so, however: https://github.com/Synzvato/decentraleyes/issues/34
I'm okay with 1st party usage, but I don't want Google following me around the web.
Mozilla (and Chromium) could mirror Top X Google Fonts directly into the user's font system and entirely eliminate remote calls for a small size increase in the browser installation.
(Or Microsoft and Apple could do it in OS images.)
You can do it yourself, even, but unfortunately font loading timings are a deanonymization vector with its own privacy implications and it would take a concerted group effort to install similar font sets locally to avoid those privacy issues.
I do like that now Google lets you downloads the fonts, so you can serve from your own CDN without having to hunt them down or download them manually from their CDN endpoint. One thing I'd like to see Google do is add icon font sets to their repo.
The main content may load quickly, at least with javascript disabled, and that's a good thing; but I can hardly read the text though. 300 weight text at 51% grey is awful.
When I see pages formatted like this, I tend to make a decision between opening the inspector and fixing the fonts, or just not bothering to read it, since it's clearly not designed to be read.
> On this site, in which performance is the only name of the game, I forgo web fonts entirely, opting instead to make use of the visitor’s system font.
I appreciate the tip! Is PageSpeed better? I checked Google's tool as well, before commenting. I went with the GTmetrix as I find the layout of how it portrays results cleaner.
Faster still would be to skip the request for the CSS altogether by inlining it in the head. Therefore you'd just request the font immediately and directly. This makes the preconnect moot, and should be faster.
Faster still is to use already installed fonts, as others have noted. But don't use "system" fonts if that means UI fonts like San Francisco or Segue. Exploit the rich font options on the desktop: Georgia, Sitka Text (Windows 8.1+), Calibri, Hoef, etc. Bootstrap and Medium started a ridiculous fad of using system UI fonts for body text. There are actual body text fonts available people.
Modern browsers are smart enough to only download the required file type, sniffing is unnecessary the vast majority of the time and you save an entire 3rd party connection.
The tool you linked does not solve the same problem, as the problems isn’t file types but URIs. Google is able to provide the tiniest possibly font files by hinting them for the specific browser/platform requesting them. We never consistently or predictably know the resultant URI of a Google Fonts-hosted font file. Here is a Tweet to the same effect from two days ago. Believe me, I’ve researched this :(
The fonts are static, but the CSS (from fonts.googleapis.com), and the font files it references, vary depending on the User-Agent. For instance, with a Chrome UA it will request WOFF files; with a blank UA it may request TTF files.
The idea is that you take all the links to the different font types and put them directly in your local CSS. Your browser knows which formats it supports, if you have TTF and WOFF2 fonts linked, Chrome will only download the WOFF2 version. No need to send an extra 3rd party request just to get a piece of CSS that only links a single file type.
Well yes, of course you can do that. But at that point, why would you reference third-party font URLs, instead of self-hosting them? (The article pretty much begins by stating that this is the fastest option.)
If performance is your utmost priority, forego web fonts entirely. If you value performance but want the benefit of a web font, self-host your CSS and fonts. If the convenience of Google Fonts is appealing, the suggestions here can improve first-paint performance. Different projects will have different trade-offs.
You could use a couple microseconds on the server to inline CSS to match the HTTP U-A; assuming whatever you needed to know is still in there by the grace of Google whenever they slush up the U-A strings.
The media query doesn’t match. Why does the browser even load the stylesheet? Shouldn’t it only load it if it starts to match? Especially for things like print stylesheets, where the media query will only become true by deliberate user action (unlike viewport size media queries where actions like rotating a device could cause them to start matching). Print stylesheets will be used by <0.0001% of users on almost all pages, and could easily be loaded only when the user tries to print the document.
The whole thing is a dubious technique anyway because it depends on JavaScript—if JavaScript is disabled, the stylesheet will now not load ever. You’re probably OK with that in a case like this (the fonts are deliberately optional), but inevitably with such techniques people start using them on stylesheets that actually are important, because “it makes the page load faster” or something.
P.S. Why the trailing slash on the tag? It’s completely useless, by definition, and trailing slashes can mislead people into thinking that you can close tags that way, which you can’t.
"This will implicitly tell the browser to load the CSS file in a non-blocking fashion, applying the styles only to the print context. However, the moment the file arrives, we tell the browser to apply it to all contexts, thus styling the rest of the page."
The browser ignores the file because it's just for print and can be loaded later on. But when the page is fully loaded (onload="..."), the media property is set to "all" and does not stay at "print". When this happens, the browser now knows it should load it as soon as possible and does so.
As you mentioned: if JS is disabled, the file will never load. The author states that his solution is not 100% perfect: "[Async webfonts] should always be considered an enhancement anyway, so we need to be able to cope without them; we can and should design decent fallbacks for use during their absence, and;"
You missed my point, or I didn’t explain it well enough. I’m saying: why is the browser even starting to load the stylesheet? It should see media=print and decide that it doesn’t need it at all, and only fetch and load it when the media query starts to match, or perhaps by heuristics when there’s a reasonable chance that it will soon match.
As it stands, browsers are fetching print stylesheets all the time (sure, at idle priority, but they’re still fetching them) even though they’re used less than once per million page loads. This seems silly.
This reminds me of the SEO industry, where people apply cheap tricks for years telling themselves they can outsmart Google, then suddenly there's a core update and all those sites get heavily penalized.
This will probably backfire on frontend devs the same way. A browser prefetching files that aren't needed in 99.999% cases (probably higher, who prints a random webpage in 2020?) sure seems like a bug, so that will probably get fixed someday, and people who applied this trick will wonder why their websites are all breaking down at once.
In general, do things that sound intuitive and coherent to you rather than things that are unintuitive and go against the platforms you are developing on. If someone advises you to go against the value proposition of Google Search (find interesting content) or against the value proposition of Google Chrome ("browse the web in a simple, secure, and faster way"), you might want to take a big step back and rethink this.
OP here: Simply because the only mechanism a browser needs is ‘a currently-matching media type’ or ‘not a currently-matching media type’. There is no need to add further checks for a specific media type; that would lead to added and potentially infinite complexity as new media types are added.
“Does the media query match” is certainly the simplest way to defer loading, but I think some leeway could be useful; the user agent may have ways of predicting when there’s a reasonable probability that the media query will match soon. Kinda like how <img loading=lazy> doesn’t load once the image is needed, but a short time before it’s probably needed.
Hmm, thinking about <img loading=lazy>, I’ve thought of a reason they might not load such stylesheets lazily: privacy leak, you’re notifying the server that the document may have been printed. Lazy image loading has been careful to address this situation so that it’s no new surface (e.g. browsers shouldn’t lazy load if JS is disabled, but if it’s enabled you’re not leaking anything new). But printing specifically? I guess there hasn’t been any way of detecting that the document has been printed, so doing lazy loading on stylesheets for different media types would reveal something new.
Note that we can’t use `background-image: url();` here as browsers will not print background styles by default, so we’d likely miss the majority of cases.
Good point, I completely forgot about that vector. Then there’s no privacy leak, and I go back to not being able to see why they do it the way they do! :)
Stylesheets are different story to images. Stylesheets (that match a media type) are render-blocking whereas images are not. Lowering the priority of a non-matching stylesheet but still downloading it is a better option than JIT loading one.
I don’t believe it’s technically correct to characterise stylesheets as render-blocking; if they take too long to load, user agents may start rendering without them. (This used to happen regularly. Not sure if browsers do it less than they used to or if the conditions where it happens just occur less often these days.)
If you control your layout with JavaScript, things like orientation changes can take a short time to update after the viewport has altered. It’s not ideal, but it’s not awful either.
I disagree with your second claim. I assert (without statistics) that the chance that a print stylesheet will be needed are more than a million to one against (possibly closer to a billion to one). If that is so, I would much rather have printing a document take the extra second to fetch the print stylesheet, rather than needlessly fetching a lot of print stylesheets that I literally never use.
> I don’t believe it’s technically correct to characterise stylesheets as render-blocking…
But they are. There’s absolutely no question about that. A browser will only render in the absence of a stylesheet if a) there’s programmatic intervention from the developers (e.g. timeouts) or b) if the server ultimately responded with a TCP timeout because of an outage. In the latter case, rendering is blocked for 20s on Win and 80s on *nix. CSS is render-blocking. There are no two ways about it. You can verify either slowdowns or outages by using https://slowfil.es or a blackhole server respectively.
> If you control your layout with JavaScript, things like orientation changes can take a short time to update after the viewport has altered. It’s not ideal, but it’s not awful either.
In this scenario you’re CPU-bound and not network-bound. Dispatching render-blocking requests on a high-latency connection JIT is far worse than front-loading your CSS asynchronously with minimal priority.
> I disagree with your second claim. I assert (without statistics) that the chance that a print stylesheet will be needed are more than a million to one against
I agree that print stylesheets are very very very rarely needed. My point—which I stated already—is that to accommodate individual media types increases complexity in the browser for zero gains.
> P.S. Why the trailing slash on the tag? It’s completely useless, by definition, and trailing slashes can mislead people into thinking that you can close tags that way, which you can’t.
Simple: so that XML parsers can load the HTML, as they are not aware of the HTML context which allows "unclosed" tags.
You wouldn’t parse an HTML document with regular expressions.
So why would you parse one with an XML parser? It’s just wrong. (And an effort doomed to failure if you ever have to deal with documents other people wrote, because very few will parse.)
I deal with boatloads of manually written XML and HTML (templates) at my job. It's simpler in mindset to always write something that can be parsed as XML and is not much overhead (a single byte ffs).
There are a lot of more XML parser than HTML5 parser in the world. That's an argument for polyglot markup, if you like the open web and HTML as an API.
As I said, in this case it’s deliberate and acceptable, but techniques like this have a pernicious way of being used in other more important places where they’re emphatically bad.
Concerning the trailing slash: it’s something I’ve long been puzzled about because it seems to me to be not merely pointless but slightly counterproductive. Here you’ve evidently deliberately inserted it, and I can’t for the life of me understand why people are doing this, so I’m asking.
It actually wasn’t a deliberate inclusion—I didn’t give it any thought, largely because it makes no difference and isn’t relevant to the topic of the article. Hopefully readers feel empowered enough to delete their own forward-slashes.
Off topic, but does anyone have a thought on what is the best unicode font? That is, a font that includes all the characters for the 30+ most use languages (including all the double byte languages)? I know every system had a default unicode font that any character can fall back to (I was surprised when I was working with Turkish and the font didn't 3 of the Turkish characters so it fell back to the system font for those three. That was the first time that I learned that text is rendered character by character and if the indicated font doesn't have that character then it will keep going through the fall backs before reaching the system font and then falling back to some default no font character found symbol), but what is the best non-system font that also covers the vast majority (by percentage of people) of modern languages?
I'm involved in fonts for my native language (Sinhalese), and let me tell you: dealing with fonts for multiple languages are is not easy! Some of the Asian languages including Sinhalese are pretty difficult to get right, and glyphs are quite difficult to give a character without breaking their meaning, specially when it comes ZWJs, diacritics, etc.
You can subset a font like Noto to serve your languages, but it will come pretty large. Note that for web, @font-face declarations can set a Unicode character range for each font file, so browser downloads those fonts only when necessary.
I think the architectural limitation of many font formats to 65,536 glyphs means that there aren’t really any good mainstream fonts that contain the entirety of Unicode, but families like Noto have multiple separate fonts that cover most of it.
I use `font-display: optional` instead of `swap` as it leads to less paint flashing, and if the font is too slow to load, it's not the end of the world if it displays it with the fallback system font.
I noticed this is actually mentioned in the article at the end as a bonus section. In my case `optional` did seem to work better. I didn't encounter the empty page flash he mentined.
LE: I don't have that problem because I don't use async CSS. I didn't even know that was a thing, why would you use JavaScript to make sure the browser doesn't wait for the CSS to load? If JS is disabled you end up without any styles or have to add a noscript fallback. Also, why would you let the browser render FOUC?
Here's a simple idea for the Chromium team:
Bundle the top 100-200 Google web fonts (in .woff2 format) with Chromium (less than 20-30MBs) and boom, you just accelerated the entire internet.
Does anybody else block fonts? Not only is it wasteful for my mobile data plan, but I just have this suspicion that sooner than later they will be used as a vector for some kind of security issue.
I just set browser.display.use_document_fonts to false. This sometimes leads to problems for websites that want to use symbol fonts, but I don't mind that. If I use that website frequently I might write some user script to replace the weird letters with better letters, but that's rare.
The bigger details are usually what move the needle. Don't get stuck optimizing a local maxima, which is very easy to do if you're using AB tests. Arguably the point of an AB test is to find the local maxima, but the goal should be to broaden the search space and look for something closer to the global maxima.