If I was setting up a server, and had the SSL certificate(s), why wouldn\'t I use HTTPS for the entire site instead of just for purchases/logins? I would think it would make
For high latency links the initial TLS handshake requires additional round trips to validate the certificate chain (including sending any intermediate certificates), agree on cipher suites and establish a session. Once a session is established subsequent requests may utilize session caching to reduce the number of round trips but even in this best case there is still more round trips than a normal HTTP connection requires. Even if encryption operations were free round trips are not and can be quite noticable over slower network links especially if the site does not leverage http pipelining. For broadband users within a well connected segment of the network this is not an issue. If you do business internationally requring https can easily cause noticable delays.
There are additional considerations such as server maintenance of session state requiring potentially significantly more memory and of course data encryption operations. Any small sites practically need not worry about either given server capability vs cost of todays hardware. Any large site would easily be able to afford CPU /w AES offload or add-on cards to provide similar functionality.
All of these issues are becoming more and more of a non-issue as time marches on and the capabilities of hardware and the network improve. In most cases I doubt there is any tangable difference today.
There may be operational considerations such as administrative restrictions on https traffic (think intermediate content filters..et al) possibly some corporate or governmental regulations. Some corporate environment require data decryption at the perimeter to prevent information leakage ... interference with hotspot and similiar web based access systems not capable of injecting messages in https transactions. At the end of the day in my view reasons for not going https by default are likely to be quite small.
I was told that on one project at our company, they found that the bandwidth taken up by SSL messages was significantly more than for plain messages. I believe someone told me it was an astounding 12 times as much data. I have not verified this myself and it sounds very high, but if there is some sort of header added to each page and most pages have a small amount of content, that may not be so far out.
That said, the hassle of going back and forth between http and https and keeping track of which pages are which seems like too much effort to me. I only once tried to build a site that mixed them and we ended up abandoning the plan when we got tripped up by complex things like pop-up windows created by Javascript getting the wrong protocol attached to them and that sort of thing. We ended up just making the whole site https as less trouble. I guess in simple cases where you just have a login screen and a payment screen that need to be protected and they're simple pages, it wouldn't be a big deal to mix-and-match.
I wouldn't worry much about the burden on the client to decrypt. Normally the client is going to be spending a lot more time waiting for data to come over the wire than it takes to process it. Until users routinely have gigabit/sec internet connections, client processing power is probably pretty irrelevant. The CPU power requried by the server to encrypt pages is a different issue. There might well be issues of it not being able to keep up with hundreds or thousands of users.
The biggest reason, beyond system load, is that it breaks name-based virtual hosting. With SSL, it's one site - one IP address. This is pretty expensive, as well as harder to administer.
windows Server 2012 with IIS 8.0 now offers SNI which is Server Name Indication which allows multiple SSL Web Applications in IIS to be hosted on one IP Address.
https requires the server to encrypt and decrypt client requests and responses. The performance impact will add up if the server is serving lots of clients. That's why most current implementations of https is limited to password authentication only. But with increasing computing power this may change, after all Gmail is using SSL for the entire site.
One other small point (maybe someone can verify), If a user types data into a form item such as a text box and then for some reason refreshes the page or the server crashes out for a second, the data the user entered is lost using HTTPS but is preserved using HTTP.
Note: I'm not sure if this is browser specific but it certainly happens with my Firefox browser.