How to create a lightning fast website

Gold standard for web site speed by Wordtracker, the leading keyword research tool

Usain Bolt may be fast, but in the world of web design, waiting for nine and a half seconds for a page to load puts you firmly in the ‘also ran’ category, and will cost you valuable business online. But how do you check your site speed? And what’s on your site that’s slowing you down?

For many years now, Google has advocated fast-loading web pages as a valuable factor in good user experience, and has suggested that pages loading in under two seconds will be rewarded with a small, but subtle lift in search result positions.

While it is not always clear when (or if) sites are experiencing a positional lift from fast load times, having a site that takes an excessive amount of time to load will certainly see positions drop, and mean that users will 'bounce' away from your page rather than waiting for it to load; another indication to Google that users may not be valuing a site returned for a search query.

lightning fast website

The measure of success

So how do you measure your site’s speed? Google has a benchmark in the Labs section of Webmaster Tools that takes the average load time of a selection of pages across the site. This gives a rolling graph of site performance and can highlight any particular areas where server performance has spiked or flat-lined.

Site performance graph

Although it is always useful to gauge Google’s perception of a website, the speed benchmark isn’t always that accurate and for small or new sites, may even be completely unrealistic, or not updated on a useful basis. Google has also announced this feature is to be removed; a rather puzzling step considering their insistence on the importance of site speed and its inclusion as a factor in the ranking algorithm. But there are some other Google site speed tools available, like Page Speed which is available as an add-on to Chrome and Firefox.


Pingdom is another useful site and its tools section will allow you to run tests on individual pages. Although wide-scale speed monitoring of all site pages isn’t feasible using the free test option, a selection of representative pages can be periodically tracked. Pingdom randomizes the servers used to ping the target web page, so it’s always best to perform multiple tests on the chosen pages and take the average speed, to lessen the effect of outlying results.

In addition to this, registering on Pingdom allows you to set up an uptime alert, so if the server goes down an email can be sent out, rather than leaving you retrospectively looking at a puzzling dip in sales figures.

Speed Tracer is another free tool that you can use in the Chrome browser, which will benchmark a target page and, like Pingdom, gives a visual readout of the different page elements and the time taken to call, load and repaint the page. Breakdowns like this can help highlight any bottlenecks occurring on a site, such as external scripts taking too long to load, or excessive periods of graphical and text elements being re-drawn on a page. Speed Tracer also gives a handy score report, indicating if individual tasks are causes for concern in the time they take to execute.


Individual tests are useful, but another handy metric is how your site stacks up against the competition. WebPageTest is another free resource that allows you to compare different sites and even gives you a visual 'load race' which you can download as a video. In addition to showing if your site is faster or slower than competitors, it also shows at what point useful content appears for the user: so although a site may still be loading, users may be able to start interacting with content and be unaware resources are still loading up in the background.

Web page test

Room for improvement

There are other browser plugins that can offer gradings and suggestions of site speed improvements. Firebug and Yslow will analyze a page in a browser; they won’t benchmark the speed but will assign a score grade which you can compare against the competition to see how your website measures up. Each will also suggest areas of improvement: although these suggestions are pretty generic, there may well be some obvious quick wins that can be implemented to edge up the speed a little.

Firebug screenshot


As third-party plugins, you may experience some issues with browser version updates until the source code gets updated.

Common areas that can affect site speed are:


Large or high resolution images take longer to download and tie up server resources. Sometimes sites that recycle printed marketing material online don’t realize they are using high definition print-quality images, instead of web-optimized images that are far lower resolution.

Back ‘in the day’, chopping up large amounts of image content into smaller bits and loading them separately was a method of getting an image-heavy site to load progressively, especially when sites used tables to design the layout. However, each image – no matter how large – makes a separate server request when it loads. Combining lots of images into one big image (known as a sprite) and positioning this with CSS makes just one request on the server, speeding up the loading process and reducing the total number of bytes downloaded by a web page.

There are some limitations with CSS sprites, but generally background images, icons and graphical menu elements can be sprited into single images instead of being downloaded separately. If you lack a designer who can do this, there are even websites that will sprite your images for free.

Physical page size

Larger pages will obviously take longer to load and although raw text will usually load very quickly, extensive content may be faster to present, and easier to read, if broken into separately themed pages on a site. So rather than having pages that scroll on forever, think about ways you can break them up into more manageable chunks.

Rich content

Google places a lot of value on pages containing rich content, like videos and images, however this also takes longer to download and display. If hosting your own multimedia files, consider using a content delivery network These are a collection of web servers, located around the globe, designed to deliver content more efficiently to your users. Also ensure that streaming content is enabled where possible, so users do not have to wait for large files to be served and downloaded before they can consume content on your site.

If you’re using a service like YouTube and embedding your videos, try limiting the number of videos on each page, as too many will very quickly slow down the page load time.

With Google emphasizing that website owners need to present more content, and giving the opportunity for rich media, embedded on a page to start ranking in blended search results, it’s vital to ensure your site can cope with additional content. Presenting your site content quickly almost certainly makes the difference between converting a visitor or having them click away to a competitor and may do your overall position rankings a favor too.

White space

Although it’s easier for humans to understand code if it’s spaced correctly, each white space in code, like an extra space or a line break, adds to the overall page size and the time taken to download the page. Some pages generated by CMS systems can often add in vast chunks of redundant white space, which could be stripped out to provide a small, but noticeable saving on overall page size.


Having a large number of script files or external stylesheets will hold up page loading time as each is executed. If these are held on an external site you will also need to wait for these to be fetched, incurring even longer load times. Try to keep script usage down to a minimum and combine them into as few files as possible. If you have both external CSS style sheets and external Javascript, even something as simple as making sure the CSS comes first can make a significant difference. (CSS can run at the same time as other things, but JavaScript can’t. So if you put the script first, it will need to finish running before the CSS can start.)

Code order

Browsers execute page code in a logical order, starting at the top and working their way through the page until they get to the bottom. Although some scripts stipulate where in the document they need to be called on in order to work properly, having out-of-place scripts can often cause bottlenecks on a page as elements wait for the code to complete before new content is loaded. As a related point, inline JavaScript, that is, JavaScript that is on the page and not on an external style sheet, shouldn’t come between CSS and other resources. Again, they prevent the CSS from running in parallel with other things.

(We sometimes say that files running simultaneously is called ‘Parallelization’. 'Serialization' is when files run one after the other.)


If your site speed is struggling, it’s worth checking that your server and bandwidth is up to the task and configured correctly: even a speedy server box will slow and eventually crash if it is badly configured and filling up with large logfiles. Tools like Monitor Us can help. And it’s free.

ViewState Code pages are one of the most common type of dynamic web page on the web (dynamic just means that they change depending on user inputs. Static pages, ones written purely in HTML, will render the same regardless of what the user does). Often however, these can result in strings of code that can sometimes run on for pages. ViewState is one of the easier-to-implement methods on a server of storing information on a web page so that information on that page that has been entered or changed by a visitor can be kept if the page is revisited. Examples of needing to do this might be for a search query, contact form or shopping cart. If the information cannot be stored, and the user recalls that page (using a ‘back button’ in their browser), then they would get back to a ‘stateless’ page, where none of the details they entered would appear, effectively causing them to start from scratch. Not great for customer conversion!

Although good for customer experience, the way ViewState stores this information can quickly get out of hand: complicated forms or parameters lead to huge blocks of seemingly random text, which can bloat out the size of the page (this is the encoded or ‘hashed’ content of the information). If you ‘view source’ on your HTML pages and notice large blocks of this code appearing, then you may want to get a developer in to streamline the way you are handling persistent information across web pages.

Page source

If calling a web developer isn’t appropriate, or you just want to learn more yourself, Microsoft, the creators of have some resources available They also suggest a third party tool called Flesk to help you optimize your ViewState, and cut down on bloat.

Asynchronous JavaScript

AJAX is a new method to allow scripts to load in the background while the browser gets on with loading other parts of the page. AJAX was touted as an end to the ‘click and wait’ mentality of the web. Instead of waiting for page elements to load one by one before a user can interact with a page, AJAX allows multiple resources to load in parallel, so while text information is displayed and being read, supporting images will be loading in the background ready to display when the user gets around to investigating them, for example.

This is used a great deal by e-commerce sites, which have product images that can be magnified or scanned by hovering a mouse over them. Instead of loading these up when a user triggers them with a mouse click or hover (as with usual JavaScript) these will be loaded asynchronously and ready more-or-less instantly. It also allows more dynamic and interesting use of menu tabs and widgets, but can be used for other functions, such as Google’s web analytics code, which moved over to an asynchronous format some time ago.

As with any code element though, ensuring the correct position of the script on the page is essential in order to take advantage of the asynchronous loading. AJAX scripts need to be called at the head of a document (as opposed to the footer, where the old Google Analytics code used to be placed).

So what do you think? We’ve not written much on site speed before so if there are things you’d like us to expand on, join the conversation on Twitter.