Caché FastCGI de NGINX: cómo acelerar WordPress

Consigo acelerar WordPress de forma notable utilizando el Caché de NGINX a nivel de servidor y entrego respuestas HTML directamente. De este modo, el TTFB se reduce considerablemente, PHP-FPM queda libre y la base de datos procesa menos Consultas.

Puntos centrales

• Del lado del servidor En lugar de un plugin: FastCGI Cache alivia la carga de PHP y reduce la latencia.
• Purga En caso de cambios: los contenidos se mantienen actualizados y se renuevan de forma selectiva.
• Exclusiones Las áreas dinámicas de inicio de sesión, cesta de la compra y finalización de la compra se mantienen dinámicas.
• Escala bajo carga: las cachés se utilizan con mayor frecuencia y reducen la carga del servidor.
• Medible Más rápido: los valores de TTFB, RPS y CPU mejoran notablemente.

Cómo NGINX FastCGI Cache acelera WordPress

La primera vez que se accede a la página, WordPress la genera; a continuación, NGINX almacena la respuesta final como HTML y sirve las futuras solicitudes idénticas sin PHP-FPM. De este modo, reduzco el tiempo de CPU y los cambios de contexto, mientras que el sistema de archivos o la caché del sistema operativo proporcionan un rápido Hits proporciona. Precisamente en los picos de tráfico, el tiempo de respuesta se mantiene bajo, ya que no es necesario iniciar procesos PHP. De este modo, minimizo el TTFB y permito realizar más solicitudes por segundo. El resultado se traduce en una interacción más fluida, menos tiempos de espera y una clara reserva de rendimiento para procesos dinámicos reales.

Caché del servidor frente a caché de plugins (incluye comparación)

Un complemento de caché funciona en el Pila de PHP y, a menudo, activa procesos incluso cuando hay coincidencias, mientras que FastCGI Cache responde directamente a nivel del servidor web. De este modo, se eliminan muchas cargas adicionales, como la inicialización de PHP y los hooks de los plugins. Para los visitantes habituales, apuesto sobre todo por la solución del lado del servidor y la combino, si es necesario, con un plugin ligero de optimización del frontend. Quien quiera examinar los detalles a fondo, puede empezar con una versión simplificada Fase de prueba y mide por separado el TTFB, la CPU y la tasa de aciertos de la caché. Las diferencias se aprecian muy rápidamente, sobre todo bajo carga.

Criterio	Caché de plugins (PHP)	Caché FastCGI de NGINX
Modo de respuesta	Se inicializa PHP; el plugin comprueba la caché	El servidor web sirve el archivo directamente
TTFB	más alto debido al inicio de PHP	muy bajo cuando se produce una coincidencia en la caché
Recursos	más CPU/RAM por solicitud	muchos menos recursos
Escala	limitado por los procesos de PHP	se adapta de forma eficiente con NGINX
Dependencias	Posibles conflictos entre temas y plugins	funciona con WordPress

Además, utilizo claves de caché claras y una estructura de carpetas bien organizada, para que los contenidos se separen por host, esquema y URI. Si buscas una introducción al tema, puedes consultar mi guía sobre Optimización de la caché de NGINX utilizarlo como guía. De este modo, la configuración se mantiene clara y las futuras ampliaciones se llevan a cabo más rápidamente.

Escenarios adecuados y excepciones importantes

Quien más se beneficia Contenido, es decir, blogs, revistas, páginas de destino y sitios corporativos con muchas visitas anónimas. Almaceno en caché todas las páginas que permanecen idénticas para los visitantes y excluyo todo lo que sea personalizado. Entre ellas se incluyen el inicio de sesión, el perfil, los formularios de comentarios, el carrito de la compra de WooCommerce, la caja y «Mis cuentas». Las cookies y los encabezados sirven como criterio para eludir la caché de forma selectiva. De este modo, las páginas públicas siguen siendo rapidísimas, mientras que las áreas sensibles mantienen correctamente su carácter dinámico y los usuarios disfrutan de una experiencia fluida. sirve convertirse.

Conceptos técnicos básicos: zona de caché, clave, encabezado

En primer lugar, defino el Ruta de la caché y una zona en la configuración de NGINX, incluyendo el tamaño y el tiempo de inactividad. La clave de caché incluye el esquema, el host y el URI, así como cadenas de consulta opcionales, para que las variantes se almacenen por separado. Mediante las reglas `fastcgi_cache_valid`, `bypass` y `no-cache`, controlo cuándo las solicitudes eluden la caché. Los encabezados importantes, como «Set-Cookie», «Authorization» y determinadas cookies de WordPress o WooCommerce, indican dinamismo. Además, defino qué páginas de error o respuestas 50x se almacenan temporalmente en la caché para que la página siga funcionando bajo carga respuestas.

Gestión de la caché y estrategia de purga

Una caché solo da lo mejor de sí misma cuando las actualizaciones son fiables Despliegue. Al guardar una entrada, inicio una purga específica de las URL afectadas, incluidas las páginas de inicio, las categorías y los feeds. Además, establezco un TTL adecuado para que los contenidos se regeneren periódicamente. En sitios web de gran tamaño, la precarga resulta útil para las páginas de destino importantes, de modo que el primer visitante no experimente un arranque en frío. Tras cada modificación, compruebo la tasa de aciertos de la caché y si las purgas no dejan fragmentos obsoletos dejar.

Normas para WordPress y WooCommerce

Permito sistemáticamente a los usuarios que han iniciado sesión acceder a la caché ya ha pasado, normalmente mediante la cookie «wordpress_logged_in». En el caso de WooCommerce, excluyo el carrito, el proceso de pago y «Mi cuenta» mediante patrones URI y presto atención a cookies como «woocommerce_items_in_cart». En cambio, las páginas de productos, categorías y contenido las almaceno en caché de forma normal. Además, elimino la caché cuando el stock o el precio cambian mediante un hook. Esta separación mantiene rápidas las páginas públicas sin afectar a los procesos de compra. molestar.

Elegir correctamente el TTL, el «stale» y el «locking»

Establezco el TTL del contenido en función de la práctica, desde unos minutos hasta unas pocas horas, dependiendo de Actualidad y el tráfico. Las opciones «stale» me permiten servir objetos caducados de forma temporal, mientras se genera una versión actualizada en segundo plano. El bloqueo evita el «efecto estampida» cuando muchas solicitudes acceden simultáneamente a un objeto caducado. Las reglas adecuadas de error y tiempo de espera garantizan que los visitantes reciban una respuesta incluso en caso de una breve interrupción. Ofrezco más información sobre las directrices en mi breve Estrategias de control de la caché, que se pueden combinar bien con FastCGI Cache.

Seguimiento y valores de medición que realmente importan

Lo primero que hago es medir la TTFB, y a continuación las solicitudes por segundo y la carga de la CPU, desglosadas por aciertos y fallos de caché. Los registros de NGINX y los encabezados de respuesta me indican si se trata de un HIT, un MISS, un BYPASS o un EXPIRED. Un aumento de la tasa de aciertos junto con una disminución de la carga de la CPU es mi indicio de que las reglas están funcionando. Además, observo la E/S del sistema de archivos y el número de procesos PHP activos. Para el almacenamiento en caché condicional, utilizo ETag/Last-Modified de forma adecuada y remito a mi guía sobre Almacenamiento en caché condicional con ETag, para que la caché del navegador y la del servidor funcionen en armonía y la carga de la red se reduzca de forma notable cataratas.

Errores habituales y cómo los resuelvo

Un error muy común es que sea demasiado amplio Clave de caché, que enmascara las variantes y muestra contenidos erróneos. Igualmente crítico es que falten exclusiones para cookies como «wordpress_logged_in» o señales de WooCommerce. Si las purgas solo afectan a la página individual, las páginas de archivo y la página de inicio quedan desactualizadas; por eso amplío los destinos afectados. A menudo también necesito incluir las cadenas de consulta en la clave; de lo contrario, una variante sobrescribe a la otra. Los TTL demasiado cortos generan tasas de MISS innecesarias, mientras que los TTL demasiado largos aumentan el riesgo de que el contenido quede desactualizado Páginas.

Flujo de trabajo práctico para la implementación

Empiezo cada proyecto con un claro Plan: Definir objetivos, marcar las rutas que se van a almacenar en caché y establecer excepciones dinámicas. A continuación, configuro la ruta de caché, la zona, la clave y las reglas de encabezado. En el siguiente paso, compruebo los HIT/MISS, reviso las cookies y observo el TTFB bajo una prueba de carga ligera. A continuación, optimizo el TTL, el Stale y el Locking hasta que las curvas se vean coherentes. Para terminar, documento las rutas de purga, las responsabilidades y un breve procedimiento para los redactores, de modo que los contenidos siempre fresco permanecer.

Configuración práctica de NGINX y ejemplos

Considero que la configuración borrar Estructurado: una zona de caché central, una clave única, reglas de omisión claras y encabezados de diagnóstico útiles. Un buen punto de partida es el siguiente:

fastcgi_cache_path /var/cache/nginx levels=1:2 keys_zone=WORDPRESS:100m \
    inactive=60m use_temp_path=off loader_files=200 loader_sleep=50ms loader_threshold=300ms;

map $request_method $skip_non_get {
    default 1;
    GET 0;
    HEAD 0;
}

map $http_cookie $skip_cookie {
    default 0;
    ~*(wordpress_logged_in|comment_author|woocommerce_items_in_cart|wp_woocommerce_session|woocommerce_cart_hash) 1;
}

map $arg_preview $is_preview { por defecto 0; 1 1; }
map $request_uri $is_search { por defecto 0; ~*\?s= 1; }

server {
    # ...
    set $skip_cache 0;
    if ($skip_non_get) { set $skip_cache 1; }
    if ($skip_cookie)  { set $skip_cache 1; }
    if ($is_preview)   { set $skip_cache 1; }
    if ($is_search)    { set $skip_cache 1; }

    location ~ \.php$ {
 include fastcgi_params;
 fastcgi_pass unix:/run/php/php8.2-fpm.sock;

        fastcgi_cache WORDPRESS;
 fastcgi_cache_key "$scheme$request_method$host$request_uri";
 fastcgi_cache_bypass    $skip_cache;
        fastcgi_no_cache $skip_cache;

 fastcgi_cache_valid 200 301 302 10m;
        fastcgi_cache_valid 404 1m;
 fastcgi_cache_use_stale updating error timeout http_500 http_502 http_503;
 fastcgi_cache_lock on;
 fastcgi_cache_lock_timeout 5s;

        add_header X-Cache $upstream_cache_status always;
 add_header X-Cache-Key   $scheme$host$request_uri always;
    }
}

Más adelante ampliaré esto, en función del proyecto, con señales Vary (por ejemplo, idioma, moneda) y exclusiones más precisas. Importante: POST, PUT, DELETE y todo lo que contenga Autorización o Establecer cookie Lo omito sistemáticamente en PHP.

Estrategias de variantes y cookies en detalle

Cuantas menos variantes tenga un documento HTML, mayor será la tasa de aciertos. Reduzco las variantes de forma deliberada y solo separo aquellos casos en los que la La edición distingue:

• Idioma: Lo ideal es una única versión HTML adaptativa. Si hay versiones en diferentes idiomas, utilizo una cookie de idioma o la URI (por ejemplo, /de/, /en/) en la clave, no el User-Agent.
• Dispositivos: Evito los «UA-splits». El CSS «mobile-first» y los diseños adaptativos mantienen la caché compacto.
• Moneda/País: En las tiendas con geolocalización o selector de moneda, varío de forma selectiva en función de una cookie estable, no de la IP. De lo contrario, la cardinalidad se dispara.
• Cadenas de consulta: Incluyo en la lista blanca los parámetros útiles (por ejemplo, pagination, filter) e ignoro los parámetros de seguimiento (utm_*, gclid) para evitar que se generen variantes innecesarias.

Hay que tener especial cuidado con las cookies de los plugins de consentimiento o de banners: si ya instalan cookies en la página de inicio, NGINX puede interpretarlas erróneamente como dinámicas. Me encargo de que solo visual Los banners que no tengan repercusiones funcionales no activarán la cascada Cache-BYPASS.

Sistema de archivos, zona de caché y optimización del cargador

La elección de la memoria caché influye enormemente en el rendimiento. Yo utilizo SSD locales de alta velocidad y tengo previsto... keys_zone suficiente (por ejemplo, entre 100 y 256 MB para los índices), para que los metadatos no queden desplazados. El inactivo‑Determino el tiempo en función del perfil de tráfico: el contenido de cola larga se beneficia de un periodo de inactividad más prolongado, mientras que los portales muy dinámicos no tanto. Con los parámetros loader_* regulo la intensidad con la que NGINX precarga los objetos, para que el sistema, bajo carga, tranquilo permanece. Para sitios con mucho tráfico, puede ser útil utilizar una caché parcial en tmpfs, aunque en ese caso compruebo minuciosamente la presión sobre la RAM y el consumo de inodos. La rotación de registros y los límites en el número de archivos evitan que el volumen se llene; la supervisión controla la espera de E/S, el espacio libre y los descriptores de archivos abiertos.

Organizar adecuadamente las capas de la caché de la CDN y del navegador

Me gusta combinar la caché de NGINX con un Edge-CDN y unos valores TTL sólidos en el navegador. La regla es la siguiente: el origen (NGINX) proporciona páginas HTML coherentes, la CDN las almacena además en caché, y el navegador recibe valores «max-age» moderadamente cortos para que los editores puedan ver rápidamente los cambios. Mecanismos de caducidad y revalidarConfiguré las estrategias de manera que los nodos de Edge puedan seguir sirviendo contenido mientras NGINX vuelve a generar las páginas en segundo plano. Activo las purgas en un orden definido (primero la CDN, luego el origen) o de forma sincronizada en ambos lugares, para evitar que se produzcan flancos obsoletos. Además, compruebo que los encabezados de la CDN, como «Age», «Cache-Status» y «Vary», no entren en conflicto con las reglas de mi servidor.

Precalentamiento, implementación y flujos de trabajo editoriales

Para evitar que, tras un reinicio completo, miles de usuarios activen el arranque en frío, precaliento las páginas importantes. objetivo Por ejemplo: páginas de inicio, productos más vendidos, categorías, páginas centrales de la revista. Un precargador ligero lee el mapa del sitio, realiza las llamadas de forma paralela y respeta los límites de frecuencia, para que ni PHP ni la base de datos se saturen. En las implementaciones, distingo entre «full-flush» (cambio de tema o código) y «partial-flush» (actualización de contenido), y documento las Pasos para el equipo editorial y el equipo operativo. De este modo, los plazos de lanzamiento son breves y con pocos riesgos.

Multisitio, multilingüismo y lógica de divisas

En WordPress Multisite, separo las claves de caché estrictamente por nombre de host o ID de sitio, para que Subsitios están bien aisladas. Para las páginas multilingües con WPML/Polylang, prefiero utilizar rutas de idioma (de/en) o dominios específicos; en ese caso, la clave incluye el esquema, el host y la ruta. En las tiendas online, tengo muy en cuenta las cookies de moneda y la geolocalización: guardo en caché las vistas de productos y categorías por moneda, mientras que el carrito y la caja se mantienen dinámicos. Si cambian los precios o los tipos impositivos, activo un en parte Elimina (producto, categoría, módulos de avance) para que las páginas de inicio principales sean coherentes rápidamente.

Pruebas bajo carga, métricas y reversión

Antes de la puesta en marcha, simulo situaciones realistas Picos (mezcla GET/HEAD, recursos, HTML) y separo las mediciones de forma estricta: «warm» frente a «cold», con/sin CDN, usuarios registrados frente a anónimos. Analizo el P50/P95 del TTFB, las tasas de error, la saturación de la CPU, la espera de E/S y el número de procesos PHP. En NGINX, activo un formato de registro adecuado con $upstream_cache_status y compruebo muestras aleatorias directamente en el encabezado de respuesta (HIT/MISS/BYPASS/EXPIRED). Una ruta de reversión rápida (opción «Skip» para el funcionamiento de la caché, TTL reducido, desactivación de reglas concretas) me permite, en caso de anomalías, inmediatamente puede reaccionar sin desestabilizar el sistema en su conjunto.

Seguridad, exactitud y protección de datos

Evito sistemáticamente que los contenidos confidenciales se almacenen en la caché: áreas de administración, modos de vista previa, páginas privadas y acciones protegidas con nonce. Respeto la distinción entre HEAD y GET; las solicitudes POST no se pueden almacenar en la caché. Set-Cookie y Authorization se consideran reglas estrictas BYPASS‑Señales. Omito las páginas de vista previa (preview=true) y los resultados de búsqueda (s=) para evitar que se produzcan resultados erróneos. Además, compruebo que no haya datos personales en las respuestas HTML, que posteriormente quedarían almacenados ampliamente en la caché. Cuando es necesario, encapsulo los fragmentos personalizados mediante puntos finales AJAX independientes, que utilizo deliberadamente no caché.

Gestionar adecuadamente los casos extremos y las excepciones

Hay algunos patrones que se repiten constantemente: los mapas de sitio XML y los puntos finales de feeds los guardo en caché durante un breve periodo de tiempo (por ejemplo, entre 1 y 5 minutos). Las redirecciones 301/302 las revalido por separado para evitar bucles de redirección. Las páginas de archivo y de paginación reciben tiempos de vida (TTL) moderados, ya que suelen contener enlaces a fresco Contener datos. Los parámetros que solo influyen en la ordenación pueden incluirse en la clave, pero no deben acortar artificialmente el TTL. Y si un complemento establece cookies de forma inesperada, compruebo si estas son realmente necesarias para la salida HTML relevante son; de lo contrario, las marcaré como «ignorables» para evitar resultados BYPASS innecesarios.

Brevemente resumido

Con NGINX FastCGI Cache acelero WordPress en el Fuente, genera HTML directamente y evita costosos procesos PHP. Las exclusiones bien definidas y una purga fiable mantienen los contenidos actualizados, mientras que los valores de TTFB y CPU se reducen considerablemente. Un TTL práctico con funciones de «stale» y «locking» garantiza una entrega fluida incluso en picos de carga. Quien supervise de forma sistemática los valores de medición y ajuste continuamente las reglas, conseguirá páginas rápidas de forma sostenible. De este modo, el sitio web gana en capacidad de respuesta, sigue siendo fácil de mantener y crece sin problemas a medida que aumenta el Tráfico dentro.