[Re]Encoded.com

10 Ways to Minimize Site Loading Time

All of us has occasionally ran into a web site that was slow to load or worse yet, refused to load at all. As you are well aware, this can be a rather frustrating experience. You are probably among the majority of Internet surfers who would just as soon hit the back button of their browser rather than sitting there waiting for the painfully slow progress of the status bar.

Obviously, frequent instances of slow loading times and downtime do not bode very well for any web site, especially your web site. If this type of thing happens often enough, you may well end up losing a lot of visitors. The question then becomes what then can you do in order to minimize these occurrences? The answer is to find ways to minimize your web sites loading time. The following is a list of ten ways to do just that.

Find your performance issues using Web Tools

One of the easiest ways to do this is with the use of a program called YSlow. This is a tool for front end designers and tells you why they are slow after analyzing the web page. This analysis is primarily based on the rules of high performance websites which is located on Yahoo!’s developer network. Although many of these high performance rules are common sense, some rules apply only to those websites that get millions of unique hits each day. While this tool is not the absolute last word on performance problems, it is a good starting point. And will give you an idea where the problem areas are.

After a run with YSlow on a test website the problem became rather obvious:

The YSlow results for test website. Obviously this site needs some improvement.
Not only did the results indicate a performance grade of only 31, the size of the page load was a huge 1320.5k. To get an idea where that large weight was coming from, check the size of the java script, style sheet, and image folders for the site. Remember that any bytes being sent to the client will result in a lag time in page display.

Another useful tool is the Google Webmaster Tool’s Site. The performance feature display will look like this:

The performance review depicts a graph of the combined speed numbers for the website, based on those pages that were accessed most often by visitors who used the Google Toolbar when the PageRank feature was activated. Google will not test your site from a location that your users do not use. If, for example, your users are all in Italy and your site is in Italy, the chart will depict the load time as it seen in Italy. Likewise, if most of your users use high speed broadband or dial up connections which would be reflected in these numbers as well.

Reduce the size of the downloaded content

Most people don’t take into account the backend (or server side) of the code when they are performing site optimization. The reason is that this code accounts for only about 20% of the response time of a web application. The bottom line is that the majority of the problem starts with the browser, and the very first thing a browser does is download all the content it needs to display to the user. So what needs to be done is to help it along.
To accomplish this, what is to be retrieved must be simplified. Reducing what a browser agent has to download from 750kb to 250kb is a big help. Also, reducing the number of files to be downloaded from two 125kb files to one 250kb file is another big help. Remember that it takes time to initiate a connection to the server.

Use a Content Delivery Network

There is a definite relationship between response time and the web server’s proximity to the user. For faster page loading, deploy your content across numerous, geographically dispersed servers.

Don’t try to redesign your web application to perform in a distributed architecture. Although it depends somewhat on the application, changing the architecture might include such daunting tasks as having to replicate database transactions across server locations and synchronize the session state. Any attempts to reduce the distance between content and users could result in this architecture step causing a delay.

The Performance Golden Rule is that approximately 80% to 90% of the user response time is used downloading all the components in the page including Flash, scripts, and images. It is better to disperse your static content rather than having to start with the difficult task of having to redesign the architecture of your application. This will not only achieve a greater response time reduction, but it is also easier as a result of content delivery networks.

Put Your Stylesheets at the Top

To make pages load even faster, move your stylesheets to the document head. The reason for is that this allows progressive rendering of the page. Designers want pages to load in a progressive manner. The browser should display its content as quickly as possible. This is especially important users that have slow Internet connections and for pages that have a lot of content. It is important that the user receive visual feedback such as a progress indicator. This helps improve the overall user experience.

Put Scripts at the Bottom

The problem that scripts cause is that most times they will stop downloads in parallel. Browsers should download in parallel a maximum of two components for each hostname. Should you serve images from numerous hostnames, the result is that at least three downloads will happen in parallel. However, during the time of script download, the browser will not start any further downloads, even when on hostnames which are different.

It is not always easy to relocate scripts to the page bottom. For example, if a script uses a document.write to insert any content of the page, it can’t be moved to the page bottom. Also, there may also be issues with scoping. In most cases, however, there are workarounds for these situations.

One alternative is to use scripts which are deferred. The script will not contain a document.write if the DEFER attribute is used which therefore tells the browser that it may continue rendering. Unfortunately, not all browsers support this attribute or at least not nearly as much as is desired. However, a deferred script means that it can also be relocated to the page bottom. This will make the web pages load even faster.

To display the effects of numerous hostnames, the following graph depicts a simulated user with an effective bandwidth during the loading of a page having numerous objects of any given size, with an effective bandwidth which is determined by dividing the total number of object bytes received by the time necessary to receive them. Perhaps more clearly, the following graph shows how much faster pages could load with an assortment of the most common access latencies and speeds with several external objects spread out over four hostnames. The baseline is one hostname.

Interesting things to take note of:

A.) For those objects that are relatively small in size, depicted in the left hand portion of the graph, it can be seen just how small the amount of downstream bandwidth is utilized from the empty space immediately above the plotted line. All the while the requests from the browser are happening as quickly as is possible. This user is requesting objects, which are larger in size than 100k, before the downstream bandwidth that is available is filled.

B.) For those objects under about 8k in size, the effective bandwidth can be doubled by spreading the requests over four hostnames. This is a huge gain.

C.) Should the user enable pipelining in his browser, the number of hostnames used wouldn’t matter, and the user could make more effective use of available bandwidth. But the server side can’t be controlled.

The following is a graph that shows, perhaps more clearly, how much quicker the pages can load for numerous common access latencies and speeds with several external objects which are spread over four hostnames. The baseline is one hostname.

Interesting things to note from that graph:
If objects that are smaller than 10k are loaded, users both local and on the other side of the world would see substantial and dramatic improvement from spreading requests over four hostnames.

Users that are further away show a much greater amount of improvement.
This will become even more evident as access speeds increase. The user who was a distance of 20ms from the server and on 100meg Ethernet enjoyed the greatest improvement.

Remove All Duplicate Scripts

If you use the same script file twice on the same page may hurts performance. Duplicate scripts hurt performance by wasted script execution and by creating unnecessary HTTP requests.
Unneeded HTTP requests happen all the time on some browsers. Should an external script not be cacheable and included twice, it generates two HTTP requests while the page is loading. Even if the script is cacheable, when the user reloads the page an extra HTTP request occurs.
In addition, time is also wasted while evaluating the script numerous times. This redundant script execution happens, regardless of whether the script is cacheable or not.

The Earlier You Flush the Buffer the Better

It can take anywhere up to 500ms for the back-end of the server to put together the HTML page each time a user requests a page. During this period of time, the browser is waiting for the data to arrive and is sitting idle. The flush() function is available in PHP. This function permits the sending of your partially ready response back to the browser which allows the browser to begin fetching components during the time the back-end is completely busy with the remainder of the HTML page. This mainly benefits light front-ends or busy back-ends.
Since the HTML for the HEAD command permits you to add any script files so that the browser can start fetching in parallel while the back-end is still processing and it is easier to produce, a good place to consider flushing is right after the HEAD command.

Component Preload

Although preload may appear to be the exact opposite of post load, in actuality it has quite a different goal. By preloading components you can request components such as scripts, styles, and images, and take advantage of the time the browser is idle. This way when the user visits the next page, you could have most of the components already in the cache and your page will load much faster for the user.

There are actually several types of preloading: Unconditional preload. Fetch some extra components as soon as the files are on loaded; Conditional preload. Make an educated guess, based on previous user action, where the user is headed next and preload accordingly, and; Anticipated preload. Before launching a redesign, preload in advance.

Splitting Domain Components

Splitting your components permits you to increase your parallel downloads to the maximum. Be sure you’re not using more than four domains to avoid the DNS lookup penalty. For example, you can host your dynamic content and HTML on www.thisexample.net and divide your static components between static1.thisexample.net and static2.thisexample.net.

Reduce Cookie Size

Cookies are employed for numerous reasons including personalization and authentication. Cookies information is exchanged in the HTTP headers between browsers and web servers. It is very important to maintain the cookie size to a minimum in order to minimize the impact on the response time that impacts the user. Basically, the rules are: Eliminate unnecessary cookies; Keep cookie sizes to a minimum to reduce the impact on the user response time; Set cookies at an appropriate domain level such that other sub domains are not impacted; Set an appropriate Expires date. No Expires date or an earlier one removes the cookie sooner which improves the user response time.

To determine how well your website is doing and if you are going in the right direction or not there are numerous traffic graphs available such as the following:

Other useful graphs may include a performance graph such as illustrated below:
The graph below depicts the number of requests that the website can process in one day and the rate at which reports are being produced. Typically, the slow periods are when the server has experienced high loads when website crawler bots does not honour the robots.txt file.

The Pages is the number of unique requests processed and the Requests measure the total number of requests processed by the system. A request is created whenever a user requests a website page, where a previous request exists, or whenever a report is submitted which requires new distribution to be uploaded. A page can either be an author page or a distribution page.