A Nice Big Headline in Delicious Roman
A sweet and smaller heading in Delicious Bold
Base64 encoding EOT font files (inlining in CSS)
This page uses two fonts for the headings: Delicous Bold and Delicious Roman.
The EOT font files (for IE6 and IE7) are each ~ 42 KB, 84 KB in total.
Inlining these fonts with base64 encoding in the CSS makes the total weight for these fonts ~ 117 KB, a good 39% larger.
Gzip to the rescue
The 2 external font files Gzipped are ~ 46 KB.
Gzip brings the inlined/base64 encoded fonts file size down to ~ 60 KB, which is 14 KB and 30% larger.
The 30% is quite large, but 14 KB extra will not increase page load time in a noticeable way (~ 40 ms on a 3000 kbps down connection).
Conclusions
- Encoding the fonts with base64 and inlining in the CSS increases file size with ~ 30% (14 KB) for the EOT files , with Gzip on!
- Without Gzip, the increase in file size for the 2 EOT files is 43 KB (note: on average, 15% of users request the HTML and CSS uncompressed, so be aware of the 'without-gzip' scenario)
- EOT is for IE6 and IE7, the slower desktop browsers. The benefit of saving the 2 HTTP requests by inlining the fonts can be significant for users with these browsers.
- The Main Question: will base64 encoding and inlining the fonts improve the user experience? I think yes:
- IE6 and IE7, users are more likely not to experience the nasty FOUT or FOUC.
- If you inline the CSS in the HTML, the initial rendering of the page will not be delayed, because downloading the extra 'base64' bytes will take less or same amount of time as downloading the external font files (mainly because of the costs of setting up the connection and network latency)
- Must read: Gzip your @font-face files and @font-face gzipping - take II.