10 Optimization Tweaks to Speed Up Adegga

Adegga moved to a dedicated server a while ago. We took this opportunity and also implemented a couple of other performance tweaks. In this post I’ll explain the things we changed and how they affected performance.

We implemented 10 tweaks that are mostly based on Yahoo’s Web Optimization Best Practices:

1. Minimize HTTP Requests
2. Add an Expires or a Cache-Control Header
3. Gzip Components
4. Put Stylesheets at the Top
5. Avoid CSS Expressions
6. Make JavaScript and CSS External
7. Reduce DNS Lookups
8. Split Components Across Domains
9. Minify JavaScript and CSS
10. No 404s

Results
The graphics below show a waterfall representation of all the requests needed to download the homepage as created by this testing tool. Here you can see the result before and after the modification.

Before and After implementing the tweaks. Click the graphics for more details.

With the changes the page moved from 438KB to 208KB (on a first request) and 64KB to 13KB (on second, cached, request). That’s half the size on the first and six times smaller on the second!

In terms of time speed tests show that the page moved from 13 sec to 4 sec (on a first request) and 1.7 sec to 1.3 sec on the second request. I take this results only as reference to each other. There are better ways of measuring effective page loading time like using Firebug.

The Tweaks
1. Minimize HTTP Requests

Most of the time used to load a page is spent downloading components (images, stylesheets, scripts, etc). If you can reduce the number of components you reduce the number of needed HTTP requests. Amazon and Yahoo load their CSS directly inside each page thus not using another request for this file.

We haven’t included css and scripts inside the page for now (but we worked on them in a different way, however, I thought this point was too important to miss and decided to include it in the this post anyway.

2. Add an Expires or a Cache-Control Header

Basically there are 2 things you can do:

For static components: implement “Never expire” policy by setting far future Expires header
For dynamic components: use an appropriate Cache-Control header to help the browser with conditional requests

Adegga now uses mod_expires that was implemented following the tips seen in this article.

3. Gzip Components

Compressing files before sending them reduces size of the HTTP response and thus response times. We used mod_gzip to implement this step.

4. Put Stylesheets at the Top

Like stated in the HTML specification, stylesheets should be loaded in the HEAD section and help the page render progressively as it loads up. We had this in place before on Adegga so we were apparently already doing something right!

5. Avoid CSS Expressions

CSS expressions are a powerful way to set CSS properties dynamically. We have been using them because of compatibility problems with Internet Explorer. In the new design and new code (that is already implemented here) we’ve removed expressions from the main CSS file and dumped them in a specific CSS file only loaded by Internet Explorer.

6. Make JavaScript and CSS External

JavaScript and CSS files can be cached by the browser so using external files in the real world can produces faster pages. Inline JavaScript and CSS (like suggested on another rule above) get downloaded every time the HTML document is requested. This reduces the number of HTTP requests that are needed, but increases the size of the HTML document.

It really depends on the size and frequency of use of your css and javascript code. We opted to maintain them in separate files allowing for browser caching.

7. Reduce DNS Lookups

Reducing the number of DNS lookups cuts response times but increasing the number of parallel downloads can decrease response times. We’ve opted to use a couple of sub-domains increasing the number of requests but increasing the number of parallel downloads as you can see in the next point.

8. Split Components Across Domains

The idea here is to increase the number of simultaneous download of elements (images, scripts, etc.). On Adegga we use www.adegga.com for html and dynamic content and another 2 sub-domains: i.adegga.com for all the images on the site and s.adegga.com for all the other static content (css and javascript). This results in a good compromise between reducing DNS lookups and allowing a high degree of parallel downloads.

We will soon use another webserver (Lighttpd or Nginx) dedicated to serve static. This option allows static files to be server much quicker and reduces the load on the main (dynamic) webserver.

9. Minify JavaScript and CSS

By removing unnecessary characters from code we reduce its size and improve loading time. We’re currently using a packed version of the jQuery library. We will soon be moving to the minified version that takes more time to load but can be faster to read by the browser.

To compress the CSS (to some extension) we used CSSTidy.

10. No 404s

HTTP requests are expensive and making an HTTP request and getting a error response (example: 404) is totally unnecessary. We had a 404 on an image as you can see if you click the left graphic at the top and fixed it.

Finally

As you can see, website optimization in an ongoing job. I’m sure there’s a lot more that we can do to make pages even faster and we’ll certainly work on more tweaks in the upcoming months as traffic continues to rise. I highly recommend checking out Yahoo! Developer Network for lots of other cool articles on the subject and other useful resources.

Update: thanks to a suggestion by André Torgal here’s the link to Yahoo’s YSlow Firefox extension that analyzes web pages and tells you why they’re slow based on the rules for high performance web sites.

Update 2 Manuel Lemos suggested the great Google Webmaster Tools as a good way to analyse 404s and clean dead pages from the site.

March 20, 2009 | Tags: adegga, css, jquery, optimization, tweaks, webdevelopment, webmaster

comments

12 Responses to “10 Optimization Tweaks to Speed Up Adegga”

Leo on March 20th, 2009

Excellent post André, thank you so much for sharing your experience. It really is, as you state at the and, an ongoing process for which you will always have to allocate some time and priority.

Will soon implement some of the quick wins on some of our projects - as soon as I have the time and the priorities straightened up!
Andre on March 20th, 2009

Thanks Leo, if you need help let know!
bjr on March 20th, 2009

boa onda… em tempos fiz essa mesma checklist… os resultados são espantosos
andrezero on March 20th, 2009

We had Rasmus Lerdorf himself do a talk here at SAPO last week, http://developers.blogs.sapo.pt/5714.html and addressed precisely some of these issues, plus a few more, specially on the server side, mostly PHP related.

I suggest you add to your post a link to YSlow, Yahoo’s client side performance meter, which is an extension to the firebug extension.http://developer.yahoo.com/yslow/
Andre on March 20th, 2009

@André, great suggestion. I’m adding an update to the post now.

Thanks!
álvaro on March 20th, 2009

Another very important trick (and by our experience, the most important) is to place JS calls at the end of the page and merge the various JSs into one JS file. This relates to perceived speed by the user rather than the real speed of the download.

When the browser comes across a JS the download of the rest of the elements keeps stopped until the JS is read by the browser. So apart from minimizing and merging them, many times a JS at the top of the document makes stops the browser from showing the page to the user.

Probably you’ll have to make changes regarding how do you invoke JS in your app, but it really pays off.

http://developer.yahoo.com/performance/rules.html#js_bottom
álvaro on March 20th, 2009

Another thing: if your have an external JS like an adserver call or external widget, place it in an iframe, so it doesn’t stop the page from loading, and to be sure your page keeps loading even if the external server is down or slow.
Andre on March 20th, 2009

Thanks for the tip Álvaro. I know that we’ve eventually have to move all the JS to a single script.

What do you do with individual code for each page? You have a specific file for JS on that page?
Andre on March 20th, 2009

That’s a good tip too. We use Flick slideshow on a producer’s page and they slow down the page. Putting them in an iframe should solve that.
álvaro on March 20th, 2009

> What do you do with individual code for each page? You have a specific file for JS on that page?

In this case we put the JS inline, at the end of the document or in the header.
Manuel Lemos on March 22nd, 2009

(Desculpa comentar em Português, mas acho estranho comentar em inglês num blog escrito por um Português quando todos que comentaram parecem ser portugueses, espero que não haja problema)

O que queria dizer é que apesar da maioria das regras serem boas, é preciso ter em atenção algumas situações particulares.

Por exemplo, 404 são importantes para informar os robots do Google que alguma página que foi acedida não existe. A partir dessa informação fica mais fácil descobrir links internos e externos que estão quebrados e precisam ser consertados. Basta usar por exemplo as ferramentas de Webmaster do Google. Já consertei muitos erros em sites que não me tinha apercebido se não fosse usar 404.

https://www.google.com/webmasters/tools/
Andre on March 22nd, 2009

Manuel, claro que não há problema de responder em Inglês. Apenas quem ler o post em Inglês e quiser aproveitar os bons comentários que acrescentam valor (como o teu) poderá não conseguir perceber.

A tua dica é excelente. Eu próprio uso muito o Google Webmaster Tools e faz todo o sentido adiciona-lo ao post. Não só elimino muitos dos 404s por lá como também identifico algum do falso conteúdo duplicado (páginas diferentes mas com o mesmo titulo).