Quality of implementation matters — no argument there — and you should do your due dilligence. That said, you need to test on your own hardware and with realistic traffic patterns to get an accurate picture of what works best for your specific workload. Don't trust outdated benchmarks, update your OpenSSL libraries, update your server, and run the tests.
Not necessarily. Once you enable and optimize your TLS stack you're also well on your way to deploying SPDY and HTTP/2. Unlike HTTP/1.1, both of these protocols require only a single connection to the server, which means fewer sockets, memory buffers, TLS handshakes, and so on. As a result, it may well be the case that you will be able to handle more users with fewer resources.
One possible route is to leverage TCP Fast Open, which would allow us to send the ClientHello within the TCP SYN packet — that would cut another RTT. In the meantime, both TLS 1.3 and QUIC are experimenting with "zero-RTT" handshake mechanisms. See QUIC crypto doc and this GDL episode for a general introduction to QUIC.
Mozilla maintains a wiki page with a recommended ciphersuite list and server configuration tips.
Both resumption and TLS False Start eliminate an extra roundtrip from the TLS handshake. However, resumption also allows you to skip the asymmetric handshake crypto by reusing parameters from a previous session — this saves CPU cycles. In other words, yes you need both.
Ensure you have a shared session cache to get a good cache hit rate on resumed sessions across different servers. Also, ensure you expire and rotate your sessions and session ticket keys in a secure manner, especially when forward secrecy is enabled.
You can get a free certificate for non-commercial use from multiple certificate providers. For commercial use, you can get a single domain certificate for ~$10, a multi-domain certificate for ~$30, and a wildcard for ~$100. If you need EV verification, then you will have to pay a bit extra. Use your favorite search engine to look for and evaluate the available options. The security and integrity of your visitors' data is worth every penny!
ECC certificates offer stronger security and smaller certificates - e.g. a 256-bit ECC key is equivalent to a 3072-bit RSA key. However, many clients do not support ECDSA, which means that the server should support both RSA and ECDSA, and some popular servers do not support dual certificate deployments. Consult the documentation of your server to see if RSA+ECDSA is a supported option.
CRIME is an attack against compression at the TLS layer. All modern user agents disable TLS compression, but it is still recommended that you disable TLS compression on your server. BREACH, on the other hand, is an attack against compression on top of TLS (e.g. HTTP compression) and must be mitigated both at the server and application levels - read more.
Checkout the HTTPS Everywhere presentation (slides) from Google I/O to learn the best practices and the steps to safely migrate your existing content to HTTPS.
It's running on nginx with resumption, OCSP stapling, 1400 byte TLS records, forward secrecy, NPN, and SPDY/3.1. See config files.