A (quick) performance review of healthcare.gov

Introduction

Which ecommerce website received the most hits on Oct 1? If your answer was amazon.com, you would be wrong. It was the newly launched healthcare.gov – as per these statistics.  At least on launch day, it overtook amazon.com as the number one ecommerce site.

Too many visitors on day 1 ? That’s a good type of problem to have. So – how exactly did healthcare.gov hold up to the onslaught?

Here’s a detailed review from websiteoptimization – but if you want an executive summary, it is included below.

The three biggest offenders (Front End Code)

1. healthcare.gov used too many requests to external resources (for images , scripts, css etc.) all of which could have been included internally, or cached on a Content Delivery Network (CDN). They were not cached causing extraneous http requests every single time a new visitor arrived.
2. Overuse of javascript : As javascript libraries have exploded, so has their size. Healthcare.gov used 12 libraries in all – sizing up to 166 K (compressed) – which is a fair chunk to load, especially on a low bandwidth connection.
3. Image compression – This is one of those things that always falls on the backburner – after all, getting users registered correctly is far more important than compressing images. healthcare.gov used uncompressed images – size 250K total. Again, not a small size for a lot of internet users. If compressed, this could be brought down to 150 K.

Not just healthcare.gov’s problem

These three culprits are not unique to healthcare.gov. Almost every major site today shows these same symptoms in different proportions. As Mark explains in this post, these 3 are part of the ‘top 5’ performance culprits in a majority of websites today. 

NOTE that this list does not include performance issues on the backend (data tier, persistence tier, business tier or even the MVC layer). These are just things that could be done better between the web server and the web client (browser).

The Backend

All those failed registrations are far more problematic than slow page responses – and hint at serious backend code issues. Only time will tell – but I am sure the backend team has been asked to bring in their sleeping bags.

Summary

I wasn’t there to witness all the horror stories (ironically, I was troubleshooting performance issues in a web application). However, none of these items on the list above (front end issues) is super-bad (most sites today operate with uncompressed images and large javascript libraries) – and the site did somehow manage to get through the first week.  My guess is that once they figure out their bottleneck (s ) on their backend tiers, users will have a smoother registration experience.