Zoompf's Web Performance Blog

Note: Archived Content

This is the archived version of the Zoompf blog. Since our acquisition by Rigor, all our new research and posts on web performance are being published on The Rigor Blog

Speed Up Your Bootstrap and Font-Awesome Sites Using Font Compression

 Mark Isham on August 21, 2014. Category: Guide


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 even if you have compression turned on for your HTML, CSS and Javascript, you’re still missing out on large possible savings by excluding your font files. In the demonstration below, we’ll dive into this in more detail, then show what you can do about it!


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.

From there, I constructed a very basic HTML file that includes the latest Bootstrap (3.2.0) and Font-Awesome (4.1.0) libraries.


If you’re playing along at home, you can download this full sample here: FontCompressBlog.tar or FontCompressBlog.zip

After installing the base Apache 2.2 image provided by Amazon:

yum install httpd
service httpd start

I then ran the Zoompf scanner against this page, you can see the full report here. The results showed no compression enabled for ANY of the files, the default for the prepackaged Apache on Amazon.


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:


This tells Apache to compress HTML, CSS and Javascript files, which is the common compression use case for the majority of the web. Many Apache installations will now set this for you automatically, as well as performance packages like mod_pagespeed, but you can’t assume this is a given.

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:

AddOutputFilterByType DEFLATE text/plain
AddOutputFilterByType DEFLATE text/html 
AddOutputFilterByType DEFLATE text/xml 
AddOutputFilterByType DEFLATE text/css
AddOutputFilterByType DEFLATE application/xml
AddOutputFilterByType DEFLATE application/xhtml+xml
AddOutputFilterByType DEFLATE application/rss+xml
AddOutputFilterByType DEFLATE application/javascript
AddOutputFilterByType DEFLATE application/x-javascript

# Common Fonts
AddOutputFilterByType DEFLATE image/svg+xml
AddOutputFilterByType DEFLATE application/x-font-ttf
AddOutputFilterByType DEFLATE application/font-woff
AddOutputFilterByType DEFLATE application/vnd.ms-fontobject
AddOutputFilterByType DEFLATE application/x-font-otf

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.

In Closing

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.

To see if your website is compressing your font files properly, try out Zoompf’s Free Report, and to keep your site fast over time, check out our newly announced Free Alerts Beta!


Have some thoughts, a comment, or some feedback? Talk to us on Twitter @zoompf or use our contact us form.