https

Ce n'est un secret pour personne : les sites en HTTPS sont à 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.

schema HTTP vs HTTPS

Le chiffrement TLS a de quoi donc 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.

Start Render Speed Index Nombre de requêtes Poids de la page
HTTP 4,611 6831 112 1429
HTTPS 5,704
(+24%)
8108
(+19%)
112
(=)
1515

(+6%)

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 : adieu la cascade, bonjour la falaise, ou comme dirait Stéphane, notre CEO, “Adieu le waterfall, bonjour le wall !”.

HTTP 1.1 vs HTTP/2

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 :

Start Render Speed Index Nombre de requêtes Poids de la page
HTTPS 5,704 8108 112 1515
HTTP/2 5,810
(+2%)
7536
(-7%)
113
(=)
1497
(-1%)

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 :

  Start Render Speed Index Nombre de requêtes Poids de la page
HTTPS 5,704 8108 112 1515
HTTP/2 + optimisations FEO 2,901
(-49%)
5446
(-32%)
61
(-45%)
976
(-36%)

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 :

http-https-http2

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.

waterfall HTTP2

Comme nous pouvons le voir, certaines ressources sont déjà unshardées. Mais elles ne le sont pas toutes. De fait, le Start Render est retardé (cf. la ligne verticale verte).
En unshardant toutes les ressources dans le(les polices par exemple), le Start Render pourrait être avancé, car les temps pour établir de nouvelles connexions TLS seraient économisés. L’expérience utilisateur n’en serait que meilleure.

Vous l’aurez compris, la perte de vitesse en passant au HTTPS n’est pas une fatalité, dès lors que vous prenez du temps pour comprendre le chargement de votre site et que vous appliquez les bonnes pratiques (nous pouvons le faire pour vous si vous voulez).
Pour aller un peu plus loin, vous trouverez dans cet article et dans cette vidéo du meetup webperf les optimisations adaptées à HTTP/2, ainsi que celles qui pourraient être contre-productives.
À vous de jouer !

Vous souhaitez décrypter un peu plus votre waterfall
et comprendre comment l’optimiser ?

Téléchargez le livre blanc

Quelques ressources pour en savoir plus sur HTTP/2 :

VOUS AIMEREZ PEUT-ÊTRE AUSSI...

Comment organiser ses équipes pour booster la webp... article img { margin:15px !important; } .grey-box { background: #dfe1e1; padding: 20px; margin-bottom: 20px; } Des utilisateurs aux...
4 conseils pour tenir la charge pendant les soldes article img { margin:15px !important; } .grey-box { background: #dfe1e1; padding: 20px; margin-bottom: 20px; } Nous y revoilà, le...
Webperf : Comment optimiser le chargement des font... Quel est l'impact du chargement des fonts sur vos temps de chargement ? Quelle est la meilleure stratégie webperf à adopter pour optimiser l...
4 optimisations clés pour accélérer votre site HTT... Le TLS (Transport Layer Security) chiffre le trafic d'un site Web empêchant d'autres entités de surveiller ses communications. Cependant, l'...