Optimising a Drupal site for performance and SEO - part 2

* Originally posted on crawlscore.com but moved here as the blog on crawlscore.com is no more *

The blog post I had in mind for this has been very, very well covered in Wim Leers post on improving Drupals page loading performance.

What I will do is blog about the specific issues I discovered by using crawlscore.com and how I addressed them.

Using Fasterfox I took an average load time of the Blog page of this site which was around 4.4 seconds.

HTTP analysis

Then using a HTTP analyser such as LiveHTTP (or Fiddler) I looked at exactly what was being requested and the HTTP status code of each element.

I found that I had a number of unused modules (taxonomy, CCK, etc) for which the appropriate CSS was being requested. I disabled all unused modules and load times dropped to 3 seconds.

**Note : it is worth pointing out that I appear to have a "troubled" Firefox installation and these times are all relative. When I ran the same test on another PC with the same setup, load times were basically halved.

**

So here's the HTTP list before :

GET /modules/date-5.x-1.5/date/date.css
GET /modules/imce_gallery-5.x-1.x-dev/imce_gallery/imce_gallery.css
GET /modules/cck-5.x-1.5/cck/content.css
GET /modules/cck-5.x-1.5/cck/fieldgroup.css
GET /modules/forum/forum.css
GET /modules/img_assist-5.x-1.2/img_assist/img_assist.css
GET /modules/node/node.css
GET /modules/system/defaults.css
GET /modules/system/system.css
GET /modules/user/user.css
GET /themes/skymod/style.css

(total of 11 GET requests)

And after :

GET /modules/cck-5.x-1.5/cck/content.css
GET /modules/node/node.css
GET /modules/system/defaults.css
GET /modules/system/system.css
GET /modules/user/user.css
GET /themes/skymod/style.css

(total of 6 GET requests)

If we enable CSS caching then that goes down to one request.

Caching

I then had a close look at the HTTP trace to see if everything was caching ok. I was looking for HTTP 200 where there should be 304. Bizarrely, on my "troubled" Firefox installation I was getting HTTP status for some images but when I ran the same trace on another PC, everything was as it was with a 304 for cached images. Even more bizarre is that there is a thread on Drupal forums (that I can't find anymore...) where someone had exactly the same problem.

I considered using the block caching module but the blocks used on this site are very simple with very little dynamic content so decided against it.

With those modules disabled, standard caching turned on my load times are reduced to around 2.5 seconds. On another PC this was < .5 second for cached pages.

The only items that aren't cache'able are the external elements IE addthis, Sphinn, Blogcatalog and Statcounter. I'd suggest these items are non-cacheable by design.

It's not ideal from a performance or crawling point of view to have these external elements on the page but they're pretty much essential.

Drupal CSS, JS and Expires

Drupal already has CSS at the top and JS loading at the bottom so in that respect there was nothing to do.

Drupal sets the "Expires" header for all other files than web pages to 2 weeks. Yahoo recommend far future – can be achieved by mod’ing .htaccess but this means changing actual filename if it does change in the future.

So in summary, Drupal is actually pretty good from a caching and general performance point of view.