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-ControlyExpires— configúrala en.htaccess(Apache) o en el bloquelocation(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 -Itras 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: