Pixelastic

Did you know that when debugging RewriteRules, instead of commenting/uncommenting each line, you can simply make RewriteEngine On / RewriteEngine Off all along your code ?

I didn't, and now that I do it seems so obvious I don't believe I've never thought of that before...

Disclaimer : What I'm talking about in this blog post can be optimised. Yes, having multiple hosts is a great feature for performance improvement, but I kind of did it wrong. My recent try at the webperf contest gave me more insight on how to do it right.

I'll post more on the subject or update this post to reflect that.

 

I've just added to this site a performance improvement I read a long time ago but never implemented.

I'm talking about the multiple domains to serve static content. There are two important things to note here : parallel requests and cookies. Let me explain in a little more details what it's all about.

Parallell requests

Your browser is only able to perform a certain number of parallel request at the same time. It means that it can only download a certain number of files concurrently (usually 4).

In other words, it will start the download of, say, a CSS file, a Javascript file, and two images. Then, whenever one of this files is received, it will start downloading a new file, and so on.

This means that there is a certain amount of time that is "lost" in the process. You have to wait for one of the files to be downloaded before starting downloading the next.

The important thing to note is that the limit on the number of parallel downloads is set on a per-domain basis. It means that you can download only 4 files of foo.com while downloading at the same time 4 files from bar.com. This is the basic of what we will be using to our advantage.

Splitting your files accross several domains (or subdomains) allows you to get the best of parallel download. You do not really need to have your content hosted on different servers, you just need them to be accessible through different domain names, and subdomains are just perfect for that.

I have created four subdomains : css.pixelastic.com, js.pixelastic.com, img.pixelastic.com and dl.pixelastic.com.

Each one maps to the exact same site as www.pixelastic.com but using different names improve the number of possible downloads and thus improve page load.

Cookies

All this stuff about subdomains brings me to my second point : cookies.

If you host all your files on the same domain, it means that all requests (be it a php page or a static css file) will send cookie information without you knowing.

Cookie data is usually small, like 100Ko or so, but is added to every single request made. And most of the time this information is not even useful.

Apart from the fact that you are slowly killing your website bandwith with useless information, your are also decreasing your page speed load for your potential user.

The same trick of using a subdomain applies here too, and cookies won't be sent.

There is one caveat that you should be aware of, though. If your site is accessible through domain.com and you host your files on files.domain.com, cookies will still be sent because domain.com is considered the master domain of files.domain.com and thus all cookies set on the main domain will also propagate to the subdomains.

On the other hand, if your main domain is www.domain.com, it is not considered a parent domain of files.domain.com (but rather a sibling domain).

Configuring Apache

If you need to edit your httpd.conf file, here is what I put to add my different subdomains on my local machine :

<VirtualHost *:80>
	ServerName pixelastic
	ServerAlias www.pixelastic
	ServerAlias css.pixelastic
	ServerAlias js.pixelastic
	ServerAlias img.pixelastic
	ServerAlias dl.pixelastic
	DocumentRoot "www/pixelastic.com"
	<Directory "www/pixelastic.com">
		Options Indexes FollowSymLinks Includes ExecCGI
		AllowOverride All
		Order allow,deny
		Allow from all
	</Directory>
</VirtualHost>

 

As a security reason, Firefox do not allow an @font-face rule to load fonts hosted on a different domain (even a subdomain).

I don't exactly understand why, I guess it has something to do with preventing crosslinking and copyright violation. I think we should keep the website author handle all this stuff and not required the browser to make assumptions like that.

Anyway, I recently tried to move my CSS file to a subdomain, to reduce pages loading times. Doing so I saw that my fonts did not correctly load on Firefox.

After some digging, I found that I had to manually allow them to be linked from an other domain, server-side. Here is the little snippet I added to my .htaccess

<FilesMatch "\.(ttf|otf|woff)$">
	<IfModule mod_headers.c>
		Header set Access-Control-Allow-Origin "*"
	</IfModule>
</FilesMatch>

 

When using @font-face to display fonts, you have to create a whole bunch of font files on your server to accomodate the quirks of the various browsers.

If you do things right (or follow the automatic kit build of FontSquirell), you should get a .eot file for IE, a .ttf/.otf file for current browsers, a .svg file for Chrome and the iPhone/iPad and a .woff file for the next browser generation.

Unfortunatly, you'll have to cope with that because there isn't much we can do about it at the moment.

But you can compress those files to make the font rendering faster. Some browsers even download all the fonts even if they will only use one, so compress them !

The easiest way is to configure your server to automatically gzip them. You should already have done that for your css and js file so it is just a matter of adding new types.

As far as I know .otf and .ttf files don't have registered mimetype, so I had to create a dummy one for them in my .htaccess :

AddType x-font/otf    .otf
AddType x-font/ttf    .ttf
AddType x-font/eot    .eot

I also added the .eot because even if an application/vnd.ms-fontobject mimetype is registered for this obscure microsoft format, when I tried to add a deflate rule on it, my Apache crashed so I took the safest way of defining a custom mimetype.

I prefixed them with an x- to make sure that it won't mess with existing mimetypes.

The second part was to add gziping to those

AddOutputFilterByType DEFLATE x-font/otf x-font/ttf x-font/eot

SVG files are in fact xml files, and you should already have them gzipped, so no need to add them here.

I haven't included .woff files because .woff files are already compressed files, so you don't need to gzip them.