Speed Up Your Bootstrap and Font-Awesome Sites Using Font Compression
Twitter Bootstrap and it’s frequent add-on Font-Awesome have gained tremendous popularity in recent years due to the relative ease these libraries provide for building good looking, responsive websites. So much so that here at Zoompf we’ve seen the same performance problem appear again and again: uncompressed font files.
Of course, uncompressed font files are not specific to bootstrap or font-awesome – in fact this problem is quite common! Still, I call out these 2 particular libraries due to their popularity and the pervasiveness of this problem. Font files come in many shapes and sizes, but the easiest way to spot them is to look in your CSS files for includes to files with these extensions: SVG, EOT, WOFF, TFF and OTF. (And there are many more).
Here’s the dirty little secret about fonts: almost all of them can benefit from HTTP compression, and most webservers do NOT compress font files by default. SVG, for example, is entirely defined in XML, which is highly compressible! In the example I’ll show below, just the one font file fontawesome-webfont.svg can be reduced by 179 kb.
So let’s take a hands-on look. To begin, I launched a test Amazon 64 bit linux instance running Apache2 in a manner similar to my earlier blog post about mod_pagespeed.
After installing the base Apache 2.2 image provided by Amazon:
yum install httpd
service httpd start
So basically we have a very small page (1 kb) that already has over 333 kb of bloat just by including those 2 libraries! Of course bootstrap and font-awesome are, well, awesome, so let’s see what we can do to help here.
Turns out that while mod_deflate is installed as part of the Apache installation on Amazon, it is not pre-configured to compress any specific file types. You can fix this a number of ways, I chose to edit the httpd.conf file in /etc/httpd/conf and add this:
Rerunning our performance scan sees some nice improvement, but we still see those pesky uncompressed font files!
Don’t be ashamed, “this happens to everyone”. Those poor old font files are always left out…
Well, let’s fix it. For Apache, you need to make sure your configuration also compresses the proper font extension as well. In this example, we do this by adding these 2 lines to the httpd.conf:
This instructs Apache to also compress SVG and EOT files, both of which were included by the Bootstrap/font-awesome libraries. A quick restart of Apache (“service httpd restart”) and rescan with Zoompf and we see this very satisfying result:
Also refer to the full report.
So by turning on compression for the correct file formats, we saved over 333 kb of unneeded bloat from just these 2 libaries alone – 225 kb (68%) of which was from the font libraries! Fonts can chew up a lot of space, and are rarely included in the compression filters for most websites.
What Else Can I Do?
So you may ask why webservers don’t just compress everything by default? The problem is that some content, like PNG and JPG images, are already compressed. If the webserver tried to “re-compress” files that were already compressed, performance would actually get worse! We have a great blog post about this in our archive called Lose the Wait: HTTP Compression. I highly recommend checking it out.
So with this said, we need to explicitly tell the webserver what file types to compress. In the case of Apache, this can be done by adding AddOutputFilterByType lines to your configuration like shown above. While individual needs may vary, here’s a recommended configuration that covers most common scenarios:
If you need to add other file types, you can look up the appropriate entries from this list of default MIME types for Apache.
If you want to take it a step further, we highly recommend checking out the HTML5 Boiler Plate project. This resource provides a great default Apache configuration that is well optimized for speed. Of particular interest is their sample .htaccess file.
While this article does not cover the configuration for other servers such as IIS and NGINX, the problems remain the same and a similar methodology applies.
What about NGINX and IIS?
NGINX is a little easier then Apache, but still requires you supply the appropriate file types for compression in your nginx.conf file under the gzip_types directive. You can read more about this in this helpful article.
For Microsoft IIS 7, it’s a little trickier. While IIS 7 turns on compression by default, it does not compress most font files, including SVG. To enable this, you need to use the “appcmd.exe” tool (located for me in C:\System32\inetsrv directory) to add the missing MIME types to the “static types” list of what gets compressed. Microsoft has a reference on this here. And here’s the syntax for adding SVG:
appcmd.exe set config -section:system.webServer/httpCompression /+"staticTypes.[mimeType='image/svg+xml',enabled='True']" /commit:apphost
And similar commands can be issued for the other types. After you’re done, restart IIS to be safe and those types should now be compressed. If you have further problems, a great place to look to debug is in the “httpCompression” tag section of your “application.host” file, located in the c:\Windows\System32\inetsrv\config directory (or equivalent). For example, on my test instance I had to move the image\svg+xml entry above the “*/*” deny rule like such:
No doubt an order of precedence applied there, so you may get hit with a similar problem by using the appcmd tool alone.
As shown above, even the default “out of the box” installation of useful libraries like Bootstrap and font-awesome can introduce a good amount of bloat to your webpage. While the capabilities of these libraries more then justify the cost, there are still steps you can take to get the best of both worlds here.
While turning on HTTP Compression is always a must-do for any website administrator, very commonly (LARGE) font files are left out of the compression equation. As shown above, this is often resolved through a simple configuration update.