There are few things I hate more than a slow website – especially when it’s my own website. Yes, I’ll admit it: as it currently stands, our website is slow. Even though we have all the expertise to build fast websites, we need to invest some more time into making our own website a lot faster.
On average, pages in your site take 5.7 seconds to load (updated on Nov 21, 2011). This is slower than 80% of sites.
Google Analytics isn’t reporting much better. In fact, much worse:
It appears that over 70% of our home page visitors are seeing a page load time that is more than 3 seconds and that our average page load time (on the home page) is 10.6 seconds. I’m going to focus on the home page of our website for the purposes of this post.
That is just terrible. No one should ever have to wait that long to load a page. I sure wouldn’t.
Let’s see why this might be. We performed speed optimization about a year ago, but since then have launched new features, updated designs and added CMS functionality. My suspicion is that code has gotten less efficient in the meantime.
Speed Optimization Tools
I started by using a bunch of page load testing tools to diagnose our speed issues. Below are the ones I find useful. Comment below if you have any other great ones. Keep in mind that these tools don’t give you a full picture – they just show you what is wrong with the front-end your website. I will go into more detail regarding server and database optimization further down.
Google Page Speed
In Firefox, you can download Page Speed as an add-on to Firebug. In Chrome, it’s still experimental, so you’ll need to enter “about:flags” in your address bar, enable Experimental Extension APIs, relaunch the browser, then install the extension. Here is a help article on that. Or you can use the online version of the browser extension here. There’s even an Apache 2.x Page Speed module for those who configure their hosting.
What Page Speed looks like when installed in Chrome:
YSlow is another Firefox add-on that works with Firebug, this time by Yahoo!
GT Metrix combines these two tools into an easy-to-use online format, with comparison abilities. It will also give download time information.
Web Page Test is pretty much just all around performance testing awesomeness. The fact that a free tool can provide such information is amazing. Thank Patrick Meenan (now at Google) for this great piece of work.
Then I put the tools to use and here is what I found out about our website.
Google Page Speed:
Not bad, right? 95 out of 100. As I said, it only tells part of the story.
YSlow gave me a similar result:
WebPageTest.org, tested from New York, with a 1.5Mb connection, on IE8, gave me the following results:
It took a full 12.7 seconds to load our home page, with 1 second of delay to even begin downloading the page and 1.8 seconds to start rendering.
Here is a video of how our home page loads with the above parameters (1.5 Mb connection in New York). It’s pretty bad.
Conclusions So Far
Here are a few preliminary conclusions I have come to based on my initial research.
- The wait time to start rendering the page is extremely slow (almost 2 seconds just to start seeing something!). There is a need to look deeper at our database configuration to see if queries are optimized and if caching is being used to speed up performance.
- There are too many connections being opened simultaneously from the same host. One solution is to split content across multiple hosts, but in this case it can be more easily done by using sprites. We are making just under 100 requests to our host, www.bluefountainmedia.com and most of them are images that can be grouped together into sprites, thus reducing the number of requests.
- Images being requested should have their height and width specified before making the request.
- Images need to be better compressed without losing quality. Many of them are not as small a file as they could be.
I ran this page through webpagetest.org and got a load time of 10.3 seconds with 74 requests. Here’s what that looked like:
Then I created a version that uses sprites. I combined many of the images in a logical fashion then modified the html to pull the sprites rather than the individual images. This reduced requests down to 30 and page load time went down to 8.4 seconds. I noticed that there was more that could be done with the ordering of images to increase efficiency. Here’s what this version looked like:
Ordering of Sprites
Using the waterfall view of the page as a guide, while keeping in mind that it’s important to load content above the fold in a graceful manner, I re-ordered the sprites and split one into two. The result was a load time of 7.85 seconds.
From here, there were 3 options moving forward:
- Move some images to another host so that they can be downloaded concurrently to other images.
- Change image types from PNG-24 to JPEG on some of the larger images and take some measures to reduce file sizes on images.
- Get rid of the images that take a long time to load and that were not visible on-load. Theoretically could use something like Ajax to call those images when need be rather than using Jquery, which is what is currently in place.
Move some images to another host
I tried this out using a dev server and the outcome was in fact an increase in load time (8.42 seconds). This requires further experimenting on a server that is optimized for this purpose. It looks like resources start downloading earlier thanks to the additional server, but perhaps due to bandwidth are causing everything to download slower, therefore not helping in reducing the overall load time for a user with a 1.5 Mb connection. I believe that a second host would come in handy when you are optimizing for most users who would have a much higher speed connection.
Change image file types and reduce size
I changed many of the larger images from PNG-24 to JPG and cut down the size of the PNG’s that did not qualify to be changed for design reasons. This time, page load time went down to 3.8 seconds. That’s more like it!
Reduce number of images
Getting rid of unessential images resulted, as can be expected, a major drop in load time. It went down to 2.15 seconds.
To be continued…
Based on this information, it appears that it may be possible to cut down our home page load time by close to 8 seconds for a user on a 1.5 Mb connection. I will continue this blog post after we implement a solution and will show what the outcome is in terms of performance and conversion rates. My plan is to build a replica of our home page, optimize it for speed, then see how it performs against our current home page.