Web Performance for ESPN – LoadStorm

It seems like weekly that we hear of some very high profile website performing poorly or going down completely. Are site outages reported somewhere centrally? If so, I haven’t found it. However, this one caught my eye because I’m a sports fan. Saturday night both ABC.com and ESPN.com were poster children for website outage.

Many people on Twitter were complaining and tweeting jokes about the performance of both sites.

ESPN Crashes on Saturday Night, As Does ABC.com is a quick summary on the outage as well.

However, searching the ABC website on terms like “downtime Saturday”, “outage”, “site down”, etc. only returned results for things like Pirates of the Caribbean or War of the Worlds. I guess I don’t blame them for not advertising their problems, but it does seem like good customer service to at post an explanation or apology.

How is it Performing Now

Knowing that ABC owns ESPN, and that both of their domains resolve to the same go.com, I decided to see how go.com was doing today in order to judge it’s performance health on a normal morning.

There are two tools that I like to use for analyzing a specific page’s performance – Yottaa.com and webpagetest.org. Both check the performance of one page. Yottaa allows you to compare one site’s homepage performance against another site and against many sites. In fact, it is monitoring & scoring the performance of 37,871 websites.

Running some analysis on go.com, it looks like the site is a poor performer anyway. The first graph above shows that ESPN is slower than 79% of most of the websites in existence. Hmmm…it looks like the Pareto Principal holds true once more. The so-called “World-wide Leader in Sports” is a bottom dweller when it comes to web performance.

One of the most important best practices for a web page to perform well is to have fewer HTTP requests. It’s simple math to understand that every round trip has overhead in moving the data through the network as well as the processing by client and by servers. ESPN’s home page has 84 assets being requested. It also has a total of 663 kilobytes of data to be transferred to the browser. The HTML document is 39 KB, and while that isn’t huge (I’ve seen some 100+ KB), it is bigger than most I work with. For example, the LoadStorm.com home page has 9 KB of HTML.

61 images comprising 370 KB is a bit heavy. 11 separate Javascript files for almost 200 KB is also more than I’m used to seeing. Combining some of those files would make sense from a performance standpoint. Webpagetest.org agrees with me and makes that very recommendation.

Now let’s analyze ABC.go.com. Maybe the parent company invests all of it’s performance engineering budget on its flagship website. Perhaps not. The Yottaa score is 47, so that is a slight improvement – it’s better than 22% of other sites. However, when you start to look at the other measurements, you notice that the ABC home page is much larger – over 1 MB! Wow, that’s a big page. Plus there are more requests and more overhead. 100 images! 23 domains? 20 Javascript files.

It would be safe to place a $10 wager with Lloyds of London that the web developers and designers at ABC are not placing a high priority on the performance of their home page. That’s not to say that they haven’t given it thought and tuned some aspect of the page. To their credit, they are using a CDN to deliver that massive load of static assets in a geographically advantageous method. They are also using persistent connections (keep alive), so that is a positive.

Here’s the bad news. They aren’t compressing their text. If they were to use compression (e.g. GZIP encoding) on all appropriate text assets, webpagetest.org says they could save 346.7 KB because the total 584.3 KB of text would result in 237.6 KB when compressed. What is even more puzzling is that they are compressing some HTML and Javascript, but only on about 40% of what could be optimized.

Another key area of improvement is leveraging browser caching of static assets, but it doesn’t appear as if the ABC web performance engineers have opted to use Expires headers to make many .png, jpg, and .js files cacheable. For more information on this performance technique, see High Performance Web Sites: Rule 3 – Add an Expires Header on the Yahoo Developer Network.

With such a enormous heap of images the ABC.go.com site is using, a web performance engineer would normally think about compressing those images. Again, webpagetest.org tells us that a potential savings of 291.3 KB is lost because the total 1,062.9 KB could be reduced to 771.7 KB. Another optimization opportunity!

Webpagetest.org’s analysis tells us that the ABC home page takes a full 16 seconds to load.

Summary – Pay Attention to Your Site’s Performance

Obviously, when these two websites went dark last Saturday, it was a blow to the company. Estimates of site outages such as these on heavy traffic destinations would probably show a cost of something in high six or low seven figures. That’s enough money to pay a good performance engineer to make the site more efficient and pay the web team to implement extra redundancy to avoid outage.

Web performance tuning pays off – even if your site never goes down like these did. Just being slow is bad. Improving your web application performance can directly impact your bottom line by 10% or more.

Additionally, it is a continuous process to keep your site or application running at the optimal level. To put it another way: Web performance tuning never ends.

Please don’t think that I’m trying to be hard on the web team at go.com. I’m really not. I am simply trying to emphasize the importance of web performance, and the need for performance testing on all aspects of a site. Especially a home page!

My recommendation to you is to go to Yottaa.com and/or Webpagetest.org and see how your key pages are responding. Compare yourself to your competitors. It’s vital because it translates to money. Be faster than your competition.