Basics of Drupal optimisation
Drupal is such a powerful CMS, but at the same time it is a bit weighty. Specially because of it’s flexibility and modularity, it may cause hundreds of requests to generate a single page. But, fortunately, we can deal with it. In this tutorial i will guide you through several steps of your site optimisation.
It’s important for you to refer to this tutorial title, since all this stands for a site without connected trafic. I mean your visitors do not produce any content, they do not have any account on the web site.
We’ll talk here mainly about caching, which means serving same pages without regenerating them to all users. Caching policy strongly differs when it comes to connected visitors, where it’s just impossible to serve same page to all users.
Using Pressflow instead of Drupal
What is Pressflow?
“Pressflow is a distribution of Drupal with integrated performance, scalability, availability, and testing enhancements.”
As long as Pressflow is Drupal - it is fully API compatible. Everything that works with Drupal will work with Pressflow. (see Comparison Pressflow vs Drupal).
So the first step will be overwritting your Drupal installation with Pressflow distribution. You can download latest version from here. (You will note some new modules appeared in /modules directory - we’ll talk about them a bit later). Do not forget to backup your site and database before doing this
Once you’re done with this - you’re on Pressflow!. Easy enough, huh ?
Now you are ready to start with deeper optimisation, such as reverse-proxy, database replication, all this stuff :) But before....
Aggregation and zipping of Javascript and CSS
As you may notice - Drupal (as Pressflow) includes bunch of CSS and JS files to the HTML Page.
Each of these files is a hit for our webserver. So we have to reduce it somehow. The salvation is Drupal built-in feature, called “optimise js” and “optimise css”. All of these optimisation things could be found at “Performance” (admin/settings/performance) page. Lets turn it on.
So what do we get in return?
Pretty cool, huh ?
Now we can do even better: we can gzip aggregated css to minimise bandwidth consumption. There are CSS Gzip and Javascript Aggregator modules.
JS / CSS Aggregation as compression MAY cause some problems. Mainly you must be sure that you user drupal_add_css and drupal_add_js API methods to add new CSS / JS files to your theme. NEVER include them directly in template’s HTML (like in page.tpl.php huh !). Then some module may produce some bugs in old navigators (for example I’ve got a problem with TinyMCE and JS compression on IE6). So do not do it in late project stages to avoid headache and sleepless nights of debugging.
Now lets leave baby stuff and move to more serious matters ;)
Boost - boosting up pages performance
Boost provides static page caching for Drupal enabling a very significant performance and scalability boost for sites that receive mostly anonymous traffic. Boost generates static HTML files for all pages of your site. This HTML content may then be stored on a CDN (Content Distribution Network) or locally.
Note that Boost is not an alternative for all the rest of caching policies described later in this tutorial. Of course Boost, and basically static HTML files will handle 90% of your traffic, but you still want your site being fast on cache miss (when boost doesn’t have the page and wants to generate it) or when you simply use your back-office.
So how does Boost work ? When website accessed for the first time (meaning when cache does not exists), request goes to Drupal, Drupal hits database, then Drupal assembles page with database data and outputs this assembled page to the web browser. Boost stores this assembled page on the disc, and next time page is requested, it avoids all this Drupal-database cycle. It just returns cached page. Drupal also provides full page cache, but it still hits database to obtain it. So the main point is that Boost allows you to avoid Drupal+Database hits to display cached page.
NOTE: in order to have boost working - clean urls should be enabled in your Drupal installation.(admin/settings/clean-urls)
Installation of the module should follow same rules as for other modules. After you’ve uploaded and enabled Boost module, you need to go to admin/reports/status page and correct all warnings and errors, which stops boost from correct working. After you’re done with warnings fixing and generating and putting in place .htaccess Boost instructions boost should works correctly.
More about boost and configuration you can see on this cool video.
Views caching
There are no sites on Drupal without using Views, it’s for sure. But Views are known not only because of their awesome features but also because of their consumption of system resources.
Let’s see how we can improve the situation. Either result of views query, or views rendering can be cached using views <=> cache (i mean Drupal caching system) integration. This could be done through 2 simple steps:
1. Make sure views caching is enabled (admin/build/views/tools)
2. For specific view, let’s call it “test” and specific display “test”, we need to enable caching
Now views output or queries will be cached.
As you may know, Drupal has pluggable cache system, which could be extended by 3rd party modules. Out of the box Drupal uses database tables for cache storing. This default behavior has one significant disadvantage - it is relatively slow, as long as database still gets queried.