How to reduce page load time by improving web performance

Before you try to worry about performance keep in mind that performance that comes at the cost of user experience is useless

Almost everything you can do to improve performance will eventually end up at one or more of these principles.

1.  Minimize HTTP requests: Every HTTP requests has an overhead. HTTP headers that accompany each request have some size (response headers are 250-350 bytes and request headers are close to 1KB) but the major culprit is the time between request initialization and request service (which can vary between 200 to 500 ms).

2.  Keep the size of data you get from the server to a minimum: Most users don’t have high speed internet connection and those which have would be simultaneously browsing other sites when they are looking at your **very important page**. So don’t expect more than 30-40 kbps for your site. Now you see where this is getting. If your page size is 500 kb do the math and you will see it will take around 13 seconds for your page to completely load.

3.  Be lazy. Don’t do something until you absolutely have to: In most cases this principle would apply to JavaScript. Most pages load all the JavaScript unconditionally (at worst at the top of the page). This is bad because a lot of JavaScript is downloaded from the server and parsed (which takes time) which never gets used. So try to be lazy in getting content from the server and active in deciding what and when to get it from the server. A very good example is Facebook’s photos page. Since most people just look at photos and don’t tag them, the JavaScript required to tag photos is not downloaded on page load but only downloaded when somebody tries to tag the photos. So figure out your use-cases and try hard to be lazy.

4.  Be gentle on the browser: This principle applies to pages that run a lot of JavaScript but because nowadays every web application runs a lot of JavaScript so… When the browser parses JavaScript the UI thread blocks which means that the browser freezes, it can’t interact with the user or make changes to the DOM while the JavaScript is being parsed. So if you have a lot of JavaScript don’t execute that in one go but execute that in parts to give the browser some breathing time. Also write JavaScript that executes fast (more on that soon).

Some things you must do:

1.  Enable compression on your server (follows from principle 2): To make sure that the size of the data that goes down the wire to the client less, enable compression on your server. Put the following code either in your Apache configuration file or in the .htaccess file of your project’s root

This makes sure that HTML, css, JavaScript are sent to the browser in compressed form.

2.  Enable HTTP caching on your server (follows from principle 1): Turn on caching on you server so the user’s browser doesn’t make a request to the server for the content everytime but fetches it from the disk when it can. For most sites, content like images, scripts (js and css), flash don’t change often so they can be cached in the browser. Put the following code either in your Apache configuration file or in the .htaccess file of your project’s root

3.  Stay away from .htaccess file: Never write in the .htaccess file until you absolutely have to. If you have to enable compression or caching or enable a module use the apache configuration file rather than touching the .htaccess file. The reason is that .htaccess files are read on each HTTP request. The longer the file the more time it will take to read that file. If you can, don’t even use the .htaccess file. Now if your application is on a shared hosting I sympathize with you because you can’t edit your apache configuration and have to use the .htaccess file.

4.  Minify and if possible compress your css and JavaScript (follows from principle 2): Serving minified scripts (css and js) can greatly reduce the time to load a page. Use tools like Minify or YUI or Google Closure Compiler to minify css and JavaScript. YUI and Google Closure Compiler are hosted online here and here. Give them a shot. A reduction of up to 50% can be achieved in size especially JavaScript if JavaScript is written properly (more on that soon).

5.  Reduce the number of JavaScript and css files (follows from principle 1): Generally pages make a lot of requests for external css and JavaScript files. You can combine all your JavaScript into one file and css into the other and serve just 2 files rather than say 6 or 10. YUI and Google Closure Compiler provide this feature of combining your scripts into one file. Now you can keep combined files on your server or combine them on the fly using the above mentioned tools.

6.  Keep your JavaScript at the bottom of the page (follows from principle 3): Most people put the external JavaScript files as well as the inline JavaScript in the head of the document without much thought. This is bad because since almost all the JavaScript you have in the head is there to do something with the DOM but the DOM is not even loaded yet. So you didn’t need the JavaScript right now. The net effect it has is that user perceives your site to be slow because while the external script file is being downloaded and parsed or your inline JavaScript is being parsed the browser can’t render any HTML or make changes to the existing HTML. But if you keep all your JavaScript somewhere close to the ending of body tag the user starts seeing content of your page pretty early. So this doesn’t actually make your site fast but creates a perception of being fast which is pretty good because after all users don’t sit with a timer in their hand to measure your load time and they don’t even care how much data comes down the wire because they are busy looking at your content. There was a saying at Microsoft that “if you can’t make it good at least make it look good”.

7.  Keep your css at the top of the page(follows from principle 4): If you place all your css at the start of the page the browser knows beforehand what the size, position,margin,etc of the elements is going to be. If the browser comes to know about the style of the element after it has drawn it, it has to redraw the element with the styles. So tell your browser about the styles before it draws the element.

8.  If inline JavaScript exceeds 50 lines make it external (follows from principle 2): Don’t write too much inline JavaScript. Better keep it in a file because the browser can cache it and also it keeps the HTML clean.

9.  Serve JavaScript libraries from Google’s CDN (follows from principle 2): Almost all the popular JavaScript libraries are present in Google’s CDN. So instead of serving those libraries from your server use Google’s CDN. This saves your bandwidth but because a lot of sites already serve these libraries from Google they might be in the user’s cache which saves the overhead of 1(maybe more) HTTP request.

10. Make minimum number of DOM modifications (follows from principle 4): Each DOM modification is costly because whenever you add or remove or resize an element something called ‘reflow‘ happens. Because of reflow the browser has to recalculate geometry of all the elements. So the next time you do something like adding 10 divs under a div, create a document fragment with document.createFragment and then add those 10 divs to the fragment and add the fragment to the parent div.