Removing export ciphersuites is fine, but it's not the case that TLS randomly picks a ciphersuite from the list and therefore removing some slow ones will speed things up.
Servers either use the client's most preferable ciphersuite or their own. Most servers use their own preference (SSLHonorCipherOrder in mod_ssl).
So removing 3DES doesn't do anything because none of the connections will be using it anyway as everyone prefers RC4 or AES. The only cases where it would be used is if the client supports almost nothing else. In that case, you're just breaking the client.
Far more important is that the text is recommending DHE-RSA-AES256-SHA as the most preferable ciphersuite. The benefit of AES-256 over AES-128 are almost nil in this case, because AES is not your weakest link. And the cost of DHE is substantial.
Disabling DHE removes forward security, but results in substantially faster handshake times. Ideally the text would discuss this tradeoff and how ECDHE gets you the best of both worlds to some extent.
Given that most sites are going to nullify forward secrecy with non-ephemeral SessionTicket keys in any case, RSA-AES128-SHA or RSA-RC4-SHA are reasonable choices for the casual site. Certainly better than just using HTTP.
The points about Keep-Alive is fine and caching are fine, but not specific to HTTPS.
Minimising domains and serving complete chains is correct, but just telling people not to miss intermediates is unhelpful: put your site into ssllabs.com and it'll tell you if you need to fix your certificate chain.
Yes, I am sorry if that seemed misleading to you. I didn't want to get into too much details for a small post like that. I will write more on the subject later, with more data to help my points.
SSL Labs is a great tool that I use regularly, it is very helpful :)
Servers either use the client's most preferable ciphersuite or their own. Most servers use their own preference (SSLHonorCipherOrder in mod_ssl).
So removing 3DES doesn't do anything because none of the connections will be using it anyway as everyone prefers RC4 or AES. The only cases where it would be used is if the client supports almost nothing else. In that case, you're just breaking the client.
Far more important is that the text is recommending DHE-RSA-AES256-SHA as the most preferable ciphersuite. The benefit of AES-256 over AES-128 are almost nil in this case, because AES is not your weakest link. And the cost of DHE is substantial.
Disabling DHE removes forward security, but results in substantially faster handshake times. Ideally the text would discuss this tradeoff and how ECDHE gets you the best of both worlds to some extent.
Given that most sites are going to nullify forward secrecy with non-ephemeral SessionTicket keys in any case, RSA-AES128-SHA or RSA-RC4-SHA are reasonable choices for the casual site. Certainly better than just using HTTP.
The points about Keep-Alive is fine and caching are fine, but not specific to HTTPS.
Minimising domains and serving complete chains is correct, but just telling people not to miss intermediates is unhelpful: put your site into ssllabs.com and it'll tell you if you need to fix your certificate chain.