Speed vs. security: Four ways that security solutions can cause performance problems (and what you can do about it)

Security-related performance problems can happen in a few key areas — some of which you have control over, and some of which you don’t. While each of these areas by itself may not amount to much, the cumulative performance penalty can be significant. And while you may not be able to make performance-improving changes to your (or your visitors’) security features, this makes a compelling argument for why you need to optimize all the other areas that are within your control.

Here are four key ways that security measures can hurt page load:


Transport Layer Security (TLS) — and its predecessor, Secure Sockets Layer (SSL) — are protocols for encrypting information over the Internet. You know you’re on a site that uses TLS/SSL when you see “https” as the URL prefix.

HTTPS requires an initial “handshake” to create a connection between the browser and the server, and this handshake can be be very slow. This diagram (courtesy of IBM) gives a good idea of how the SSL handshake works:

SSL handshake

The problem

It takes at least four TCP roundtrips just to open a single SSL connection between the client and the server — and this doesn’t happen until after the initial TCP connection has been set up. The amount of data transferred as part of the handshake isn’t huge (under 5 kB typically), but for very small requests this can be quite a bit of overhead.

Important to know: The SSL handshake is actually even more process intensive than the actual data encryption that happens over the connection after the handshake is successfully complete.

How to know if this problem affects you

No one can give you a meaningful answer to this question without some information about the nature of your web site, hardware, software, and network configuration.

There are a couple of ways to look into this problem for your own site:

1. Profile the performance of your web server. There are several tools out there (such as JMeter and Visual Studio) to compare the performance of an HTTP vs HTTPS server.

2. Run WebPagetests of key secure pages on your site. Look at the purple bars on the waterfall chart that indicate SSL negotiation. You don’t want to see:

  • too many purple bars
  • long purple bars
  • purple bars associated with non-essential page resources

Here are a couple of examples showing how you don’t want your waterfalls to look:

SSL: bad waterfall 1

SSL: bad waterfall 2

Solution 1: Fewer handshakes.

Re-use TCP connections. Take extra care when it comes to HTTP keep-alives, in order to create longer-lasting SSL connections.

Solution 2: Offload SSL processing to another device.

You can mitigate the performance concern by offloading the SSL processing to another device, such as a dedicated load balancer or firewall. There is also dedicated hardware for handling SSL, which not only unburdens your servers from dealing with it, but also speeds up the SSL handshakes and encryption, overall.

Solution 3: Make sure you’re not using SSL content on pages that don’t need it.

Some third-party tags, particularly those for website monitoring products (i.e., Alertsite and Verisign), are secure by default, so they add SSL load to every page they appear on — even pages that are otherwise non-secure. Here’s how this looks on a waterfall:

SSL bad waterfall 3


Using unnecessarily secure tags is a simple enough mistake to make. Site devs will include the default tag in page templates, so that it’s automatically used on every page of a site, even the non-SSL pages. There are non-SSL versions of these tags. Ideally, devs should use the SSL version on secure pages, and the non-SSL version on the rest of their pages.

2. Security products (e.g., firewalls, IDS/Intrusion Detection Systems, IPS/Intrusion Protection Systems, WAF/Web App Firewalls)

Security products track traffic behaviour at a granular level in order to prevent attacks. They can be used either offline or inline. Products that function offline obviously don’t affect performance, but inline products — also known as “bumps in the wire” — look inside pages in realtime, watching at a much deeper level than load balancers/ADCs.

The problem

It’s difficult to quantify the exact performance penalty caused by security products, but because they’re performing deep packet inspection, we know that they incur extra latency at the packet level.

Solution 1: Ask your security product vendor for details.

Talk to your vendor about the performance impact of their products, and ask them for benchmark tests.

Solution 2: Perform your own A/B tests on your security products.

To test performance impact for yourself, you could set up split tests with the products turned on and off.

3. Browser extensions

As internet users become more savvy about security and privacy, there’s a growing market for plugins that add security support at the browser level. (Here are some industry-recommended plugins for Chrome, Firefox, Internet Explorer, and Safari.) Some of these addons govern your passwords or block ads, which are pretty innocuous from a performance perspective. Others, however, can cause a noticeably performance hit.

The problem

This entire post was inspired by my experience with installing HTTPS Everywhere, an extension for Firefox and Chrome that automatically identifies when you’re visiting a site that supports HTTPS and then serves you a secure version of the page, following the protocol described above in the section on TLS/SSL. After I installed HTTPS Everywhere, I perceived a noticeable slowdown in many pages I visit regularly — most of which don’t really need to be secure, in my opinion.

Some might disagree with this. Google’s motto — “Secure the world” — is a great goal, but right now, given the fact that the average page still takes 8 seconds to load, I can’t rationalize the additional performance hit created by universal HTTPS.

Browser extensions can have other performance implications, ranging from reportedly slower load times due to redirects (KB SSL Enforcer) to preventing pages from working properly (NotScripts and NoScript).

The solution

As a site owner, you have no control over what your users are doing at the browser level. You should, however, have the foresight to anticipate what they’re doing. I recommend that site owners test drive leading security extensions and measure their performance impact from the perspective of a real user

4. Desktop antivirus software

Antivirus software scans incoming files to identify and eliminate computer viruses and other malware such as adware, spyware, trojan horses, etc. It does this by analyzing all files coming through your browser. Like firewalls and security products, antivirus software operates in realtime, meaning that files are paused for inspection before being permitted to download.

The problem

As with security hardware, it’s hard to quantify the performance impact of antivirus software, but a certain penalty is inevitable, depending on the software and on the composition of the page/resource being rendered in the browser.

A few years ago there was an issue with some antivirus software breaking a fundamental performance best practice called compression. This practice involves using gzip to compress content so there are fewer bytes to send. Fewer bytes equal faster pages. The antivirus software ripped out the gzip header in the requests that would have indicated to the site that the browser could compress content. As a result, sites wouldn’t compress content, even if the browser supported compression. So sites kept sending uncompressed content to the browsers. (Steve Souders wrote about this issue here and here.)

The solution

As with browser extensions, you have no control over potential problems caused by AV software if you’re a site owner. But that doesn’t mean you shouldn’t arm yourself with the knowledge that problems are occurring.

One way to do this is by examining your server logs – where you can see if a browser that you know can compress (pretty much any modern browser) showed up without the Accept-Encoding header that would’ve indicated that it supports compression. This will at least tell you if you may have a problem.


In case it needs to be stated, I am emphatically not advocating that people sacrifice security for the sake of speed. That would be ridiculous. Security is an increasingly critical issue, and site owners and internet users need to protect themselves online. The question is: how to protect yourself while reducing the performance penalty caused by your security measures.

While there are some areas, outlined above, in which site owners can improve performance without compromising security, in other areas we have to accept certain performance hits. The only solution then is to focus our efforts on optimizing performance elsewhere.

Related posts: