Our feature for speeding up your page load if you use Google Fonts

Does your website belong to huge majority that use Google Fonts? Did you know that as soon as you start using externalised fonts such as Google Fonts, you run the risk of performance problems linked to Third Parties? Google Fonts are, in fact, part of the critical page rendering path: they are a required resource for text display.

In addition to our dedicated fonts optimisations, we have one that will allow you to save (even more) precious milliseconds in the load time of your web pages. Thanks to this feature, your users will no longer be obliged to wait for the CSS file to load for the text to appear.

Google Fonts: win the race against time by limiting your use of API

We have already developed different features for optimising fonts and tackled techniques to ensure that they load as quickly as possible, but we have identified certain problems specific to Google Fonts, the basic issue being the frequent use of API to load and display fonts.

How does Google Fonts operate? By adding a font to a website, you add a CSS file which is retrieved from the fonts.googleapis.com domain. It includes font definitions in the following format:

@font-face {
 font-family: 'Open Sans';
 font-style: normal;
 font-weight: 400;
 src: local('Open Sans Regular'), local('OpenSans-Regular'), url(https://fonts.gstatic.com/s/opensans/v17/mem8YaGs126MiZpBA-UFWZ0bbck.woff2) format('woff2');
 unicode-range: U+1F00-1FFF;
}

This CSS file optimises the font files (such as the .woff2 file in the above example) that are necessary for the page, the fonts themselves being accessible from the fonts.gstatics.com domain.

Given that the CSS file and the font files must be loaded in order to allow display (without this the browser would have no idea which fonts to use), the whole loading process of these files must be executed as quickly as possible so that the first page rendering is effective and browsing is smooth.

We will now look at font loading in detail. For each one, loading requires the following 4 steps:

DNS resolution in green - Connection establishment in yellow -
TLS negotiation in pruple (for HTTPS) - Request in green and orange

These 4 steps are carried out for the CSS and then for the fonts file. There are therefore 8 steps for a font.

So, how can you save some time?

Avoid having one CSS file per font. Put everything in the same file.
Anticipate the resolution, connection and negotiation for the fonts.gstatics.com domain.
Pre-load the fonts as soon as possible.
Allow the choice of text display, even if the font is not yet known.

Have a behind-the-scenes look at our engine: non-blocking asynchronous loading, concatenation and pre-connection

On a technical level, this is how our engine works:

CONCATENATION OF THE USE OF GOOGLE API

The URLs are “factorised” so that the Google API is used only once. All the fonts present on a page can thus be loaded at the same time.
In practical terms, what changes are there in the page code when our users activate the Google Fonts feature from their Dashboard?

Quite simply, our engine converts this type of tag in order to load the Oswald and Rotovo fonts here

<link href='https://fonts.googleapis.com/css?family=Oswald:400,700,300' rel='stylesheet' type='text/css'>
<link href='https://fonts.googleapis.com/css?family=Rotovo' rel='stylesheet' type='text/css'>

Into:

<link href='https://fonts.googleapis.com/css?family=Oswald:400,700,300|Rotovo' rel='stylesheet' type='text/css'>

**PRE-CONNECTION ON THE FONTS.GSTATICS.COM DOMAIN**

Fasterize establishes a pre-connection on the fonts.gstatics.com domain which is the one where Google actually retrieves the fonts after using the API (not googleapis.com). To do this, we insert this tag before the Google Fonts CSS declaration file:

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

So, when the fonts file has to be loaded, the DNS resolution part, establishing a connection to the gstatics.com domain and the TLS negotiation will already have been processed.

These two graphs illustrate the TLS pre-connection process:

NON-BLOCKING ASYNCHRONOUS LOADING OF CSS FILE

You can choose to activate asynchronous loading of the CSS file or not, in particular if you want to avoid a SPOF. All you need to do for this is add the following attributes to the link tag for loading the CSS:

“media="print" onload="this.onload=null;this.media='all'"

Thanks to these attributes, the CSS file is pre-loaded and the “screen” media is replaced by “print”. Once the page has loaded, “print” is replaced by “all” so that the CSS applies to all media.

Our tag for loading the font’s CSS file thus becomes:

<link href='https://fonts.googleapis.com/css?family=Oswald:400,700,300|Rotovo' rel='stylesheet' type='text/css' “media="print" onload="this.onload=null;this.media='all'">

WHY NOT UNSHARD THE GOOGLE FONTS OR HOST THEM DIRECTLY?

Unsharding the Google Fonts directly on the main domain would, in fact, be ideal. This would save a network call and a CSSOM recompilation. However, this is not straightforward because the Google API generates different versions of the CSS file according to the browser’s possibilities (WOFF2 and Unicode-ranges support) but also according to the OS (Windows/Mac), the subset and the various font attributes (bold, italic, strikethrough, etc.).

Because our CDN does not manage as many different versions according to the User-Agents, we would therefore be obliged to prepare thousands of non-specific CSS files in advance for the fonts available on Google Font, in the same way as https://google-webfonts-helper.herokuapp.com/fonts. We did not wish to take this option which is difficult to maintain.

CHOICE OF FONT-DISPLAY ATTRIBUTE

For fonts that have no display value (recently introduced by Google Fonts), we add the swap value (or any other value that you may define) by default. Why? Because in the absence of a value, the block value is used by default and blocks the text display if the font has not been loaded. This swap value allows you to display the text with a default font before the Google font is loaded. This is always better than a blank page!

<link href='https://fonts.googleapis.com/css?family=Oswald:400,700,300|Rotovo&display=swap' rel='stylesheet' type='text/css' “media="print" onload="this.onload=null;this.media='all'">

One of the beneficial effects of font display is that almost 1 second is gained on the First Meaningful Paint:

Using Google Font's new display param saved us 800ms on First Meaningful Paint @addyosmani @SpeedCurve #webperf pic.twitter.com/Oa9HpXtzC3

— Josh Deltener (@hecktarzuli) May 16, 2019

But what happens if some fonts already have a display value which is not the same for all fonts?

If some fonts have a display value and others do not, we concatenate only those with no display value. So there is much to be gained from harmonising values beforehand. We suggest that you do not indicate any display value but let the Fasterize engine deal with adding them.
This is also true for the other Google Font settings (subset, text): thus a font declared with a specific subset would never be used in a concatenation. The same applies to a font in which the number of characters to be loaded is limited by the text setting.

Our Google font optimisation feature is already in use on several websites which we are speeding up. Load times are thus reduced. Below is a video of an example: the menu text at the top is displayed more quickly thanks to the swap option, and the asynchronous CSS allows time for other resources displayed in the viewport to be loaded.

Now that you have had a look behind the scenes of Google Fonts loading optimisation ...

Are you interested in trying out this option,
or one of the many intelligent features that can improve your load time?

Articles similaires