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

131–140 of 152 posts

Re: The Fastest Google Fonts

#131

Post by csswizardry »

chrismorgan wrote: post #130
csswizardry wrote: post #121

Earlier quoted context omitted.

OP here: Simply because the only mechanism a browser needs is ‘a currently-matching media type’ or ‘not a currently-matching media type’. There is no need to add further checks for a specific media type; that would lead to added and potentially infinite complexity as new media types are added.

“Does the media query match” is certainly the simplest way to defer loading, but I think some leeway could be useful; the user agent may have ways of predicting when there’s a reasonable probability that the media query will match soon. Kinda like how doesn’t load once the image is needed , but a short time before it’s probably needed. Hmm, thinking about , I’ve thought of a reason they might not load such stylesheet…

You can detect print very, very easily. I helped the NHS track print-users using this: https://csswizardry.com/2018/03/measuring-the-hard-to-measur...

Note that we can’t use `background-image: url();` here as browsers will not print background styles by default, so we’d likely miss the majority of cases.

Re: The Fastest Google Fonts

#132

Post by csswizardry »

chrismorgan wrote: post #130
csswizardry wrote: post #121

Earlier quoted context omitted.

OP here: Simply because the only mechanism a browser needs is ‘a currently-matching media type’ or ‘not a currently-matching media type’. There is no need to add further checks for a specific media type; that would lead to added and potentially infinite complexity as new media types are added.

“Does the media query match” is certainly the simplest way to defer loading, but I think some leeway could be useful; the user agent may have ways of predicting when there’s a reasonable probability that the media query will match soon. Kinda like how doesn’t load once the image is needed , but a short time before it’s probably needed. Hmm, thinking about , I’ve thought of a reason they might not load such stylesheet…

Stylesheets are different story to images. Stylesheets (that match a media type) are render-blocking whereas images are not. Lowering the priority of a non-matching stylesheet but still downloading it is a better option than JIT loading one.

Re: The Fastest Google Fonts

#133

Post by csswizardry »

chrismorgan wrote: post #127
csswizardry wrote: post #122

Earlier quoted context omitted.

> The whole thing is a dubious technique anyway because it depends on JavaScript—if JavaScript is disabled… I address this twice in the article, which presumably you didn’t read. > P.S. Why the trailing slash on the tag? It’s completely useless… Are you just looking for things to be unhappy about?

As I said, in this case it’s deliberate and acceptable, but techniques like this have a pernicious way of being used in other more important places where they’re emphatically bad. Concerning the trailing slash: it’s something I’ve long been puzzled about because it seems to me to be not merely pointless but slightly counterproductive. Here you’ve evidently deliberately inserted it, and I can’t for the life of me unde…

It actually wasn’t a deliberate inclusion—I didn’t give it any thought, largely because it makes no difference and isn’t relevant to the topic of the article. Hopefully readers feel empowered enough to delete their own forward-slashes.

Re: The Fastest Google Fonts

#134

Post by mschuster91 »

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…

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

Re: The Fastest Google Fonts

#135

Post by woodrowbarlow »

rkagerer wrote: 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 )

this page doesn't use web fonts.

> On this site, in which performance is the only name of the game, I forgo web fonts entirely, opting instead to make use of the visitor’s system font.

Re: The Fastest Google Fonts

#136

Post by chrismorgan »

csswizardry wrote: post #132
chrismorgan wrote: post #130

Earlier quoted context omitted.

“Does the media query match” is certainly the simplest way to defer loading, but I think some leeway could be useful; the user agent may have ways of predicting when there’s a reasonable probability that the media query will match soon. Kinda like how doesn’t load once the image is needed , but a short time before it’s probably needed. Hmm, thinking about , I’ve thought of a reason they might not load such stylesheet…

Stylesheets are different story to images. Stylesheets (that match a media type) are render-blocking whereas images are not. Lowering the priority of a non-matching stylesheet but still downloading it is a better option than JIT loading one.

I don’t believe it’s technically correct to characterise stylesheets as render-blocking; if they take too long to load, user agents may start rendering without them. (This used to happen regularly. Not sure if browsers do it less than they used to or if the conditions where it happens just occur less often these days.)

If you control your layout with JavaScript, things like orientation changes can take a short time to update after the viewport has altered. It’s not ideal, but it’s not awful either.

I disagree with your second claim. I assert (without statistics) that the chance that a print stylesheet will be needed are more than a million to one against (possibly closer to a billion to one). If that is so, I would much rather have printing a document take the extra second to fetch the print stylesheet, rather than needlessly fetching a lot of print stylesheets that I literally never use.

Re: The Fastest Google Fonts

#137

Post by chrismorgan »

csswizardry wrote: post #131
chrismorgan wrote: post #130

Earlier quoted context omitted.

“Does the media query match” is certainly the simplest way to defer loading, but I think some leeway could be useful; the user agent may have ways of predicting when there’s a reasonable probability that the media query will match soon. Kinda like how doesn’t load once the image is needed , but a short time before it’s probably needed. Hmm, thinking about , I’ve thought of a reason they might not load such stylesheet…

You can detect print very, very easily. I helped the NHS track print-users using this: https://csswizardry.com/2018/03/measuring-the-hard-to-measur... Note that we can’t use `background-image: url();` here as browsers will not print background styles by default, so we’d likely miss the majority of cases.

Good point, I completely forgot about that vector. Then there’s no privacy leak, and I go back to not being able to see why they do it the way they do! :)

Re: The Fastest Google Fonts

#138

Post by chrismorgan »

mschuster91 wrote: post #134
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…

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

Re: The Fastest Google Fonts

#139

Post by csswizardry »

chrismorgan wrote: post #136
csswizardry wrote: post #132

Earlier quoted context omitted.

Stylesheets are different story to images. Stylesheets (that match a media type) are render-blocking whereas images are not. Lowering the priority of a non-matching stylesheet but still downloading it is a better option than JIT loading one.

I don’t believe it’s technically correct to characterise stylesheets as render-blocking; if they take too long to load, user agents may start rendering without them. (This used to happen regularly. Not sure if browsers do it less than they used to or if the conditions where it happens just occur less often these days.) If you control your layout with JavaScript, things like orientation changes can take a short time t…

> I don’t believe it’s technically correct to characterise stylesheets as render-blocking…

But they are. There’s absolutely no question about that. A browser will only render in the absence of a stylesheet if a) there’s programmatic intervention from the developers (e.g. timeouts) or b) if the server ultimately responded with a TCP timeout because of an outage. In the latter case, rendering is blocked for 20s on Win and 80s on *nix. CSS is render-blocking. There are no two ways about it. You can verify either slowdowns or outages by using https://slowfil.es or a blackhole server respectively.

> If you control your layout with JavaScript, things like orientation changes can take a short time to update after the viewport has altered. It’s not ideal, but it’s not awful either.

In this scenario you’re CPU-bound and not network-bound. Dispatching render-blocking requests on a high-latency connection JIT is far worse than front-loading your CSS asynchronously with minimal priority.

> I disagree with your second claim. I assert (without statistics) that the chance that a print stylesheet will be needed are more than a million to one against

I agree that print stylesheets are very very very rarely needed. My point—which I stated already—is that to accommodate individual media types increases complexity in the browser for zero gains.

Re: The Fastest Google Fonts

#140

Post by XCSme »

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 also removed yesterday the Google Fonts import and just imported them locally. Performance seemed the same in my case, but I finally managed to completely remove Google 3rd party scripts from my site (no more GA, Google Fonts or Google Tag Manager). The only 3rd party left in my case is the chat widget from Tawk.to, but I will soon replace it with a simple contact form, as I am only using it as one anyway.
Post reply on HN