Vendor Google fonts in #4864
Vendor Google fonts in #4864
Conversation
|
This patch used `google-font-downloader`[1] to generate a fonts directory that contains the used Google fonts for shields.io. There are bunch of reasons for vendoring fonts in, but the first and most important one is privacy.[2] Another is performance.[3] And the third one is reducing external dependencies. Keeping those small helps to prevent unexpected breaking of web interfaces just due to changes or failure of an external service provider. [1]: https://github.com/Bloggify/google-font-downloader [2]: google/fonts#1495 [3]: https://csswizardry.com/2019/05/self-host-your-static-assets/
SISheogorath
force-pushed
the
feature/vendored-fonts
branch
from
08cb8c7
to
9947abb
Compare
|
Hi! Thanks for this contribution. I'll be curious to hear others' thoughts on this. Here are a few of my own. Reducing repo dependencies is almost a non-goal for Shields. We try to be judicious about what we maintain ourselves. For example, we avoid maintaining our own logos; instead we pull them in from Simple Icons. Adding dependencies is often a good way to avoid maintenance work. That said, reducing external runtime dependencies for the user of the website is a reasonable thing to consider. This is especially true for people who host their own copy of Shields. I can totally seem self-hosting users preferring to host their fonts themselves. To accommodate that, I'd be happy to include tooling which runs google-font-downloader at build time, and either making it opt-in for self-hosting users, or maybe even turned on by default (though not necessarily turned on for https://shields.io, see below). For users of https://shields.io/ I am not sure hosting the fonts ourselves improves performance. It seems likely it would reduce performance. If the fonts are already in their browsers' cache from Google Fonts, which is likely, they would be redownloaded. Also, I think the cache would be invalidated on each deploy, unless we did some extra work to ensure longer cache timeouts on those assets, meaning the fonts would frequently be redownloaded. Privacy and regulatory compliance is another matter. If there's an argument to be made that Shields' no tracking promise means the public website shouldn't depend on Google Fonts, that decision probably should happen in an issue first. |
paulmelnikow
added
frontend
|
Feel free to open an issue to discuss further! |
This needs real live testing and not guessing.
I don't think so. Setting good cache header is far more important to not generate to many requests.
Which is kinda unlikely since Chrome 77. See https://www.chromestatus.com/feature/5730772021411840 . Cache isn't global anymore so I would have to visit shields.io to cache the font.
Stick a cache-control or etag header on the response and don't change the URL with each deploy. Does not sound as hard to do. |
This patch uses the fontsource libraries instead of using Google Fonts in order to provide the fonts in the frontend. This way the web frontend becomes more private, since it no longer shared visitors IPs with Google and might even loads faster since modern web browsers isolate site caches from each other and can re-use connections with HTTP/2 instead of setting up a new connection to Google.[1] It's basically the next iteration of my previous PR[2], that no longer relies on a tool to download the fonts separately, but uses a library instead. It also relates to issues that have been opened before[3] and should be easily handled and upgraded by the regular NPM package tooling[4], solving all related problems to that. [1]: https://csswizardry.com/2019/05/self-host-your-static-assets/ [2]: badges#4864 [3]: badges#5883 [4]: https://github.com/badges/shields/labels/dependencies
This patch uses the fontsource libraries instead of using Google Fonts in order to provide the fonts in the frontend. This way the web frontend becomes more private, since it no longer shared visitors IPs with Google and might even loads faster since modern web browsers isolate site caches from each other and can re-use connections with HTTP/2 instead of setting up a new connection to Google.[1] It's basically the next iteration of my previous PR[2], that no longer relies on a tool to download the fonts separately, but uses a library instead. It also relates to issues that have been opened before[3] and should be easily handled and upgraded by the regular NPM package tooling[4], solving all related problems to that. [1]: https://csswizardry.com/2019/05/self-host-your-static-assets/ [2]: badges#4864 [3]: badges#5883 [4]: https://github.com/badges/shields/labels/dependencies
This patch uses the fontsource libraries instead of using Google Fonts in order to provide the fonts in the frontend. This way the web frontend becomes more private, since it no longer shared visitors IPs with Google and might even loads faster since modern web browsers isolate site caches from each other and can re-use connections with HTTP/2 instead of setting up a new connection to Google.[1] It's basically the next iteration of my previous PR[2], that no longer relies on a tool to download the fonts separately, but uses a library instead. It also relates to issues that have been opened before[3] and should be easily handled and upgraded by the regular NPM package tooling[4], solving all related problems to that. [1]: https://csswizardry.com/2019/05/self-host-your-static-assets/ [2]: #4864 [3]: #5883 [4]: https://github.com/badges/shields/labels/dependencies
This patch used
google-font-downloader[1] to generate a fonts directorythat contains the used Google fonts for shields.io. There are bunch of
reasons for vendoring fonts in, but the first and most important one is
privacy.[2] Another is performance.[3] And the third one is reducing
external dependencies. Keeping those small helps to prevent unexpected
breaking of web interfaces just due to changes or failure of an external
service provider.
1: https://github.com/Bloggify/google-font-downloader
2: google/fonts#1495
3: https://csswizardry.com/2019/05/self-host-your-static-assets/