Los plugins de Cache (y no tan Cache) que usamos:

Aquí hay una pequeña controversia, ya que realmente el nombre cache se ha estandarizado tanto que hoy en día, un plugin que mejore el WPO ya es un plugin de Cache y como nosotros no somos menos, también caemos en el error y generalizamos con los nombres, así que vamos con los plugins de “Cache” que más utilizamos en el día a día:

1. WP3Total Cache
   • Como dice Alvaro de Raiola, “Esto es como matar moscas a bazocazos” (es imprescindible poner acento “Galleguiño” al leero ? ). Este plugin es uno de los más completos, pero una mala configuración puede provocar un consumo excesivo de recursos que acabe derivando en una “desmejora” del WPO en cuestiones del rendimiento del servidor.
2. Autoptimize
   • Este plugin en concreto es más un minificador y unificador de código que un plugin de cache, pero como también tiene la función (por muy simple que sea cachea algo) y es increíblemente fácil de usar, ¡pues para adelante con el!
3. Fastest Cache
   • Otro plugin que da buenos resultados para el poco trabajo que da configurarlo, realmente si ni fuese por Autoprimize y Fastest Cache, sería tremendamente complicado para algunas personas tener la web cacheada y minificada.
4. WP Rocket
   • A día de hoy la mejor opción, pero como toda buena opción hay que dejarse “lereles”, en concreto “39lereles” por sitio, lo bueno se paga, y lo malo también, pero a la larga ?. Nos gusta tanto WP Rocket porque con 4 ajustes que tiene, ofrece la misma efectividad que W3Totalcache y Fastest Cache, una pasada. Y además tienen un gran soporte, que entienden la pasta que te dejas en el dichoso plugin y que este tiene que funcionar perfecto.
5. WP SuperCache
   • ¡Realmente este plugin está de capa caída, se queda lejos de sus competidores, por estar viejo y tomar malas decisiones en cuanto a gestión de cache, pero aún lo tenemos en el recuerdo y por eso lo nombramos!

¿Qué hacen (o deberían) los plugins de Caché (o Suits de WPO)?

Como comentábamos al principio, realmente si nos ceñimos al concepto caché, sólo deberíamos fijarnos en:

1. Cacheo en Servidor
   • El plugin compila el PHP y los datos de la Base de Datos y genera un HTML estático en texto plano. De forma que realiza la tarea de cargar la web entera y almacenarla en el servidor, antes de que cualquier usuario haga una consulta a este.
2. Cacheo en cliente
   • Este punto es uno de los más importantes, ya que establecen el tiempo de estancia de los archivos descargados en el servidor para que estos no tengan que volver a descargarse las siguientes veces que se necesiten. Es decir, el navegador comprueba si tiene la información guardada y si lo está, la carga desde el propio ordenador y la muestra, por lo que no tiene que volver a descargarla.

Y algunas otras funciones que asociamos a los Plugins de Cache (por simplificar el término) y que afectan de una forma muy directa al WPO:

1. Minificar el código
   • Reducir y eliminar todo el código que el navegador no puede (o no quiere procesar) como, por ejemplo, los comentarios HTML, los espacios o saltos de línea.
2. Unificar CSS y JS
   • Esta técnica es la que nos trae hoy aquí, ya que realmente, sobre el papel es una gran opción, reducir al máximo el número de CSS y JS (siempre teniendo en cuenta el peso de ese archivo resultante). Esto no sólo es una mejora en cuanto a peso y carga de la página, sino también a procesamiento de archivos de cara a GBOT, ya que, si reducimos el número de archivos JS, menos Java Script tendrá GBOT que intentar interpretar y si lo hacemos con los CSS menos tendrá que cargar Page Speed para comprobar la accesibilidad de nuestra web. Como decimos esto sobre el papel funciona de una forma perfecta, pero la gran mayoría de los plugins (por lo menos los que hemos probado) en este punto fallan dramáticamente por una simple tontería.
   • Estos plugins generan unas url con caracteres únicos (HASH) cada vez que minifican y unifican el código. Esto lo hacen por un motivo muy claro, y es que como estos plugins establecen en el Htacces que los archivos permanezcan en los servidores durante años (para curarse en salud), y el navegador comprueba mediante el nombre del archivo si este ya se ha descargado anteriormente. Si nosotros hacemos un cambio en un CSS (o JS) y el navegador comprueba que ese CSS ya lo habíamos descargado antes y encima nuestro htacces le dice que debe permanecer en caché durante años, ese archivo CSS no se descargará hasta que se limpie la cache o pase el tiempo establecido en Htacces, por lo que hay personas que podrían estar viendo la web mal durante meses. Para solucionar este problema, estos plugins empezaron a trabajar con “HASHES”, conjuntos de caracteres alfanuméricos únicos , forzando de esa forma al navegador a descargar siempre estos archivos ya que van cambiando de nombre y de esta forma nunca existe un archivo igual alojado en el navegador.

Los problemas de estos Plugins

El primer problema
Como estos plugins tienen como principal característica limpiar la cache cada X días (o incluso horas), esto provoca que se generan nuevos archivos con urls diferentes, lo que provoca que cuando el navegador compara la url que tiene guardada en cache con la que el servidor le ofrece para descargar, este encuentra que es un archivo totalmente nuevo y vuelve a descargarlo, por lo que si tenemos un plugin configurado para que limpie la cache, por ejemplo, una vez al día (que como ya comentamos pueden estar configurados hasta pare que se haga cada X horas) la próxima vez que el usuario entre en mi web, tendrá que descargarla por completo, haciendo todo lo contrario a lo que deberían hacer, descargar el mínimo de información posible.
Y el segundo problema:
Al limpiar la caché de esta forma tan indiscriminada, los plugins generan nuevos archivos con nuevas urls, creando así de cara a GBOT un nuevo archivo que rastrear, dado que nosotros le damos mucha importancia a ese archivo “lincandolo” desde todas las páginas de nuestra web, ese archivo adquiere una relevancia muy alta (a parte de lo importante que es por si mismo y CSS y JS para que google entienda nuestra web) y GBOT lo rastrea y procesa con mucha efectividad. Como ya sabemos si le decimos a GBOT que un archivo es más importante que otro, GBOT en la medida de lo posible, rastreará más frecuentemente ese archivo, acumulando una cantidad enorme de eventos en ese archivo.
El problema no es que un archivo CSS o JS acumule muchos eventos (lecturas por parte de Google), realmente están para eso, el problema es que al limpiar la caché, estos archivos , que ayer eran los más importantes, dejan de existir ( en algunos casos generan 404 y otros un “falso” 200) y google tiene que volver a rastrear unos nuevos, pero como GBOT es un cabezón, no dejará de rastrear estos archivos que ya no existen y además empezará a rastrear y priorizar los nuevos, lo que provocará una cantidad inmensa de rastreo en estas urls erróneas, y dejará de lado las páginas que intentamos posicionar.
Este problema, afecta sobre todo a las páginas que son nuevas o tiene poca frecuencia de rastreo, ya que si tengo pocos eventos y estos se producen en 404 o “falsos” 200, estas páginas tardarán mucho en indexarse y google las tomará como páginas de baja prioridad.

Análisis de los Plugins de Cache – [VÍDEO]

¿La solución?

Pues, desde el Dpto de Experimentación de Webpositer, como profesionales en marketing que somos, la veremos en una siguiente entrega ( y así estáis atentos) ?, de momento lo único que os podemos decir es: si tu web es relativamente nueva y no tarda mucho en cargarse (menos de 3 segundos), de momento olvida la unificación de CS y JS, el problema es mejor que la solución, os lo decimos por propia experiencia.
Mientras preparamos la mejor guía de WPO jamás contada, os ofrecemos el cuadro de preguntas para dejar los temas que querías tratar y dudas que tengáis sobre el WPO en general.