The speed of which a website loads, from pressing enter to appearing fully rendered on your screen is an important factor to consider when developing a website. First of all I will explain the many elements that are inside of a web developers control. A basic html web page, consisting of just text, with no images, javascript, styling etc is the fastest type of web page to load. Figure 1 ( is a simple web page which simply redirects the page to Google Mail. It has no images, no styling, not even a font defined. A page like this will load and render the fastest as there is very little data to transfer (392 bytes to be precise) and the performance of the PC is negligible as all it's rendering is text. The page you are viewing now is coded using HTML5 and CSS3 with minimal javascript elements and large images, which massively affect the loading/rendering time of a web page.

Server Side

Server side issues which can affect performance involve the web server capacity, the available bandwidth available, executions required before page load, the number of hits the page has had, and file types. All these factors are outside the users control, and can be limited and optimised by the web developer. A web server is in fact the same as the PC you are on now, with some modifications to allow multiple NIC's (Network Identity Cards) and usually more stable and faster hardware. They will typically be located in data centres but as a web server is just a PC, there is nothing stopping you from hosting one at home. Web server capacity is closely related to my rant about hosting here in my web architecture article. The capacity of a web server typically depends on how much you spend on hosting. The capacity of the web server depends on the server, as with servers, like PC's, the come in all different shapes, sizes and most importantly specification. Hosting for $3.99 will get you shared hosting. This can mean that your website will be hosted on a web server alongside maybe hundreds of others. For an information website, this may be fine as the web traffic to and from the website on the web server may only be small. Traffic is a key issue with web servers and is an exploit DDOS attacks usually use. A typical web server can usually handle between 2 and 80,000 simultaneous connections to clients, which is by default is between 500 and 1,000. As previously stated, 500 to 1,000 connections may be fine for a web server hosting many many low traffic information websites but does leave it very subjectable to overloading, as if one of the web sites on the web server becomes viral, to say the become very popular, it will have a negative impact on all the other websites on the web server, as it may overload the server leading to the webserver to becoming unresponsive.


The bandwidth between the web server and the client can be divided into three main sections, the bandwidth available to the web server, the bandwidth/geographical distance between the web server and client, and the bandwidth available to the client. bandwidth in a computing sense is simply the transmission capacity of a computer network or other telecommunication system. This is measured in megabits per second (Mb/s (note lowercase b)). The bandwidth between a typical web server in a data center and the Internet is typically over 1Gb/s+ and coherent (same up and down) meaning there is usually plenty of bandwidth to transceive data for all the webservers needs. large websites, such as Google, will have a number of not only webservers, but dedicated data centers, with a load balancing system in place to ensure that traffic is equally distributed. Depending on the type of website, different types of websites will require different amounts of bandwidth. For instance a streaming media website such as YouTube, Spotify or Netflix will require more than one web server, more whole data centers (plural), with hundreds of GB/s (Gigabytes per second) bandwidth as they will be simultaneously streaming media to thousands if not millions of clients.

The geographical distance between server and client is also a big factor when it comes to bandwidth and latency. An excellent example of this is to do a speedtest to two different locations, however for arguments sake I will use three; Manchester, San Francisco and Wellington. To conduct this little experiment I used OOKLA's speed test service, to test the upload, download and latency between the various servers and the client. The client PC is located in Coleg Llandrillo Cymru and has fiber optic broadband provided by The JNT Association which has a total available bandwidth of 140GB/s, however only a portion of that is devoted to Coleg Llandrillo Cymru. Safe to say however the broadband in College is fast, and perfect grounds to perform this experiment.


The first test was performed between the client and Manchester. There geographical distance between these locations is about 50 miles showing a nearly completely symmetrical result 95Mb/s either upstream and downstream. Latency is also good, at 16ms. Latency is the time taken for a ping request to go from the client to the server and back to the client. this means that a website loading from a webserver in Manchester would load very fast indeed.

The second test was conducted between Coleg Llandrillo Cymru and San Francisco. The distance between these locations is about 5150 miles and the impact on the results are dramatic. The download speed is reduced to 11Mb/s and upload to 13Mb/s, which is still pretty symmetrical, albeit slower overall, but still fast enough to stream video if necessary. The impact on latency however is the killer. An increase of 882% from 16ms to 157ms. This would mean that it would take an extra 141ms for the page to load, not counting the slower connection speed and the increased packet loss.

The third test was administered between Coleg Llandrillo Cymru and Wellington, New Zealand. New Zealand is about 11600 miles away from Coleg Llandrillo Cymru and the fact it takes only 0.3 seconds to go from the client, to the server, and back is quite a feat in itself. However for realistic web server it would have a noticeable negative impact on website performance, a 1775% increase in latency is likely to be noticeable. The upstream/downstream speeds are no longer symmetrical, and the speeds are greatly degraded.

The map above demonstrates the distance between the server and client in each of the tests. The aim of these tests was to show how the available bandwidth of the internet itself differentiates geographically, and the importance of having your web server local to the target area.

The connection between the client and the internet also has a great impact on website performance. For instance a client with dial-up internet access, compared to a client with fiber optic broadband, will have a harder time trying to view any online content at all, as everything will take a long time to load, and streaming media would be impossible. Dial-up is an unfair comparison however, as there are always broadband alternatives, be that a landline ADSL, Fiber Optic, mobile network or even satellite, offering usually at least 2Mb/s download speeds, which is fast enough to steam medium quality video. Other aspects which can affect the bandwidth of the client, is the ratio of users to connection. If for instance there is more than one device connected to the internet on the clients LAN then this may have repercussions on the bandwidth.

YouTube has an interesting page here about the bitrates of the various resolutions that they offer. For arguments sake lets take the average broadband speed from ofcom, 15Mb/s and four clients streaming HD media at a resolution of 1920x1080. This equates to 4.5Mb/s per client, being used with a total of 18Mb/s being used. As each client has only 3.75Mb/s of bandwidth each, it will lead to inconsistent playback and will lead to the individual clients switching to a lower resolution. Clients can increase their total available bandwidth by upgrading to a broadband package with a greater download bandwidth, or reducing the number of simultaneous users.

Another big impact on how a page loads is the number of executions required on the server side before the page loads. This mainly takes the form of server side scripting using languages such as PHP, java, Python, ASP, Lua etc. These can be doing functions such as responding to user queries, accessing databases, customisation of the webpage for individual users and so on. This website, WebTech, doesn't require much in the way of server side scripting, save for the discus panel on the homepage, and the contact us form, powered by google. This ultimately speeds up the speed of which websites load on the clients web browser dramatically as there is not much need for webtechs servers to process much data before sending data to the client.

There are some websites however which require server side processing, for functions such as eCommerce, and all of the above. In this case it is important for the webmaster to have invested in good hosting, with enough processing power and bandwidth. A web company such as eBuyer for instance will rely upon server side processing for its eCommerce functions, security, and all user interactive ability.

The number of hits a websites receives also makes an impact on website performance. DNS servers caches the website IP for a specific amount of time, and if the website doesn't receive any traffic for months at a time, then it will impact on the performance of the initial page load, as the DNS request may have to go to the original registrars DNS server for resolve the IP. Webmasters can monitor the traffic on a website by using analytics tools. This website uses google analytics (because its the best) to monitor traffic. Below is a screenshot of the Google analytics account used for WebTech.


As demonstrated, Google Analytics displays a graph for the total visits to the website for the past month, giving the webmaster, and indeed the client (client referring to the website owner, not the end user) to when their website is busy, and where in the world they have a large audience among many other features.

The file type used for various aspects of a website can have serious repercussions on the website performance, perhaps the most of all. To begin with, before we delve into the different individual file formats, we have to look at the three main file compression formats; uncompressed, lossless and lossy. Uncompressed formats such as BMP, WAV and AVI are formats which do not apply any form of compression, therefore giving the best possible quality, but at a price of very large file sizes. Using uncompressed TIFF images on this website would lead to very slow load times for that image, using up bandwidth unnecessarily.

Lossless formats allow compression without losing information or degrading the quality of the file. These are prefered to uncompressed, but still have rather large file sizes. Lossless compression formats include (but are not exhaustive) ZIP files; TIFF, PNG and GIF images; FLAC, ATRAC and MLP audio. There are very few consumer grade lossless video file formats but formats such as FFV1 and Dirac however lossless (and uncompressed) video formats are seldom used as they result in enormous file sizes with 30mins of video pushing past the 100GB mark. These are unsuitable for their intended use, and are therefore not used often.

Lossy formats are formats which produce the smallest file sizes, as they discard irrelevant data as the compression encoders will eliminate redundant and unnecessary information. This will lead to a near identical file to its uncompressed counterparts, however at a lower quality. The JPEG file format is possibly one of the most used file format in the world as it offers high quality at low file sizes, as it uses lossy compression techniques. Most images on this website are compressed in a JPEG format, including the images in this article. Sound is very commonly compressed in a lossy MP3 format. For instance in my music library I have both lossy and lossless versions of a song by the title Life is a lemon and I want my money back by MeatLoaf (my media player, Foobar, automatically prefers lossless over lossy) and where the AAC version of the song is only 16MB the FLAC version is 60MB. Although the FLAC format does sound better (and supports 5.1 surround sound beautifully) than the AAC format, using average speakers the difference is slight. On a website a MP3 or OGG vorbis etc. format will normally be used to reduce the amount of bandwidth required to stream the audio.

Similarly with video formats there are a number of good lossy compression formats such as MP4, OGG theora and my personal favourite MKV. Websites, such as YouTube, use the popular H.264/MPEG-4 AVC format (usually simply called MP4) as it offers a good compression to quality ratio and more importantly can be decoded on practically any platform.


A good tool for determining the load time of your website is pingdom's Website Speed Checker. The results for WebTech can be seen here. WebTech is hosted on shared hosting, which isn't the greatest in the world (mostly because I'm cheap) and that has a large impact on site performance. The link above gives a breakdown of the individual requests done to load the page, and is useful for the web developer to improve various aspects of the site, to improve performance.

Client Side

The client side of the website performance spectrum is also a big part of the performance of a website. The main aspects at play here are; the available client side bandwidth, browser type, cache memory and computer speed. The available bandwidth to the client was previously covered, above therefore I will consider that covered, and move straight to the browser type.

The type of browser used to access a website, can, and will have repercussions on the website performance, but also how the website performs. If you missed my small rant about Internet Explorer, see here. Googles allows you to see what browser you are using (incase you didn't know) as well as recomending other web browsers for you to try and a brief introduction as to what a web browser is.

There are five main browsers in use today; Internet Explorer, Mozilla Firefox, Google Chrome, Apple's Safari and Opera, however this is not a web browser comparison article therefore instead of delving into the obstrosities of IE, and the greener world of Google Chrome, I will stick to the performance point of view, and compare the performance of a poor browser such as IE6 and a newer browser such as Google Chrome. Internet Explorer 6 is unfortunately still in wide use today and in some parts of the world the usage is as high as 30%. IE6 is terrible in practically every department, including its tendency to readily leak memory, be frighteningly unsecure and support barely any features of HTML5/CSS3. allows you to view a screenshot of your website in most web browsers, present and past, and below (at the bottom of the page) is a small gallery of about 144 browsers, across Windows, Linux and Macintosh showing how well the website is supported in each one.


The cache memory will affect the performance of a website in a good way, as what it does is store recently accessed web pages, allowing it to load part of the site from the local disk instead of requesting a brand new version from the web server. This works well, so long as the web page has not been modified and increases the page load time dramatically.

The performance of the PC in question will have the biggest overall impact on website performance, as it is the hardware at the end of the day which is going to render the web page. A 20 year old Tandy 1000 TL/3 running Windows 3.1 will without a doubt not perform as well as a newer PC. The CPU speed, amount of RAM, GPU speed, the NIC speed etc. will all have large repercussions on the speed the PC renders the web page, and depending on the age, and what web browsers it supports there may be little to no support of HTML5/CSS3, which is required for this website to perform correctly.