How to speed up a website
by Chris Woodford. Last updated: October 11, 2016.
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 recent
"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.
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.
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.
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
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
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.