Let’s take a look at Covered California. Go to that page, and click Start Here, go to Preview Plans and watch the network activity:
I must point out that Covered California is not alone. Every exchange I looked at had some interesting choices that might be OK on someone’s vanity site, but make you go *sigh*. But, Covered CA actually seems to be the most responsive as I write this, so that’s what I will look at.
We have:
- 28 requests
- 1.3 MB on the wire
- Nine, yes, nine
404s - Images, CSS, JavaScript, all being served from the same server
7.5 seconds for that is not bad.
That’s just to get to the form.
These are the low hanging fruit, the obvious optimizations.
If the front end exhibits such oversights, I suspect the backend is not that much better.
I then felt adventurous and filled some sensible values, just to see what options exist in California.
That took a while.
This time, a screenshot from Firefox’s Developer Tools instead of Firebug:
That is 71 requests and 3,821KB.
After that, you get to adjust a few more things, and then ask for a list of plans available to you.
And that really takes a while.
122 requests, 5,312KB, and 1,025 seconds later, we are rewarded by a display that shows me 3 plans at a time.
Now, what took so long? Well, I am not sure how typical this is (and I only made a handful of requests), but a lot of time was spent waiting and connecting.
The worst offender seems to be the getIndividualPlans which returns a JSON response. It took about 130 seconds. The returned list contained 30 plan choices. Thirty.
What would cause the process of gathering information about those 30 plans to take two minutes? Keep in mind, the information is not dynamic. The prices are not changing. The list of plans is not changing. You are just selecting a different subset in response to different parameters.
Looking at the returned data structure, I can make guesses about what is causing the bottlenecks, but I am not going to go into that much speculation.
However, one should ponder what happens when a visitor enters sensitive and private information on this web site, and ferrets on the other end connect to various 3-letter federal agencies to check and verify the information, in real time.
With some of these web sites dumping stack traces every chance they get, doesn’t that make you wonder?
Sure, glitches can happen any time. But, making sure your web app does not reveal a stack trace to random visitors is the first thing you take care of, not the last.
I like the idea of a central marketplace where all pertinent information about available plans and their prices are publicly available. President Obama referred to shopping on Amazon.com. All I know is, if I search for something on Amazon.com, I immediately get a full list of everything that is available along with the prices. Right there, right in front of me. Not one at a time. Not three at a time.
Thoughts?
Update
I just saw Less than 1 per cent of Web visitors are signing up for Obamacare on some state health exchange websites:
Caldwell couldn’t say how many of the 5.7 million website hits were from unique Californians. But assuming 712,500 online visitors saw eight different Web pages each, the sign-up rate was 0.58 per cent.
That depends on what Ms. Caldwell meant by a “hit”.
The commonly accepted definition of hit is “… a request to a web server for a file, like a web page, image, JavaScript, or Cascading Style Sheet.”
Even a 304 is a hit. I am not sure if they are counting all the 404s. But, let’s be conservative and assume that each page view generates about 50 hits on average and say each visitor does view eight pages.
Then, what we really have are about 15,000 (being generous here) visitors to Covered California. Not millions.
‘7,700 consumers began their application process yesterday. … 4,143 applications are pending,’ she added. ‘We received 23,269 calls yesterday to our service center.’
That means about 50% of the visitors started applications. According to California Health Care Foundation, there are 7.1 million uninsured people in California. That means approximately 0.11% of them began their application process yesterday.