It's like my desire for quality CLI apps and APIs before any sort of fancy schmancy GUI. The important part is reminding one's self that the other 99% of people want and need the GUI version of the app.
Practically there's no difference between a browser that lazily downloads builtin fonts, and a global URL for a font file across websites with an extremely long TTL. And you don't want the browsers to be even more bloated than they already are!
It's been a while now, but at one point there were some numbers that came in that showed that a much higher fraction of user agents arrive at a web site with a completely empty cache [than you might expect].
Enough so that if you rely on caching for user experience, your average user is not going to have a good time.
- not all sites use CDN, even if using the same font
- not all sites use the same CDN
- users clear the cache (clearing history does that on firefox)
- incognito mode is a thing
- first load matters a lot
- browser have a limit of the disk space they use for cache, and they evict older entries when they reach it. Given sites are now bloated, this fills up fast.
- this repeats for each browser. I have 5 on my laptop, 3 on my mobile, 2 on my tablet.
Font selection in browsers isn't limited. Browsers don't have embedded fonts—they rely on whatever fonts are installed in the operating system.
The challenge is that to ensure consistency, you need to use the "lowest common denominator" of fonts that are installed by default across all operating systems. Which leaves you with (like) Arial, Times, Courier, Verdana, Georgia, Palatino, and (hahahaha) Comic Sans.
The real answer here is why web designers use Google Fonts as opposed to embedding their own fonts. To which the answer is: it's so much easier. (Tech, licensing, formats, compatibility, etc.)
> Which leaves you with (like) Arial, Times, Courier, Verdana, Georgia, Palatino, and (hahahaha) Comic Sans.
Not Palatino.
And most of those fonts have licenses that are inconvenient at best. The only thing that allows them to be packaged for Linux distributions is Microsoft's '90s-era "Core Fonts for the Web" initiative. This initiative is long discontinued, and so the fonts cannot be downloaded from Microsoft anymore. Only the '90s versions of the fonts are free. Worse yet, the license forbids packaging the fonts in any way other than with their original 32-bit Windows installer, which means that hacks like cabextract are necessary to install them on any other system.
The only way to do that would be to include particular typefaces as part of the CSS specification, rather than just the generic font-family keywords like “sans-serif” and “monospaced”. But who should pick them, which ones would they pick, and how would they be licensed?
It’s kind of the same problem as saying that the browser should include common images. Which images? Why? How many?
> It’s kind of the same problem as saying that the browser should include common images. Which images? Why? How many?
Images follow a different usage distribution than fonts. I'd say that the top 100 fonts are enough to render most web content, for images I'd say this is obviously different, the top 100 images might appear often but not as often as the top 100 fonts.
Google is already distributing the equivalent for text, in the form of the brotli corpus which ships in every Chrome installation.
> why don't browsers just include the most popular fonts, so the underlying OS doesn't matter?
Well, pontificating here:
1. Because many applications don't ship with additional fonts, and it's an additional layer of complexity. Some do—Microsoft Word comes to mind, IIRC.
2. Because you're still left with the same problem: unless all browsers can agree on an additional set of standard fonts, you as a web developer will only want to use those installed by Chrome and Edge and Safari and Firefox.
3. Because licensing for desktop application may (?) be more of a pain than licensing for web usage. Which may not matter for Google Fonts, since they may be the license holder for all anyway. I don't know.
Loading fonts is tracking and data collection. It's what Google does. If they build the fonts into the browser, then tracking/data collections calls are not made.
Last I checked, browsers don't come with fonts. Browsers use the OS's fonts if a webpage doesn't have them. I'd rather browsers not maintain their own fonts.
The top fonts aren't the issue for page loading, they'll be cached 99% of the time. It's more obscure fonts that actually hit the server causing the issue.
But they do. Javascript itself has evolved significantly over the past decade obsoleting many features that used to solely be provided by add-on frameworks.
HTML5 as a living standard brings the majority of the needs that used to be served by plugins – interactivity, dynamic pages, two-way communications, multimedia.
WebSockets provide for realtime communications with the browser, something again not possible without 3rd-party plugins.
So, what you are saying is in fact happening. But that doesn't mean it's not an issue with sliding goalposts. It's just that it doesn't happen as quickly as we all may like it, but that's because "basic functionality" is a constantly moving target with different definitions depending on who asks.
The problem si that number of "standard" fonts are thining. It sucks having different widths of fonts on different platforms. You will have to load some webfont if you want consistency.
