Webfonts are a great way to add a bit of personality to your website, but they can also slow down your page load time. If you’re looking to speed up your website, you can enable web font display swapping. This feature allows you to swap out the default web fonts with custom fonts that are faster to load. ..
Website optimization is crucially important for ranking well in Google and other search engines, and when you’re competing with the rest of the world, every millisecond counts. Deferring the loading of your site’s fonts can give you a slight boost.
Web Fonts Are Render Blocking
If a resource is render-blocking, it must be loaded before your site reaches its first contentful paint. Render-blocking resources should be kept to an absolute minimum for any optimized site.
The downside here is obvious—if a client must load additional resources before your site loads, they’ll need to make an extra-secure connection and TCP handshake before even beginning to download the render-blocking resource, which can add hundreds of milliseconds to load times on mobile. If you’re loading large blocking resources, you’re also putting your load times at the mercy of the other host.
The solution is to change the way the fonts are handled. By default, fonts are not optional, and all text is blocked until it can be rendered with the correct font. But all users have default fonts installed like Arial and Times New Roman, so it’s possible to display those fonts first and then swap to the web font once it’s loaded.
You can specify this behavior in your @font-face directive using the font-display parameter:
If you’re using Google Fonts, however, the font-face directive will be defined in the CSS file they give you to add the font. Thus, you can’t edit it directly, but luckily Google has recently added support for font-display: swap in the API. It should be set by default if you’re adding a new font, but if you added the font a while ago, you can update it by adding the &display=swap URL parameter on the end:
That’s all you need to do. Once the font is set to swap, it will stop render-blocking. You may notice your site loading in the default font before quickly flashing to the updated one; to minimize this issue, find a default font that most closely matches your main web font. Most desktop users probably won’t notice it alongside the rest of the page load, though if the user is on a slow mobile connection, they may notice the font popping in a second later.
If you aren’t trying to squeeze out every millisecond of performance, you can use a different option: The font-display: fallback option will render block for a short amount of time (not more than 100ms in most browsers), then fall back to swapping whenever the font decides to load. This gets rid of the flashing issue for most desktop users with good connections but does add a worst-case ~100ms (browser depending) load time if the font doesn’t load in time.
Preconnect fonts.gstatic.com
This tip doesn’t affect the render-blocking aspect of web fonts, but it does speed up Google Fonts in particular.
When a client needs to fetch a resource from another origin, they must perform a TCP handshake and (if the site was created anytime this decade) establish a secure HTTPS connection. Doing so takes time, so performing unnecessary round trips will slow downloads.
This is exactly what Google Fonts do. First, the CSS stylesheet from fonts.googleapis.com is loaded with all the info about the fonts. The src parameter of the font face is then read, and the client connects to fonts.gstatic.com to download the font. The problem here is that the font file we want is gated behind the CSS stylesheet on another origin.
To solve this problem, you can preconnectfonts.gstatic.com. Preconnecting is a special link option that tells the browser to go ahead and perform the HTTPS handshake before it has been given a link to open. It cuts down considerably on the latency of performing two round trips like this.
You can preconnect with the following link tag:
The crossorigin parameter tells the browser to perform an HTTPS handshake, rather than a simple DNS lookup (the default behavior).
If you’re serving fonts yourself, you’ll want to make sure your Cache-Control headers are set properly so that your fonts are loaded from cache when a user visits again. You may also want to consider using a CDN if you want to host fonts yourself, as it will cut down on the latency on static object requests.
