Live data from Hacker News

The Fastest Google Fonts

csswizardry.com

141–150 of 152 posts

Re: The Fastest Google Fonts

#141
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.

Re: The Fastest Google Fonts

#142
post #141

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?

Re: The Fastest Google Fonts

#143
post #3

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 st…

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.

Re: The Fastest Google Fonts

#144
post #87

Earlier quoted context omitted.

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. There are tools like https://google-webfonts-helper.herokuapp.com/fonts which will get you the needed css.

I know how browsers work, but thanks. 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,…

The URLs on gstatic.com are static. I've been doing this for years in production without issues.

Re: The Fastest Google Fonts

#145

Earlier quoted context omitted.

> 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).

Re: The Fastest Google Fonts

#146
post #115

Earlier quoted context omitted.

What about all that juicy tracking data though?

What data do you think is tracked exactly?

I don't know exactly what they're harvesting, but I'm assuming Google isn't offering a free font API out of the goodness of their hearts.

Do you disagree? Maybe they're giving away a font API for literally nothing in return........

Re: The Fastest Google Fonts

#147
post #144

Earlier quoted context omitted.

I know how browsers work, but thanks. 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,…

The URLs on gstatic.com are static. I've been doing this for years in production without issues.

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.

Re: The Fastest Google Fonts

#148
post #144

Earlier quoted context omitted.

The URLs on gstatic.com are static. I've been doing this for years in production without issues.

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.

Re: The Fastest Google Fonts

#149
post #8

This page opens crazy fast (at least for me). Well done. EDIT: Okay, still a few things they could improve on ( https://gtmetrix.com/reports/csswizardry.com/N9gkLyhq )

Thanks! Though GTMetrix hasn’t been considered a reliable or relevant tool for a while now, unfortunately.

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.

Re: The Fastest Google Fonts

#150
post #148

Earlier quoted context omitted.

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.

Post reply on HN