performance

Battle plan for Drupal 7: performance

My battle plan for Drupal 7 is simple: get as many performance improvements or performance-improvement-enablers from my Drupal page loading performance article into Drupal 7. From high to lower priority:

  1. #214934: file_url() and hook_file_server() – yep, patch for Drupal 5 already available and in production use here on this site as well as DrupalBin) – for rule 2, rule 3 and rule 9.
  2. Automatic CSS sprite generator, for rule 1. I still have to play with this to figure out if it's a realistic goal.
  3. GZIP CSS and JS files, for rule 4.
  4. Put JS files at the bottom by default. However, when at least one JS file is added to the header, both jquery.js and drupal.js should be added to the header as well. JS files that alter the appearance of the site heavily (such as carousels) should always be added to the header, and guidelines for this should be written, and should be very clear. This is for rule 6.

CSS sprite generator open sourced!

I already mentioned the CSS sprite generator in my article on Drupal's page loading performance. More great news though: they open sourced it! See the blog posts by the authors, Stuart Colville and Ed Eliot.

It's under the BSD license though, so it would never be accepted on Drupal's CVS repositories, which is a must. I contacted the authors, asking if they would be willing to dual-license it under the GPL.

The effects of such a module – if technically possible to generate CSS sprites completely autonomously – would be enormous. It would reduce the number of HTTP requests per page considerably: all CSS background images would be aggregated into a single image!
Even on "just" the Garland theme of a default Drupal 6 installation (this includes a logo and a small Drupal banner at the bottom), this would save 7 HTTP requests per page.

Improving Drupal's page loading performance

Introduction

Google dominates the search engine market for a large part thanks to its spartan, no-bells-nor-whistles interfaces. But also thanks to its incredible speed (which is partially thanks to that spartan interface, of course).

Since you're reading this article, you're probably a Drupal developer. It's pretty likely that you've had some visitors of your Drupal-powered web site complain about slow page load times. It doesn't matter whether your server(s) are shared, VPSes or even dedicated servers. Visitors that live abroad – i.e. far from where your servers are located – will face the same performance issues, but at even worse scales.
This article is about tackling these issues.

Syndicate content