Host fonts/icons locally, instead of fetching them remotely with Google Fonts #58
Conversation
celenityy
commented
Aug 9, 2025
celenityy
commented
- Improves privacy by preventing unwanted connections to third-parties, and prevents Google from tracking users (For reference, Google Fonts has been found to violate the GDPR: https://wptavern.com/german-court-fines-website-owner-for-violating-the-gdpr-by-using-google-hosted-fonts).
- Prevents the website from appearing ugly for users who block third party fonts.
- Improves performance and reliability.
- Improves privacy by preventing unwanted connections to third-parties, and prevents Google from tracking users (For reference, Google Fonts has been found to violate the GDPR: https://wptavern.com/german-court-fines-website-owner-for-violating-the-gdpr-by-using-google-hosted-fonts) - Prevents the website from appearing ugly for users who block third party fonts - Improves performance and reliability Signed-off-by: celenity <[email protected]>
|
|
Signed-off-by: celenity <[email protected]>
Signed-off-by: celenity <[email protected]>
lberrymage
left a comment
lberrymage
left a comment
There was a problem hiding this comment.
I really like this change, thank you. My main comment is on how we should bundle and source the font files to facilitate 1) easily automated font version upgrades, 2) long-term caching and 3) keeping binary files out of source control.
| "src/material-icons.css", | ||
| "src/roboto.css", |
There was a problem hiding this comment.
I think these should be in "styles" (line 33) rather than "assets" so they can be minimized.
| "src/material-icons.css", | ||
| "src/roboto.css", |
There was a problem hiding this comment.
I think these should be in "styles" (line 140) rather than "assets" so they can be minimized.
There was a problem hiding this comment.
For all of the added font files, I think it would be best to keep the original file names and paths instead of creating our own for a couple of reasons:
- The original filenames are sufficiently randomized for cache busting, so if we use them we can cache the font files indefinitely. Google does this themselves: Cache-Control for the font files is set to 1 year.
- The original paths reflect that the upstream font files are versioned. We will want to update the font versions over time as part of our CI process, and if we simply replace the original files, we can no longer cache them indefinitely since browsers would never pick up the new versions.
|
|
||
| <!doctype html> | ||
| <html lang="en"> | ||
|
|
There was a problem hiding this comment.
nit: These whitespace changes aren't really necessary.
There was a problem hiding this comment.
We may want to find a way to pull in the font files during build time rather than vendoring them directly into the source repository. This could 1) help us automate version upgrades and 2) reduce the number of binary files we're checking into VCS. Perhaps we should look into something like Fontsource?
3 participants
