Undressing Red Dress Butique's Web Performance

Shark Tank is one of my favorite shows, it appeals to my inner entrepreneur. Recently ABC created a spin off show, Beyond the Tank, where they follow some of the companies after they make their pitch. To me this is more valuable to watch than the Shark Tank pitches because you see what it takes to run the real business. OK, well at least you get a made for TV taste of what it takes to run a TV show, but it allows you to see behind the normal walls.

Episode 2 follows Red Dress Boutique, a company Mark Cuban invested and has a very positive history and future. The owners want to create a new web site to replace their existing site. They have identified various issues holding them back based on customer feedback and administrative issues.

Red Dress Boutique Product Details Web Page Test Scorecard

Cuban on the other hand does not support a completely new web site, but instead stay focused on maintaining the legacy site. The owners decide to press forward with the new application, which is still in the works. So I thought I would do some analysis, similar to what I do for my clients. Today I am going to review various aspects affecting their performance using my favorite tool, WebPageTest. Maybe you can glean some knowledge from this evaluation and make your application better.

Red Dress Boutique Product Details Page

Overall the red Dress home page renders within 2 seconds, which is admirable, but they could achieve sub 500ms render times with some simple changes. The product detail pages seem to take much longer to load, in this WebPageTest run it took 13.5 seconds. At 10 seconds everyone has most likely given up and left. So there are many things Red Dress Boutique can do to speed up their site.

I am going to focus on the product page for two reasons, home pages tend to get more performance love and product pages are more critical to sales. So lets break down some things in the WebPageTest audit.

Speed Index - 10818

Speed index is a metric created by WebPageTest's creator, Patrick Meean. This is a way to measure the average time at which visible page parts are rendered. The goal is to be under 1000 or 1 second. A score of 10818 indicates the average page component took 10 seconds to render.

A review of the filmstrip view shows the page rendering. Since nothing on the page renders till 6 seconds the speed index has a hard time recovering.

What can Red Dress do to improve the page load time? Let's look at the waterfall to for more insights.

Time To First Byte

The initial request takes 1.3 seconds to return. To put this in perspective my SPA applications typically render completely in this much time over broadband. I often encounter slow time to first byte situations. They are typically created by a poorly optimized web server. This can typically be corrected in 2 ways, proper caching and optimizing database interactions.

Red Dress Boutique Product Details Page

When the server takes more than a few milliseconds to return the markup it means caching, like ASP.NET OutPut Caching is not enabled. Most server-side web platform offer some sort of caching mechanism.

When the web server can cache a result, be it markup or JSON, it means it does not need to run through the logic needed to render the result. Instead it calls the finished product from memory, which is more or less instant. When it does not have a cached instance the server much hit the disk for the file and more often than not execute a call to the database to get the data. Then it much render the data with the markup to get the finished markup to return to the client.

ASP.NET's Output Cache is pretty sophisticated because it allows you configure it by headers, parameters and for a controlled amount of time. Express, the popular NodeJS web server, offers a very simple caching mechanism. Unfortunately it cannot be configured. So check with the web platform you have for opportunities to cache your results.

In my experience Red Dress should be able to shave about a second from their load time by utilizing server-side caching.

Not Bundling & Minifying

It has been nearly a decade since Steve Souders' Yahoo team published their YSlow rules. The fewer HTTP requests a page needs to make the faster it typically renders. Unfortunately I might be the only developer that understands this rule because no one seems to utilize bundling and minification. This is where you combine individual CSS files together and JavaScript files together. Next you minimize them by removing white space. Not only are there fewer requests, but they overall data footprint is about half the size. The effect is faster load and render times.

When High Performance Web Sites was published bundling and minification was still sort of a dark art. Today we have the benefit of task runners like Grunt and Gulp to manage this important build step. Because modern task runners are free and easy to use there is no excuse for developers and devops teams to not bundle and minify their application's assets. My rule of thumb, a single CSS file and no more than 3 JavaScript files. And the only reason it is not a single JavaScript file is many sites need a 3rd party analytics script.

CSS in the Head, Script at the Bottom

Again another fundamental web development rule. You always want your CSS references in the document's HEAD. This is because the way the browser composes the page to render. When the CSS is referenced in the Body or at the end of the DOM the browser must back up and re-render everything. While this is not a problem, as far as I can tell, on Red Dress it is something to avoid.

Red Dress CSS Requests

However the majority of the 50 plus JavaScript references are in the document's HEAD. Again moving the script reference to the bottom will cause the page to render much faster. When the browser encounters a Script tag it stops everything and waits till the script is loaded and evaluated.

Red Dress CSS Requests

Remember the Red Dress product page takes over 6 seconds to start rendering, this can be directly correlated to their JavaScripts loading and being evaluated. In particular you can see it takes nearly 3 seconds to load the Amazon payments widget. I have not done enough research into how Amazon payments works, but there has to be a better way to implement Amazon payments.

Amazon Payment Widget request

Amazon Payment Widget request

Since there are no Ajax requests the Red Dress product page could start rendering in about 1.5 seconds (assuming the slow time to first byte has not been fixed).

Summary

Normally when I perform an audit for a client the report is 50-60 pages, but I don't want to get into that sort of detail on the Blog. These items are things I can pick up with a quick glance through the report. They are also what I call low hanging fruit, or things that are very easy to correct. I could easily product one of my 50+ page reports for the site and still have more to say. To be fair, I am very critical of my own applications.

The items I identified here, Output Caching, Bundling & Minification and proper script references could easily cut the 13.5 seconds needed to fully render a Red Dress Boutique product page to well under 3 seconds. These are typically things I can fix in ASP.NET sites in less than 2 hours and often a single hour. Red Dress is currently in PHP and uses the Magento e-commerce platform, both of which I have no tangible experience. But I am sure I could figure it out fairly quickly and you can too. I hate to keep pressing the same items here I have identified in the past, but it seems no one applies these valuable techniques.

So do the Red Dress Boutique owners need to build a new web site? Yes probably. Not because you could not make the site perform better within their current platform, but rather at their scale they need to own everything about their application. So I think I agree with the owners, but I also understand Mark Cuban's perspective. But $300,000 is way too much to spend on something like a basic e-commerce platform, so hopefully they will get some better advice before they waste a lot of money. I know because I have built many e-commerce sites, by myself and at the traffic levels they have.

We know performance affects sales. Customers do not like to wait to check out in a retail store and they have even less patience for slow web sites. E-commerce is particularly sensitive to performance issues, even when the site starts rendering at 2 seconds. Search engine optimization, bounce rates and company perceptions are all tied to perceived performance. I know if Red Dress applies some of the advice here they will be able to increase sales, customer satisfaction and lower their overhead. You can too, no matter your site or application's size.

Share This Article With Your Friends!