Your users’ experience in terms of navigating your site should be reason enough for performance tuning a site. Users have many options when it comes to consuming content on the internet, and a slow performing website will frustrate them and send them to another site. A faster and more responsive website will keep them more engaged and focused on your content, rather than waiting for scripts and images to load.
Another reason is for Search Engine Optimization (SEO) since Google announced they are using page speed in their ranking algorithm. This means that faster performing sites may rank higher in search engine results. As developers and marketers look to optimize their sites, page speed should be among the top things they look into. Consider the following from an article by Pear Analytics:
- Zona research said in 1999 that you could lose up to 33% of your visitors if you page took more than 8 seconds to load.
- Akamai said in 2006 that you could lose up to 33% of your visitors if your page took more than 4 seconds to load on a broadband connection.
- Tests done at Amazon in 2007 revealed that for every 100ms increase in load time, sales would decrease 1%.
- Tests done at Google in 2006 revealed that going from 10 to 30 results per page increased load time by a mere 0.5 seconds, but resulted in a 20% drop in traffic
While I liked the visual look of my site in the past, performance wasn’t great. I also knew it wasn’t as SEO optimized as it could be. I knew that one of the largest penalties my site was seeing was coming from CSS import statements, the dynamically created CSS by the theme (it used a xxx=css parameter on the end of a query string to get the CSS on every page load), and the JQuery implementation. JQuery was the same as the CSS; it was being dynamically injected. The implications of this were that even with caching plugins installed my site wasn’t performing all that well. Lastly, I knew that I had a bunch of “junk” in my database… old options left over in the tables, as well as old tables not removed, from uninstalled plugins that didn’t clean themselves up properly. I may do a “How To” article as some point in the future, but for now I wanted to highlight what a difference choices in plugins, themes, and caching can make.
Based on the above I started disabling plugins and paired down to just the minimum I knew I needed, disabled caching so I had baselines for performance, and then went on a hunt for a new theme. I looked at the major frameworks, free/premium themes, and performance claims.
The theme I finally landed on using Standard Theme. The decision was hard, there are some good theme’s out there but this one comes highly recommended, has an active user forum, and the price (yes… I PAID for performance) was low enough I could justify the cost. After putting Standard Theme in place I realized that while quick out of the box, it didn’t have as many drag and drop in place type of options as I was used to on my last theme… in other words, I had tweaks to do directly in the code. Once those were in place I started running performance metrics. Below is a side by side comparison on the old site vs the new site.
Old Site Performance WITH caching
Standard Theme without caching
So it doesn’t immediately look as though the new theme is better, but keep in mind that the left image is the old theme with caching enabled and the right is the theme without caching or optimization. So what happened after I optimized images, styles, and enabled caching:
Standard Theme - cached, images optimized
GMetrix History
Great post, thanks for the read.