Ir al contenido 
Sin Caché de página completa WordPress procesa cada solicitud de forma dinámica: PHP, la base de datos y los plugins se ejecutan con cada llamada, lo que limita la escalabilidad de las páginas grandes. Como resultado, el TTFB, la carga del servidor y las tasas de error aumentan drásticamente durante los picos de tráfico, mientras que las señales de SEO y la conversión se ven afectadas hasta que la página se ralentiza bajo una carga elevada. Carga se baja.
Puntos centrales
Antes de profundizar más, resumiré brevemente los puntos principales para que se entiendan mejor los aspectos más importantes. Hechos están claras desde el principio.
- Carga del servidor: El renderizado dinámico en cada solicitud provoca rápidamente picos de CPU y tiempos de espera.
- TTFB: Sin caché, el tiempo de espera aumenta considerablemente, mientras que con Full Page Cache se reduce a unos pocos milisegundos.
- SEO: Los tiempos de carga deficientes perjudican los Core Web Vitals y los rankings.
- Escala: Solo Full Page Cache hace que el alto número de accesos simultáneos sea viable.
- Estrategia: Page-, Object-, OPcache y Browser-Cache se utilizan en conjunto.
Por qué el renderizado dinámico no se adapta
WordPress genera HTML cada vez que se accede a él, carga Plugins, ejecuta Hooks y consulta la base de datos, lo que funciona cuando hay poco tráfico, pero se colapsa cuando hay picos de visitas. Cada visitante adicional aumenta el número de consultas y el tiempo de ejecución de PHP, lo que sobrecarga la CPU. Los temas grandes, los constructores y los plugins de SEO aumentan la Trabajo por solicitud. Si hay 1000 usuarios simultáneos, la carga se multiplica exponencialmente hasta que el servidor web rechaza las solicitudes. En las auditorías, a menudo veo TTFB de 300-500 ms en reposo, que aumentan a segundos bajo carga y UX arruinar.
Qué hace Full Page Cache
Full Page Cache almacena la página completamente renderizada como estática. HTML y responde a las solicitudes posteriores sin PHP y sin base de datos. Las variantes del lado del servidor, como Nginx fastcgi_cache, entregan el contenido antes de la capa PHP y reducen el TTFB a unos pocos milisegundos. Para los usuarios anónimos, que a menudo representan entre el 90 y el 95 % del tráfico, casi todas las páginas provienen de la caché. Controlo la validez (TTL), las reglas de purga y las excepciones con cookies o variantes de URL para que las áreas dinámicas sigan siendo correctas. De esta manera, reduzco el CPU-Tiempo por solicitud drásticamente y gana escalabilidad real.
Sin caché: cifras y consecuencias
Las instancias de WordPress sin caché generan entre decenas y cientos por cada llamada. Consultas y funcionan bajo carga con un uso de CPU de 100 %. A partir de 3 segundos de tiempo de carga, la tasa de rebote aumenta significativamente, lo que afecta directamente a las ventas y los clientes potenciales. Los Core Web Vitals, como el LCP, disminuyen porque el servidor tarda demasiado en enviar el primer byte. Con 10 000 usuarios por hora, observo con frecuencia tasas de error y acumulación de colas. La siguiente tabla muestra las diferencias típicas que observo habitualmente en los proyectos. feria:
| Aspecto | Sin caché de página completa | Con caché de página completa |
|---|---|---|
| TTFB | 200-500 ms | < 50 ms |
| Carga del servidor con 10 000 usuarios | CPU 100 %, error | 20-30 CPU % |
| Escalabilidad | hasta aprox. 1k simultáneamente | alta simultaneidad |
| Impacto SEO | valores bajos | valores sólidos |
Combinar de forma inteligente el almacenamiento en caché de varios niveles
Yo pongo Full Page Cache como primera opción. Nivel y complétalo con Object Cache (Redis o Memcached) para que los resultados recurrentes de la base de datos se almacenen en la RAM. OPcache mantiene el código byte de PHP y ahorra tiempo de ejecución, lo que reduce notablemente el rendimiento del backend. El almacenamiento en caché del navegador reduce las solicitudes de activos estáticos como CSS, JS e imágenes. Sin Full Page Cache, estas medidas siguen siendo limitadas, ya que el HTML se sigue generando dinámicamente. Si quieres entender las diferencias y los ámbitos de aplicación, consulta Tipos de caché Una clara delimitación de los mecanismos que utilizo a diario.
Almacenamiento en caché del lado del servidor con Nginx fastcgi_cache
Nginx entrega páginas almacenadas en caché directamente desde el Memoria o desde SSD, antes incluso de que se inicie PHP: esa es la disciplina reina. Defino claves con host, ruta y cookies relevantes, establezco TTL significativos y reglas de „bypass“ para los usuarios que han iniciado sesión. Un plugin como Nginx Helper controla de forma fiable las purgas tras las publicaciones y actualizaciones. Junto con un control de caché bien configurado a nivel de activos, los picos de carga desaparecen incluso en las campañas. Si desea profundizar más, utilice la guía sobre Almacenamiento en caché del servidor y aplica las medidas con rapidez.
Uso adecuado del almacenamiento en caché perimetral y la CDN
Con un alcance global, reduzco la distancia al Usuarios con almacenamiento en caché perimetral a través de una CDN. Cloudflare APO puede almacenar HTML en caché en el perímetro, reduciendo así el TTFB en todo el mundo. Es importante un enrutamiento limpio de las cookies y las áreas dinámicas para que las partes personalizadas sigan siendo correctas. Para noticias, revistas y blogs, APO ofrece ventajas cuantificables en la primera visita. Una forma práctica de empezar es el Prueba de Cloudflare APO, que muestra el efecto sobre los tiempos de carga y la carga.
Acelerar WooCommerce y los usuarios registrados de forma específica
Las tiendas viven de áreas personalizadas como el carrito de la compra, el proceso de pago y „Mi cuenta“, que yo deliberadamente no Caché completa. En su lugar, la caché de objetos gestiona consultas costosas, mientras que yo utilizo una caché de página completa agresiva para las páginas de categorías y las listas de productos. Las técnicas de cookie-vary y fragmentos permiten mantener los widgets individuales de forma dinámica. Me aseguro de no establecer cookies de carrito en cada visita a la página, para que la caché de la página no se omita accidentalmente. De este modo, el proceso de pago sigue siendo receptivo y las páginas de categorías se cargan rápidamente a pesar de los picos de tráfico. de.
Errores típicos de caché y cómo evitarlos
Un error frecuente es almacenar en caché páginas con datos personales. Contenido, lo que genera gastos innecesarios. Igualmente críticos son los TTL demasiado cortos, que apenas permiten acceder a la caché, o los TTL demasiado largos, que retrasan las actualizaciones. Defino eventos de purga claros para publicar, actualizar y eliminar, con el fin de evitar inconsistencias. También controlo las cadenas de consulta que generan variantes innecesarias. Para evitar las estampidas de caché, utilizo bloqueos o microcachés, de modo que no se produzcan miles de Procesos Reconstruir la misma página.
Pasos para la implementación sin rodeos
Empiezo con un entorno de host que Nginx, PHP-FPM, OPcache y Redis para que todos los niveles funcionen juntos. A continuación, activo Full Page Cache en el servidor y compruebo con curl y los encabezados de respuesta si „HIT“ aparece de forma fiable. Después, configuro la purga mediante un plugin adecuado y pruebo las actualizaciones en entradas, menús y widgets. Para la caché de objetos, configuro Redis con memoria persistente y compruebo la tasa de aciertos mediante la supervisión. Por último, refuerzo el control de la caché para los activos, compruebo HTTP/2 o HTTP/3 y mantengo TTFB y LCP a la vista.
Costes, elección del alojamiento y escalabilidad real
El alojamiento compartido comparte recursos y ralentiza los grandes archivos sin almacenar en caché. Páginas de inmediato. Un VPS o un servidor gestionado con CPU dedicada y SSD NVMe rápido permite un almacenamiento en caché real del lado del servidor y un rendimiento planificable. Con Full Page Cache, los costes de infraestructura suelen reducirse, ya que se necesita menos potencia bruta. A menudo observo que una pila bien almacenada en caché puede soportar picos que antes solo eran posibles con costosas actualizaciones. De este modo, el presupuesto sigue siendo calculable y la experiencia del usuario es fiable. rápido.
Invalidación de caché en la práctica
La caché solo es tan buena como su invalidación. Trabajo con eventos (publicar, actualizar, eliminar) para purgar específicamente las URL afectadas: la propia entrada, la página de inicio, las páginas de categorías, etiquetas y autores, así como las paginaciones relevantes. En WooCommerce, se añaden las páginas de productos, categorías y, si procede, de ventas adicionales y cruzadas. En lugar de borrar „todo“ de forma global, utilizo patrones (por ejemplo, rutas de una taxonomía) y mantengo la invalidación estricta. Esto evita los desiertos de caché y reduce la presión sobre el origen. Después de las purgas, caliento automáticamente las rutas críticas (basadas en el mapa del sitio o el menú) para que las rutas más populares aparezcan inmediatamente como HIT. Para el contenido de alta rotación, establezco TTL cortos y los prolongo con estrategias de caducidad (véase más abajo) para lograr un buen equilibrio entre actualidad y estabilidad.
Vary, cookies y excepciones seguras
El Claves de caché Las defino de tal manera que solo contengan variantes relevantes: host, ruta, lista blanca de cadenas de consulta y unas pocas cookies. Las excepciones estándar son wp_logged_in, wordpress_logged_in, comment_author, admin_bar y las cookies específicas de WooCommerce para el carrito y la sesión. Las cookies excesivas de marketing o de pruebas A/B destruyen la tasa de aciertos, por lo que las bloqueo para las páginas anónimas o las normalizo desde la clave. Además, ignoro los parámetros UTM, fbclid o gclid para que no se creen nuevas variantes por campaña. Las solicitudes POST, las vistas previas, el administrador, XML-RPC y los puntos finales REST relacionados con la sesión siempre pasan por alto la caché. Si es necesaria la personalización, la aíslo: pequeños fragmentos Ajax, Edge-Includes o fragmentos de widgets controlados por cookies, sin dejar toda la página sin caché.
Estrategias de precalentamiento y estancamiento
Después de implementaciones o purgas importantes, no quiero cachés frías. Apuesto por Precalentamiento con una lista de prioridades (URL principales, páginas de categorías, navegación, mapas del sitio), para que los primeros usuarios no soporten toda la carga PHP. Además, utilizo la semántica „stale-while-revalidate“ y „stale-if-error“: las páginas caducadas pueden seguir sirviéndose durante un breve periodo de tiempo, mientras se ejecuta una actualización en segundo plano o el origen está bajo carga. Esto estabiliza los inicios de las campañas y evita oleadas de errores. En el caso de puntos finales similares a API o páginas muy frecuentadas, ayuda Microcachés (unos segundos) para evitar estampidas sin perder actualidad.
Monitorización, KPI y comprobaciones de encabezados
Escalar sin medir es como volar a ciegas. Realizo un seguimiento de la tasa de aciertos de la caché (global y por ruta), TTFB P50/P95, Origin-QPS, CPU, memoria, E/S, desalojos y volumen de purga. En los encabezados de respuesta, dejo valores de estado claros (por ejemplo, caché X o caché FastCGI: HIT/BYPASS/MISS/STALE) y utilizo la sincronización del servidor para visualizar los tiempos. En cuanto a los registros, evalúo combinaciones de código de estado, tiempo de respuesta ascendente y estado de la caché para identificar cuellos de botella. En el lado del cliente, combino pruebas sintéticas con datos RUM para cubrir las rutas reales de los usuarios (primera visita, navegación, pago). Objetivos: >90 % HIT con tráfico anónimo, TTFB < 50 ms para páginas almacenadas en caché, P95 estable incluso con carga máxima.
Antipatrones de código y plugins
Muchos problemas de rendimiento surgen en el código. Evito las sesiones PHP, las salidas aleatorias en cada solicitud y los encabezados „nocache“ sin necesidad. En lugar de transitorios en la base de datos, utilizo el Caché de objetos (Redis) con TTL significativos e invalidación selectiva. wp-admin-ajax no debe convertirse en un arma multiuso: encapsulo las acciones costosas en puntos finales REST almacenados en caché, cuyas respuestas mantengo temporalmente en la RAM. Reduzco los intervalos de latido, agrupo las tareas cron y las ejecuto de forma asíncrona. Los feeds, los mapas de sitio y los agregados GraphQL/REST tienen su propia microcaché. Importante: los nonces y los datos personales no deben pasar a fragmentos HTML almacenados en caché; para ello, utilizo pequeñas islas dinámicas o sustituyo valores del lado del cliente.
Multisitio, multilingüismo y cadenas de consulta
En configuraciones multisitio o multilingües, la variante (dominio/subdominio/ruta) debe incluirse obligatoriamente en la clave. Defino explícitamente los parámetros de idioma (lang, locale) o los prefijos de ruta como Vary, para que las traducciones no se mezclen. Evito las variantes móviles mediante la detección de agentes de usuario. sensible El marcado y el CSS suelen ser la mejor solución, ya que un UA-Vary aumenta el tamaño de la caché. Para las páginas de filtro y búsqueda, trabajo con cadenas de consulta.Listas de permitidos, para que solo los parámetros relevantes influyan en la clave. Los parámetros de seguimiento se eliminan o normalizan. Las paginaciones reciben un almacenamiento en caché separado, pero agresivo, con un TTL más corto para reducir el rastreo y la carga útil.
Seguridad, protección de datos y cumplimiento de la normativa
Nunca almaceno en caché páginas con datos personales, información de cuentas o tokens. Para los formularios, utilizo „no-store“ o bypass específicos cuando hay CSRF-Nonces en juego. La barra de administración, los modos de vista previa y las entradas privadas permanecen fuera de la caché; las cookies correspondientes son criterios de exclusión estrictos. A nivel de servidor, evito que las URL privadas o borradores terminen accidentalmente en cachés Edge u Origin. Enmascaré los registros y los encabezados para que no se muestren valores de cookies o ID sensibles. Especialmente en el contexto de la UE, es importante que la caché no conserve contenido personal y que todas las purgas funcionen de manera confiable.
Pruebas de carga, implementación y funcionamiento
Antes de lanzar grandes campañas, simulo la carga de forma realista: arranque en frío, rampas de tráfico, picos y campañas de larga duración. Mido las tasas de HIT y TTFB bajo carga y compruebo si las purgas afectan a la estabilidad. Los lanzamientos se realizan de forma preferente. Azul/Verde o como Canary con TTL conservadores, lo que me permite volver atrás inmediatamente si es necesario sin confundir la jerarquía de la caché. Para el funcionamiento, defino runbooks claros: ¿cómo purgar de forma selectiva? ¿Cómo precalentar? ¿Qué umbrales activan las alarmas? ¿Y cuándo escalar horizontalmente (más trabajadores PHP) frente a verticalmente (CPU/IO más rápidos)? Una pila bien configurada puede soportar de forma predecible incluso picos de tráfico repentinos.
Ajuste fino de la estrategia de activos
Para que el almacenamiento en caché HTML funcione correctamente, los activos deben estar a la altura. Yo trabajo con Reventar la caché Utiliza hash de nombres de archivo, establece TTL largos (meses) y garantiza referencias coherentes en las implementaciones. Gzip o Brotli son obligatorios, HTTP/2/3 reduce las latencias y los puntos críticos de división CSS/JS evitan el bloqueo de la renderización. Es importante que los encabezados de los activos no se vean afectados por sobrescrituras imprudentes de los complementos: mantengo Cache-Control y ETag consistentes y evito reescrituras agresivas que eluden las cachés.
Controles operativos y garantía de calidad
Por último, compruebo regularmente los aspectos básicos: ¿Se garantiza que el inicio de sesión del administrador sea un BYPASS? ¿Se aplica a los usuarios anónimos en todas las rutas principales? HIT¿Las vistas previas permanecen sin almacenar en caché? ¿Funcionan correctamente los feeds, los mapas del sitio, la búsqueda y las páginas 404? ¿Coinciden los TTL entre Edge y Origin? ¿Cuál es la tasa de EVICTION y hay teclas de acceso rápido que desplacen la caché? En la práctica, estas comprobaciones rutinarias evitan la mayoría de las escaladas, ya que detectan los problemas antes de que el tráfico los haga visibles.
Brevemente resumido
Sin Caché de página completa procesa cada solicitud en PHP y la base de datos, lo que bajo carga provoca tiempos de espera excesivos, un TTFB deficiente y conversiones perdidas en cuestión de segundos. Con Full Page Cache, respondo a la mayoría de las visitas a la página desde la memoria y reduzco drásticamente la carga de la CPU. Solo la combinación de Full Page, Object Cache, OPcache y un almacenamiento en caché del navegador adecuado hace que las grandes páginas de WordPress sean realmente viables. Nginx fastcgi_cache más una purga limpia proporciona las respuestas HTML de forma rápida y sin errores a los usuarios anónimos. Si planeas alcanzar un gran alcance o ya lo has logrado, no puedes prescindir del almacenamiento en caché del lado del servidor si quieres que la página sea fiable. Escala debería.
