Fastest Cache : acelera tu sitio con Varnish y NGINX

Procédure

¿Por qué acelerar la velocidad de carga de su sitio? 

Es bueno saber que la velocidad de carga de su sitio es primordial para garantizar su éxito. Para una empresa, por ejemplo, esto ofrece una primera imagen a sus visitantes. Además, una carga demasiado lenta de este último puede tener un impacto en el posicionamiento de su sitio en los principales motores de búsqueda y no permitirá una exposición suficiente para hacerlo crecer.

No existe un umbral que no deba superarse en lo que respecta a la carga de sus páginas web. Sin embargo, el tiempo de carga de la mayoría de los sitios de internet es inferior a tres segundos.

¿Qué es Fastest Cache y para qué sirve?

La herramienta Fastest Cache es un sistema diseñado y desarrollado por LWS que permite optimizar el rendimiento de carga de su sitio web gracias al uso de mecanismos de caché de página, configurados a nivel del servidor web. La herramienta combina las tecnologías aportadas por NGINX y Varnish.

NGINX es un servidor web orientado al rendimiento que permite gestionar muchas más solicitudes en comparación con el servidor web tradicional Apache HTTPd Server (consulte nuestra entrada de blog titulada “Apache VS Nginx : Test de performance”). LWS utiliza NGINX para poder recibir previamente un volumen elevado de solicitudes HTTP sin comprometer el rendimiento. A continuación, estas pueden filtrarse eficazmente y eliminar las solicitudes maliciosas (consulte LWS Protect) y dirigir las solicitudes HTTP al servidor de caché Varnish o LiteSpeed, según la elección del cliente desde su interfaz de alojamiento.

Varnish es un servicio HTTP que implementa un mecanismo de caché de página que permite almacenar en memoria RAM el resultado de una solicitud HTTP.

Con las configuraciones adecuadas, NGINX permite atender más solicitudes en su sitio web, y Varnish permite al mismo tiempo acelerar el tiempo de carga de su página y reducir su consumo de CPU y memoria RAM.

¿Cómo funciona el servicio Fastest Cache?

Funcionamiento sin caché

Para comprender mejor el funcionamiento, veremos primero cómo se desarrolla sin sistema de caché para que el visitante pueda ver su sitio.

1. El visitante solicita la página al servidor web. Ejemplo: index.php
2. El servidor web realiza las ejecuciones de scripts necesarias (PHP, Python, Node.js …)
3. El servidor web recibe el resultado de la ejecución
4. El servidor web envía la página HTML resultante de la ejecución del script

Funcionamiento con el módulo Fastest Cache

Cuando Fastest Cache está activado, un servidor de caché se introduce entre el visitante y el servidor web.

El objetivo es reducir el número de ejecuciones de scripts necesarias, manteniendo el resultado de la ejecución en memoria para las próximas solicitudes que requieran la misma respuesta. Esto permite no ejecutar varias veces el mismo script para obtener un mismo resultado.

Así, eliminamos el tiempo de espera de la ejecución del script en el tiempo de carga de la página y, al mismo tiempo, ahorramos los recursos utilizados durante la ejecución del script.

11. El visitante solicita la página al servidor web. Ejemplo: index.php
2. Fastest Cache verifica si la respuesta puede obtenerse desde la caché:

• Si sí, la página se devuelve directamente al visitante sin necesidad de acceder al servicio web y sin ejecutar el script
• Si no, la página es generada por el servidor web, lo que provoca la ejecución del script (PHP, Node.js, Perl, Ruby, …). Una vez generada la página, Fastest Cache determina si la respuesta puede guardarse en caché.
  • Si sí, la página se registra en la memoria caché y se devuelve al visitante
  • Si no, la página se devuelve al visitante sin ser registrada en la memoria caché

Se constata que cuando una página se almacena en la memoria caché, se evita el procesamiento por el servidor web así como la ejecución del script, lo que reduce considerablemente el tiempo de ejecución y el consumo de recursos.

Comportamiento del sistema de almacenamiento en caché

Fastest Cache se basa en múltiples señales para decidir el comportamiento de almacenamiento en caché adoptado:

• Extensión del archivo en la URL
• Presencia y contenido de los parámetros URL (query strings)
• Encabezado de respuesta Cache-Control
• Cookies

Fastest Cache también detecta ciertos CMS y extensiones / módulos e implementa comportamientos de almacenamiento en caché específicos relacionados con estas herramientas.

Comportamiento al recibir la solicitud

Fastest Cache solo almacena en caché los métodos HTTP GET y HEAD.

Cuando un visitante visita una URL, Fastest Cache normaliza la solicitud eliminando las cookies y parámetros de URL que no influyen en la representación final del script del lado del servidor (parámetros de URL de Google Analytics, cookies vinculadas a scripts Javascript ...).

Una vez normalizada, se verifica si la solicitud contiene una autenticación HTTP (encabezado de solicitud HTTP Authorization) o si quedan cookies (encabezado de solicitud HTTP Cookie). Si es así, la solicitud se devolverá al servidor web sin pasar por el sistema de caché.

Comportamiento al enviar la respuesta

Si la solicitud no ha eludido la caché en el momento de su recepción, Fastest Cache analiza de nuevo la respuesta HTTP proporcionada por el servidor web y verifica si es posible almacenar la respuesta en caché para un uso futuro.

Si la respuesta HTTP proporciona un encabezado de respuesta HTTP Cdn-Cache-Control, Fastest Cache respeta inmediatamente lo que allí se define :

• Si se define no-store, no-cache o private, Fastest Cache devuelve la respuesta al visitante sin guardarla en la caché.
• Si se define s-maxage o max-age, Fastest Cache utiliza inmediatamente este valor como tiempo de retención de la página en la caché.

Si Cdn-Cache-Control está definido junto con Set-Cookie, Cdn-Cache-Control será ignorado y la respuesta no se guardará en la caché.

Los archivos estáticos correspondientes a los temas, plugins, uploads y core de WordPress se guardan automáticamente en caché durante 30 días.

Si la respuesta HTTP proviene del sistema de caché de página LWS Optimize, WP Fastest Cache, Airlift, W3 Total Cache, WP Rocket, WP Optimize o FastPixel, esta se guarda en caché durante 7 días. Estos plugins de WordPress realizarán ellos mismos la purga de la caché Varnish cuando eliminen la caché de página.

Si la respuesta HTTP proviene del directorio /_next/static, también se guarda en caché durante 7 días.

Si la respuesta HTTP devuelve un código HTTP 404, esta se guarda en caché durante 900 segundos. Esto permite evitar más solicitudes innecesarias a la base de datos MySQL, en particular para WordPress.

Si la respuesta HTTP devuelve un código HTTP 500, la respuesta nunca se guarda en caché.

Si la respuesta HTTP contiene una cookie (encabezado de respuesta HTTP Set-Cookie), la respuesta nunca se guarda en caché.

Si la respuesta HTTP proporciona un encabezado de respuesta HTTP Cache-Control o Surrogate-Control, Fastest Cache sigue el comportamiento de caché esperado para los navegadores. Si estos encabezados se proporcionan con Cdn-Cache-Control, Fastest Cache ignora Cache-Control y Surrogate-Control en favor de Cdn-Cache-Control. Esto permite, por ejemplo, obligar al navegador a realizar una solicitud HTTP para consultar una lista de artículos en cada visita, sin que la lista de artículos esté ausente de la caché del servidor.

Presentación de la interfaz y activación del servicio

Fastest Cache se presenta en forma de un icono en cPanel en la sección “Performance”.

Una vez en la interfaz, el dominio principal, los dominios adicionales y los subdominios se muestran en la lista.

• La columna “Estado de la caché” muestra el estado de activación de la caché. Si está en “Activado”, entonces la caché está activada.
• El botón “Purgar la caché” permite eliminar todos los datos en caché para ese nombre de dominio en particular.
• El botón “Desactivar la caché” permite desactivar el almacenamiento en caché.
• El botón “Activar la caché” permite activar el almacenamiento en caché.
• El botón “Cambiar el modo de funcionamiento” permite modificar el comportamiento del sistema de caché. Estos modos se explicarán a continuación.

Los diferentes modos de caché

Por defecto, el sistema de caché opta por el modo « Uso general » que conviene a los usos generales. No obstante, existen otros modos:

Modo desarrollador : idéntico a la desactivación de la caché, esto permite eludir el sistema de caché durante sus periodos de desarrollo.
WordPress : un modo de caché más adaptado a WordPress en el que se mejora la gestión de los directorios (wp-content, wp-admin, …) y de las cookies específicas de WordPress.
Prestashop : un modo de caché más adaptado a Prestashop en el que se mejora la gestión de los directorios y de las cookies.

Purgado de la caché

Más allá de la interfaz cPanel que permite purgar la caché, es posible purgar manualmente la caché desde el terminal SSH de la cuenta cPanel o desde un script alojado en el servidor.

Ejecutadas desde su alojamiento (script PHP de su sitio, tarea Cron o terminal SSH), estas métodos no requieren ni token de API ni identificador: Fastest Cache acepta directamente los métodos HTTP PURGE.

Purgado de la caché con cURL

Purgar la caché de una página:

curl -X PURGE https://mon-site-web.com/mapage.php

Esto permitirá purgar la caché de la URL https://mon-site-web.com/mapage.php.

Purgar la caché de un directorio:

curl -X PURGE 'https://mon-site-web.com/wp-content/uploads/.*'

Esto permitirá purgar todas las cachés de las URLs que comiencen por 'https://mon-site-web.com/wp-content/uploads/'

Purgar la caché de un sitio

curl -X PURGE https://mon-site-web.com/.*

Para el conjunto de estos tres comandos, son posibles tres respuestas:

Código HTTP 200 : la purga se ha realizado correctamente sin error.

Código HTTP 4xx : la purga no está autorizada.

Código HTTP 5xx : se ha producido un error.

Purgado automático con un script PHP (tarea Cron)

El siguiente script vacía la caché de todo el sitio, o solo de algunas páginas. Cópielo en un archivo purge-cache.php de su alojamiento y luego indique su dominio en $site. Para purgar solo ciertas páginas, enumérelas en $pages.

 'PURGE',
        CURLOPT_RETURNTRANSFER => true,
        CURLOPT_CONNECTTIMEOUT => 5,
        CURLOPT_TIMEOUT        => 20,
    ]);
    curl_exec($ch);
    $code = curl_getinfo($ch, CURLINFO_HTTP_CODE);
    curl_close($ch);
    return $code;
}

if (empty($pages)) {
    echo date('Y-m-d H:i:s') . ' purga completa : HTTP ' . purger($site . '/.*') . PHP_EOL;
}
else {
    foreach ($pages as $page) {
        echo date('Y-m-d H:i:s') . ' ' . $page . ' : HTTP ' . purger($site . $page) . PHP_EOL;
    }
}

Para lanzarlo automáticamente, por ejemplo cada noche, cree una tarea Cron que ejecute este archivo con PHP. Si simplemente quiere vaciar toda la caché, la tarea Cron también puede ejecutar directamente:

curl -s -o /dev/null -X PURGE 'https://mon-site-web.com/.*'

Purgado con un plugin o módulo

La mayoría de los plugins/módulos que tienen una integración Varnish son compatibles con el mecanismo interno de purga de Fastest Cache.

Estos son algunos plugins probados y verificados como compatibles:

• LWS Optimize
• WP Fastest Cache
• WP Rocket
• Proxy Cache Purge

Detección HTTPS y redirecciones

El estado HTTPS y los puertos indicados en Apache se inyectan en el entorno y, por lo general, no requieren ninguna modificación adicional.

No obstante, si la detección HTTPS no funciona con Fastest Cache, esto puede causar bucles de redirección infinitos. Por lo tanto, será necesario modificar los datos de detección.

Los encabezados HTTP de confianza para la detección son:

• X-Forwarded-Proto
• X-Forwarded-Port

Así, si utiliza la siguiente redirección HTTPS con un .htaccess:

RewriteEngine On 
RewriteCond %{SERVER_PORT} ^80$
RewriteRule ^(.*)$ https://%{SERVER_NAME}%{REQUEST_URI} [L,R]

y si esto no funciona, puede reemplazar la variable SERVER_PORT por X-Forwarded-Proto :

RewriteEngine On
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteCond %{HTTPS} !on
RewriteRule ^(.*) https://%{HTTP_HOST}%{REQUEST_URI} [L,R]

CloudFlare y otros CDN

Los CDN de tipo CloudFlare pueden filtrar las solicitudes HTTP que podrían bloquear las solicitudes “PURGE” y utilizadas por Fastest Cache para purgar la caché. Entonces se recomienda precisar la dirección IP del servidor al purgar con curl para eludir los CDN durante las acciones de purga:

curl -X PURGE --resolve mon-site-web.com:443:IP_DU_SERVEUR 'https://mon-site-web.com/.*'

Los CDN también pueden contener una capa de caché adicional que debe gestionar independientemente de la caché proporcionada por Fastest Cache.