The Fastest Google Fonts(csswizardry.com) |
The Fastest Google Fonts(csswizardry.com) |
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.
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.
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.
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.
In conclusion, http://bettermotherfuckingwebsite.com/ forever, because https://thebestmotherfucking.website/ goes too far.
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.
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...
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.
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 recently ripped the webfonts out of one web site and the page load time halved. I was like, "You have to be kidding!"
Also, this list won't help anyway. The clients aren't picking fonts by performance.
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.
Perhaps for English and other Latin-based alphabets. But for some other writing systems, system fonts are simply terrible.
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.
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.
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).
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.
And what a glorious improvement that would be!
(I could do without the RSS feed, though)
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.
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.
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.
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.
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.
> 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.
So… well read, I guess?
Designers tend to disagree.
I personally agree with you, but if we were not a very small minority, lynx[1] would be much more popular today..
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.
It's probably a good idea to refresh the fonts off Google once or twice a year though. Although not often, these font file get updated.
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.
Chrome is pretty chatty with Google; you probably wouldn't notice the extra traffic from these notifications.
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'm okay with 1st party usage, but I don't want Google following me around the web.
EDIT: Okay, still a few things they could improve on (https://gtmetrix.com/reports/csswizardry.com/N9gkLyhq)
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.
Original: https://qui.suis.je/drop/faster/illegible.png
400 weight: https://qui.suis.je/drop/faster/better.png
400 weight and black: https://qui.suis.je/drop/faster/black.png (not necessarily an improvement, once the weight is normal).
> 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.
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.
There are tools like https://google-webfonts-helper.herokuapp.com/fonts which will get you the needed css.
<link rel="stylesheet"
href="$CSS&display=swap"
media="print" onload="this.media='all'" />
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.
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.
Good article though, great research effort.
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?
It does not work with fonts as far as I'm aware, but it can serve popular libraries locally, saving bandwidth, and protecting privacy.
You mean like being rendered into a canvas to get a high-entropy fingerprint of your device?
1. https://security.stackexchange.com/questions/91347/how-can-a...
2. https://threatpost.com/of-truetype-font-vulnerabilities-and-...
3. https://googleprojectzero.blogspot.com/2015/07/one-font-vuln...
"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;"
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.
Simple: so that XML parsers can load the HTML, as they are not aware of the HTML context which allows "unclosed" tags.
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 address this twice in the article, which presumably you didn’t read.
> P.S. Why the trailing slash on the tag? It’s completely useless…
Are you just looking for things to be unhappy about?
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.
Do you disagree? Maybe they're giving away a font API for literally nothing in return........
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.
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.
1. https://csswizardry.com/2019/05/self-host-your-static-assets... 2. https://andydavies.me/blog/2018/09/06/safari-caching-and-3rd... 3. https://bugs.chromium.org/p/chromium/issues/detail?id=910708
(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.
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.
My self-hosted, cached, server-pushed fonts keep the total load time well under 500 milliseconds. I load 2 fonts in a total of 6 variants.
The 100kb responsive header is a much bigger bottleneck.
You can achieve much bigger savings with proper caching, gzipping, a fast server and a lightweight page than with system fonts.
[1] https://webmasters.googleblog.com/2020/05/evaluating-page-ex...
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.)
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.
This is very jarring and happens all the time with web fonts.
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 :(
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.
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.
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.
Open Sans, via Google Fonts https://wordpress.org/
Facebook:
Freight Sans https://www.facebook.com/
font-family: Helvetica, Arial, sans-serif
When I visit Wordpress.com and check the font on the body, I see:
font-family: -apple-system,BlinkMacSystemFont,"Segoe UI","Roboto","Oxygen-Sans","Ubuntu","Cantarell","Helvetica Neue",sans-serif
font-family: Merriweather, Georgia, "Times New Roman", serif
It's wordpress.org (not .com) that has Open Sans. Not sure what that's about.
Hint, it should never happen on a well designed site.
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.
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.
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?
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).
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.
How about the most popular third party theme? Web fonts: https://themes.svn.wordpress.org/astra/2.4.4/assets/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.
[1]: https://fonts.google.com/?sort=popularity
[2]: https://themes.svn.wordpress.org/twentytwenty/1.3/style.css (warning: content-disposition: download)
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'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.
1. https://medium.com/@ValidScience/two-mysterious-web-font-bug...
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.
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.
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.
We still haven't figured out where the goalposts started!