Ir al contenido 
invalidación de la caché de wordpress decide si los visitantes ven el contenido actual o acaban en costosas pausas de carga. La lentitud inesperada surge cuando las eliminaciones de caché van demasiado lejos, llegan demasiado tarde o chocan con plugins y reglas de CDN.
Puntos centrales
Resumiré brevemente los aspectos más importantes para que pueda tomar medidas específicas y evitar pérdidas de rendimiento innecesarias.
- InvalidaciónElimine las entradas de caché obsoletas sin ralentizar todo el sistema.
- TTLSeleccione los tiempos de ejecución para que el contenido se mantenga fresco y la carga sea baja.
- PrecargaRellena los alijos fríos con antelación para que el primer visitante no tenga que esperar.
- Caché de objetosReduzca los accesos a la base de datos y mantenga estables los tiempos de respuesta.
- ConflictosLos plugins de caché, la CDN y las normas de alojamiento deben armonizarse adecuadamente.
¿Qué significa realmente la invalidación de la caché en WordPress?
Invalidación de la caché en WordPress elimina específicamente las copias obsoletas de páginas, consultas o activos en cuanto cambian los datos originales. Si actualizo una entrada, el sistema debe reconocer las cachés afectadas: Caché de página, caché de objetos, caché del navegador y posiblemente la CDN. La tarea principal es entregar contenido fresco sin aumentar el tiempo de carga. Borrar demasiado crea un desierto de caché que ralentiza notablemente la recarga. Un borrado demasiado infrecuente proporciona información obsoleta, lo que cuesta confianza cuando se trata de precios, disponibilidad y noticias. Si se aplica correctamente, mantengo el índice de aciertos alto, los datos actualizados y el tiempo de respuesta corto.
¿Por qué de repente las páginas se cargan lentamente?
lentitud a menudo tiene una causa simple: cachés frías después de borrar demasiadas páginas o un cambio con un gran alcance. Si muchas páginas dejan de ser válidas al mismo tiempo, las nuevas peticiones llegan a la base de datos y a PHP sin control y crean congestión. TTLs incorrectamente configurados también conducen a fases cortas de alta carga, por ejemplo cuando muchas páginas populares se ejecutan al mismo tiempo. Los conflictos entre la caché del plugin, la caché del servidor y la CDN agravan el problema porque cada parte invalida de forma diferente. Si además hay código no optimizado o una base de datos hinchada, los tiempos de espera se hacen más frecuentes. Los tiempos de carga superan rápidamente la marca crítica de los 3 segundos, mientras que la caché limpia suele permanecer por debajo de los 500 milisegundos.
Comparación de métodos de invalidación de cachés
Elección de métodos decide si puedo crear actualidad y rapidez al mismo tiempo. La invalidación basada en el tiempo (TTL) es sencilla, pero puede provocar demasiado contenido nuevo o demasiado contenido obsoleto. La invalidación basada en eventos reacciona con precisión a los cambios y mantiene el contenido fresco de forma fiable. La eliminación selectiva se centra en las páginas o rutas afectadas y protege el resto de la caché. Los enfoques de "escritura a través" escriben los cambios en la caché y en la fuente de datos en paralelo, lo que parece limpio pero consume tiempo de computación. El borrado completo sigue siendo un freno de emergencia que evito porque produce picos de carga y ralentiza a los visitantes.
| Método | Puntos fuertes | Riesgos | Adecuado para |
|---|---|---|---|
| Basado en el tiempo (TTL) | Simple Sistema de control | El funcionamiento simultáneo genera carga | Páginas estáticas, activos, archivos |
| Impulsado por eventos | Contenido fresco sin Sobrecarga | Los eventos que faltan dejan datos obsoletos | Catálogos de productos, noticias, precios |
| Escritura directa | Alta Sincronicidad | Más E/S, cuellos de botella con mucho tráfico | Páginas de detalles críticos, pequeños conjuntos de datos |
| Purga selectiva | Suave Recursos | Requiere la asignación exacta de las teclas afectadas | Blogs, tiendas, portales |
| Purga total | Rápido Renovación | Caché fría, larga fase de reconstrucción | Solución de problemas, excepciones |
Práctico Combino TTL para archivos estáticos, eventos para contenido dinámico y purga selectiva para rutas afectadas. Esto mantiene la página de inicio, los productos más vendidos y las categorías calientes, mientras que sólo se recargan las páginas detalladas modificadas. En las CDN, confío en borrar rutas o etiquetas individuales en lugar de borrarlo todo. A nivel de servidor, utilizo grupos de caché para que las rutas de administración y API tengan reglas fijas. Esta mezcla reduce notablemente los tiempos de arranque y mantiene estable la tasa de respuesta.
WooCommerce y contenido personalizado
Tiendas requieren un cuidado especial porque la cesta de la compra, los precios o los grupos de clientes están personalizados. Caché HTML para Invitados agredir y aislar rutas sensibles: /cart, /checkout, /my-account, wc-ajax, admin-ajax.php, REST endpoints con auth. Cookies como woocommerce_items_in_cart, woocommerce_cart_hash, wp_woocommerce_session_*, wordpress_logged_in_* y woocommerce_recently_viewed señalan que el HTML ya no puede compartirse globalmente. En tales casos, establezco un Cookie-based Vary o eludir completamente la caché de la página.
Fragmentos como minicestas, listas de deseos o personalizaciones se encapsulan por separado: bien mediante ESI en el borde (minicomponentes con TTL corto) o en el lado del servidor como caché transitoria/fragmentada que sólo vuelve a mostrar estas áreas. De este modo, las páginas de categorías y las listas de productos se mantienen calientes, mientras que la cesta de la compra se muestra fresca. Importante: Los nonces, los tokens CSRF y los precios específicos de cliente no deben acabar en la caché global; o los mantengo fuera de la caché o los actualizo mediante JavaScript después de la carga de la página.
Precios y Disponibilidades a menudo cambian de forma asíncrona. En lugar de vaciar categorías completas, asigno las purgas a las páginas de productos afectadas, sus categorías, los archivos de marca y posiblemente la página de inicio si el artículo aparece allí. Para los cambios masivos (por ejemplo, importación de existencias), utilizo una cola de purga con backoff para que la CDN no alcance ningún límite de velocidad y el Origin no se sobrecaliente.
Configuración: de TTL a precarga de caché
TTLs Establezco duraciones escalonadas: Tiempos de ejecución largos para activos estáticos (por ejemplo, de 7 a 30 días), medios para páginas con cambios poco frecuentes (por ejemplo, de 1 a 6 horas) y cortos para rutas muy dinámicas (por ejemplo, de 5 a 20 minutos). Así evito procesos grandes y simultáneos. Además, alimento activamente la caché de la página para que el primer visitante real no se convierta en el probador del rendimiento del día. Para calentar, utilizo mapas del sitio, métricas internas y las últimas URL más visitadas de la semana. Una estructura Precalentamiento de la caché evita los bordes fríos y reduce el tiempo real del primer byte. Esto sigue siendo importante: Precarga específicamente después de despliegues o actualizaciones de precios para que no todo se inicie en frío a la vez.
Utilizar correctamente la caché de objetos
Caché de objetos (Redis o Memcached) ahorra consultas a la base de datos y estabiliza la página bajo carga. Garantizo un alto índice de aciertos almacenando en caché las consultas recurrentes, las opciones y los transitorios. Los objetos demasiado grandes o poco utilizados saturan la memoria y desplazan claves importantes, por lo que vigilo los tamaños máximos. La persistencia garantiza que el contenido de la caché sobreviva a los despliegues, mientras que el vaciado selectivo sólo afecta a los grupos modificados. Para páginas muy frecuentadas, una buena caché de objetos acelera la entrega en órdenes de magnitud, especialmente cuando llegan muchas peticiones similares. Si la caché está llena, controlo las estadísticas LRU y ajusto la memoria, los TTL y las excepciones.
Multisitio, multilingüismo y estrategias clave
Multisitio y Multilingüismo requieren espacios clave limpios. Separo las claves de la caché de objetos por ID/prefijo de blog para que las purgas no afecten accidentalmente a páginas vecinas. Para la caché de páginas, evito las variantes mixtas dando a las rutas de idioma (por ejemplo, /de/, /en/) o dominios sus propios cubos. Reglas variables en Aceptar idioma porque generan variantes incontroladas; en cambio, las URL de idioma único son más robustas.
Alcance de la purga ayuda a mantener bajo control las instancias grandes: Un mensaje en /es/ sólo invalida su variante de idioma, además de los archivos y feeds asociados. Las navegaciones, los pies de página y los widgets son a menudo multi-idioma o multi-página; les asigno sus propias claves sustitutas para limpiarlas específicamente cuando se actualizan los menús sin barrer sitios enteros. Para el mapeo de dominios, aseguro validaciones de CDN separadas por nombre de host para que no todos los clientes se enfríen al mismo tiempo.
Variantes móviles Sólo los separo si la estructura HTML difiere realmente. El diseño adaptable sin diferencias HTML no necesita una variante móvil, ya que de lo contrario se reduce innecesariamente a la mitad la tasa de aciertos. Cuando es necesario, utilizo una variación definida (por ejemplo, en una cookie de dispositivo independiente) en lugar de una división por agente de usuario, que produce demasiadas variantes.
Uso sin conflictos de las cachés de plugins y alojamiento
Conflictos surgen cuando una caché de plugin, una caché del lado del servidor y una CDN aplican sus propias reglas al mismo tiempo. Normalmente sólo dejo que una capa mantenga la caché de la página HTML y utilizo las otras capas principalmente para los activos y la entrega de bordes. Marco las rutas de administración, pago y personalización como no almacenables en caché para que las sesiones y las cestas de la compra permanezcan limpias. Si un host ya requiere Nginx microcaching o Varnish, desactivo las funciones de caché de páginas duplicadas en el plugin. Controlo las CDN mediante purgas de rutas o etiquetas y las vinculo a eventos de WordPress para que los cambios lleguen inmediatamente. Esto evita señales contradictorias y mantiene el control transparente.
Solución de problemas: contenido obsoleto y caché fría
Diagnóstico Empiezo por comprobar los encabezados: ¿Funcionan Cache-Control, Age y HIT/MISS como se espera? Luego compruebo los registros de purga y las tareas cron que pueden faltar o ejecutarse con muy poca frecuencia. Si las páginas permanecen frías, a menudo falta una precarga o el mapa del sitio no contiene las rutas pertinentes. El contenido obsoleto indica que faltan eventos o una categorización incorrecta, por ejemplo, si se actualizan las categorías pero sólo se vacían las entradas individuales. En el caso de fluctuaciones inexplicables, me fijo en los procesos TTL simultáneos de muchos vendedores importantes. Un despliegue selectivo de escalonamiento de TTL desenreda rápidamente este nudo.
ESI, caché de fragmentos y parcial
Almacenamiento en caché de fragmentos permite carcasas estáticas con islas dinámicas. Con ESI (Edge Side Includes), la CDN puede ensamblar una página a partir de varios bloques de construcción: El shell (TTL largo) más pequeños fragmentos como el estado de inicio de sesión o el minicart (TTL corto o sin caché). En el lado del servidor confío en Caché parcial a través de Transitorios/Opciones y agruparlos por función (p. ej. fragmento:menú:primario). Sólo se invalida el grupo afectado cuando cambian los menús, los banners o los bloques.
Nonces y los tokens de tiempo crítico no pertenecen a la caché global. Los renderizo en bloques ESI o los reemplazo después de la carga de la página mediante Ajax. Así se evitan los mensajes de error debidos a tokens caducados en las páginas almacenadas en caché. Para los sitios con mucho tráfico, vale la pena establecer un límite de renderización por fragmento más la coalescencia de peticiones para que cientos de peticiones no construyan la misma sección al mismo tiempo.
Trampas de rendimiento: Cache busting, cadenas de consulta, OPcache
Reventar la caché El uso de cadenas de consulta aleatorias (por ejemplo, ?v=123) hace que las cachés queden ciegas y crea variantes innecesarias. Sólo utilizo parámetros de versión de forma controlada, preferiblemente como parte del nombre del archivo en la construcción del activo. También tengo en cuenta el PHP OPcache: grandes cambios de código o invalidaciones frecuentes pueden desencadenar picos de latencia a corto plazo. Si suavizas los despliegues y ejecutas los reseteos de OPcache con moderación, TTFB funcionará más suavemente. Resumo los antecedentes y las contramedidas en mi artículo sobre el Validación de OPcache juntos. Estos detalles determinan si un lanzamiento va sobre ruedas o si todos los usuarios esperan al mismo tiempo.
Estrategias de caché HTTP: stale-while-revalidate, stale-if-error y coalescing
Stale-While-Revalidate sigue ofreciendo contenidos antiguos a los visitantes durante un breve periodo de tiempo mientras se crean nuevos contenidos en segundo plano. Esto mantiene bajo el tiempo de respuesta y evita picos de carga tras las purgas. Stale-If-Error garantiza la disponibilidad cuando Origin es débil: mejor contenido ligeramente obsoleto a corto plazo que errores 5xx. En combinación con Solicitar coalescencia (Reenvío colapsado), sólo una solicitud de origen es responsable de la recarga, todas las demás esperan o se quedan obsoletas.
Ejemplo de cabecera para páginas HTML con tiempos de búfer:
Cache-Control: public, max-age=300, stale-while-revalidate=30, stale-if-error=86400
Control-Sustituto: max-age=300, stale-while-revalidate=30, stale-if-error=86400
Vary: CookieAjuste finoPara las páginas muy frecuentadas, aumento stale-while-revalidate, para que todos los usuarios no esperen nunca una recarga. Para las páginas sensibles (por ejemplo, los resúmenes de precios), mantengo cortas las ventanas de inactividad. La coherencia entre Edge, el proxy y el navegador es importante: Los navegadores pueden tener max-age más estrictos, mientras que s-maxage/Surrogate-Control permite a la CDN retener más tiempo.
Establecer correctamente el encabezado HTTP
Encabezado controlan cómo los navegadores, proxies y CDNs almacenan en caché: Cache-Control, s-maxage, ETag y Vary influyen directamente en la tasa de aciertos. Para las páginas orientadas al usuario, establezco Vary en cookies o cabeceras para evitar resultados mixtos. Los activos estáticos reciben valores s-maxage largos en la CDN, mientras que el TTL del navegador se mantiene moderado para que lleguen las actualizaciones. Utilizo claves sustitutas para purgar colecciones específicas de páginas, como todos los posts de una categoría. Si mezclas directivas poco limpias, saboteas involuntariamente el almacenamiento en caché; puedes encontrar más detalles en Encabezado de caché HTTP explicado. Una estrategia limpia y coherente marca la diferencia entre un festival de golpes y una orgía de fallos.
API REST, búsqueda y configuraciones headless
API REST y GraphQL están predestinadas a la caché siempre que las peticiones sean anónimas e idempotentes (GET). Almaceno en caché las peticiones GET con cadenas de consulta a nivel de borde y en la caché de objetos, pero varían a Autorización y cabeceras relevantes para que no se compartan las respuestas personalizadas. Para las consultas de búsqueda (?s=), establezco un TTL moderado y normalizo los parámetros para evitar duplicados (por ejemplo, espacios, mayúsculas/minúsculas). Listas de resultados de WP_Query acaban en la caché de objetos con un TTL cuidadoso, mientras que suelo mantener corta la caché HTML de la página para los resultados de búsqueda.
Sin cabeza-Los frontends se benefician de la purga basada en etiquetas: un post modificado borra su recurso API y todas las listas/feeds que lo contienen. Agrupo las purgas en lotes y alivia Origin con coalescing. Los webhooks, las retrollamadas de pago y las acciones de administración siguen siendo estrictamente no almacenables en caché para que las integraciones funcionen de forma fiable.
Control y pruebas: medir en lugar de adivinar
Valores medidos aportan las pruebas: TTFB, ratio HIT/MISS, tasas de error, picos de carga y tiempos de calentamiento pertenecen al cuadro de mandos. Primero pruebo los cambios en el staging, compruebo las ejecuciones de formularios, los checkouts y las páginas personalizadas y simulo la carga con caché fría y caliente. Distribuyo los despliegues en ventanas de tiempo para que los TTL no terminen al mismo tiempo. Utilizo comprobaciones sintéticas para reconocer los grupos de páginas que se inician en frío con más frecuencia de lo previsto. Las pruebas A/B de los TTL y los intervalos de precarga muestran dónde puedo ahorrar recursos sin perder frescura. Si se mide con transparencia, se pueden encontrar los tornillos de ajuste de forma rápida y fiable.
Estrategias de lanzamiento y despliegue
lanzamientos Planifico cuidadosamente: antes de un despliegue, caliento las rutas críticas (página de inicio, categorías, principales vendedores) de forma selectiva. Cambio las versiones de los activos de forma controlada sin crear variantes HTML innecesarias. Ejecuto los reseteos de OPcache por etapas y fuera de las horas punta para minimizar los picos de latencia. Tras el despliegue, activo purgas selectivas (etiquetas/rutas) en lugar de vaciar toda la CDN.
Orquestación de la purga evita los límites de tarifa: Reúno los eventos (postactualización, cambio de menú, importación de precios) en una cola, desduplico los objetivos idénticos (debounce) y envío lotes a intervalos fijos. Para sitios muy grandes, añado un período de gracia-Mecanismo: Primero purga en una parte de los bordes, luego calentamiento, luego despliegue global. Así se mantiene baja la tasa de error, aunque cambien muchos recursos.
Estufa atronadora Evito esto con microcaching (TTLs cortos en el rango de segundos), coalescencia y estrategias stale. Los bloqueos ocupados de Nginx/varnish y el reenvío colapsado de CDN garantizan que no haya más de una solicitud que desencadene la reconstrucción. El resultado son latencias suaves, incluso inmediatamente después de las purgas o durante los picos de tráfico.
Reflexiones finales
Resumido Mantengo WordPress rápido planificando deliberadamente las invalidaciones en lugar de borrarlas de forma generalizada. Los eventos se limpian de forma selectiva, la purga selectiva protege las partes calientes de la caché y los TTL graduados evitan las olas de carga. Una precarga activa hace que el primer golpe sea rápido, mientras que la caché de objetos y las cabeceras limpias estabilizan la base. Las purgas registradas de forma coherente, las tareas cron fiables y las rutinas de despliegue limpias evitan sorpresas desagradables. Si resuelve los conflictos entre las cachés de plugins, servidores y CDN y se toma en serio la supervisión, conseguirá tiempos de carga cortos, contenidos frescos y mejores clasificaciones. De este modo, el rendimiento se convierte en una fuerte constante en lugar de un milagro diario.
