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

Self-host your fonts for better performance

wicki.io

Post reply on HN
Print view View original

231–240 of 417 posts

Re: Self-host your fonts for better performance

#231

Post by pwinnski »

zinekeller wrote: post #207
colejohnson66 wrote: post #199

Earlier quoted context omitted.

Wasn’t the point of Google Fonts that your browser would have in its cache fonts from Google so it wouldn’t download multiple copies from all over the place? A CDN basically. I know jQuery and Bootstrap recommend using their CDNs so browsers have the copy in their cache. Of course, there’s always the tracking ability, but that’s inherent to every CDN.

> Wasn’t the point of Google Fonts that your browser would have in its cache fonts from Google so it wouldn’t download multiple copies from all over the place? That's true for now (you should know that Google Chrome will deploy changes on caching third-party content), but webfont caching simply doesn't work as well when you've realized that websites that do use webfonts have a tendency to pick fonts that are unlikely…

That is not true for now, as the article points out.

Hasn't been true for Safari for quite some time, and Chrome followed suit two months ago. That's not "will deploy," it has already been released in Chrome v86.

Re: Self-host your fonts for better performance

#232

Post by [deleted] »

fareesh wrote: post #110

What if you had a declaration like @font-face { font-signature: somehash } And the browser just checks to see if it already has the font. If you release a webfont you can share it with signatures or just generate signatures if the author hasn't done it for you. This way if you're self-hosting Lato and the user already has Lato, they don't need to download it again.

[deleted]

Re: Self-host your fonts for better performance

#233

Post by jfk13 »

dubcanada wrote: post #148
jakub_g wrote: post #140

Earlier quoted context omitted.

I'm not an expert but: - 1. Copyright (though many fonts are free, true) - 2. Everyone uses a different font (just like everyone uses a slightly different version jquery) so cache hit would be pretty small IMO. Do you really want a browser to be gigabytes large? Especially on mobile it's not viable Maybe if browsers standardized on shipping, say, 20 carefully chosen fonts (not necessarily the most popular ones, just…

I mean I’ve said it before but shipping like 20 (montserrat, raleway, open sans, etc) would cover most websites who use Google Fonts.

Do we really want to invite a couple of browser vendors to set the course of typographic design for the next few decades?

Re: Self-host your fonts for better performance

#234

Post by hunter2_ »

ffpip wrote: post #220

FYI Google fonts are also loaded from the google.com domain. They can associate your login cookies with every page you visit. As you can see, it is very sneaky by using CNAME Cloaking - https://i.imgur.com/VB2DB75.png The request is to fonts.gstatic.com, but it resolves to gstaticadssl.l.google.com Tracking using CNAME cloacking - https://medium.com/nextdns/cname-cloaking-the-dangerous-disg...

Wait, are you saying that if foo.example.com and bar.example.com are each CNAME records pointing at example.com (and the server has regular name based vhosts to isolate what is served for each), then browsers use a single cookie jar for foo and bar? So if the admin of the foo site and the admin of the bar site are adversarial, they can steal each other's cookies?

That doesn't seem right at all... I hope I am misunderstanding.

Now, if the admin of foo overrides the cookie scope to be *.example.com instead of the default foo.example.com, then yes it's expected that the admin of bar can steal foo's cookies. This is mentioned in the NextDNS Medium article you linked to, toward the end. This is definitely a "gotcha" situation but at least the default is safe, as far as I can tell.

Re: Self-host your fonts for better performance

#235

Post by edoceo »

ffpip wrote: post #220

FYI Google fonts are also loaded from the google.com domain. They can associate your login cookies with every page you visit. As you can see, it is very sneaky by using CNAME Cloaking - https://i.imgur.com/VB2DB75.png The request is to fonts.gstatic.com, but it resolves to gstaticadssl.l.google.com Tracking using CNAME cloacking - https://medium.com/nextdns/cname-cloaking-the-dangerous-disg...

Cookies gstatic.com wouldn't share to the resolved name would they? The cookie site is requested name not the resolved cname - or am I missing something?

Re: Self-host your fonts for better performance

#236

Post by madboston »

ffpip wrote: post #220

FYI Google fonts are also loaded from the google.com domain. They can associate your login cookies with every page you visit. As you can see, it is very sneaky by using CNAME Cloaking - https://i.imgur.com/VB2DB75.png The request is to fonts.gstatic.com, but it resolves to gstaticadssl.l.google.com Tracking using CNAME cloacking - https://medium.com/nextdns/cname-cloaking-the-dangerous-disg...

I'm glad pihole now blocks CNAMEs as well for known hosts :)

Re: Self-host your fonts for better performance

#237

Post by mhils »

ffpip wrote: post #220

FYI Google fonts are also loaded from the google.com domain. They can associate your login cookies with every page you visit. As you can see, it is very sneaky by using CNAME Cloaking - https://i.imgur.com/VB2DB75.png The request is to fonts.gstatic.com, but it resolves to gstaticadssl.l.google.com Tracking using CNAME cloacking - https://medium.com/nextdns/cname-cloaking-the-dangerous-disg...

Correct me if I'm wrong, but a CNAME "redirect" on the DNS level does not change the page origin. `fonts.gstatic.com` will only get the cookies set for `fonts.gstatic.com`, even if it is CNAMEd to a different domain.

Re: Self-host your fonts for better performance

#238

Post by arcturus17 »

metalforever wrote: post #203
arcturus17 wrote: post #167

Earlier quoted context omitted.

How has the web been subverted? By whom? And which notable, useful old tecnologies have been discarded? The capabilities of the web have only been expanded. You can still build websites in Django and Rails and myriad other "old-school" technologies. What are you missing? Perl and CGI? To the point of this article, you can perfectly build a website with self-hosted fonts, or with default system fonts. Is this what "lo…

This comment touches on some points which don't make sense from an engineering perspective. Different tools for different use cases. You can't throw the baby out with the bathwater and choose SPAs for every single application. They still perform poorly with SEO and people with disabilities that need a screen reader. It's not black and white (good or bad). Also, using Django and Rails are hardly the same as using Perl…

What doesn’t make sense from an engineering perspective?

I did not say you should build everything as an SPA. I said you still can build in SSR - not once did I say what you should or shouldn’t do. But I agree - some sites are better off as SSR, static sites or what have you. What in my comment made you think that I think otherwise?

I also do not think that Django or Rails are remotely similar to CGI sites - what makes you remark that they are hardly the same, when my comment doesn’t suggest the opposite?

Re: Self-host your fonts for better performance

#239

Post by EGreg »

ffpip wrote: post #220

FYI Google fonts are also loaded from the google.com domain. They can associate your login cookies with every page you visit. As you can see, it is very sneaky by using CNAME Cloaking - https://i.imgur.com/VB2DB75.png The request is to fonts.gstatic.com, but it resolves to gstaticadssl.l.google.com Tracking using CNAME cloacking - https://medium.com/nextdns/cname-cloaking-the-dangerous-disg...

So they can also do it with A records and IP addresses. I guess the CNAME resolved to an IP address at the end anyway.

Re: Self-host your fonts for better performance

#240

Post by EGreg »

mhils wrote: post #237
ffpip wrote: post #220

FYI Google fonts are also loaded from the google.com domain. They can associate your login cookies with every page you visit. As you can see, it is very sneaky by using CNAME Cloaking - https://i.imgur.com/VB2DB75.png The request is to fonts.gstatic.com, but it resolves to gstaticadssl.l.google.com Tracking using CNAME cloacking - https://medium.com/nextdns/cname-cloaking-the-dangerous-disg...

Correct me if I'm wrong, but a CNAME "redirect" on the DNS level does not change the page origin. `fonts.gstatic.com` will only get the cookies set for `fonts.gstatic.com`, even if it is CNAMEd to a different domain.

I am not sure that’s true. Where is your proof... and Can’t they just ask you to set an A record btw?
Post reply on HN