Battle plan for Drupal 7: performance

published on February 4, 2008

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.

If I manage to get all these improvements in, Drupal 7 will without a doubt be the fastest loading out-of-the-box Drupal release ever. And if you can and are willing to pay for a CDN, it can even be faster.

The average site uses the Garland theme, Google Analytics, has at least some images on its frontpage, and does not have access to a CDN.
I simulated this on my frontpage, and my YSlow score was 85. With a CSS sprite generator, that’d be a better score of course. So that’s my goal for a default Drupal 7 installation: a YSlow score of 85.

Comments

Ximo's picture

Ximo

I’m far from an expert, but I think frontend performance tuning is an interesting area, and I’ll try to help out wherever I can :) Like Steve Souders has demonstrated, there’s a lot to gain on the frontend side of things - even for Drupal.

Wim Leers's picture

Wim Leers

I’d like to say: especially for Drupal. If Drupal gets all these things Right, then Drupal will deliver an amazing out-of-the-box performance, and thus experience for more users. Thus again increasing the adoption rate.

Go Drupal! :)

Craig Rosenblum's picture

First off, big steve souders fan.

Got his book in high performance, and i was hooked. Always was a backend performance junky, now both XD

  1. I think a huge performance gain on backend can be thru getting bind variables in place, we have tons of queries, that are repeated or similar, and should be taking advantage of bind variables. Which are a way to treat similar queries with different where values as the same query.

  2. We should also have a suggest list of automated events, that we can offer instruction on how to tweak, tune performance of your drupal installation… For example, I use this script http://www.999tutorials.com/tutorial-optimize-mysql-tables-simple.html as a windows scheduled task, and it keeps my mysql tables automatically tuned. There may be additional things, we can do from home to pro servers to keep them tuned to high scalability.

  3. I think we need to get behind the ball on CSS Sprites, and encourage people to who understand this far better than i do, to release a more modern, fail proof version..

  4. Perhaps some new articles on how to best configure apache, php, mysql, and any other server component. The more we know, and the more we can automatically improve drupal the better it will be.

I mean, drupal can have all the customizability in the world, but that wont’ matter without solid performance.

Front end performance is great, but honestly, we need all around performance, from sql queries, to well written modules, to tight security.

Just my opinion for what it’s worth :)

lordofthelake's picture

lordofthelake

If I’m allowed to post my two cents (I found this post for chance), I’d express my doubts about the CSS sprites generation part: are you sure it is a work for the CMS? Shouldn’t it be a work for the designer who made the theme?

I think that adding a sprite generation facility to Drupal is not only a unrealistic goal, but probably a wrong thing.

I’m only a casual visitor here, but I already heard of this idea, and sincerely I think it’d complicate things (breaking some themes?) more than providing real benefits. Obviously, if you find a way to do it, without incurring in the mentioned problems, it’ll be welcome.

About all the other points, indeed, I agree 100%. Just my 2 cents.

Google décide de mieux classer les pages rapides | Lesbazeil's picture

[…] pages ne sont pas parfaitement au point(voir Improving Drupal’s page loading performance) mais drupal 7 va être plus performant. var addthis_language = ‘fr’; Share| Catégorie(s) : Web dev Tags : drupal, google, […]