The First Step is Admitting You Have a Problem
Here at OpenSesame we love data just as much as the next startup – probably even more. We have your run-of-the-mill analytics tools, marketing automation scripts, remarketing scripts, scripts to monitor our other scripts… You get the picture.
At some point, our scripts got away from us. In early May we took a close look at site performance and were horrified to discover our pages were taking up to 10 seconds to load. There is a delicate line every tech company walks between using scripts to collect necessary site date, and hoarding scripts, services and sharing buttons to the detriment of the very business metrics you’re trying to monitor. We had fallen flat on our faces on the wrong side of that line. Our ever-increasing addiction to data and metrics had negatively impacted something that mattered even more – a fast, responsive customer service experience.
Why A Slow Site Hurts Your Business
We realized the impact of our feature overdose in the most awkward way possible – during one of our regular user testing meetings. In session after session, one page or another would sit, endlessly loading. If you ever want to feel true frustration, watch a recording of a user on your site being subjected to dial-up load times and site responsiveness. Our testers were generally pretty polite as they sat waiting to make their next click, but we suspected the average user was probably less patient. We realized that we were putting sales on the line and alienating potential customers. Something needed to be done, and fast.
My preliminary research on improving site speed led me to read this excellent slideshare deck by Jonathon Colman. Inside I discovered just how important high-speed sites are. Consider the following:
- Google uses speed to determine rankings for the top 1% of queries.
- Customers expect your site to load in 2 seconds.
- 40% of customers will abandon any site that takes longer than 3 seconds to load.
- For every 1 second of load time, conversion drops by 7%.
- For every 1 second of load time, user satisfaction drops by 16%.
So for those of you who had any doubt the answer is yes – having a slow site does hurt your business. With a new understanding of our big problem, and we set about attempting to fix it.
What We Did to Speed Up
Thankfully we found there was no shortage of low-hanging fruit for us to tackle. We started with…
Scripts, Scripts, Scripts
We systematically examined every piece of Javascript on the OpenSesame website. For each script, we decided whether we really needed the service it provided, and whether there were better ways to implement it. As much as asynchronous scripts are promised not to slow pages down, our testing showed very few page loads that weren’t slowed down by one script or another. It wasn’t the same one script every time. In fact, we had so many third party tools that a different one was the culprit behind each test.
Here are some some specific actions we took to weed out unnecessary scripts and help speed up the site:
- We removed social sharing buttons from product pages. This step alone shaved an average of half a second off load time. (If this sounds like social media suicide, you might want to read more on why removing social sharing buttons is worthwhile.)
- We picked just one analytics package to record site activity instead of loading three different tools with similar feature sets.
- We changed an on-page Javascript implementation of KissMetrics to a server side PHP implementation.
- We found an outdated synchronous script from a marketing automation provider that was consistently blocking the rest of the page load and removed it.
- Over time we had built up old Website Optimizer test scripts, AdWords conversion tags, remarketing tags and other one-off tags. We cleaned those up.
- We audited all of our own custom Javascript and found many scripts that were loading and interacting on pages where they didn’t need to.
Images and Sprites
We already had several sprites on OpenSesame, but after some investigation discovered they hadn’t been updated in awhile. Certain sprites had images in them that we didn’t use any more, but were still loading. Other sprites were loading on every page when they were only needed in certain specific instances. Cleaning up and optimizing our images into proper sprites both sped up browser processing and reduced page size.
Cache, Cache, Cache
We had been using a content delivery network, but we invested serious time in improving our integration.
First, we made the vast majority of the pages on the site cacheable by AJAXing in the user-specific data. Eventually we loaded the user-specific data in a script in the Head tag so that the user-specific request would begin sooner.
We increased the amount of time assets from our site were stored on the CDN and users’ browsers too. Previously our TTL for most assets was only 24 hours, but increasing that to a full 28 days meant returning visitors would see a big boost in performance. The downside of increasing TTLs is of course the risk that users will see a stale version of a page. To combat this we added a feature to flush content from the CDN as soon as it changed. We also made sure that the few images that we might need to update, like sprites, had low enough TTLs that the user would get the update in a reasonable amount of time.
Our CDN configuration includes a site shield which is a set of CDN proxy servers that the CDN edge servers around the world all point back to. By tracking flush requests and re-fetching pages that changed, we increased our cache hit rate while also making sure that users get the latest version of the pages.
Cleaning Up CSS and Javascript
As a young start-up, OpenSesame has made many design changes over the past few years. Some of these changes were sitewide while others applied to just one button. During each new iteration we accumulated bits of CSS that weren’t used any more, or used older, inefficient selectors. With modern browsers on fast computers this isn’t a big problem, but OpenSesame users (mainly in corporate environments) commonly browse the site with Internet Explorer 8, or – gasp! – IE 7. This, in conjunction with users’ older computers, mean clunky CSS is slows down page rendering – a seriously big problem. We updated our CSS to use clean selectors, and removed any lines we weren’t using. This resulted in 50% fewer lines of CSS for browsers to parse.
What Happened Next?
Phew, that was a lot of work. Did anything change? Yes! After making the changes described above, our average page load time in the US dropped to 2.5 second site-wide. That’s a 75% reduction in page load time across our entire site in just a matter of weeks. Certain high traffic pages, like our homepage and major product category pages, dropped all the way to sub one second average page load times.
Google Likes Speed
Let’s just jump straight to the data. Here are the charts from our Webmaster Tools account:
Both our pages crawled and KB downloaded per day increased about 300% from our normal range. Google only allots a certain amount of processing power per day, so if your server responds faster it can get way more done and get way more data from you every day. This means changes you make get into the index faster, and Googlebot can index deeper pages from your site.
Now you know what happened with Googlebot after we increased our speed, but how about the business-related, ‘real world’ results? Over the nine weeks of these site speed changes, OpenSesame’s organic traffic grew 30%. Other engagement metrics saw similarly impressive gains:
- Bounce rate sitewide dropped 19%.
- Pages/visit increased 18%.
- Average visit duration increased an amazing 26%!
User experience had clearly improved along with Google bot. Faster site speed made them much more likely to continue perusing the site, prolonging their experience with OpenSesame.
Dolla Dolla Bills
A more engaged audience is certainly a welcome change, but we ultimately determined the success of this project based on its impact on conversion and sales. We compared the data from the before and after, and here’s what we found:
- The raw number of transactions increased 30% from the previous period.
- Conversion rate improved by more than 20%.
Here’s What We’re Doing Next
We aren’t satisfied with 2.5 seconds. Our goal was to hit an average page load time of less than 2 seconds in the United States. We have already accomplished the 20% of changes that got us 80% of the way, but now comes the really hard work. Here are some of the next items on our performance optimization checklist. We think that successfully completing these tasks will knock out another second of page load time:
- Adding Parallel domains for static assets from a cookieless domain
- Refactoring all CSS using Compass/SASS (This is a major project, but is something that is long overdue to really and truly optimize our CSS for peak site performance.)
- Putting Javascript at the bottom of the document
- Pushing rendered pages into the CDN instead of using the shield cache (This will ensure even higher cache hit rates.)
There you have it. Optimizing our page load time sitewide positively impacted all kinds of metrics. We definitely aren’t done, though, and will continue to pursue a faster, more responsive customer experience. I’m sure we haven’t thought of everything. Is there
something your company did to improve site performance that we missed? Let us know in the comments.