Improving Drupal's page loading performance

published on January 30, 2008

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.

Front-end performance

Faster servers with more memory stop improving your web site’s performance at some point. Yet, even before your web site gets big, there are other places to look at to improve performance, where greater effects can be achieved, even at lower costs – significantly lower costs actually. Typically, less than 20% of the total response time is used to retrieve the HTMl document. That means the other 80+% is used to process what’s in the HTML file: CSS, JS, images, videos. And in many cases, that number is even higher.

Depending on your website, your server(s), et cetera, these optimizations will probably shave off between 25 and >100 percent (estimated) of your page loading time. Initial (empty cache) and consecutive page loads (primed cache) will both be significantly faster, unless you’ve already done your own round of optimizations.

Much thanks go to Yahoo!’s research that resulted in fourteen rules and the accompanying YSlow tool (we’ll get to that in a second) that allows you to check how your web site performs according to those rules. If you can apply all fourteen successfully, your web site should fly. (Assuming that your page generation times aren’t super slow, of course.) As always, more optimizations are still possible. I’ll discuss some very effective ones briefly at the end.

YSlow

First things first: make sure you’ve installed Firefox, Firebug and YSlow for Firebug (version 0.9 or better).

Firebug is simply a must-have for any web developer, it doesn’t matter whether you’re a professional or an amateur. YSlow is a Firefox add-on developed by Yahoo!, that analyzes your web page and tells you why exactly (remember those fourteen rules?) your site is slow (hence “y-slow”, which is pronounced as “why slow”). But at the same time, it tells you how you can fix those pain-points. The lower the rule number, the greater the effect.

What follows is a comprehensive, yet pretty complete review of how Drupal 5 and 6 score on each rule, by listing the required features, settings or guidelines.

If you want to skip the information and want to see results, just skip to the part where I explain how you can apply the optimizations to your site.

Rule 1: Make fewer HTTP requests

RequirementDrupal 5Drupal 6
CSS aggregationyesyes
JS aggregationnoyes
Generate CSS sprites automaticallynono

Drupal even has the ability to compress CSS files (through stripping comments and whitespace). JS aggregation has been added in Drupal 6. To my knowledge, not a single CMS/CMF ships with the ability to generate CSS sprites. Nor does a single one have a module or extension that allows them to do so. This could be a Drupal key performance feature, if it were supported.

Solution

The easiest way to reduce this significantly is to enable Drupal’s CSS and JS aggregation. You can find these settings at admin/settings/performance in your Drupal site.
If you’re using Drupal 5, there’s a backport of Drupal 6’s JS aggregation feature, you can find it in this issue – I sponsored this patch.

There is not yet an automatic CSS sprite generator module for Drupal. If your site is styled pretty heavily, this would benefit you even more than CSS and JS aggregation. I hope somebody – or some Drupal company – will take the initiative.
In the mean time, there’s a free CSS Sprite Generator out there, if you don’t mind doing it manually.

Rule 2: Use a CDN

RequirementDrupal 5Drupal 6
Alter URLs of served files dynamicallynono

Drupal’s File API needs work: it should be trivial to alter file URLs dynamically, e.g. based on the file size or type of a file.

Solution

I chose to tackle this particular problem myself, because using a CDN greatly enhances the usability of your web site for visitors that live far away from your servers. And one of the projects I’m working on, is one with a very international audience.

The first part of what’s needed, is obviously to update Drupal core to support file URL altering. I chose to create a new function, file_url(), through which all URLs for files should be generated, including the URLs for additional CSS files in the page.tpl.php file (e.g. for a print.css file). This patch also provides a new hook: hook_file_server(), through which modules can provide new file servers. To configure the preferred file server, a new “File servers” setting has been added to the File system settings form. If one server can’t serve a file, Drupal will try the second server, and so on. It will always fall back to the web server Drupal is being served from if all servers provided by modules failed.
Currently, I’ve only got a Drupal 5 patch (it’s included in the CDN integration module and attached at the bottom of this article), because I want to get more feedback before I start maintaining patches for 2 different versions of Drupal. As soon as the patch ends up in its final form, I will provide a Drupal 6 patch, and of course push for Drupal 7 inclusion. An issue at Drupal.org has been created.

The second part – integration with a CDN – obviously requires an implementation of hook_file_server(). So the CDN integration module was born. It’s written with flexibility in mind: it supports synchronization plugins (currently ships with one: FTP), can create unique filenames or directories (necessary if you don’t want to break relative paths), provides the tools to check whether your filters are working well (per-page and site-wide statistics) and the filters can be configured using parameters similar to Drupal’s file_scan_directory() function.

An article that includes benchmarks of the effects of the CDN integration module is being worked on. The same article will include a complete installation tutorial as well.

Rule 3: Add an Expires header

RequirementDrupal 5Drupal 6
Don’t set the Expires header for web pagesyesyes
Set the Expires header for all other filesyesyes
Allow far future Expires headers: ability to alter URLs of served files dynamicallynono

By setting the Expires header for files, you tell the browser that it’s ok to cache them.
Drupal sets the “Expires” header for all other files than web pages to 2 weeks. This is sufficient for most uses. For maximum performance, this should be set to a date in the far future (e.g. 10 years from access), but this requires unique filenames: each time the file is updated, the filename should change as well this is why file URL altering is a requirement. If not, your users could still be using the old files, since they may be in their cache.

Solution

Changing the future date for the Expires headers is easy enough: simply edit your .htaccess file. Your Apache server must also have mod_expires installed, this is available by default on most servers. However, making filenames unique is an entirely other matter. The altering of file URLs is already solved in the solution for rule 2. So all you have to do now, is implementing a file server that supports this. The aforementioned CDN integration module provides this feature, but if you want to use it, you of course have to use a CDN.

Rule 4: GZIP components

RequirementDrupal 5Drupal 6
GZIP web pagesyesyes
GZIP CSS and JS filesnono

When Drupal’s page caching is enabled, pages are written to the cache in GZIPped form! To learn more about how Drupal handles GZIPping, run this command from your Drupal root directory:

egrep ‑rn "gzip" .

Don’t forget the dot at the end!
However, Drupal does not yet allow you to gzip CSS and JS files.

Solution

A Drupal core patch for this is being worked on, but has unfortunately been inactive for quite some time.
If you are using my CDN integration module, you don’t need to worry about this, since CDNs GZIP files by default, if the client supports it.

Alternative solution

As an alternative, you could configure your Apache server to automatically compress files.
An example for Apache 2.x: add the following lines to your .htaccess or httpd.conf file:

AddOutputFilterByType DEFLATE text/css application/x-javascript

Rule 5: Put CSS at the top

RequirementDrupal 5Drupal 6
Abstraction to add CSS files to the web pageyesyes
Default location in the XHTML document is the tagyesyes

Drupal has this abstraction: drupal_add_css().
Putting stylesheets to the document HEAD makes pages load faster: it allows the page to be rendered progressively.

Rule 6: Put JS at the bottom

RequirementDrupal 5Drupal 6
Abstraction to add JS files to the documentyesyes
Default location in the XHTML document is just before nono

Drupal has this abstraction as well: drupal_add_js().
JS should be at the bottom, because browsers wait until everything in the tag has loaded. As you probably know, JS files tend to be pretty large these days, so loading them might take a while, thus postponing the rendering of the page. If you’d put the JS files at the bottom, then your page can be rendered while the JS files are still loading! It also achieves a greater download parallelization, thus cutting down your overall page loading time.
This is also being discussed at groups.drupal.org.

Solution

Unfortunately, the default value for the $scope parameter of drupal_add_js() is bad: 'header'. If we simply make 'footer' the default, we’re good. The number of contributed modules that sets this to 'header' explicitly, is very low, so it shouldn’t be too much work to convert these. And I’ve yet to encounter the first module that has issues with being at the bottom instead of the top.

A more complex part of the solution are Drupal’s default JS files: misc/jquery.js and misc/drupal.js. These can be put in the footer without any issues whatsoever. But what if a contributed module chooses to put its files in the header? Then they may not yet be loaded! For maximum compatibility, we should add the default JS files to the header if at least one module chooses to add its JS file to the header.

I’ve attached patches for both Drupal 5 and 6, but neither implement the more complex part I just explained. In my opinion, Drupal should enforce a strict policy: all JS files should be “footer-compatible”. Until somebody can point me to some JS that must be in the header to work properly, I’m unlikely to change my opinion about this proposed policy.

Alternative solution

The second method to fix this, doesn’t involve hacking Drupal core, but is also more hassle since you have to repeat it for every theme you’re using. Suppose you’re using the default Drupal core theme, Garland. Then open the themes/garland/page.tpl.php file in your favorite editor. Find this line at the top of the file:

Cut it away from there, and put it just before this line at the bottom:

So your end result should look like this:

As you can see, it now comes just before the closing tag. (Well, also before the $closure output, which is the output generated by all hook_footer() implementations.)

Rule 7: Avoid CSS expressions

RequirementDrupal 5Drupal 6
No default theme should implement ityesyes

CSS expressions are not recommended, because they’re evaluated many times: when the page is rendered or resized, but also when the page is scrolled. Even when the user moves the mouse over the page!
None of the Drupal core themes uses CSS expressions. Just make sure you don’t use it in your own themes.

Rule 8: Make JS and CSS external

RequirementDrupal 5Drupal 6
Inline CSS and JS should be avoided or used sparinglyyesyes

If your web site is a common homepage for many users, you may want to use a custom strategy and read this. Otherwise, you can ignore this rule without worrying.

Rule 9: Reduce DNS lookups

RequirementDrupal 5Drupal 6
Use 2-4 hostnames by default: ability to alter URLs of served files dynamicallynono

To my knowledge, not a single hosting provider offers a static file server by default. So it makes a lot of sense that Drupal doesn’t do it by default. However, Drupal should support it out-of-the-box.

If you use a lot of so called widgets (those small blocks of content provided by Flickr, del.icio.us, MyBlogLog, and so on) on your site, you’ll have some extra work to do.

Solution

The altering of file URLs is already solved in the solution for rule 2. So, once again, all you have to do now, is implementing a file server that supports this.
If you use my CDN integration module, then you’ll be using 2 hostnames or more, but this of course requires you have access to a CDN.
Alternatively, you can use a static file server. Robert Douglass’ article on using Drupal with a static file server is a very complete reference: from the pros and cons to the entire server setup.
See Yahoo’s documentation for more details.

Widgets solution

If you’re using a lot of widgets and you want to continue using them, you can. The solution is simple: cache as much as possible on your own site (or to your CDN).
For example, if you use Google Analytics, make sure you’ve installed the Google Analytics module, which has an option to cache the .js file locally (and update it once each day, to make sure you’re serving the latest version).

Rule 10: Minify JavaScript

RequirementDrupal 5Drupal 6
JavaScript minificationnono

This was originally included in Drupal 6 core. However, it has been removed because it was problematic; it would result in boatloads of JS errors, and thus the JS would simply stop working. The technique used by Drupal 6 was Dean Edwards’ packer, also nicknamed packer.

Solution

Packer, isn’t just a minifier, it’s also an obfuscator. A minifier only strips whitespace and comments, but an obfuscator also munges the code; it renames variable and functions as short as possible. For this, the packer uses a reduction algorithm (hence its name). However, this has serious consequences for the page loading time as well: it can easily take 200 ms to unpack the JS! Additionally, the effectiveness of GZIPping packed JS files is much lower.

More reliable alternatives are JSMIN (minifier/uglifier), Dojo Shrinksafe (minifier/obfuscator) and YUI Compressor (minifier). The last two are built on top of Rhino, Mozilla’s Javascript engine, written in Java. Therefor neither qualify for Drupal core inclusion. A JSMIN PHP implementation exists, so I think this is the best choice.
There’s an issue to add this to Drupal 7.

Rule 11: Avoid Redirects

RequirementDrupal 5Drupal 6
Avoid redirects by defaultyesyes

Drupal could redirect users accessing the non-aliased URL /node/11 to the aliased version /about, but it does not – at least not by default.
The Global Redirect module implements this feature in a sensible way. See the project page for a complete explanation.

Rule 12: Remove Duplicate Scripts

RequirementDrupal 5Drupal 6
Abstraction to add JS files to the documentyesyes

Drupal has this abstraction, as mentioned in rule 6: drupal_add_js(). You then just use a static variable to prevent adding the same file multiple times. For an example, see the jCarousel module.

Rule 13: Configure ETags

This is the only rule that depends completely on the server setup. An ETag uniquely identifies a file, and is used to verify if the file in the browser’s cache matches the file on the server.

The problem is that they are generated using attributes specific to the server (inodes) they’re being served from. This implies that when, for example, you’re using multiple servers behind a load balancer, you may one time be accessing the files from server 1, another time the files from server 2. And since the ETags don’t match, you’ll be downloading the file again!

Solution

If you’re using multiple servers, disable ETags. For Apache users: add this line to your httpd.conf:

FileETag none

IIS users have to follow a more complex procedure.

Alternative solution

Use a single server to serve files, or a CDN. See the solutions for rules two and nine for detailed information.

Rule 14: Make Ajax Cacheable

RequirementDrupal 5Drupal 6
Pluggable render formatsnono
Ability to set GZIP-ability per format (i.e. rule 4)nono

These feature was being worked on for Drupal 6, but unfortunately wasn’t ready in time.
The ability to set the GZIP-ability per output format (i.e. rule 4) should be handled at in the same patch, or in a follow-up, since it affects the performance of AJAX callbacks so much.
Other - but mostly less important - rules that are implemented automatically: rules 9 and 13 (AJAX responses will be served from the same server as Drupal), rule 11 (redirects are extremely unlikely to be used for AJAX callbacks in Drupal). Rule 10 is almost completely irrelevant, because GZIPping JSON data has a much greater effect.

Solution

The node rendering refactoring issue is listed for the Drupalcon Boston 2008 code sprint, so we’ll probably see this in its final form in a couple of months.

Applying this to your site

This is of course a boatload of information. The easiest way to apply all of it to your site, is by installing my CDN integration module, and using the included Drupal core patch that also adds JS aggregation and puts JS files at the bottom (by changing the default scopes).

Live sites

Before you start applying this to your site, you of course want some proof that all these optimizations do indeed have an effect. No problem. You’re looking at it. This page should have been loaded in less than a second. Subsequent page loads should complete in less than half a second. With Drupal’s page caching disabled (!), eAccelerator installed and a MySQL query cache in place.

Another live site is DrupalBin. That site is running on a shared server (DreamHost), without eAccelerator and without a MySQL query cache – which explains the often slow page generation times.

Additional optimizations

In order of effectiveness:

  • The Boost module enables Drupal to perform static page caching. This means that rendered pages are written to files, and through some mod_rewrite magic, it will serve the statically cached page from the file if it’s available, thus without even a single DB query!
  • This article at 2bits is chock full with Drupal performance tips.
  • The core patches module Advanced cache, again by Robert Douglass, provides caching for blocks, comments, the forum structure, built nodes, path lookups, popular search queries and taxonomy trees.

Drupal issues

More information

Thanks to …

  • Yahoo! for their work on YSlow.
  • Greg Knaddison (greggles) for proofreading this article and making several excellent suggestions to make this article more complete.

Comments

Wim Leers's picture

Wim Leers

You have to add wimleers.cachefly.net as the CDN used on the web site, then it’ll increase the score. The CDN module is not yet ready for production use though. I’m also having a server issue because of which new files haven’t synced yet at the moment of speaking, causing a couple of files not to be served from the CDN.

 For Drupal Developers - TechAdmin's Soul Asylum 's picture

[…] Improving Drupal’s Page Loading Performance Bạn đang tìm cách tăng tốc cho các trang web của mình? Đây là cách giải quyết dành cho bạn. […]

Anonymous's picture

Anonymous

I’ve found that a PHP library called Smart Optimizer works well with Drupal.

http://farhadi.ir/works/smartoptimizer

It automatically minifies, concatenates, and gzips CSS and JS and caches the resulting files to serve future requests. Super easy to setup as well - just copy the directory to your server and paste a snippet in you htaccess file. Makes a huge difference in Yslow.

Anonymous's picture

Anonymous

Great resource BTW!

I used your alternative suggestion and amended my theme to put the .js files at the bottom of the page. However it appears that this breaks FCKEditor, the editor simply does not show up! When I reverted to putting .js files in the header it worked again!

I’m using Drupal 6

HGH's picture

HGH

Man that was awesome. Going to bookmark it. Will refer to it often. Thanks!

Zane Rokklyn's picture

Zane Rokklyn

Great advice! And I like how you challenge us to try loading the page to see how your tips work on your own site. Unfortunately, when I run Yslow on this page, it get this:

Performance Grade: C (71) Expand All Collapse All D 1. Make fewer HTTP requests F 2. Use a CDN B 3. Add an Expires header D 4. Gzip components B 5. Put CSS at the top A 6. Put JS at the bottom A 7. Avoid CSS expressions n/a 8. Make JS and CSS external A 9. Reduce DNS lookups C 10. Minify JS A 11. Avoid redirects A 12. Remove duplicate scripts F 13. Configure ETags

Time to revisit your own advice? :-(

Wim Leers's picture

Wim Leers

I stopped using my CDN provider because it turned out they had very few PoPs and for that, I was no longer willing to pay. So it’s simply because I’m no longer using a CDN. This is temporary. I’m in my exam period currently, so I don’t have the time to test with another CDN.

I’ll fix it ASAP :)

For Drupal Developers « Web for Dummies’'s picture

[…] Improving Drupal’s Page Loading Performance Bạn đang tìm cách tăng tốc cho các trang web của mình? Đây là cách giải quyết dành cho bạn. […]

Rob Loach's picture

Rob Loach

A small note that the JavaScript Aggregator module for Drupal 5 will aggregate the JavaScript for you. In Drupal 6, the JavaScript Aggregator module will use JSMin to compress/minify the aggregated JavaScript.

Wim Leers's picture

Wim Leers

Yep, that’s new since I wrote this article :)

I will probably post an updated version of this article in a couple of weeks.

Florian Sievers's picture

I Just wanted to update my drupal from D6.9 to D6.10. Befor I startet the required database update, I reapplied the patch for JS in the footer (manually, because common.inc have been changed).

If “function drupal_add_js” had been changed to insert the JS in the footer, the database update can’t be applied, because the script, that shows the progressbar, won’t run.

Solution: First update the database and than patch common.inc. Whenever you need to update the database (e.g. after module update), you must change common.inc to include JS in the header, and after that, you can reapply the patch.

Ethos Blog » Drupal - A Quick Start up to Drupal's picture

[…] Improving Drupal’s Page Loading Performance Looking to speed up a Drupal website? Try following these steps. […]

Wim Leers's picture

Wim Leers

I already noticed. Great work :) I’m sure it’ll be appreciated by many Drupal users!

Оптимизируем Drupal | CMS - Content Managment Systems's picture

[…] ниже расположен перевод заметки “Improving Drupal’s page loading performance”, в которой рассматриваются прикладные методы […]

 Tổng quan về Drupal - CỘNG ĐỒNG PKC | PLEIKU - GIA LAI's picture

[…] hệ thống là một khía cạnh rất quan trọng. Hãy tìm hiểu từ bài viết này. Improving Drupal’s Page Loading Performance Bạn đang tìm cách tăng tốc cho các trang web của mình? Đây là cách giải quyết […]

matt's picture

matt

for the css sprite generator, what do the offset options do, besides make the image bigger? Is there any reason the offset shouldn’t be as little as possible? (The sprite generator doesn’t accept an offset of zero, though I don’t understand what the problem would be.)

Roger's picture

I installed the Javascript Aggregator module and it works great. Page load times are significantly improved. But when I tried to implement Rule 6, I had a problem.

The site makes heavy use of the Gmap module, with most of the pages featuring a Google map. When I tried to move the <?php print $scripts ?> line to the bottom of the page, all of the maps disappeared, exposing the ‘Javascript is required … ’ message. Returning the scripts to the <head> corrected the problem. (Drupal version 5.17)

Anonymous's picture

Anonymous

I just wanted to say that this script has really helped improve the general performance (and YSlow score!) of my company’s Joomla site. I also wanted to say thanks. My Drupal 6.2 site’s YSlow score improved from 69 to 81. Keep up the good work. Cheers.

More About Drupal | depiak's picture

[…] Improving Drupal’s Page Loading Performance Looking to speed up a Drupal website? Try following these steps. […]

Anonymous's picture

Anonymous

Thank You for the article. I am still reviewing it.

I have a minor issue request. Could you tell me how you were able to add the “TAGS” option at the end of the article block where there are ” apache Drupal Page loading performance performance ” tag links.

Dan's picture

Really useful and definitely worth bookmarking. Now to get my head round how to implement some patches!

danreb's picture

I applied some of the information written here to optimize my drupal site http://www.thecapulenos.com . The only thing I can’t apply is the CDN module integration, but it improves much website performance so I’m happy with it.

Drupal Developer’s Toolbox | 9Tricks.Com - Tips - Tricks -'s picture

[…] Improving Drupal’s Page Loading Performance Looking to speed up a Drupal website? Try following these steps. […]

Alexandre's picture

Hi Wim, After using it for several weeks, I have just got it! :-(

Here an example of what is impacted when one use footer as default scope from drupal_add_js: there is no more marker on Google Maps (through the gMap module).

I have noticed some other small cases like non-expandable fieldgroup on the update.php page…

Do you know more about this point in D7? Did Angela ‘n friends have taken it into account?

Thanks, Alexandre

Wim Leers's picture

Wim Leers

Google Maps markers are indeed one of the many examples.

There are no new features regarding JS placement in the HTML document in Drupal 7.

Speeding up Drupal performance page load's picture

[…] The CDN module is maintained by Wim Leers which also wrote a great but a bit older post on Drupal page loading performance. Also check out his slideshow and video presentation from DrupalCon Paris on this topic if you want […]

 Hoge laadsnelheid website wordt belangrijker - SEO forum's picture

[…] Dit kan aardig oplopen in laadtijd besparing. Een zeer goed artikel hierover mbt Drupal staat op: Improving Drupal’s page loading performance | Wim Leers Daarnaast heeft de Yahoo! Yslow tool zeer veel uitleg om je pagina nog sneller te laden! Zo […]

Millennium &amp;amp;raquo; Blog Archive &amp;amp;raquo; Разгоняем Dr's picture

[…] ниже расположен перевод заметки “Improving Drupal’s page loading performance”, в течение которой рассматриваются прикладные методы […]

Dream's picture

Dear Wim leers,

I hope you don’t mind me posting as you are a freelancer I was hoping you could help me out. I know this post is about loading performance (you have some spam on here as well) but I was wondering if there is a way to remove a stylesheet on one page? I have developed a forum by using phpbb2drupal and now my forum is totally messed up as it is calling style.css rather than the phpbb3 embedded style. I have tried creating a page-forum.tpl.php page and removed print styles, but it still does not work.

Also tried this solution on the drupal site:

<?php print str_replace(‘@import “misc/drupal.css”;’, ”, $head); ?>

So, question is how to remove CSS styles (default) to one page in drupal and keep the headers. Please please please help me :-)

Elaine's picture

I Just wanted to thank you for posting the link to remove the style sheet. I think I was having a blond moment that day! Thanks again WinLeers :-)

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

[…] Drupal 6 les 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) : […]

Peter Emanuel Roos's picture

I read the entire article and it is definitely an important one in my bookmarks! Thanks Wim!

Although I quickly browsed through all the comments, maybe I missed another question about this…

Why not also use an equivalent of Tidy on the generated XHTML? Removing all the whitespace has made my non-Drupal static sites loading faster when I have Tidy in my CMS-engine (I use an older, but great Dutch product for creating static sites). And with not removing line-breaks the source is still quite easy to check (or just do occasional checks in an XML validator with a pretty print option).

Which also brings me to: what would be the impact of whitespace-stripping PHP? I’m clueless about this, but I know from long ago that parsers are very often progress byte-by-byte on their low level processing. Would an optimization here do any good?

I also would love to hear a comment on the impact of using 2 dedicated servers, one for Drupal, one for MySQL (Gb connected). This is of course a very expensive approach, but would it make page loading also a lot snappier? Or is it just a final approach for really big trafic sites?

Thanks for any comments! Cheers, Peter

Wim Leers's picture

Wim Leers

Yes, tidied HTML would indeed load faster. The impact is just significantly less than the loading of other resources, it can save at most a few KB of an HTTP request that would happen anyway. But it can help.

Whitespace-stripping PHP would also work but is of course definitely not recommended. Instead, use a PHP opcode cache such as APC.

The impact of using 2 dedicated servers would depend on your web site. It’s also completely not related to page loading performance: that’s all about page rendering performance, i.e. server-side performance. If you have slow SQL queries and by extent slow page loads, it may make sense to do that. But it really depends.

Imprimante Info's picture

Hi,

I was wondering why gzip was not working on my site. As stated here, cache must be enabled for gzip to work. thanks for the tip.

Pages