#BASE64 ENCODING SIZE INCREASE DOWNLOAD#

The base64 encoding for a WOFF file increases its size by about 30%,īut Gzip compression almost reduces it to its original size.įortunately Gzip helps a little. Ineffective base64 encodingĪnother disadvantage of inlining: base64-encoded files are on average 30% larger than the binary version, as you can see on the following graph:Īverage size of a WOFF file based on the analysis of a corpus of 20,000 files.

So forget about WOFF2 and its much higher compression rate. The only possibility is to serve the font format wich is the most broadly supported by browsers: WOFF. 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). One possible font format: WOFFĪdditional disadvantage of inlining fonts: it is limited to a single font format for web. once the stylesheet is loaded.Īdditionally, all fonts are downloaded even if they aren’t useful on the page: loading unnecessary resources does not help in any way. Indeed, fonts can only be displayed once they are all available. Specifically, inlining fonts prevents the benefits of parallel downloads, progressive rendering and lazyloading.

#BASE64 ENCODING SIZE INCREASE DOWNLOAD#

It takes more time to load than if there were 3 separate font files downloaded in parallel:Ĭonsidering 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. The browser only downloads a single CSS file that is much heavier. If these 3 fonts are inserted in the same stylesheet, here below is the appearance of the Waterfall. 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: This first visual shows how fonts are loaded when they are not inlined. In the case where the bandwidth is not saturated, there is a real difference in download. On his blog, Bram Stein illustrated - see timeline here below - the disadvantage of inlining fonts. No more progressive render and lazyloading (and dessert) Therefore, in case of error or timeout, the SPOF (blank page) is inevitable. 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.įirst notable disadvantage of inlining: some browsers may need to wait several seconds for fonts to be available before rendering the page. Thus, when all fonts are combined in the same stylesheet, there is only one connection. Each new TCP connection takes time, which causes additional delay to display the texts. Why reduce the number of requests? Because with HTTP/1, a browser can only download a limited number of resources in same time. 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. Inlining fonts, an optimization that actually has the opposite effect If you want to activate the inlining fonts correction, simply go to your Dashboard: Why and how activate inlining font correction with Fasterize As early as 2015, Bram Stein was already reporting the limits of this process on his blog. Inlining fonts was a widespread practice until recently, even though the arrival of HTTP/2 and font-display made it even more counterproductive. In order to follow our fonts optimization, our engine now allows the extraction of fonts included in the rule of the CSS.

No more progressive render and lazyloading (and dessert)Ī new feature to speed up the loading time of your pagesįasterize aims to help its customers implement the best web performance practices and standards.

Inlining fonts, an optimization that actually has the opposite effect.

Why and how activate inlining font correction with Fasterize.

A new feature to speed up the loading time of your pages.

Base64 encoding size increase