Sorry. I should be more clear. The initiation of an HTTPS session is expensive because it consumes a large chunk of CPU for a real-world-measurable chunk of t

Sorry. I should be more clear. The initiation of an HTTPS session is expensive because it consumes a large chunk of CPU for a real-world-measurable chunk of time, all at once, in most libraries. Everything beyond that point you're dealing with <use algorithm of choice> over <max of 32kb> of data. It does indeed consume CPU. It does indeed consume perhaps 8x MORE memory than a typical http connection - but the memory side here is completely dominated by the fact that we're trying to cache multiple gigabytes of data. You can serve HTTP faster than you can serve HTTPS with less CPU - this is objective fact. But if we're talking about CPU utilization? I can't speak to whether this argument has traction right now, for large connections, relative to the claimed 'non-problem' position of several companies who serve small sessions dominated by that connection time, but as time passes it's going to be even less coherent a position than it is right now.