Load Speed Matters: Where To Start Trimming The Fat
How fast a webpage downloads and displays in a user’s browser has always been important for online stores, primarily because faster loading pages convert better than slow pages. One of the easiest ways to increase sales is to radically slim down category and product pages to make shopping faster and easier. But in recent times, […]
How fast a webpage downloads and displays in a user’s browser has always been important for online stores, primarily because faster loading pages convert better than slow pages. One of the easiest ways to increase sales is to radically slim down category and product pages to make shopping faster and easier.
But in recent times, load speed has become more important than ever because site performance now affects SEO. How fast your pages load now potentially affect your store’s rankings in Google’s organic results.
Slow loading sites often provide a bad user experience, and if it’s bad enough, Google could tag your domain as a low quality site.
Load Speed Back In The Dial-Up Days
I’ve always been a little obsessed with load speed, probably because we started selling online back in the dial-up days, when the Web was really, really slow! Back then, the limiting factor on page size was low-bandwidth Internet connections.
In 1998, I used Yahoo! Store’s online store builder over 28.8K dial-up that was easily 50 times slower than the connection I’m using to write this article today. We retailers were painfully aware of how slow a webpage could load as we waited for all the thumbnails and product images and other files to download and display on the screen.
Even in 2011, load speed directly affects your store’s ability to convert browsers into buyers. And while adding social media plug-ins, video, and pimping out your store looks great, piling code on top of code may result in unintended negative consequences.
Slowing your site’s load speed can shoot your sales in the head.
The Law Of Unintended Consequences
Last month’s column covered managing wild swings in revenue and how I diagnose a problem store. This month we get to see our plan in action.
Here’s a real world example of trouble-shooting a store in jeopardy! Recently, I got an email followed by a phone call from yet another store owner whose sales are way off. Had to let all her employees go. She’ll have to close the business if sales don’t improve very, very quickly.
I know how that feels. In the Pre-dot com days, we were losing $1000 a day at one point. I volunteered an hour or more and dug in. We looked at her site and dove into her stats.
I took the history of the site to see if anything clicked. It’s a seasonal business and sales are down a little in July, but last year, the MAY DAY update really did a number on them.
This graph shows daily revenue over an 18 month period.
The owner commissioned a redesign and as the graph shows revenue (and both traffic and conversions) have been off ever since. People say, “Correlation does not imply causation,” but I get antsy when I see traffic and sales tank that soon after a redesign. There are multiple issues, so let’s dig in.
Usually, I walk through the process I discussed in last month’s column, but sometimes when sales fall off like this, there might be an easy answer. Now, I was looking for “parking brakes” to undo — simple fixes that result in faster loading sites which usually result in more sales.
Just How Fat & Slow Is My Site?
Just curious, I wondered how fast the homepage loaded, so I ran it through tools.pingdom.com. This is a free tool which downloads a webpage, tells you how long it takes, and gives you all kinds of stats about files and download speeds.
When you use it, remember to scroll to the bottom to find that gray box with all the totals in it. The huge list of files can be confusing for retailers or other folks who don’t see these files every day!
You want to look at two things: TOTAL LOADING TIME in seconds and TOTAL OBJECTS which shows the number and combined file size of the HTML, images, scripts, and other files that make up a webpage.
And The Survey Says…
The tool said the homepage was both fat and slow. Total file size was 1.5MB which is pretty fat. Load time was 12 seconds. Ouch! That’s really, really slow.
Google says a fast webpage is one that loads in 1.5 seconds or less, and that 20% of pages on the Web are that fast or faster! So, 12 seconds to load a single page is slower than ~95% of the other pages on the Web.
The background image alone (line 5) took 2.75 seconds to download. I doublechecked it by testing the image itself. What really stuck out in the report was weird lag on a lot of images — see the yellow in the image below.
This graph is a screenshot from the tools.pingdom.com report on a test page calling the secure version of the images.
Here is a screen shot of what the time bar means:
The CSS file calls 19 template elements on the secure server. The only valid reason to do that I can think of is to recycle images for a faster cart and checkout — which is smart. In this case though, her cart was the old design and used very few of the new elements.
Cage Match: Two Pages Enter. One Page Leaves…
To test the lag, I made two sample pages — one calling secure versions of the images and one calling regular versions of the images. I compared the load speed of the two at various times during the day.
The added lag of secure encryption resulted in a delay of an additional two seconds for every single entry page on her website. And has done this for the past 10 months.
The graph below is a screenshot from the tools.pingdom.com report on a test page calling the regular version of the images (which is not secure and therefore faster).
It also shows the 75K background image, which we decided to pull.
We decided to stop and fix it immediately.
Although the designer was adamant that there’s no lag on images with a secure server, the graphs and dramatic decrease in download time with regular images showed otherwise.
Once the client emailed her designer specific instructions, it took the designer less than 5 minutes to implement these changes.
Removing the background image and changing the path from the secure server to the regular server dropped the homepage load time from 12 seconds down to 4.5 seconds.
Look…You don’t know what your designer doesn’t know. Or what their employees don’t know. You have to pay attention because it’s your business on the line any time someone makes changes to your online store.
The funny thing is that radical change came from one thing: just looking at the homepage and load speed.
To be fair, the site also has some merchandising and SEO issues, but after a couple more hours on the phone, I think the owner has a handle on them and is in a position to get things back to the good old days with a little work.
- Login to your analytics.
- Run a report to list your top 20 entry pages by revenue for the past year.
- Go to tools.pingdom.com and run the first page.
- Sort the files by file size.
- Look at each file on each page and make sure each file is necessary.
- If necessary, make sure the file is optimized.
- If not necessary, remove it from the page.
- Repeat for the next 19 pages.
In a month, run them again to see how well you optimized them. Compare the post-tweak bounce rate on these pages to the month before you optimized them. Now do the next 20 pages. Rinse and repeat.
Next time, unless Google does something insane this month, I plan to detail a process you can use to improve the load speed of your online store by doing the following:
Setting a baseline to establish where you are now by:
- Establishing acceptable ranges for load times and file sizes
- Optimizing various types of files
- Tweaking your HTML to take advantage how browsers work
- Creating an optimization work flow for new pages
- Regularly measuring results
Keep your hand on your wallet and your eyes on your stats!
Signing off from somewhere in sleepy Mississippi where it’s 101 degrees with no breeze and 90% humidity…
Opinions expressed in this article are those of the guest author and not necessarily Search Engine Land. Staff authors are listed here.