This Simple Trick Can Net You Faster Apps

I am often humbled by the depth of insight of those who toil in the trenches of the enterprise data center.

At our Agility conference back in August, my cohort and I gave a presentation on the State of Application Delivery. One of the interesting tidbits of data we offered was that, over the course of the past year, our iHealth data shows a steady and nearly even split of HTTP and HTTPS traffic. To give you an example, my data from October was derived from over 3 million (3,087,211 to be precise) virtual servers. Of those, roughly 32% were configured to support HTTP, and another 30% were supporting HTTPS.

Now, I’ve been looking at this data for more than a year, and it has stayed roughly the same with only slight variations up or down, but always within a couple percentage points of each other. But it wasn’t until a particularly astute customer spoke up that I understood why that split existed in the first place. After all, the rise of SSL Everywhere is well-documented. Our own data supports it, industry data supports it, and the move to support only TLS-enabled connections from browser via HTTP/2 is forcing it. But why, then, the split?

“Redirects,” the customer told me, giving me a look that seemed to question how I had not seen that before. Indeed. The Curse of Knowledge strikes again.

Once elucidated, it seems obvious. And of course, sites are going to encourage HTTPS but they aren’t going to sacrifice their web presence in doing so. That means gently herded millions of customers who have been taught to type in “http” to a more secure site. That’s what redirects do.

But they do more than just enable a more secure application experience. They add the application experience’s evil nemesis to the equation. That’s right.

[cue dramatic, spine-tingling music] Latency.

You see, a redirect tells the browser "you know, you should load this URI instead”. And then browser says, “okay, I’ll do that.” And then it has to basically start over. The existing TCP connection is invalid. A new one, requiring a repeat of the TCP handshake and then adding on the requirement to negotiate TLS or SSL requirements. All this adds up to more time. It negatively affects the application experience by dragging out the connection process. This is particularly noticeable on mobile connections, where compute and bandwidth is often constrained and leads to “hanging pages” and other horrific web app loading experiences.

Poor performance leads to abandonment. Abandonment leads to loss of revenue or conversions. And loss of either leads to, well, not a good place.

But I wouldn’t be offering commentary on a problem if I didn’t have a solution cause, Midwestern gal here.

Turns out you can eliminate redirects and their negative effect on the web application experience a couple of ways. First, and for those security minded folks the best, use HTTP Strict Transport Security (HSTS) headers instead. Once responses are received with HSTS headers, the browser is forced to subsequently behave in a manner compliant with the policy imparted. For example, it will automatically change any insecure (http) links to secure (https) links. That means http://mydomain.com/mystuff/ will automatically become https://mydomain.com/mystuff/.  Once a browser sees an HSTS header from a site, it will not use HTTP again. Even if you type it into the address bar and try to force it, it will refuse to do so, instead replacing it with HTTPS and making the request securely.

By specifying a really long “max-age”, say a year (that’s 31,536,000 seconds for one non-leap year), you eliminate the drag on performance from future redirects, and ensure a faster, more pleasant application experience for not only mobile users, but all users. It’s just more likely that mobile customers will actually notice a difference, given the differences between mobile and tethered connectivity.

Another option is to ensure that you aren’t relying on temporary redirects (HTTP 302). You want to make sure you’re at least using permanent redirects (HTTP 301) to force browsers to use the secure location for as long as possible in the future. Permanent redirects are cached locally, so they can be lost due to cache cleaning, but they’re better than temporary redirects.

Worried about the operational cost to update every web application server? Fear not, header insertion is (or should be) a basic capability of any application delivery solution you’re using for load balancing or web application security services. They can insert headers transparently into an HTTP response with a few lines of configuration or code, reducing the effort required to virtually (heh, pardon my pun) nothing. Neither the user not the application should notice anything except for an improvement in overall performance.

It’s a simple change, but one that can have a noticeable impact on the application experience (a.k.a. web performance).