Essential steps to speed up a Drupal web site

Technologies: Drupal 5+, PHP (optional), MySQL (optional), Apache (optional)

An initial installation of the Drupal content management system can be slow. You can speed up your web site substantially by making a few essential adjustments to your site's web server, database, PHP, and Drupal configurations. This article introduces a series of articles on the steps to take and why.

Configure the web server

Drupal is a popular content management system written using PHP and typically installed using a MySQL database and an Apache web server. If you have administrator authority over the computer running Apache, PHP, and MySQL, making a few adjustments can halve page load times and substantially speed up your web site. If the computer serves multiple web sites, all of them will benefit.

The default configurations for Apache, PHP, and MySQL have important performance features turned off. The following articles in this series provide step-by-step instructions and explanations to turn these features on:

Configure Drupal

Drupal has several built-in performance features that can further reduce page load times and speed up your site. The default configuration for Drupal has these features turned off. The following series articles show how to turn them on:

Configure your theme and page layout

Drupal makes it easy to enable lots of features and decorate your site with all sorts of blocks listing recent content, current users, the latest weather report, and lots more. Drupal's theming system lets you download and install hundreds of different themes, or author your own to create a very fancy look and feel. But beware. The more you add to your site, the slower it goes.

The following articles in this series include step-by-step instructions, explanations, and benchmarks showing the costs for blocks and theming choices and what you can do about them:

However, it's easy to get carried away fiddling with everything to extract the maximum performance from a site. Sometimes, the effort is just not worth the savings:

Comments

This is fantastic stuff, man!

Especially the bit about optimizing the theme, aggregating the CSS and the other Drupal config stuff. Great for multi-module sites.

One question -- what is a good webhost that will let you configure the webserver and database server as you reccommend?

And speaking of which, doesn't a lot of the speed question just get down to what webhost you use?

Thanks a ton.

Web hosts, configurations, etc.

Thanks for your comments.

There are roughly four main things that affect the perceived performance of a web site:

  • Database query time
  • PHP page assembly time
  • Page download time
  • Page request time

Every time a user asks for a Drupal web page, Drupal issues database queries. Sometimes quite a lot of queries. Most of the time spent by MySQL to answer a query is spent reading data from database tables on disk. Using a faster computer won't help much. A faster disk and more memory for a disk cache will help. But the best way to improve performance is always to avoid doing slow things in the first place. So enable MySQL's query cache to save previous query results. This will skip doing most slow disk I/O and return query results faster without having to buy or lease faster hardware.

Drupal has to spend time executing PHP code to assemble a page for a user. Since PHP is an interpreted language, the PHP engine has to compile Drupal's PHP scripts into an executable program every time a script is run. Installing a PHP script cache saves a lot of this time. Using a faster computer would speed up PHP compiles, but a script cache is always a win regardless of the computer's speed. Once a script is compiled, a faster computer would execute that script faster. But a better approach is to cache previously-generated Drupal pages. Then there is less PHP code to execute and the computer's speed doesn't matter as much. Caching is always better than depending upon fast hardware.

Once a page is assembled, it has to be downloaded to the user. The higher the network bandwidth, the more you can send them within a few seconds. But the bandwidth bottleneck is usually at the user's side. So adding more network bandwidth on the web server side won't help the user any. Instead, compress text content before you send it, carefully compress your images, and use a simpler theme so that there is less to send in the first place. A faster web host can compress text faster, or cache the compressed files, but since the bottleneck is almost always the network I/O, a faster computer won't help that much.

Every web page uses multiple files: the HTML, the CSS, images, JavaScript, Flash, etc. To get a file, a user's browser issues a request to the server and waits for the file to be returned. Network latency describes the round-trip time for the request to travel across the Internet and the server to answer. This is largely a function of the speed of light and the distance between the user's computer and the web server. Since the speed of light can't be increased, and the user's location isn't under your control, network latency is largely unavoidable. To reduce its impact, though, reduce the number of files you have to send to the user. CSS aggregation does this. Using a simpler theme with fewer images, JavaScript files, and Flash also makes a big difference. If there are fewer files to send, the user's browser spends less time waiting for them.

So, for a small web site the speed of a web hosting company's computers and network connection doesn't matter much once you enable caching and do good web site theme design. From a hosting company's perspective, enabling caching everywhere reduces the server load and enables them to host more sites on the same server. That means more income without spending more money on hardware. So, any competent hosting company should be pleased to enable Apache compression, MySQL query caching, and PHP script caching. If they aren't, perhaps they aren't that competent and you'd be better served by going someplace else. Or host the site yourself. It isn't that hard and for a small site it can be done with any old PC or Mac you have laying about.

Dave_Nadeau You are mostly correct but...

HTTP request round-trip time and browser rendering time make up the most of the time it takes to load a page.

see Yahoo's Exceptional Performance Team

Re: Dave_Nadeau You are mostly correct but...

Each of the factors I listed above strongly affect the page load time. If you install Drupal and do not enable a PHP accelerator, MySQL query cacheing, and Drupal page cacheing, your site will be slower than it should be... regardless of the page request time (the HTTP round-trip time) or the browser rendering time. It is only after you have sped up the server side that the rest of the load time factors become relevant.

Yahoo's excellent articles, which you reference, study the page load time issues after a site has had its servers made reasonably quick. They do not advocate ignoring server side performance problems entirely. Common sense tells you that if you serve your web site on, say, an ancient 286 PC, it's going to be slow. What the articles point out is that after doing reasonable server-side optimization, the problem shifts to a network and browser problem and further server-side effort has diminishing returns. To gain further performance improvements you have to shift your focus to network and browser issues.

Browser rendering time is a factor in the page load time, but usually a very small factor. The rendering time on most reasonable computers is well under a second for even large web pages. By far most of the page load time comes from sending page requests (via HTTP) and waiting for the responses. And the time waiting for those responses is mostly due to network latency... if the web server has been properly configured first.

this is exactly what I was looking for

I'm testing Drupal 4.x for our intranet. I had everything configured, but it was just too slow. Now it looks like I can go live. Thanks.

Great stuff

Really nice article. I feel it saved a lot of time for me.
I was just searching for this.

Thanks,
Ipsita

This is what I need...

Im using Drupal 5.x for my website, but it was very slow. I think this article have all that I need.

Thanks,
adie_ndonk.

Can I do this on my Shared Godaddy Hosting Account?

Does Godaddy and similar shared hosting companies allow us to make the tweaks for PHP and SQL cacheing?

The site I am concerned about is built in Drupal 6, and I turned on all of the available cacheing functions within Drupal. I found that my homepage load time was still miserably slow as measured at Site Report Card (77+ seconds on a slower connection.) Of course, since I do not know if it is possible, I have not turned on PHP/SQL caching, which I think is the key to this.

Also, enabling CSS aggregation caused my fivestar module to not display the star rating system. Also, once I logged out of my site and clicked on the main nav links, I landed on pages with the in place editing functions turned on (even though I was logged out.)

Any help would be appreciated.

-Doug

Re: Can I do this on my Shared Godaddy Hosting Account?

You'll need to contact GoDaddy to see what services they can enable for your site. MySQL and PHP cacheing both decrease CPU use, but they also increase memory use. GoDaddy may not be willing to make that trade-off. If not, consider moving to a different hosting service that will. PHP cacheing, in particular, can have a significant impact on your page load times – if HTML generation is the problem.

Page load times are the sum of individual load times for each of the elements on your page. While 77+ seconds is way too slow (aim for under 4 seconds), the problem may not be Drupal's HTML generation and it may not be improved much by MySQL or PHP cacheing.

To begin to debug the problem, go get the Firefox browser and the FireBug and YSlow plugins. With them installed, clear your browser cache, visit your web site, then click on the FireBug bug icon at the bottom of the Firefox window. Click through the many tabs and see what it's telling you about the size and load time for the HTML, CSS, JavaScript, and images on your page. Look at the "Net" tab for a timeline for loading elements, and click through the YSlow report card to see what changes it recommends.

Keep in mind that there are three main parts to the load time: (1) time spent sending a request to a server, (2) time spent by the server to satisfy the request, and (3) time spent sending the data back to the browser. MySQL and PHP cacheing speed up server time for HTML only (unless you are using certain Drupal plugins that create page-specific CSS, JS, and images). Getting a faster net connection speeds up sending the data. But most of the page load time is spent waiting on requests. That means that the most effective way to speed up a web site is to reduce the number of requests made per page. Usually this means reducing the number of images used.

Regarding CSS aggregation and the fivestar module... browse the module's forums and/or report a bug. This shouldn't happen.

Regarding logging out and still seeing edit pages... this sounds like a cacheing problem. Your browser, GoDaddy, or an intermediate ISP cache is failing to honor the cache control header on HTML generated by Drupal. This is fatal. Use FireBug to confirm that the response header for an HTML page request says "Cache-Control: max-age=0". If it doesn't, something is stripping that off. Contact GoDaddy.

Thank You

Thank you very much for your detailed instructions, bookmarking this page for sure!

Great article

Thanks for this eye opening article. I will contact my hosting provider today to check if they have apache.mysql and php caching enabled. I noticed that css compression is not a good option for all sites coz it breaks many modules secondly, high PHP caching will again break modules.

Enabling drupal CSS file aggregation automatically remove the sp

Enabling drupal 6 CSS file aggregation automatically remove the spaces and new line marks of a css file, so no need to duplicate the work manually.

Re: Enabling drupal CSS file aggregation automatically remove

Drupal's CSS aggregation concatenates CSS files and removes white space, but full CSS optimization does more. It removes redundant and overridden properties and combines property settings that may have become spread out within the same file or across multiple files. For instance, perhaps one CSS file sets a default <h1> font size and another one overrides it:

h1 { font-size: 160%; }
...
h1 { font-size: 120%; }

CSS optimization on the combined files can throw out the overridden first property, making the file shorter.

Drupal's CSS aggregation doesn't do this. If you need these optimizations, you'll need to do them yourself. However, see my article titled Don't bother using CSS optimization to speed up a web site for benchmarking that shows that there is little tangible benefit to CSS optimization. The few bytes saved do not yield a noticeable reduction in page load time.

The main performance benefit from Drupal's CSS aggregation is from the file concatenation, not the white space removal. Once aggregated, a browser only needs to make one file request instead of a dozen or so. This significantly reduces the amount of time a browser spends sending requests and waiting for data to come back.

Thanks for the great article

Thanks for the great article mate. These tips are really useful. My Drupal website was loading really slowly, moreover when I tried to load it with my mobile phone - it crashed every time. But I have tried almost all of your tips, and when I have enabled page caching and CSS file aggregation, Bum! My website started to load 2 times faster. I was surprised and shocked a little bit (of course I mean the good meaning of this word). So it is everything because of your help. Thanks one more time for this useful material and I will be looking forward to another great stuff from you.

Sincerely,

Brad Toston from software application development

Browser cache and optimization

One thing concerns me with the built in Drupal optimisation - when CSS and JS are aggregated, Drupal appears to assign a "randomised" filename on each page load - or at least, it creates aggregated versions for each page on the site. This works to reduce server load, because it favours caches on server side - but for an end user, it means they need to load a 'new' CSS+JSS file on each page load. Without aggregation, 90% of the CSS and scripts are loaded on the first page visited, and from there on displayed from browser cache?

Re: Browser cache and optimization

This takes a bit to explain...

Every module installed at a Drupal site could have its own CSS and JavaScript files. Different types of pages might involve different modules and thus require different combinations of CSS and JavaScript files. So page "1" might need files from modules "A", "B", and "C", while page "2" might need files from modules "B", "D", and "E".

It would be incorrect for Drupal to blindly aggregate all CSS and JavaScript for all modules into one big CSS file and one big JavaScript file and deliver those same files for every page, regardless of whether the page needed them or not. Instead, Drupal keeps track of what combinations of files are needed and creates a different aggregation for each one. So, in my example, Drupal might aggregate "A", "B", and "C" to create an "ABC" file, and also aggregate "B", "D", and "E" to create a "BDE" file. Now if the browser needs page "1" it gets the "ABC" aggregation, and if the browser needs page "2" it gets the "BDE" aggregation.

For a simple site like my own, there is only one aggregation and every page gets that same aggregated file. But for a more complex site there may be many different unique combinations of modules for different pages, and thus many different aggregated files. They are all created and they are all stored for quick delivery. To keep them all separate, each one gets a unique file name. While the file name might look random, it's actually a hash code based upon the names of the modules contributing to that aggregation.

The result is that there may be many different aggregated files for a site. As the user browses the site, they might require one of them on one page, and a different one on another page. However, the number of aggregate files is much much smaller than the number of pages at the site, so after browsing for a few pages the user will have gotten them all and they'll all be in their browser's cache. After that, there's no further downloading of CSS or JavaScript from the site.

If you want to optimize the user's experience, simplify the site. Use fewer modules and/or fewer different configurations for different parts of the site. If the entire site always uses the same set of modules for all pages (like my site does), then there'll only be one aggregated CSS file and one aggregated JavaScript file and the user will only download each one once.

About Previous Articls

Hi

Really it is a very nice and summarize article.
Thanks for that

Thank you very much for your

Thank you very much for your detailed instructions, bookmarking this page for sure!

It Also Helps With Your Organic Ranking

Site speed is now an official "ingredient" to the organic algorithm at Google so not only does a faster site help your visitors it is one of many components that helps your rank as well.

Post new comment

The content of this field is kept private and will not be shown publicly.
  • Allowed HTML tags: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • Lines and paragraphs break automatically.
  • Web page addresses and e-mail addresses turn into links automatically.

More information about formatting options

Nadeau software consulting
Nadeau software consulting