Improving speed of https pages

When it comes to secure sites, it’s not easy to achieve a fast loading page.

There are a few points that really help:

• Connections over HTTPS are more expensive compared to an uncompressed connection. So especially try to reduce the number of required connections. And assure keep-alive is active – even a very short time helps (it is used with HTTP1.1 automatically – usually. Test it to be sure).
• Connections over HTTPS are encrypted per user. Public caching infrastructure (like a companies proxy) is not able to buffer content closer to the user. Requests always go to the server.
• Even worse, browsers won’t save cached items to the hard disk. For security reasons, that makes sense. But on a modern website, most of the content is actually not required to be secure. But again, for security reasons, all the content must be transfered encrypted. But you can tell the (modern) browsers which of the transfered files may be cached on the hard disk with the Cache-Control: public Header. Decide which files actually don’t have confidential information and can be cached. In most cases this will be static files that are the same for all users. Deliver these with the Cache-Control: public header.
• Terminate HTTPS as close to the user as possible, preferably in a CDN. Although not possible for all request, at least some can be cached close to the user.
• If you’re required to support a large userbase of deprecated browsers (like in a corporate environment), prepare for a long frustrating research. It helps to use a HTTPS Traffic sniffer like Fiddler.
• Of course, a secure site also should fulfill the performance tuning basics.