Page Speed and Business Metrics: The Relationship

Share this article

Your design team developed a great prototype for the upcoming iteration of your website’s homepage, and it’s all good according to the best practices of usability and design. It was approved by your testers, so you implemented the changes into your site… only to face inexplicably disappointing results.

How could this that happen when you did everything by the book?

There are three common design mistakes that can affect the loading efficiency of your pages, which will ultimately have a negative effect over the page views and any other business metric important for your website’s success.

Page Speed and Business Metrics: The Relationship

You are probably familiar with the idea that web application speed is directly associated with its effectiveness in achieving intended goals.

There are many proofs demonstrating the clear connection between the speed of a page and its performance indicators, such as the customer satisfaction, sales, cart size, bounce rate, page visits, and all other business metrics that come to your mind.

An in-house study at came out with the results that saw an up to 2% increase in conversions on the site for every single second of improvement on the load time. The accumulative growth of revenues went up to 1% for every 100 milliseconds of load time improvement.

.. an up to 2% increase in conversions on the site for every single
second of improvement on the load time

Just like the speed improvement flows through to positive effects on the site performance, delays result in penalties from e-commerce clients: the bounce rates increase, the number of page views decreases, the cart size drops and the conversion rate goes down.

When good practices become bad

So, how to these types of mistakes escalate?

The reasons are sneaky. Firstly, you need to understand how they are disguised by different design best practices, in order to realize why they occur in the first place. These mistakes are incredibly common, so the drop in performance shouldn’t be taken as an unbearable shame for the site owner.

These are three best practices that can have an undesired outcome in terms of site performance:

1) Feature banners/carousels occupying screen real estate

The practice of placing a feature banner or carousel with the intention of promoting and enhancing of sales is so established that many site developers take it for granted. Often website owners don’t put a lot of thought into the way feature banners are placed on the page.

How does this best practice become a worst practice?

The feature banner is typically the last element that loads on a website. The home page, for instance, features a filmstrip view that’s typical for many pages. You have to wait for the navigation elements to load for about five seconds, and then you’ll see a progress indicator in the feature area for five more seconds before the banner image appears.

The QVC typical site load

This loading sequence generally isn’t appreciated by users, which shouldn’t come as surprise to the website owners.

A user who has to wait for the page’s feature content to appear won’t spend more than 1% of their time on this site being visually engaged with that content; whereas a user who sees the feature content within a second after they open the page will spend nearly 20% of their time on the website within the feature area.

In plain language, one certain way for the visitors to miss out on the most important content is to render it last.

How do we solve it?

You can fix this issue with few straightforward enhancements to the website. First of all, you need to optimize the order of rendering objects on the page. It may seem silly to recommend such an obvious fix, but the number of sites that failed to pay attention to priorities is even more obvious.

Another thing you can do is to optimize the images that are featured. You don’t need images that consist more than 50% of the total payload of a typical page.

There is another basic technique many developers forget about: image compression. That simple performance trick will enable you to reduce the payload and still feature the images effectively.

Most websites fail to benefit from progressive image rendering, and the reason for that is the awful reputation progressive JPEGs got during the ’90s. This technique involves loading an image in low-resolution version before the increasing resolution reveals the full version. If this progressive rendering is properly implemented, it will introduce visual content for the visitor earlier.

2) Primary CTA (Call To Action) links/buttons are located at the bottom of the feature banner

The layout of a typical banner is predictable: an image in the background , header copy, text with description, and a CTA button.

This is a practice used by many websites, without understanding some of the unexpected effects it can have on performance.

How does this best practice become a worst practice?

Though there are feature banners that are interactive before being completely rendered, most don’t become interactive until the image is fully loaded. If the user isn’t sure whether they can click on the feature banner until the button renders, they’re unlikely to wait and see.

On the Costco home page, for example, the link to the online-only coupon offers is buried at the banner’s bottom, although it’s considerably important for online shoppers. The Costco home page takes 5 seconds to fully render, and the call-to-action button is last to become visible.

Costco’s call to action is the last element to load.

How do we solve it?

The solution isn’t much different from what we previously mentioned. Again simple optimization of the rendering order of the objects on the website would be a nice solution when accompanied with image optimization and progressive rendering of buttons.

If the call-to-action button is that important, the easiest solution would be to reposition it on the top of the banner. It doesn’t get any simpler than that!

3) Testing usability and design in an ivory tower

During usability testing, many web developers are guilty of this mistake. Developing prototypes and bringing testers into the lab to put the site through all stages is a proven recipe of overseeing obvious deficiencies. This leads to lack of necessary revisions and improvements to the prototype before implementing it into practice.

How does this best practice become a worst practice?

When you design and test prototypes and wireframes in the lab, you have insight of how the site functions in a perfect model of setting, which includes a preloaded browser cache, a fast connection, the latest browser and a speedy system.

A real site viewer is far from this setting, and you can expect for their computer to be at least five times slower than the system you’re using for testing.

On the other hand, the problem of third-party scripts that inhibit the page rendering can be experienced only when your site goes live. When these issues are neglected, the page can easily take up to 20 seconds to load for a real user. You don’t want that!

How do we solve it?

Every person who touches a page is responsible for its performance, no matter which stage of the process they covered. The performance will be lost when each separate team assumes that the mistake is someone else’s responsibility. The last person who works on the page is usually the one who gets blamed about the performance failure, which is completely unfair.

Every phase of the design, testing and development stages has to involve performance as one of the main factors to success. All teams have to see the pages from the aspect of real visitors.

One solution is to artificially choke the connection prior to the deployment, during the phases of designing and testing. This will give you insight of the points where things get delayed and the rendering order of the pages. After the deployment stage, WebPagetest can help when you combine it with real-user tools for monitoring.


The only way to have happy users is to fix all above-mentioned issues. It’s ridiculous to see how common those mistakes are when they have such simple solutions.

Take this example as an inspiration: on every 400 ms of improvement, the traffic at Yahoo! was increased by 9%.

Being a happy site owner means that you have to make your users happy; and that can only be done by fixing the problems.

Robert MorrisRobert Morris
View Author

Robert Morris is content manager at NinjaEssays. He provides consulting services to clients from various industries such as social networking and user experience.

Share this article
Read Next
Get the freshest news and resources for developers, designers and digital creators in your inbox each week