HTTPS trop lent : Google peut-il vraiment accélérer le chiffrement sans sacrifier la sécurité ?

Pourquoi Google investit-il dans l'accélération de HTTPS ?

L'objectif est clair : supprimer le frein principal à l'adoption massive du chiffrement. Pendant des années, les sites ont évité HTTPS en invoquant la latence supplémentaire lors du handshake SSL/TLS. Ce délai, bien réel, pesait sur les Core Web Vitals avant même que le concept n'existe.

Google travaille avec ses équipes Chrome sur SPDY (précurseur de HTTP/2) et False Start, une technique qui permet au client d'envoyer des données chiffrées avant la fin complète du handshake. Concrètement, on gagne une aller-retour réseau, soit plusieurs dizaines de millisecondes sur des connexions internationales.

Quelle différence entre SPDY et False Start ?

SPDY est un protocole de transport qui multiplex plusieurs requêtes sur une seule connexion TCP. Il compresse les headers, priorise les ressources critiques, et embarque HTTPS par défaut. False Start, lui, est une optimisation SSL pure : le client anticipe l'envoi de données applicatives pendant que le serveur finalise la négociation cryptographique.

Les deux approches se complètent. SPDY accélère le transfert global, False Start réduit la latence initiale. Pour un praticien SEO, la distinction technique importe peu : ce qui compte, c'est que HTTPS devient aussi rapide que HTTP dans des conditions normales.

Cette déclaration change-t-elle le calcul coût/bénéfice de HTTPS ?

Absolument. À l'époque de cette annonce, beaucoup de sites justifiaient leur refus de migrer vers HTTPS par l'impact performance. Google affirme ici que cet argument devient obsolète grâce aux optimisations protocolaires.

En pratique, un site correctement configuré avec HTTP/2 (successeur de SPDY) et TLS 1.3 (qui intègre nativement des mécanismes type False Start) peut même être plus rapide qu'en HTTP/1.1 non chiffré. Le multiplexage élimine la limite des 6 connexions parallèles par domaine.

• SPDY et HTTP/2 réduisent la latence globale par multiplexage et compression
• False Start coupe le temps de handshake SSL initial
• TLS 1.3 modernise ces optimisations avec 0-RTT sur les connexions répétées
• L'argument « HTTPS est lent » ne tient plus face à une configuration moderne
• Les sites en HTTP pur perdent l'avantage perf qu'ils pensaient avoir

Cette déclaration est-elle cohérente avec les observations terrain ?

Oui, mais avec un décalage temporel important. SPDY a été déprécié au profit de HTTP/2 dès 2015. False Start a été intégré dans TLS 1.3 sous une forme évoluée (0-RTT). Les navigateurs modernes appliquent ces optimisations automatiquement.

Sur le terrain, on observe que les sites HTTPS bien configurés (HTTP/2, TLS 1.3, certificats ECDSA, session resumption activée) ont des TTFB comparables voire inférieurs aux sites HTTP. Le problème, c'est que beaucoup de sites restent en TLS 1.2 avec des configs héritées des années 2010.

Quelles nuances faut-il apporter ?

Google ne précise pas que ces optimisations exigent une infrastructure moderne. Un serveur Apache 2.2 avec mod_ssl va toujours traîner la patte. Les gains de SPDY/HTTP/2 nécessitent un serveur compatible (nginx, Apache 2.4+, LiteSpeed), un CDN récent, et des certificats correctement dimensionnés.

Deuxième nuance : 0-RTT introduit des risques de replay attacks. Certains sites sensibles (banques, paiements) désactivent cette fonctionnalité. Google ne mentionne pas ce trade-off sécurité/performance. [À vérifier] dans quelle mesure Google applique lui-même 0-RTT sur ses propres services critiques.

Dans quels cas HTTPS reste-t-il réellement plus lent ?

Sur des connexions ultra-rapides locales (LAN, datacenter), le surcoût cryptographique reste mesurable en microsecondes. Mais personne n'optimise le SEO pour des utilisateurs en LAN. Pour le web public, ce cas ne compte pas.

Autre cas : les devices anciens avec CPU faibles peuvent souffrir du chiffrement AES si le hardware ne supporte pas AES-NI. Mais ces devices disparaissent progressivement. En 2020+, même les smartphones d'entrée de gamme ont une accélération matérielle du chiffrement.

Que faut-il faire concrètement pour bénéficier de ces optimisations ?

D'abord, migrer vers HTTP/2 ou HTTP/3. HTTP/2 est le successeur officiel de SPDY et bénéficie des mêmes avantages (multiplexage, compression headers). La plupart des CDN et serveurs web modernes l'activent par défaut sur HTTPS.

Ensuite, vérifier que votre serveur supporte TLS 1.3. Cette version intègre nativement des mécanismes type False Start via 0-RTT. Testez avec SSL Labs : si vous êtes encore en TLS 1.2 uniquement, vous laissez de la performance sur la table.

Quelles erreurs éviter lors de l'optimisation HTTPS ?

Ne pas multiplier les redirections HTTP → HTTPS inutiles. Chaque redirect ajoute un aller-retour réseau. Configurez HSTS pour forcer le navigateur à passer directement en HTTPS sans redirection initiale.

Éviter les certificats RSA 4096 bits si vous pouvez passer à ECDSA. Le handshake ECDSA est significativement plus rapide. Sur mobile 3G/4G, chaque milliseconde compte pour le LCP.

Comment vérifier que mon site exploite bien ces optimisations ?

Utilisez WebPageTest avec un profil mobile lent (3G). Regardez le « Connection View » : vous devez voir une seule connexion TCP multiplexée, pas 6 connexions parallèles comme en HTTP/1.1. Le handshake TLS ne doit pas dépasser 100-150ms sur une connexion internationale.

Vérifiez également dans les Chrome DevTools (onglet Security) que le protocole négocié est bien h2 ou h3, pas http/1.1. Si vous voyez http/1.1 sur HTTPS, votre serveur ou CDN est mal configuré.

• Activer HTTP/2 ou HTTP/3 sur votre serveur/CDN
• Passer à TLS 1.3 avec session resumption activée
• Préférer les certificats ECDSA aux RSA pour le handshake
• Configurer HSTS pour éviter les redirections HTTP initiales
• Tester régulièrement avec SSL Labs et WebPageTest
• Monitorer le TTFB HTTPS vs concurrence avec des outils RUM