Hacker News new | past | comments | ask | show | jobs | submit login
Should you self-host Google Fonts? (tunetheweb.com)
289 points by bewuethr 38 days ago | hide | past | web | favorite | 155 comments



We’re basically forced to switch to self hosting due to the bizarre way Google implements statistics for Google Fonts. 1 out of 1000 requests will include a “tracking font” which is actually invalid and breaks document.fonts.load. This was an incredibly frustrating bug to track down.

Bug for those interested: https://github.com/google/fonts/issues/2345


Thanks for sharing! Also `fonts.gstatic.com` is a CNAME alias for `gstaticadssl.l.google.com` which is commonly blocked by ad blockers. uBlock Origin recently added CNAME based blocking, and PiHole is rolling out support for it too. Just another reason to host it yourself.


And this is probably a good reason why they do it this way, they would be stupid not to. Not that I'm happy we end up with this, but business wise it makes way too much sense.


Useful information on self-hosting 3rd party resources: https://calendar.perfplanet.com/2019/self-hosting-third-part...


The guy who is affiliated with Google Fonts who showed up on a thread a few days ago said that he didn't think there was any tracking related to new implementations of Google Fonts stuff.

I guess this says the opposite. Let me try to dig up the thread for completeness...

EDIT: Well that was faster than I thought I'd be able to do. Here's the comment, and the thread: https://news.ycombinator.com/item?id=22369415


I actually don’t care what they’re doing with the data, I care that it crashes the site.

The font that gets loaded once every thousand requests is https://fonts.gstatic.com/stats/Roboto/normal/400 so it’s some form of statistics. But again, my actual concern is that it breaks.

Here’s the code I used to “catch” it. Here, it took roughly 500 requests: https://runkit.com/tolmasky/5e49b314ef61f900146c9a3b

Edit: To be clear, I’m not implying this is something they try to keep secret, just showing a way to observe it since it purposely rarely shows up.


Your users might... But who cares, right?


I don’t think there’s super meaningful data to be gleaned from server-side tracking, especially with browsers increasingly sending little to no information to third party resources. This is CSS, not a JS script that might collect more info and phone home. So yeah, the site going blank is higher priority to me than them knowing if I, the service provider, not my users, prefer Roboto over Open Sans, or if most users now support woff2 vs. ttf. But either way, we’re not going to use them anymore.


CSS can be crafted to conditionally load additional resources, which means it can be a vector for fairly sophisticated information gathering and tracking. For example: https://github.com/kkuchta/css-only-chat


Right but that’s not what’s happening on google fonts.


Makes you wonder if it's one node with bad content in a set of one thousand servers!

Or bad content cached on one of these/cdn server.


Incidentally, not that it helps you if you're concerned about your users' privacy, you can use a lot of these third party resources pretty securely with a single Firefox setting:

    network.http.referer.XOriginPolicy = 2
This tells Firefox to only send the referer header to sites on the same origin. This seems to break very few sites, but means there's no way Google could track me through web fonts even if they wanted to, since they don't know what site I've requested the font from.

That said, I think it's pretty plausible (as another user noted) that Google is only keeping general metrics here, not tracking anyone. 1/1000 requests is not very useful data, even if it provided them something on top of the Referer, which they already have.


That helps in some cases, but google would still know what font was requested and when. So if a certain site uses Noto Sans and Montserrat that narrows down which site you visited to ones that use those two. Considering google regularly crawls the whole web it definitely knows which sites match those two. That would be a pretty big group of sites, but the more sites that use the features that google fonts touts as performance gains like subsetting and the display parameter the more tracking bits google gains. The more fonts and options sites use the more unique the request signature becomes.

Basically if you don't want to be tracked the only good way is to not request anything from the tracking companies. As soon as your browser connects to them they have gained something. Use uMatrix to block all third parties by default, and only whitelist what is absolutely critical for the site to work.



It's a nice add-on but sadly it doesn't cache fonts and some other resources.

See: https://git.synz.io/Synzvato/decentraleyes/issues/34


Ah I just assumed it did for some reason; thanks


There's a difference between user activity tracking (the context of the discussion you linked) and generic metric gathering, which is clearly a thing given that the post was a link to the public fonts analytics page.

(I work at Google, I know nothing specific about fonts)


I agree, but it's a problem because a big part of googles business relies on the former, so I can't trust them when they say that one of their products only does the latter.


Why not?

A growing part of Google's business relies on b2b transactions. Are you also concerned that you're going to suddenly have to subscribe to search?


> Why not?

I thought that was pretty clear in my previous comment, what part was unclear?

> A growing part of Google's business relies on b2b transactions. Are you also concerned that you're going to suddenly have to subscribe to search?

No, because search is profitable and already explicitly data-milked for most of it's worth. I'm concerned about the data collected in unprofitable services just because they are not profitable and claim to not have every iota of data extracted from them.

So I'm concerned that Google Fonts, ajax.googleapis.com and so on will start to be milked for data just like search is.


Why are you so confident that these services are unprofitable?

You're already assuming the main profit source would be second order effects (analytics value add). Why not go further and assume that there already are second order effects that make fonts profitable.

For example, more internet users means more profit for Google, and accessible cross language fonts lead to more web users.


Totally understand and agree that there is a difference: I just half-remembered an at-least tangentially related post and wanted to call it out in case others didn't catch it in the last couple days.

I think some actually conflate the generic vs. user-specific metrics collection quite frequently in arguments that I see on this site and I agree that it's definitely not the same but I still felt it was worth the call-out.


Good! Yet another benefit of having control of your site.

And another potential cost of relying on someone elses servers.


Have you been able to verify 1 of 1,000? Or was that only this site, this instance of the error?

I'm ask because, I wonder if Google adjusts that depending on the site? The traffic?? And/or what it thinks it need to know?


I could add another point: A software should be self-sufficient (at least to a degree). When user opens the page, the page should not require an external service to function.

Imagine a user who can access your page but cannot access Google, the user then has to wait a long time looking at a blank page before the web browser stopped trying, that is some really really bad experience.

And your users won't blame Google for been too slow, they will just simply close your page, and try another search result instead.


I usually just download and self-host for this reason. A software should never rely or be dependent to content delivery networks/repositories like Google Fonts. There's nothing wrong with Google Fonts as a service and repository (tracking stuff aside), but I've never felt comfortable at the idea that we just link, lets say, jQuery or Angular through CDN and call it a day.

I should add that most of my work is through intranet applications with servers only accessed through VPN and I've seen the firewall disrupt Microsoft services one too many times so... it's more of a "yea, it's just a save-as or copy file to my app assets folder" versus users sending me emails that the pages stopped working.


> A software should never rely or be dependent to content delivery networks/repositories

Not sure that's viable in today's cloud-y world


It's the cloud that is not viable in a software world. Software is too important to introduce unnecessary dependencies and weaknesses.


Eliminating weaknesses to provide services that are faster and more robust is exactly why CDNs exist. Whether or not you find them necessary is up to you. Personally a world with content closer to my machine with more robust servers that can handle high traffic is better than the alternative.


You can get the best of both worlds by self-hosting and putting a CDN in front of that. This way you get robustness and your app will still function in isolation


I'd add that the nature and value of the internet itself is in having interconnectedness. Perhaps, not initially for a site's infrastructure, but only because no one saw that far ahead. None the less, the ideal was there.

If there's that much fear in connecting elsewhere then we've done something wrong. Of course, there are exceptions. There always are. But the arc of the internet is the natural ability to connect.

p.s. Using a CDN ideally saves the browser time. If I've already visited a site that used the same version of jQuery from the same CND then that's in the browser cache.

Sure. Maybe we need to refine this. I'm not sure. But let's not make connecting and sharing sound like a bad idea.


>that's in the browser cache.

As per article that's no longer true. Thanks fingerprinting.


Isn't that like not trusting AWS and have your own reliable data center for website hosting?

Edit: Removed cache statement.


Pretty much.

I'm really starting to doubt whether it's competitive to do your own thing anymore. And this seems to be getting worse.

Hard to compete with the combo of features & scaling that cloud provides. Attempting it pretty much guarantees you a gnarly trade-off somewhere (reliability, complexity etc).


You have to accept that a server may fail to be accessible, whether it's yours or Amazon's. If this is an issue you add redundancy.

When you load lots of resources from God knows where in a way such that any single failure takes the page down, you are reducing the reliability that you could have had if the resources were all in the same place which you concentrate on keeping available.


If your site runs on AWS, it should run on AWS, not on AWS + Google Fonts + React CDN + Github + ...

But actually, there's nothing wrong with adding dependencies, granted that you correctly do your risk assessment. Are those developers assessing their risks and making an informed decision to add them?


I agree on that, I just don't see fonts as critical for your site, provided that you have a fallback. But I see how hosting the fonts is pretty easy to do and you avoid one point of failure for the user experience.


> Imagine a user who can access your page but cannot access Google, the user then has to wait a long time looking at a blank page before the web browser stopped trying, that is some really really bad experience.

Not quite how web fonts work, usually they just swap in for the system fonts once loaded.


Yes, a well-designed system can minimize the impact by for example lazy-load the font file or even `Font Face Observer`[0] them for manual hot swap.

But that is not the main point. The main point is: You are the one who's in charge of the user experience, not Google. Don't shift the responsibility to somebody (external service) you don't have control of.

The software works the best when all it's parts are predicable, and make it more self-sufficient can help.

[0] https://fontfaceobserver.com/


Google’s own pages don’t do that, they intentionally hide the text until the font loads to prevent a “flash of unstylised content.” (It’s quite a bit longer than a flash on many connections, plenty long enough to start reading.)


Very important point. A major Austrian newspaper's web site currently doesn't work for me because I block FB's SDK. My choice in this case, but as a user I'm also at risk when FB can choose to block my browser and disable some (badly designed) web pages in the process.


On the other hand, self-hosting everything doesn't let you take advantage of caching.

What I mean is, if two sites use the same resource, and if both sites fetch the resource from the same URL, the resource will likely be cached by the browser once and reused again and again. This can be huge for load times when users visit a website for the very first time.

Or at least, this was the argument that was floating around in the community, when I used to do web dev. It's been a few years since, and I'd be interested to see if people have other arguments for/against this.


These are good points, but there are a few things to consider. First, as the article points out, self-hosting may result in a faster experience for your users due to the slowness of Google's font delivery. Secondly, your site is likely already serving up other assets which are not nearly as large as the fonts themselves (CSS, logos, other images, JavaScript, etc), so the savings is really not that large in comparison. Third, you can make use of cache-control headers that will ensure that all of these assets don't expire on the client's side for as long as you'd prefer.

One of the benefits of a CDN is the "N" part. If you host on a single server and you start getting requests from across the globe, those users will have a slightly more fluid experience if they can download the assets from a server that's physically closer to them than if they have to wait for packets to hop across dozens of nodes.


The odds of google being down / slow instead of your site are pretty bad.

Unless you build your own data center, pull in all the fiber yourself, make the network switches yourself, build the servers yourself, etc... you are always going to be dependent on a third party or external service.


Google is blocked in some parts of the world, so chance of "being down" is actually non zero if you think of the whole world.


Also, some webpages don’t even run on the internet.


True. Saw this issue first hand on a company internal network.


It's not instead of, it's an additional failure mode.


For years I blocked google-analytics.com because it was on the critical path for far too many pages loading.


The issue isn’t Google being down, it is my ISP’s connection to Google that might be subpar.

They might have a direct peering which is down and unexpected traffic is flowing though transit, you got BGP flaps, you got local CDN outages... and in the eyes of the customer your website is down, not Google CDN.


> The odds of google being down / slow instead of your site are pretty bad.

If my site is down, they already can't access it. Using Google Fonts just adds an additional failure probability, however small it may be.


Google has a reputation of shutting their services down. What if they shut their fonts CDN down or change their URLs without redirects?


This might not be end of the world. In a lot of cases convenience is worth the risks. There is no golden rule that one should never depend on third parties. It is always balancing pros vs cons.

Self hosting introduces extra code, resources and assets that you as a developer must introduce and maintain. This is not free.

Especially if worst thing that happens is a wrong font loaded.


Than a hell of a lot of sites lose their fonts until they update.


To be fair, lots of people being affected hasn't stopped Google in the past.

In the case of Fonts though, it's a good source of user and browser data, so it's not likely to be shut down any time soon.


I have this bookmarked that makes it very convenient to download a font from google:

https://google-webfonts-helper.herokuapp.com/fonts


I switched my blog over to self hosted fonts the other day; that helper made it so easy. Do notice the tabs and checkboxes, it has many options.


One thing I see is that it by default includes specific support for IE6-IE9, IOS before v5, android before v4.4 which definitely should not be the default these days. It should be an option, but not the default.


Creator here. Yeah, you can possibly switch to "Modern Browsers" by now. Haven't touched this project in a while...


Thanks, I use your web app for all my projects.


This is a great resource. Thanks for sharing!


If you have a worldwide CDN yourself, or you only care about local users, or your fonts are small (Latin subset), yes.

If you're using CJK fonts and you don't already have a CDN for your stuff, no. Google Fonts' CDN is going to beat your own server from any other continent.


An alternative is jsdelivr, a CDN for hosting open source libraries and fonts: https://www.jsdelivr.com

For example, here’s Lato: https://www.jsdelivr.com/package/npm/lato-font


But if you’re already loading your entire site from your server, what difference does it make if the fonts come from there too?


CJK fonts can be megabytes. The rest of an otherwise lean site can be a few hundred kilobytes or less.

E.g. my site's About page is tiny, but pulls in a CJK font (with delayed load) for one line of text. It would make no sense to self-host that: https://marcan.st/about/


A self-hosted font containing just those few characters would be tiny, and nicer to your visitors than forcing a mostly useless megabyte download on them. Makes a lot of sense.


K does not belong together with C and J in this case. If you are subsetting fonts to include the actually-used glyphs, the font file size for a typical Korean-language site will be considerably smaller than for a typical Chinese-language or Japanese-language site. That is, the active set of glyphs for Korean is much smaller even if the fonts you’d start the subsetting process from were about as large.

Self-hosting a Japanese font for one line of text is completely doable. I self-host all fonts for my site, which has a handful of CJK characters (across 4 fonts: Korean, Japanese, Traditional Chinese, and Simplified Chinese).


does it really make sense to load a large font for a single line of text on the page regardless if it is self-hosted or not? that must be one important line of text.


If you use a custom/download able font at all, it would make sense to use one copy (URL) - so every visitor only has to download it once - then use it from cache. This probably also the best reason to use a central CDN over your own - likely some other site already warmed up the client cache for you, with popular fonts (the ultimate in pre-warmed font cache, is of course the fonts the browser/os already have installed - unfortunately the lowest common denominator is a problem here, between Android, ios, os x, windows, Linux).

I'm not sure if Google font service actually does facilitate cross-site caching though - there might be tailored URLs or account?


The article already addresses that. Cross-site caching is blocked in Safari and will be blocked in Chrome in the future.


Jesus, why bother we a lean site with that mindset.

If it truly is a must make it a small (self-hosted) png.


Or better, just use a system font. Anyone who can read Japanese will have a suitable font installed.


Lol, his about page pulls a 1.42 MB font to display eleven characters in a light font weight instead of my system font. On a page that would otherwise be ~30 KB.


Eh, then it's no longer text?

Fwiw I don't really think a one-time large font download is much of a problem - considering that improved typography is a very good way to improve how a site looks. And unlike your png - the text will display without the custom font. Fall-back fonts are only really a problem with icon font sets.


It will read just fine. But no, I would not recommend it. But much rather that than a multi-megabyte one-liner.

One time. Per site. On slow and/or expensive mobile connection?

The png will also display without the custom font...


Png has poor screen reader support, though it can be amended via an alt tag, I suppose. [ed: but breaks copy and paste, which might be bad for an about page listing address and contact information - personally I'd much prefer fallback font to a png].

It's a shame there are no "bandwidth" queries in css, like there are @media queries - the client should be able to say - just content and essential downloads, please.


They’ve been proposed!: https://drafts.csswg.org/mediaqueries-5/#prefers-reduced-dat...

You can already do this with JavaScript now: https://developer.mozilla.org/en-US/docs/Web/API/NetworkInfo... though as you can see from the bottom of that link, Browser support is limited at the moment (and experimental so may even be removed/changed!).


Maybe the site owner has a CDN(CloudFront, CloudFlare, ...) in front of their whole website.


Wouldn't that cache font files along with the rest of the website?


[deleted]


Shared cache is going away: https://news.ycombinator.com/item?id=21429621


If you're using the C in CJK, then there's a good chance absolutely anything will beat Google Fonts since approximately 99% of your users have Google permanently blocked.


I read this question more generally as I have just revisited it myself in the past week.

For me this isn't just a question about Google Fonts. It's a question about jQuery and React and any common js lib off a CDN. And it's even a question about DLLs. glibc, zlib, .net. If it doesn't ship as part of your product, but your product can't work without it...

There's the problem of malicious replacement. There's the problem of disappearance. And various other problems.

On the other hand, there are all the positives. One upgrade at one URL and tons of dependent software gets a free security fix or performance fix or what have you. There's better caching. There's the speed benefit of CDNs. There's the lower memory consumption of DLLs.

This time around I have decided to self-host. But I don't think there's one right answer.


Better caching is no longer an advantage since they changed how caching works to prevent data leaks https://bugzilla.mozilla.org/show_bug.cgi?id=1536058


Looking at this, as an old fart who works in the kernel, I just can't help but wonder:

How is it possible that we have arrived at something this painfully slow? What are we getting from all these zillion resources a page is loading to make it worth the 3-6 second wait?

The static web of the 90s over dialup was faster than this.

I want my 28800 modem, pentium pro running netscape on FreeBSD 2.x, and static pages back. It was faster (with images disabled at least) than today's web with a 1Gb/s symmetric fiber connection, FF/Chrome on a MBP, even with ads blocked.


While I take your point about bloated web pages, I think you have a serious case of nostalgia viewed through rose-tinted glasses.

I recall the days of a 14k modem, and they were not pleasant, even for just text. And when you added images to the mix, it was just painful. Let's not even discuss videos...


He took it too far, granted, but overall there's a valid point. By coincidence, I'm writing an applicant tracking tool in rails+react now, and I also wrote one in perl about 16 years ago.

The modern app uses so many javascript libraries, 3rd party fonts, and is generally just so... ouch.

I remember demoing the perl app internally at my first job, and in many cases our page could render the page about as fast as it took to click. Our boss thought it was a static html demo just based on how fast it was.


I've had similar experiences, except it used to be PHP for me back in the day, rather than perl - I recall a servicedesk system, as well as a purchase order approval system, amongst many others. Not a single line of JS in sight!

But some of us never abandoned server-side rendering - I work a lot with ASP.NET Core MVC, and it's great; I'm very productive with it. But I do add Javascript on top here and there, where it adds value.


Those charts are using “3gslow” mode, simulating a ludicrously slow and lossy mobile connection. Also note that these fonts are loaded lazily and don’t have to block the page painting.


> Those charts are using “3gslow” mode, simulating a ludicrously slow and lossy mobile connection.

"3gslow" mode, unfortunately, accurately reflects the day-to-day connectivity most people see in non-capital cities around my country. It might be ludicrous, but it isn't necessarily far from the norm.


The internet was also just that little bit nicer then :) I miss those days ! :/


We ran into a rather large issue using Google Font CDN a few years ago. We were using Rubik font and pages were font was render as blank in certain browser combination.

They had to rollback, but there were a lot of escalations.

You can see the issue here. https://github.com/google/fonts/issues/1137

Self-hosting fixed the problem. We no longer use Google Font CDN.


Safari does more than other browsers to prevent cross domain tracking. 3rd party cookies disabled by default, cookies in iframes considered 3rd party (so, blocked), and TIL it maintains a separate local cache for each domain to prevent fingerprinting a user across domains. I have a hunch you could probably drop 3rd party cookies using a <video> element (maybe for DRM stuff? Just a hunch I have because video-ad CPMs are consistent or better on iOS over android/desktop indicating perhaps advertisers know the user somehow). Awesome article, great reference links, super interesting!


Good article, but the best solution to the font problem is to simply use native fonts:

https://www.smashingmagazine.com/2015/11/using-system-ui-fon...

This solves both privacy and performance problems and this is also what Bootstrap recommends now:

https://getbootstrap.com/docs/4.0/content/typography/


Long prose does not benefit from those fonts. A system font is usually used for UIs and is optimized accordingly. There's more to font selection than "use the same font as native applications".


I'm not quite sure what about e.g. Roboto or SF Pro Text isn't suited to long prose, or if you think OSes ship with just the font used for system UI (and not also dozens of others several of which were pretty much designed for longform text).


One time a Dell support install overwrote my Helvetica Neue font and it took me months to figure out why some sites looked absolutely terrible.

Not saying that you shouldn't use native fonts but man Dell threw a wrench into that idea for me.


It's a good idea to self-host ALL 3rd party assets. Otherwise you open yourself up to the possibility any one of those contains malicious code.

At the very minimum, always check the integrity hash of third party assets


In addition to this, If you have users that live in or travel to China, you want to self host. Unless you like broken websites.


Personally I block all third party fonts and have never noticed an issue with a plain old font. The web is so much nicer with a very restricted font set and range of sizes.


Only thing I've noticed breaking badly are symbol fonts that try to be clever with ligatures, so that e.g. "arrow_right" gets turned into an arrow symbol. Happens a bunch on Google documentation sites.


As is pointed out in the article for the most part fonts are a form of progressive enhancement and lacking the font normally doesn't actually break a website. Unless a little less pretty == broken of course.


As someone who browses with "browser.display.use_document_fonts=0", virtually no site breaks without its fancypants fonts.


I'd say that in 99% of the cases, your users would be better off and your site more useful, if you just used one of the standard fonts.


I love how this guy thinks. "Why does this font flash on pageload?" and then procedes a 5-page write up on the intricacies of fonts, caches and everything in between. Great write-up!


Free fonts aren't sufficiently better than the default system fonts to justify the slowdown. More people will leave your site because of the added microsecond latency than because "the font doesn't look good." You shouldn't use Google Fonts period.

https://practicaltypography.com/font-basics.html#why-use-pro...


That post doesn't come across as anything but pure elitism, it makes no real point and just claims "yeah system and free fonts are just worse".

Fonts like Roboto, Fira, Open Sans, Ubuntu, Merriweather or Vollkorn are all "professional grade" font families with lots of variants and options. Basic typesetting knowledge is going to get you much much further than buying a random professional font if you're designing "a document".


A while ago I routed Google Fonts to ::/0.0.0.0 in my /etc/hosts file. It makes pages load a little faster, and shows me which websites thought to provide a sensible fallback and which did not.


Some time ago I disabled all webfonts (ublock or umatrix) because I really don't care about stupid individual fonts and I thought I could save some bytes. Unfortunately that broke a lot of video-players (like netflix) because they use font-symbols for play/pause buttons etc.


Mm, to me that feels like an abuse of fonts — it's inaccessible at least. It makes me sad that they don't bother using the Unicode codepoints corresponding to those symbols if they exist.


I turned off custom fonts and find some websites are much nicer to read.


So the only thing that self-hosting would be missing is all the magic that Google is doing server-side to optimize the served files for the particular browser that is making the request.

Things like encoding (WOFF vs WOFF2) and font hinting need to be dynamically enabled/disabled based on the browser making the request to get the best possible result.

You can’t do that with self-hosting without writing some code.... that would be a great open source plugin to have, so that self-hosting could be done without any quality compromises.

Getting the right asset served to every browser was the reason I punted on self-hosting fonts last time I tried.

For example, I care much more about the page looking correct (legible crisp rendering fonts) than shaving 10Kb off the page size. Nothing is worse than the wrong font package causing blurry letters on 20% of your users’ devices.


So, to counter the point that "fonts only make the web look pretty," consider that font choice has a major impact on how accessible your website is.

For example, most people don't consider that the W and the M in your font must look distinctly different, and not just vertical mirrors of each other. That is a user inclusion choice, not just a "make it look pretty" or "make it on-brand" choice.


...rule one of accessibility is let the user configure how they access your content, and you just chose to override that. So that's a pretty weak excuse.


They can still disable custom fonts in their browser if they care. I have them disabled in Chrome.


Why "must"? What group is being excluded by this?


Dyslexics


> For example, most people don't consider that the W and the M in your font must look distinctly different, and not just vertical mirrors of each other.

Why isn't relying on default fonts provided by the user's system good enough for that?


I don't know what specific problem the parent is pointing to, but generally, users don't set up defaults, so you're really using the defaults of the vendor of whatever system the user uses. That may or may not be useful.

Tool customization may be where the users and power users are separated - but it's hard to tell who is who when you're just looking at an HTTP request.


At this point you have to self host assets, assuming their license allows that, if you want to comply with privacy regulation. If you don't have a signed legal contract with Google asserting they are not tracking your customers via embedded links, then you must assume they are doing so and you are out of legal compliance.


Another reason to self-host: Google will gladly change the font characteristics out from under you.

https://github.com/JulietaUla/Montserrat/issues/60#issuecomm...


If you use npm, there are packages for most (if not all?) google fonts via the Typefaces project, which makes them trivial to self host. https://github.com/KyleAMathews/typefaces


if you happen to use cloudflare, you can do this: https://blog.cloudflare.com/fast-google-fonts-with-cloudflar...


Honestly though, this is absolutely ridiculous that you have to do something this complex to fix something so simple. Why doesn't Cloudflare just build this in and let users toggle it on and off under their performance tab?


eventually i guess. if the interest is high. this is just an example of what cloudflare workers can do.


IMO: don’t force your users to load fonts. On slow connections they’ll read part of the page until suddenly the font loads and everything gets rearranged. Worse is what google does: hide the text with JavaScript until the font loads so the whole page takes eons before you can read it.

If there’s a font with identical metrics that most people have installed then fine, otherwise don’t be a dick to people on bad connections.


Besides performance and other completely technical reasons, in my view it is mostly a question how dependent an individual or a company wants to be.

Of course it can be technically and operationally convenient but it also means that now you are even more dependent on the fickle choices that Google makes that is per definition in their own interests.


Surprised I didn't see that point mentioned: If you self-host Fonts ("Google Fonts" is ultimately just a collection of open source fonts) it's one less thing to care about regarding privacy laws, sharing data with third parties and potentially having to justify due to GDPR etc.


From the post: “That leads nicely into the privacy implications of using third-party CDNs. You have no idea what sort of tracking they are doing to your users by using them, rather than self-hosting. And recent legislation means a lot of sites have to explicitly list all the cookies used on the site, which gets more complicated when using a third-party.“


Will some of the fonts already be available if you've visited other Google sites?


In the past this may have worked. But it won't anymore since browsers have introduced partitioning by origin in their caches. https://www.jefftk.com/p/shared-cache-is-going-away.amp


The article argues that it's unlikely, with IMHO good reasons given.


If you're in the EU you might want to self-host the fonts (and other assets!) anyway for GDPR compliance - technically, loading any 3rd party asset exposes the visitor's IP address plus any possible tracking cookie plus the exact URL of the website your visitor is reading to the provider.

Google might say they're not doing any tracking on the fonts, but I don't believe them at all.


What’s the current thinking on stashing fonts in localStorage for FOUT reduction?


What would be the advantage over loading the fonts from the browser cache?


Seems rude to take up space in the browser that won't automatically expire.


Probably better to split your font, and put your critical glyphs somewhere fast. Plus localStorage limits are very low, a couple decent sized fonts will blow your budget.


Is IndexedDB bigger? Why not use that?


You can. Another thing you can do is setup a service worker and intercept requests to Google Fonts, responding with an entry from cache or indexeddb instead.


That service worker stuff doesn’t work in iOS Safari though

Can service workers intercept requests to other sites?


It does since like 11.1.

Yes, SW can cache all resources. This is how offline PWAs work.


Talkin about WebView


localStorage at least historically is painfully synchronous and in some cases it has to be fully loaded from disk before the page's JS can run. So if you're sure you're going to be using the font on every page I guess you can eat that load penalty, but then you have to deal with the size limit for localStorage (~2mb worst case, iirc), and also go to the trouble of doing string encode/decode to get the raw font bytes, then shove the font bytes into a blob and get a url for the bytes so you can finally load the font.

At the end of that whole song and dance you've wasted a bunch of CPU and probably wall clock time being clever. Not sure it'd be faster than just hosting the files locally the regular way.


Should you use Google fonts?


Google-Fonts could be made part of Google-Chrome and would never be downloaded ever again for Chrome Users


There are a lot of fonts on Google Fonts that are many GB in size if you’d include them all.


You should host everything yourself.


I’m about to switch to self hosting so the font will load in mainland China.


Sure if you/your clients don't want be tracked.


Another reason would be to simplify CSP configuration.


you should self host EVERYTHING


But wouldn't that stop Google from putting ads into their fonts and AMP into URLs? Does anybody self-host Gmail?


Step 1) get a degree to jerk around with docker all day for money

Step 2) realize that this computer shit is hard

Step 3) let google do it instead


In a word; yes.


I believe stuff like this is what localstorage was for




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: