Guía completa de uso de los distintos tipos de caché en WordPress: estrategias, técnicas y optimización por tipología de web y ejemplos

WordPress es un CMS fantástico, pero tiene un problema de base, y es que cada vez que alguien visita tu web, WordPress tiene que hacer un montón de trabajo: consulta la base de datos, ejecuta código PHP, compone la página HTML, carga recursos… todo esto en cada petición. Es como si cada vez que alguien quiere una hamburguesa, el restaurante tuviese que criar la vaca desde cero.

La caché es la solución a este problema. En lugar de repetir todo ese trabajo cada vez, guardamos el resultado y lo servimos directamente cuando alguien lo pide. Simple, ¿verdad?

Pues sí y no. Porque hay muchos tipos de caché, muchas capas donde aplicarla, y lo que funciona perfectamente en un blog puede hundir una tienda online.

Por qué la caché es fundamental en WordPress

No te lo cuento, mejor echamos cuentas:

• Una web sin caché puede tardar de 2 a 5 segundos en cargar
• La misma web con caché bien configurada puede bajar a 0,8 o incluso 0,3 segundos
• Google penaliza webs lentas en el SEO
• El 53% de los usuarios móviles abandona una web que tarda más de 3 segundos en cargar
• Incluso webs como Amazon pierden un 1% de ventas por cada 100ms de retraso, o sea, un 10% por cada segundo, una burrada.

Pero no solo es velocidad. Una web sin caché consume muchísimos más recursos de servidor. Lo que tu hosting podría aguantar con 10.000 visitas al día sin caché, lo aguanta con 100.000 con caché bien configurada. Esto se traduce en dinero: o pagas más por un servidor potente, o aprovechas mejor el que tienes.

Cómo funciona WordPress sin caché (el problema)

Veamos qué pasa cuando alguien visita tu WordPress sin caché:

1. El navegador pide la página a tu servidor
2. El servidor recibe la petición y arranca PHP
3. WordPress se carga en memoria (cientos de archivos)
4. WordPress consulta la base de datos para ver qué tema usar
5. WordPress consulta la base de datos para cargar plugins activos
6. WordPress ejecuta todos los hooks de los plugins
7. WordPress consulta la base de datos para cargar la configuración
8. WordPress consulta la base de datos para cargar el contenido
9. WordPress consulta la base de datos para cargar comentarios, metadatos, taxonomías…
10. WordPress ejecuta el tema y genera el HTML
11. El servidor envía el HTML al navegador
12. El navegador pide los CSS, JavaScript, imágenes…
13. El servidor tiene que servir cada uno de esos archivos

Todo esto POR CADA VISITA. Si tienes 100 personas visitando tu web al mismo tiempo, tu servidor tiene que hacer esto 100 veces simultáneamente. Es una locura.

El impacto real: velocidad, SEO, experiencia de usuario y costes de servidor

• Velocidad: La diferencia entre una web con y sin caché es abismal. Estamos hablando de pasar de 3-4 segundos a menos de 1 segundo. En el mundo web, esto es la diferencia entre el éxito y el fracaso.
• SEO/GEO: Google tiene claro que la velocidad es un factor de ranking. Core Web Vitals, LCP, FID, CLS… todas estas métricas que Google mide dependen directamente de lo bien que esté configurada tu caché. Una web lenta no posiciona bien, punto.
• Experiencia de usuario: Los usuarios son impacientes. Si tu web tarda en cargar, se van. No importa lo bueno que sea tu contenido si nadie espera a verlo. La caché hace que tu web sea ágil, que responda inmediatamente, que la navegación sea fluida.
• Costes de servidor: Aquí es donde la caché puede ahorrarte dinero de verdad. Un servidor que sin caché aguanta 5.000 visitas diarias antes de morir, con caché bien configurada puede aguantar 50.000 o 100.000. Esto significa que puedes estar más tiempo sin tener que escalar tu plan de hosting, o que puedes contratar un plan más modesto.

Ahora que tenemos claro por qué la caché es fundamental, vamos a ver los tipos de caché que existen en el ecosistema WordPress. Porque no hay una sola caché, hay muchas, y cada una sirve para algo diferente.

Tipos de caché en WordPress: entendiendo cada capa

Aquí es donde la cosa se pone interesante. No existe «la caché de WordPress». Existen múltiples capas de caché, cada una guarda cosas diferentes, funciona de forma diferente, y tiene sus propios pros y contras. Vamos a verlas todas.

Caché de navegador (Browser Cache)

Esta es la caché más cercana al usuario. Literalmente está en su ordenador o móvil.

Qué es y cómo funciona: Cuando alguien visita tu web por primera vez, su navegador descarga todos los archivos: CSS, JavaScript, imágenes, fuentes… La caché de navegador le dice «oye, esto no va a cambiar en un tiempo, guárdalo en tu disco duro». Así, cuando el usuario vuelve a tu web, su navegador ya tiene esos archivos y no tiene que volver a descargarlos.

Qué elementos cachea: Principalmente archivos estáticos:

• CSS (hojas de estilo)
• JavaScript (archivos .js)
• Imágenes (JPG, PNG, WebP, SVG…)
• Fuentes (WOFF, WOFF2, TTF…)
• Vídeos y audio
• PDFs y otros documentos

Configuración mediante cabeceras HTTP: Se configura enviando cabeceras HTTP especiales que el navegador entiende:

• Cache-Control: max-age=31536000 (cachea durante 1 año)
• Expires: Thu, 31 Dec 2026 23:59:59 GMT (método antiguo pero aún válido)
• ETag y Last-Modified (para validar si el archivo ha cambiado)

Tiempo de caducidad recomendado por tipo de archivo:

• CSS y JS: 1 año (cambias el nombre del archivo cuando lo actualizas)
• Imágenes: 1 mes a 1 año (depende de si las cambias frecuentemente)
• Fuentes: 1 año (casi nunca cambian)
• HTML: 0 segundos o muy poco (quieres que siempre esté actualizado)
• Favicon: 1 mes

Lo bueno de la caché de navegador es que es gratis, no consume recursos de tu servidor, y es la más rápida de todas. Lo malo es que solo funciona para visitantes recurrentes, no para la primera visita.

Caché de página (Page Cache / Full Page Cache)

Esta es la estrella del espectáculo, la caché más importante para la mayoría de webs.

Qué es y cómo funciona: Guarda el HTML completo de cada página ya generado. Cuando alguien visita tu web, en lugar de ejecutar todo WordPress, simplemente le sirves el HTML guardado. Es como tener las hamburguesas ya hechas en lugar de cocinarlas cuando llega el cliente.

HTML estático vs dinámico: Aquí está el truco. El HTML estático es igual para todos los usuarios. El dinámico cambia según quién lo visita (usuarios conectados, carritos de compra, contenido personalizado…). La caché de página funciona fenomenal con contenido estático, pero puede ser problemática con contenido dinámico.

Cuándo es efectiva y cuándo problemática:

Efectiva en:

• Blogs y revistas (el artículo es igual para todos)
• Webs corporativas (las páginas institucionales no cambian)
• Landing pages (contenido fijo)
• Portafolios y webs personales

Problemática en:

• Tiendas online (carritos, cuentas de usuario)
• Áreas de miembros (contenido personalizado)
• Foros (contenido que cambia constantemente)
• Webs con formularios complejos

Limitaciones con contenido personalizado: Si cacheas una página que muestra «Hola, Juan» arriba, todos los usuarios verán «Hola, Juan». Si cacheas una página con un carrito que tiene 3 productos, todos verán esos 3 productos. Por eso hay que excluir ciertas páginas y usar técnicas especiales (AJAX, ESI…) para mezclar contenido cacheado con contenido dinámico.

Caché de objetos (Object Cache)

Esta caché es menos conocida pero igual de importante que la de página.

Qué es y cómo funciona: Guarda los resultados de consultas a la base de datos y operaciones complejas. Por ejemplo, si WordPress tiene que hacer una consulta para obtener la lista de categorías de tu blog, en lugar de hacerla cada vez, la guarda en caché de objetos. La próxima vez que la necesite, la recupera de la caché en lugar de consultar la base de datos.

WordPress transients API: WordPress tiene su propia API de caché de objetos llamada Transients. Puedes usar funciones como set_transient(), get_transient() para guardar datos temporalmente. Muchos plugins usan esto para mejorar el rendimiento.

Diferencia entre caché persistente y no persistente:

• No persistente: Los datos se guardan solo durante la ejecución de la página. Cuando termina, se borran. Es lo que WordPress hace por defecto.
• Persistente: Los datos se guardan en un sistema externo (Redis, Memcached, o en disco) y permanecen entre peticiones. Es mucho más eficiente.

WordPress te avisa en Herramientas > Salud del sitio si no tienes caché de objetos persistente activada.

Casos de uso ideales:

• Webs con muchas consultas a la base de datos
• Tiendas online (consultas de productos, categorías, atributos…)
• Webs de membresías (consultas de usuarios, permisos…)
• Webs con muchos plugins activos (cada plugin hace sus consultas)
• Portales con mucho contenido relacionado

Caché de base de datos (Database Query Cache)

Esta caché es un poco especial porque depende más del servidor de base de datos que de WordPress.

Qué es y cómo funciona: MySQL y MariaDB pueden cachear los resultados de las consultas SELECT. Si haces la misma consulta dos veces, la segunda vez te devuelve el resultado guardado en lugar de ejecutarla de nuevo.

MySQL Query Cache (deprecado en MySQL 8.0): Ojo, esto es importante. MySQL Query Cache existía en versiones antiguas de MySQL pero se eliminó en MySQL 8.0 porque no funcionaba bien con aplicaciones modernas. Si tienes MySQL 8.0 o superior, no tienes esta caché disponible.

Alternativas modernas: En su lugar, MySQL 8.0 mejoró otras áreas:

• InnoDB Buffer Pool (cachea datos y índices en RAM)
• Mejor optimizador de consultas
• Y sobre todo: usa caché de objetos persistente (Redis/Memcached) que hace esto mismo pero mejor

Cuándo realmente aporta valor: Hoy en día, sinceramente, no te preocupes mucho por esto. Si tienes MySQL 5.7 o anterior y está activado, bien. Si no, confía en la caché de objetos persistente que hace el mismo trabajo pero mejor.

Caché de opcodes (OPcache)

Esta es, sin exagerar, quizás una de las cachés más importantes para WordPress, y mucha gente ni sabe que existe.

Qué es y cómo funciona: PHP tiene que compilar el código PHP a opcodes (código que la máquina entiende) cada vez que se ejecuta. OPcache guarda esos opcodes ya compilados en memoria. Es decir, PHP no tiene que leer y compilar los archivos cada vez, directamente ejecuta el código ya compilado que tiene guardado.

Por qué es una caché muy importante: Porque afecta a TODO. Cada petición a WordPress ejecuta cientos de archivos PHP. Sin OPcache, PHP tiene que leer y compilar esos cientos de archivos en cada petición. Con OPcache, simplemente los ejecuta. La diferencia de rendimiento es brutal: entre 2x y 5x más rápido.

Configuración óptima para WordPress: En tu php.ini deberías tener algo así:

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

Verificación de que está activa: Crea un archivo info.php y dentro añade únicamente <?php phpinfo(); ?>, súbelo a tu web, visita tuweb.com/info.php y busca la sección «Zend OPcache». Si dice Enabled, estás de suerte. Si no, habla con tu hosting para que lo activen. Es FUNDAMENTAL.

Cuando termines de verificar, BORRA ese archivo por seguridad.

Caché de fragmentos (Fragment Cache)

Esta es una técnica más avanzada pero muy útil en ciertos escenarios.

Qué es y cómo funciona: En lugar de cachear la página completa o solo objetos, cacheas «fragmentos» de la página. Por ejemplo, en una página de producto de WooCommerce puedes cachear la descripción del producto (que es igual para todos) pero dejar sin cachear el botón «Añadir al carrito» (que es dinámico).

Cachear partes específicas de una página: Se suele hacer en el código del tema o plugin usando transients. Por ejemplo, obtener un fragmento guardado como transient, y si no existe, generarlo y guardarlo con una caducidad determinada.

Uso con contenido mixto (estático + dinámico): Es la solución perfecta para webs que necesitan mezclar contenido cacheado con contenido personalizado. Por ejemplo:

• Un blog con banners personalizados
• Una tienda con productos relacionados dinámicos
• Un portal de noticias con widgets personalizados

No es algo que configures con un plugin, requiere desarrollo a medida. Pero conocer que existe te ayuda a entender ciertas optimizaciones avanzadas.

Redis y Memcached

Estos son sistemas de caché de objetos persistente externos a WordPress, y son lo más top.

Qué son y diferencias entre ambos: Son servidores de caché que guardan datos en RAM. Son extremadamente rápidos porque la RAM es muchísimo más rápida que el disco.

Redis:

• Más moderno y con más funcionalidades
• Puede guardar estructuras de datos complejas (listas, sets, hashes…)
• Puede persistir datos en disco como backup
• Admite pub/sub, transacciones, scripting Lua…
• Es el más recomendado actualmente

Memcached:

• Más antiguo y simple
• Solo guarda pares clave-valor
• Más ligero en consumo de memoria
• Más que suficiente para WordPress
• Aún muy usado en muchos hostings

Cuándo usar Redis vs Memcached:

• Para WordPress, ambos funcionan bien
• Redis es mejor si necesitas funcionalidades avanzadas
• Memcached es más simple y a veces más rápido para casos básicos
• Si tu hosting ofrece ambos, prueba ambos y quédate con el que vaya mejor

Requisitos de servidor:

• Necesitas que tu hosting tenga Redis o Memcached instalado
• No todos los hostings compartidos lo ofrecen
• Los VPS y dedicados sí suelen tenerlo o puedes instalarlo
• Algunos hostings compartidos lo incluyen (como SiteGround)

Integración con WordPress: Necesitas un plugin que conecte WordPress con Redis o Memcached:

• Para Redis: Redis Object Cache
• Para Memcached: Object Cache 4 Everyone o Speed Optimizer (en SiteGround)
• Estos plugins crean un archivo especial object-cache.php en /wp-content/

Varnish Cache

Varnish es también artillería pesada.

Qué es y cómo funciona: Varnish es un proxy inverso que se pone delante de tu servidor web. Cuando alguien visita tu web, primero llega a Varnish. Si Varnish tiene la página cacheada, la sirve directamente sin ni siquiera tocar Apache/Nginx/PHP/WordPress. Si no la tiene, la pide al servidor, la cachea, y la sirve.

Diferencias con otras cachés: Varnish es extremadamente rápido, puede servir decenas de miles de peticiones por segundo. Otras cachés sirven cientos o miles. Varnish es como tener un CDN en tu propio servidor.

Nivel de complejidad: Alto. Varnish requiere:

• Configuración a nivel de servidor (no es un plugin)
• Conocimientos de VCL (Varnish Configuration Language)
• Gestión de reglas de purga y bypass
• No apto para hostings compartidos

Cuándo merece la pena:

• Webs con tráfico muy alto (100 k o más visitas diarias)
• Portales de noticias que reciben picos de tráfico
• Webs donde cada milisegundo cuenta
• Cuando tienes servidor dedicado o VPS y conocimientos técnicos

Para la mayoría de webs WordPress, Varnish es una desmesura casi siempre. Pero si algún día llegas a ese nivel, pues verás que funciona.

CDN (Content Delivery Network)

Los CDN son diferentes a la caché, pero van de la mano, y también tienen caché.

Qué es y cómo funciona: Un CDN es una red de servidores distribuidos por todo el mundo. Cuando alguien visita tu web desde Madrid, el CDN le sirve los archivos desde un servidor en Madrid. Si alguien visita desde Buenos Aires, desde un servidor en Buenos Aires. Esto reduce la latencia (el tiempo que tarda en llegar la información) de forma brutal.

Diferencia entre CDN y caché:

• La caché guarda contenido para no tener que generarlo cada vez
• El CDN guarda contenido cerca del usuario para que llegue rápido
• Son complementarios, no excluyentes

Tipos: pull vs push:

Pull CDN (el más común):

• Tú no haces nada, el CDN se encarga de todo
• La primera vez que alguien pide un archivo, el CDN lo descarga de tu servidor
• Lo guarda y lo sirve desde su red
• Cloudflare, BunnyCDN, KeyCDN

Push CDN:

• Tú subes manualmente los archivos al CDN
• Más control pero más trabajo
• Usado para archivos muy grandes o streaming

Principales proveedores y diferencias:

Cloudflare (gratuito y de pago):

• El más usado con diferencia
• Plan gratuito muy generoso
• Incluye protección DDoS, SSL, optimizaciones…
• Fácil de configurar (solo cambiar DNS)
• Cachea HTML en planes de pago

BunnyCDN (de pago, muy barato):

• Muy rápido y económico
• Enfocado en rendimiento puro
• Sin funciones extra, solo CDN
• Pago por uso real

KeyCDN (de pago):

• Similar a Bunny
• Buena relación calidad-precio
• Buena integración con plugins WordPress

Amazon CloudFront, Fastly, Akamai:

• CDN profesionales y caros
• Para empresas grandes
• Excesivo para la mayoría

Para una web WordPress normal, Cloudflare gratis es más que suficiente. Para webs con mucho contenido multimedia Bunny es fantástico por su precio.

Herramientas y plugins de caché

Ahora que sabemos qué tipos de caché existen, veamos qué herramientas tenemos en WordPress para gestionarlas.

Plugins todo-en-uno

Estos plugins intentan gestionar varios tipos de caché desde una única interfaz.

WP Rocket (de pago, ~50 €/año)

Qué ofrece:

• Caché de página (lo hace muy bien)
• Caché de navegador (configuración automática)
• Optimización de CSS y JS (minimizar, combinar archivos)
• Lazy load de imágenes
• Precarga de caché
• Integración con CDN
• Optimización de base de datos
• Interfaz muy intuitiva

Pros:

• Configuración por defecto ya optimizada
• No tienes que tocar casi nada y funciona
• Soporte técnico bueno
• Actualizaciones frecuentes
• Compatible con casi todo

Contras:

• Es de pago (aunque no es caro)
• No incluye caché de objetos persistente

Ideal para: Quien quiera resultados inmediatos sin complicarse la vida y no le importe pagar.

LiteSpeed Cache (gratuito)

Qué ofrece:

• Caché de página a nivel de servidor (si tienes LiteSpeed Web Server)
• Caché de objetos
• Optimización de imágenes (con cuota gratis limitada)
• Lazy load
• Minimizar CSS/JS
• CDN propio (QUIC.cloud)
• Critical CSS automático
• Y mil opciones más

Pros:

• Gratuito y muy completo
• Si tienes LiteSpeed server, es la caché más rápida posible
• Muchas funcionalidades incluidas
• Optimización de imágenes integrada

Contras:

• Interfaz abrumadora con demasiadas opciones
• Si no tienes LiteSpeed server, funciona como cualquier otro plugin
• Algunas funciones requieren registrarse en su servicio
• Puede ser excesivo para webs simples

Ideal para: Quien tenga hosting con LiteSpeed. Si no tienes LiteSpeed, hay opciones más simples.

Speed Optimizer (gratuito)

Qué ofrece:

• Caché de página completa + dinámica si estás alojado en SiteGround
• Caché de objetos (Memcached si estás alojado en SiteGround)
• Caché de navegador
• Minimizar CSS/JS
• Eliminación de recursos innecesarios
• Lazy Load de imágenes
• Optimización de fuentes
• Precarga de recursos
• Creación de WebP
• Y mucho más

Pros:

• Gratuito
• Muy potente y configurable
• Admite todos los tipos de caché
• Memcached en SiteGround
• Conversión a WebP gratis
• Usado en webs muy grandes

Contras:

• Algunas funcionalidades solo disponibles si te alojas en SiteGround

Ideal para: Usuarios de todo tipo, especialmente si la web está alojada en SiteGround

WP Super Cache (gratuito)

Qué ofrece:

• Caché de página (simple pero efectiva)
• Preload de caché
• CDN básico
• Compresión

Pros:

• Gratuito
• Simple y ligero
• Desarrollado por Automattic (los de WordPress.com)
• Muy estable

Contras:

• Funcionalidades limitadas
• Interfaz un poco anticuada
• No incluye optimizaciones avanzadas
• No tiene caché de objetos

Ideal para: Blogs simples que solo necesitan caché de página básica. Para algo más complejo, hay mejores opciones.

Plugins especializados

A veces no necesitas un plugin todo-en-uno. Necesitas gestionar un tipo específico de caché y combinarlo con otras herramientas.

Redis Object Cache

Para qué sirve: Conectar WordPress con un servidor Redis para caché de objetos persistente.

Cómo funciona:

• Instalas el plugin
• Si tu servidor tiene Redis, lo detecta automáticamente
• Creas el drop-in object-cache.php
• Ya tienes caché de objetos persistente

Requisitos: Tu hosting debe tener Redis instalado y accesible.

Ventajas:

• Hace una sola cosa pero la hace muy bien
• Interfaz clara que muestra estadísticas
• Puedes ver hit rate, memory usage, etc.
• Compatible con cualquier plugin de caché de página

Object Cache 4 Everyone

Este plugin es una joya, y no es muy conocido, a pesar mio.

Para qué sirve: Activar caché de objetos persistente, tengas o no Memcached en tu servidor.

Cómo funciona:

• Si tu hosting tiene Memcached, lo usa
• Si no tiene Memcached, crea caché de objetos basada en archivos en disco
• Instalar y activar, ya está

Por qué es especial: Es la única forma de tener caché de objetos persistente sin necesitar Redis o Memcached en el servidor. Sí, basada en disco es más lenta que en RAM, pero es infinitamente mejor que no tener caché de objetos persistente.

Advertencia importante: Si usa caché en disco (cuando no tienes Memcached), puede generar MUCHOS archivos en /wp-content/cache/object/. En tiendas grandes con mucho tráfico puede ocupar gigas. Hay que vigilar el espacio en disco y borrar esa carpeta periódicamente si es necesario.

Ideal para: Hostings compartidos básicos sin Redis ni Memcached. O incluso en hostings que sí tienen Memcached, a veces funciona mejor que el sistema del hosting.

Soluciones de servidor y hosting

Los plugins son geniales, pero la caché a nivel de servidor es aún mejor.

LiteSpeed Web Server

Qué es: Un servidor web alternativo a Apache y Nginx, con caché integrada de serie.

Ventajas:

• Caché extremadamente rápida a nivel de servidor
• Compatible con reglas .htaccess de Apache
• El plugin LiteSpeed Cache se comunica directamente con el servidor
• Gestión inteligente de purga de caché

Hostings que lo ofrecen: Cada vez más. Hostinger, algunos planes de Webempresa, muchos VPS modernos…

Cómo saber si lo tienes: El plugin LiteSpeed Cache te lo dirá al instalarlo. O mira en tu panel de hosting.

Nginx FastCGI Cache

Qué es: Sistema de caché integrado en Nginx (otro servidor web muy popular).

Ventajas:

• Muy rápido
• No consume PHP ni WordPress para servir páginas cacheadas
• Gratuito y incluido en Nginx

Desventajas:

• Requiere configuración manual del servidor
• Complicado de purgar la caché automáticamente
• Necesitas acceso al servidor

Cómo usarlo con WordPress: Existen plugins como Nginx Helper que ayudan a purgar la caché cuando publicas contenido nuevo.

Apache mod_cache

Qué es: Módulo de caché de Apache.

Advertencia: No lo recomiendo para WordPress. Es antiguo, menos eficiente que las alternativas, y difícil de configurar. Si tienes Apache, mejor usa un plugin de caché o cambia a LiteSpeed/Nginx.

Cloudflare (CDN + caché)

Cloudflare merece mención especial porque es más que un CDN.

Plan gratuito:

• Cachea automáticamente CSS, JS, imágenes, etc.
• No cachea HTML por defecto (puedes con Page Rules en plan gratis, limitado)
• SSL gratis
• Protección DDoS básica
• Optimizaciones automáticas (Rocket Loader, Mirage, Polish…)

Planes de pago (desde 20$/mes):

• Cachea HTML también
• Más Page Rules
• Mejor rendimiento
• Soporte

Integración con WordPress:

• Plugin oficial Cloudflare
• O simplemente cambiar tus DNS a Cloudflare
• Configurar Page Rules para cachear HTML selectivamente

Estrategias de caché por tipología de web

Aquí viene la chicha. Cada tipo de web necesita una estrategia diferente. Lo que funciona para un blog es un desastre para una tienda. Vamos a verlo todo en detalle.

Antes de seguir: Lo siguiente son solo estrategias generales por tipo de web, pero no para webs específicas. El tipo de contenido, el diseño o configuración de cada página, incluso de la misma web, pueden afectar completamente a la efectividad de los distintos métodos de caché, siendo muy efectivos en algunas URLs y totalmente contraindicados en otras, en el mismo sitio.

Landing pages y sitios estáticos

El caso más fácil y el que mejor funciona con caché.

Cualquier tamaño

Caché más agresiva posible: Estos sitios son perfectos para caché porque:

• No cambian casi nunca
• No hay contenido personalizado
• No hay usuarios conectados
• Objetivo: conversión rápida

TTL máximos:

• HTML: 30 días
• CSS/JS: 1 año
• Imágenes: 1 año

Preload completo del sitio: Como suelen ser pocas páginas, precarga TODO:

• Página de inicio
• Todas las landing pages
• Thank you pages
• 404

Así la primera visita de cada usuario es ultra rápida.

CDN altamente recomendado: Las landings viven de conversión. Cada 100ms cuenta. CDN es obligatorio.

Caso ideal para Cloudflare: Configuración óptima:

1. Activar Cloudflare (plan gratis vale)
2. Crear Page Rules para cachear HTML
3. Activar Auto Minify (HTML, CSS, JS)
4. Activar Rocket Loader (acelera JavaScript)

Con esto + WP Rocket o LiteSpeed Cache: Velocidades de carga < 0.5 segundos son totalmente posibles.

Optimizaciones extra para landings:

• Critical CSS inline
• Preload de fuentes
• Lazy load de imágenes below the fold
• Diferir JavaScript no crítico
• Eliminado de jQuery si no se usa

Web corporativa

Las webs corporativas son, para caché, un caso ideal. Contenido casi siempre estático, pocos cambios, sin contenido personalizado.

Web corporativa pequeña (< 10 k visitas/mes)

Caché agresiva posible: Puedes cachear TODO:

• Página de inicio
• Páginas de servicios
• Sobre nosotros
• Contacto (OJO con el formulario)
• Blog corporativo si lo hay

Formularios de contacto: consideraciones:

Los formularios pueden dar problemas con caché. Dos escenarios:

1. Formulario simple (Contact Form 7, WPForms…): Funcionan por AJAX, no hay problema con caché.
2. Formulario con protección: Si usas nonce, CAPTCHA, o honeypot, la caché puede cachear el token y todos los usuarios compartirían el mismo. Soluciones:
   • Generar token por JavaScript: Muchos plugins modernos lo hacen
   • Excluir la página de contacto de la caché: Pierdes velocidad en una página, no es grave
   • Usar AJAX: El formulario se envía sin recargar, la página está cacheada

TTL largos recomendados:

• Página de inicio: 7 días
• Páginas de servicios: 30 días
• Blog: 1 día (si publicas)
• Assets: 1 año

Configuración recomendada:

• WP Rocket (facilidad total)
• Caché de navegador 1 año
• Cloudflare gratis para CDN
• Preload de todo el sitio (es pequeño)

Resultado esperado: Tiempo de carga < 0.8 segundos, velocidad extrema.

Web corporativa mediana (10 k-100 k visitas/mes) y grande (> 100 k visitas/mes)

Configuración similar a la pequeña, con estas adiciones:

CDN especialmente para assets corporativos: Si tienes muchos PDFs corporativos, vídeos, presentaciones:

• CDN especializado como BunnyCDN
• Servidor de assets separado
• Optimización de PDFs (compresión)

Caché de página completa ideal: Las webs corporativas son el caso perfecto para caché completa porque casi nunca cambian. TTL de 30 días no es descabellado.

Si tienes área de clientes o portal: Ya no es tan simple, ve más abajo al apartado del portal de membresía para esa parte.

Blog o revista digital

Los blogs son también un caso sencillo para caché. El contenido es mayormente estático, igual para todos los usuarios.

Blog pequeño (< 10 k visitas/mes)

Frecuencia de actualización baja (semanal/mensual)

Capas de caché recomendadas:

1. OPcache: Fundamental, asegúrate de que está activa
2. Caché de página: La más importante aquí
3. Caché de navegador: Configuración de 1 año para assets
4. Caché de objetos: No imprescindible pero ayuda

Configuración de plugins:

Opción 1 – WP Rocket (la más simple):

• Instalar y activar
• Dejar configuración por defecto
• Activar precarga de caché
• Configurar CDN si lo usas
• Ya está, no necesitas tocar más

Opción 2 – LiteSpeed Cache (si tienes LiteSpeed server):

• Instalar y activar
• Usar preset «Blog»
• Revisar que esté activa la caché
• Activar optimización de imágenes (cuota gratis)

Opción 3 – Speed Optimizer / Object Cache 4 Everyone:

• Speed Optimizer para caché de página
• Configuración: Caché de página activado, minimizado
• Object Cache 4 Everyone para caché de objetos si no estás alojado en SiteGround

Caché de servidor: No imprescindible a este nivel de tráfico. El hosting compartido básico aguanta perfectamente con un buen plugin de caché.

CDN: No es necesario a menos que tengas audiencia muy internacional. Si tu público es español y tu servidor está en Europa, no necesitas CDN. Si tienes lectores en Latinoamérica, sí puede ayudar (Cloudflare gratis es perfecto).

TTL recomendados:

• Caché de página: 24 horas (se purgará cuando publiques)
• Caché de navegador: CSS/JS 1 año, imágenes 1 mes
• Caché de objetos: 12-24 horas

Qué NO cachear:

• Página de comentarios si tienes comentarios activos
• URLs con parámetros de búsqueda (/?s=algo)
• Página de vista previa (si editas con Elementor, Divi, etc.)
• URLs con parámetros UTM (opcional, dependiendo de tu analytics)

Incompatibilidades comunes:

• Plugins de contador de visitas pueden no contar bien con caché agresiva
• Sistemas de comentarios en tiempo real (mejor usar Disqus o Facebook Comments)
• Plugins que muestran «publicado hace X minutos» pueden desactualizarse

Resultado esperado: Tiempo de carga < 1 segundo, servidor aguantando sin problemas.

Frecuencia de actualización media (diaria)

Todo igual que el anterior, con estos ajustes:

Purga automática de caché: Asegúrate de que cuando publicas una entrada:

• Se purga la página de inicio
• Se purga el archivo de categoría de la entrada
• Se purga el sitemap XML
• La entrada nueva se precarga automáticamente

WP Rocket y LiteSpeed hacen esto automáticamente.

TTL ajustado: Puedes reducir el TTL de la página de inicio a 6-12 horas si publicas todos los días a la misma hora. Así la caché se regenera justo antes de tu publicación habitual.

Frecuencia de actualización alta (múltiples veces al día)

Cambios importantes respecto a los anteriores:

Balance caché vs frescura del contenido: Aquí tienes que elegir. Si cacheas 24h, tu última entrada puede no aparecer en página de inicio durante horas. Opciones:

1. Reducir TTL de página de inicio: 1-2 horas. Se regenera más a menudo.
2. Purga manual: Cuando publiques algo urgente, purga la caché manualmente.
3. Caché con AJAX: Cachea la página de inicio pero carga los últimas entradas por AJAX. Más complejo pero mantiene velocidad y frescura.

Precarga inteligente: Configura la precarga solo para páginas importantes, no para todo el sitio. Cada vez que publicas, el preload se dispara y puede sobrecargar el servidor.

Blog mediano (10 k-100 k visitas/mes)

Frecuencia baja

Cuándo implementar Redis/Memcached: Desde aquí es muy recomendable. Con este tráfico, tu base de datos empieza a recibir bastante carga. Redis/Memcached alivia esa carga de forma muy notable.

Importancia de OPcache: A partir de este nivel, OPcache pasa de recomendable a OBLIGATORIO. Sin OPcache, tu servidor sufrirá. Con OPcache, irá como una seda.

Configuración recomendada:

• Plugin de caché (WP Rocket, LiteSpeed, o Speed Optimizer)
• Redis o Memcached para caché de objetos (Redis Object Cache o Object Cache 4 Everyone)
• CDN sí o sí (Cloudflare gratis mínimo)
• Preload de caché activado
• Minimizado y combinación de CSS/JS

CDN recomendado desde este punto: Con 10k+ visitas al mes, un CDN marca la diferencia. Opciones:

• Cloudflare gratis: Lo básico, suficiente para la mayoría
• BunnyCDN (~1 €/TB): Si tienes muchas imágenes/vídeos
• CDN del plugin: LiteSpeed tiene su QUIC.cloud, WP Rocket se integra con varios

Caché de servidor: Si tu hosting lo ofrece (LiteSpeed, Nginx FastCGI…), actívalo. Potenciará aún más el rendimiento junto con el plugin.

Frecuencia media y alta

Mismas consideraciones que el blog pequeño pero CON Redis/Memcached sí o sí. Con múltiples publicaciones diarias y ese tráfico, la base de datos sin caché de objetos sufre mucho.

Blog grande (> 100 k visitas/mes)

Frecuencia baja

Caché de servidor obligatoria: A partir de aquí, confiar solo en plugins no es suficiente. Necesitas:

• LiteSpeed server con LiteSpeed Cache
• O Nginx con FastCGI Cache
• O Varnish (si tienes conocimientos)

Múltiples capas simultáneas:

1. OPcache (sin discusión)
2. Redis para caché de objetos
3. Caché de servidor (LiteSpeed/Nginx/Varnish)
4. Plugin de caché (complementario)
5. CDN (Cloudflare o CloudFront)
6. Caché de navegador optimizada

Configuración típica de éxito:

• VPS o dedicado (hosting compartido no aguanta)
• LiteSpeed Web Server
• LiteSpeed Cache plugin
• Redis con Redis Object Cache
• Cloudflare
• PHP 8.2+ con OPcache optimizado
• MariaDB con InnoDB y buffer generoso

Monitorización de hit rate: Empieza a ser importante medir:

• Hit rate de Redis (debería estar > 95%)
• Hit rate de caché de servidor (> 90%)
• Hit rate de CDN (> 80%)

Si estos números son más bajos, algo falla en la configuración.

Frecuencia media y alta

Con 100k+ visitas y publicación frecuente, estás en terreno profesional. Consideraciones adicionales:

Purga selectiva inteligente: Cuando publicas, no purgar TODO, solo:

• La entrada nueva
• Página de inicio
• Categoría de la entrada
• Quizá archivo de fecha

No purgar el resto de entradas ni páginas.

Preload con límites: El preload puede saturar el servidor. Limítalo a:

• Página de inicio
• Últimos 10-20 entradas
• Páginas principales

Deja que el resto se cachee bajo demanda.

Separación de caché: Llegando a este nivel plantéate separar la caché de assets (CSS/JS/imágenes) en el CDN y la caché de HTML en el servidor. Así cada sistema hace lo que mejor sabe hacer.

Tienda WooCommerce

Las tiendas son el caso más complejo para caché. Contenido dinámico por todos lados: carrito, cuenta de usuario, stock, precios personalizados…

Tienda pequeña (< 10 k visitas/mes)

Baja frecuencia de pedidos (< 50/día)

Estrategia específica para e-commerce:

La clave con WooCommerce es cachear lo que puedes y excluir lo que no debes. Puedes cachear:

• Páginas de producto (OJO con stock dinámico)
• Páginas de categoría y tienda
• Páginas institucionales (sobre nosotros, envíos, etc.)
• Blog si lo tienes

Páginas que NUNCA cachear:

• /carrito/ o /cart/
• /finalizar-compra/ o /checkout/
• /mi-cuenta/ o /my-account/
• Cualquier URL con ?add-to-cart=
• AJAX add-to-cart
• Páginas de pago (retorno desde PayPal,  RedSys, etc.)

Cookies y sesiones: el problema: WooCommerce usa cookies para:

• Mantener el carrito
• Saber si el usuario está conectado
• Recordar productos vistos

La caché tiene que saltarse (bypass) estas cookies. Configuración típica:

WP Rocket con WooCommerce:

• WP Rocket detecta WooCommerce y configura exclusiones automáticamente
• Verifica en «Exclusiones» que estén cart, checkout, my-account
• Cookie woocommerce_items_in_cart hace bypass automático

LiteSpeed Cache con WooCommerce:

• Usa el preset de WooCommerce
• Configura ESI para widgets dinámicos (carrito, cuenta)
• Gestión inteligente de stock

Configuración de exclusiones: Si usas Speed Optimizer u otro plugin:

Excluir URLs:

/carrito/
/cart/
/checkout/
/finalizar-compra/
/mi-cuenta/
/my-account/

Excluir cookies:

woocommerce_items_in_cart
wordpress_logged_in_

Excluir parámetros:

add-to-cart
remove_item

Gestión de stock en caché: Si vendes productos con stock limitado, tienes opciones:

1. No cachear páginas de producto: Pierdes velocidad pero el stock siempre es preciso.
2. Cachear pero con purga: Cachear con TTL bajo (1-2 horas) y purgar automáticamente cuando cambia el stock. WP Rocket y LiteSpeed hacen esto.
3. Mostrar stock por AJAX: Cachear la página pero cargar el stock dinámicamente con JavaScript. Mantiene velocidad y precisión.

CDN para imágenes de producto: Fundamental. Las fotos de producto suelen ser pesadas. Un CDN:

• Reduce el tiempo de carga de imágenes
• Ahorra ancho de banda de tu servidor
• Mejora la experiencia móvil

Cloudflare gratis es perfecto para esto.

Resultado esperado:

• Páginas de producto: < 1.5 segundos
• Página de tienda/categoría: < 2 segundos
• Checkout: Puede ser más lento, es normal, no está cacheado

Media frecuencia de pedidos (50-200/día)

Ajustes adicionales:

Object cache imprescindible: Con 50+ pedidos diarios, WooCommerce hace muchas consultas:

• Calcular envío
• Aplicar cupones
• Gestionar stock
• Cargar pedidos del usuario

Sin caché de objetos, la base de datos sufre. Con Redis/Memcached, todo va fluido.

Caché de fragmentos para widgets: El widget de carrito es un problema. Está en todas las páginas pero es dinámico. Soluciones:

1. ESI (Edge Side Includes): Si usas LiteSpeed o Varnish, puedes cachear la página entera excepto el widget del carrito. LiteSpeed Cache lo hace automáticamente.
2. AJAX: Cachear la página y cargar el contenido del carrito por AJAX. Muchos temas WooCommerce modernos lo hacen.
3. TRUCAZO – No mostrar cantidad: En lugar de «Carrito (3)», mostrar solo «Carrito». Así puedes cachear todo.

Alta frecuencia de pedidos (> 200/día)

Con 200+ pedidos diarios estás vendiendo en serio. Configuración agresiva:

Preload selectivo: No precargar todo. Solo:

• Página de inicio
• Categorías principales
• Productos destacados

El resto bajo demanda.

Separación de caché: Considera tener:

• CDN para imágenes (BunnyCDN recomendado)
• Caché de página para contenido estático
• Sin caché para checkout y carrito
• Redis para caché de objetos y sesiones

Optimizar checkout: El proceso de compra es lento por naturaleza (cálculos, pasarelas de pago, etc.). Enfócate en:

• Minimizar plugins activos en checkout
• Deshabilitar scripts innecesarios en checkout
• Usar pasarela de pago rápida (Stripe > PayPal)

Tienda mediana (10 k-100 k visitas/mes) y grande (> 100 k visitas/mes)

Configuración para tienda mediana:

Redis obligatorio: No es opcional. WooCommerce con este tráfico sin Redis es un infierno. Redis para:

• Caché de objetos
• Sesiones de WooCommerce (configurar en wp-config.php)
• Transients

Varnish en sitios muy grandes: Si superas 100k visitas/mes y tienes presupuesto, Varnish + ESI es la mejor solución para WooCommerce. Te permite:

• Cachear páginas enteras
• Excepto bloques específicos (carrito, cuenta)
• Velocidad extrema
• Gestión inteligente de purga

Pero requiere servidor dedicado/VPS y conocimientos técnicos.

Estrategias de purga selectiva: Cuando alguien compra un producto, no purgar toda la caché. Solo:

• La página de ese producto (si cambió el stock)
• La categoría (si muestras stock en listados)

No purgar todo el resto.

AJAX para contenido dinámico: A partir de aquí, es recomendable que:

• Botón «Añadir al carrito» funcione por AJAX
• Carrito se actualice sin recargar página
• Stock se cargue dinámicamente

Así cacheas el 99% del HTML.

ESI (Edge Side Includes) con Varnish: ESI permite cachear una página completa pero dejar huecos que se rellenan dinámicamente. El widget del carrito se genera dinámicamente pero el resto está cacheado. LiteSpeed Cache también admite ESI sin Varnish.

Configuración de ejemplo para tienda grande:

• VPS o dedicado con LiteSpeed o Varnish
• PHP 8.2+ con OPcache
• Redis para objetos y sesiones WooCommerce
• LiteSpeed Cache con ESI, o Varnish con VCL personalizado
• BunnyCDN o CloudFront para assets
• Cloudflare delante (solo proxy, desactivar caché HTML)
• Múltiples workers PHP (PHP-FPM con 20-50 workers)

Monitorización crítica:

• Time to first byte (TTFB) en checkout: Debe ser < 500ms
• Hit rate de Redis: > 95%
• Hit rate de caché de página: > 90%
• Errores de stock: 0 (purga correcta es fundamental)

Portal de membresía / Zona privada

Este es el caso más complejo para caché, más incluso que WooCommerce.

Portal pequeño (< 10 k visitas/mes), mediano y grande

El caso más complejo para caché: Cada usuario ve contenido diferente:

• Nombre personalizado
• Contenido según su suscripción
• Progreso personal
• Mensajes privados

Contenido personalizado por usuario: Es imposible cachear estas páginas de forma tradicional. Si cacheas una página que dice «Hola, Juan», todos verán «Hola, Juan».

Qué NO cachear (casi todo el área privada):

• Dashboard de usuario
• Páginas de perfil
• Contenido exclusivo de miembros
• Cursos en progreso
• Mensajes/notificaciones
• Cualquier cosa personalizada

Estrategias de caché de objetos intensiva: Lo único que puedes cachear agresivamente son objetos:

• Consultas de cursos disponibles
• Listados de lecciones
• Información del sitio
• Menús
• Widgets

Aquí Redis no es recomendable, es OBLIGATORIO. Un portal de membresía sin Redis es lentísimo.

Separación de áreas públicas vs privadas:

Área pública (cachear agresivamente):

• Página de inicio
• Página de precios
• Página de registro/login (cuidado con nonces)
• Blog/recursos públicos
• Landing pages

Área privada (no cachear):

• /miembros/
• /cursos/
• /perfil/
• /dashboard/

Configuración típica en el plugin de caché:

Excluir URLs:
/miembros/
/dashboard/
/perfil/
/mi-cuenta/

Excluir cookies:
wordpress_logged_in_*
miembro_conectado (si tu plugin usa esta)

Cookies y bypass de caché: Los usuarios conectados tienen cookies. Configura tu caché para NO cachear si detecta cookie wordpress_logged_in_*.

WP Rocket y LiteSpeed lo hacen automáticamente, pero verifica que funcione.

Redis es casi fundamental en sitios medianos/grandes: Con muchos usuarios simultáneos consultando cursos, lecciones, su progreso… las consultas a la base de datos se disparan. Redis las cachea y el sitio va fluido.

Configuración típica:

• Plugin de caché (WP Rocket, LiteSpeed, Speed Optimizer)
• Redis obligatorio con Redis Object Cache
• NO cachear área de miembros
• Sí cachear área pública agresivamente
• CDN para vídeos de cursos (fundamental)
• OPcache bien configurado

Consideración de Varnish: Si el portal crece mucho (100k+ usuarios), Varnish con ESI puede permitir cachear incluso páginas semi-personalizadas. Pero es complejo y solo para casos avanzados.

Sitio de cursos con LMS (Learning Management System)

Similar a membresías pero con complejidad añadida: progreso, cuestionarios, certificados…

LMS pequeño, mediano y grande

Similar a membresías pero más complejo: Añades:

• Sistema de cuestionarios con límite de tiempo
• Seguimiento de progreso en tiempo real
• Emisión de certificados
• Foros de estudiantes

Caché de recursos educativos estáticos: Puedes cachear:

• Páginas de descripción de cursos (para no conectados)
• Recursos descargables (PDFs, etc.)
• Páginas informativas

Exclusiones de seguimiento de progreso: NUNCA cachear:

• Páginas de lecciones (contienen progreso personal)
• Tests y exámenes
• Página de «Mi progreso»
• Foro de discusión

Vídeos: CDN especializado: Los LMS suelen tener muchos vídeos. Opciones:

1. BunnyCDN Stream: CDN especializado en vídeo, adaptativo, protección contra descarga. ~5-10 €/TB.
2. Vimeo Pro: Hosting de vídeo con privacidad, embeds sin marca. ~50 €/año.
3. YouTube privado: Gratis pero menos control.
4. Bunny + autohosting: Subir vídeos a tu servidor, servir a través de BunnyCDN. Balance precio/control.

Object cache crítico para queries de cursos: Un LMS sin Redis hace miles de consultas:

• Cargar estructura de curso
• Verificar progreso
• Cargar siguiente lección
• Verificar prerequisitos
• Calcular estadísticas

Redis cachea todo esto y la experiencia mejora radicalmente.

Configuración típica LMS mediano/grande:

• VPS o hosting especializado (muchos no aguantan un LMS)
• PHP 8.2+ con OPcache y memory_limit alto (más de 256M)
• Redis obligatorio
• NO cachear área de cursos
• CDN para vídeos especializado
• Backup diario (datos de progreso de usuarios son críticos)

Foros y comunidades

El contenido en tiempo real es el enemigo de la caché.

Foro pequeño, mediano y grande

Contenido en tiempo real: En un foro:

• Se publican mensajes constantemente
• Los usuarios esperan ver contenido nuevo al instante
• Hay notificaciones, menciones, mensajes privados
• Contadores de «no leído»

Caché selectiva muy específica: Solo puedes cachear:

• Página de inicio del foro (para no conectados)
• Reglas y páginas estáticas
• Quizá hilos antiguos archivados

No cachear:

• Lista de hilos (cambia constantemente)
• Hilos activos
• Perfiles de usuario
• Mensajes privados
• Notificaciones

Object cache intensivo: Los foros hacen MUCHAS consultas:

• Cargar hilos
• Cargar respuestas
• Contar no leídos
• Verificar permisos
• Cargar perfiles

Sin caché de objetos las consultas matan el servidor.

Estrategias de purga automática: Configura para que:

• Al publicar un mensaje, purgar ese hilo
• Al crear un hilo nuevo, purgar la lista de hilos
• Mantener cacheados hilos sin actividad reciente

Redis o Memcached obligatorio en medianos/grandes: No hay discusión. Un foro con  más de 100 usuarios simultáneos sin ello es complicado.

Configuración típica:

• Caché de página SOLO para área pública/informativa
• Redis obligatorio para caché de objetos
• TTL muy bajo en hilos activos (1-5 minutos)
• TTL alto en hilos archivados (1 día)
• CDN para avatares de usuario y archivos adjuntos

Si usas bbPress o BuddyPress: Plugins de caché suelen tener presets para estos. Úsalos, están optimizados.

Alternativa: Plantéate usar plataformas especializadas en foros (Discourse, Circle) en lugar de WordPress. Son más rápidas y eficientes para este caso de uso. WordPress no es la mejor plataforma para foros de alto tráfico.

Configuraciones avanzadas y casos especiales

Algunos sitios tienen necesidades especiales que requieren configuraciones específicas.

Sitios multilíngües

Si tu web está en varios idiomas, la caché se complica.

Caché por idioma: Cada idioma es una versión diferente del sitio. La caché tiene que mantener versiones separadas:

• / (español)
• /en/ (inglés)
• /fr/ (francés)

Consideraciones con WPML/Polylang:

WPML: Usa cookies y parámetros:

• Cookie wp-wpml_current_language
• Parámetro ?lang=es

Tu caché debe generar versiones separadas según la cookie/parámetro.

Polylang: Similar, usa estructura de URLs o subdominios:

• tuweb.com/es/
• tuweb.com/en/
• O es.tuweb.com, en.tuweb.com

Configuración en WP Rocket:

• WP Rocket detecta WPML/Polylang automáticamente
• Genera caché separada por idioma
• Purga correcta por idioma

Configuración en LiteSpeed Cache:

• Activar «Separate Cache Per Language»
• Configurar cookie/parámetro usado

Separación de cachés: Importante que:

• Cada idioma tenga su propia caché
• Al cambiar contenido en un idioma, solo purgar ese idioma
• No mezclar idiomas en la caché

CDN y multiidioma: Si usas CDN, asegúrate de que:

• No cachea según IP (geolocalización automática puede causar problemas)
• Respeta la cookie de idioma
• Cloudflare: Desactiva el minimizado automático si da problemas con caracteres especiales

Sitios con geolocalización

Algunos sitios muestran contenido diferente según la ubicación del usuario.

Contenido por ubicación: Ejemplos:

• Precios según país
• Productos disponibles según región
• Idioma según ubicación
• Tiendas físicas cercanas

Bypass de caché por país: Si el contenido cambia radicalmente por país, tienes que:

1. Desactivar caché (opción simple pero lenta)
2. Caché por país: Generar versión de caché para cada país. Complejo pero factible.
3. AJAX: Cachear la página base, cargar contenido específico del país por JavaScript.

Cloudflare Workers: Cloudflare Workers puede detectar el país del visitante y:

• Servir contenido diferente desde el edge
• Modificar la página cacheada según país
• Sin tocar tu servidor WordPress

Es avanzado pero muy potente para geolocalización + caché.

Alternativa: Usar servicio especializado como GeoTargetly que hace esto por ti.

Sitios con múltiples perfiles de usuario

Algunos sitios muestran contenido diferente según el perfil del usuario.

Bypass por perfil: Si un admin ve menús diferentes a un suscriptor la caché tiene que diferenciar.

Caché diferenciada: Opciones:

1. No cachear para conectados: Simple, todos los usuarios que estén conectados ven contenido sin caché. WP Rocket y otros lo hacen por defecto.
2. Caché por perfil: Generar versión de caché para cada perfil. Solo viable si tienes pocos perfiles y las diferencias son menores.
3. AJAX por perfil: Cachear lo común, cargar elementos específicos del perfil por JavaScript.

Contenido personalizado: Si personalizas mucho (nombre de usuario, estadísticas personales, etc.), la caché completa no es viable. Confía en:

• Caché de objetos (Redis) para consultas comunes
• Caché de fragmentos para partes comunes
• Generación dinámica de contenido personalizado

APIs y REST API de WordPress

WordPress tiene una API REST que algunos usan.

Cachear endpoints o no: Depende del endpoint:

Sí cachear:

• /wp-json/wp/v2/posts (listado de entradas)
• /wp-json/wp/v2/categories (categorías)
• Endpoints de contenido público que no cambia a menudo

No cachear:

• Endpoints de autenticación
• Endpoints que crean/modifican contenido (POST, PUT, DELETE)
• Endpoints personalizados con datos del usuario

Configuración específica: En tu .htaccess o configuración de Nginx, puedes cachear selectivamente endpoints GET.

Varnish para APIs de alto tráfico: Si tu API recibe muchas peticiones, Varnish es la mejor solución:

• Cachea respuestas JSON
• Purga selectiva por endpoint
• Rate limiting integrado
• Maneja miles de peticiones por segundo

Si vas en serio con una API pública en WordPress, Varnish + el plugin WP REST Cache es la combinación ganadora.

Incompatibilidades y conflictos comunes

No todo es compatible con todo. Aquí está la lista negra.

Plugins que suelen dar problemas

Con caché de página:

• Plugins de contador de visitas (WP Statistics, estadísticas de Jetpack…): Pueden no contar bien si la página está cacheada. Solución: Usar tracking con JavaScript (Google Analytics, Plausible…).
• Plugins de contenido dinámico (widgets de últimas noticias externas, clima, etc.): Se cachean y quedan desactualizados. Solución: Cargarlos por AJAX o excluir esas páginas.
• Sliders con contenido de base de datos: Se cachea la primera versión. Solución: Excluir o usar sliders con JavaScript.
• Plugins de test A/B: Fundamental que funcionen por JavaScript del lado del cliente, no del servidor.

Con caché de objetos:

• MemberPress: Según ellos, desactivar Memcached. En la práctica, suele funcionar bien. Probar.
• Plugins de LMS antiguos: Algunos no entienden caché de objetos persistente. Actualizar o cambiar.

Con CDN:

• Plugins de protección de imágenes: Si proteges imágenes con protección de hotlinking puede romper el CDN.
• Plugins que modifican URLs de assets: Pueden entrar en conflicto con CDN. Desactivar uno u otro.

Conflictos entre tipos de caché

Duplicación innecesaria:

• Caché de página en plugin + caché de servidor: Si tienes Nginx FastCGI Cache activo y además WP Rocket cacheando, estás duplicando. Resultado: Dos cachés que purgar, más complejidad, sin beneficio. Solución: Elegir uno. El de servidor suele ser más rápido.
• Múltiples plugins de caché: NUNCA tengas dos plugins de caché activos (WP Rocket + Speed Optimizer, por ejemplo). Se pisan entre ellos, duplican archivos, causan problemas. Solución: Solo uno.

Sobrecarga de servidor:

• Preload agresivo de caché: Si tienes un sitio con 10.000 URLs y preload activo, cada vez que publicas algo el servidor intentará regenerar 10.000 páginas. Puede tumbarlo. Solución: Limitar precarga a páginas importantes.
• Minimizado de CSS/JS: A veces genera más problemas de los que soluciona. Si tu sitio ya es rápido, puede que no necesites esto. Solución: Medir antes y después, desactivar si no mejora significativamente.

Configuraciones contraproducentes:

• TTL demasiado corto: Si pones TTL de 5 minutos, la caché se regenera tan a menudo que casi no sirve. Solución: TTL mínimo 1 hora para caché de página.
• Excluir demasiadas URLs: Si excluyes media web de la caché, no estás cacheando realmente. Solución: Ser selectivo, solo excluir lo estrictamente necesario.
• Combinación de archivos CSS/JS: Actualmente NO se recomienda combinar recursos como optimización, es incluso contraproducente. Solución: Desactivar combinación, solo minimizar.

Temas que complican la caché

Maquetadores que generan JS dinámico:

• Elementor, Divi, etc.: Estos maquetadores generan JavaScript inline con contenido de base de datos. Si cacheas agresivamente, puede haber problemas con:
  • Formularios que no funcionan
  • Popups que no se muestran
  • Animaciones que no se ejecutan

Solución:

• Usar modo de edición fuera de caché (WP Rocket detecta esto)
• No cachear URLs con ?elementor-preview
• TTL razonable (no días, máximo horas)

Personalización excesiva:

• Temas con contenido personalizado por usuario: Si tu tema muestra «Hola, [Nombre]» en la cabecera estás jodido con caché. Solución:
  • Desactivar esa funcionalidad
  • Cargarla por JavaScript
  • No cachear para usuarios conectados

Soluciones generales:

1. Usa temas modernos y bien codificados: Temas de calidad (Astra, GeneratePress, Kadence) están optimizados para caché.
2. Evita personalización excesiva del lado del servidor: Todo lo que puedas hacer con JavaScript cliente, hazlo así.
3. Haz pruebas SIEMPRE después de activar caché: Navega tu sitio como visitante anónimo y verifica que todo funciona.

Optimización del servidor para caché

La caché de WordPress es importante, pero la base es el servidor.

PHP y OPcache

Sin OPcache todo lo demás es secundario.

Configuración óptima php.ini:

[opcache]
opcache.enable=1
opcache.enable_cli=0
opcache.memory_consumption=256
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=20000
opcache.max_wasted_percentage=5
opcache.use_cwd=1
opcache.validate_timestamps=1
opcache.revalidate_freq=2
opcache.save_comments=1
opcache.fast_shutdown=1

Explicación de parámetros críticos:

• opcache.memory_consumption=256: Memoria dedicada a OPcache. 128-256 MB es ideal para WordPress.
• opcache.interned_strings_buffer=16: Strings internos (nombres de variables, funciones…). 8-16 MB.
• opcache.max_accelerated_files=20000: Número máximo de archivos PHP a cachear. WordPress + plugins pueden ser 5000-10000 archivos.
• opcache.revalidate_freq=2: Cada cuántos segundos verificar si los archivos cambiaron. 2 segundos es un buen balance. En producción sin cambios frecuentes, puedes poner 60.
• opcache.validate_timestamps=1: Si está en 0, nunca verifica cambios (máximo rendimiento pero tienes que reiniciar PHP tras cambios).

Monitorización:

Instala el plugin OPcache Manager o crea un archivo opcache-status.php con phpinfo() dentro.

Busca estadísticas:

• Opcache Hit Rate: Debe ser > 99%
• Memory Usage: Debe tener espacio libre (no al 100 %)
• Cached Scripts: Ver cuántos archivos hay cacheados

Si el Hit Rate es bajo, aumenta memory_consumption y max_accelerated_files.

MySQL/MariaDB

La base de datos también necesita optimización.

Query cache (si aplica, MySQL < 8.0):

query_cache_type=1
query_cache_size=128M
query_cache_limit=2M

Pero recuerda, en MySQL 8.0+ esto no existe.

InnoDB buffer pool (lo realmente importante):

innodb_buffer_pool_size=2G
innodb_log_file_size=256M
innodb_flush_method=O_DIRECT
innodb_flush_log_at_trx_commit=2

• innodb_buffer_pool_size: Lo más importante. Debe ser 50 – 70 % de tu RAM (en servidor dedicado a MySQL). En compartido, lo que tu hosting asigne. 1-4 GB es típico.
• innodb_log_file_size: Archivos de log. 256 MB – 1 GB es bueno.
• innodb_flush_method=O_DIRECT: Optimiza I/O en Linux.

Optimizaciones complementarias:

max_connections=200
tmp_table_size=128M
max_heap_table_size=128M
table_open_cache=4000

Mantenimiento regular:

Ejecuta periódicamente consultas OPTIMIZE TABLE en las tablas principales de WordPress, a mano o con plugins como WP Rocket o Speed Optimizer.

Índices: WordPress tiene buenos índices por defecto, pero plugins añaden tablas. Revisa que tablas grandes tengan índices en columnas usadas en WHERE. En caso contrario optimiza los índices de la base de datos.

Nginx vs Apache vs LiteSpeed

Nginx:

Pros:

• Muy rápido para contenido estático
• Bajo consumo de memoria
• Excelente para alto tráfico
• FastCGI Cache integrado

Contras:

• No lee .htaccess (tienes que configurarlo manualmente)
• Curva de aprendizaje más alta
• Algunos plugins esperan Apache

Configuración típica para WordPress: Nginx con FastCGI Cache configurado para cachear respuestas PHP, con las rutas y excepciones apropiadas para WordPress.

Apache:

Pros:

• Compatible con .htaccess (plugins funcionan sin configuración)
• Más fácil para principiantes
• Más documentación para WordPress

Contras:

• Más lento que Nginx/LiteSpeed
• Mayor consumo de memoria
• Menos eficiente en alto tráfico

Cuándo usarlo: Hosting compartido que no ofrece alternativas, o si no quieres complicarte.

LiteSpeed:

Pros:

• Lo mejor de Apache (lee .htaccess) + velocidad de Nginx
• Caché integrada extremadamente rápida
• Plugin LiteSpeed Cache optimizado para él
• Drop-in replacement de Apache

Contras:

• De pago (aunque muchos hostings lo incluyen)
• Menos conocido que Nginx/Apache

Cuándo usarlo: Si tu hosting lo ofrece, úsalo sin dudarlo. Es la mejor opción para WordPress.

Recomendación:

• Hosting compartido: Lo que te den (suele ser Apache o LiteSpeed)
• VPS/Dedicado tú mismo: Nginx si sabes configurarlo, LiteSpeed si quieres facilidad
• WordPress gestionado: LiteSpeed es cada vez más común

Redis/Memcached en servidor

Instalar y configurar caché de objetos persistente.

Instalación Redis (Ubuntu/Debian):

sudo apt update
sudo apt install redis-server
sudo systemctl enable redis-server
sudo systemctl start redis-server

Configuración /etc/redis/redis.conf:

maxmemory 256mb
maxmemory-policy allkeys-lru

• maxmemory: Memoria máxima para Redis. 256MB-2GB según tu servidor.
• maxmemory-policy allkeys-lru: Cuando se llene, eliminar keys menos usadas.

Conectar WordPress:

1. Instalar plugin Redis Object Cache
2. Activar
3. El plugin buscará Redis en localhost:6379 (por defecto)
4. Hacer clic en «Enable Object Cache»

Verificar que funciona:

En el plugin verás estadísticas:

• Hit Rate: Debe subir a 90% o más tras usar la web un rato
• Memory Used: Debe crecer pero sin llenar la memoria asignada

Instalación Memcached (Ubuntu/Debian):

sudo apt update
sudo apt install memcached php-memcached
sudo systemctl enable memcached
sudo systemctl start memcached

Configuración /etc/memcached.conf:

-m 256
-p 11211
-l 127.0.0.1

Conectar WordPress:

1. Instalar plugin Object Cache 4 Everyone
2. Activar
3. Detectará Memcached automáticamente

Límites de memoria: No asignes toda tu RAM. Regla general:

• Redis/Memcached: 10 – 30 % de RAM
• PHP-FPM: 40 – 50 % de RAM
• MySQL: 20 – 40 % de RAM
• Sistema: 10 – 20 % de RAM

Persistencia vs volatilidad:

• Redis: Puede guardar datos en disco. Si el servidor se reinicia, no pierdes la caché.
• Memcached: Solo RAM, si se reinicia pierdes todo.

Para WordPress, ambos funcionan igual de bien. Redis tiene ventaja si quieres datos críticos persistentes.

Monitorización y métricas

¿Cómo sabes si la caché funciona realmente?

Cómo saber si la caché funciona

Hit rate vs miss rate:

• Hit: Petición servida desde caché (rápido)
• Miss: Petición que tuvo que generarse (lento)

Un buen hit rate es > 90 %. Si está por debajo del 70 % algo falla o casi mejor no usar caché.

Dónde ver el hit rate:

• Redis Object Cache plugin: Muestra hit rate en su dashboard
• LiteSpeed Cache: En Dashboard > Caché tiene estadísticas
• WP Rocket: No muestra hit rate (es caché de archivos)
• Cloudflare: Analytics > Performance muestra cache hit ratio

Herramientas de medición:

Query Monitor (plugin):

• Muestra todas las consultas SQL
• Cuántas están cacheadas
• Tiempo de cada consulta
• Imprescindible para debug

Object Cache Viewer (dentro de Query Monitor):

• Ver qué está en caché de objetos
• Hit/miss de cada consulta

Cabeceras HTTP a revisar:

Abre DevTools (F12) > Network > Recarga la página > Haz clic en el documento HTML > Headers.

Busca:

• X-Cache: HIT (Cloudflare/CDN)
• X-LiteSpeed-Cache: hit (LiteSpeed)
• X-Nginx-Cache: HIT (Nginx FastCGI)
• X-WP-Rocket: served-from-cache (WP Rocket)
• Cache-Control: max-age=... (caché de navegador)

Si ves estas cabeceras la caché funciona.

Pruebas y validación

Herramientas online:

GTmetrix (gtmetrix.com):

• Analiza velocidad de carga
• Muestra si los assets están cacheados
• Recomienda TTL
• Ve qué archivos no están comprimidos

Busca:

• «Add Expires headers» o «Leverage browser caching»: Si aparece, falta caché de navegador
• «Serve static assets with efficient cache policy»: Tu caché está mal configurada

Google PageSpeed Insights:

• Core Web Vitals (LCP, FID, CLS)
• Recomendaciones de caché
• Simulación móvil y escritorio

Objetivo: Puntuación > 90 en ambos.

WebPageTest (webpagetest.org):

• Tests muy avanzados
• Simular diferentes ubicaciones
• Ver cascada de carga (waterfall)
• Verificar caché de navegador

Plugins de debug:

• WP Rocket Debugger: Si usas WP Rocket, muestra info de caché en el HTML.
• LiteSpeed Cache Debug: En LiteSpeed Cache > General > Debug Level, actívalo temporalmente para ver qué cachea.
• Query Monitor: Ya mencionado, para caché de objetos.

Logs de servidor:

Si tienes acceso SSH, revisa logs de caché según tu configuración de servidor.

Problemas comunes y diagnóstico

Problema: Caché que no funciona

Síntomas: Las cabeceras no muestran caché, el sitio sigue lento.

Diagnóstico:

1. Verifica que el plugin está activado
2. Verifica que se generan archivos de caché (en /wp-content/cache/)
3. Verifica que no haya conflicto con otro plugin de caché
4. Verifica permisos de carpeta (755 para directorios, 644 para archivos)
5. Desactiva todos los plugins excepto caché, prueba. Si funciona, hay conflicto.

Solución:

• Purga toda la caché y regenera
• Desactiva/reactiva el plugin de caché
• Revisa los registros de error de PHP

Problema: Contenido desactualizado

Síntomas: Publicas algo nuevo pero no aparece.

Diagnóstico:

1. ¿Purgaste la caché después de publicar?
2. ¿El TTL es muy largo?
3. ¿CDN también tiene cacheado? (puede tener TTL diferente)

Solución:

• Configurar purga automática al publicar (WP Rocket, LiteSpeed lo hacen)
• Si usas Cloudflare, purgar caché en Cloudflare también
• Reducir TTL si necesitas actualizaciones más frecuentes

Problema: Caché que se llena demasiado

Síntomas: /wp-content/cache/ ocupa gigas, servidor sin espacio.

Diagnóstico:

1. ¿Tienda WooCommerce con muchos productos?
2. ¿Object Cache 4 Everyone sin Memcached? (genera muchos archivos)
3. ¿Sitio con miles de URLs?

Solución:

• Limitar precarga de caché
• Borrar /wp-content/cache/object/ manualmente
• Contratar hosting con más espacio
• Implementar Redis/Memcached en lugar de caché en disco

Problema: Problemas de purga

Síntomas: Purgas la caché pero algo sigue cacheado.

Diagnóstico:

1. ¿Tienes múltiples capas de caché? (plugin + servidor + CDN)
2. ¿El CDN tiene su propia caché?

Solución:

• Purgar todas las capas
• En Cloudflare: Caching > Purge Everything
• En servidor: Si tienes FastCGI Cache, purgarlo también
• En plugin: Purgar desde el plugin

Problema: Caché rompe funcionalidades

Síntomas: Formularios no funcionan, carrito WooCommerce se vacía, etc.

Diagnóstico:

1. ¿Qué funcionalidad falla?
2. ¿Es algo dinámico que no debería cachearse?

Solución:

• Excluir esas URLs de la caché
• Para WooCommerce: Verifica que /carrito/, /finalizar-compra/, /mi-cuenta/ (o como tengas definidas las URLs) estén excluidos
• Para formularios: Excluir página de contacto o asegurar que funciona por AJAX

Estrategia de implementación paso a paso

No implementes todo de golpe. Paso a paso.

Auditoría inicial

Antes de tocar nada, mide.

Qué medir antes de empezar:

1. Velocidad actual:
   • GTmetrix o PageSpeed Insights
   • Anota el tiempo de carga actual
   • Anota el tamaño de página
2. Recursos del servidor:
   • Uso de CPU (si tienes acceso)
   • Uso de RAM
   • Uso de disco
3. Consultas SQL:
   • Instala Query Monitor
   • Cuenta cuántas consultas hace la página de inicio
   • Anota tiempo total de consultas
4. OPcache:
   • ¿Está activo?
   • Si no, hablar con hosting para activarlo

Consejo importante: Anota todo en un documento. Después de implementar caché compararás.

Ejemplo:

• Antes de caché:
  • Velocidad en página de inicio: 3.2 segundos
  • Tamaño: 2.5 MB
  • Consultas SQL: 45
  • Tiempo consultas: 0.8s
  • OPcache: NO activo

Orden de implementación

Paso 1: OPcache

Antes de cualquier otra caché, asegúrate de que OPcache está activo. Sin esto, lo demás es menos efectivo.

Si tu hosting no lo ofrece, cambia de hosting.

Paso 2: Caché de objetos

Si tu hosting tiene Redis/Memcached:

• Instalar Redis Object Cache o usar Object Cache 4 Everyone
• Activar

Si no tiene:

• Instalar Object Cache 4 Everyone
• Funcionará con caché en disco

Medición: Usa Query Monitor para ver hit rate tras navegar un rato. Debería reducir consultas SQL en 30-50%.

Paso 3: Caché de página

Elegir plugin:

• WP Rocket si quieres simplicidad (pago)
• LiteSpeed Cache si tienes LiteSpeed server
• Speed Optimizer para todo tipo de usuario

Instalar, configurar básicamente, y activar.

Medición: Tiempo de carga debería caer drásticamente (50-70% más rápido).

Paso 4: Caché de navegador

La mayoría de plugins de caché lo configuran automáticamente. Verifica en GTmetrix que tus assets tienen Cache-Control con TTL largo.

Si no, añade a .htaccess las reglas apropiadas para configurar Expires headers.

Paso 5: CDN (opcional pero recomendado)

Configurar Cloudflare:

1. Crear cuenta en Cloudflare
2. Añadir tu dominio
3. Cambiar nameservers en tu registrador
4. Esperar propagación
5. Activar el minimizado y Rocket Loader

Medición: Velocidad debería mejorar especialmente para usuarios lejos de tu servidor.

Cuándo añadir la siguiente capa: Solo cuando hayas verificado que la anterior funciona correctamente.

No pases a CDN si la caché de página no funciona. No pases a caché de página si OPcache no está activo.

Testing progresivo: Después de cada paso:

1. Purga caché
2. Navega tu sitio como visitante anónimo
3. Verifica que todo funciona
4. Mide velocidad
5. Compara con baseline
6. Si hay mejora, siguiente paso
7. Si hay problemas, debug

Optimización continua

La primera configuración no es la definitiva. Hay que afinar.

Ajustar TTL:

Después de una semana, revisa:

• ¿Hay contenido desactualizado frecuentemente?
• Reduce TTL de esas páginas
• ¿Hay páginas que nunca cambian?
• Aumenta TTL de esas páginas

Refinar exclusiones:

Inicialmente excluyes de forma conservadora. Después:

• ¿Hay páginas excluidas que podrían cachearse?
• ¿Hay páginas cacheadas que causan problemas?

Ir refinando la lista de exclusiones.

Medir mejoras:

Cada semana o mes:

• GTmetrix otra vez
• Comparar con baseline inicial
• Comparar con medición anterior

Objetivo: Mejora continua, no perfección inmediata.

Cosas a probar:

• ¿El minimizado de CSS/JS mejora o empeora?
• ¿Lazy load ayuda?
• ¿Preload de caché vale la pena o sobrecarga el servidor?
• ¿CDN realmente mejora tiempos?

Haz pruebas activando/desactivando cada funcionalidad y midiendo.

¿Qué hemos aprendido?

Después de lo que hemos visto, estos son los que considero que son los aprendizajes más importantes:

1. Object cache es obligatoria para WooCommerce y plataformas dinámicas

Si tu web tiene muchas consultas a base de datos (tiendas, membresías, LMS), Redis o Memcached no son opcionales, son obligatorios. La diferencia es brutal: de 100+ consultas SQL a 10-15.

2. No todas las páginas necesitan el mismo TTL

Diferencia los tiempos de vida según el tipo de contenido:

• Página de inicio de noticias: 1 hora
• Entradas individuales: 24 horas o más
• Páginas de producto: 7 días
• Páginas estáticas: 30 días

3. Los plugins actualizados funcionan con caché

Contact Form 7, WooCommerce, LearnDash, etc. están preparados para funcionar con caché si están actualizados. El problema suele ser versiones antiguas.

4. El vaciado automático es fundamental

Configura siempre el vaciado automático de caché al publicar contenido. No dejes que los usuarios vean contenido viejo por no configurar esto.

5. Una CDN gratuita es suficiente para la mayoría

Cloudflare gratis proporciona CDN, minimizado, y protección DDoS gratis. Para el 90% de webs WordPress es más que suficiente.

6. Mide antes y después

Usa Query Monitor, GTmetrix, o PageSpeed Insights para medir antes y después. Los números no mienten y te ayudan a justificar inversiones en hosting mejor.

7. Hosting barato + caché agresiva > Hosting caro sin caché

Un hosting compartido de 5 €/mes con caché bien configurada rinde mejor que un VPS de 30 €/mes sin caché. La caché multiplica la capacidad de cualquier servidor.

8. No cachees el pago, carritos o áreas de usuario

Parece obvio pero es el error más común. Excluye siempre URLs con contenido personalizado o procesos de pago.

9. La velocidad mejora la conversión

En todos los casos vimos mejoras de conversión: formularios (+15 %), tienda (+18 %), cursos (+12 %). La velocidad importa para el negocio, no solo para SEO.

10. Empieza simple, escala según necesites

• Blog pequeño: WP Super Cache + Cloudflare gratuito (0 €)
• Web media: WP Rocket + Object Cache (60 €/año)
• Tienda grande: Speed Optimizer + Memcached + CDN premium (300 €/año)

No necesitas la configuración más compleja desde el día 1. Empieza por algo básico y ve escalando según crezcan tus necesidades y tráfico.

¿Te gustó este artículo? ¡Ni te imaginas lo que te estás perdiendo en YouTube!

---