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 have this suspicion that sooner than later they will be used as a vector for some kind of security issue. You mean like being rendered into a canvas to get a high-entropy fingerprint of your device?
The Fastest Google Fonts
101–110 of 152 posts
Re: The Fastest Google Fonts
#102Does 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.
Re: The Fastest Google Fonts
#103Just 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 st…
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-fee…
I recently ripped the webfonts out of one web site and the page load time halved. I was like, "You have to be kidding!"
Re: The Fastest Google Fonts
#104
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 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.
Re: The Fastest Google Fonts
#105Faster 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, Sit…
OP here. Inlining CSS won’t work as the request is UA-sniffed.
Re: The Fastest Google Fonts
#106Earlier quoted context omitted.
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-fee…
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 notin…
Re: The Fastest Google Fonts
#107Earlier quoted context omitted.
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…
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.
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
Re: The Fastest Google Fonts
#108I don’t understand why the async stylesheet thing works: 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 styl…
"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;"
Re: The Fastest Google Fonts
#109Just 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 st…
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.
Re: The Fastest Google Fonts
#110I 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.
They've always all been open, and you've always been able to get them. https://github.com/google/fonts