Having come across this article on Building43 “Excuses for Bad Web Performance“, I figured I would write up a quick guide to troubleshooting slow web site performance and some tips on avoiding it.
Why is this important? Well besides user-experience, and how people hate slow sites, it is also considered a factor in search engine ranking for sites, so here is my guide to optimisation:
Tools – Visualising Slowness
Use Y-Slow & Firebug: these 2 browser plug-ins are a great way to figure out why your site is so slow. Firebug has a net panel which shows you all the files downloaded for a page to load, the request times for them and the time it took to download them. These are obviously key pointers when the site doesn’t necessarily appear until a range of files are downloaded and in place.
Above and beyond these in browser plug-in you will want to consider using web site monitoring services that provide you with real-time charts and long-term analysis of your web sites performance from multiple locations around the world. Just because something is fast for you doesn’t mean the same will be the case for users everywhere!
Reduce File Requests
Reducing the number and size of requests, i.e. to pack as much JS and CSS into single files, and to optimise and minify the code is also a good idea to help improve speed of requests to load a page. Once the file has been downloaded the first time, the file will be cached int he end users browser, but there is always the initial hit.
To this end, there are hosted libraries on Google APIs which are being used across a lot of sites, to this end, you can potentially save yourself a request or two for these files by using these shared, remotely hosted files. Moreover, even if the files are not already cached in the site visitor’s browser, the fact the file comes from a remote host means that it will be downloaded concurrently, alongside other files from your servers, and help speed up the load time.
On the flip side, if any specific host is taking ages to respond to requests, you need to identify this and remove it from the mix as quickly as possible. On a high traffic site this could mean affecting hundred or thousands of visitors, though even on a single site with low volume traffic, it’s not nice to push your visitors away with blank browser windows for seconds and seconds.
Lazy Loading & Optimised Images
Lazy loading uses the idea that you do not load content into the page until the site visitor is ready to see it. Imagine a collection page with 250 images in the gallery and then trying to load them all in at once, despite the visitor only seeing 10 at a time. Why load in 3MB of data when you can load in 200KB for example. It’s doesn’t make sense, therefore use JS to load them in “on paging” as the gallery scrolls, or load the page and then load the images in via the background with JS.
On top of lazy loading you might want to consider optimising your images, not just by compressing them to a minimum without loss of recognisable quality but also by using sprites for common web site assets such as logos and buttons. Sprites are where you place multiple image assets on a single canvas and then use background position in CSS to display the required asset in the HTML element. A single image load is much fast er than 2-3-4-5-6 and so on.
Multiple Hosts & Fast Static Servers
Even if going to the same directories on the server, it is worth setting up multiple hostnames for example www.domain.com & assets.domain.com to allow some of the content to be downloaded from one and other content to be downloaded from the other concurrently.
In addition to these multiple hosts you will want to ensure that any static content, such as image assets, JS and CSS comes from the FAST source. Given that ZERO evaluation needs to be processed before sending the request optimising that side of the equation is key to getting MASSES of images out via the network ASAP. Pushing content to a content distribution system helps with this.
Caching Through The Nose
When your site is being pummeled by requests and the database is being overloaded you need to cache as much content as possible. To this end you can run a data caching layer in the form of Memcached and you can use HTML caching such as Squid. It’s all about the reduction of processor time to get the content “out the door” and over to your clients. This kind of best practice is useful when you are working with heavy data-sets and web services, such as those used for open APIs at museums.
Analyse Your Configuration, Code, SQL & Data
Analysing your logic, queries and data at every stage of the serving process is important to removing bottlenecks. Making sure your database search queries are optimised with indexes and that your php logic (or whichever language you use) isn’t sucking up unnecessary processor time or sucking up tooo much memory is important. Write, re-factor, and then re-factor again. There are always ways to streamline and bring your code and queries down to the lowest common denominator. Whilst using services like memcached you will want to ensure that every second page load will reduce the number of database calls down to zero.
Above and beyond these things you will also want to look at your base setup. I know for one that the default config of Apache isn’t optimal for serving up some heavy duty sites, especially when you live in a world of heavy downloading, so the connections remain open persistently for long periods of time. Therefore you need to look at the config, make sure the available RAM is enough and that the number of child server instances is enough etcetera.
Hosting & Your Target Audience
Making sure that your site is hosted near its target audience is important. A site hosted in the UK will provide SLOW load times to the Japanese marketplace compared to a site hosted in Asia. This doesn’t necessarily mean you have to run an entire copy of your in each market place but you can optimise the process by providing content distribution networks that help transfer the content to the site visitor from the nearest possible location. To this end, static content such as images, CSS and JS can be loaded via CDN and any uncached content, such as that from the database, can be loaded up from your primary location.
Shared vs Dedicated vs Cloud
When hosting a highly trafficked site, you will want to ensure your content is being served under optimal conditions, and if you are running the site of a shared environment which is being hammered, you are not going to get the best load times. Shared hosting might be cheap but you also get what you pay for. And just because you are “on the cloud” doesn’t mean you are doing much better. Personal experience of Mosso Cloud and other Cloud services recently tells me that there is still benefit in being in charge of your own dedicated server, managed or not.
One thing is for sure, when operating a site with multiple heavy duty functions, for example popular forums and a popular download e-commerce site, you will want to decouple the functions, and run the 2 different sections of the site from 2 different machines. Not only does it mean that one service impinges on the other, but overall the two can live in better harmony and users can enjoy a better browsing experience.
Manage Updates – Scheduled vs Real-time
From a more human and less technical perspective, when site visitors know there will be an update at a specific time on a certain day, and they are actively interested in that, i.e. at Last.fm when the charts were being updated once a week, site users will visit and the site will get hammered with obvious regularity once a week. To avoid this using real-time updates or an irregular schedule is a way to avoid this. Every action has a repercussion, and when you send out an email to 50,000 recipients all in one go you can also assume they are all going to hit the site at once. Thinking before you do things is another way to avoid site overload and inevitable slowness for your users.
And All This, Why?
So much effort for so little it might seem, but we have to remember why we are doing this. Website performance is about good user experience, and visitors will not sit around on a slow web site, especially when there are thousands of other alternatives. Would you ever shut the door in the face of potential customers interested parties? If not then why bother serving up slow content and service?
Share
I am, for want of a better word, a web developer. Practising since '96 and
focused on front and back-end work with a slant for optimisation.
I love music, art, and helping people, traits which I hope are borne out here.
Read more about me and this blog on the 
No Comments so far ↓
There are no comments yet...Kick things off by filling out the form below.