Rendimiento HTTP vs HTTPS

378

¿Existen diferencias importantes en el rendimiento entre http y https? Creo recordar haber leído que HTTPS puede ser un quinto más rápido que HTTP. ¿Es esto válido con los navegadores / servidores web de la generación actual? Si es así, ¿existen documentos técnicos que lo respalden?

3
  • 1
    También debe consultar HTTP2, que los navegadores actualmente solo admiten cuando se usan con HTTPS. en.wikipedia.org/wiki/HTTP/2 28/12/15 a las 0:46
  • 2
    httpses siempre más lento que http(o mucho más lento).
    i486
    16/10/2017 a las 12:58
  • Si se produce un almacenamiento en caché transparente (calamar, por ejemplo), entonces podría ser significativo. El protocolo en sí, no creo que tenga una gran sobrecarga.
    Rolf
    27/06/18 a las 16:36
236

Hay una respuesta muy simple a esto: Perfile el rendimiento de su servidor web para ver cuál es la penalización de rendimiento para su situación particular. Existen varias herramientas para comparar el rendimiento de un servidor HTTP vs HTTPS (me vienen a la mente JMeter y Visual Studio) y son bastante fáciles de usar.

Nadie puede darle una respuesta significativa sin alguna información sobre la naturaleza de su sitio web, hardware, software y configuración de red.

Como han dicho otros, habrá algún nivel de sobrecarga debido al cifrado, pero depende en gran medida de:

  • Hardware
  • Software de servidor
  • Relación de contenido dinámico frente a estático
  • Distancia del cliente al servidor
  • Duración típica de la sesión
  • Etc (mi favorito personal)
  • Comportamiento de almacenamiento en caché de los clientes

En mi experiencia, los servidores que tienen un gran contenido dinámico tienden a verse menos afectados por HTTPS porque el tiempo dedicado al cifrado (sobrecarga de SSL) es insignificante en comparación con el tiempo de generación de contenido.

Los servidores que son pesados ​​para servir un conjunto bastante pequeño de páginas estáticas que se pueden almacenar en caché fácilmente en la memoria sufren una sobrecarga mucho mayor (en un caso, el rendimiento se midió en una "intranet").

Editar: un punto que ha sido mencionado por varios otros es que el protocolo de enlace SSL es el mayor costo de HTTPS. Eso es correcto, por lo que la "duración típica de la sesión" y el "comportamiento de almacenamiento en caché de los clientes" son importantes.

Muchas sesiones muy cortas significan que el tiempo de apretón de manos abrumará a cualquier otro factor de rendimiento. Las sesiones más largas significarán que se incurrirá en el costo del protocolo de enlace al inicio de la sesión, pero las solicitudes posteriores tendrán una sobrecarga relativamente baja.

El almacenamiento en caché del cliente se puede realizar en varios pasos, desde un servidor proxy a gran escala hasta el caché del navegador individual. Generalmente, el contenido HTTPS no se almacenará en caché en una caché compartida (aunque algunos servidores proxy pueden aprovechar un comportamiento de tipo intermediario para lograr esto). Muchos navegadores almacenan en caché el contenido HTTPS para la sesión actual y, a menudo, entre sesiones. El impacto del no almacenamiento en caché o menos almacenamiento en caché significa que los clientes recuperarán el mismo contenido con más frecuencia. Esto da como resultado más solicitudes y ancho de banda para atender la misma cantidad de usuarios.

6
  • James, esperaba que pudiera proporcionar un breve comentario sobre la velocidad comparativa de esta solución aSSL : assl.sullof.com/assl En la parte superior de su cabeza, ¿hay algo ganado en cuanto al rendimiento? ¡Gracias! 5 de nov. De 2009 a las 16:10
  • PD: Tengo entendido que esta solución requiere una clave del lado del cliente (que podría implementarse en el caso de una aplicación webkit / titanium), el objetivo es simplemente maximizar este componente de la ecuación de velocidad junto con los otros que mencionaste. 5 de nov. De 2009 a las 16:17
  • 7
    Esta publicación realmente no responde a la pregunta. Parece que Jim Geurts pregunta sobre la naturaleza del rendimiento de HTTP y HTTPS en sí mismos, no sobre una implementación en particular. HTTPS indudablemente más lento porque hace más trabajo. Entonces la pregunta es, ¿cuánto más lento? Todo el mundo sabe que si agrega más variables, obtiene resultados variables. 16/09/11 a las 20:13
  • 79
    Esta respuesta menciona muchas cosas irrelevantes (en otras palabras, incorrectas) al principio . Toma 5 párrafos para llegar a la respuesta correcta, que es un apretón de manos . 19/04/2013 a las 17:22
  • 2
    El contenido servido a través de HTTPS no se almacenará en caché mediante servidores proxy . Todos los navegadores modernos almacenan en caché el contenido HTTPS de forma predeterminada, a menos que se indique explícitamente que no lo hagan, como lo explica Jeff Atwood. 29/04/2014 a las 19:45
227

HTTPS requiere un apretón de manos inicial que puede ser muy lento. La cantidad real de datos transferidos como parte del protocolo de enlace no es enorme (por lo general, menos de 5 kB), pero para solicitudes muy pequeñas, esto puede ser una sobrecarga. Sin embargo, una vez que se realiza el apretón de manos, se utiliza una forma muy rápida de cifrado simétrico, por lo que la sobrecarga es mínima. En pocas palabras: realizar muchas solicitudes cortas a través de HTTPS será un poco más lento que HTTP, pero si transfieres muchos datos en una sola solicitud, la diferencia será insignificante.

Sin embargo, keepalive es el comportamiento predeterminado en HTTP / 1.1, por lo que hará un solo protocolo de enlace y luego muchas solicitudes a través de la misma conexión. Esto marca una diferencia significativa para HTTPS. Probablemente debería perfilar su sitio (como han sugerido otros) para asegurarse, pero sospecho que la diferencia de rendimiento no será notable.

6
  • 19
    Resulta que este costo del protocolo de enlace se pagará entre 4 y 10 veces por sesión, como mínimo, debido a que la mayoría de los navegadores utilizan múltiples conexiones al mismo servidor. Dependiendo de la duración de https-keep-alive para un navegador, es posible que se produzca repetidamente durante una sesión. 24 de nov. De 2008 a las 16:09
  • 6
    Con respecto a la característica de HTTP keepalive, hemos experimentado el escenario en el que las conexiones no permanecen persistentes. Para cada solicitud, la conexión de solicitud se está construyendo y desgarrando, lo que significa un protocolo de enlace MA-SSL. Hay posibilidades en las que el cliente o servidor puede haberse configurado para cerrar las conexiones. Suele ocurrir en entornos Tomcat / Websphere. 8 de septiembre de 2009 a las 14:15
  • 8
    @JamesSchek Varias conexiones deberían reutilizar la misma sesión SSL , lo que cambia bastante la imagen. Lo mismo se aplica incluso si HTTP Keep-Alive no funciona. 30 de enero de 2013 a las 0:14
  • 14
    @EJP Eso es cierto. Y en 2013, la mayoría de los navegadores / servidores y las implementaciones de SSL / TLS utilizan la reutilización de sesiones. En 2008, no siempre fue una suposición segura. 30 de enero de 2013 a las 2:59
  • 3
    Esta pregunta aparece alta en Google para "rendimiento http vs https". Si bien la respuesta anterior era cierta en 2008, ya no lo es en 2015 y no debe utilizarse como base para tomar decisiones para evitar el uso de https. 31/03/15 a las 16:17
101

Para comprender realmente cómo HTTPS aumentará su latencia, debe comprender cómo se establecen las conexiones HTTPS. Aquí hay un bonito diagrama . La clave es que en lugar de que el cliente obtenga los datos después de 2 "tramos" (un viaje de ida y vuelta, usted envía una solicitud, el servidor envía una respuesta), el cliente no obtendrá datos hasta al menos 4 tramos (2 viajes de ida y vuelta). . Por lo tanto, si un paquete tarda 100 ms en moverse entre el cliente y el servidor, su primera solicitud HTTPS tardará al menos 500 ms.

Por supuesto, esto se puede mitigar reutilizando la conexión HTTPS (lo que deberían hacer los navegadores), pero explica parte de ese bloqueo inicial al cargar un sitio web HTTPS.

5
  • 1
    En términos de un cliente Java, ¿cómo se puede hacer que la conexión HTTPS sea reutilizable? Quiero decir, ¿puedo hacer un objeto estático de HttpsConnection y reutilizarlo? (en el contexto de una aplicación web)
    Niks
    29/12/11 a las 9:27
  • 1
    5 años después, el enlace al bonito diagrama +1 no funciona, ¿alguien puede encontrarlo y ponerlo en la respuesta en lugar de un enlace? 1 de noviembre de 2013 a las 13:05
  • 2
    @FRoZen encontró un enlace alternativo 8/11/2013 a las 13:21
  • También creo que esta página es un diagrama muy bueno de http para entender mejor la imagen completa: blog.catchpoint.com/2010/09/17/anatomyhttp 9 de enero de 2014 a las 1:51
  • 1
    @Nikhil Java reutiliza automáticamente la conexión subyacente y la comparte entre solicitudes, a menos que el usuario lo obligue a través de disconnect. Consulte los documentos .
    Mohnish
    8 de ene. De 2019 a las 21:29
77

La sobrecarga NO se debe al cifrado. En una CPU moderna, el cifrado requerido por SSL es trivial.

La sobrecarga se debe a los apretones de manos SSL, que son largos y aumentan drásticamente el número de viajes de ida y vuelta necesarios para una sesión HTTPS a través de HTTP.

Mida (utilizando una herramienta como Firebug) los tiempos de carga de la página mientras el servidor está al final de un enlace de alta latencia simulado. Existen herramientas para simular un enlace de alta latencia - para Linux existe "netem". Compare HTTP con HTTPS en la misma configuración.

La latencia se puede mitigar hasta cierto punto mediante:

  • Asegurarse de que su servidor esté usando keepalives HTTP: esto le permite al cliente reutilizar las sesiones SSL, lo que evita la necesidad de otro protocolo de enlace.
  • Reducir el número de solicitudes a la menor cantidad posible, combinando recursos siempre que sea posible (por ejemplo, .js incluyen archivos, CSS) y fomentando el almacenamiento en caché del lado del cliente.
  • Reduzca el número de cargas de página, por ejemplo, cargando datos no necesarios en la página (tal vez en un elemento HTML oculto) y luego mostrándolos usando el script de cliente.
1
  • 9
    Estoy muy de acuerdo con @MarkR. En mi perfil reciente de mi página de inicio, HTTP vs HTTPS, los tiempos de carga promedio fueron 1,5 sy 4,5 s, respectivamente. Al observar los detalles de la conexión, el gran factor de desaceleración fueron los viajes de ida y vuelta adicionales debido al protocolo de enlace SSL. Los navegadores móviles a través de 3G fueron aún peores. Los números eran 5 y 9, respectivamente. 11/07/11 a las 22:49
24

Actualización de diciembre de 2014

Puede probar fácilmente la diferencia entre el rendimiento HTTP y HTTPS en su propio navegador utilizando el sitio web de prueba HTTP vs HTTPS de AnthumChris : “Esta página mide su tiempo de carga en conexiones HTTP no seguras y HTTPS cifradas. Ambas páginas cargan 360 imágenes únicas no almacenadas en caché (2,04 MB en total) ".

Los resultados pueden sorprenderle.

Es importante tener un conocimiento actualizado sobre el rendimiento de HTTPS porque Let's Encrypt Certificate Authority comenzará a emitir certificados SSL abiertos, automatizados y gratuitos en el verano de 2015, gracias a Mozilla, Akamai, Cisco, Electronic Frontier Foundation e IdenTrust.

Actualización de junio de 2015

Actualizaciones de Let's Encrypt, que llegarán en septiembre de 2015:

Más información en Twitter: @letsencrypt

Para obtener más información sobre el rendimiento de HTTPS y SSL / TLS, consulte:

Para obtener más información sobre la importancia de usar HTTPS, consulte:

Para resumir, permítanme citar a Ilya Grigorik : "TLS tiene exactamente un problema de rendimiento: no se utiliza lo suficiente. Todo lo demás se puede optimizar".

Gracias a Chris , autor de la prueba comparativa HTTP vs HTTPS , por sus comentarios a continuación.

14
  • 9
    Esa "prueba HTTP vs HTTPS" es engañosa intencionalmente, por favor no la vincule. Lo que realmente hace esa página es comparar HTTP con SPDY . Es cierto, si no me crees, pruébalo en IE y mira lo que dice. No existe ninguna situación en la que una solicitud HTTP sea más rápida que una solicitud HTTPS equivalente.
    orrd
    17/06/15 a las 16:44
  • 6
    Google obligó a SPDY a usar conexiones seguras solo por razones políticas, no técnicas. HTTP / 2 (que usa las mismas técnicas de mejora de velocidad de SPDY) puede usar una conexión no segura, y es un poco más rápido cuando lo hace. Una conexión no segura es siempre al menos un poco más rápida que una conexión segura que utiliza el mismo protocolo. La "prueba HTTP vs HTTPS" es intencionalmente engañosa y engañosa.
    orrd
    18 de junio de 2015 a las 4:47
  • 3
    El sitio web proporciona una comparación cuantitativa con números reales y es un esfuerzo para alentar a más personas a proteger a sus usuarios con HTTPS. Las opiniones solo nos llevan hasta cierto punto, y siempre tenemos la libertad de crear aplicaciones lentas e inseguras para IE a través de HTTP. Siempre votaré por crear aplicaciones web rápidas, de vanguardia y seguras para Chrome / Firefox con HTTPS. 22/06/15 a las 15:48
  • 2
    La aritmética en httpvshttps.com parece incorrecta: 1,7 segundos en comparación con 34 segundos no es "95% más rápido". Es 20 veces más rápido o 1900% más rápido. Debería comparar velocidades en lugar de duración. 16/11/2016 a las 17:07
  • 4
    La prueba es engañosa y engañosa. Según tools.ietf.org/html/rfc7540#section-3.2, no hay ninguna razón por la que HTTP / 2 no se pueda utilizar en una conexión no segura. Las grandes empresas están presionando por el uso universal de HTTPS. Las razones varían. Pero el hecho permanece. A menos que haya datos personales en la página, no hay razón para ejecutar SSL. Y aunque sí, con las computadoras de hoy, el protocolo de enlace SSL es trivial. Si empezamos a decir esto y aquello es trivial, las cosas simplemente se empantanarán. Realice una prueba 1: 1 de HTTP / 1.1 frente a HTTP / 1.1 SSL y HTTP / 2 frente a HTTP / 2 SSL. Luego discuta.
    Shinrai
    4 de abril de 2018 a las 0:23
24

La respuesta principal actual no es completamente correcta.

Como otros han señalado aquí, https requiere un protocolo de enlace y, por lo tanto, realiza más viajes de ida y vuelta de TCP / IP.

En un entorno WAN, por lo general, la latencia se convierte en el factor limitante y no en el aumento del uso de la CPU en el servidor.

Solo tenga en cuenta que la latencia de Europa a EE. UU. Puede ser de alrededor de 200 ms (tiempo de viaje).

Puede medir esto fácilmente (para el caso de un solo usuario) con HTTPWatch .

0
12

Además de todo lo mencionado hasta ahora, tenga en cuenta que algunos (¿todos?) Navegadores web no almacenan el contenido en caché obtenido a través de HTTPS en el disco duro local por razones de seguridad. Esto significa que, desde la perspectiva del usuario, las páginas con mucho contenido estático parecerán cargarse más lentamente después de reiniciar el navegador, y desde la perspectiva de su servidor, el volumen de solicitudes de contenido estático a través de HTTPS será mayor que el que habría sido a través de HTTP.

1
  • 7
    Enviar el encabezado "Cach-Control: max-age = X, public" hará que los navegadores modernos (recién probados FF4, Chrome12, IE8, IE9) almacenen el contenido en caché. Sin embargo, noté que estos navegadores envían un GET condicional, lo que podría generar una latencia adicional para los viajes de ida y vuelta adicionales, especialmente si una conexión SSL no está almacenada en caché (Keep Alive). 11/07/11 a las 23:28
6

No hay una sola respuesta para esto.

El cifrado siempre consumirá más CPU. Esto se puede descargar a hardware dedicado en muchos casos, y el costo variará según el algoritmo seleccionado. 3des es más caro que AES, por ejemplo. Algunos algoritmos son más caros para el cifrador que para el descifrador. Algunos tienen el costo opuesto.

Más caro que la criptografía a granel es el costo del protocolo de enlace. Las nuevas conexiones consumirán mucha más CPU. Esto se puede reducir con la reanudación de la sesión, a costa de mantener los secretos de la sesión anterior hasta que caduquen. Esto significa que las pequeñas solicitudes de un cliente que no vuelve por más son las más caras.

Para el tráfico cruzado de Internet, es posible que no note este costo en su velocidad de datos, porque el ancho de banda disponible es demasiado bajo. Pero ciertamente lo notará en el uso de la CPU en un servidor ocupado.

6

Puedo decirle (como usuario de acceso telefónico) que la misma página a través de SSL es varias veces más lenta que a través de HTTP normal ...

2
  • 7
    Buen punto. También descubrí que los tiempos de carga a través de la red de telefonía móvil (3G) también son de 2 a 3 veces más lentos. 11/07/11 a las 23:31
  • ¡Sí! ¡Solo un año y medio después de esa respuesta, me mudé a una nueva casa y finalmente pude cambiar a DSL por menos dinero que tener una línea POTS! 31 de mayo de 2013 a las 12:25 p.m.
6

En varios casos, el impacto en el rendimiento de los apretones de manos SSL se verá mitigado por el hecho de que la sesión SSL se puede almacenar en caché en ambos extremos (escritorio y servidor). En máquinas con Windows, por ejemplo, la sesión SSL se puede almacenar en caché hasta por 10 horas. Consulte http://support.microsoft.com/kb/247658/EN-US . Algunos aceleradores SSL también tendrán parámetros que le permitirán ajustar la hora en que se almacena en caché la sesión.

Otro impacto a considerar es que el contenido estático servido a través de HTTPS no será almacenado en caché por proxies, y esto puede reducir el rendimiento entre varios usuarios que acceden al sitio a través del mismo proxy. Esto puede mitigarse por el hecho de que el contenido estático también se almacenará en caché en los escritorios, las versiones 6 y 7 de Internet Explorer almacenan en caché el contenido estático HTTPS almacenable en caché a menos que se le indique lo contrario (Menú Herramientas / Opciones de Internet / Avanzado / Seguridad / No guardar páginas cifradas al disco).

3

Aquí hay un gran artículo (un poco antiguo, pero aún excelente) sobre la latencia del protocolo de enlace SSL. Me ayudó a identificar SSL como la principal causa de lentitud para los clientes que usaban mi aplicación a través de conexiones lentas a Internet:

http://www.semicomplete.com/blog/geekery/ssl-latency.html

3

Hice un pequeño experimento y obtuve una diferencia de tiempo del 16% para la misma imagen de flickr (233 kb):

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

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

ingrese la descripción de la imagen aquí

Por supuesto, estos números dependen de muchos factores, como el rendimiento de la computadora, la velocidad de conexión, la carga del servidor, la QoS en la ruta (la ruta de red particular que se toma del navegador al servidor), pero muestra la idea general: HTTPS es más lento que HTTP, ya que solicita más operaciones para completar (protocolo de enlace SSL y datos de codificación / decodificación).

1
  • 6
    no se puede crear una métrica de análisis estadístico basada en 2 solicitudes, una para cada una. 12 de enero de 2017 a las 16:41
2

Como estoy investigando el mismo problema para mi proyecto, encontré estas diapositivas. Mayor pero interesante:

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

1
  • Encontré los diagramas simplificados útiles pero también un poco deficientes. Creo que para comprender mejor el número de viajes de ida y vuelta, esta página para http es útil: blog.catchpoint.com/2010/09/17/anatomyhttp Entonces, lo más cerca que puedo decir de https: agregamos un viaje de ida y vuelta. 9 de enero de 2014 a las 1:49
2

Parece haber un caso extremo desagradable aquí: Ajax sobre wifi congestionado.

Ajax generalmente significa que KeepAlive ha expirado después de, digamos, 20 segundos. Sin embargo, el wifi significa que la conexión ajax (idealmente rápida) tiene que hacer varios viajes de ida y vuelta. Peor aún, el wifi a menudo pierde paquetes y hay retransmisiones de TCP. En este caso, HTTPS funciona realmente muy mal.

2

Is TLS fast yet? Yes.

Hay muchos proyectos que tienen como objetivo difuminar las líneas y hacer que HTTPS sea igual de rápido. Como SPDY y mod-spdy .

2

HTTP VS HTTPS PERFORMANCE COMPARISON

Siempre he asociado HTTPS con tiempos de carga de página más lentos en comparación con el HTTP antiguo. Como desarrollador web, el rendimiento de la página web es importante para mí y cualquier cosa que ralentice el rendimiento de mis páginas web es un no-no.

Para comprender las implicaciones de rendimiento involucradas, el diagrama a continuación le brinda una idea básica de lo que sucede bajo el capó cuando realiza una solicitud de un recurso mediante HTTPS.

ingrese la descripción de la imagen aquí

Como puede ver en el diagrama anterior, hay algunos pasos adicionales que deben llevarse a cabo cuando se usa HTTPS en comparación con el uso de HTTP simple. Cuando realiza una solicitud mediante HTTPS, debe producirse un protocolo de enlace para verificar la autenticidad de la solicitud. Este protocolo de enlace es un paso adicional en comparación con una solicitud HTTP y, desafortunadamente, incurre en algunos gastos generales.

Para comprender las implicaciones del rendimiento y ver por mí mismo si el impacto en el rendimiento sería significativo o no, utilicé este sitio como plataforma de prueba. Me dirigí a webpagetest.org y usé la herramienta de comparación visual para comparar la carga de este sitio usando HTTPS vs HTTP.

Como puede ver en el video Aquí está la prueba, el resultado usando HTTPS tuvo un impacto en los tiempos de carga de mi página, sin embargo, la diferencia es insignificante y solo noté una diferencia de 300 milisegundos. Es importante tener en cuenta que estos tiempos dependen de muchos factores, como el rendimiento de la computadora, la velocidad de conexión, la carga del servidor y la distancia del servidor.

Su sitio puede ser diferente y es importante probarlo a fondo y comprobar el impacto en el rendimiento que implica el cambio a HTTPS.

1
  • 1
    En general, el ejemplo es bueno, pero es más complicado de lo que se muestra, especialmente con Perfect Forward Secrecy. También hay cuatro claves simétricas en uso.
    zaph
    4 de agosto de 2016 a las 16:16
0

HTTPS tiene una sobrecarga de cifrado / descifrado, por lo que siempre será un poco más lento. La terminación SSL consume mucha CPU. Si tiene dispositivos para descargar SSL, la diferencia en las latencias puede ser apenas perceptible dependiendo de la carga a la que estén sus servidores.

0

Una diferencia de rendimiento más importante es que una sesión HTTPS permanece abierta mientras el usuario está conectado. Una 'sesión' HTTP dura solo para una solicitud de un solo artículo.

Si está ejecutando un sitio con una gran cantidad de usuarios concurrentes, espere comprar mucha memoria.

1
  • 2
    No en HTTP 1.1. Las conexiones se dejan abiertas durante mucho tiempo.
    Sklivvz
    29 de septiembre de 2008 a las 15:58
0

Es casi seguro que esto sea cierto dado que SSL requiere un paso adicional de cifrado que simplemente no es requerido por HTTP no SLL.

2
  • 2
    Que hay una diferencia de desempeño entre los dos casos. 29 de septiembre de 2008 a las 16:10
  • 2
    Pero la pregunta es "¿Existen diferencias importantes en el rendimiento entre http y https?"
    Sklivvz
    29 de septiembre de 2008 a las 16:11
0

Hay una forma de medir esto. La herramienta de apache llamada jmeter medirá el rendimiento. Si configura una gran muestra de su servicio con jmeter, en un entorno controlado, con y sin SSL, debería obtener una comparación precisa del costo relativo. Me interesarían tus resultados.

0

El HTTPS de hecho afecta la velocidad de la página ...

Las citas anteriores revelan la estupidez de muchas personas sobre la seguridad y la velocidad del sitio. El protocolo de enlace del servidor HTTPS / SSL crea un bloqueo inicial en las conexiones a Internet. Hay un retraso lento antes de que algo comience a mostrarse en la pantalla del navegador de su visitante. Este retraso se mide en información de tiempo hasta el primer byte.

La sobrecarga de protocolo de enlace HTTPS aparece en la información de tiempo hasta el primer byte (TTFB). El TTFB común varía desde menos de 100 milisegundos (en el mejor de los casos) a más de 1,5 segundos (en el peor de los casos). Pero, por supuesto, con HTTPS es 500 milisegundos peor.

Las conexiones 3G inalámbricas de ida y vuelta pueden durar 500 milisegundos o más. Los viajes adicionales duplican los retrasos a 1 segundo o más. Este es un gran impacto negativo en el rendimiento de los dispositivos móviles. Muy malas noticias.

Mi consejo, si no está intercambiando datos confidenciales, entonces no necesita SSL en absoluto, pero si le gusta un sitio web de comercio electrónico, puede habilitar HTTPS en ciertas páginas donde se intercambian datos confidenciales como el inicio de sesión y el pago.

Fuente: Pagepipe

-1

Los navegadores pueden aceptar el protocolo HTTP / 1.1 con HTTP o HTTPS, pero los navegadores solo pueden manejar el protocolo HTTP / 2.0 con HTTPS. Las diferencias de protocolo de HTTP / 1.1 a HTTP / 2.0 hacen que HTTP / 2.0, en promedio, sea 4-5 veces más rápido que HTTP / 1.1. Además, de los sitios que implementan HTTPS, la mayoría lo hace a través del protocolo HTTP / 2.0. Por lo tanto, HTTPS casi siempre será más rápido que HTTP simplemente debido a los diferentes protocolos que usa generalmente. Sin embargo, si se compara HTTP sobre HTTP / 1.1 con HTTPS sobre HTTP / 1.1, HTTP es un poco más rápido, en promedio, que HTTPS.

Aquí hay algunas comparaciones que ejecuté usando Chrome (Ver.64):

HTTPS sobre HTTP / 1.1:

  • 0,47 segundos de tiempo medio de carga de la página
  • 0.05 segundos más lento que HTTP sobre HTTP / 1.1
  • 0.37 segundos más lento que HTTPS sobre HTTP / 2.0

HTTP sobre HTTP / 1.1

  • 0,42 segundos de tiempo medio de carga de la página
  • 0.05 segundos más rápido que HTTPS sobre HTTP / 1.1
  • 0.32 segundos más lento que HTTPS sobre HTTP / 2.0

HTTPS sobre HTTP / 2.0

  • 0,10 segundos de tiempo medio de carga
  • 0.32 segundos más rápido que HTTP sobre HTTP / 1.1
  • 0.37 segundos más rápido que HTTPS sobre HTTPS / 1.1