Ethernet cable

How to speed up a website

by Chris Woodford. Last updated: February 22, 2020.

Okay, I'll let you into a secret: this isn't the fastest website in the world. It's a collection of detailed pages—long, hopefully helpful articles packed with text and images—so it's bound to load more slowly than a lot of other sites. At least, that's what I'd always figured. But when Google launched its "let's make the web faster" initiative, I discovered I had a lot to learn about website optimization. I'd put a lot of focus on things like the quality of my pages, ease-of-use, and accessibility, but in the process I'd neglected one of the cardinal rules of website design: users like pages that load quickly. Armed with a painful hint from Google Webmaster Tools that my site was among the slowest 20 percent of websites, I decided to set about doing what I could to improve speed without sacrificing quality. Here are a few simple things I did over the space of 2–3 weeks that improved the loading times of my pages by about 50 percent.

1. Regularly check Google Analytics

I was slightly skeptical when Google announced its page speed monitoring tool: why would anyone want to focus on page speed rather than page quality? But assuming you've already focused on your content, it makes sense to speed things up as well. It's a win-win-win: everyone benefits from faster pages. People on mobile devices—over half of all web traffic is now mobile—gain even more, since they're often on relatively slow cellphone networks.

If you use Google Analytics, you'll find there's a feature called Site Speed that measures the page timings for a sample of your pages. Keep checking that as you optimize your site. Get into the habit of measuring how quickly your pages appear to typical users (and don't fall into the trap of assuming that because your site runs fast for you (on a fast corporate network), it runs fast for everyone, everywhere.

2. Test your speed with page speed tools

Page Speed and YSLow

One of the quickest ways to assess your site's overall performance is to run it through Google's web-based test called PageSpeed Insights, which measures the speed of any web page as other users are likely to experience it (on both desktop and mobile), and offers simple tips for optimization. YSlow, originally developed by Yahoo!, is a similar tool that will give you similar advice, but it doesn't hurt to run both.

Chrome Timeline

What else can you use? In Google Chrome (and Chromium), look in Tools > Developer Tools and you'll find a handy little timeline panel that will draw charts showing you how all the elements of your page resolve their DNS, load from servers, and render into a finished web page. You can see exactly how long each operation takes, so you can figure out which bits of your page are responsible for the worst of your delay. There's a good little video on YouTube explaining how to use the timeline panel.

Web Page Test

One of the hardest problems with analyzing performance issues is knowing how other users are experiencing your website. It's quite possible you have your Internet service and hosting provided by the same company. In that case, when you view your website, you're almost certainly going to see pages loading at impressive speeds that don't reflect how slowly they might appear to people in other countries or continents. A really useful website called Web Page Test helps you to address that. You type in a web page address and then specify a test location somewhere in the world where you'd like it to load. The page will load into a dummy browser at that location, Web Page Test will log all the operations involved (from resolving DNS to loading files and rendering) and then draw you a chart showing how long everything took. This is a great way to discover if your hosting looks horribly slow from the viewpoint of other users. It's also really helpful if you have key traffic coming from a number of different countries and you want to optimize speed for your most lucrative territories. (I cover this point again briefly later on.)


If you want to test how well connected your server is to the Internet generally, you might find Pingdom useful. It pings your server from various locations around the world and gives you tables or graphs of the response time. It's important to remember that some servers give low priority to ping traffic, so you can't necessarily conclude your server is slow if ping times are high; however, you can get a rough sense of how well-located servers are on the Internet and compare different potential, worldwide hosting locations.

What makes my web page slow?

Sample output from speed test showing why a web page loads slowly

Here's a sample of the output from Web Page Test that I ran to diagnose why one of my pages seemed slow. It's a very detailed page about climate change and global warming, which has loads of text and images—plus some advertising. There's no way I want to reduce the amount of text or the number of images just to make page load times better; I'm not compromising on quality. But what else can I tell from an analysis of page speed—and what other improvements can I make?

The HTML file of the page is loading from a test server in the United States, while the images and CSS are loaded from a CDN (I think it was Cloudfront). Each horizontal colored block on the chart shows a separate item on the page that has to load before the page is complete: 33 of them in all. The colors within the block show DNS resolving time (dark greenish blue), initial connection (orange), time to first byte (green), and content download (blue).

Five things on the page are quickly worth looking at:

  1. This top line is my main HTML page. Note the long DNS lookup time (blueish green), time to serve up a byte, and download times. That's because the nameserver for this site is in the UK, the hosting is in the United States, and the test location is Sydney Australia! No surprise that it takes a long time for a computer in Sydney to figure out where my files are (DNS lookup) and pull them over the network.
  2. This is my CSS file downloading. With help from PageSpeed, I've made this extremely small and I've also put it on my CDN. The long DNS lookup time is the time taken to resolve the DNS of my CDN. But since my CDN is serving up most of the remaining files, that's not a big issue.
  3. This section is mostly the downloading of image files from my CDN. I'm concerned by all that blue. These long download times show files are taking ages to get from the CDN to the browser—precisely the problem a CDN is supposed to solve. I need to investigate whether the CDN is operating correctly and loading things from the right place. With a browser in Sydney, it should be loading files from somewhere in the Asia/Pacific region.
  4. By the time section 3 is finished, my page is pretty much loaded—in about 2.5 seconds, which I think is not bad at all considering how big and rich the page is. However, what's all this extra activity? It's advertisements that are taking fully one more second to load. Is advertising slowing my page down too much? That's something I can investigate. Chances are the advertisements are asynchronous (loading inside my page after the rest of it is built), so that may not be a concern.
  5. The page finally, fully loads when we cross that blue line at about 3.5 seconds.

What difference does it make where you locate your server?

I was running this test to try to figure out whether to relocate my hosting from the UK to the USA, where I'd set up a dummy version of my website serving identical files to the ones normally served in the UK. It's a snap to rerun a test with identical pages located on two or more servers and then compare all the DNS lookups, file loading times and so on to see what difference the server location makes. If you're doing this, be sure to repeat the test a number of times at different times of day to rule out arbitrary factors (such as network congestion). Try a number of different browser locations around the world and see how the page load speeds compare.

3. Minimize the number of files per page and the total size of the page

If you judge by the size of the main HTML file alone, you might be surprised how big some of your pages are when they finally show up in a user's browser. You can find out by loading a typical page from your site then saving it as a "complete page" (a folder containing all its images, javascript, CSS, advertisements, widgets, and other files), then simply calculating the total size of the folder your browser creates. Prepare to be amazed as your little 35K HTML page bloats up to a total page load of 200–450K, as some of mine do!

Your mission is to reduce the number of files loaded by your pages (since more files mean more HTTP server requests) and the total size of those files (since bigger files take longer to travel over the Net from server to browser). Look through the files in the "complete page" folder and figure out a) which ones are biggest (if images make up 90 percent of your page size, that's really what you need to focus on) and b) which are most numerous (have you got dozens and dozens of small thumbnails or icons you could rationalize somehow to reduce the number of HTTP requests?).

It's also important to minimize the number of different servers you use to serve up the files on a page. The browser will need to lookup the DNS details of each server, so the fewer servers you use the better. This is what the page speed tools mean when they say "minimize DNS lookups."

4. Cut the size of common files

With the help of the Page Speed addon, try to reduce the size of any common files loaded by most or all your pages (things like your CSS files, your header graphics, social bookmarking icons and so on). Simply reducing your main CSS file by a few thousand bytes will bring an improvement, since that file may be loaded tens of thousands or even millions of times a day. Page Speed may also demonstrate that switching some graphics from GIF to PNG (or vice versa) will save you thousands of bytes with no perceptible loss of quality. Cutting your common files will give you a speed improvement and a bandwidth reduction too, so it can save you money.

5. Use CSS as much as you can

One key principle of speeding up your site is to throw workload from the server onto the browser. One way to do this is to use CSS for visual effects. For example, suppose you want black borders around all your JPG images. You could do that in a graphics package, but you'll make every single file bigger and slower loading in the process. Far better, you could add a border to some or all your images simply by styling an IMG in your CSS file. That way, you get the same effect but your files stay smaller and faster. The same goes for social networking icons. You may have a dozen or more little PNG icons loading on each page, one for Facebook, one for Twitter, and so on. But did you know that loading each one of those slows down your server? The recommended way to reproduce those icons is to use a single image containing all the icons and a bit of CSS called a sprite that lets the browser pull just the relevant bit out of the image in each case.

6. Use gzip/deflate compression for HTML

If your site is like mine and heavy on words, you might wonder what you can do to improve speed. After all, the words are the most important thing and there's no way to reduce them. True enough, but if you have large, wordy pages try to enable your server so it compresses HTML files while they're in transit (it's a bit like sticking your HTML into a ZIP file). One simple way to do this is to enable gzip or deflate compression, by modifying your htaccess file (assuming you're using an Apache server). This puts an extra load on your server so it may not be enabled by default by your hosting company; ask your tech support people for help if you can't make it work.

7. Compress images if you can

I routinely compress JPG images to about 75 percent, which I find gives an acceptable tradeoff between quality and file size. When I first set up my site, I decided to put drop shadows on all my JPGs, which I now realize adds little to the aesthetics of the site but makes all the images about 25 percent bigger than they need to be and costs me a lot of money in bandwidth. It's now become possible to do drop shadows with CSS styling, so adding shadows to individual photos is pointless and unhelpful.

I've also noticed that quite a few of the more "decorative" photos can be compressed down to 70 percent with little loss of quality and a considerable reduction in size. I identified about 1000 images and decided to change their JPG compression from 75 to 70 percent. Sounds like an onerous job? It takes just a few minutes. First, make a backup copy of all your images in case something goes wrong. Then put all the images you want to compress into a new folder and load them into your favorite graphics program (GIMP, Picasa if you still use it, Photoshop, or whatever you prefer). Then select all the images and export them as a batch with a compression of 70 percent. It's automatic! Once you've done it, look through all the compressed images and make sure nothing is too blurred or fuzzy. If it is, simply ditch that image and go with your original version at 75 percent compression or higher.

While we're on images, remember to use the optimum file type for the image file you're using. Generally (but not always), JPG is best for photos and GIF or PNG is best for illustrations and icons, but always check what comes out smallest. Don't automatically use one file type or another without checking first which gives the best quality and smallest file size (many people simply use JPG for everything because it's never occurred to them to try anything else). Sometimes JPG will blur writing or annotation on photos to an unacceptable degree, obliging you to use a bigger PNG file. Sometimes PNG files comes out far bigger than GIF with little or no improvement in quality. Experiment with making PNG files that are "indexed" instead of RGB and you'll find you can often cut their size by 50–75 percent. If you have animated GIFs with a number of frames, you'll find they can be very large. One way to reduce the size is to reduce the number of colors in the palette from, say, 255 down to 128 or 64. That can give a dramatic reduction in file size with little or no reduction in image quality. If you think file size is going to be a problem, you can be smart and draw your image with a small color palette (8 or 16 colors) to start with.

8. Watch those scripts!

If you've got lots of external scripts loading from your page (news plugins, advertisements, widgets, page trackers, "follow-me" buttons, and so on), you're obviously going to slow it down. Make sure all the stuff on your page is earning its keep. For example, if you've got an Amazon "deal of the day" advertisement widget on your page and no-one ever clicks on it, take it off right now. It's doing nothing for you or your users and giving Amazon a free advertising ride on your site; it's slowing your page down—so get rid of it! As a general rule, the more third-party servers your site calls (for advertising, social media, or whatever else), the slower it will be: each new server you add will require another DNS lookup and more http requests. So keep the number of servers to a minimum. You can check how well you're doing with this by running a speed test from Web Page Test; when the results come in, click on the "Domains" tab to see how many different domains (servers) you call, what percentage of the page load requests and bytes each one is responsible for, and therefore how slow each of these servers makes your site).

9. Trim any hidden page fat

My site's A-Z index is simply a list of all my other pages. Each item on the list is a link to another page with a little colored dot (a PNG image) to indicate how easy or hard the page is for readers of different ages and abilities. But for each of those dot images, I'd also added an ALT tag that was about 5–6 words more wordy than it needed to be. Multiply 5–6 words by the several hundred list items on the page and you can see the HTML as a whole was about 40-50K bigger than it needed to be. With a few search and replaces, and no loss of page quality, I cut the size of that page (and its loading time) by about a third. What hidden comments, spaces, or unnecessary page flab can you trim?

10. Put your hosting near your traffic

I confess that this is something I've not done. My site is hosted in the UK, where I happen to live, but it's aimed at a worldwide audience and the vast majority of my traffic comes halfway round the world in the United States and Asia. It would make sense—and speed up my site a lot—to locate my hosting nearer to where the traffic is coming from. But obviously there are other considerations in choosing a good Web host such as reliability, convenience, and cost to chew over before you relocate. I love the web hosting company I use and their reliability and professionalism is something I would be reluctant to lose for the slim advantage of a small speed gain. By using a CDN, I've got the point where only one file is loaded from my main server anyway, so that server's location is much less important than if it were serving up every single file for every page load. That brings me neatly on to...

Use a content delivery network (CDN)

How can you put your files close to your traffic if your traffic comes from all over the world? The easy solution is to put your "static" files (maybe your images and CSS—files that change rarely or not at all) on a CDN, which effectively copies your files to a number of different servers in different countries. When someone looks at one of your pages, the CDN serves the files from a location that's as near to them as possible, cutting file-transfer times dramatically. CDNs are now really easy for anyone to implement. Amazon Cloudfront and Rackspace Cloud Files are two pay-as-you-go CDNs that you can set up and have working in less than an hour; I've used both and they're both easy, reliable, and effective. You pay for the file storage space you use and the bandwidth the CDN uses serving up your files.

Find out more

On other sites



Please do NOT copy our articles onto blogs and other websites

Text copyright © Chris Woodford 2010, 2015. All rights reserved.

This article is part of my archive of old material. Return to the list of archived articles.