5 Reasons Why Your Web Performance May be Slow

The National Retail Federation (NRF) predicts that this year’s holiday sales will increase 4.1 percent to $586.1 billion. But here’s a wrinkle in the data that nobody really records: The companies that are making money are those that have fast, responsive websites. Companies with slow websites won’t be cashing in this season.

In fact, a Kissmetrics report on shopping cart abandonment found that 40 percent of people abandon a website that takes more than three seconds to load, and a less forgiving group of almost 50 percent of users expect a website to load in two seconds or less. This is just the latest in a slew of similar studies that have been produced since the dawn of the e-commerce era that conclude website performance has a direct correlation to revenue performance.

So what can you do to ensure your web pages load in two seconds or less? Avoid the following faux pas. These are the most common problems we see that slow e-commerce sites down to the point of depressing sales.

1. Unforeseen traffic spikes.

Heavy traffic is one of the most obvious reasons a website slows down, and most IT departments provision for this. But what if IT doesn’t know what’s coming, or when it’s coming? A surge of users to a site for a specific reason that IT doesn’t know about is a big risk that is easily preventable.

Historically, there’s always been a delineation between IT and marketing. To help bridge this gap, many organizations have hired a chief web officer (CWO), who oversees an organization’s web presence, including all Internet and intranet traffic. The CWO helps communicate marketing’s website performance needs to the IT department in enough time for them to prepare for any big promotional events.

As soon as marketing suspects that the website might receive heavier-than-normal traffic, IT and marketing should start working together on a schedule that will help avoid any last minute problems. The most important thing marketing should be communicating is how many users they are expecting and how long they expect core page load to take.

While not all situations are the same, don’t despair if your website goes down during a time when you expected to rake in huge online sales. There are a few things you can do to remedy the situation. A common strategy is to throw more bandwidth or more CPU at the site to resolve the issues — but it’ll cost you. Before doing this, organizations should conduct a quick cost-benefit analysis.

A business with an overloaded site will need to decide if the revenue they will bring in from their site staying up will break even with or surpass the amount they put into extra bandwidth or CPU.

2. Inadequate infrastructure and code base measurement and testing.

This problem can be avoided during the software development lifecycle by using tools that realistically measure your website’s performance from an external perspective, as well as having benchmarks associated with testing. During the software development lifecycle, the following factors affect your site’s speed:

• Where the infrastructure is located geographically. If you’re selling to the Asian market but planning to host your infrastructure in Amazon East, you’re going to experience latency delays right off the bat.
• Whether to cache or use CDNs. There is a subtle difference between the two, but front-end caching will help you avoid taxing your web servers, something that will cause your website to slow down. Front-end caching allows the cache version of the data to sit right in front of the web server and can be done relatively inexpensively with freeware technology. CDNs will come at a more significant cost, but will ensure localized delivery of content, saving you the latency that networks might provide.
• Image size. If the graphics on your site are not optimized and efficient, the page will take longer to download. You need a way to analyze graphical development throughout your site, find those that are suboptimal, and redeploy them.
• Whether you are using standalone or shared hosting environments. Standalone services allow for improved control and understanding of your environment and performance. A shared environment is like an apartment complex — you don’t know much about your neighbors or how their application/environment could be affecting your performance. While shared environments might be cheaper in the short-term, they could very well cost more over time.
• Whether you are using virtualized instances or traditional servers. Depending on the application requirements, virtualized instances could be more convenient for deployment and backup purposes. However, they could cause performance issues. As a result, evaluate the overhead associated with your application on a virtualized instance versus a non-virtualized environment.
• What type of database you chose. Whether it’s MySQL or Cassandra, SQL vs. NoSQL, we repeatedly see underutilized or misconfigured setups that cause performance significant issues. Additionally, we see organizations make interesting database solution selections that don’t take into consideration real benefits. Often a database is chosen based solely on the available in-house or outsourced expertise rather than the actual needs of the application.
• What type of OS you chose. Costs and technical expertise are the two most common drivers behind operating system architecture and design. But the success of the OS ultimately comes down to optimization. Fine-tuning can be performed according to best practices; however, running a load test against your environment will allow you to truly optimize it.
• If this site will be hosted in your own data center, co-located, or in a cloud hosting environment. Many organizations today begin by hosting their application in the cloud for rapid deployment, short term wins, and proof of concept to investors. As the application grows or the user base increases, organizations often will consider and migrate to their own data center or at least out of the cloud. There are appealing solutions today that allow for applications to continue to scale in an effort to mimic many popular cloud environments. Regardless of the environment, it’s imperative to learn your performance numbers and ensure that you meet or exceed performance metrics as you migrate.

3. Lack of maintenance.

Conducting incremental performance tests with each new update or change to your environment might sound like a lot of extra work for your IT department. But, there are several subtle efficiencies you can perform that solve multiple problems. Spriting, for example, combines multiple images or CSS files.

You can continue to tweak your environment by optimizing your code with each update of the site. Implementing cache management will regulate which and how many objects to keep in memory. Regular patch management maintenance can prevent memory leaks within the code base that cause slowness.

Most organizations find that their maintenance works best on a regular schedule, and is performed whether the environment has changed or not. Microsoft, for example, has Patch Tuesday. Every Tuesday is dedicated to making sure their apps are updated with the latest and greatest patches, as well as reviewing the code base to figure out how to best optimize as environments change.

4. Inability to scale.

A lot of organizations will develop sites that are not built to scale to the level they need, even though this is such a fundamental component of the software development lifecycle. We talk to a lot of web developers whose strategy is to simply buy more resources — hardware/software, bandwidth, CPU, memory, servers, etc. — than they need, and then assume that the extra will help them handle any heavy traffic that comes down the pike.

A more practical strategy (that will also save you money) is to take the time to develop an adaptive environment that you know can scale. Again, the sure-fire way to avoid this is to test and test often, so that you know every part of the stack can scale. And I mean to test everything — the front and back end web servers, databases, and application servers.

5. Quality measurements.

Some IT teams are afraid to shine a light on their own work for fear of exposing errors they might have made during the development process. This is a common internal, political problem for most organizations.

The bottom line is that if the website is slow, revenue is lost, so it needs to be confronted. If an IT team finds errors in its website after it goes live, they are often hesitant to draw attention to it right away, or even at all.

It’s important to say that I don’t believe internal IT teams can’t detect errors or are incapable of fixing them. All I’m saying is that our customers are often relieved to receive help from a third party that will objectively identify errors and are guaranteed to have the time and resources to fix them.

How much of this holiday season’s expected $586 billion will you be generating? Hopefully, a lot. Especially if you take the time now to pay attention to your website’s performance and do what it takes to make sure your customers get the best experience. Yes, the competition for customers will be fierce, but sticking to these five simple tips will keep your website up and running through January.