The importance of page speed in eCommerce as well as the web in general is a rising trend. Studies have shown that long page loads cause higher bounce rate and lower conversion, the modern web is a place of great impatience and as such fast loading pages is a real virtue which can help any company to sell online, there is a great infographic with lots of stats over on kissmetrics showing the sharp affect page speed can have on pretty much every website metric. Although the importance of page speed for usability should not be underestimated, page speed has been seen to be of more importance recently due to it’s effect on search engine rankings, with Google adding page speed as a signal for rankings, the basic idea being that slower sites will affectively be penalised in search engine rankings.
Finding Your Bottlenecks
Your first port of call when looking into optimising page speed on your site should be Google Analytics, if you have not set up or used Google Analytics yet, have a look at my previous introduction to Google Analytics post. In Analytics in the ‘Content’ section of reports you will find the ‘Site Speed’ reports, here you can see the performance of your site relative to load times, either as an overview or by page. Generally speaking a page load time of less than two seconds is seen as being good, in many cases there will need to be a trade off between page speed and features / cost however generally you want pages to load as fast as is possible.
The Google Analytics reports can be used to easily see how the site is performing generally, which can show how responsive your server and application architecture is, as well as on a page by page basis which will allow you to find any pages on your site which are performing below par and therefore may have specific implementation issues.
The most important pages to target for optimisation are those on which visitors will commonly land, this will generally include your home page, statistics for which pages are most landed on can easily be found in the ‘Landing Pages’ report under the ‘Site Content’ reports also in the ‘Content’ section. Additionally focus should be out on your checkout process to ensure that any affect on dropout is minimised.
Armed with your troublesome URLs now you can look into the issues affecting particular pages and how to fix them. There are many tools available for checking a page for problems related to load times, here are links to a few common ones:
- Google Page Speed
- WebPageTest.org
- YSlow
- Pingdom
- MobiTest - For mobile
These tools all have similar features and using more than one solution to check correlation of results is always a good idea. Commonly page speed tools will have a type of waterfall diagram showing asset lags and loads over the entire page request, as well as direct checks for certain settings and capabilities with accompanying suggestions for common issues.
Remember that if you are implementing responsive design either as a truly fluid layout or with a simpler break-point methodology, it is important to test and optimise your site speed for all devices. Mobile phones and other portable devices will generally have much slower connections than static ones such as desktops, making optimisation in many cases even more important for mobile.
Common Speed Issues And Fixes
Too many concurrent requests Every asset of a webpage is requested by the client browser as a separate request, this includes your actual document (such as .html, .php, aspx), stylesheets, external JavaScript files, and images. Browsers are limited in how many requests they can make to the same domain at the same time, this means that an abundance of assets as well as a single domain from which to load them from can lead to these requests blocking each other in a big way, greatly increasing the overall loading time of the page. A common solution is to use a content distribution network (CDN) such as Amazon Web Services to serve your content from multiple domains (or to make sub-domains to emulate the behaviour), hence getting around the limit. Reducing the number of images which require loading is a great way of reducing the number of request a page needs, this is commonly done by combining images into what are called ‘Sprites’ and then positioning these sprites using CSS, have a look at the CSS tricks article on sprites for a good introduction.
Caching: There are many ways to cache at the various levels of a website or web applications, from language dependant caching (such as opcode caching in PHP), to caching of assets at the client end, to caching of html produced by a dynamic site. The principle is always the same, save time by making repeatable tasks store their results in order to make them much quicker the second time round or not required at all. Make sure to look into setting caching rules on your chosen web server as well as reducing the number of times functions / scripts with predictable or static results are returned in your code are run.
Compression: Most modern browsers and web servers are capable of compressing data to send and decompress at each end fo the server-client relationship, this results in lower bandwidth requirements however can increase the CPU loads, therefore giving a trade off. In most cases setting up simple compression with your web server such as gzip will give the advantage of lower bandwidth requirements without causing to much extra load.
Third party code: There are lots of companies associated with eCommerce and social which may provide code for you to place either site-wide or on particular pages such as post checkout, often these snippets will be html / JavaScript. In my experience these code snippets are often horrible, this is because they tend to use external requests to the third party, which can lag, a lot, and will normally not be cached at their end. Where possible choose efficient solutions for common page elements such as social sharing tools and avoid as much third party html / JavaScript as possible. Another common solution for troublesome JavaScript is to load the code on document ready (when the DOM is fully loaded), rather than including it in your mark-up directly.
Code Efficiency: If your website is JavaScript heavy then this may need to be optimised, likewise if your server-side code has bottlenecks, these will show when using the website. Database heavy sites may benefit from database optimisation, such as schema changes and indexing of commonly queried columns. Try and avoid using frameworks and libraries which are bloated or that you do not understand well.
File Reduction: A no brainer this one, smaller files will lead to smaller page load times. The two most common options here are to minify your CSS and JavaScript removing white space and readability (using a tool like the YUI Compressor) and to reduce the size of your images by removing unnecessary data from them with tools such as smush.it.
Conclusion
There are many, many reasons why a webpage can be slow to load including many which may not be apparent to beginner developers. Spending a little time optimising can lead to big long term payoff’s in competitiveness. If your website’s pages are slow to load, ignoring the problem could lead to detrimental affects on your rankings and therefore traffic as well as your website performance in terms of converting customers, the time is now to get your site up to speed.
