Cuando revisas la velocidad de tu web con herramientas como GTMetrix, Pingom, Google PageSpeed o Think with Google es bastante habitual ver un aviso sobre errores de Leverage Browser Caching, con una lista de elementos que provocan tales errores, normalmente scripts.
Si no sabes cómo solucionar estos errores y, en consecuencia, acelerar tu web, vamos a ver qué son y cómo se solucionan.
Índice de contenidos
¿Qué es el aviso de errores de Leverage Browser Caching?
El aviso de leverage browser caching se refiere a la cache de tu navegador, y es que cada vez que visitas una web descarga un montón de recursos, como imágenes, HTML, CSS y JavaScript en la cache local de tu navegador.
La idea, buena, es que así no tendrás que volver a descargarlos para mostrarlos cada vez que vuelvas a cargar esa página.
El error de Leverage Browser Caching lo que viene a decirte es que tu servidor, u otro, no tiene incluidas las cabeceras de HTTP correctas, o que aún estando no están bien configuradas debido a que el tiempo de almacenamiento en cache es demasiado corto.
Soluciones a los errores de Leverage Browser Caching en WordPress
Dependiendo de los resultados de los errores observarás que hay varias cosas a solucionar.
Los errores más comunes suelen ser de servidores mal configurados, que son los fáciles de solucionar, pero por otra parte están los que nos dejan helados, como los errores por scripts de Google Analytics o de otros scripts que creemos imprescindibles, además de alguna sorpresa más.
En cualquier caso siempre es instructivo analizar los errores de Leverage Browser Caching, así que vamos a ver los más comunes y sus soluciones.
Leverage Browser Caching en el servidor
Como he dicho, los más comunes son los errores provocados por elementos alojados en tu servidor, y se refieren normalmente a que no se ha definido la expiración.
Has de saber que a la hora de cachear contenido se suelen usar dos métodos principalmente: Cache-Control headers and Expires headers.
Cache-Control funciona en la cache del cliente y establece el recurso de la edad máxima de los recursos, mientras que Expires header se utiliza para especificar un punto específico en el tiempo a partir del cual el recurso ya no será válido.
Huelga decir (o no) que no hay que añadir ambas cabeceras, ya que sería redundante. Cache-Control es un método más nuevo y normalmente es el método recomendable, aunque hay herramientas de análisis de rendimiento, como GTMetrix, que aún comprueban las Expires Headers.
Así que nos toca aprender como se añaden estas cabeceras a tu servidor. Por supuesto, los códigos que vamos a ver son ejemplos, que no debes copiar tal cual, sino decidir sobre qué tipos de archivo, tiempos de expiración, etc., debes ajustar a tu web.
Importante: Por supuesto, antes de modificar el archivoconfigde Nginx o.htaccessde Apache haz una copia de seguridad del mismo, por si las moscas. También, si no sabes si tu servidor funciona con Ngix o Apache revisa la configuración del alojamiento o pregunta a tu proveedor.
Añadiendo la cabecera Cache-Control en Nginx
Añade lo siguiente, adaptado a tus necesidades, al archivo config de Ngix de tu servidor:
location ~* \.(js|css|png|jpg|jpeg|gif|ico)$ { expires 2d; add_header Cache-Control "public, no-transform"; }Añadiendo Expires Headers en Nginx
Para usar Expires en Nginx añade lo siguiente a tu config:
location ~* \.(jpg|jpeg|gif|png)$ { expires 365d; } location ~* \.(pdf|css|html|js|swf)$ { expires 2d; }Añadiendo cabeceras Cache-Control en Apache
En este caso las añadimos al archivo .htaccess de tu servidor:
<filesMatch ".(ico|pdf|flv|jpg|jpeg|png|gif|js|css|swf)$"> Header set Cache-Control "max-age=84600, public" </filesMatch>
Añadiendo Expires Headers en Apache
Igualmente, lo añadimos al archivo .htaccess:
## EXPIRES 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 2 days" </IfModule> ## EXPIRES CACHING ##
Para comprobar las cabeceras, y asegurarte de que ya va todo bien, puedes usar las herramientas de desarrollo o inspector de tu navegador, o echando de nuevo un vistazo a tu herramienta de análisis de velocidad favorita.
Leverage Browser Caching y Google Analytics
El otro error más común de Leverage Browser Caching suele ser Google Analytics.
Lo sé, suena casi a cachondeo que estés viendo lo optimizada que está tu web en PageSpeed de Google y precisamente sea LA herramienta de Google la que genere errores y problemas de optimización de tu web.
Pero la cuestión es ¿se puede arreglar? A fin de cuentas uno quiere saber, y Google también, quien te visita, qué hace, con qué frecuencia, etc.
Pues la única medio solución es alojar el script de Google Analytics en tu servidor, algo que a Google no le gusta, pero funcionar funciona.
Para lograrlo te puedes servir de un plugin llamado Complete Analytics Optimization Suite, que precisamente permite, entre otras cosas, que alojes localmente el archivo analytics.js de Google Analytics, actualizándolo usando wp_cron().
Los beneficios de alojar localmente tu script de Google Analytics es que reduces las peticiones HTTP hacia Google a la mitad, además de tener un control total del archivo, lo que significa que puedes aplicarle las reglas de cache en cabeceras que hemos visto antes.
El funcionamiento del plugin es sencillo, lo instalas y activas, le pones en los ajustes tu ID de seguimiento de Google Analytics y el plugin hace todo lo demás: añade el código de seguimiento a tu WordPress, descarga el archivo analytics.js en tu servidor y lo actualiza usando un script programado en wp_cron().
Eso sí, no uses este plugin conjuntamente con otros plugins de Google Analytics, por mucho que te gusten, o no funcionará.
Leverage Browser Caching y las redes sociales
Otros elementos que suelen dar error son los relativos a redes sociales como Facebook y Twitter, ya que rara es la web que no tiene un widget para mostrar los últimos tuits o para darle al me gusta en su página de Facebook, y claro, todos estos scripts, para mostrar los seguidores y tuits en tiempo real ralentizan la carga de tu web mientras realizan las comprobaciones.
La solución igual no te gusta pero pasa por evitar este tipo de plugins y widgets. Si quieres mostrar los seguidores pon una imagen y enlázala a tus perfiles, punto. Casi nunca merece la pena mostrar tuits en tiempo real.
Leverage Browser Caching y Google Maps
Similar, pero peor, es el caso de Google Maps, pues requiere que varios scripts identifiquen si el usuario que ve el mapa está conectado a su cuenta de Google y a cual, determina su ubicación, mapas guardados, y más cosas.
Este tipo de elementos cada vez se usan más en las webs corporativas, sobre todo en la página de contacto, pero en realidad no aportan mucho más allá del aspecto.
¿Solución? No hay arreglo directo posible, pero lo que he visto en muchos sitios, y consigue el resultado, es sustituir el script que cargue el mapa en tiempo real por una captura del mismo enlazada a la URL de Google Maps de la ubicación en cuestión.
El usuario al hacer clic abrirá la ubicación, en su aplicación de mapas incluso si es desde un móvil, con lo que ofreces la funcionalidad al mismo tiempo que optimizas la web.
¿Y el resto de scripts?
Hay otro buen montón de posibles scripts externos que puedes estar usando. Hablo de códigos de servicios de newsletters, servidores de anuncios y mil cosas más.
Aquí tendrás que decidir si la funcionalidad que te aportan merece la pena como para comprometer el rendimiento y tiempos de carga de tu web.
Resumiendo
Como habrás visto, es posible reducir los errores de Leverage Browser Caching, y optimizar tu web al máximo posible, pero también recuerda que no debes tomarte al pié de la letra las recomendaciones y resultados de estos analizadores de velocidad.
Y, sobre todo, que debes decidir en cada caso qué ganas y qué pierdes, antes de cambiar los tiempos de expiración de un recurso o eliminarlo.
Pero sí que es bueno que al menos apliques algunas de las técnicas aquí vistas, pues la realidad es que mejorarás el rendimiento de tu web y tu WordPress irá más rápido.
Si sabes algún otro truco para reducir errores de Leverage Browser Caching nos lo cuentas en los comentarios.
¿Te gustó este artículo? ¡Ni te imaginas lo que te estás perdiendo en YouTube!
AVISO: Esta publicación es de hace 3 años o más. Si es un código o un plugin podría no funcionar en las últimas versiones de WordPress, y si es una noticia podría estar ya obsoleta. Luego no digas que no te hemos avisado. ¡Ah! ¿te funciona? pues entonces no he dicho nada :)
Con esto hay que tener muchisimo cuidado porque como pongas que no caduque en mucho tiempo cambiarlo es un infierno. Si tu web actualiza poco da igual, pero como seas de hacer muchos cambios,. etc… Puedes tener mil problemas.
Y depende en qué. Para estas cosas hay que analizar el propio contenido y tener claros los objetivos, como en todo.
te falto las intrucciones para añadir actualizar el google analitycs en wp_cron()
Como es algo específico del plugin no lo creí conveniente, pero en la FAQ del plugin lo explican y con enlace a un crontab generator y todo: https://wordpress.org/plugins/host-analyticsjs-local/faq/
I utilizar un cdn tipo cloudflare ya estaria solucionado, no?
Las CDN hacen mucho de esto pero no todo. Si no tienes errores entonces no tienes que hacer nada
Fernando eres grande gracias!!! No sabes lo que he sufrido para encontrar una guía así de buena para nginx de este tema, y me calificaba con mas de 30 puntos menos google page speed.
¿Y como hago para comprar tu nuevo libro si estoy en colombia?
Me alegro 🙂
Si ya se puede adquirir libros en Colombia desde Amazon pues eso, desde Amazon, sino quizás te lo envíen en la Casa del Libro
Gracias
Hola Fernando, lo primero enhorabuena sobre este gran articulo!! Llevo semanas muy indecisa sobre los plugins de cache o tocar el htaccess… Te explico seria conveniente usar estos codigos para un woocomerce? Lo digo por el tema de no cachear ciertas paginas en woocomerce. tambien utilizo un script bastante amplio del pixel de facebook, que es primordial para mi negocio. He ecncontrado este codigo completo
# BEGIN Expire headers
ExpiresActive On
ExpiresDefault «access plus 1 seconds»
ExpiresByType image/x-icon «access plus 2592000 seconds»
ExpiresByType image/jpeg «access plus 2592000 seconds»
ExpiresByType image/png «access plus 2592000 seconds»
ExpiresByType image/gif «access plus 2592000 seconds»
ExpiresByType application/x-shockwave-flash «access plus 2592000 seconds»
ExpiresByType text/css «access plus 604800 seconds»
ExpiresByType text/javascript «access plus 216000 seconds»
ExpiresByType application/javascript «access plus 216000 seconds»
ExpiresByType application/x-javascript «access plus 216000 seconds»
ExpiresByType text/html «access plus 600 seconds»
ExpiresByType application/xhtml+xml «access plus 600 seconds»
# END Expire headers
# BEGIN Cache-Control Headers
Header set Cache-Control «max-age=2592000, public»
Header set Cache-Control «max-age=604800, public»
Header set Cache-Control «max-age=216000, private»
Header set Cache-Control «max-age=600, private, must-revalidate»
# END Cache-Control Headers
# BEGIN Compress text files
SetOutputFilter DEFLATE
# END Compress text files
,¿ que te parece? o ¿que me aconsejas?
Muchisimas gracias por tu tiempo.
P:D la nota de google speed en vista movil es de 40/100… es de risa la verdad
Ainhoa
Ese código es un refrito de varias cosas pero sí debería funcionar en Apache sin problemas.
En cuanto a lo de usar estas cosas con WooCommerce no le afectan negativamente, pero sobre todo no te vuelvas loca con el PageSpeed porque en una tienda online nunca dará buenos resultados y de lo que se trata es de vender ¿carga en un tiempo razonable tu tienda? ¿la gente compra sin huir por largos tiempos de espera? Pues que le dén a Google
Hola buenas, cuando introduzco este código: » Header set Cache-Control «max-age=84600, public» » en mi .htaccess la página se cae y me da un error 500
Una de dos:
– Revisa que copies bien el código, sin cambiar comillas
– Habla con tu hosting, a veces tienen capadas ciertas modificaciones
Buen día, aún soy inexperto en este tipo de cosas. El tiempo de carga de mi web varía entre 3.8 y 3.6 segundos. GTMetrix marca una grado de 93% de velocidad, hasta ahí lo considero algo normal. En los errores encontrados me marca «Leverage Browser Caching» desde el servidor. Al añadir las líneas de código a mi servidor Apache me devuelve un error 500, ¿A qué se debe? los códigos los he colocado dentro del .htaccess que se encuentra dentro de la carpeta public_html
Mira mi respuesta al compañero del comentario anterior
Buen día. Felicitaciones por tu excelente artículo y gracias por tomarte el tiempo en redactarlo.
Tengo una duda …en la herramienta de gtmetrix.com me está saliendo siempre el error de Leverage browser caching con calificación de F(0). Ya puse los respectivos códigos en el .htaccess y no cambia el resultado en la herramienta de Velocidad.
Siempre me muestra algunos archivos como imagenes , archivos de JS o de CSS y me dice que está establecido el tiempo en 1 hora, pero en mi .htaccess le tengo más tiempo a todos esos recursos.
Te pongo mi código por si tienes el tiempo de verlo y analizar si tengo algo mal, aunque sospecho que ya es más algo del servidor y no de mi código.
ExpiresActive On
ExpiresByType image/gif «access 1 month»
ExpiresByType image/jpeg «access 1 month»
ExpiresByType image/jpg «access 1 month»
ExpiresByType image/png «access 1 month»
ExpiresByType text/css «access 1 week»
ExpiresByType text/javascript «access 1 week»
ExpiresByType application/javascript «access plus 1 week»
ExpiresByType application/x-javascript «access plus 1 week»
ExpiresByType image/x-icon «access plus 1 year»
ExpiresByType image/svg+xml «access plus 1 year»
ExpiresByType image/vnd.microsoft.icon «access plus 1 year»
ExpiresByType application/font-woff «access plus 1 year»
ExpiresByType application/x-font-woff «access plus 1 year»
ExpiresByType application/vnd.ms-fontobject «access plus 1 year»
ExpiresByType font/opentype «access plus 1 year»
ExpiresByType font/ttf «access plus 1 year»
ExpiresByType font/otf «access plus 1 year»
ExpiresByType application/x-font-ttf «access plus 1 year»
ExpiresByType application/x-font-otf «access plus 1 year»
Muchas gracias por tu tiempo y por tu ayuda.
¡Hola! En mi caso, y después de probar muchas herramientas, la que más confiable me parece es GTMetrix, ya que PageSpeed sigue marcándome errores después de optimizar el sitio.
Por otro lado, encuentro que a veces es imposible optimizar al 100%, ya que hay sitios como las tiendas online que usan plugins para cobrar o geolocalizar que son imposibles de eliminar.
Con respecto al AMP también, ya que hace que el sitio sea extremadamente minimalista y poco atractivo para los usuarios. Aunque reconozco que carga mucho más rápido.
¡Un saludo!
No hay que obsesionarse con las herramientas de medición, que no lo son todo. Una web rota te dará un 100%, con eso lo digo todo