Forgetting peoples names since 1978


Setting HTTP headers on CSS fonts for great justice (and performance)

Some tips for configuring your web server for optimum performance when using CSS fonts (’@font-face’, as some would call it).

1. Certain types of font files don’t have any sort of compression in the actual file, so your web server should be configured to serve them up compressed. Compressing the font files can give significant file size savings, Museo Sans weighs in at 48KB for the TTF version, gzip compression drops this to 26KB. Compressing SVG can give even greater savings – from 53KB down to 15KB.

2. Setting a far future Expires header for font files will make them cachable & reduce HTTP requests on subsequent visits.

3. In addition, not having the correct content type can cause display issues (i.e. they don’t display at all).

This handy table summarises what is what:
Name Extension Compressed file? Content type
EOT .eot yes application/
TrueType .ttf no font/ttf
OpenType .otf no font/opentype
WOFF .woff yes font/x-woff
SVG .svg no image/svg+xml

Clear as mud? Okay, let’s move on to…

Configuring the server

Three things need to be done: - enable gzip compression for the non-compressed fonts (TTF, OTF & SVG) - add correct content types for all font types - add far future expires header for all font files

Configuration for specific servers will differ, but these should get you started:

Apache 2:



This doesn’t cover all the other juicy bits you can do to improve performance when using CSS fonts – removing kerning, subsetting, base64 encoding, etc. – these will be dependent on your own personal preferences & the needs of your particular project.

Impact of attribute order on compression

One of my personal coding standards is to keep similar HTML attributes grouped together in a consistent order at the start of the element, e.g.

<script type="text/javascript" src="foo"></script>
<script type="text/javascript" src="bar"></script>


<script src="foo" type="text/javascript"></script>
<script src="bar" type="text/javascript"></script>

This helps with readability, maintainability, &c. &c.

Recently another thought occurred to me: that this would also help with HTTP compression.

I ran a quick test using these two (very simplified) HTML documents:

With the following results (taken from the Firebug Net panel):

File Size
ordered.html 240b 145b
unordered.html 240b 148b

So, the ordered version gives us a saving of 3 bytes – not a massive gain, but in a much larger document it could be significant.

I imagine this would also hold true (and possibly give much more significant savings) for CSS if property/value pairs that are the same are grouped together.

For those of you interested in such things, I tested the compressed vs. uncompressed HTML by first soft linking the HTML files:

ln -s ordered.html ordered-uncompressed.html
ln -s unordered.html unordered-uncompressed.html

The adding the following .htaccess:

AddOutputFilterByType DEFLATE text/html
SetEnvIfNoCase Request_URI uncompressed no-gzip dont-vary

which disables output compression for any URI that contains ‘uncompressed’.

Redesign in progress

Tagged with

I’ve finally started doing the redesign I’ve been promising for so long.

It’s not finished yet, so if you whinge about it not working in whatever stupid browser you’re using then I’ll just laugh at you :p


  • Finish the background (cloning & dodging & burning etc. to make it tile horizontally)
  • Get the skipnav thinger workign better
  • Funky JavaScript animation
  • Print CSS
  • Sekrit awesome stuff that will blow your freakin mind (if I ever finish it)
  • Spinning bits
  • Bacon

Fun bits:
  • Using HTML5 properly (aww yeah)
  • Liquidy-proportional-whatever layout so you can stalk me on your iPhone or your 36inch 29000×4282 monitor or whatever