Típicas malas configuraciones del Core de Drupal que afectan a la velocidad de carga

 Hola, bienvenidos aquí una semana más con Drupalizate. Hoy quiero contaros básicamente las cosas que me he encontrado yo en webs ya hechas por otra gente, que son cosas que hacen que el Drupal sea lento. No es que el Drupal sea lento, sino que está mal configurado o se está usando mal. Y lo tengo resumido en dos partes. Una es gestión de imágenes, que no sé por qué mucha gente lo usa mal. Y la otra es el tema de cachés. Voy a hablar sólo de lo que es el core de Drupal, sin instalar ningún módulo extra, ni contribuido, ni custom, ni nada. Es sólo con el core, tal como viene Drupal. Como mucho se activa algún módulo interno del core de Drupal, para que quede claro. No voy a hablar de ni redis, ni memcache, ni temas de cargas a síncronos de imágenes, ni nada que no esté en el core. Dicho eso, el primer apartado y el más típico que veo que siempre está mal, el tema de las imágenes. Supongo que tú sabes, tú que me escuchas y sabes algo de Drupal ya, que tenemos el módulo de estilos de imagen, que sirve para que cuando un usuario sube una imagen a Drupal de 2000x2000 píxeles, si en el sitio donde Drupal la tiene que mostrar no hace falta esa de 2000 píxeles, sino que con 500 ya no sirve, porque es una imagen que se va a demostrar más pequeña del tamaño original. Si configuras Drupal en un estilo de imagen de ese tamaño, pues lo que da Drupal es hacerte una copia y redimensionarla, o recortarla, o hacerle cosas, dependiendo de lo que has configurado, para tener un estilo de imagen nuevo. O sea, una imagen modificada de la original. Tienes la original guardada, que apenas se usa, y a raíz de esta hace una copia y hace modificaciones, y tienes varias copias con distintos estilos de imagen, pues uno de cabecera que sea más programático, uno del listado de noticias que sea más cuadrado, una que sale en la home que es más grande que la del listado, y así. Se puede tener tantos estilos como tú quieras. Esto ya depende más de tu diseño, visualmente cómo se ha de ver la web y la imagen. El problema es que me encuentro en muchas webs que esto no lo usan. No tiene estilos de imagen. Tienen los estilos de imagen que vienen en Drupal por defecto, que son tres básicamente, y como no les sirven para su diseño, pues no los usan. Está mostrando en todas partes la imagen original. Me he encontrado algunos que se quejaban de que, claro, es que esto es una mierda, tengo que estar recortando la imagen yo en local y subiendo ya la imagen adaptada. Y yo me quedé, no, no, no, no. Que en Drupal te lo puedes gestionar todo el solito. O sea, no hace falta que en tu local tengas, o sea, en tu máquina, en tu ordenador, un programa que te recote las imágenes a distintos tamaños y que en tu nodo, en tu página, tengas varios campos distintos de imagen de cabecera, imagen de la home, imagen de... No, no. La misma imagen y que Drupal la recorte, la escale, le haga cosas. Bueno, pues me han contado cosas de estas. Así que el primer fallo es no saber configurar los estilos de imagen correctamente. Segundo, también de temas de imágenes, imágenes responsive. Hoy en día cualquier web es responsive. Eso significa que tenemos un diseño un poco distinto para lo que es móvil, para tablet y para escritorio. Mínimo tenemos esos tres. Podemos tener más, pero digamos que lo mínimo son esos tres, digamos, backpoints. Vale, ¿qué pasa con esto? Que quizás, bueno, quizás no, casi siempre queremos tener la misma imagen pero que se ve distinto en cada dispositivo. En dispositivos móviles, por ejemplo, si tenemos un listado de imágenes o de artículos, la imagen acostumbra ser un poco más panorámica, no tan cuadrada como la que se muestra en escritorio. ¿Por qué? Porque queremos que ocupe menos espacio la imagen en dispositivos móviles. O sea, que no ocupe casi toda la pantalla, sino que te invite a hacer scroll porque ves que hay títulos y otros artículos debajo del artículo principal. Bueno, lo que voy, que eso depende del diseño, ¿vale? Pero que en la mayoría de casos queremos tener imágenes en formato distinto. Ya no digo solo de tamaño, sino de formato. Con Drupal y el módulo de Responsive Image que viene en el Core, puedes configurar un estilo de imagen Responsive que use estilos de imagen, como digo, pues uno para móvil, uno para tablet y otro para escritorio. Y en Responsive la web va a detectar de, ah, el usuario está navegando como móvil, le voy a mostrar las imágenes con el estilo que está configurado para móviles. O está navegando por escritorio, o sea, por tamaño de pantalla grande, pues le voy a mostrar imágenes en un estilo de imagen, digamos, más grande. ¿Esto por qué? Basicamente por rendimiento. En móvil no hace falta que la imagen tenga más de 400 píxeles de ancho, porque la pantalla móvil acostumbran a hacer render por aquí. Con lo cual, si tenemos un estilo de imagen que escala la imagen, la recorta, la hace más pequeña, menos peso, los móviles van a consumir menos ancho de banda y, sobre todo cuando no estamos en Wifi, cuando estamos por 3G, las imágenes se van a descargar más rápido porque pesan menos. Del mismo modo, cuando estamos en escritorio, como que el tamaño, entre comillas, nos da un poco igual y queremos que la imagen se vea todo lo que pueda dar, o sea, si tenemos la pantalla de 25 pulgadas o de 29 o de 32, queremos que se vea lo más grande posible dentro del diseño. Total, usar estilos de imagen, uno. Dos, usar los estilos de imagen Responsive, si es que tu web es Responsive, que, como digo, hoy en día es la mayoría de casos. Me he encontrado muchísimas webs que no usan ninguna de estas dos. ¿Qué usan entonces? Pues directamente, o configuran, no tengo la configuración, lo que viene por defecto, que es imagen en tamaño original, que está mal, pero bueno. Pues que ya el top del sumo, lo que me he encontrado es gente que en las plantillas, en este caso hablamos de 8.9, son plantillas twig, en vez de renderizar el campo imagen, que como digo está configurado por defecto con tamaño original, no, no, lo que hacen es obtienen el valor dentro del campo, no lo que se configura para que renderice, sino el node.nomeDelCampo.value o URL y aquí ya pintan los valores de los campos. Eso es el tc error que me encuentro bastante, ya sea de imágenes, urls o textos. En vez de usar lo que puedes configurar en Drupal, que gestione las cachés, que te limpia que no haya html o inyecciones de código, no, no, directamente lo que está en base de datos, vale, aquí te lo pinto y me quedo tan pancho, con lo cual están metiendo en el html el tag de imagen y en la url el valor que viene directamente de la base de datos. Esto está mal, vale, y me sorprende la de veces que me he encontrado esto, así que evítalo. Directamente usa el content.nomeDelCampo, que es lo que te da Drupal por defecto y en la configuración del view mode en Drupal le dices de no, quiero este tipo de estilo de imagen o este responsive o quiero un enlace pero en formato texto o en formato x, o sea, usa la configuración de Drupal que para eso está y es muy útil y te genera las cachés, vale, es que me sorprende la gente que no usa esto, que es una de las mayores ventajas son los view modes de Drupal, la gestión de campos y la renderización de los campos. Vale, y con esto más o menos acabo con el primer apartado que era imágenes y el tema de plantillas. Segundo apartado, donde veo que se falla muchísimo y básicamente es hacer dos clics. El primero es la compresión de css y javascript. Me sorprende la de webs que me llegan, que veo que no tienen ni el css comprimido ni el javascript comprimido. Esto para intentar explicarme para la gente que no sepa de qué estoy hablando, digamos que los temas visuales cuando tienes un tema en Drupal, o ya no un tema sino el tema y varios módulos que he instalado, si todos estos módulos y temas tienen css vas a tener, por decir algo un número un poco al azar, pero 20, 30 ficheros css o ficheros javascript. El problema que el navegador se tiene que estar bajando constantemente esta cantidad de ficheros. Y otro problema a tener en cuenta es que el navegador una vez se ha bajado estos ficheros los guarda en caché del navegador. Con lo cual si de aquí a una semana modificas el css, el navegador sigue teniendo en caché el ficher antiguo, con lo cual no ves los cambios o no todos los usuarios ven los cambios css. Lo cual es un problema cuando estás marcar la web, se detecta que hay un fallo de un color que está mal, un tamaño que está mal, se modifica y cliente se te queja de no, aún no veo el cambio subido. Y tú cómo que no veo el cambio? Vale pues porque estás usando los ficheros css y javascript tal cual, sin comprimir. Ventajas de comprimirlos es ir a confiación de rupal, rendimiento y hay un checkbox para css y un checkbox para javascript de compresión. Normalmente no tienen que estar activados en desarrollo o en local cuando se está desarrollando la web, pero en producción deberían estar siempre activados. Basicamente lo que hacen estos checkboxes es juntar los ficheros. De 20 o 30 ficheros css pasaremos a tener 1, 2, 3 ficheros y con un nombre que tiene un hash en el nombre de fichero y cuando se vuelva a vaciar la caché y se vuelve a generar un nuevo fichero comprimido, el nombre de fichero ese hash que decía antes estará modificado. Con lo cual como tiene un nombre de fichero distinto, el navegador va a cargar de nuevo, estamos forzando al navegador a que se vuelva a descargar ese fichero. Con lo cual no estará en caché, con lo cual cuando se hacen cambios y se vacíen cachés del rupal, el navegador va a ver todos los últimos cambios y no tienes el problema de que cliente es que yo no veo el cambio que ha subido, no lo ha subido bien. Cuando se vacíen cachés es cuando se ve el cambio y cuando tienes la compresión activada. Y en javascript, perdón, en javascript lo mismo que en css. Si tienes la compresión activada, ves los cambios al momento, si no pues es un marrón y hay javascript que no funciona porque estás en tu navegador mostrando javascript antiguo. Es uno de los problemas más típicos que veo, que muchas webs no usan la compresión de javascript y css y es que realmente es darle a un checkbox. Otro punto, el tema de las cachés. Ya no es la compresión sino son las cachés. En la misma página de configuración en rendimiento, donde hay los dos checkboxes de compresión de javascript css, hay un desplegable y un checkbox de activar cachés en las páginas y pues configurar el tiempo de caché. Si lo quieres de 10 minutos o de un día o de lo que tú quieras. ¿Por qué es importante esto? Porque esto depende más del tipo de web que tengas, pero si es una web que no tiene muchos cambios, donde estás subiendo solo artículos, es un blog y estás subiendo artículos, la caché tiene sentido que se vacíe cuando se genera un nuevo artículo. No tiene sentido que cada 10 minutos estés vaciando la caché automáticamente o que directamente no tengas caché. Al final es una web entre comillas muy estática, porque los contenidos no cambian constantemente. Cambian cada x horas o cada x días. En estos sitios tiene mucho sentido activar las cachés y ponerlo lo máximo que puedas, a días. Y nada, que actives las cachés. Que me sorprende la de webs que no tienen las cachés activas. Después la web valenta, pues claro. Las cachés sirven para no ser consultas a la base de datos. Si no tienes cachés, estás haciendo muchas consultas innecesarias a la base de datos. Así que activa las que es gratis y es muy fácil. Y el último punto de esto es las cachés o el debug de Twig. Twig es el sistema de plantillas que usa Drupal. Y el problema que tenemos con Twig, esto me lo contar mucho menos, porque primero no viene activado por efecto, lo tienes que activar tú en un fichero, o sea no es una configuración visual, es un fichero de configuración de código, donde activas el debug de las plantillas Twig. Como digo, esto viene desactivado por efecto y mucha gente, como mucha gente, desarrolladoras que saben un poco lo que hacen, lo activan en desarrollo o en local. El problema, que se queda activado en producción. Y esto realmente perjudica muchísimo, pero muchísimo el rendimiento. Así que lo que... y esto, primero, para que la gente sepa que hace, evita la caché de los fichos Twig y añade comentarios en el HTML para saber en qué tipo de fichero, o sea el nombre del fichero que está usando en determinadas partes de la web. O sea, va muy bien para hacer debug de plantillas y temas de front-end. Pero como digo, en producción no tiene ningún sentido que estés mostrando comentarios en el HTML, muchos comentarios en el HTML, para que la gente vea qué plantillas están usando y después de que no tengas las cachés propias de Twig. Al final tenemos cachés de Drupal, que son las cachés de la base de datos. Tenemos cachés del navegador de CSS y JavaScript. Y tenemos las cachés de Twig, que no son envasados, sino que te genera un fichero nuevo, que digamos que es como que se compila, para que se me entienda, las plantillas visuales de la web. Tenemos estos tres tipos de cachés y me encuentro muchas webs que no usan ninguno de los tres. Así que las buenas prácticas, intenta tener los tres tipos activados. Y aunque sean webs pequeñas, la verdad es que se nota. Y al final, si puedes tener un servidor más pequeño, porque la web está mejor optimizada, pues tienes un menor coste. Y nada más, que creo que con esto ya queda más o menos claro los típicos fallos que me encuentro de malas configuraciones de rendimiento para cosas que son contribuidas, perdón, que son del code, que no son contribuidas de Drupal, que no hace falta instalar nada más. Drupal ya de por sí, si se usa bien, es muy potente. Así que nada más, hasta la semana que viene. Espero que haya sido útil esta semana.