¿Qué debo implementar primero: gzip o HTTP/3?

Si las respuestas de texto no están comprimidas, normalmente tiene más sentido comprobar primero la compresión de contenido, como gzip o Brotli. Si la compresión ya funciona correctamente, HTTP/3 puede aportar mejoras adicionales en redes con pérdida de paquetes o latencia y cuando hay muchas solicitudes simultáneas. Sin embargo, la prioridad real depende de si la imagen LCP, el CSS o JavaScript que bloquea el renderizado, o el TTFB constituyen el cuello de botella principal.

¿Sigo necesitando gzip si uso HTTP/3?

Sí. QPACK de HTTP/3 es un método de compresión para las cabeceras HTTP, mientras que gzip es una codificación de contenido que comprime cuerpos de respuesta como HTML, CSS, JavaScript y JSON. Operan en capas distintas y pueden utilizarse conjuntamente.

¿Aplicar gzip a las imágenes hará que carguen más rápido?

Por lo general, no. Los archivos que ya están comprimidos, como JPEG, WebP, AVIF, vídeo y audio, suelen obtener poco beneficio de volver a comprimirse con gzip y pueden añadir sobrecarga de procesamiento. Para el rendimiento de las imágenes, es más importante usar las dimensiones y el formato adecuados y priorizar las imágenes necesarias.

¿HTTP/3 siempre reduce el tiempo de carga para todos los usuarios?

No siempre. Mediante los flujos independientes de QUIC, HTTP/3 puede reducir hasta qué punto la pérdida de paquetes afecta a otros flujos, pero no resuelve directamente un procesamiento lento en el servidor, imágenes grandes, recursos que bloquean el renderizado ni el tiempo de ejecución de JavaScript. HTTP/2 y HTTP/3 deben medirse por separado en entornos de usuarios reales.

¿Puedo ofrecer solo Brotli en lugar de gzip?

La compatibilidad con Brotli está muy extendida en los navegadores modernos, pero los servidores deben inspeccionar la cabecera Accept-Encoding de la solicitud y elegir una codificación que el cliente pueda aceptar. En la práctica, es habitual ofrecer Brotli y mantener gzip como alternativa de compatibilidad.

¿Qué son gzip y HTTP/3, y qué deberías mejorar primero para el rendimiento de carga de páginas web?

Por 쉬었음.comPublicado 12 de septiembre de 2026

gzip es una forma de reducir la cantidad de datos que deben transmitirse mediante la compresión de los archivos de texto de una página web, mientras que HTTP/3 es un protocolo que modifica cómo se gestionan varias solicitudes y cómo se aborda la pérdida de paquetes al entregar HTTP sobre QUIC. Ambos pueden ayudar a cargar una página, pero no resuelven el mismo problema. En vez de preguntar «¿Qué es más rápido, gzip o HTTP/3?», es más preciso preguntarse primero dónde está el cuello de botella de la página actual: bytes transferidos, pérdida de red, respuesta del servidor, imágenes, renderizado o JavaScript.www.rfc-editor.org datatracker.ietf.org

Uno de los errores de concepto más frecuentes en la práctica es pensar que activar HTTP/3 hace automáticamente más rápido todo un sitio web. HTTP/3 puede ser una mejora fundamental importante, pero no sustituye las soluciones para una imagen excesivamente grande en la parte visible inicial, CSS o JavaScript que bloquean el renderizado, o una respuesta lenta del servidor. A la inversa, si un sitio no comprime en absoluto las respuestas de texto, activar gzip o Brotli puede reducir notablemente el volumen transferido con un cambio de configuración relativamente pequeño.web.dev developer.mozilla.org

¿Qué es exactamente gzip?

gzip es una codificación de contenido (Content-Encoding) ampliamente utilizada para HTTP. Un servidor comprime el HTML, CSS, JavaScript, JSON, SVG y contenido similar originales en formato gzip antes de enviarlos, y el navegador los descomprime y utiliza el contenido original. La especificación HTTP Semantics define gzip como una codificación de contenido que utiliza compresión de la familia LZ77 y un CRC de 32 bits.www.rfc-editor.org www.rfc-editor.org

El punto clave es que el tipo lógico del archivo no cambia. Por ejemplo, incluso cuando un servidor entrega app.js con gzip, el navegador termina ejecutando el mismo JavaScript. Lo que cambia es el número de bytes que viajan por la red. Cuando un archivo es más pequeño, tarda menos en descargarse con ancho de banda limitado y también puede reducir el uso de datos móviles del usuario.www.rfc-editor.org developer.chrome.com

¿Cómo eligen los navegadores y servidores un método de compresión?

Los navegadores utilizan la cabecera de solicitud Accept-Encoding para indicar qué formatos de compresión pueden decodificar. A partir de esa lista y sus prioridades, el servidor selecciona una representación adecuada y añade a la respuesta una cabecera como Content-Encoding: gzip o Content-Encoding: br. br significa Brotli.www.rfc-editor.org developer.mozilla.org

Si un servidor o CDN proporciona respuestas distintas para la misma URL según el método de compresión, es habitual enviar Vary: Accept-Encoding para que las cachés las distingan. De lo contrario, una representación comprimida almacenada para un cliente podría reutilizarse indebidamente para una solicitud con condiciones distintas.www.rfc-editor.org

El siguiente es un flujo conceptual:

El navegador declara formatos compatibles, como Accept-Encoding: br, gzip.
El servidor o CDN elige una de las versiones del archivo: Brotli, gzip o sin comprimir.
Identifica el formato seleccionado en Content-Encoding junto con el cuerpo de la respuesta.
El navegador descomprime la respuesta durante o después de recibirla y, después, continúa con el análisis de HTML, la aplicación de CSS y la ejecución de JavaScript.

gzip puede reducir el tiempo de transferencia en este proceso, pero no elimina el tiempo que el navegador dedica a analizar y ejecutar JavaScript. La compresión es una parte del rendimiento, no una solución para todas las fuentes de retraso.developer.chrome.com web.dev

¿Qué archivos se benefician de gzip?

gzip es especialmente adecuado para texto con muchas cadenas y estructuras repetidas. Los datos con mucha repetición, como etiquetas HTML, selectores CSS, identificadores y sintaxis de JavaScript, y nombres de campos JSON, pueden reducir mucho su tamaño de transferencia tras la compresión. Las recomendaciones generales de rendimiento web también aconsejan aplicar compresión a los recursos de texto y excluir los recursos que ya están comprimidos.developer.mozilla.org web.dev

Tipo de recurso	Evaluación general para gzip	Áreas prioritarias que examinar
HTML	Normalmente adecuado	Tiempo de respuesta del servidor, caché, tamaño del documento
CSS	Normalmente adecuado	Eliminar CSS sin usar, gestionar CSS crítico
JavaScript	Normalmente adecuado	División de código, eliminar código sin usar, tiempo de ejecución
Respuestas JSON y API	Normalmente adecuado	Diseño de respuestas, caché, eliminar campos innecesarios
SVG	Normalmente adecuado	Limpiar y simplificar los SVG
JPEG, WebP, AVIF	Normalmente inadecuado	Dimensiones de imagen, formato, entrega adaptativa
MP4 y audio	Normalmente inadecuado	Tasa de bits, streaming, carga diferida

Para formatos que ya realizan compresión por sí mismos, como JPEG, WebP, AVIF, vídeo, audio y archivos comprimidos, volver a aplicar gzip puede aportar poco beneficio. Lo mismo ocurre con los archivos pequeños. web.dev explica que los recursos inferiores a aproximadamente 1 KiB pueden comprimirse de forma ineficiente o no ofrecer ahorros significativos.developer.mozilla.org web.dev

Aquí es importante distinguir entre tamaño de transferencia y tamaño original. En el panel Network de las herramientas de desarrollo, puedes comparar el tamaño de descarga comprimido con el tamaño sin comprimir, y consultar la cabecera de respuesta Content-Encoding para verificar si realmente se aplicó compresión.developer.chrome.com

¿En qué se diferencian gzip y Brotli?

Brotli no es el sucesor de gzip; es otro algoritmo que se puede seleccionar junto a gzip para la compresión de contenido HTTP. En la web moderna, es habitual priorizar Brotli para los recursos de texto y ofrecer también gzip para los clientes que no pueden utilizar Brotli. Como los navegadores envían Accept-Encoding y los servidores negocian el resultado, pueden enviarse distintas representaciones comprimidas para la misma URL según el cliente.developer.mozilla.org developer.mozilla.org

Por lo general, Brotli puede producir resultados más pequeños que gzip para texto web. Sin embargo, eso no siempre significa una mejora proporcional de la velocidad percibida de la página en conjunto. Si los bytes ahorrados son pocos, o el cuello de botella son las imágenes, el procesamiento del servidor o la ejecución de JavaScript, cambiar de gzip a Brotli puede tener un efecto limitado. En servidores que comprimen dinámicamente, las configuraciones que aumentan la tasa de compresión también pueden aumentar el uso de CPU y la latencia de respuesta. Por tanto, los recursos estáticos deberían comprimirse previamente durante la fase de compilación o en la CDN, mientras que las respuestas dinámicas deben ajustarse según la carga real.web.dev web.dev

En otras palabras, los criterios de selección se acercan más a los siguientes que a «Brotli siempre es mejor»:

Si los recursos de texto son grandes y hay muchos visitantes por primera vez, considera servir tanto Brotli como gzip.
Si una CDN ya proporciona una compresión adecuada, no comprimas de nuevo el mismo contenido en la aplicación.
Para un servicio dinámico con CPU de servidor limitada, mide el equilibrio entre el nivel de compresión y el TTFB.
Si las imágenes y el vídeo representan una gran parte de la página, la optimización multimedia puede ir antes que la compresión de texto.

¿Qué cambia HTTP/3?

HTTP/3 es un estándar que conserva la semántica de solicitud-respuesta de HTTP mientras sustituye TCP por QUIC como base de transporte. QUIC funciona sobre UDP, pero no es simplemente una forma de enviar HTTP sobre UDP. Proporciona funciones como establecimiento de conexión, cifrado, fiabilidad, control de congestión y flujos multiplexados, y HTTP/3 utiliza estas funciones para entregar mensajes HTTP.datatracker.ietf.org developer.mozilla.org

HTTP/1.1 tenía limitaciones importantes para gestionar solicitudes mediante una única conexión, por lo que se extendió el uso de varias conexiones TCP en paralelo. HTTP/2 mejoró esto al multiplexar varias solicitudes en una conexión TCP. Sin embargo, como TCP garantiza la entrega ordenada de los datos recibidos, cuando se pierde un paquete en una conexión, los datos que llegan después no pueden entregarse ordenadamente a la aplicación hasta que se recupera esa pérdida. En HTTP/2, este retraso a nivel de TCP puede afectar a varios flujos HTTP.datatracker.ietf.org www.rfc-editor.org

QUIC de HTTP/3 gestiona una entrega fiable y ordenada por flujo. Como resultado, la pérdida de datos en un flujo no exige necesariamente que otros flujos no relacionados también se detengan. RFC 9000 explica que, cuando se pierde un paquete, solo los flujos que contienen datos de ese paquete quedan bloqueados a la espera de retransmisión, mientras que los demás pueden continuar.www.rfc-editor.org

¿Qué precisión tiene la expresión «elimina el bloqueo de cabecera de línea»?

Lo que HTTP/3 aborda principalmente es el bloqueo de cabecera de línea en la capa de transporte para toda la conexión. Es inexacto interpretar esto como si toda espera desapareciera.

En primer lugar, el orden sigue importando dentro de un mismo flujo. Si se pierde una parte anterior en el mismo flujo, como el cuerpo de un documento HTML o una imagen grande, los datos posteriores de ese flujo no pueden utilizarse completamente hasta que se restaure el orden necesario. En segundo lugar, si datos de varios flujos se incluyeron en un paquete QUIC, la pérdida de ese paquete puede retrasar varios de esos flujos a la vez.www.rfc-editor.org

Por tanto, los beneficios de HTTP/3 pueden ser especialmente evidentes en redes donde hay pérdida o reordenación de paquetes. En cambio, al visualizar una página pequeña en una conexión por cable, de baja latencia y baja pérdida, la diferencia con respecto a HTTP/2 puede ser pequeña o variar según las condiciones de medición. Esto se debe a que HTTP/3 no es una tecnología que reduzca mágicamente los bytes; es una arquitectura que reduce hasta qué punto se propaga la espera durante el transporte.datatracker.ietf.org www.rfc-editor.org

¿En qué se diferencia QPACK de HTTP/3 de gzip?

HTTP/3 incluye un mecanismo de compresión de cabeceras llamado QPACK. Esto puede hacer pensar erróneamente que HTTP/3 incluye gzip, pero se aplican a objetivos diferentes. QPACK está diseñado para representar de forma eficiente los campos de cabecera de las solicitudes y respuestas HTTP, como Cookie, Content-Type y Cache-Control. gzip y Brotli son codificaciones de contenido que comprimen los cuerpos de respuesta, como HTML, CSS y JavaScript.datatracker.ietf.org www.rfc-editor.org

HPACK de HTTP/2 se basa en la suposición de que el estado de compresión de cabeceras se entrega en secuencia, pero esta suposición es difícil de aplicar sin cambios a la arquitectura de flujos independientes de QUIC. QPACK utiliza flujos unidireccionales separados para gestionar el estado de la tabla dinámica, lo que permite a las implementaciones equilibrar la eficiencia de compresión frente al riesgo de bloqueo de cabeceras.datatracker.ietf.org datatracker.ietf.org

Desde la perspectiva del rendimiento real de una página, resulta útil entender sus funciones de este modo:

gzip y Brotli: reducen el volumen de transferencia de los cuerpos de texto.
QPACK: mejora la eficiencia de transmisión de las cabeceras de solicitud y respuesta.
HTTP/3 y QUIC: reducen hasta qué punto los retrasos de transporte causados por varias solicitudes y condiciones de pérdida se propagan a otras solicitudes.
Caché: evita volver a transferir recursos que ya se han recibido.
Optimización de imágenes y código: reduce la cantidad de trabajo que debe descargarse y procesarse desde el principio.

No son opciones excluyentes entre las que elegir; son enfoques complementarios para distintos cuellos de botella.

¿Cuáles son los mayores cuellos de botella en la velocidad percibida de una página web?

La velocidad de carga que perciben los usuarios no es un único número. El tiempo hasta que el servidor envía el primer byte, el tiempo hasta que se hace visible el contenido principal de la parte visible inicial y el tiempo hasta que los botones y las entradas responden pueden retrasarse por causas diferentes. En particular, LCP (Largest Contentful Paint) representa el momento en que se renderiza la imagen, bloque de texto o vídeo más grande de la ventana gráfica, por lo que resulta útil para evaluar la experiencia inicial de la página.web.dev

Un LCP lento no siempre significa que la causa sea la compresión de red. web.dev recomienda separar TTFB, retraso de carga del recurso, tiempo de carga del recurso y retraso de renderizado del elemento al diagnosticar LCP. Por ejemplo, aunque una imagen se descargue rápidamente, un CSS grande puede bloquear el renderizado, o el hilo principal puede estar demasiado ocupado con tareas largas de JavaScript para mostrar la imagen.web.dev

Cuando la imagen de la parte visible inicial es el cuello de botella

El elemento más grande de la parte visible inicial suele ser una imagen, como una foto grande de producto en una página de detalle, una imagen principal en la portada de un sitio de noticias o un banner en una página de viajes. En esta situación, activar gzip no ayuda mucho a los propios archivos JPEG, WebP o AVIF. Un enfoque más eficaz consiste en servir imágenes dimensionadas para su tamaño de visualización, usar formatos modernos adecuados y evitar retrasar la imagen LCP con loading="lazy". Cuando sea necesario, puedes proporcionar una pista de prioridad mediante fetchpriority="high", pero asignar alta prioridad indiscriminadamente a muchas imágenes puede crear competencia.web.dev web.dev

Cuando CSS y JavaScript son el cuello de botella

CSS tiene características de bloqueo del renderizado porque evita que el contenido aparezca sin estilos. Sin embargo, un CSS excesivamente grande, el CSS que no se necesita para la vista inicial y los scripts cargados de forma síncrona pueden retrasar la visualización del contenido principal. Incluso después de que termina la transferencia, los paquetes grandes de JavaScript usan el hilo principal del navegador para análisis, compilación y ejecución, por lo que reducir solo el tamaño de descarga con gzip puede no ser suficiente.developer.chrome.com web.dev

Por ello, el rendimiento de JavaScript debe examinarse por separado de la compresión. Entre las posibilidades están eliminar código sin usar, cargar de forma diferida funciones que no se necesitan para la vista inicial, dividir tareas largas y, cuando sea posible, utilizar renderizado en servidor o prerrenderizado para que el HTML inicial exponga el contenido y recursos principales para su descubrimiento. Sin embargo, el renderizado en servidor también puede aumentar el tiempo de procesamiento del servidor y afectar al TTFB, por lo que los cambios arquitectónicos deben evaluarse con mediciones.web.dev

Cuando la respuesta del servidor y la caché son el cuello de botella

Cuando el TTFB es largo, al navegador le resulta difícil descubrir recursos posteriores antes de recibir el HTML. Las causas frecuentes incluyen un servidor situado lejos, procesamiento prolongado de bases de datos y personalización, redirecciones innecesarias y oportunidades de caché no aprovechadas. HTTP/3 puede mejorar parte de la etapa de transferencia en esta situación, pero no reduce directamente el tiempo que necesita el servidor para generar la primera respuesta.web.dev

La caché es distinta por naturaleza de otras mejoras de rendimiento. gzip envía los mismos datos en una forma más pequeña, HTTP/3 cambia las características de conexión utilizadas para entregar datos y la caché evita que los datos se envíen de nuevo en visitas repetidas que cumplen las condiciones. Para un servicio con una alta proporción de visitantes recurrentes, una política de caché adecuada puede producir una diferencia percibida mayor que cambiar los algoritmos de compresión. Sin embargo, las estrategias de caché para respuestas que cambian con frecuencia o varían según el usuario, como HTML, deben diseñarse con más cuidado.www.rfc-editor.org developer.chrome.com

¿Cuál es el orden práctico de las mejoras de rendimiento por impacto percibido?

No existe un orden fijo que se aplique a todos los sitios. Los resultados difieren según la composición de la página, la proporción de visitantes nuevos y recurrentes, las redes de los usuarios, las ubicaciones de los servidores y la configuración existente. Aun así, para las páginas típicas de contenido, comercio y servicios donde persisten cuellos de botella importantes, el siguiente orden es práctico para investigar.

Encuentra qué retrasa el contenido principal de la parte visible inicial. Examina primero el tamaño, el momento de descubrimiento y la prioridad de la imagen LCP; el CSS que bloquea el renderizado; el JavaScript síncrono; y el renderizado innecesario del lado cliente.web.dev
Revisa el tiempo de respuesta del servidor y la caché. Comprueba TTFB, redirecciones, ubicación de la CDN, caché de recursos estáticos y retrasos de procesamiento en el backend.web.dev www.rfc-editor.org
Comprueba la compresión de texto para HTML, CSS, JavaScript y JSON. Si no están comprimidos, aplicar gzip o Brotli es una prioridad alta. Si ya están correctamente comprimidos, las ganancias adicionales en la misma área pueden ser limitadas.developer.mozilla.org developer.chrome.com
Reduce el volumen total de transferencia y optimiza la composición de solicitudes. Optimiza imágenes, scripts y recursos de terceros grandes, y retrasa las solicitudes hasta que realmente se necesiten. Las cargas útiles de red grandes se asocian con tiempos de carga prolongados.developer.chrome.com developer.chrome.com
Ofrece HTTP/3, conserva una alternativa HTTP/2 y valídalo con tráfico real. Compara los resultados antes y después, especialmente en entornos móviles con alta latencia o pérdida de paquetes y en páginas con muchas solicitudes simultáneas.datatracker.ietf.org www.rfc-editor.org

Este orden tiene excepciones importantes. Si una aplicación tiene respuestas de texto sin comprimir de más de 1 MB, aplicar gzip o Brotli en el paso 3 puede ser la mayor mejora a corto plazo. A la inversa, si una imagen principal ocupa varios MB y el texto ya está comprimido con Brotli, la optimización de imágenes tiene prioridad. Si el servidor no puede generar HTML durante varios segundos, el trabajo en backend y caché va antes que HTTP/3.developer.mozilla.org web.dev developer.chrome.com

Si solo comparas gzip y HTTP/3

Si debes elegir solo entre estas dos tecnologías, la decisión es relativamente sencilla.

Cuando el texto no está comprimido: gzip o Brotli suele ser lo primero. Reduce la cantidad de datos que hay que transmitir, por lo que se pueden esperar beneficios en toda conexión compatible.
Cuando la compresión ya funciona correctamente: aumenta el valor relativo de HTTP/3. Sin embargo, la mejora real depende de la calidad de red y de la estructura de solicitudes.
Para páginas con muchas imágenes y vídeo: ni gzip ni HTTP/3 por sí solos probablemente resolverán el problema mayor. La optimización multimedia va primero.
Para aplicaciones JavaScript grandes: gzip es solo un punto de partida. También debes examinar los costes de ejecución posteriores a la transferencia para lograr una mejora percibida sostenida.
Para servicios con muchas visitas recurrentes: las tasas de aciertos de caché pueden ser una variable mayor que cambiar los métodos de compresión.

Por tanto, ninguna de estas conclusiones es precisa: «gzip siempre está por delante de HTTP/3» o «HTTP/3 es más nuevo, así que siempre está por delante». Una afirmación más precisa es: la compresión de contenido es la prioridad básica para texto sin comprimir, mientras que HTTP/3 es una optimización fundamental que puede aportar beneficios adicionales según las condiciones de transporte y los patrones de solicitud.

¿Qué limitaciones debes tener en cuenta al adoptar HTTP/3?

Para ofrecer HTTP/3, los servidores, CDN, balanceadores de carga, cortafuegos y herramientas de observabilidad deben poder gestionar adecuadamente el tráfico basado en QUIC y UDP. Puesto que algunos clientes o rutas podrían no poder utilizar HTTP/3, normalmente resulta apropiado un despliegue gradual que también ofrezca HTTP/2 o HTTP/1.1. El estándar HTTP/3 se basa en QUIC y define el proceso mediante el cual un cliente descubre un servidor HTTP/3 y después establece una conexión QUIC.datatracker.ietf.org

Desde una perspectiva operativa, es importante no evaluar el éxito solo a partir de un cambio de protocolo. Supervisa conjuntamente la proporción de conexiones HTTP/3, las tasas de fallos y reintentos, TTFB, LCP, las tasas de error y el uso de CPU. En particular, cuando una CDN o proxy se sitúa delante del origen, el protocolo visible en el servidor de origen puede diferir del que utilizó realmente el navegador del usuario final, por lo que también debe incluirse la observación del lado cliente.developer.chrome.com developer.chrome.com

¿Hay consideraciones de seguridad para la compresión?

Sí. Incluso con HTTPS, si una entrada controlada por un atacante y valores secretos se comprimen juntos en el mismo contexto de compresión, un atacante puede ser capaz de inferir el secreto observando diferencias en la longitud del texto cifrado. Las especificaciones HTTP Semantics y HTTP/3 advierten sobre situaciones donde datos sensibles y datos controlados por un atacante se comprimen juntos, e identifican desactivar la compresión para datos sensibles o separar los contextos de compresión como las mitigaciones más fiables.www.rfc-editor.org www.rfc-editor.org

Esto no significa que toda respuesta gzip sea peligrosa. La cuestión clave es si existen al mismo tiempo una entrada de usuario reflejada, secretos relacionados con la autenticación y condiciones que permitan a un atacante realizar solicitudes repetidas y observar tamaños de respuesta. Los flujos sensibles, como inicio de sesión, pagos y recuperación de cuentas, no deberían recibir mecánicamente las mismas políticas de compresión que los recursos estáticos generales; deben revisarse junto con el diseño de seguridad.www.rfc-editor.org datatracker.ietf.org

¿Qué debo medir en mi sitio?

Es más seguro validar las mejoras de rendimiento mediante la experiencia de usuarios reales que con una única puntuación de laboratorio. Lighthouse es útil para identificar rápidamente posibles problemas, pero no representa a todos los usuarios reales en redes, dispositivos, estados de caché y regiones diversos. Usar las herramientas de desarrollo junto con la monitorización de usuarios reales facilita separar las hipótesis de los resultados.developer.chrome.com developer.chrome.com

Puedes revisar el rendimiento en el siguiente orden:

Comprueba el estado actual de transferencia. En el panel Network, revisa Content-Encoding, el tamaño de transferencia y el tamaño original de las respuestas clave de HTML, CSS, JS y JSON.developer.chrome.com
Comprueba el protocolo. En la columna Protocol, confirma si las solicitudes reales utilizan h3, h2 o http/1.1.
Segmenta las métricas de usuario clave. Compara TTFB, LCP y métricas de interacción por visita nueva frente a recurrente, móvil frente a escritorio, región y tipo de red.web.dev web.dev
Cambia una cosa cada vez. Si despliegas al mismo tiempo la activación de gzip, el soporte de Brotli, sustituciones de imágenes, división de JavaScript y la activación de HTTP/3, es difícil identificar qué cambio produjo un efecto.
Registra también los efectos secundarios. Supervisa asimismo la CPU del servidor, las tasas de error, las tasas de aciertos de caché y las tasas de fallo o alternativa de conexión HTTP/3.

Por ejemplo, si cambiar un paquete JavaScript sin comprimir a gzip reduce el tamaño de transferencia pero apenas modifica el LCP, es probable que el siguiente cuello de botella sea una imagen grande, CSS o la ejecución de JavaScript, en vez de la compresión. A la inversa, si la cola larga de LCP mejora para usuarios de redes móviles después de adoptar HTTP/3, puedes identificar beneficios en entornos con alta pérdida y latencia, además de examinar los promedios. Estas conclusiones parten de cuellos de botella medidos, no del nombre de una tecnología.web.dev www.rfc-editor.org

Resumen: considera gzip y HTTP/3 funciones complementarias, no una competición de clasificación

gzip y HTTP/3 son ambos útiles para el rendimiento web, pero la base para compararlos es distinta. gzip reduce los bytes transferidos de las respuestas de texto, mientras que HTTP/3 puede reducir el impacto que la pérdida de red tiene sobre varias solicitudes mediante flujos multiplexados basados en QUIC. QPACK de HTTP/3 es compresión de cabeceras; no sustituye la compresión del cuerpo gestionada por gzip y Brotli.www.rfc-editor.org datatracker.ietf.org datatracker.ietf.org

La prioridad más práctica es identificar primero el cuello de botella real entre LCP, TTFB, bloqueo de renderizado, JavaScript, imágenes y caché; implementar la compresión de texto como referencia básica si falta; y luego validar HTTP/3 en condiciones de usuarios reales. El rendimiento no consiste en añadir una tecnología reciente: consiste en acortar el camino más largo que el usuario debe esperar.web.dev developer.chrome.com

Lecturas adicionales

Especificaciones de HTTP Semantics y codificación de contenidowww.rfc-editor.org
Estándar HTTP/3datatracker.ietf.org
Estándar de compresión de cabeceras QPACKdatatracker.ietf.org
Especificación de transporte QUICwww.rfc-editor.org
Guía de rendimiento web y optimización de LCPweb.dev
Resumen de la compresión HTTPdeveloper.mozilla.org