HTTPS : l’impact sur les temps de chargement

Ce n’est un secret pour personne : les sites en HTTPS sont a priori plus gourmands en ressources que les sites HTTP et la complexité introduite dans la communication entre le serveur et le navigateur peut impacter les temps de chargement. Les questions qui se posent alors sont : à quel niveau les ralentissements se font-ils ? Dans quelle mesure ? Et quelles sont les solutions pour éviter ces ralentissements ?

À quel niveau ?

C’est vrai qu’il y a quelques années, le processus de chiffrement était consommateur de CPU, mais les processeurs d’aujourd’hui peuvent le gérer assez facilement.

« TLS/TLS accounts for less than 1% of the CPU load, less than 10KB of memory per connection and less than 2% of network overhead. »
— Migration de GMail en 2010 – Adam Langley (Google)

« We have found that modern software-based TLS implementations running on commodity CPUs are fast enough to handle heavy HTTPS traffic. »
— Doug Beaver (Facebook)

L’impact sur le serveur semble donc limité.

De plus, bien souvent, la terminaison TLS se fait sur des équipements dédiés (load-balancers par exemple) et qui peuvent posséder des CPU dédiés pour cette tâche (ASIC).

Même si au niveau du serveur, les impacts sont limités, l’ajout de la couche de chiffrement complexifie la communication avec vos visiteurs.

Le chiffrement TLS a de quoi ralentir le chargement de la page web.

Dans quelle mesure ?

Nous avons réalisé quelques simulations depuis l’outil WebPageTest. Nous avons testé un même site mobile, dans les conditions suivantes : connexion 3G, depuis Paris, via le navigateur Chrome et avec une émulation sur Nexus 5.

Dans ce test, nous pouvons constater l’impact du TLS sur le Start Render (+24%) et sur le Speed Index (+19%). C’est loin d’être neutre !
Bien évidemment, le nombre de requêtes reste le même et l’évolution du poids de la page peut elle s’expliquer par un changement de contenu (tel que les pubs) et le poids des certificats.

Quelles solutions ?

1. HTTP/2

L’arrivée de HTTP/2 résout certains des problèmes de performance liés au protocole HTTP 1.1 :

• compression des headers des requêtes et des réponses,
• multiplexage des requêtes au serveur,
• Server Push,
• protocole binaire.

Les waterfalls sont ainsi bien moins longs – ou comme dirait Stéphane, notre CEO : “Adieu le waterfall, bonjour le wall !”.

En ce qui concerne HTTPS, le point important de HTTP/2 est qu’il ne fait plus 6 connexions par domaines mais une seule : il n’y a donc plus besoin de créer de multiples connexions TLS qui prennent un temps considérable !

2. Le Front-end Optimization (ou FEO)

Si HTTP/2 réduit le nombre de connexions et peut ainsi faire gagner un temps précieux, ce gain reste limité.
Reprenons l’exemple ci-dessus. Voici les résultats lorsqu’on applique HTTP/2 :

L’impact de HTTP/2 ici est très limité, voire inexistant. En effet, HTTP/2 n’est pas toujours plus performant.
Nous évoquions justement l’écart qu’il peut y avoir entre les promesses de HTTP/2 et la réalité dans cette interview au JDN.

En revanche si on couple HTTP/2 à du Front-End Optimization (FEO), le résultat devient nettement plus intéressant :

Le Start Render est réduit de moitié, le Speed Index de 32%, le nombre de requêtes diminue de 45% et enfin le poids de la page descend de 36% : des gains non négligeables en termes d’expérience utilisateur.

Pour vous aider à mieux percevoir ces gains, voici les représentations des différents chargements :

3. L’”Unsharding”

Comme son nom l’indique, l’”unsharding” est l’inverse du sharding, qui consiste à multiplier artificiellement le nombre de domaines pour multiplier le nombre de connexions en parallèle en HTTP/1.1.

L’”unsharding” consiste donc en la réécriture des URL en utilisant le domaine de la page. Cela permet de minimiser le nombre de résolutions DNS ou de réutiliser le CDN du site web pour des ressources externes. L’objectif est donc de réduire le nombre de domaines utilisés afin de profiter de la connexion unique de HTTP/2.

Voici le waterfall issu du test ci-dessus en HTTP/2.