Image from LoozrBoy
In my last post, I talked about the benefits of going all SSL for a webapp. There were plenty of benefits, not the least of which was securing your users’ data. However, there still exists that one pesky drawback that prevents most of us from using SSL more often…performance.
There’s no denying that SSL has overhead. The handshaking that happens between a client and server requires 2 complete roundtrips to complete before HTTP can take over. For connections with a lot of latency, this can add up quickly. In the future, I’m sure we’ll see better performing security protocols, and the gap between secure and non-secure requests will be dramatically reduced. For now, we’re stuck with what’s available. So as developers, what can we do to reduce the impact all ssl webapps? Here are a few reminders:
Use Persistent Connections
Setting the Connection: keep-alive header will allow the browser to keep a connection open, bypassing the SSL handshaking for subsequent requests. Given that the handshake consists of 2 full roundtrips, anytime this can be skipped without comprising security is good.
Allow infrequently changing content to be cached locally by the client. Use cache control headers wisely.
If you’ve got a bunch of small icons on your site, consider combining them into a single image sprite. Obviously, reducing 10 calls for images down to a single call will have a nice performance boost. Not only are you avoiding the SSL handshake, but you only endure the network latency once.
The processing power required to decrypt responses from the server depends on the size of the data to decrypt. The less data, the less time and effort is needed to decrypt it. Plus, you don’t have to send as much data over the wire. Win Win.
Use CDNs or Caching Proxies for Static Content
Offload static payload to other servers so your application server doesn’t have to waste CPU cycles. Technically, this falls under the category of reducing the work my server has to do, rather than reducing the overall work that has to be done. But shoot, if those CDNs will help us out, then all the better. If your application server doesn’t have to mess around with those pesky static files, then your app will be quicker to respond.
Keep in mind that unless your user base is geographically diverse, a CDN is probably overkill. You’ll have to put up with long TTLs while the changes propagate, with no apparent gain. In this case, a caching proxy is probably a better fit.
Again, this isn’t anything new. Although we’re talking about performance tuning within the context of an all SSL site, these really are just general webapp tuning principles. The name of the game is reducing requests, reducing data, and utlimately, reducing time.