Rendimiento para webs Drupal

 Bienvenido o bienvenida otra semana más a un episodio de Drupalízate, donde yo, Robert Menetray, te voy a contar cosillas de Drupal. Esta semana toca hablar sobre temas de rendimiento, de cómo mejoras el performance de una web. Y nada más, si me quieres dar feedback o contactarme o hacer una consultoría, me puedes contactar en menetray.com o directamente en LinkedIn, buscas por mi nombre, Robert Menetray, y ya está. Si quieres estar al tanto de novedades semanales, te apuntas a la newsletter que tengo en LinkedIn, hablando también de temas Drupal y... pocos más, la verdad. Vamos con el tema que si no me alargo muchísimo con estos episodios. Esta semana toca hablar sobre performance, sobre rendimiento, sobre hacer que la web vaya lo más rápido posible. Primero de todo, el concepto que tienes que tener más claro son las cachés en Drupal, qué son y más o menos cómo funcionan, las partes más básicas al menos. Digamos que como otros CMS que trabajan en PHP, tenemos la parte de PHP, la parte de servidor de ejecución de código y la parte de base de datos, MySQL. A ver, cómo lo explico. Cuando tienes un usuario que entra en tu web, el usuario está haciendo una petición, una solicitud al servidor de, ¡hey! Quiero ver esta página, quiero ver la home de esta web. El servidor recibe esta petición de, ah, vale, uno solo quiere ver la home. Vale, la home contiene, vale, este parágrafo, este bloque, este y lo otro. Vale, hago una consulta a base de datos. ¡Hey, base de datos! Devuélveme estos datos. Vale, se los devuelve a PHP. PHP los analiza, los calcula, los renderiza, por así llamarlo, o sea, calcula el resultado que ha de devolver al usuario y cuando tiene todo, le devuelve la respuesta al usuario. Ya todo hecho, todo montado, vale, por así llamarlo. O sea, al final, hay muchas partes, desde que el usuario hace la solicitud, o sea, pone la URL en el navegador y se solicita de, ¡hey! Quiero ver la home de la web, hasta que el servidor recibe esto y lo procesa, consulta base de datos, esta responde y lo vuelve a procesar y lo reenvía, digamos que hay muchos pasos que se pueden y que pueden influir muchas cosas para tener un buen rendimiento. Aquí entran lo que son las cachés. Si tienes solo un usuario que te hace una petición a la home, pues no hacen falta cachés. Pero si tienes dos usuarios, pues si tienes cachés activas, el segundo usuario se va a saltar todos estos cálculos que ya ha hecho para el primero usuario. Si tienes dos usuarios, quizá no se nota mucho el cambio, o sea, no tendría quizá mucho sentido. Entonces, en vez de dos, tienes cien o mil usuarios al día, ya te digo yo que sí que se nota mucho el cambio. De tener solo un usuario que se come el tiempo de cálculo y el tiempo de consulta base de datos donde se generan las cachés, en vez de tener un usuario que tiene cien al mismo tiempo que te están haciendo el mismo cálculo, exactamente el mismo, tiene sentido cachar la respuesta. Cachar la respuesta significa básicamente cuando yo le digo a alguien de dos más dos cuánto es y piensas nada un milisegundo, ah, es cuatro. Vale, si eso se lo hace a cien personas, mejor dicho, te lo hacen a ti cien personas, tienes que responder cuatro, cuatro, cuatro, todo el rato, tiene sentido cachar y ya ni pensar en el cálculo. Me sé la respuesta, te la digo directamente. Estos son las cachés. De forma muy simplista y mal explicada, pues me explico de pena, pero espero que se entienda. Las cachés sirven para evitar hacer cálculos, el mismo cálculo, todo el rato, ¿vale? Las cachés de Drupal son muy, pero muy potentes, bastante más que comparadas con otras cachés de otros CMS y sobre todo porque vienen ya por defecto, o sea, vienen en el core de Drupal, no hace falta instalar nada externo. Sí que es verdad que hay módulos que permiten ampliar y mejorar algunas partes en concreto, pero digamos que lo que viene por defecto es suficientemente bueno para muchas de las webs. Volviendo al tema, cachés, hay dos tipos, ¿vale? Más que los tipos se pueden diferenciar dos muy básicas que son, digamos, una parte que es temporal, por ejemplo, tenemos cachés que podemos decir que cada x horas o cada x minutos caduque la caché, porque el proyecto en concreto nos interesa de que, yo qué sé, cada 24 horas caduque o que cada 10 minutos, porque hay una consulta que se hace a un servidor externo y queremos que cada 10 minutos, por ejemplo, tengamos una respuesta nueva. Pero si tenemos muchas visitas, esos 10 minutos lo queremos cachear para que no hagan muchas consultas a un servidor externo, es por poner un ejemplo. Estos son en base temporal, ¿vale? Es cada x tiempo la caché caduca y en Drupal tenemos otra que es la caché en entidades o por tax, que digamos que si tenemos una caché, por ejemplo, una página de un nodo o de una taxonomía, si no sabes lo que es una entidad, escúchate el episodio, uno de los episodios anteriores que expliqué así por encima qué son las entidades en Drupal, pues tenemos la caché de esa entidad. No va a caducar esa caché hasta que la entidad sea modificada. Con lo cual, si tenemos un nodo, por ejemplo, un artículo del blog y no se edita en un mes, la caché no va a caducar durante ese mes, con lo cual nos ahorramos muchas consultas a base de datos. A ver, lo estoy simplificando mucho, ¿vale? O sea, hay cosas a tener en cuenta, pero simplifico mucho para que se entienda. Esto, si que sea hiperpotente, tiene esos dos tipos de caché porque permiten mucho juego y permite caducar la caché de una forma mucho más eficiente que no solo si fuese en base temporal. Solo te lo comento para que tengas las nocientes más básicas en ese tema. Dicho todo esto, las cachés, cuando se generan, ¿dónde se guardan? Pues en base de datos. Y me dirás, uy, ya, pero si hacemos la caché para evitarnos las consultas a base de datos y metemos la caché en base de datos, no nos agarramos nada, ¿no? Bueno, sí y no, porque no es lo mismo, por ejemplo, en el caso de la operación matemática de 4 más 4, no es lo mismo hacer, por ejemplo, una consulta de dame el primer número, ¿vale? 4 a base de datos. Dame, te consulto a base de datos cuál es la operación, suma, ah, vale. Y dame el segundo número a base de datos, ah, otro 4, vale, 4, perdón, 2 más 2, o 4 más 4, ¿vale? O sea, no es lo mismo hacer tres consultas y después calcular el resultado que directamente hace una consulta a la caché de, ey, dame el resultado de la operación. Y te da el cálculo ya hecho, ¿vale? Muy simplista, es solo una operación matemática, pues en vez de esto es dame cómo se debe renderizar esta página entera o dame cómo se ha de renderizar o calcular x t del web, no es una operación matemática, sino que es un cálculo, digamos, un poco más complejo. Hay muchas cosas en juego, ¿vale? O sea que sí, se ganan cosas teniendo la caché activada, aunque la caché, pues respecto a un Drupal, se guarda en base de datos. Vale, ¿qué módulos tienes que tener activados sí o sí? Drupal depende de si has instalado la versión estándar, la que viene por defecto, o la versión minimal, tendrás los módulos de caché activos o no. Básicamente Drupal tiene dos módulos de caché, la caché dinámica, que creo que era Internal Dynamic Page Caché, o algo así, y lo mismo, pero como está, o sea, el Internal Page Caché, creo que era. Básicamente los dos hacen lo mismo pero enfocado de forma distinta. Uno está más pensado para usuarios anónimos, ¿vale?, que las páginas siempre son las mismas para todos los usuarios, y la otra está más pensada para usuarios dinámicos, usuarios registrados, donde, por ejemplo, el usuario administrador va a ver partes distintas a un usuario que no es administrador, o un usuario que es solo editor de textos. Vale, igualmente, estos dos módulos no tienen configuración alguna, solo se han de activar, y deberían estar sí o sí activados en tu web. Vale, me he encontrado algunas webs que esto no lo tienen activado, deberían estar sí o sí activados. Segundo, en algunas webs me he encontrado que por código, no sé por qué motivo, desactivan cachés en determinadas partes. Me he encontrado, por ejemplo, que en algunas views invalidan la caché de la página. Pero si esa views, esa vista, se usa en varias partes de la web, estás invalidando la caché de muchas páginas. Lo mismo, por ejemplo, con formularios. Me he encontrado que invalidan la caché de formularios y ese formulario lo están incrustando en todas las páginas. En el footer, por ejemplo, con lo cual estás invalidando la caché de todas las páginas. Se han de tener en cuenta cosas cuando invalidas cachés. Y hay gente, normalmente junios o ya ni junios, gente que no trabaja con Drupal, que esto no lo sabe y, digamos, que la lía bastante invalidando cachés. Sobre todo cuando son webs con muchas visitas. Otro web, perdón, otro módulo que debías tener activado es el BigPipe. BigPipe, el que viene en el code, ya digo porque especifico, el BigPipe que viene en el code, trabaja, digamos, no exclusivamente, pero donde se nota más la diferencia con temas de rendimiento es con usuarios registrados, no con usuarios anónimos. BigPipe lo que hace es, a ver cómo me explico, en vez de devolver el resultado de toda la página entera, o sea, una página entera se construye mediante muchas cachés al mismo tiempo. La caché de la cabecera del menú, la caché del footer, la caché del sidebar, la caché del contenido central, la caché del contenido del botón, lo que sea. Todas las cachés juntas generan la página en concreto. Esto es porque, por ejemplo, la caché del header y la caché del footer, seguramente, van a ser la misma para todas las páginas de la web. En cambio, la caché del contenido central solo será para esa página, para esa URL. El resto de URL's tendrán el contenido distinto. Vale, total, que por efecto de ropa lo que hace es, junto a todas las cachés, genero la página y la devuelvo ya montada. BigPie lo que hace es, en vez de devolver de toda la página montada, te devuelvo los segmentos y es el navegador del usuario el que los junta. De hecho, de otro modo, en vez de darte un puzzle ya montado, te doy las piezas ordenadas para que te sea fácil montarlo. Y realmente se nota la diferencia en rendimiento. Porque no es lo mismo que un usuario esté esperando, por decir algo, un segundo o dos segundos, la página en blanco mientras el servidor responde, a que BigPie te devuelva en pocos, yo que sé, por decir algo, en un cuarto de segundo te devuelva la cabecera, justo después te devuelva el footer, justo después te devuelva el contenido, o sea, te va devolviendo fragmentos de contenido y desde el punto de vista del usuario, la carga de la página es más rápida. Realmente no, porque si sumas los tiempos hasta que toda la web está montada, con BigPie estarás lo mismo que directamente toda la web montada sin BigPie. Pero la diferencia es cómo lo percibe el usuario final. Y desde el punto de vista de SEO y de usabilidad es mucho mejor tener BigPie activado. No hay configuración alguna, es activar el módulo y ya está. Y para mí también es un módulo de requisito de tenerlo activado. Aunque digo, se nota mucho más cuando son usuarios registrados. No está tan pensado para usuarios anónimos. Y aquí entra otro módulo que es el SessionLessBigPipe, que básicamente permite que BigPipe se trabaje mucho mejor con cachés de páginas internas para usuarios anónimos. O sea, cuando la página apenas ha cambiado nada. Es otro módulo que no tiene configuraciones, activar y ya está. Y que yo te digo una cosa que me ha pasado en un proyecto, que es que el tema visual, me acuerdo bien bien cómo estaba hecho, pero tampoco era la mejor práctica. Pero ese tema visual de la web se rompió un poco el CSS de la web cuando se instaló el SessionLessBigPipe. Porque no estaba pensado, no es que estuviera pensado, es que habían algunas malas prácticas y realmente se tuvieron que ajustar algunos temas del estilo visual de la web. Lo digo para que lo tengas en cuenta y que no actives esto a lo tonto en producción. Pruebalo antes en local o en desarrollo, ¿vale? Bueno, estos módulos para mí deben estar sí o sin todas las webs. Siguientes módulos. A ver, hemos dicho que las cachés están en base de datos, ¿vale? Una opción de mejorar el rendimiento de las cachés es sacarlas de base de datos. Que básicamente significa meterlas en memoria RAM y que no estén en base de datos. ¿Cómo se pueden sacar a memoria RAM y que Drupal tenga lo que es contenido en base de datos y lo que es caché en memoria RAM? Hay dos módulos, que no son sólo módulos, sino que tienes que configurar el servidor para que trabaje con esas herramientas. Una es memcache y la otra es redis. Cada una de ellas tiene su módulo correspondiente en Drupal, que hace que en Drupal se conecte con redis o se conecte con memcache en vez de conectarse con el caché de base de datos. Sí que hay un poco de configuración, pero muy poca y es bastante simple de activar. La parte compleja es configurar el servidor. Esto ya depende de tu hosting, si permite tener memcache o te permite tener redis. Y o si estás pagando a un DevOps que te gestione el servidor. Pero esto ya es para webs más serias, porque para webs más pequeñas no tiene sentido dedicar el presupuesto a tener memcache o redis. Pero para webs ya más serias, normalmente es muy recomendable tener... Para mí es un poco mejor redis que memcache, pero realmente es muy similar, te sirve cualquiera de los dos. Otros temas. Aquí depende un poco de la tipología de web que tengas. A ver si me explicas. No es lo mismo tener una web que es un buscador, porque por ejemplo tienes muchos productos o muchas páginas. Y básicamente donde el usuario interactúa más es el buscador de la web. Si imagínate Amazon, por ejemplo. Amazon es un buscador de productos, de miles y miles y millones de productos. Si tu caso de uso es que eres un buscador, un directorio, por ejemplo, un Wallapop, por decir algo, que también es un buscador, es un directorio. En este caso es de optimizar las consultas a base de datos. Y en este caso en concreto en Drupal es mejor usar el módulo search API que usar el módulo views por defecto. Porque estás sacando de las búsquedas, no se realizan a MySQL, sino que se realizan contra un servidor externo que normalmente es un solar o un elasticsearch. A mi punto de vista es un poco mejor el elasticsearch, pero te lleva un poco a gustos. Total, que si tu interacción principal de usuarios es con búsquedas, deberías usar un search API con un servidor externo de, con un índice externo de base de datos. Un elástico o un solar. Después, si lo que tiene tu web es por ejemplo muchos artículos, muchos de los cuales después de X años, o sea, son webs con muchísimo contenido y normalmente también con muchos idiomas, generas muchas páginas 404, una cosa a optimizar sería la página de error 404. En Drupal consume, digamos, excesivos recursos para lo que es la página 404 y esto, si tienes muchísimas páginas 404, se nota. Se nota mucho en consumo de RAM y CPU. Es mejor tener una página 404 lo más simple posible. Por ejemplo, hay un módulo que es del fast 404 y si no lo quieres instalar, pues configures directamente desde el servidor Apache o NGINX devuelva una respuesta más simple. O sea, finales, o configuras el servidor para que tenga una respuesta lo más rápida posible o configuras Drupal para que use un módulo como fast 404 que hace que la respuesta de Drupal sea lo más rápida posible o haces que por código o por tema visual la página 404 sea lo más liviana posible. Esto básicamente significa no tener un fórmula de búsqueda en la página 404, no tener el footer con el menú del footer, no tener el header con el menú del header, básicamente no tener nada. Tener una imagen de, ¡uy! 404 y un link que te lleva a la home. Punto. Eso es lo más básico y es lo que mejor funciona por rendimiento. ¿Vale? Eso es como digo, si tienes una web con muchísimo contenido y mucho del cual es un 404. Vaya mejor en Teoria si tuvieras el módulo redirect y en vez de tener páginas 404, redirigías al usuario a la nueva página que le corresponde. Pero es que es muy posible que, por ejemplo, después de una inmigración de una web muy grande te genere muchas páginas 404. Ya sea porque hay contenido que ha dejado de existir o por mala táctica porque no se ha tenido en cuenta o porque realmente el cliente final ha pivotado el negocio y ha dejado de tener contenido que antes recibía visitas. Bueno, en cualquier caso, esto, ten en cuenta que el 404 puede afectar al rendimiento y puede sobrecargar el servidor. ¿Vale? Así que ten la 404 lo más liviana posible. Después, por ejemplo, si tienes webs, o tu web mejor dicho, usan mucho listados de views, creo que no es un episodio de views, creo que el siguiente quizá lo hago de esto. Views es un módulo que te permite, sin tocar código, hacer listados. Creo que sí, que el siguiente episodio lo haga en detalle de esto. Digamos que en los listados de views, la paginación, cuando le marcas que te genere paginación, si usas la paginación completa, donde te muestra todo el número de páginas, digamos que por rendimiento no es del todo bueno. Es mejor si no hay paginación o si usas, por ejemplo, la paginación más básica o si usas la paginación de infinite scroll, donde no hay paginación. Básicamente, cuando haces scroll, se cargan más elementos uno debajo el otro. Esto depende para qué tipo de proyectos puedes ser factible y para qué tipo de proyectos no es factible. Pero solo que sepas que si tus páginas de listados van lentas y todos los listados tuyos tienen paginación completa, podrías probar a quitar la paginación completa. Quizá mejoren algo. No será para tirar cohetes, pero algo hará. Después tema de imágenes. Ya lo medio comenté en el episodio pasado, el tema de optimizar imágenes, las imágenes responsive y estilos de imagen. Básicamente es que sepas de qué deberías optimizar los estilos de imagen. No voy a comentar mucho más. Si te interesa más el tema, escúchate el episodio pasado, donde hablo de SEO, porque la carga de imágenes afecta el SEO y lo comenté en más detalle allí. Pero aquí quiero comentar aparte un par de módulos más de tema de imágenes. Uno es el Image API Optimize, Optimization, no me acuerdo el nombre exacto. Pero básicamente es cambiar el motor de gestión de imágenes y en vez de usar el que viene por defecto en Drupal, se usa otro que hace instalar tú en tu servidor, pero que permite que las imágenes se compriman a un tamaño mucho menor. O sea, el tratamiento es mucho más optimo de imágenes, lo cual genera una imagen de menor peso, lo cual genera una imagen que se descarga mucho más rápido, lo cual si tienes muchas imágenes en tu web, significa que la web en general carga un poquito más rápido. Así que también te recomiendo que intentes optimizar cuanto puedas la gestión de imágenes en tu web. De la misma forma, en vez de intentar comprimir lo máximo posible las imágenes JPG o PNG, hay otro módulo que es WebP, que es un formato de imagen que se sacó Google de la manga y básicamente comprime la imagen mucho mejor que un JPG. O sea, pesa mucho menos una imagen WebP que una imagen JPG. Es un módulo que está en Drupal, lo hace instalar y básicamente las imágenes pesan menos y la web carga más rápido. Después también, si tu web tiene muchísimas imágenes, por ejemplo tienes un escaparate de productos o algo similar, y son sobre todo imágenes de alta calidad, donde puedes comprimir el tamaño hasta cierto aspecto, pero si lo haces mucho más, quizá pierdes un poco de calidad y no te interesa. Una opción es el lazy loader. Básicamente es cuando estás haciendo scroll, a ver cómo digo, cuando cargas la página solo ves un fragmento de la web, o sea, ves la parte de arriba de la web. Cuando haces scroll, ves el resto de la web. Si tienes, por ejemplo, 20 imágenes, en la primera carga de página solo ves las dos o tres imágenes que están más arriba. Con lazy loaders, lo que haces es solo cargas estas tres imágenes visibles y cuando haces scroll te cargará las imágenes que vayas viendo debajo. Seguro que lo has visto en muchas webs, que cuando estás haciendo scroll te sale un cargando y al cabo de un segundo se vea la imagen. Esto es una técnica de evitar que la web tarde mucho en cargar por culpa de las imágenes. Se ha de tener en cuenta que hay veces que Google lo penaliza si lo que te interesa es el SEO de imágenes. En muchos casos lo que a cliente le importa es el SEO de la página, no de la imagen. En ese sentido no hay ningún problema y recomiendo usarlo, pero si lo que te interesa a ti es que en Google Images salgan tus imágenes bien posicionadas, eso te puede penalizar. Solo tenlo en cuenta. Y creo que ya está que me he alargado mucho con este episodio y tengo una idea de esto. La semana que viene, seguramente, hablaré sobre views, que es el módulo, cómo usarlo más o menos y por qué. Debes saber cómo configurarlo. Y nada más, si te interesa el tema, suscríbete y estáte atento hasta la semana que viene. Chao.