Synthetic Monitoring
On Monday, May 25th Lululemon – a Vancouver-born, billion-dollar retail company – had a website outage that lasted just less than 24 hours. The company sees 17% of its revenue from online sales, and “just three days of an outage would likely have cost the company nearly $425,000 in lost sales.”
This isn’t the first-time Vancouver’s most loved yoga company saw an outage in the last year. Apica released its Top 100 Cyber Monday Index, showing which companies websites went down due to the holiday traffic. Lululemon was 36th on the list. It’s crucial for brands, especially those as large as Lululemon, to test and monitor their infrastructure when doing a big online brand/marketing push. Otherwise, the time and money spent are jeopardized.
Possible reasons for Lululemon website outage
It is being reported that Lululemon’s North American site crashed after a power failure and other problems at a server farm, but outages can happen for many reasons and retail brands that sell online need to be prepared for all of them.
Scaling and Stability are a Major Issue
Hosting infrastructure that isn’t built to scale can produce a very poor “stability” score, meaning there is a very substantial difference in the minimum and maximum load times. Even sites with optimized designs can crumble under demand if the infrastructure can’t scale properly.
Progressive Page Loading Is the Key to Speed
Developers can work with the system by loading the page’s basic functionalities as quickly as possible, and its auxiliary components afterwards. This way, even if the page takes eight seconds to load, the visitor thinks it only took two.
Recommendations for all e-commerce/online revenue generated companies
Reduce Reliance on Third-Party Scripts
Relying on third-party hosts for scripts on busy traffic days creates problems for site performance. For example, if your site is pulling a third-party hosted jQuery script that it shares with other sites, the increased traffic from all those other sites can slow down the third-party server and kill page load time.
Servers Closer to the Visitor are Faster
Just because you can access the site quickly in San Diego doesn’t mean a customer in New York is having the same experience. The physical distance between the visitor and server matters. Our test found, for example, that Avon’s website takes about 1.8 seconds just to initially respond, while HomeDepot.com takes only 300ms.
Faster Sites Structure Web Pages so Content Loads Before Scripts Run
Scripts can interfere with the web browser’s rendering process and significantly increase load times. For instance, when a browser encounters an image, it can start the download process and move on to the rest of the page; however, the browser has to stop and wait for a script to load before continuing. Therefore, it’s a best practice to put scripts at the end of the page so the DOM can finish (or come close to finishing) before it needs to pause.
For more tips about avoiding the damage of a website crash, read advice from Apica founder Sven Hammer in this article from MarketingTech.
To proactively test your own site, sign up for a trial today.