HTTPS overhead compared to HTTP
Solution 1:
Price : There's heaps of CA's and resellers that provide well supported SSL certificates that are even affordable for your Mom's recipe website, let alone for business use. Besides a couple of free ones, as in beer, others are still cheaper then a pint. So no issue there.
Latency is increased by switching to HTTPS : the initial SSL handshake requires two extra roundtrips before the connection is established, compared to just the one roundtrip required to establish a TCP connection to the plain unencrypted HTTP port. So effectively it will take three times as long before the first data is received by your users.
Bandwidth Increase : The used bandwidth will increase slightly as the header size will increase by a number of bytes for protocol reasons and the effective payload will decrease a due to the framing overhead, and some ciphers will use padding as well. Assume a common MTU of 1500 bytes packet size ; the HTTPS protocol overhead will still leave at least 1400 bytes effective payload data size, therefore in max 6-7% increase in bandwidth.
CPU Load : The most computational expensive part is the public key exchange, after which a relatively efficient symmetric cypher is used. Most quotes suggest that modern commodity hardware does not require SSL offload cards to deal with that overhead.
In January this year (2010), Gmail switched to using HTTPS for everything by default. Previously it had been introduced as an option, but now all of our users use HTTPS to secure their email between their browsers and Google, all the time. In order to do this we had to deploy no additional machines and no special hardware. On our production frontend machines, SSL/TLS accounts for less than 1% of the CPU load, less than 10 KB of memory per connection and less than 2% of network overhead. Many people believe that SSL/TLS takes a lot of CPU time and we hope the preceding numbers (public for the first time) will help to dispel that.
If you stop reading now you only need to remember one thing: SSL/TLS is not computationally expensive any more. -- Adam Langley (Google)
A good resource is chapter 4 from High Performance Browser Networking by Ilya Grigorik
In conclusion, the overhead except for the latency in establishing a new connection, is negligible.
What is best, it depends on your needs... Using a CDN might become more expensive when you also need SSL support for instance.