Click here to Skip to main content
65,938 articles
CodeProject is changing. Read more.
Articles / web / HTML

7 Simple Steps to Make healthcare.gov Website Faster

5.00/5 (28 votes)
27 Oct 2013CPOL4 min read 35.6K  
Politics aside, here are 7 simple tweaks that could make heathcare.gov website instantly fast.

Introduction

Politics aside, here are 7 simple tweaks that could make healthcare.gov website run instantly fast.

Image 1

These tweaks are pretty preliminary and can be made quickly as they involve re-organizing static resources, making some config changes and minimal code changes. I used YSlow and PageSpeed to analyze the website and site’s registration page as a candidate for these suggestions. Take a look at page's source code before moving further. 

Step 1: Put JavaScript at the Bottom

"Scripts block parallel downloads."

As soon as a browser encounters script tag, it starts downloading file and blocks fetching other resources in queue (even blocks downloading resources hosted on other domains). The browser waits until the file is fully downloaded, parsed and executed before it moves to the next resource.

Image 2

There are 61 JavaScript files on registration page document head tag.

There are very few reasons to put script file in the head, may be a modernizr. In many cases, script files can be placed just before the body end tag.

Moving website's JS files to the very end of DOM tree makes page load faster by loading HTML and parallel downloadable resources.

Step 2: Make Fewer HTTP Requests

The fastest HTTP request is the one not made.”

For each HTTP request, the browser has to resolve the resource IP address, open a TCP connection to communicate with the server, wait for server response and close the connection after it completes the resource download. In case of cached resource (304) all these steps will take place except the download part. 

Image 3

The page makes 90 HTTP requests out of which there are 63 JavaScript files and 11 external style sheets.

Even if all those files are needed, they can potentially be bundled into 1 JS file and 1 CSS file reducing the number of HTTP requests to 2 vs. 74.

Step 3: Use a Content Delivery Network (CDN)

“Offload static resources to CDN” 

Using a good CDN to host and serve static resources has multiple benefits.

  • Offloads load from the server
  • A well distributed CDN can reduce latency, making static resources to fetch faster
  • Having a different CDN domain will enable parallel downloading that will improve page load performance.

There are 79 static components that are not on CDN.

Step 4: Minify HTML/CSS/JS Resources

“You browser doesn’t care about your comments and indentation.”

Minifying HTML/CSS/JS resources removes unnecessary whitespaces, tabs, line breaks, comments, etc. that may help reduce file download size thus improving page load times.

There are 82 HTML comments on this page that can be removed. Bootstrap styles and several JS files and inline JS can be minified to reduce size.

Step 5: Enable gzip Compression

“Gzip compression is the ultimate no-brainer.”

Enabling gzip on modern web servers is a very simple, typically a configuration setting. Gzip compression significantly reduces text based file size by using various text replacement techniques. Smaller HTTP resources will deliver improved page download times and bandwidth costs saving.

Most of the site’s static text resources can take advantage of Gzip.

Step 6: Serve Static Content from Cookie-free Domains

“Cookies are useless to serve static resources.”

Per Chrome dev tools 31.0?KB of cookies were sent with static resources for this page.

Serving static resources from cookie free sub-domains or even better cookies free CDN could reduce the unnecessary cookie network traffic.

Step 7: Reduce Number of CSS Selectors

“Less CSS rules, less load on browser”

To render a webpage, browser has to load, evaluate, and maintain every CSS rule to see if a rule is applicable to each of the HTML DOM elements. Reducing number of CSS selectors helps increase selector efficiency and reduce load on browser's memory and CPU cycles. This leads to better rendering performance.

A quick Dust-me run shows the page has over 5000 CSS selectors from 11 external style sheets.

  • 5455 – CSS selectors
  • 640 used CSS selectors
  • 4,815 unused CSS selectors

Depending on site’s code structure, this step could be little bit more involved.

There are many more tweaks, some of them more involved, like minimizing the HTML loading with script tags (page loads more than 1600 lines HTML of code blocks via script tags), better browser cache leveraging, serving optimized images, etc.

I hope you enjoyed learning a little bit about how a flagship website targeted to be used by millions of users fails to implement the very basic web development practices.

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)