HTTPS and TLS speed: keeping the cost small

Why HTTPS is not optional

TLS, the technology behind HTTPS, keeps what travels between the browser and your server private and unaltered. MDN's security guidance says it should be used for all communication, and that browsers are moving towards requiring HTTPS by default. Many web features can only be used in a secure context. HTTP/3 always uses TLS, and the usual way to run HTTP/2 is over TLS too. See HTTP/2 and HTTP/3.

So the question is never whether to use HTTPS. It is how to keep its speed cost as small as possible. In Lighthouse 13.5 the audit Uses HTTPS is in the Best practices category with a weight of 5, among the heaviest there, and Redirects HTTP traffic to HTTPS has a weight of 1. A third check, Use a strong HSTS policy, is listed for information and does not count towards the score.

Where HTTPS adds time

Each new connection needs the secure handshake described in connection setup. With TLS 1.2 it takes two round trips. With TLS 1.3 it takes one, which web.dev puts at a third less connection setup time for HTTP/1 and HTTP/2. After the handshake, encrypting the traffic itself costs very little.

The extra time comes from these sources:

• An older TLS version. All major browsers began removing TLS 1.0 and 1.1 in early 2020. A server must offer TLS 1.2 or 1.3, and TLS 1.2 costs the extra round trip.
• Distance. Every round trip is longer for a visitor far from the server.
• A redirect from HTTP to HTTPS. A visitor who types the address without https:// first goes to the insecure address and is sent to the secure one, which is a whole extra request.
• Many hosts. Each host needs its own handshake.
• Mixed content. Files requested over plain HTTP from a secure page are blocked or flagged, and the page loses parts or shows warnings.
• A slow or overloaded server. The handshake needs processor time, and a busy server answers it late.

Step 1: use TLS 1.3 and modern protocols

Ask your host or CDN to confirm that TLS 1.3 is enabled. In the 2025 Web Almanac, 99% of the page requests answered by CDNs used TLS 1.3. For third-party requests the share was 96% on CDNs and 78% on servers outside a CDN, up from 68% a year earlier. The same lab tests found the median TLS negotiation for a page took 57 milliseconds on a CDN against 177 on an origin server on desktop, and 183 against 302 on mobile. These are controlled measurements and show direction, not a promise.

If you run the server yourself, use a configuration generator from a trusted source rather than writing cipher lists by hand. MDN recommends Mozilla's SSL Configuration Generator, which produces settings for common servers, based on Mozilla's TLS guidelines.

Step 2: redirect once, on the same host

Most sites keep listening on the insecure port so that an address typed without https:// still works. That is fine, with two rules from MDN:

1. Redirect to the same address on HTTPS, and nowhere else.
2. Do not redirect from HTTP on one host to HTTPS on a different host in one step. If the host must change, first go to HTTPS on the same host, then redirect on to the other. A jump straight across prevents HSTS from being set for the first host.

On Nginx this is:

server {
  listen 80;
  return 301 https://$host$request_uri;
}

On Apache, for one host:

<VirtualHost *:80>
  ServerName site.example.org
  Redirect permanent / https://site.example.org/
</VirtualHost>

Then remove the need for the redirect wherever you can. Every link on your site, every address in your sitemap, social profiles, ads and emails should use the final https address, with the host name you have chosen. See time to first byte for how redirects add to the wait.

Step 3: add HSTS, carefully

The Strict-Transport-Security header, HSTS, tells the browser to use HTTPS for your site even if someone types or follows an http address. The browser upgrades the request itself, without going to the server and being redirected. For returning visitors that removes the redirect round trip altogether.

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

• max-age is how long, in seconds, the browser remembers. MDN recommends at least six months, with two years suggested for the long term.
• includeSubDomains applies the rule to every subdomain. Test carefully, because it can lock out any subdomain that does not yet have HTTPS.
• preload lets your site join the browsers' built-in HSTS list. The list requires includeSubDomains and a max-age of at least one year. Sites on the list are upgraded before the browser has ever seen the header, so even a first visit skips the redirect.

Be careful. Once a browser has seen the header, the site must keep supporting HTTPS until the time expires. web.dev warns that setting too aggressive a policy without enough testing can break your website. Lighthouse's own HSTS check recommends a rollout in stages, starting with a low max-age. Raise it step by step while you check every host and every page.

Step 4: no mixed content

A secure page that asks for a script over plain HTTP has the script blocked. An image over plain HTTP loads with a warning and a degraded page. MDN's advice is to check that every resource is requested over HTTPS before you deploy. If a site has many old insecure addresses in its content, the upgrade-insecure-requests directive of the Content Security Policy tells browsers to treat them as HTTPS. Searching your content for http:// addresses, in posts, theme settings and plugin options, finds most of the rest.

Step 5: bring the handshake closer

The handshake is a series of round trips, so its cost depends on the distance. A CDN ends the visitor's secure connection on a server nearby. See what a CDN does. On your own server, choose hosting in the region where most of your visitors are, as the hosting guide explains.

HTTP/3 helps further. It builds on TLS 1.3, so a new connection takes one round trip and a returning visitor can resume with none, according to web.dev.

Keep the certificate valid

A browser requires a valid certificate from the server before it will make a secure connection. An expired or mismatched certificate does not just slow the page: visitors see a full-screen warning and most leave. Renew automatically if your host or certificate provider allows it, and watch the expiry date if not. Uptime monitoring that checks the certificate is worth having. A certificate also has to cover every host name you use, including www and the bare domain.

How to measure it

• DevTools. Click a request in the Network panel and open Timing. The Initial connection phase includes the TCP handshake and the TLS negotiation together.
• curl. It can split the two:

curl -o /dev/null -s -w 'tcp %{time_connect}s  tls done %{time_appconnect}s\n' https://example.com/

The TLS handshake is the difference between the second and the first number. Run it several times and from more than one place.

Check your own page

Run the free audit and check that the page passes Uses HTTPS and Redirects HTTP traffic to HTTPS, and look at whether Document request latency reports a redirect. Then type your address with http:// and with and without www, and count how many redirects happen before the final page. The answer should be one at most.

Sources

• Transport Layer Security (TLS) configuration on MDN: redirection rules, HSTS and mixed content.
• Strict-Transport-Security and TLS on MDN.
• Content delivery networks (CDNs) and Optimize Time to First Byte on web.dev: TLS 1.3 handshakes and HSTS.
• CDN chapter, Web Almanac 2025: TLS 1.3 adoption and negotiation times.