Top Web Performance Land Mines—and How to Avoid Them

The holidays will be here before we know it, and many organizations are focusing a good deal of time and attention ensuring their websites and web applications can handle heavy traffic loads. Yet, in reality, there are only a few reasons why websites and applications go down under load. If organizations know up front what these top performance land mines are, they can avoid them by testing their websites the right way, before they go live.

In this article, we’ll explore web performance as a business issue. We’ll also look at the top performance land mines that organizations often encounter as they roll out and introduce new web pages and web applications to customers. Finally, we’ll examine how businesses can best avoid these land mines through a proper approach to testing, which mitigates land mines and prevents them from causing harm to organizations.

Web Performance as a Business Issue
Recent statistics and metrics are very explicit in revealing what a web performance problem or issue can mean to a company. Google found that by slowing its search results down by only four-tenths of a second, over time, this would dramatically reduce the number of site visitors or end-users viewing search results. If the time needed to produce search results went up to a half-second or more, the number of lost visitors would increase even further. In Google’s case, this would translate to a loss of end-users viewing ads. In this sense, four-tenths of a second would really affect not just the end-user experience but also the bottom line. Similarly, Amazon found that if its end-users experienced a one-second delay at some point in their experience, Amazon could lose up to $1.6 billion a year.

The Top Performance Land Mines
With so much at stake, it’s critical for organizations to ensure the fastest, most reliable applications under load. Implementing a load testing strategy that addresses these three common performance land mines is critical to ensuring peak load readiness.

1. Your website is bloated, and it’s time to lose a little “weight”
There is a linear relationship between page size and response time. Website owners add a variety of objects and features to their web pages and applications, including analytics, advertising, and customer feedback. The goal is to create the most feature-rich, satisfying end-user experiences possible. In fact, it’s estimated that the average website collects data from twenty-nine hosts before being delivered to an end-user.

But paradoxically, as the number of objects on a page grows and the size of the page increases, end-user satisfaction may be dwindling. Complex pages that have a great deal of content coming from a large number of locations can exert an even more negative impact on mobile users, who are at the mercy of mobile connections. All of this begs the question: Are there opportunities to “trend down” and reduce the number of objects and features on a page, thus reducing page download times? Ultimately, the answer depends on the following:

First, you need an ongoing monitoring and measuring strategy that collects data on individual hosts and tracks their performance alongside the health of the entire application. The “ongoing” part is key, since your site’s degree of complexity is apt to always be changing. You must be able to see the performance impact of adding, then taking away, various objects and features.

Second, you need a cross-discipline team (development, marketing, etc.) that is committed to making smart use of this information to promote a shared goal of delivering a great user experience to serve business objectives. Every single bit of content on your website should exist only for this reason.

In many instances, adding a page object, or increasing the number of hosts where content is pulled from, increases response times and does not serve business goals. The key is finding the balance. Understanding the performance impact under load of adding certain objects and features—from the true end-user perspective—is critical to making these calls, and load testing strategies must be centered on delivering this intelligence.

2. Third-party services are slowing you down
Similar to using external hosts, the addition of third-party services—social widgets like Facebook or Google+, map providers, or content delivery networks (CDNs)—can increase web page complexity, leaving organizations with blind spots that can result in performance degradations. Third-party services may add highly engaging capabilities like social media plug-ins, images, and video. But they also result in services being “added” to your website from beyond your own firewall, where their performance under both normal and peak loads is outside your direct control.

Many organizations conduct load testing by generating synthetic traffic loads from within their own data centers. This approach of load testing from within the firewall essentially omits third-party services from the load testing process. For many organizations—particularly those that are heavily reliant on external third-party services, like retailers—it is not uncommon for a sizeable majority of their web traffic to be delivered by external CDNs. CDNs may promise to speed up critical content delivery, but if they are not properly included in the load test, organizations may be totally unaware of how a slowed CDN under load is impacting the end-user experience.

For these reasons, load tests must be based on the true end-user experience—the only place where the complete, final end-user interaction can be accurately measured. In addition, as is the case with external hosts, load tests must enable performance comparisons “before” a third-party service is added, as well as “after.” Just because your own website or web application can handle a heavy traffic load, doesn’t mean your third-party service providers are as adept. Having this information arms you with the tools you need to consult with third-party service providers on SLAs and opportunities for performance optimization.

3. Load testing from within your datacenter does not account for browser nuances
As we’ve discussed above, load testing from within one’s own firewall is not sufficient to measure and understand the impact of third-party services. But it is also insufficient in addressing a huge performance-impacting variable: the browser. For these reasons, your load testing strategy cannot just rely on simulated traffic loads generated from inside the data center, or even load generated from the cloud. Instead, you must generate load from real browsers in order to understand how different browser technologies behave under load.

With this information, you can make the needed changes that support the best possible performance across the most popular browsers. For example, you can optimize perceived load time for a particular browser. This means arranging for page objects to load in a particular order (elements above the fold first), giving the appearance that a page has downloaded, even if all objects on the page (specifically, those below the fold) are not fully there yet.

Simulated traffic loads generated from the cloud can give you a good idea of how your own infrastructure, external hosts, and third-party services hold up under load. But you’ve got to couple this with a real browser view in order to address issues and find opportunities for browser performance optimization. Otherwise, your employees and customers may be the ones telling you that something isn’t right.

These three performance land mine categories—bloated web pages, third-party hot spots, and omission of the actual browser in the load testing process—tend to cause the majority of website performance issues under load. Often, these issues can cause your organization great harm without you even knowing they’re there. Waiting until you’re in production to uncover these issues is not the ideal approach; rather, fixing these problems early on in development makes much more sense. Load testing that is based in a true understanding of the end-user experience at the browser level, at all phases of the application lifecycle, will help you move application performance forward in the biggest way possible.