SSL/TLS es necesario para cualquier sitio en 2026 — Google lo premia, los navegadores lo exigen y los usuarios lo esperan. El mito de que "HTTPS es más lento que HTTP" fue cierto en 2010, pero hoy una conexión TLS bien configurada no añade latencia perceptible. El problema es que muchos sitios siguen usando configuraciones obsoletas que sí penalizan la velocidad.
En esta guía verás exactamente qué pasos añade TLS a una conexión, por qué algunas configuraciones son lentas, y qué hacer para eliminar esa lentitud sin comprometer la seguridad.
¿Qué hace TLS y por qué puede ser lento?
Cuando un navegador se conecta a tu servidor por primera vez usando HTTPS, ocurre un proceso llamado TLS handshake (negociación TLS). Este proceso autentica al servidor, negocia el algoritmo de cifrado y establece las claves de sesión.
En TLS 1.2, este handshake requiere 2 round-trips antes de que se envíe el primer byte de contenido. En una conexión con 50 ms de latencia, eso son 100 ms adicionales solo para negociar la conexión segura, antes de contar la descarga del HTML.
Las principales fuentes de lentitud relacionadas con TLS son:
- Usar TLS 1.2 en lugar de TLS 1.3 (que requiere solo 1 round-trip).
- No reutilizar sesiones TLS (cada visita negocia desde cero).
- Certificados con cadenas largas o mal ordenadas que el navegador tiene que verificar.
- Cifrados lentos como RSA 2048 sin curvas elípticas.
- OCSP stapling desactivado (el navegador consulta al emisor del certificado en cada visita).
TLS 1.3: el cambio más importante que puedes hacer
TLS 1.3 reduce el handshake a 1 round-trip (y 0 en conexiones repetidas con 0-RTT). Es la versión más moderna y segura del protocolo, y prácticamente todos los navegadores modernos lo soportan.
Para verificar si tu servidor usa TLS 1.3, puedes comprobarlo con SSL Labs (ssllabs.com/ssltest) — busca que el campo "TLS 1.3" aparezca como "Yes" en los protocolos soportados.
Para habilitarlo en Apache:
SSLProtocol -all +TLSv1.2 +TLSv1.3Para Nginx:
ssl_protocols TLSv1.2 TLSv1.3;Mantén TLS 1.2 como fallback para navegadores más antiguos, pero desactiva TLS 1.0 y TLS 1.1 — están obsoletos y son inseguros.
Reutilización de sesiones TLS
La reutilización de sesiones permite que un navegador que ya negoció una sesión TLS la recupere en visitas posteriores sin repetir el handshake completo. Hay dos mecanismos:
Session Resumption (ID de sesión)
El servidor guarda el estado de la sesión y entrega al cliente un ID. En la siguiente visita, el cliente presenta el ID y se salta el handshake. Funciona bien en servidores con un solo proceso, pero pierde efectividad en entornos con múltiples workers o servidores (el ID solo vale para el proceso que lo creó).
Session Tickets
El servidor cifra el estado de la sesión y lo envía al cliente como un "ticket". En la siguiente visita, el cliente presenta el ticket y el servidor lo descifra para restaurar la sesión. Funciona en entornos multi-worker, pero requiere que todos los servidores compartan la misma clave de cifrado de tickets.
En Apache con mod_ssl, la reutilización de sesiones está habilitada por defecto. En Nginx:
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 1d;
ssl_session_tickets off; # Desactivar tickets es más seguro (Perfect Forward Secrecy)Con TLS 1.3 y 0-RTT activado, las conexiones de retorno no pagan ningún coste de handshake — aunque 0-RTT tiene implicaciones de seguridad que conviene entender antes de activarlo en producción.
OCSP Stapling: elimina una consulta externa por visita
Por defecto, cuando un navegador recibe tu certificado SSL, verifica que no ha sido revocado consultando al servidor OCSP (Online Certificate Status Protocol) de la autoridad certificadora. Esa consulta es una petición HTTP extra a un servidor externo, con su propia latencia.
OCSP Stapling resuelve esto: tu servidor obtiene periódicamente la respuesta OCSP y la adjunta ("staplea") a la respuesta TLS. El navegador recibe la confirmación de validez directamente, sin hacer ninguna consulta externa.
En Apache:
SSLUseStapling On
SSLStaplingCache shmcb:/var/run/ocsp(128000)En Nginx:
ssl_stapling on;
ssl_stapling_verify on;
resolver 1.1.1.1 8.8.8.8 valid=300s;
resolver_timeout 5s;Después de configurarlo, verifica con SSL Labs que "OCSP stapling" aparece como "Yes".
Certificados optimizados: ECDSA vs RSA
Los certificados RSA 2048-bit son el estándar tradicional, pero los certificados ECDSA P-256 son significativamente más pequeños (lo que reduce el tiempo de transmisión) y el handshake es más rápido porque usa criptografía de curva elíptica.
| Tipo | Tamaño de clave | Velocidad de handshake | Compatibilidad |
|---|---|---|---|
| RSA 2048 | ~2 KB | Moderada | Universal |
| RSA 4096 | ~4 KB | Lenta | Universal |
| ECDSA P-256 | ~0.5 KB | Rápida | Todos los navegadores modernos |
Si tu hosting te permite elegir el tipo de certificado, opta por ECDSA P-256. Let's Encrypt lo soporta completamente. Si tu audiencia incluye dispositivos muy antiguos, mantén RSA como fallback con una configuración dual (si tu servidor lo permite).
HTTP/2 y HTTP/3: el complemento perfecto de TLS
TLS es un requisito para HTTP/2 y HTTP/3 — los navegadores solo los usan en conexiones HTTPS. Esto convierte al certificado en la puerta de entrada a estas mejoras de protocolo:
- HTTP/2 permite multiplexar múltiples peticiones sobre una sola conexión TCP, elimina el bloqueo de cabecera de línea y comprime las cabeceras HTTP.
- HTTP/3 (sobre QUIC) elimina los problemas de TCP con pérdida de paquetes y reduce aún más la latencia de handshake.
Si tu servidor ya tiene TLS activado, habilitar HTTP/2 suele ser una sola línea de configuración. En Apache:
Protocols h2 http/1.1En Nginx (requiere compilar con --with-http_v2_module, incluido por defecto en versiones recientes):
listen 443 ssl http2;Para verificar si tu sitio ya usa HTTP/2, abre DevTools, ve a la pestaña Network, añade la columna "Protocol" y recarga — deberías ver "h2" en las peticiones.
Un buen proveedor de hosting activa HTTP/2 por defecto en todos los planes. Si el tuyo no lo hace, puede que sea momento de evaluar opciones — un equipo especializado en rendimiento web puede orientarte sobre qué servidor y configuración conviene para tu caso.
Lista de verificación: TLS rápido y seguro
- TLS 1.3 habilitado (TLS 1.0 y 1.1 desactivados).
- OCSP Stapling activado y verificado en SSL Labs.
- Reutilización de sesiones configurada (session cache o tickets).
- Certificado ECDSA P-256 si tu CA lo soporta.
- HTTP/2 (o HTTP/3) habilitado en el servidor.
- Cadena de certificados completa y en el orden correcto (hoja → intermedios → raíz).
- HSTS activado para eliminar redirecciones HTTP→HTTPS.
Si quieres una auditoría completa de tu configuración TLS, contáctanos en elenlace.com — revisamos SSL Labs, optimizamos la configuración del servidor y verificamos que HTTP/2 esté activo.
Para más guías sobre optimización técnica, visita nuestro blog de rendimiento web.
Conclusiones clave
- SSL/TLS moderno (TLS 1.3) no ralentiza el sitio — el mito del HTTPS lento viene de configuraciones de 2010.
- TLS 1.3 reduce el handshake a 1 round-trip; con 0-RTT, las conexiones repetidas son gratuitas.
- OCSP Stapling elimina una petición externa por visita, reduciendo la latencia de conexión.
- Los certificados ECDSA P-256 son más pequeños y rápidos que RSA 2048 con seguridad equivalente.
- HTTP/2 (y HTTP/3) solo funcionan sobre HTTPS — activar TLS correctamente abre la puerta a ambos protocolos.
- La combinación TLS 1.3 + OCSP Stapling + HTTP/2 + HSTS es el estándar mínimo en 2026.
¿Tu sitio todavía usa TLS 1.2 sin OCSP Stapling y sin HTTP/2? El equipo de elenlace.com puede auditar y modernizar tu configuración TLS en una sola intervención.
Preguntas frecuentes
¿HTTPS es realmente más lento que HTTP?
Con TLS 1.3, HTTP/2 y las optimizaciones descritas en esta guía, la diferencia de velocidad es prácticamente imperceptible — menos de 10 ms en condiciones normales. En muchos casos, un sitio HTTPS con HTTP/2 es más rápido que uno HTTP/1.1 porque HTTP/2 permite multiplexar peticiones.
¿Cómo sé si mi servidor usa TLS 1.3?
Entra a ssllabs.com/ssltest, ingresa tu dominio y busca la sección "Protocol Support". Si TLS 1.3 aparece, está activo. También puedes ver la versión de protocolo en la pestaña Security de DevTools al cargar tu sitio.
¿Qué es OCSP Stapling y por qué importa?
OCSP Stapling hace que tu servidor adjunte la prueba de validez del certificado directamente en la respuesta TLS, evitando que el navegador consulte al emisor del certificado en cada visita. Elimina una petición DNS + HTTP adicional por conexión, mejorando la latencia de establecimiento.
¿Let's Encrypt es suficientemente rápido para sitios con mucho tráfico?
Sí. Let's Encrypt emite certificados DV estándar que funcionan exactamente igual que los certificados de pago en términos de velocidad TLS. La velocidad de conexión depende de la configuración del servidor (TLS 1.3, OCSP Stapling, HTTP/2), no del emisor del certificado.
Recursos útiles
Otros proveedores y guías que vale la pena comparar:
