X
Popular Searches

Speed Up Your Website in a Few Minutes By Enabling Web Font Display Swapping

Font comparison.

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 begining 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:

@font-face {
  font-display: swap;
}

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:

https://fonts.googleapis.com/css?family=Lobster&display=swap

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:

<link rel="preconnect" href="https://fonts.gstatic.com/" crossorigin>

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.

Anthony Heddings Anthony Heddings
Anthony Heddings is the resident cloud engineer for LifeSavvy Media, a technical writer, programmer, and an expert at Amazon's AWS platform. He's written hundreds of articles for How-To Geek and CloudSavvy IT that have been read millions of times. Read Full Bio »

The above article may contain affiliate links, which help support CloudSavvy IT.