performance

In this article, seven distinctly different page loading profiling tools are compared: UA Profiler, Cuzillion, YSlow, Hammerhead, Apache JMeter, Gomez/Keynote/WebMetrics/Pingdom, Jiffy and Episodes. “Profiling” must be interpreted rather broadly: some of the tools cannot measure actual performance but are useful to gain insight in page loading performance characteristics.

If you can not measure it, you can not improve it.
— Lord Kelvin

The same applies to page loading performance: if you cannot measure it, you cannot know which parts have the biggest effect and thus deserve your focus. So before doing any real work, we will have to figure out which tools can help us analyzing page loading performance. “Profiling” turns out to be a more accurate description than “analyzing”:

I went to FOSDEM on Sunday. I got up at 6 AM but went to bed at 2 AM (because I still had to review my presentation) … so I only had 4 hours of sleep! I met up with Jo Vermeulen and Tim Dupont at 7 AM in Hasselt’s station. Jo is a PhD student and Tim is a teaching assistant at Hasselt University.
I hesitated at first because both of them have teached me a course either this year or last year, so it’d be a bit weird. But getting to know people is virtually always more fun than pain, so what the heck, I traveled with them anyway!

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:

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 code repository, 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.

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.