Healthcare.gov failing again?! Is There a Web Perf Doctor in the House?
We’re at the end of the busiest online shopping weekend of the year, Black Friday to Cyber Monday. All eyes are on the major ecommerce websites as they drop their prices and handle millions of users and over $1 billion in sales per day. So it’s a surprise that the site with the biggest problem handling additional users wasn’t a retail giant, but Healthcare.gov.
Out of respect, we tried to avoid stirring the pot on this hot-button topic, but as Web Performance experts and tax payers, we need to highlight the site’s continued issues and offer solutions to get the site (and Affordable Care) back on track.
We have been monitoring the Healthcare.gov website for a couple of weeks and even after major improvements were made upon yesterday’s re-launch, the website is still failing and more can be done to improve its performance.
Diagnosing the Issues
First, let’s start with some data to understand the issues. All of the charts shown are median values, based off of about 60k measurements between 11/6/2013 to 12/2/2013
- Backbone measurements refers to measurement capture from key datacenters in US, which remove the last mile noise.
- Last Mile measurements were taken from consumer homes, accessing the internet through consumer ISPs (DSL, Cable, and Fiber)
Homepage Performance
The homepage is where all insurance seekers go first, so we used it as a starting point to measure the site’s performance. We compared the loading of the homepage against two major ecommerce sites, Apple.com and Amazon.com. Below is the data comparing the 3 sites from Backbone as well as an additional chart showing Healthcare.gov from Last Mile.
Fortunately, loading the homepage is pretty stable and fast, in line with Amazon and Apple. The median from our Backbone nodes was 2.3 seconds and 2.7s from our Last Mile nodes.
- They made a great change in the homepage by removing that very heavy background image and saved about 300kb! Good job!
Signing Up
We then assessed the performance of the sign up process by emulating a user signing up for healthcare in Indiana in the following four steps:
- Load the homepage
- Click on the Apply button
- Select Indiana
- Enter some Information (without pressing submit)
As you can see from the Availability chart at the bottom, the performance of step 4 (Enter Information) was terrible. Below are some of the errors pages our agents captured:
Looking at the performance by Hour of Day, it appears that the site undergoes maintenance every day from about 9/10 PM ET to 6 AM ET.
Logging in
Lastly, we looked at the Login Process by emulating a user logging in with the following four steps:
- Load the homepage
- Click on the Login button
- Enter Credentials, Logged in User
- Logout
You can see that the system maintenance impacts these charts as well.
There is Room for More Improvement:
While teams have been hard at work correcting the site’s performance issues, there is much more room for improvement, especially when it comes to front-end optimization. Making these changes, or asking your CDN provider (Akamai) to do it for you, will make the site faster and save some tax payer money.
Here are our suggestions:
– Turn on Compression / Gzip on all text based assets (Css, JS, HTML) or ask Akamai to do it for you. You will improve performance and save some money.
• Login page: https://www.healthcare.gov/marketplace/global/en_US/registration & Sign Up Page Step1 for example https://www.healthcare.gov/marketplace/global/en_US/registration#signUpStepOne
• example: https://www.healthcare.gov/marketplace/global/en_US/js/jquery.dataTables.js which is over 400Kb.
==> You could save about 1.1 Mb!
– Enhance your browser caching or ask Akamai to do it, make sure you have an expiry header. There is no need to request a file 20 times! You will improve performance and save some money.
– Reduce number of JavaScript and CSS files. 70 Javascripts and 11 CSS files in a page is way too many.
– Reduce third party tags!! I would love to know why a healthcare site needs all these third party measurement tools – which have a large overlap in functionality. We’re dealing with a healthcare site, are all of these third party tags even HIPAA compliant?
I am scratching my hairless head – after working at DoubleClick and dealing with the privacy issues of tags on medical websites and the headaches it gave us, I am wondering, is it normal now? Is this a non-issue now after all the millions of dollars the government made us waste in hearings and lawsuits? Maybe DoubleClick should get its money back!
Here is a non-exhaustive list of 3rd party tags we recorded. Some of the tags are there to improve or track performance, but I wonder why Twitter, Google, Facebook need to be there? These companies have my name, address, my friends, what I talk about – and now they also have my visits to government’s Healthcare site. I wonder how they will use this new information?
I totally understand that this is not easy. Even large ecommerce sites had their fair share of growing pains – Amazon.com used to go down a few years ago. I am sure hundreds of good folks are working on the stability and performance every day and I salute you.
But if you guys do not buckle up and quickly this is going to be a huge lost opportunity for our country. We sent people to the moon! We invented the Internet! We can build a web site that can handle a few thousand people? And if you cannot, then reach out to the folks at Etsy, HomeDepot, Walmart, Sears, Amazon, Grainger, Priceline… they can share with you one or two things about scalability.
Also if you have some money left from that budget, can you please head to Amazon and buy the following books:
- High Performance Web Sites: Essential Knowledge for Front-End Engineers
- Even Faster Web Sites: Performance Best Practices for Web Developers
- High Performance Browser Networking
Mehdi – Catchpoint