Following a healthier, lighter diet also applies to CSS, and the latter will become heavy if it has to put up with base64-encoded fonts. Fasterize helps you optimize your loading times by outsourcing fonts instead of embedding them in CSS, a critical resource that the browser needs to load as quickly as possible. The result? Pages are displayed faster thanks to a better Start Render.
A new feature to speed up the loading time of your pages
Fasterize aims to help its customers implement the best web performance practices and standards. In order to follow our fonts optimization, our engine now allows the extraction of fonts included in the @font-face rule of the CSS.
Inlining fonts was a widespread practice until recently, even though the arrival of HTTP/2 and font-display made it even more counterproductive. As early as 2015, Bram Stein was already reporting the limits of this process on his blog.
Why and how activate inlining font correction with Fasterize
If you want to activate the inlining fonts correction, simply go to your Dashboard:
Inlining fonts, an optimization that actually has the opposite effect
Where fonts inlining historically comes from: this practice was popular at the time of HTTP/1, to reduce the process of rendering the page by reducing the number of requests.
Why reduce the number of requests? Because with HTTP/1, a browser can only download a limited number of resources in same time. Each new TCP connection takes time, which causes additional delay to display the texts. Thus, when all fonts are combined in the same stylesheet, there is only one connection. Text rendering is slower, but the advantage is that all fonts are available at the same time when the page is displayed - and that’s actually one of the only advantages.
First notable disadvantage of inlining: some browsers may need to wait several seconds for fonts to be available before rendering the page. Therefore, in case of error or timeout, the SPOF (blank page) is inevitable.
No more progressive render and lazyloading (and dessert)
On his blog, Bram Stein illustrated - see timeline here below - the disadvantage of inlining fonts. In the case where the bandwidth is not saturated, there is a real difference in download.
This first visual shows how fonts are loaded when they are not inlined. We observe a in parallel download and a display as soon as the loading is finished for each of the fonts A, then B, then C:
Downloading external fonts in parallel
If these 3 fonts are inserted in the same stylesheet, here below is the appearance of the Waterfall. The browser only downloads a single CSS file that is much heavier. It takes more time to load than if there were 3 separate font files downloaded in parallel:
Downloading inlined fonts in sequence
Considering that many browsers allow up to 8 downloads per domain in HTTP/1, and virtually unlimited HTTP/2, having all fonts in one file while a browser can download multiple resources simultaneously has little interest.
Specifically, inlining fonts prevents the benefits of parallel downloads, progressive rendering and lazyloading. Indeed, fonts can only be displayed once they are all available ... once the stylesheet is loaded.
Additionally, all fonts are downloaded even if they aren’t useful on the page: loading unnecessary resources does not help in any way.
One possible font format: WOFF
Additional disadvantage of inlining fonts: it is limited to a single font format for web. Because the whole font file is built into the CSS, support for another format would further increase its size (the same font is stored once per format).
The only possibility is to serve the font format wich is the most broadly supported by browsers: WOFF. So forget about WOFF2 and its much higher compression rate.
Ineffective base64 encoding
Another disadvantage of inlining: base64-encoded files are on average 30% larger than the binary version, as you can see on the following graph:
Average size of a WOFF file based on the analysis of a corpus of 20,000 files.
The base64 encoding for a WOFF file increases its size by about 30%,
but Gzip compression almost reduces it to its original size.
Fortunately Gzip helps a little. The other disadvantage of base64 is that it requires a lot of decoding time on mobile phones, particularly on medium to low range devices whose CPUs are weak.
Caching affected
Inlining also has a negative impact on caching. If you update one or more fonts in your stylesheet, you will need to invalidate the browser cache for the entire stylesheet (for example, by changing its name). Your users will then have to download the CSS file containing all the fonts, once again, even if most of them haven’t changed.
Whereas if the font files were served and cached as individual files, only the updated font file could be downloaded again, and the other files could remain cached. Undeniably, the inlining is not advantageous either for internet users (to say things nicely).
Unusable font-display
Last but not least in the long list of disadvantages, inlining fonts makes font-display obsolete. This is a shame because it would allow precisely to avoid the SPOF, since it is applied to @font-face rule, it defines the way the browser behaves before and during the download of the fonts.
You got it, we really do not recommend inlining fonts. To conclude, let’s have a look at a customer case study of an e-commerce website which we accompanied in the improvement of loading times.
Case study: what we implemented
On our client’s website the fonts were inserted into the CSS file, which obliged the browser to download them all, whether they were used on the page or not. The timeline here below pictures a heavy file (947 KB) taking a considerable time to load:
Thanks to the correction of the fonts inlining, the weight of the file has been reduced drastically to less than 100k, allowing the browser to load only the fonts which are useful for the page:
Tests done with WebPageTest with Chrome on a mobile using 3G
The impact is even more visible on this video : on the left a "non-fasterized" version of the website, in the middle a version optimized by Fasterize but without correction of inlining fonts, and on the right a "fasterized" website with correction of the inlining fonts.
Now if you are still wondering what's going on technically in your stylesheet … Here is an overview:
The src attribute will reference a file built by Fasterize from the inlined file or from another non-inlined source.
If you have any questions about this new feature, our webperf experts will be happy to help!
Would you like to discover all our features dedicated
to intelligently automate the optimization of your loading times?
