Rendimiento y mantenimiento

Cómo configurar la caché del servidor web y evitar errores

Configurar la caché del servidor correctamente reduce la carga del servidor y acelera cada página, pero hacerlo mal puede servir contenido desactualizado a tus visitantes.

Close-up of a digital interface showcasing futuristic graphs and data analytics in low light.

Configurar la caché del servidor web correctamente significa que las páginas que tus visitantes ya cargaron se sirven al instante desde memoria o disco, sin que el servidor tenga que procesar PHP ni consultar la base de datos de nuevo. El resultado es menor tiempo de carga, menos carga en el servidor y una mejor experiencia para el usuario.

Tipos de caché que intervienen en un servidor web

Antes de tocar ninguna configuración conviene entender qué capa de caché estás modificando, porque cada una tiene un propósito distinto.

Tipo Dónde vive Qué almacena
Caché de página completa Servidor (disco o RAM) HTML generado por PHP/CMS
Caché de opcode (OPcache) PHP en el servidor Scripts PHP compilados
Caché de objetos (Redis/Memcached) Servidor (RAM) Resultados de consultas DB
Caché del navegador Dispositivo del usuario Imágenes, CSS, JS, fuentes
Caché CDN Servidores perimetrales Recursos estáticos y páginas

Esta guía cubre principalmente la caché del navegador (controlada desde el servidor mediante headers HTTP) y la caché de página completa con Apache, que son las dos configuraciones más frecuentes en alojamientos compartidos y VPS.

Configurar la caché del navegador con headers HTTP

El servidor le indica al navegador cuánto tiempo puede guardar un recurso enviando el header Cache-Control. Si el navegador ya tiene el archivo y este no ha expirado, no hace ninguna petición nueva.

En Apache con .htaccess

El método más común en hosting compartido y cPanel es editar el archivo .htaccess en la raíz del sitio:

<IfModule mod_expires.c>
  ExpiresActive On

  # Imágenes: 1 año
  ExpiresByType image/webp "access plus 1 year"
  ExpiresByType image/jpeg "access plus 1 year"
  ExpiresByType image/png  "access plus 1 year"
  ExpiresByType image/svg+xml "access plus 1 year"

  # CSS y JavaScript: 1 mes
  ExpiresByType text/css                "access plus 1 month"
  ExpiresByType application/javascript  "access plus 1 month"

  # Fuentes web: 1 año
  ExpiresByType font/woff2  "access plus 1 year"
  ExpiresByType font/woff   "access plus 1 year"

  # HTML: sin caché (contenido dinámico)
  ExpiresByType text/html "access plus 0 seconds"
</IfModule>

<IfModule mod_headers.c>
  # Asegura que imágenes y estáticos usen Cache-Control
  <FilesMatch "\.(jpg|jpeg|png|gif|webp|svg|ico|css|js|woff2|woff)$">
    Header append Cache-Control "public, immutable"
  </FilesMatch>
</IfModule>

Con este bloque, los recursos estáticos se almacenan en el navegador del visitante hasta un año. La próxima vez que visite el sitio, se cargarán instantáneamente desde el caché local.

En Nginx

Si tienes acceso al archivo de configuración del servidor (VPS o dedicado), el equivalente en Nginx es:

location ~* \.(jpg|jpeg|png|gif|webp|svg|ico|css|js|woff2|woff)$ {
    expires 1y;
    add_header Cache-Control "public, immutable";
}

location ~* \.html$ {
    expires -1;
    add_header Cache-Control "no-store, no-cache, must-revalidate";
}

Caché de página completa en Apache con mod_cache

La caché del navegador solo ayuda en visitas repetidas. Para acelerar la primera visita y reducir la carga del servidor, se configura una caché de página completa que sirve el HTML ya generado sin pasar por PHP.

Habilitar mod_cache en Apache

En servidores donde tienes acceso a la configuración de Apache (VPS con cPanel o servidor dedicado), los módulos necesarios son mod_cache y mod_cache_disk.

# En el VirtualHost o httpd.conf
CacheEnable disk /
CacheRoot /var/cache/apache2/mod_cache_disk
CacheDirLevels 2
CacheDirLength 1
CacheDefaultExpire 3600
CacheMaxExpire 86400
CacheLastModifiedFactor 0.5

En hosting compartido no tendrás acceso a esta configuración. La alternativa práctica es usar un plugin de caché para tu CMS (WP Rocket, LiteSpeed Cache o W3 Total Cache en WordPress) que genera los archivos HTML estáticos y los sirve directamente con reglas en .htaccess.

OPcache: la caché PHP que a menudo se olvida

PHP compila cada script en bytecode cada vez que recibe una petición. OPcache guarda ese bytecode en memoria, eliminando la compilación repetida. En un WordPress con tráfico medio puede reducir el tiempo de respuesta del servidor un 30–50%.

Verifica si está activo con phpinfo() (busca la sección Zend OPcache). Si no está activo, pídelo a tu proveedor de hosting o, en VPS, edita php.ini:

opcache.enable=1
opcache.memory_consumption=128
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=10000
opcache.revalidate_freq=2
opcache.fast_shutdown=1

Errores comunes al configurar la caché

Una caché mal configurada puede causar más problemas que no tener caché en absoluto. Estos son los errores más frecuentes:

Cachear páginas de usuario autenticado

El carrito de compras, el panel de usuario o cualquier página con contenido personalizado nunca debe cachearse. Asegúrate de que tu configuración excluya las cookies de sesión:

CacheIgnoreHeaders Set-Cookie

Y en WordPress, la mayoría de plugins de caché excluyen automáticamente a usuarios logueados — verifica que esa opción esté activada.

No usar cache busting en recursos estáticos

Si actualizas tu CSS o JS pero el nombre del archivo no cambia, los navegadores sirven la versión en caché durante meses. La solución es añadir un query string o cambiar el nombre del archivo al desplegar: style.css?v=1.4.2 o style.1.4.2.css.

Cachear respuestas de error

Los errores 404, 500 y redirecciones temporales (302) no deben cachearse. Agrega esto a tu configuración:

CacheDisable /error-page
<IfModule mod_headers.c>
  Header always set Cache-Control "no-store" "expr=%{REQUEST_STATUS} == 404 || %{REQUEST_STATUS} == 500"
</IfModule>

TTL demasiado corto en recursos estáticos

Poner 1 hora a imágenes y CSS es casi tan malo como no cachear: el navegador tiene que verificar el archivo en cada visita. Usa 1 mes o 1 año en recursos estáticos y resuelve las actualizaciones con cache busting.

Si no tienes tiempo para gestionar estas configuraciones, un servicio especializado puede hacerlo por ti. En elenlace.com configuramos la caché completa del servidor como parte de nuestros planes de mantenimiento web. También te recomendamos revisar nuestra sección de rendimiento con guías adicionales sobre optimización.

Verificar que la caché funciona

Tras aplicar la configuración, verifica los headers de respuesta desde el navegador (DevTools → Network → selecciona el archivo → Headers) o con curl:

curl -I https://tusitio.com/style.css

Deberías ver algo como:

Cache-Control: public, max-age=31536000, immutable
Expires: Sat, 19 Jun 2027 12:00:00 GMT

Si ves Cache-Control: no-cache o no-store en recursos estáticos, la configuración no se aplicó correctamente.

Conclusiones clave

  • Existen varias capas de caché: navegador, página completa, OPcache y CDN. Cada una resuelve un problema distinto.
  • La caché del navegador se controla desde el servidor con headers Cache-Control y Expires — configúrala en .htaccess (Apache) o en el bloque location (Nginx).
  • Los recursos estáticos (imágenes, CSS, JS) deben cachearse 1 mes a 1 año; el HTML dinámico, nunca.
  • OPcache puede reducir el tiempo de respuesta PHP un 30–50% y debe estar activado en cualquier instalación PHP de producción.
  • Los errores más comunes son: cachear sesiones de usuario, no usar cache busting y poner TTL demasiado cortos.
  • Verifica la configuración con DevTools o curl -I tras aplicar los cambios.

¿Prefieres dejar la configuración en manos de expertos? Contáctanos en elenlace.com y nos encargamos de optimizar la caché de tu servidor para que tu sitio vuele desde el primer clic.

Preguntas frecuentes

¿Puedo configurar la caché del servidor en un hosting compartido?

Sí, pero con limitaciones. En hosting compartido puedes controlar la caché del navegador desde .htaccess (si el proveedor tiene habilitados mod_expires y mod_headers). La caché de página completa a nivel de servidor requiere acceso a la configuración de Apache o Nginx, algo reservado a VPS y servidores dedicados.

¿Cuánto tiempo debo cachear el HTML de mi sitio?

En general, el HTML no debería cachearse en el servidor de forma agresiva porque el contenido puede cambiar (nuevas entradas, stock actualizado, sesiones de usuario). Si usas un CMS, deja que el plugin de caché gestione el TTL y asegúrate de que invalide el caché automáticamente al publicar cambios.

¿La caché puede hacer que mis cambios no se vean?

Sí, si no implementas cache busting. Cuando actualices CSS, JS o imágenes, cambia el nombre del archivo o añade un parámetro de versión. Muchos CMS y plugins de caché hacen esto automáticamente al limpiar el caché tras una publicación.

¿Redis o Memcached son necesarios para WordPress?

No son indispensables en sitios pequeños, pero son muy recomendables para tiendas WooCommerce o sitios con tráfico medio-alto. Almacenan en RAM los resultados de consultas a la base de datos, reduciendo drásticamente la carga del servidor en horas punta.

Para saber más

Otros proveedores y guías que vale la pena comparar:

← Todos