Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Fastest Google Fonts

csswizardry.com

Post reply on HN
Print view View original

111–120 of 152 posts

Re: The Fastest Google Fonts

#111

Post by GrayShade »

thaumaturgy wrote: post #28
slashdev wrote: 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…

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…

As an end user, I don't care about your web fonts, and I suspect others think the same. Usually designers push for them with concerns of brand image and consistency between platforms. I couldn't care less that I get a different font on Linux than what you design for on your Mac.

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.

Re: The Fastest Google Fonts

#112

Post by oftenwrong »

MintelIE wrote: post #89

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.

As much as is possible, I configure browsers to display my preferred font in my preferred size.

Re: The Fastest Google Fonts

#113

Post by chrismorgan »

Kovah wrote: post #108
chrismorgan wrote: post #104

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

It is explained in the article how it works: "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…

You missed my point, or I didn’t explain it well enough. I’m saying: why is the browser even starting to load the stylesheet? It should see media=print and decide that it doesn’t need it at all, and only fetch and load it when the media query starts to match, or perhaps by heuristics when there’s a reasonable chance that it will soon match.

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.

Re: The Fastest Google Fonts

#114

Post by vntok »

chrismorgan wrote: post #113
Kovah wrote: post #108

Earlier quoted context omitted.

It is explained in the article how it works: "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…

You missed my point, or I didn’t explain it well enough. I’m saying: why is the browser even starting to load the stylesheet? It should see media=print and decide that it doesn’t need it at all , and only fetch and load it when the media query starts to match, or perhaps by heuristics when there’s a reasonable chance that it will soon match. As it stands, browsers are fetching print stylesheets all the time (sure, at…

This reminds me of the SEO industry, where people apply cheap tricks for years telling themselves they can outsmart Google, then suddenly there's a core update and all those sites get heavily penalized.

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.

Re: The Fastest Google Fonts

#115

Post by vntok »

chance_state wrote: post #90
fevangelou wrote: post #85

Here's a simple idea for the Chromium team: Bundle the top 100-200 Google web fonts (in .woff2 format) with Chromium (less than 20-30MBs) and boom, you just accelerated the entire internet.

What about all that juicy tracking data though?

What data do you think is tracked exactly?

Re: The Fastest Google Fonts

#116

Post by nicbou »

christophilus wrote: post #63
johnghanks wrote: post #37

Earlier quoted context omitted.

What an absolutely stupid response to this. Of course, just use something that people would already have, 5head. Let me just ask the designer on my team to stop using anything other than Arial and Times New Roman. 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.

You can make a stack of standard fonts look just fine. I think most of the web would be better off doing that. You can choose the best looking font for Windows, the best one for Mac, and the best looking Linux fonts, and just move along. Your page will load faster, and look more familiar to your users.

The fonts on my site weight about 50 kb. I don't think it will make such a big difference.

Re: The Fastest Google Fonts

#117

Post by csswizardry »

r1ch wrote: post #87
csswizardry wrote: post #73

Earlier quoted context omitted.

OP here. Inlining CSS won’t work as the request is UA-sniffed.

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, I’ve researched this :(

https://twitter.com/csswizardry/status/1265716520346320903

Re: The Fastest Google Fonts

#118

Post by ancarda »

ken wrote: post #72
thaumaturgy wrote: post #28

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

> They continue to be used everywhere because they offer a consistency that's impossible to get otherwise. 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…

>Every single day I run across webpages with custom fonts that I literally struggle to read.

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.

Re: The Fastest Google Fonts

#119

Post by 0-O-0 »

derefr wrote: post #20
onion2k wrote: post #15

Earlier quoted context omitted.

That might change. Google are changing their search ranking metrics to include the new Core Web Vitals metrics[1]. One of those is "Cumulative Layout Shift", or how much the page changes the layout over time. Using a font that isn't performant will cause the page to render, and then to move around once the page loads, which could push your site down on Google's search results page. [1] https://webmasters.googleblog.c…

Has anyone ever suggested doing "progressive fonts"? I.e., start the font downloading before the page renders at all; have the font organized so the first thing that's received is the bounding boxes + kerning table + ligatures table (= enough to know how much space an inline flow of graphemes will take up); then load the page, with the page layout already settled, while loading the font itself in the background. Even…

> the text just pops into existence

This is very jarring and happens all the time with web fonts.

Re: The Fastest Google Fonts

#120

Post by csunbird »

nicbou wrote: post #95

On allaboutberlin.com, I serve Google Fonts locally. Aside from the benefits mentioned in the article, it also makes HTTP2 server push possible. This means the font is pushed along with the page, without first having to parse the HTML and the CSS. It's significantly faster. There are fewer server round trips. The website loads from start to finish in 200ms on my end (in Berlin of course). At this point, DNS and serve…

I did not know that you were active in HN. Thanks for the site, it helped me out greatly!
Post reply on HN