Every study shows that if it takes too long, people give up and leave the page. Back in 2006 a person shopping online expected a page load in 4 seconds or less. That decreased to 2 seconds in 2009. Nowadays it is below one second. According to Google, latency greater than 300ms is perceivable by users.
I started this blog 4 years ago, and since the beginning I have been monitoring its traffic with WordPress’ plugins. It reached a steady audience 3-4 months after its launch, and overtime I saw its audience changes from EDA-only to software-heavy, cruising after 15 months. The main factor for visits is obviously whether the posts bring any value to readers (subjective criteria), as well as how easy they are to find in search engines (objective criteria). Only recently I wondered whether page speed was a factor.
First thing first: I started using Google analytics for accumulating measurements. It gave me a great insight about the visitors –where they are located, how they got to the site, how long they spend on it, etc. However page load data were disappointing, because fairly inaccurate.
So I started to use a few on-line tools to test and analyze the speed. I found that pingdom and webpagetest were great for the detailed waterfalls they provide, breaking down the page load time into its several components –DNS lookup, connection to server, data sending, etc.
One great feature of webpagetest is that it reports load page time at the first view and repeat view. “First view” assumes that no browser caching is enabled, which is the worst-case first-time visitor. “Repeat view” leverages browser caching for returning visitors. Obviously repeat view can be significantly faster that first view.
The waterfall analysis was striking. Although I had a fairly large variance, due in part to the fact that my blog is shared hosted, I was surprised to see that some of my posts took up to 20 seconds to fully load! Also in some cases I spend over 4 seconds doing multiple DNS lookups. Not surprisingly, my PageInsights and YSlow grades were pretty poor.
First thing first: I had to use good practices for speed. This means:
- Optimize images with proper compression
- Gzip the data sent by the server
- Avoid URL redirects and DNS lookups
- Leverage browsing caching
To optimize images, I used Yahoo’s Smush.it, which does an excellent job at compressing images without loosing visual quality. Also it is readily available via WordPress’ plugin WP Smush.it, which makes it configuring and using it a no-brainer.
DNS lookup optimization
Considering that I spent up to 4 seconds doing DNS lookup of my own site, I looked at:
- Avoid URL indirections
- Use a better DNS service
When I started my blog, I added two redirection rules in my .htaccess file, so that the address
ocoudert.com/blog was mapped to
http://ocoudert.com/blog/, itself redirected to
http://www.ocoudert.com/blog/. That way all the entry points to the site ends up on the same unique address. This was to make sure that search engines would see these three URLs as referring to the same content. Unfortunately that meant extra DNS lookup, which turned out to be pretty costly in terms of page load time.
Eventually I focused on the second aspect. I moved from using my web hosting’s default DNS servers to using CloudFlare’s. CloudFlare is a CDN and DNS service. You can signup for free and re-assign your domain name to their DNS servers. CloudFlare is not the only company providing DNS servers for free, but it was certainly extremely simple to do, and the impact was impressive: the overall DNS lookup time to
ocoudert.com dropped to below 300ms.
For page optimization and caching, I tried the two best speed optimizer WordPress plugins: WP Super Cache and W3 Total Cache (respectively referred to as WPSC and W3TC in the sequel). Both feature page rewriting (minifying, compression) and server-side page caching (deliver a cached static page instead of dynamically generated content). They also feature CDN (Content Delivery Network) setup.
WPSC is incredibly simple to setup. Make sure you:
- Use the most aggressive caching method (i.e., mod_rewrite)
- Enable compression
- Enable preload (instead of waiting for a first visit to trigger caching, a static page is built in advance).
WP Super Cache or W3 Total Cache?
If you want all the bells and whistles, you want to go with W3TC. Especially if you have a dedicated server and enough traffic, W3TC will do more for you. Make sure you understand the impact of the many options –e.g., caching database and object requests on a shared hosting site will likely slow down the server. W3TC requires a more complex and lengthy setup, and you will need more time to experiment and find the best configuration.
If you have a simple shared-hosting site like me, WPSC will do the job just as well for a setup that takes no more than a minute.
Keep in mind that W3TC does get your Google/Yahoo page grade higher than what you can get with WPSC, which might help your page search rank. As shown below, my front page got a 66/76 PageSpeed grade with SC, and 92/93 with W3TC, which is considerably higher. I however experimented with both WPSC and W3TC for one month each, and I didn’t see any significant ranking difference.
I went from un-optimized, dynamic content, to:
- Mostly static, compressed pages
- Better DNS servers for the domain
- Browser caching properly enabled
First-visit maximum page load went from 20 seconds to under 4 seconds. I didn’t see any visible page rank change. I saw a small uptick in traffic, but it may be unrelated to the site speedup –I’ll see in a few weeks whether it subsists. At least I know that visitors to the site have now a better experience.
Tags: social network