Performance improvement : moving assets to subdomains

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>

The multi-tab admin problem

Today I had to update an important zone file at my registrar. Because it was quite important, and because I already did an almost identical job a few months ago, I decided to copy-paste the old work.

So I started by opening the domain A zone edit page. Then  I opened a new tab, and loaded the domain B zone edit page.

I selected the domain B content and copied it in the domain A page. I had to update some values, mostly IP addresses, and then validate the page.

Instead of updating the domain A zones as I expected, it updated the domain B zones and left the domain A unchanged. Can you guess why ?

Session handling

My guess is that everytime I opened a new page, a Session was tracking my "current" domain, the one I was editing. So opening a new tab to a new domain changed my current domain from domain A to domain B.

Therefore, when I updated the domain A zone, the next page was assuming I was editing the domain B page. If I had opened the tabs in reverse order, it would have worked seamlessly.

Why doing that ?

I have encountered a similar behavior in my own apps. By using the cakePHP Security behavior, a special security token is generated for each form. Its integrity is checked whenever a form is posted, and verify that no field has been tampered (no mandatory field has been deleted, no new field has been added).

This is a great security component, but because a special key is stored on the Session side, it also means that whenever you open several tabs, only the latest can be correctly checked and all other one will get rejected.

It bugs me at first, because I used to open several tabs whenever I need to "batch add" a lot of items. In real life, I found that I was almost the only person to do that... So I finally accepted the multi-tab restriction.

Getting back to my registrar : I guess they did it that way because of security reasons too, but I found it particularly counter-intuitive in that case and that could have led to serious damages.

Using fonts hosted on a subdomain with @font-face and Firefox

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>

Setting the z-index of a jQuery UI datepicker

I ran into a collision issue with two of my absolutly positionned elements on a form page. I had an invisible flash buttun (used to launch an upload process) as well as jQuery UI datepicker.

The form was built in a way that when the datepicker was displayed, it was supposed to be on top of the invisible Flash button. Unfortunatly the button was in fact "on top" of the datepicker, but being invisible you do not notice it until you click.

This resulted in an upload dialog popping up and many confused users.

The fix

The Flash z-index is fixed in my CSS (10), so I thought that adding a greater z-index to the jQuery UI datepicker in CSS would be enough.

It is not. The jQuery UI datepicker seems to automatically set the z-index to 1, whatever you specified.

I checked the datepicker options, looking for a zIndex key, but found nothing...

I tried the beforeShowevent, to manually set the z-index, but it seems that jQuery still update my value to 1 AFTER the event.

So I finally resorted to adding a small timeout to re-add my value after jQuery. This is a bit of a hack but given the context this is the only way I found.

// Set the datepicker zIndex on load
element.datepicker({
[...]
  'beforeShow': function(input, datepicker) {
    setTimeout(function() {
      $(datepicker.dpDiv).css('zIndex', 100);
    }, 500);
  },
[...]
});

Finding a string in multiple files

Lately I was receiving emails with just the text "Blablabla" from an old (online) production server. This was obviously from an old debug script that I should have put online and forgot.

Unfortunatly, I wasn't able to track down exactly from where it originated. I had no mention of that string in my local files.

So I connected to the serveur using ssh and ran the following command : grep -R Blablabla /path

After some processing, I got the incriminating file and was able to delete it.