This isn't actually accurate. It's possible for a CSS author to write @font-face rules that behave in this way (by including local(...) sources ahead of remote-font URLs), but that's by no means universal practice.
https://developer.mozilla.org/en-US/docs/Web/CSS/font-family
`font-family` rules apply ahead of `@font-face` rules. `@font-face` rules are used to source fonts not already installed on the system.
(ETA: local() is to provide alternate family names when a font may be installed under different family names.)
See https://www.w3.org/TR/css-fonts-3/#font-family-desc:
> If the font family name is the same as a font family available in a given user's environment, it effectively hides the underlying font for documents that use the stylesheet.
Given CSS such as
body { font-family: Palatino, serif; }
@font-face { font-family: Palatino; src: url(palatino.ttf); }
this will block the browser from using an installed Palatino font and tell it to load the remote resource instead. So it's possible to use @font-face { font-family: Palatino; src: local("Palatino"), url(palatino.ttf); }
to ask for the locally-installed font if present, falling back to the remote resource otherwise.
Browsers have always loaded a font from the system over a web font if it has a font of that name.
We could just normalize having a lot more free as in beer fonts installed on the average user's machine.
The unfortunate emphasis there is "average user's machine" as font loading times are already a a deanonymization vector/fingerprinting. Way back in the day IE made a big deal about bundling a group of fonts and calling them "Web Safe" and we need an initiative like that again. Take the Top X fonts from Google Fonts and just bundle them with browsers or operating systems and spread those as widely as possible so that it isn't a useful deanonymization vector.