¿Se ve el aviso de «Specify a cache validator» en Pingdom, GTmetrix, o Google PageSpeed Insights en su sitio WordPress? Esto se debe a la falta de las cabeceras de HTTP caching que deberían ser incluidas en todas las respuestas de servidores de origen ya que validan y configuran la longitud de la cache. Si no se encuentran las cabeceras eso generará unas solicitudes nuevas para los recursos cada vez que aumenta la carga en su servidor. El uso de cabeceras de caching asegura que las solicitudes posteriores no tengan que ser cargadas desde el servidor así ahorrando del ancho de banda y mejorando el rendimiento para el usuario.
El aviso de Pingdom dice:
A los siguientes recursos falta cache validator. Recursos que no especifican cache validator no pueden ser actualizados eficientemente. Especifique una cabecera Last-Modified o ETag para habilitar cache validation para los recursos siguientes.
Siga los pasos a continuación para saber cómo solucionar “Specify a cache validator”.
Solucionar el Aviso de «Specify a Cache Validator»
La primera cosa para tener en cuenta sobre este aviso es que solamente se puede arreglarlo en caso de solicitudes que están en su servidor. Si tiene solicitudes de terceros y aparece esta advertencia no se puede hacer nada ya que usted no tiene control de sus servidores web. Sin embargo siéntase libre de compartir este artículo con ellos. Y no se olvide con Pingdom debe ejecutar el test unas cuantas veces. Puede ser que el aviso aparezca la primera vez y desaparezca para la segunda. Al ejecutar la herramienta por primera vez el instrumento prepara la cache de los activos del servidor.
Existen cuatro cabeceras diferentes que pueden ser utilizadas en formas distintas para arreglar este problema. Aquí puede confundirse un poco pero trataremos de explicar lo más fácil posible.
Cabeceras que Validan la Cache
Las primeras dos son last-modified and ETag. Estas cabeceras ayudan al navegador determinar si el archivo ha cambiado desde la última vez que fue solicitada. O más bien validan la cahce.
1. Last-Modified
La cabecera last-modified en general es enviada automáticamente desde el servidor. Esta en general es una cabecera que no es necesario que añada manualmente. Es mandada para averiguar si el archivo en la cache del navegador fue modificada desde la última vez que fue solicitada. Se puede ver en la solicitud de cabecera de Pingdom o utilizar Chrome DevTools para ver el valor de la cabecera que se modificó por última vez.
2. ETag
La cabecera ETag es muy similar a la que fue modificada por última vez. Es usada también para validar la cache de un archivo. Si está ejecutando Apache 2.4 o una versión más reciente la cabecera ETag es añadida automáticamente utilizando FileETag directive. En el caso de NGINX la cabecera ETag es habilitada por defecto desde 2016.
Pueden habilitar la cabecera ETag manualmente en NGINX usando el siguiente código.
etag onCabeceras que Determinan la Longitud de la Cache
Las siguientes cabeceras son Cache-Control y Expires.Estas dos ayudan a determinar qué tiempo el archivo debería ser retenido en cache antes de que vaya a buscar nueva copia desde el servidor. Recuerde arreglar las advertencias que ve en Pingdom o GTmetrix, debe asegurarse de que tenga una cabecera que valide la cache así como determine su longitud.
3. Cache-Control
Cache-Control es una cabecera hecha por directivas diferentes que le permite definir la longitud de la cache. Algunas de las directivas más comunes incluyen:
- max-age: Define la cantidad de tiempo que archivo debería ser cacheado
- public: Permite para cualquier cache públicamente que almacene la respuesta.
- private: Cacheable solamente por navegador que está accediendo el archivo.
En nuestro ejemplo arriba podemos ver que el activo está usando la directiva max-age. 604800 segundos equivale una cache de siete días. Para configurar esto en Apache añada el código siguiente a su archivo .htaccess.
<filesMatch ".(ico|pdf|flv|jpg|jpeg|png|gif|js|css|swf)$">
Header set Cache-Control "max-age=604800, public"
</filesMatch>Para configurar los mismo en NGINX simplemente añada el siguiente código a su archivo config. TODOS los archivos de configuración de NGINX están ubicados en el directorio /etc/nginx/. El archivo de configuración primaria es /etc/nginx/nginx.conf.
location ~* \.(js|css|png|jpg|jpeg|gif|ico)$ {
add_header Cache-Control "public";
}Para saber más sobre las directivas diferentes puede leer el artículo detallado sobre Cache-Control .
4. Expires
Y como última tenemos la cabecera Expires. Según el artículo de Google Developers HTTP Caching: la cabecera Cache-Control fue definida como parte de la especificación HTTP/1.1 y reemplazó cabeceras anteriores (en este caso de Expires) definía políticas de respuestas de caching. Todos los navegadores modernos apoyan Cache-Control ya que esto es todo lo que necesita. Sin embargo no hará ningún daño si tiene ambas pero recuerde que solo una será usada. La cabecera Expires utiliza una fecha actual así la cabecera Cache-Control nos deja especificar una cantidad de tiempo antes de que expire.
Para añadir la cabecera Expire en Apache añada el código siguiente a su archivo .htaccess.
## EXPIRES HEADER CACHING ##
<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType image/jpg "access 1 year"
ExpiresByType image/jpeg "access 1 year"
ExpiresByType image/gif "access 1 year"
ExpiresByType image/png "access 1 year"
ExpiresByType text/css "access 1 month"
ExpiresByType application/pdf "access 1 month"
ExpiresByType application/javascript "access 1 month"
ExpiresByType application/x-javascript "access 1 month"
ExpiresByType application/x-shockwave-flash "access 1 month"
ExpiresByType image/x-icon "access 1 year"
ExpiresDefault "access 7 days"
</IfModule>
## EXPIRES HEADER CACHING ##Asegúrese de que añada el bloque de sus cabeceras Expires debajo de tal cosas como mod_rewrite, GZIP, etc. Más seguro por la parte inferior de la lista.
Para añadir cabeceras Expires en NGINX, simplemente añada el siguiente código a su archivo config.
location ~* \.(js|css|png|jpg|jpeg|gif|ico)$ {
expires 7d;
}En muchos casos en NGINX a cabecera Cache-Control y Expires son simplemente usadas juntas, incluso si técnicamente esto no es un requisto:
location ~* \.(js|css|png|jpg|jpeg|gif|ico)$ {
expires 7d;
add_header Cache-Control "public";
}Todas estas cabeceras son añadidas por defecto en todos los servidores de Kinsta así, si usted es un cliente nuestro nunca verá esta advertencia y no deberá preocuparse por ella. La mayoría de los proveedores terceros de CDN tal como KeyCDN o CloudFlare también automáticamente añaden estas cabeceras al entregar sus activos. Si se ven estas advertencias puede ser que su host esté agotándose de software actualizado o el servidor fuera mal configurado. Típicamente esto se en los hosts compartidos. O tal vez usted esté configurando su propio servidor y en este caso alguna de las cabeceras quizás todavía no fue añadida.
Si todo funciona y usted no tiene ninguna solicitud de terceros que no puede utilizar correctamente la cabecera debe de ver una mejora en su puntuación en las herramientas de test de velocidad tal como Pingdom (como se muestra abajo).
