Performances HTTP vs HTTPS


363

Existe-t-il des différences de performances majeures entre http et https? Je semble me rappeler avoir lu que HTTPS peut être un cinquième aussi rapide que HTTP. Est-ce valable pour les serveurs Web / navigateurs de la génération actuelle? Si oui, existe-t-il des livres blancs pour le soutenir?


1
Vous devriez également consulter HTTP2, que les navigateurs ne prennent actuellement en charge que lorsqu'ils sont utilisés avec HTTPS. en.wikipedia.org/wiki/HTTP/2
Luca Steeb

1
httpsest toujours plus lent que http(ou beaucoup plus lent).
i486

S'il y a une mise en cache transparente (squid par exemple), cela peut être important. Le protocole lui-même, je ne pense pas qu'il a un gros frais généraux.
Rolf

Réponses:


231

Il y a une réponse très simple à cela: profilez les performances de votre serveur Web pour voir quelle est la pénalité de performances pour votre situation particulière. Il existe plusieurs outils pour comparer les performances d'un serveur HTTP vs HTTPS (JMeter et Visual Studio viennent à l'esprit) et ils sont assez faciles à utiliser.

Personne ne peut vous donner une réponse significative sans quelques informations sur la nature de votre site Web, du matériel, des logiciels et de la configuration du réseau.

Comme d'autres l'ont dit, il y aura un certain niveau de surcharge en raison du cryptage, mais cela dépend fortement de:

  • Matériel
  • Logiciel serveur
  • Rapport entre contenu dynamique et contenu statique
  • Distance du client au serveur
  • Durée de session typique
  • Etc (mon préféré)
  • Comportement de mise en cache des clients

D'après mon expérience, les serveurs qui sont lourds sur le contenu dynamique ont tendance à être moins impactés par HTTPS parce que le temps passé au chiffrement (surcharge SSL) est insignifiant par rapport au temps de génération de contenu.

Les serveurs qui sont lourds sur un ensemble assez restreint de pages statiques qui peuvent facilement être mises en cache en mémoire souffrent d'un surcoût beaucoup plus élevé (dans un cas, le débit a été perturbé sur un "intranet").

Edit: Un point qui a été soulevé par plusieurs autres est que la négociation SSL est le coût principal de HTTPS. C'est correct, c'est pourquoi la «longueur de session typique» et le «comportement de mise en cache des clients» sont importants.

De nombreuses sessions très courtes signifient que le temps de prise de contact dépassera tous les autres facteurs de performance. Des sessions plus longues signifieront que le coût de la négociation sera engagé au début de la session, mais les demandes ultérieures auront des frais généraux relativement faibles.

La mise en cache du client peut être effectuée en plusieurs étapes, depuis un serveur proxy à grande échelle jusqu'au cache du navigateur individuel. Généralement, le contenu HTTPS ne sera pas mis en cache dans un cache partagé (bien que quelques serveurs proxy puissent exploiter un comportement de type homme du milieu pour y parvenir). De nombreux navigateurs mettent en cache le contenu HTTPS pour la session en cours et souvent sur plusieurs sessions. L'impact de la non-mise en cache ou moins de mise en cache signifie que les clients récupéreront le même contenu plus fréquemment. Il en résulte plus de demandes et de bande passante pour desservir le même nombre d'utilisateurs.


James, j'espérais que vous pourriez être en mesure de fournir un bref commentaire sur la vitesse comparative de cette solution aSSL : assl.sullof.com/assl Du haut de votre tête, y a-t-il quelque chose à gagner en termes de performances? Merci!
Matt Gardner

PS: Je crois comprendre que cette solution nécessite une clé côté client (qui pourrait être implémentée dans le cas d'une application webkit / titanium), l'objectif est simplement de maximiser cette composante de l'équation de vitesse avec les autres que vous avez mentionnées.
Matt Gardner

7
Ce post ne répond pas vraiment à la question. Il semble que Jim Geurts pose des questions sur la nature des performances de HTTP et HTTPS elles-mêmes, et non sur une implémentation particulière. HTTPS est indéniablement plus lent car il fait plus de travail. La question est donc: combien de temps plus lent? Tout le monde sait que si vous ajoutez plus de variables, vous obtenez des résultats variables.
Elliot Cameron,

74
Cette réponse mentionne beaucoup de choses non pertinentes (en d'autres termes erronées) au début . Il prend 5 paragraphes pour arriver à la bonne réponse, qui est la PRISE DE MAIN .
bobobobo

2
Le contenu diffusé via HTTPS ne sera pas mis en cache par les mandataires . Tous les navigateurs modernes mettent en cache le contenu HTTPS par défaut, sauf indication explicite contraire, comme expliqué par Jeff Atwood
Jarek Przygódzki

222

HTTPS nécessite une prise de contact initiale qui peut être très lente. La quantité réelle de données transférées dans le cadre de la prise de contact n'est pas énorme (moins de 5 Ko en général), mais pour les très petites demandes, cela peut être un peu lourd. Cependant, une fois la prise de contact terminée, une forme très rapide de cryptage symétrique est utilisée, de sorte que la surcharge y est minimale. Conclusion: faire beaucoup de courtes demandes via HTTPS sera un peu plus lent que HTTP, mais si vous transférez beaucoup de données en une seule demande, la différence sera insignifiante.

Cependant, keepalive est le comportement par défaut dans HTTP / 1.1, vous ferez donc une seule poignée de main, puis de nombreuses demandes sur la même connexion. Cela fait une différence significative pour HTTPS. Vous devriez probablement profiler votre site (comme d'autres l'ont suggéré) pour vous en assurer, mais je soupçonne que la différence de performances ne sera pas perceptible.


19
Il s'avère que ce coût de prise de contact sera payé environ 4 à 10 fois par session, au minimum, car la plupart des navigateurs utilisent plusieurs connexions au même serveur. Selon la durée du https-keep-alive pour un navigateur, il peut être généré à plusieurs reprises au cours d'une session.
James Schek

6
concernant la fonctionnalité HTTP keepalive, nous avons expérimenté le scénario où les connexions ne restent pas persistantes. Pour chaque demande, la connexion de demande est établie et supprimée, ce qui signifie une négociation MA-SSL. Il existe des possibilités dans lesquelles le client ou le serveur peut avoir configuré pour fermer les connexions. Se produit généralement dans les environnements Tomcat / Websphere.
zkarthik

8
@JamesSchek Plusieurs connexions devraient réutiliser la même session SSL , ce qui change un peu l'image. Il en va de même même si HTTP keep-alive ne fonctionne pas.
Marquis de Lorne

14
@EJP C'est vrai. Et en 2013, la plupart des navigateurs / serveurs et implémentations SSL / TLS utilisent la réutilisation de session. En 2008, ce n'était pas une hypothèse toujours sûre.
James Schek

3
Cette question apparaît haut dans Google pour les «performances http vs https». Alors que la réponse ci-dessus était vraie en 2008, elle ne l'est plus en 2015 et ne devrait pas être utilisée comme base de décisions pour éviter d'utiliser https.
Paul Schreiber

101

Pour vraiment comprendre comment HTTPS augmentera votre latence, vous devez comprendre comment les connexions HTTPS sont établies. Voici un joli diagramme . La clé est qu'au lieu que le client obtienne les données après 2 "étapes" (un aller-retour, vous envoyez une demande, le serveur envoie une réponse), le client n'obtiendra les données qu'au moins 4 étapes (2 allers-retours) . Ainsi, s'il faut 100 ms pour qu'un paquet se déplace entre le client et le serveur, votre première requête HTTPS prendra au moins 500 ms.

Bien sûr, cela peut être atténué en réutilisant la connexion HTTPS (ce que les navigateurs devraient faire), mais cela explique une partie de ce blocage initial lors du chargement d'un site Web HTTPS.


1
En termes de client Java, comment rendre la connexion HTTPS réutilisable? Je veux dire, puis-je créer un objet statique de HttpsConnection et le réutiliser? (dans un contexte d'application Web)
Niks

1
5 ans plus tard, le lien vers le joli diagramme +1 ne fonctionne pas, peut-on le trouver et le mettre dans la réponse au lieu d'un lien?
Jim Wolff

2
@FRoZen a trouvé un lien alternatif
Stefan L

Je pense aussi que cette page est un très bon diagramme de http pour mieux comprendre l'ensemble de l'image: blog.catchpoint.com/2010/09/17/anatomyhttp
Vue elliptique

1
@Nikhil Java réutilise automatiquement la connexion sous-jacente et la partage entre les demandes, sauf si forcé par l'utilisateur via disconnect. Vérifiez les documents .
Mohnish

76

La surcharge n'est PAS due au cryptage. Sur un processeur moderne, le cryptage requis par SSL est trivial.

La surcharge est due aux poignées de main SSL, qui sont longues et augmentent considérablement le nombre d'aller-retour requis pour une session HTTPS par rapport à une session HTTP.

Mesurez (à l'aide d'un outil tel que Firebug) les temps de chargement des pages pendant que le serveur est à l'extrémité d'un lien simulé à latence élevée. Il existe des outils pour simuler une liaison à latence élevée - pour Linux, il existe "netem". Comparez HTTP avec HTTPS sur la même configuration.

La latence peut être atténuée dans une certaine mesure par:

  • S'assurer que votre serveur utilise des keepalives HTTP - cela permet au client de réutiliser les sessions SSL, ce qui évite d'avoir besoin d'une autre poignée de main
  • Réduire le nombre de demandes au plus petit nombre possible - en combinant les ressources lorsque cela est possible (par exemple, les fichiers .js incluent les fichiers CSS) et en encourageant la mise en cache côté client
  • Réduisez le nombre de chargements de page, par exemple en chargeant des données non requises dans la page (peut-être dans un élément HTML caché) puis en les affichant à l'aide du client-script.

8
Je suis très d'accord avec @MarkR. Mon profil récent de ma page d'accueil, HTTP vs HTTPS, les temps de chargement moyens étaient respectivement de 1,5s et 4,5s. En regardant les détails de la connexion, le gros facteur de ralentissement était les allers-retours supplémentaires dus à la prise de contact SSL. Les navigateurs mobiles sur 3G étaient encore pires. Les nombres étaient respectivement de 5 et 9.
Clint Pachl

26

Mise à jour de décembre 2014

Vous pouvez facilement tester la différence entre les performances HTTP et HTTPS dans votre propre navigateur en utilisant le site Web HTTP vs HTTPS Test d' AnthumChris : «Cette page mesure son temps de chargement sur des connexions HTTP non sécurisées et HTTPS chiffrées. Les deux pages chargent 360 images uniques non mises en cache (2,04 Mo au total). »

Les résultats pourraient vous surprendre.

Il est important d'avoir une connaissance à jour des performances HTTPS, car l' Autorité de certification Let's Encrypt commencera à émettre des certificats SSL gratuits, automatisés et ouverts à l'été 2015, grâce à Mozilla, Akamai, Cisco, Electronic Frontier Foundation et IdenTrust.

Mise à jour de juin 2015

Mises à jour sur Let's Encrypt - Arrivée en septembre 2015:

Plus d'informations sur Twitter: @letsencrypt

Pour plus d'informations sur les performances HTTPS et SSL / TLS, voir:

Pour plus d'informations sur l'importance d'utiliser HTTPS, voir:

Pour résumer, permettez-moi de citer Ilya Grigorik : "TLS a exactement un problème de performances: il n'est pas suffisamment utilisé. Tout le reste peut être optimisé."

Merci à Chris - auteur du benchmark HTTP vs HTTPS - pour ses commentaires ci-dessous.


6
Ce "Test HTTP vs HTTPS" est intentionnellement trompeur, veuillez ne pas y lier. En réalité, cette page compare HTTP à SPDY . C'est vrai, si vous ne me croyez pas, essayez-le dans IE et voyez ce qu'il dit. Il n'y a aucune situation où une demande HTTP est plus rapide qu'une demande HTTPS équivalente.
orrd

3
Google a forcé SPDY à n'utiliser des connexions sécurisées que pour des raisons politiques et non techniques. HTTP / 2 (qui utilise les mêmes techniques d'amélioration de la vitesse de SPDY) peut utiliser une connexion non sécurisée, et il est légèrement plus rapide lorsqu'il le fait. Une connexion non sécurisée est toujours au moins un peu plus rapide qu'une connexion sécurisée utilisant le même protocole. Le "Test HTTP vs HTTPS" est intentionnellement trompeur et trompeur.
2015 à 16h47

3
Le site Web fournit une comparaison quantitative avec des chiffres réels, et c'est un effort pour encourager plus de gens à protéger leurs utilisateurs avec HTTPS. Les opinions ne nous mènent que si loin, et nous avons toujours la liberté de créer des applications lentes et non sécurisées pour IE sur HTTP. Je voterai toujours pour la création d'applications Web rapides, à la pointe de la technologie et sécurisées pour Chrome / Firefox avec HTTPS.
AnthumChris

2
L'arithmétique sur httpvshttps.com semble fausse: 1,7 seconde contre 34 secondes n'est pas "95% plus rapide". C'est 20 fois plus rapide ou 1900% plus rapide. Il devrait comparer les vitesses plutôt que la durée.
Colonel Panic

2
Le test est trompeur et trompeur. Par tools.ietf.org/html/rfc7540#section-3.2 il n'y a aucune raison pour que HTTP / 2 ne puisse pas être utilisé sur une connexion non sécurisée. Les grandes entreprises font pression pour une utilisation HTTPS universelle. Les raisons varient. Mais le fait demeure. Sauf s'il y a des données personnelles sur la page, il n'y a aucune raison d'exécuter SSL. Et bien que oui avec les ordinateurs d'aujourd'hui, la prise de contact SSL est triviale. Si nous commençons à dire cela et que ce sont des choses insignifiantes, nous nous enliserons simplement. Produisez un test 1: 1 de HTTP / 1.1 vs HTTP / 1.1 SSL et HTTP / 2 vs HTTP / 2 SSL. Discutez ensuite.
Shinrai

23

La première réponse actuelle n'est pas entièrement correcte.

Comme d'autres l'ont souligné ici, https nécessite une négociation et fait donc plus d'allers-retours TCP / IP.

Dans un environnement WAN, la latence devient alors le facteur limitant et non l'augmentation de l'utilisation du processeur sur le serveur.

Gardez à l'esprit que la latence de l'Europe aux États-Unis peut être d'environ 200 ms (temps de torundtrip).

Vous pouvez facilement mesurer cela (pour le cas d'un utilisateur unique) avec HTTPWatch .


12

En plus de tout ce qui a été mentionné jusqu'à présent, veuillez garder à l'esprit que certains (tous?) Navigateurs Web ne stockent pas le contenu mis en cache obtenu via HTTPS sur le disque dur local pour des raisons de sécurité. Cela signifie que, du point de vue de l'utilisateur, les pages contenant beaucoup de contenu statique semblent se charger plus lentement après le redémarrage du navigateur, et du point de vue de votre serveur, le volume de demandes de contenu statique via HTTPS sera plus élevé qu'il ne l'aurait été via HTTP.


6
L'envoi de l'en-tête "Cach-Control: max-age = X, public", amènera les navigateurs modernes (juste testés FF4, Chrome12, IE8, IE9) à mettre en cache le contenu. Cependant, j'ai remarqué que ces navigateurs envoient un GET conditionnel, ce qui pourrait entraîner une latence supplémentaire pour les allers-retours supplémentaires, surtout si une connexion SSL n'est pas mise en cache (Keep Alive).
Clint Pachl

6

Il n'y a pas de réponse unique à cela.

Le chiffrement consommera toujours plus de CPU. Cela peut être déchargé sur du matériel dédié dans de nombreux cas, et le coût variera selon l'algorithme sélectionné. 3des est plus cher que AES, par exemple. Certains algorithmes sont plus chers pour le crypteur que pour le décrypteur. Certains ont le coût inverse.

Le coût de la poignée de main est plus cher que la cryptographie en vrac. Les nouvelles connexions consommeront beaucoup plus de CPU. Cela peut être réduit avec la reprise de la session, au prix de garder les anciens secrets de session jusqu'à leur expiration. Cela signifie que les petites demandes d'un client qui ne revient pas pour plus sont les plus chères.

Pour le trafic Internet croisé, vous ne remarquerez peut-être pas ce coût dans votre débit de données, car la bande passante disponible est trop faible. Mais vous le remarquerez certainement dans l'utilisation du processeur sur un serveur occupé.


6

Je peux vous dire (en tant qu'utilisateur par ligne commutée) que la même page via SSL est plusieurs fois plus lente que via HTTP standard ...


6
Bon point. J'ai également constaté que les temps de chargement via le réseau de téléphonie mobile (3G) sont également 2 à 3 fois plus lents.
Clint Pachl

Oui! Juste un an et demi après cette réponse, j'ai déménagé dans une nouvelle maison et j'ai finalement pu passer à DSL pour moins d'argent que d'avoir une ligne POTS!
Brian Knoblauch

6

Dans un certain nombre de cas, l'impact sur les performances des poignées de main SSL sera atténué par le fait que la session SSL peut être mise en cache aux deux extrémités (bureau et serveur). Sur les machines Windows par exemple, la session SSL peut être mise en cache jusqu'à 10 heures. Voir http://support.microsoft.com/kb/247658/EN-US . Certains accélérateurs SSL auront également des paramètres vous permettant de régler l'heure de mise en cache de la session.

Un autre impact à prendre en compte est que le contenu statique servi via HTTPS ne sera pas mis en cache par les mandataires, ce qui peut réduire les performances de plusieurs utilisateurs accédant au site via le même proxy. Cela peut être atténué par le fait que le contenu statique sera également mis en cache sur les bureaux, les versions 6 et 7 d'Internet Explorer mettent en cache le contenu statique HTTPS pouvant être mis en cache, sauf indication contraire (menu Outils / Options Internet / Avancé / Sécurité / Ne pas enregistrer les pages cryptées sur le disque).


4

J'ai fait une petite expérience et j'ai obtenu 16% de différence de temps pour la même image de flickr (233 ko):

http://farm8.staticflickr.com/7405/13368635263_d792fc1189_b.jpg

https://farm8.staticflickr.com/7405/13368635263_d792fc1189_b.jpg

entrez la description de l'image ici

Bien sûr, ces chiffres dépendent de nombreux facteurs, tels que les performances de l'ordinateur, la vitesse de connexion, la charge du serveur, la QoS sur le chemin (le chemin réseau particulier emprunté du navigateur au serveur), mais il montre l'idée générale: HTTPS est plus lent que HTTP, car il requesres plus d'opérations à terminer (SSL handshaking et encodage / décodage des données).


4
impossible de créer une statistique d'analyse statistique basée sur 2 demandes, une pour chacune.
Tom Roggero


2

Puisque j'étudie le même problème pour mon projet, j'ai trouvé ces diapositives. Plus ancien mais intéressant:

http://www.cs.nyu.edu/artg/research/comparison/comparison_slides/sld001.htm


J'ai trouvé les diagrammes simplifiés utiles mais aussi un peu manquants. Je pense que pour mieux comprendre le nombre de voyages aller-retour, cette page pour http est utile: blog.catchpoint.com/2010/09/17/anatomyhttp Alors pour autant que je sache pour https: nous ajoutons un voyage aller-retour.
Vue elliptique le

2

Il semble y avoir un cas de bord méchant ici: Ajax sur wifi congestionné.

Ajax signifie généralement que la KeepAlive a expiré après environ 20 secondes. Cependant, le wifi signifie que la connexion ajax (idéalement rapide) doit effectuer plusieurs allers-retours. Pire encore, le wifi perd souvent des paquets, et il y a des retransmissions TCP. Dans ce cas, HTTPS fonctionne vraiment très mal!



2

COMPARAISON DES PERFORMANCES HTTP VS HTTPS

J'ai toujours associé HTTPS à des temps de chargement de page plus lents par rapport à l'ancien HTTP simple. En tant que développeur Web, les performances des pages Web sont importantes pour moi et tout ce qui peut ralentir les performances de mes pages Web est un non-non.

Afin de comprendre les implications de performances impliquées, le diagramme ci-dessous vous donne une idée de base de ce qui se passe sous le capot lorsque vous faites une demande de ressource à l'aide de HTTPS.

entrez la description de l'image ici

Comme vous pouvez le voir sur le diagramme ci-dessus, il y a quelques étapes supplémentaires qui doivent être effectuées lors de l'utilisation de HTTPS par rapport à l'utilisation de HTTP simple. Lorsque vous effectuez une demande à l'aide de HTTPS, une négociation doit avoir lieu afin de vérifier l'authenticité de la demande. Cette poignée de main est une étape supplémentaire par rapport à une requête HTTP et entraîne malheureusement des frais généraux.

Afin de comprendre les implications en termes de performances et de voir par moi-même si l'impact sur les performances serait significatif, j'ai utilisé ce site comme plate-forme de test. Je me suis dirigé vers webpagetest.org et j'ai utilisé l'outil de comparaison visuelle pour comparer ce chargement de site en utilisant HTTPS vs HTTP.

Comme vous pouvez le voir dans Voici la vidéo de test, le résultat en utilisant HTTPS a eu un impact sur les temps de chargement de ma page, mais la différence est négligeable et je n'ai remarqué qu'une différence de 300 millisecondes. Il est important de noter que ces délais dépendent de nombreux facteurs, tels que les performances de l'ordinateur, la vitesse de connexion, la charge du serveur et la distance du serveur.

Votre site peut être différent, et il est important de tester soigneusement votre site et de vérifier l'impact sur les performances impliqué dans le passage au HTTPS.


1
En général, l'exemple est bon, mais il est plus impliqué que décrit, en particulier avec Perfect Forward Secrecy. De plus, quatre clés symétriques sont actuellement utilisées.
zaph

0

Il existe un moyen de mesurer cela. L'outil d'Apache appelé jmeter mesurera le débit. Si vous configurez un large échantillonnage de votre service avec jmeter, dans un environnement contrôlé, avec et sans SSL, vous devriez obtenir une comparaison précise du coût relatif. Je serais intéressé par vos résultats.


-1

HTTPS a une surcharge de cryptage / décryptage, donc il sera toujours légèrement plus lent. La terminaison SSL est très gourmande en ressources processeur. Si vous avez des appareils pour décharger SSL, la différence de latence peut être à peine perceptible selon la charge de vos serveurs.


-1

Une différence de performances plus importante est qu'une session HTTPS est ouverte pendant que l'utilisateur est connecté. Une «session» HTTP ne dure que pour une seule demande d'élément.

Si vous gérez un site avec un grand nombre d'utilisateurs simultanés, attendez-vous à acheter beaucoup de mémoire.


2
Non dans HTTP 1.1. Les connexions restent ouvertes pendant longtemps.
Sklivvz

-1

Cela va presque certainement être vrai étant donné que SSL nécessite une étape de cryptage supplémentaire qui n'est tout simplement pas requise par HTTP non SLL.


2
Qu'il y a une différence de performance entre les deux cas.
David The Man

2
Mais la question est "Y a-t-il des différences de performances majeures entre http et https?"
Sklivvz

-1

Le HTTPS affecte en effet la vitesse de la page ...

Les citations ci-dessus révèlent la folie de nombreuses personnes concernant la sécurité et la vitesse du site. La prise de contact du serveur HTTPS / SSL crée un blocage initial lors de l'établissement des connexions Internet. Il y a un lent délai avant que quoi que ce soit commence à s'afficher sur l'écran du navigateur de votre visiteur. Ce retard est mesuré en informations du temps jusqu'au premier octet.

Le surdébit d'établissement de liaison HTTPS apparaît dans les informations de temps jusqu'au premier octet (TTFB). Le TTFB commun varie de moins de 100 millisecondes (dans le meilleur des cas) à plus de 1,5 seconde (dans le pire des cas). Mais, bien sûr, avec HTTPS, c'est 500 millisecondes de moins.

Les connexions 3G sans fil aller-retour peuvent durer 500 millisecondes ou plus. Les trajets supplémentaires doublent les retards à 1 seconde ou plus. Il s'agit d'un impact important et négatif sur les performances mobiles. De très mauvaises nouvelles.

Mon conseil, si vous n'échangez pas de données sensibles, vous n'avez pas du tout besoin de SSL, mais si vous aimez un site Web de commerce électronique, vous pouvez simplement activer HTTPS sur certaines pages où des données sensibles sont échangées comme la connexion et le paiement.

Source: Pagepipe


-2

Les navigateurs peuvent accepter le protocole HTTP / 1.1 avec HTTP ou HTTPS, mais les navigateurs ne peuvent gérer que le protocole HTTP / 2.0 avec HTTPS. Les différences de protocole entre HTTP / 1.1 et HTTP / 2.0 rendent HTTP / 2.0, en moyenne, 4 à 5 fois plus rapide que HTTP / 1.1. De plus, la plupart des sites qui implémentent HTTPS le font via le protocole HTTP / 2.0. Par conséquent, HTTPS va presque toujours être plus rapide que HTTP simplement en raison des différents protocoles qu'il utilise généralement. Cependant, si HTTP sur HTTP / 1.1 est comparé à HTTPS sur HTTP / 1.1, alors HTTP est légèrement plus rapide, en moyenne, que HTTPS.

Voici quelques comparaisons que j'ai effectuées avec Chrome (Ver. 64):

HTTPS sur HTTP / 1.1:

  • Temps de chargement moyen des pages de 0,47 seconde
  • 0,05 seconde plus lent que HTTP sur HTTP / 1.1
  • 0,37 secondes plus lent que HTTPS sur HTTP / 2.0

HTTP sur HTTP / 1.1

  • Temps de chargement moyen des pages de 0,42 seconde
  • 0,05 seconde plus rapide que HTTPS sur HTTP / 1.1
  • 0,32 secondes plus lent que HTTPS sur HTTP / 2.0

HTTPS sur HTTP / 2.0

  • Temps de chargement moyen de 0,10 seconde
  • 0,32 seconde plus rapide que HTTP sur HTTP / 1.1
  • 0,37 seconde plus rapide que HTTPS sur HTTPS / 1.1
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.