No uses plugins de caché con WordPress

Publicado en Optimización web( WPO ) hace 3 años. Leído 6817 veces.

imagen destacada

Cuando hablé del porqué WordPress es lento, recomendé el no uso de plugins de caché. Hoy toca ver la razón.

Para saber el porqué de no usar plugins de caché, antes tenemos que saber que es la caché y cómo se realiza. Para verlo claro, vamos a verlo primero con la caché del navegador y luego lo llevaremos a un ejemplo ficticio y finalmente lo veremos con WordPress.

Cuando una persona escribe una dirección web en un navegador, éste se encarga de bajar los archivos que forman la página web y presentárselos al usuario. Si el proceso se realiza 10, 100 o mil veces, en un corto periodo de tiempo - por ejemplo, 10 segundos o cuatro minutos-, ¿ qué sentido tiene bajarse los archivos cada vez ?. Será muy raro que haya algo nuevo en ese periodo tan corto de tiempo. Así que lo que hacen los navegadores es guardar los archivos de una página web en tu ordenador. De esta manera que si la vuelves a pedir, y no ha pasado mucho tiempo de la última vez, no se molesta en bajarlos de nuevo sino que te muestra los que ya tiene en el ordenador. Si ya ha pasado un tiempo, unas horas, días o semanas, desde la última vez si que vuelve a bajar los archivos.

Esa copia en el disco duro que hace el navegador se llama caché, al proceso de crearla le llamamos, informalmente, cachear y al proceso de borrar y bajar de nuevo los archivos de una web se le llama refrescar, o limpiar, la caché.

¿ Hay algún inconveniente en el uso de caché en un navegador ?. La verdad es que no, por eso se inventó. Mi web la actualizo de semana en semana y no tiene sentido que un navegador que se haya bajado una página web de mi sitio lo baje de nuevo de hora en hora o de día en día. Pero, ¿ qué pasa con los sitios de noticias ?. Podríamos perdernos de noticias importantes si nuestro navegador no refrescara su caché y las mostrará. Por suerte, para evitar este último caso los desarrolladores web tenemos la opción de especificar en cada web cuanto tiempo es el máximo que debería de usar un navegador para cachear una de nuestras páginas web. También hay formas para que un usuario fuerce el limpiado de caché.

Los sistemas de caché en WordPress funcionan de igual manera a un navegador. WordPress, junto con los plugins que tengas instalado y el tema activo, van generando código que luego será el que se mande al navegador. Ante de mandarlo, se guarda y así no se tiene que volver a generar. Así, todos felices y tan contentos. Pues, no. Porque WordPress no es un navegador, WordPress además está orientado a la flexibilidad por lo que su forma de funcionar es incompatible con este tipo de plugins. ¿ Lo vemos con un ejemplo ficticio y luego ya más técnicamente ?.

Imagínate una empresa de fabricación de abrigos llamada WordPress. Esta empresa construye abrigos con una cadena de montaje formada por un número indeterminado de operarios. Pero, esta no es una cadena de montaje de abrigos común y corriente como las demás empresas. Es decir, en este caso, los abrigos no se van fabricando uno tras otro, siempre igual y con el mismo resultado. Esto es así porque la empresa WordPress es flexible y permite que cada cliente personalice cada abrigo. De tal manera, que cada operador de la cadena de montaje, llama por teléfono al dueño que tendrá ese abrigo para avisarle de lo que va a realizar por si quiere algo diferente. Supongamos que te llamas, Fulanito y que la empresa WordPress te va a hacer un abrigo: * Operador 1: Hola, Sr Fulanito, soy el encargado de selección de telas. Había pensado ponerle en su abrigo piel de tigre, ¿ le gusta o prefiere otro ?. * Operador 2. Hola, Sr Fulanito, ya le hemos puesto la tela que seleccionó con el Operador1. Yo soy el operador que se encarga de la manga izquierda. Había pensado que tuviera 40cm de largo y 15cm de ancho. ¿ le parece bien ?. * ...siguen operarios tras operarios... * Operador 15: Hola, Sr Fulanito, soy el operario de poner el botón tercero de su abrigo. Lo había pensado en verde y con las medidas que pidió para los anteriores a predecesores operarios, ¿ le parece bien ?. * ...siguen más operarios tras más operarios... * Operador 50:Hola, Sr Fulanito, soy el operario encargado de enviarle el abrigo. Había pensado llevárselo en moto y a su dirección. Como vemos, la fabricación de abrigos así es un muy lenta. Eso sí, muy flexible pues permite al cliente tener un abrigo tal y como deseó. Si en el año 4.000 descubren una manera de cachear cadenas de montajes, quizás podrán con todas menos con esta. No tiene sentido que a todos los clientes se le dé el mismo abrigo cuando esta empresa lo que quiere, y es su valor diferenciador, que cada cliente tenga su abrigo según sus gustos.

Ya volviendo a la vida real, y dejando atrás ejemplos fantasiosos, el CMS WordPress funciona como esa cadena de producción. Es decir, la zona de gestión y la visualización de tu web se van realizando en base a minis tareas. Durante la creación de cada tarea, el encargado software de cada tarea se detiene y pregunta ¿alguien quiere modificar lo que estoy haciendo o voy a hacer ?. A este paso de detenerse y preguntar, en desarrollo, se le llama poner un hook. ¿ Y quién responden a estas peticiones o hooks ?, los plugins o el tema.

No es muy complejo verlo. Si ponemos por caso un plugin de Google analytics, lo que hace es esperar a que el encargado software de hacer la cabecera diga que ya la está haciendo y que si alguien quiere hacer algún cambio. En ese caso, el plugin de Google analytics, que está a la escucha, toma el control y realiza un cambio a la cabecera para meter el código de Google Analytics. Después, la cadena de montaje de la web prosigue.

¿ Qué estás haciendo al instalar un plugin de caché ?. Estás evitando los hooks o que los plugins no puedan hacer uso de los hooks cuando lo necesitan. Es decir, estás cargándote como funciona WordPress.

A mi me gusta comparar el uso de plugins de caché con hacer un torniquete. Si tienes una hemorragia grave, y no te queda otra, usa un torniquete y así te librarás de morir desangrado. Eso sí, haz de saber que puedes quedar con una extremidad amputada. Ni que decir tiene que sólo uses torniquetes como último recurso. Lo mismísimo para los plugins de caché, úsalo sólo como último recurso y sabiendo lo que haces. Seguramente termines con código amputado, pero lo hiciste con conocimiento de causa, ¿ no es cierto ?.

Seguro que te oigo decir: podríamos hacer como con los navegadores, es decir, usar caché para periodo de tiempos pequeños. El caso es que una web puede determinar cuanto tiempo es lo recomendable de caché( un día, una semana o que no quiere caché ). Sin embargo, en WordPress, si yo desarrollo un plugin, no puedo decirle al plugin de caché cuando no hacerlo.

Así que por más que leas en blogs, foros, libros o revista, lo diga pepito, pepa o el mismisimo Papa, NO USES PLUGINS DE CACHÉS a no ser que sepas bien lo que estás haciendo. Para tener una web rápida no hace falta tener plugins de caché. Te lo dice uno que tiene un 99%/99% en Gtmetrix o un 100% en pingdom sin usar plugin de caché para nada. Hay soluciones mejores y más sanas a los plugins de caché. Nota: Si aún te queda alguna duda sobre esto, al menos hazlo por seguridad.

4 comentarios

Hola Manuel, primero de todo me parece interesante que se saquen estos temas y espero que no se interprete mi comentario más allá de comentar aspectos técnicos, por favor. Al contrario, yo mismo intento mantener una actitud de aprendizaje, esté o no de acuerdo con lo que se discuta.

Entiendo que la misión primaria del cache al mostrar una instantánea temporal de una página (por ejemplo cada 5 minutos) es evitar situaciones tales como que caiga el servidor por numerosas visitas sucesivas a una página concreta, que es lo que suele suceder normalmente (visitas desde menéname, foros, etc.). Esto lo hace porque con la técnica de cacheado se prescinde del acceso a base de datos, que es realmente el cuello de botella de WordPress y casi cualquier CMS.

De hecho cuando entras en una página de un servidor saturado muchas veces te encuentras con el error de demasiadas conexiones a la bbdd. Aunque a veces se trata de una mala configuración del servidor de base de datos, un sistema de caché evita este problema y permite el acceso al contenido.

Por lo que pienso que es una tema más cercano al rendimiento que a la velocidad, a como se distribuyen los recursos en el tiempo y la capacidad de aguantar una sobrecarga, en lugar de enfocarse solo en mejorar la velocidad de respuesta.

Me ha llamado la atención esta frase: “¿ Qué estás haciendo al instalar un plugin de caché ?. Estás evitando los hooks o que los plugins no puedan hacer uso de los hooks cuando lo necesitan. Es decir, estás cargándote como funciona WordPress.”

El HTML de salida es el resultado de aplicar todos los procesos de hooks y filtros, y no es necesario hacerlo cada vez cuando el HTML de salida va a ser exactamente el mismo. En caso de plugins que necesiten ejecutarse en el front, como contadores de visitas, etc. se pueden utilizar técnicas que combinen javascript y AJAX.

Por último creo que hay muchas diferencias entre el sistema de cache y los plugins que lo implementan, ya que cada cual implementa estas técnicas a su manera o según las capacidades del servidor, por lo que aspectos como seguridad habría que matizarlas respecto al plugin utilizado, su versión, etc.

Un saludo y gracias por tu tiempo.

Hola Pau, perdón la tardanza en responder.

Tu comentario es respetuoso y así da gusto responder, estemos de acuerdo o no.

El caso es que he recibido cada mensaje….uff. Bueno, te respondo con mi punto de vista y lo que me ha hecho ver que los plugins de caché no son adecuados. Pongo un ejemplo real, para que me entiendas con lo que me refiero en el post( como eres programador Web sé que no habrá problema ):

Si tú y yo desarrolláramos una web juntos desde cero, tendríamos que ver la forma de almacenar la url base del sitio. Si acaso, podríamos poner un hook, para que a la hora de guardarse dónde sea, algún plugin del cliente la pudiera cambiar. Yo creo que lo mejor sería una constante, ¿ tú como lo ves ? y antes de que se establezca como constante le pasamos el hook de filtro comentado. Hecho eso, todo solucionado, ¿ no ?. ¿ Para que sirve cambiar la url varias veces durante la ejecución ?.

WordPress no trabaja así. Cada vez que vayas a usar la url del sitio, le pasará un hook fitro por si alguien quiere cambiar algo de ella. Puedes verlo en el archivo wp-includes/link-template.php si buscas por get_site_url ( site_url() sólo es un wrapper de esta función ). Eso es tela de ineficiente, ¿ por qué lo habrán hecho así ?

Porque puede que no sea todo tan fijo como nosotros hemos pensado. Puede que durante la ejecución, un plugin decida que el visitante no es de fiar y lo redireccione a otro sitio externo. Puede que algún plugin de promoción lo quiera llevar a una landing porque es un visitante que cumple con un target determinado. Puede que haya habido un problema puntual con algún plugin y quiera mostrarle la página de mantenimiento. Puede que sea alguien que haya entrado con un código de afiliado y entonces se quiere que algunas urls mantengan el código de afiliado( por si el visitante no permite cookies ) y otras no, … hay tantas y tantas opciones que pueden pasar .

Al usar el plugin de caché, no importa si es 1hora o 5minutos o 1segundos. Porque con WordPress todo es flexible y en cualquier momento el tema o algún plugin pueden tomar el control y cambiarte lo que creías estático. Ese es su mayor potencial.

Si el problema es reducir el número de peticiones a la base de datos, siempre puedes meter un proxy por medio: https://dev.mysql.com/downloads/mysql-proxy/ . Aunque claro, tu me dirás que esto es costoso para la gran mayoría de los sitios y que para eso mejor usar caché. Vale, en ese caso de acuerdo porque aunque lo pareciera yo estoy en contra de uso de plugin de caché, pero no es así si lo haces con pinzas y si sabes lo que estás haciendo. Si eres médico, siguiendo con el simil del post, sabes cuando hacer una amputación o aplicar otro mejor remedio. En este caso, sé que eres médico y harás lo mejor para tu paciente ;)

Un saludo y gracias Pau. Así es un placer.

Interesante lo de las URLs. Sobre el ejemplo de get_site_url aparentemente no tiene sentido aplicar el filtro en cada llamada, sino que bastaría hacerlo como bien dices en la inicialización del blog. Pero que no se nos ocurra un motivo no quiere decir que no exista, y puede que haya más de una funcionalidad que necesite ese filtro, por ejemplo, no sé si será válido, sitios que tengan el front en un dominio sin https y ciertas partes del backoffice con https por seguridad, por lo que no funcionaría una inicialización común y habría que aplicar el filtro cada vez en función del contexto. Obviamente se podría hacer de otra forma más optimizada en un CMS de desarrollo propio.

Sobre el tema de eficiencia, apenas se pierde nada por poner un filtro ahí. Es más costoso las queries a la bbdd que todo el código PHP junto. Como ellos dicen es un CMS pensado para la mayoría, y es complicado hacer feliz a todo el mundo sin dar algo a cambio, en este caso filtros aparentemente injustificados.

Sobre la fiabilidad de los plugins, bueno, eso es otro cantar. Al final si quieres seguridad tienes que meterte dentro de cada uno y ver lo que hace antes de instalarlo. Yo lo hago con casi todos. Pero no veo un motivo suficiente para no usar un plugin de caché que cubran una avalancha puntual de tráfico. Incluso para los sitios con poco tráfico es positivo, por ejemplo cuando coinciden varios bots a la vez sobre las mismas páginas no te ralentiza el servidor. Y otra ventaja que a veces sucede es que te ahorras contratar un hosting más caro al necesitar menos máquina.

Por último, estamos hablando de cache de HTML. Pero WordPress también gestiona cache de datos. Si lo implementas junto con algún plugin que soporte Memcache (que va directo a la RAM sin pasar por el disco duro) el rendimiento es brutal. Muchas queries dejan de hacerse y se accede directamente a los datos en memoria. Por ejemplo las options, los datos de usuarios registrados, metadatos de posts y comentarios, etc. La opción que comentas del proxy de mysql no lo he probado nunca, tiene buena pinta para intentar reducir el número de queries.

La verdad es que tampoco intento convencer a nadie que use algún plugin de cache ya que la mayoría de sitios con poco tráfico apenas lo van a notar, aunque tampoco lo veo perjudicial. Pero en cuanto empiezas a tener mucho tráfico se hace casi obligado. Es tan sencillo como desactivar la caché momentaneamente y ver como se duplica o triplica la carga del servidor en segundos y las páginas tardan más en cargarse.

Un saludo, Pau

Pau, espero que me perdones la tardanza en publicarte el comentario y en responderte.

Das un buen ejemplo( el de urls en el backoffice ) sobre una de las posibles utilizaciones de ese filtro. Es como tu dices, se podría hacer más optimizado, pero WordPress prefierió la flexibilidad y eso le hace lento pero flexible. Porque, y aquí no estoy de acuerdo con lo que dices, puede que un filtro no haga nada, pero son tropecientos los que se lanzan en cada petición WordPress. Si encima le sumas que tiene alzheimer y otras cosas, al final, el pobre WordPress siempre va a pedales.

Pau, estoy contigo, si eres un profesional de las páginas webs y necesitas, y ves necesario, un plugin de caché, entonces úsalo. El problema son las personas que lo usan sin saber ni que hace un plugin de caché pero como lo leyeron en un blog… a eso es lo que estoy en contra.

Respecto a otros tipos de caché, si hay más como bien dices. De hecho tengo la continuación de este post pendiente. Ahí no digo nada, estoy totalmente de acuerdo contigo.

Gacias por tu aporte, Pau. Aunque no lo creas, coincidimos. Pienso en lo mismo que tú, aunque yo trato de poner hincapié en que nadie que sepa de caché debería de usarlo( al menos con WordPress ).

Un saludo y perdona de nuevo por la tardanza. Manuel Canga

Deja un comentario

Puedes usar Markdown para formatear tu comentario.

Este sitio utiliza cookies propias y de terceros para mejorar tu experiencia con el sitio web. Al continuar con la navegación consideramos que acepta su uso.