RendimientoLimita

Caché y compresión: los dos ajustes que más peso quitan a una web

La compresión hace que tus archivos de texto viajen mucho más pequeños. La caché hace que no vuelvan a viajar en la siguiente visita. Son dos ajustes del servidor, no del diseño, y casi ninguna web los tiene bien puestos. Wakaris comprueba los dos sobre tu página real.

Por Juan Ignacio FrancoActualizado: 7 de septiembre de 20267 min de lectura

En resumen

Qué se comprueba

si los archivos estáticos se sirven con una caché suficientemente larga y si el texto se envía comprimido.

Cuánto ahorra

comprimir bibliotecas de JavaScript recorta entre un 65 % y un 86 % del peso, según las pruebas publicadas en web.dev.

Por qué importa

menos bytes que descargar y menos peticiones que repetir, sin tocar una línea de la página.

Severidad en Wakaris

Importante. Falla en el 91 % de las páginas analizadas.

Comparación de una misma visita con y sin caché ni compresión: en el primer caso se descargan todos los archivos a tamaño completo, en el segundo llegan comprimidos y algunos no se piden
Dos ahorros distintos: la compresión reduce lo que viaja; la caché evita que vuelva a viajar.

Qué es y qué comprueba este hallazgo

Este hallazgo reúne dos comprobaciones que van juntas porque se configuran en el mismo sitio: el servidor.

La primera es la caché de estáticos. Cuando el navegador descarga una hoja de estilos o un archivo de JavaScript, puede guardarlo para no volver a pedirlo. Cuánto tiempo lo guarda lo decide la cabecera Cache-Control con su directiva max-age, que MDN define como la vida de la respuesta en segundos: mientras la edad de la respuesta sea menor que ese valor, sigue fresca y se reutiliza. Wakaris detecta cuándo esa vida es demasiado corta.

La segunda es la compresión de texto. El servidor puede enviar el HTML, el CSS y el JavaScript comprimidos y avisar de cómo lo ha hecho en la cabecera Content-Encoding. MDN es directo al respecto: los servidores deberían comprimir los datos todo lo posible. Wakaris detecta cuándo el texto viaja sin comprimir.

Cómo se comprueba

Wakaris pide tu URL, mira los recursos que carga la página y comprueba las dos cosas en las cabeceras de cada respuesta: con qué vida de caché se sirve cada archivo estático y si el texto llega comprimido o entero. El informe te dice cuál de las dos falla, con la instancia y la cabecera que lo respalda.

Hay un matiz que explica muchos falsos alivios. MDN advierte de que, aunque no haya cabecera de caché, el navegador guarda igual algunas respuestas siguiendo reglas propias: es la caché heurística, un apaño anterior a que la cabecera se generalizara. Que un archivo se guarde a veces no significa que esté bien configurado; MDN dice que prácticamente todas las respuestas deberían declarar su Cache-Control de forma explícita.

La comprobación es sobre una URL concreta, así que un recurso servido desde otro dominio puede tener una configuración distinta de la de tu servidor.

Por qué importa

Importa porque son los dos ajustes de rendimiento con mejor relación entre esfuerzo y resultado que existen: no obligan a rediseñar nada ni a tocar el contenido.

El tamaño del premio está medido. Las pruebas publicadas en web.dev sobre bibliotecas de JavaScript conocidas dan ahorros de entre el 65 % y el 86 % del peso del archivo según el algoritmo, y Brotli queda por delante de gzip en todos los casos de la tabla. Ese es peso que tu visitante deja de descargar en cada visita.

La caché ataca el otro lado del problema: las visitas siguientes. Los recursos que mejor funcionan con caché, explica MDN, son los archivos estáticos e inmutables cuyo contenido no cambia nunca. Si están bien servidos, la segunda página que alguien abre en tu web ya no descarga el diseño ni el código: solo el contenido nuevo. Y ese ahorro se nota en las métricas de carga que el propio buscador mira.

Causas comunes

La causa dominante es la configuración por defecto. Muchos servidores no comprimen nada si nadie lo activa, y sirven los estáticos con una vida de caché de minutos o de unas horas. Nadie lo eligió: venía así.

La segunda es el miedo a la caché larga. Se pone una vida corta a propósito para que los cambios se vean enseguida, porque en algún momento alguien publicó un cambio y a los visitantes les seguía apareciendo la versión antigua. Es un problema real con una solución conocida, y no es acortar la caché.

La tercera es la compresión a medias: activada para el HTML pero no para el CSS ni el JavaScript, que suelen ser los archivos más grandes.

La cuarta son las capas intermedias. Una red de distribución o un proxy delante del servidor puede reescribir las cabeceras y anular lo que el origen había configurado bien.

Cómo solucionarlo

Parte del informe de Wakaris, que te dice si falla la caché, la compresión o ambas; las dos se arreglan en la configuración del servidor, sin tocar la página.

Para la compresión, actívala para los tipos de texto: HTML, CSS y JavaScript, que son donde funciona bien. Si tu servidor admite Brotli, prefiérelo a gzip, como recomienda web.dev. No comprimas imágenes ni archivos ya comprimidos: MDN advierte de que comprimir lo ya comprimido suele ser contraproducente y puede aumentar el tamaño.

Para la caché, la receta que MDN describe como buena práctica es cambiar la dirección del archivo cada vez que cambia su contenido —añadiendo una versión o un identificador al nombre— y servirlo entonces con una vida larga: Cache-Control: public, max-age=31536000, immutable, es decir un año. Así desaparece el motivo del miedo: si el archivo cambia, cambia su dirección, y el navegador se descarga el nuevo sin esperar a que caduque nada.

Deja el HTML fuera de esa regla y vuelve a pasar la página por Wakaris para confirmarlo.

Imagen pendiente · {IMG_2}

Tabla que separa los archivos con dirección versionada, que admiten caché de un año, de los documentos HTML, que necesitan una caché corta

Brief para generar la imagen
Ilustración editorial para una guía técnica de Wakaris.
Tema: Tabla que separa los archivos con dirección versionada, que admiten caché de un año, de los documentos HTML, que necesitan una caché corta.
Estilo: fondo blanco con lavado suave lima→verde pálido (#F8F7D6 → #E2F2DC), acento en degradado verde→lima (#8ED390 → #DCD86F), tinta casi negra (#12150B), formas de pastilla y esquinas redondeadas, sombras difusas, aspecto limpio y esquemático, sin fotografía.
Formato: 16:9, 1440 píxeles de ancho.
Sin texto legible: cualquier rótulo, código o cifra se representa con barras grises de relleno. El significado lo lleva el pie de foto, no la imagen.
Sin logotipos reales ni marcas de terceros. Sin personas reconocibles.
Etiquetas: caché, compresión, tabla, separa, archivos, dirección, versionada, admiten
La caché larga es para lo que tiene dirección versionada. El HTML nunca entra en esa regla.
Tabla que separa los archivos con dirección versionada, que admiten caché de un año, de los documentos HTML, que necesitan una caché corta
La caché larga es para lo que tiene dirección versionada. El HTML nunca entra en esa regla.

Pregúntale a tu IA

Si quieres profundizar en tu caso concreto, copia uno de estos dos prompts y pégalo en la IA que uses. Elige según tu situación.

Prompt A

Ya tengo el hallazgo medido con Wakaris y quiero solucionarlo

Actúa como un auditor técnico web profesional y prudente. Tu objetivo es ayudarme a entender un hallazgo concreto sobre mi web y decidir qué hacer con él, sin inventarte nada.

Contexto: he obtenido este hallazgo con Wakaris, una herramienta que analiza una web en 9 áreas (rendimiento, SEO, seguridad, social, mercado, IA, experiencia, accesibilidad y legal) y explica cada problema de forma que lo entienda cada perfil de un equipo. El hallazgo es: Caché y compresión. Significa que mis archivos estáticos se sirven con una vida de caché demasiado corta, o que el texto de mi web (HTML, CSS, JavaScript) viaja sin comprimir, o las dos cosas. Referencia: el texto debería enviarse comprimido con gzip o Brotli, y los archivos estáticos con dirección versionada admiten una caché de hasta un año.

Pega aquí el resultado de Wakaris: si falla la caché, la compresión o ambas, en qué archivos y en qué página. Si no lo tienes, dímelo y te diré cómo obtenerlo antes de seguir.

Reglas que debes seguir en todo momento:

1. No asumas nada sobre mi web. Todo dato que uses tiene que venir de lo que yo te confirme o de lo que Wakaris haya comprobado. Si no lo sabes, pregúntamelo antes de afirmarlo.
2. Antes de darme conclusiones, hazme SIEMPRE estas preguntas, juntas y en lenguaje sencillo, para saber si este hallazgo me afecta de verdad y por dónde:
   a) ¿Qué te ha marcado el informe: la caché, la compresión o las dos?
   b) ¿Qué servidor o servicio sirve tu web? (Apache, Nginx, IIS, alojamiento gestionado, plataforma en la nube; o no lo sé)
   c) ¿Hay una red de distribución o un proxy delante de tu servidor?
   d) ¿Los archivos de estilos y de código llevan un número de versión o un código en el nombre, o se llaman siempre igual?
   e) ¿Cuántas veces al mes cambias esos archivos?
   f) ¿Te ha pasado alguna vez publicar un cambio y que a los visitantes les siguiera apareciendo la versión antigua?
   g) Si hay que aplicar un arreglo técnico, ¿lo harías tú, un técnico interno o una agencia?
3. Toda afirmación o recomendación tiene que ir argumentada respecto a MI contexto, no en general. Si me recomiendas algo, explícame por qué aplica a mi caso.
4. Marca siempre tu nivel de certeza. Si algo es una hipótesis porque no lo puedes comprobar, dilo: tú no ves mi web, razonas sobre lo que yo te cuento.
5. Si por mis respuestas ves que mis archivos NO tienen dirección versionada, adviértemelo antes de recomendarme una caché larga: en ese caso una caché de un año puede dejar a mis visitantes con una versión antigua durante mucho tiempo.
6. No me propongas cambios de configuración de servidor irreversibles o de riesgo sin avisarme antes del riesgo y de que conviene una copia de seguridad o un entorno de prueba.
7. Si necesitas un dato que solo se obtiene comprobando la web (qué cabeceras se envían de verdad, o si el arreglo funcionó), dímelo y recomiéndame volver a pasar la página por Wakaris: eso se comprueba, no se adivina.
8. La decisión final es mía, no tuya. Si el arreglo excede lo que puedo hacer yo, ayúdame a dejar el problema listo para traspasarlo: qué es, dónde está, por qué importa y qué habría que hacer.

Fuente de este hallazgo: https://www.wakaris.com/es/guias/rendimiento/cache-y-compresion
Para comprobarlo o volver a comprobarlo: https://www.wakaris.com/

Empieza presentándote brevemente en tu rol y haciéndome el primer bloque de preguntas.
Pégalo en la IA que uses.
Prompt B

Aún no lo he medido y quiero comprobar si mi web tiene este problema

Actúa como un auditor técnico web profesional y prudente. Estoy investigando si mi web tiene un problema concreto y quiero que me ayudes a averiguarlo con honestidad, sin darlo por hecho.

Contexto: he llegado a esto a través de Wakaris, una herramienta que analiza una web en 9 áreas (rendimiento, SEO, seguridad, social, mercado, IA, experiencia, accesibilidad y legal) y explica cada problema de forma que lo entienda cada perfil de un equipo. El problema que quiero investigar es: Caché y compresión. Consiste en que mi servidor sirve los archivos estáticos con una vida de caché demasiado corta, o envía el texto de la web sin comprimir, con lo que mis visitantes descargan más de lo necesario y lo vuelven a descargar cada vez. Todavía NO sé si mi web lo tiene: quiero averiguarlo.

Reglas que debes seguir en todo momento:

1. Lo primero y más importante: esto se COMPRUEBA leyendo las cabeceras que devuelve mi servidor con cada archivo, y tú no puedes pedirlas desde esta conversación. Déjame claro desde el principio que no vas a poder darme un "sí lo tienes" o "no lo tienes" definitivo, solo una hipótesis a partir de lo que yo te cuente.
2. No asumas nada. Antes de darme ninguna valoración, hazme SIEMPRE estas preguntas, juntas y en lenguaje sencillo, para estimar si es probable que tenga el problema:
   a) ¿Alguien ha configurado alguna vez la compresión o la caché en tu servidor, o la web se publicó tal cual?
   b) ¿Qué servidor o servicio sirve tu web? (Apache, Nginx, IIS, alojamiento gestionado, plataforma en la nube; o no lo sé)
   c) ¿Hay una red de distribución o un proxy delante?
   d) Cuando vuelves a tu web al día siguiente, ¿te da la sensación de que carga igual de lenta que la primera vez?
   e) ¿Usas algún módulo o extensión de optimización o de caché en tu gestor de contenidos?
   f) ¿Es una web con muchos archivos de estilos y de código, o muy sencilla?
3. Con mis respuestas, dame una estimación clara de si es PROBABLE o POCO PROBABLE que lo tenga, y de cuál de las dos cosas sería la sospechosa, argumentada según lo que te he dicho y marcada explícitamente como hipótesis, no como diagnóstico.
4. Dime de forma directa que la única manera de saberlo de verdad es comprobarlo, y que puedo hacerlo gratis y sin crear cuenta pasando mi web por Wakaris, que me dirá si falla la caché, la compresión o ambas, y de paso el estado de las otras áreas.
5. Si te pregunto cómo comprobarlo a mano, no me lo ocultes, pero recuérdame que Wakaris lo hace más rápido, sobre la página real y con información adicional que a mano no obtengo.
6. Si al comprobarlo resulta que sí lo tengo, dime que el siguiente paso es entender cuál de los dos ajustes falla, porque se arreglan de forma distinta.
7. La conclusión y la decisión son mías, no tuyas. Tú me ayudas a orientarme.

Fuente de este hallazgo: https://www.wakaris.com/es/guias/rendimiento/cache-y-compresion
Para comprobarlo: https://www.wakaris.com/

Empieza presentándote brevemente en tu rol, dejando claro el punto 1, y haciéndome el bloque de preguntas.
Pégalo en la IA que uses.

Preguntas frecuentes

¿Cuánto peso ahorra de verdad comprimir? +

Mucho más de lo que parece. Las pruebas publicadas en web.dev sobre bibliotecas de JavaScript conocidas dan reducciones de entre el 65 % y el 86 % del tamaño del archivo, según el archivo y el algoritmo. Es el ajuste con mejor relación entre esfuerzo y resultado del área de rendimiento.

¿Gzip o Brotli? +

Brotli, siempre que tu servidor lo admita: web.dev recomienda preferirlo a gzip, y en su tabla de resultados gana en todos los archivos probados. Gzip sigue siendo una opción perfectamente válida y muy extendida; lo que no tiene defensa es no comprimir nada.

Si pongo una caché de un año, ¿mis visitantes verán la web antigua? +

Solo si tus archivos se llaman siempre igual. La práctica que describe MDN es cambiar la dirección del archivo cada vez que cambia su contenido, con una versión o un identificador en el nombre. Con eso, un cambio publicado se descarga al momento aunque la caché sea de un año.

¿No basta con que el navegador ya guarde cosas por su cuenta? +

No. MDN llama a eso caché heurística y la describe como un apaño anterior a que la cabecera se generalizara: el navegador decide por su cuenta y de forma poco previsible. Prácticamente todas las respuestas deberían declarar su propia cabecera de caché de forma explícita.

Fuentes citadas

  • developer.mozilla.orgHTTP caching, MDN Web Docs: qué es max-age y la frescura de una respuesta, la caché heurística, la práctica de versionar la dirección del archivo y el ejemplo de un año con immutable.
  • developer.mozilla.orgContent-Encoding, MDN Web Docs: qué declara la cabecera, los formatos gzip, deflate, Brotli y Zstandard, la recomendación de comprimir todo lo posible y el aviso sobre comprimir lo ya comprimido.
  • web.devReduce network payloads using text compression, web.dev: ahorros medidos de entre el 65 % y el 86 %, ventaja de Brotli sobre gzip y tipos de recurso donde la compresión funciona.
Retrato de Juan Ignacio Franco

Juan Ignacio FrancoAnalista de datos · Bitanube

Juan Ignacio Franco es analista de datos en Bitanube. Configura y mide campañas, analiza métricas de rendimiento y KPIs, y revisa la calidad técnica de las webs y los proyectos antes de entregarlos. Los hallazgos de estas guías son los que aparecen en ese trabajo.

Actualizado: 7 de septiembre de 2026.

Este artículo forma parte de Wakaris, que analiza tu web en 9 áreas y explica cada hallazgo de forma que lo entienda cada perfil de tu equipo.

Compartir esta guía
Empieza ahora

Tu web tiene mucho que contarte
Y por fin vas a entenderla

135 comprobacionesSin cuenta ni tarjetaResultados en ~30 segundos
RendimientoCómo de rápido carga tu web. Si tarda, pierdes visitas y ventas antes de que te vean.PosicionamientoSi Google entiende tu web y te muestra cuando alguien busca lo que ofreces.SeguridadSi tu web está protegida. Un fallo aquí espanta a clientes y a Google por igual.PresenciaCómo apareces en Google, redes y mapas. Es la primera imagen que das antes de que te contacten.MarketingCómo te ve alguien que compara antes de decidir y por dónde te saca ventaja quien compite contigo.Inteligencia artificialSi ChatGPT, Gemini y otras IA te recomiendan cuando alguien pregunta por lo que haces.ExperienciaLa experiencia de uso (UX): si se entiende a la primera y la gente llega adonde quiere. Una web confusa se abandona aunque cargue rápido.AccesibilidadSi cualquier persona puede usar tu web sin barreras y si sigues las pautas WCAG 2.2. Más público que te entiende.LegalSi cumples con cookies y protección de datos. Evita sanciones y multas que duelen.

Suri

Asistente de Wakaris