And yet the site itself embeds googletagmanager.com and cloudflareinsights.com assets. Oh, the irony.
import { Roboto } from '@next/font/google'
const { className } = Roboto({ weight: '500' })
Now you can add this class name to any React elements and they'll have the Roboto font. Next.js will handle all of the self-hosting and wiring behind-the-scenes (i.e. no requests made to Google from the client).Believe this was one of the announcements to come out of the most recent Next.js conference, so info may only be available on the beta version of their docs site (linked above).
https://fontsplugin.com/google-fonts-checker/?test_id=19110
[Params]
selfHosted = true
in the top-level config.toml.One piece of feedback – it's not great that the `test_id` is a small sequentially generated integer; it's trivial to iterate across all of the URLs that have been tested.
Hosting fonts locally is something i've advocated since the beginnings of Google Fonts.
Apart from the stated benefits it also means fewer DNS lookups i.e. yet another point of failure gone and yet another privacy bonus. It's not just google that can spy on you, also your ISP.
PS: It's not just Google Fonts, this applies to all fonts stored on CDNs.
Sadly, it's typically not as easy as just putting some font files in a directory on your web server if you want to do it right. Edit: or rather "as well as possible", it's not like the below is absolutely necessary.
You'll probably want TTF, WOFF and WOFF2 formats set up, so all of your font variations will need to be converted, for example, with: sfnt2woff and woff2_compress Of course, all of those will need the corresponding @font-face elements in CSS as well, so that they can be used in the page: https://developer.mozilla.org/en-US/docs/Web/CSS/@font-face
Not only that, but you should also consider splitting up fonts based on what character sets are used, so that cyrillic characters, for example, would only be downloaded if you have them on the page, otherwise making your users only fetch latin or whatever is going to be there most of the time.
Google Fonts actually does this with "unicode-range", for example: https://fonts.googleapis.com/css2?family=Open+Sans&display=s...
More information: https://developer.mozilla.org/en-US/docs/Web/CSS/%40font-fac...
All of this can bloat your CSS a lot (which is still better than just downloading one huge font with everything included in many cases, but is not good because you have to write the CSS somehow), especially if your font has multiple different variations, such as light, regular, medium, semi-bold, bold and extrabold, or variations like condensed or semi-condensed.
Here's an example of the full CSS (without condensed and such variations) for Open Sans: https://fonts.googleapis.com/css2?family=Open+Sans:ital,wght...
That's 960 lines that I haven't found many tools for doing automatically (oh and that file only provides WOFF2 formats). For example, if I wanted to do the same for the PT Sans fonts that I enjoy, but for usage locally: https://fonts.google.com/specimen/PT+Sans
The URLs that Google Fonts give you also seem somewhat arbitrary, so you'd probably need a bit of scripting to figure out what any given one of those fonts is, were you to try and download them and rename them for your own needs:
https://fonts.gstatic.com/s/opensans/v34/memvYaGs126MiZpBA-UvWbX2vVnXBbObj2OVTSCmu1aB.woff2
Then again, many don't care and it's good enough for them to just throw a TTF or a simple WOFF2 file for the regular font variation and waste a bit of bandwidth (or use the browser's own pseudo-bold/italic implementation instead of separate font files).This is especially important to be GDPR-compliant in Europe.