13 rules to optimize your Web site performance

By Manuel Lemos

manuellemos.net

<email contact>

- The browser side also matters
- YSlow 13 optimization rules
- Too much AJAX and external Javascript may kill your page performance
- Compacting Javascript files
- Minimization versus HTTP compression
- Lighttpd: a fast HTTP server worth your attention
- So, how does the PHPClasses site perform?
- A much faster site for premium subscribers
- Free premium subscription trials
- Your performance rules



* New PHP innovation award prize: PHP on Microsoft Visual Studio

Before I proceed with the main subject of this post, I would like to mention something that I did not have the opportunity to mention in prior posts.

The PHP Programming Innovation Award that happens every month on the PHPClasses site has a new prize that the winners may pick. It is the VS.PHP add-on. This is an add-on that allows you to use Microsoft Visual Studio as IDE for PHP. It was not developed by Microsoft, but rather by JCXSoftware.

I am not a Windows user, but if you use Windows and like to use Microsoft Visual Studio, now you can develop your PHP applications using it as your IDE. Take a look here for more information:

jcxsoftware.com/jcx/vsphp/home


- The browser side also matters

Now back to this post subject, some time ago I posted an article that explained several techniques to optimize Web sites to survive traffic peaks.

phpclasses.org/blog/post/66-More-de ...

Those techniques are fine to keep up with the traffic of busy sites like PHPClasses. But most of the recommendations just focused on aspects related with PHP Web application development on the server side.

As Web developers, we are often mostly concerned with what happens on the server side. But the performance of a Web site as a whole also concerns what happens on the client side, i.e. the browser.

The content that our applications serve to the browsers and how the browsers handle it, is as important as the way our Web applications handle the HTTP requests.


- YSlow 13 optimization rules

There are many aspects to be concerned regarding what to do to make browsers interact with the Web servers in an optimized way that it takes less time and less server resources.

The issues are often not trivial to understand for people looking for quick and easy solutions to optimize their Web sites. Fortunately, there are tools that help you to audit your sites and suggest what needs to be done to boost the performance of the sites to the limit.

YSlow is one of those Web site performance auditing tools. This is a tool that the fine folks of the team of Jeremy Zawodny at Yahoo! released a few weeks ago.

developer.yahoo.com/yslow/

This is a wonderful tool that in a few seconds gives you an overview of how a page of your site is being served. It also suggests what can be done to optimize aspects that affect page loading speed and the consumption of Web server resources.

This tool is an extension for the Firefox browser. It works together with another very good extension named Firebug. So, to use YSlow, first you need to install Firebug.

getfirebug.com/

Once you have installed Firebug and YSlow, it is very easy to audit the performance of any Web page. Just load a Web page that you want to test and wait until it finishes loading. Then open the Firebug pane, click on the YSlow tab, and use the Performance button.

Immediately YSlow starts collecting details about the current page. When it is done it shows a list of 13 rules about aspects of the page loading performance.

On the left side of the listing you see grades from A to F. Those grades express how your page performs on each of the 13 rules, A being the best and F being the worst. On the top of the listing you see your overall "Performance Grade" also from A to F, and a score between 0 and 100.

If you got the score 100, congratulations, your page is perfect. Otherwise there is performance tuning work to be done.

I am not going to comment on each and every rule that YSlow tests. If you click on the titles of each rule, YSlow opens a page that explains what the rule means and what you can do to improve your score.

Anyway, I just would like to make a few comments on some of the rules. Let me divide this in topics.


- Too much AJAX and external Javascript may kill your page performance

Using AJAX and cool Javascript libraries is definitely the latest fashion in Web application development. These are common aspects that you may notice in the so-called Web 2.0 sites.

The problem is that when you use a Javascript library that has may interdependent components, sometimes to use a simple component you end up loading a pile of separate Javascript files.

This makes the browser send a lot of requests to the Web server once it enters a page that needs many of those Javascript files. Not only it may cause excessive load to the server, but it also slows down the rendering of a page, even when the page HTML has already been fully loaded. It is a similar effect of pages that use Flash movies that take a while to load.

Browsers cache Javascript files, but when the user is making the first access to a page that needs many Javascript files, it may take too long. It may give the impression that your site is much slower than it actually is.

This problem can be minimized in several ways. The most straightforward way is to completely avoid using complex Javascript libraries. Think again if you really need whatever effects such libraries provide.

If you really need those Javascript libraries in your pages, but those libraries are not used before the page ends loading, you can try pushing the Javascript inclusion tags to the bottom of your page.

Alternatively, you can delay the load of Javascript files using the "defer" attribute of the HTML script tag like this:

<script src="some_javascript_file.js" defer="defer"></script>

If you still need to use a Javascript library to implement an important feature of you site pages, and the Javascript library that you used is too slow to load, consider using a different library.

Now there are many alternative Javascript libraries that provide similar features. Study them and find which has less interdependencies between the library files, and so require loading less Javascript files for the features you need.


- Compacting Javascript files

If you still need to load a lot of Javascript files at once, you may want to consider using a Javascript minimization tool. Such tools can remove unnecessary data from Javascript files. They parse the Javascript code and rewrite it using a more compact representation of the same code.

YSlow site recommends a few minimization tools that can help you reducing the size Javascript library files. However, individual file minimization does not reduce the number of HTTP requests that a single page may trigger.

A different approach to this problem is to include the Javascript files in current page HTML. You may end up with a big HTML page, but it is loaded with a single request.

Alternatively you can just compact a bunch of common Javascript files into a single file, so it only takes one additional request on each page that uses the same Javascript files.

This solution is implemented by this Javascript compressor class written in PHP by Andrea Giammarchi . It performs both Javascript minimization and multiple file aggregation.

phpclasses.org/javascriptcompressor


- Minimization versus HTTP compression

Minimization helps reducing the size of Javascript files often by eliminating redundant text, or replacing code by more compact alternatives. This is fine but often you can achieve much more efficient results by using compression algorithms.

The HTTP protocol supports compression of the data that is sent between the Web server and the browser. Practically all browsers in use support HTTP compression. The compression algorithms work particularly well on text data like HTML, CSS and Javascript.

If you can enable HTTP compression on your Web server, usually that is much simpler solution. It is also more efficient than bothering with keeping minimized versions of all the Javascript libraries that you need.


- Lighttpd: a fast HTTP server worth your attention

The PHPClasses site has been using HTTP compression using Apache 1.x and mod_gzip. Apache 2.x users can use mod_deflate .

However, the site is using a separate multi-threaded Web server to serve static content like images, CSS and Javascript files. Multi-threaded Web servers are more efficient for serving static content because they can handle many simultaneous requests with low memory consumption.

Until recently the site was using thttpd. That is a fine multi-threaded Web server, but I could not figure how to make it automatically compress Javascript and CSS files before serving.

That was when I decided to try lighttpd. I heard so many good things about it, that I decided to spend some time testing it.

lighttpd.net/

It was actually very easy to configure it to serve automatically compressed HTML, CSS and Javascript files. Just add the following configuration lines:

server.modules += ("mod_compress")
compress.cache-dir = "/path/to/compress/directory/"
compress.filetype = ("text/plain", "text/html", "text/css", "text/javascript")

I immediately replaced thttpd by lighttpd. lighttpd, or lighty for the intimate, is indeed a brilliant piece of software. It was written by Jan Kneschke and it is Open Source.

It is not really surprising why lighttpd is now one of the top five most used Web servers in the whole Internet according to Netcraft August 2007 Web server survey. If you are not using lighttpd, try it now.

news.netcraft.com/archives/2007/08/ ...


- So, how does the PHPClasses site perform?

The PHPClasses site follows most of the rules suggested by YSlow. But some rules the site really cannot follow. Still there were some rules I was not well aware or was not very convinced that should be followed.

One of the rules was about compressing all static content. The site has been serving compressed pages for a long time. However, it was not serving compressed CSS and Javascript because there were some old browsers, like Netscape 4 and others, that had problems with that.

Since those browsers are too old, Its fair to assume nobody is using them anymore. So, serving compressed Javascript and CSS should be OK now.


Another interesting rule that was not being followed, is to serve static content with an Expires header set to a far future date.

This tip is interesting because it tells the browsers to not retrieve the static content again for a long time. This saves a lot of requests to fetch things that rarely change, like site images, CSS and Javascript.

Setting the Expires date to a far future date with lighttpd is very easy. Just add these following lines to make the files only expire 10 days after the first access:

server.modules += ( "mod_expire" )
expire.url = ( "/" => "access plus 10 days" )

Keep in mind that if you use this feature for images, CSS and Javascript that may need to be updated, you may have problems with stale cache files in the users browsers. The browsers will not check the files again until they expired, so the browser will not know of any updates.

To solve this problem, you may want to try using file names that include versions of the library that you are using, for instance like v1/my_javascript.js . Once you upgrade your Javascript or CSS files, switch the names to something like this v2/my_javascript.js .


One rule that the PHPClasses site (and most other sites) cannot follow, is the one that recommends the use of a content delivery network (CDN) to serve static content. A CDN can serve your content from servers located in countries that are closer to the networks of your users.

Well known companies like Akamai provide CDN services. However, since these services are usually very expensive, only sites run by businesses with large budgets can afford them. That is why the large majority of the Internet sites do not use them.


Another rule that the PHPClasses also cannot follow is to use a minimal number of Javascript files in your pages. The PHPClasses site does not use many Javascript libraries. However, it needs to serve a lot of advertising in its pages. Advertising uses Javascript to serve new ads on each page.

Advertising does not cause major load to the site Web server. Ads are mostly served by the Web servers of the advertising agencies like Google AdSense, TribalFusion, etc..

However, advertising causes significant delays to the page loading. There is no way to cache the Javascript of the ads served by the ad agencies Web servers because each page must show new ads.

The home page got grade F in YSlow tests (score 59). Despite all the efforts to optimize the site performance, it got a bad score. It is sad, but unfortunately a busy site like PHPClasses could not survive without advertising revenue.


- A much faster site for premium subscribers

Fortunately, since last month the PHPClasses site is providing an alternative to make the site faster, at least for some users. As you may be aware, the site introduced premium services.

Among other interesting features, one of the premium services is to provide access to the site without advertising. This means that all the page loading slowdown caused by advertising is gone.

Using YSlow to measure the performance of the site premium home page it gets the grade B (score 89). It does not only get straight A grade because of the CDN rule. It would be too expensive to follow that rule.

Premium services are available to all users that bought premium subscriptions. Such subscriptions are not very expensive. They just cost USD $5 a month or less. If you are interested you may learn more about it here:

phpclasses.org/premium/


- Free premium subscription trials

If you are not interested to buy a premium subscription, or would like at least to try before you buy, now you can request an invitation to try the premium services during a few days, absolutely free and without any commitment. Just go in the premium trial page and request an invitation:

phpclasses.org/premium/trial/

Once you get approved to try the premium services, just go in the site home page and notice how it perform in the YSlow tests.

Usually it scores 89, but let me tell you a small secret on how to make it score higher. It only takes a small change in Firefox configuration. Just go to the page about:config and add a new string property named extensions.firebug.yslow.cdnHostnames . Set that property to files.phpclasses.org . Then just run the performance tests again and there you have it: grade A (score 98)!

You can make your sites also score higher by setting that property to the domain name under which your site images, CSS, and Javascript are served.


- Your performance rules

The list of YSlow 13 rules is quite complete, but I am sure there may be other Web server tuning tips that could be applied. If you remember any other tips that were not mentioned, or you want to ask some questions or make some comments, feel free to post a comment on this article forum.