SSL has a significant number of required packet exchanges at startup, so latency for small objects is much larger; this is especially noticeable if there's a high round trip time between the client and server.
SSL blocks proxy caching.
The CA situation isn't great; especially if you're supporting older mobile clients, which basically never update their root certs.
Debugging is harder (and HTTP/2 already gets complaints about that)
This is only true for involuntary transparent proxying, which is also a huge source of reliability problems. After seeing how many times JavaScript is broken or images are degraded by "helpful" ISPs I'm quite happy to change the model to something which requires the client to opt-in to enable a proxy.
That's interesting (and I'll try to apply it where i'm running SSL), but what I'm more worried about is the very beginning of the connection. http://chimera.labs.oreilly.com/books/1230000000545/ch04.htm... SSL adds two extra round trips, which doubles the latency of a small request. This is really unfortunate when you're in a high latency environment already.
SSL has a significant number of required packet exchanges at startup, so latency for small objects is much larger; this is especially noticeable if there's a high round trip time between the client and server. SSL blocks proxy caching. The CA situation isn't great; especially if you're supporting older mobile clients, which basically never update their root certs. Debugging is harder (and HTTP/2 already gets complaints about that)