En la segunda parte de esta serie describí cómo desbloquear un nivel básico de rendimiento de tu sitio Joomla con unos pocos y simples cambios. Hoy vamos a profundizar en los medios estáticos: JavaScript, CSS y archivos de imagen. Estos cambios son más complejos, pero pueden convertir un cacharro de un sitio lento en uno con un rendimiento decente. Podría decirse que no todos estos cambios tienen sentido para todos los sitios, pero los beneficios de rendimiento que consigues son sustanciales.
Una gran parte de tu sitio web viene en forma de archivos multimedia estáticos: CSS, JavaScript, imágenes y posiblemente también audio y vídeo. Tendemos a no pensar mucho en ellos, considerándolos secundarios respecto a nuestro contenido, pero suelen constituir la mayor parte de los datos transferidos desde el servidor de tu sitio al dispositivo del usuario cuando éste visita una página. Además, el análisis de archivos CSS y JavaScript grandes o la decodificación de imágenes de gran tamaño congela el hilo principal del navegador, lo que, en términos sencillos, significa que el navegador no puede realizar ningún trabajo para renderizar la página (sólo puede descargar más datos en segundo plano). Además, cuantos más archivos CSS, JavaScript e imágenes tenga, más tiempo tardarán en cargarse, lo que significa que el navegador tiene que dejar de renderizar la página y recalcular todo desde cero cada vez que uno de estos archivos termina de cargarse. Esto puede hacer que la página se vea más lenta o causar otros defectos de representación, como que el contenido salte por la pantalla (lo que se llama "Layout Shift" en la jerga del navegador).
Optimice sus imágenes
Si tienes un sitio con muchas imágenes, como un blog o un sitio de noticias, la mayor parte de la transferencia de contenido de tu página son las imágenes. Probablemente estás acostumbrado a tomar una imagen, subirla con el Gestor de Medios de Joomla, tal vez redimensionarla o recortarla un poco - ¡El Gestor de Medios de Joomla 4 ahora puede hacer eso! - y darlo por terminado. Bien por ti, pero es muy probable que tus imágenes no estén optimizadas y sean más grandes (en Kilobytes, no necesariamente en dimensiones) de lo que deberían.
Tal vez conozcas vagamente o en profundidad herramientas como pngcrush y mozjpeg. Si te sientes cómodo con la línea de comandos, utilízalas para optimizar tus imágenes.
Incluso más fácil, hay una herramienta gratuita llamada ImageOptim para Windows, macOS y Linux que puede ejecutar varias de estas herramientas contra tus imágenes y elegir el archivo más pequeño. Es muy sencillo. Arrastra y suelta tu carpeta de imágenes en la herramienta. Espera a que termine. Tus imágenes serán reemplazadas por sus versiones optimizadas. Obviamente, esto debe hacerse primero en una copia local de tu sitio. Si no estás seguro, guarda una copia de tus imágenes originales porque ImageOptim sobrescribe tus imágenes con las versiones optimizadas.
Haz tus imágenes adaptables
Ya sabes que tu sitio se mostrará en dispositivos con diferentes tamaños de pantalla: teléfonos Android baratos de menos de 5", teléfonos inteligentes populares de 6", phablets o tabletas pequeñas de más de 7", tabletas de 10" a 11", ordenadores portátiles de 13" a 15" y enormes monitores de escritorio de más de 23". Ya lo has tenido en cuenta haciendo que tu sitio sea reactivo, lo que significa que tu contenido se adapta a los modos de interacción más apropiados para el tamaño de la pantalla en la que se muestra tu sitio.
¿Pero qué pasa con tus imágenes?
Cuando los dispositivos a los que se dirige el sitio van desde un teléfono barato de 380px hasta un ordenador de sobremesa de 5120px de ancho, el mismo archivo de imagen no es apropiado para todos los tamaños. Si se optimiza para la pantalla pequeña, la imagen se verá borrosa y pixelada en la pantalla grande. Si se optimiza para la pantalla grande, la mayoría de los visitantes descargarán un archivo innecesariamente grande para mostrar una imagen mucho más pequeña. Optimizar para el tamaño de dispositivo más común entre tu audiencia es lo peor de ambos mundos: los dispositivos pequeños descargan un archivo grande y las pantallas grandes muestran una foto borrosa.
Si ademas empiezas a tener en cuenta los dispositivos HiDPI con densidades de píxeles que son 2x, 3x o 4x la densidad de pantalla estándar (el estándar es 96 píxeles por pulgada) tienes todo un rompecabezas que resolver. ¿Debes elegir un archivo razonablemente pequeño que se mostrará mal en muchos dispositivos o un archivo enorme que se mostrará bien en todos los dispositivos pero que tiene un tamaño de un par de megabytes?
Por suerte, no hay que elegir. Los navegadores llevan mucho tiempo soportando imágenes adaptables. En resumen, utilizando el elemento PICTURE con las apropiadas media queries puedes decirle al navegador que seleccione automáticamente el archivo de imagen correcto para la pantalla (resolución y DPI) en la que se está renderizando tu sitio. Si el tamaño de la pantalla cambia, por ejemplo, si el usuario gira su dispositivo de vertical a horizontal o cambia el tamaño de la ventana del navegador en el escritorio, el navegador sabrá qué hacer. Si tiene una imagen lo suficientemente grande, la reducirá. Si no la tiene y has indicado en tu elemento PICTURE que hay un archivo de imagen más apropiado para las dimensiones requeridas, lo cargará en su lugar. Mientras se carga la imagen más grande, la más pequeña aparecerá escalada, por lo que desde la perspectiva del usuario hay un poco de desenfoque en las imágenes que desaparece en un corto período de tiempo.
Otra cosa mágica que puedes hacer con el elemento PICTURE es hacer que el navegador seleccione el formato de archivo más apropiado que soporte. La mayoría de las imágenes en la web son JPG o PNG. Se trata de formatos de imagen heredados, que se remontan a los años 90 o incluso antes. La mayoría de los navegadores modernos también soportan WEBP, un formato de archivo de imagen mucho más eficiente que da como resultado archivos mucho más pequeños y que soporta la transparencia. Desde tu perspectiva como constructor de sitios, es como un PNG con esteroides. Desafortunadamente, no puedes convertir todo a WEBP porque las versiones más antiguas de los navegadores (y todas las versiones de Safari) no soportan WEBP en absoluto.
A estas alturas puede que te estés agarrando la cabeza con desesperación. Lo que era simplemente subir un único archivo de imagen y poner una etiqueta IMG en tu contenido se ha convertido ahora en un rompecabezas que requiere crear varios tamaños y tipos de imagen diferentes. Esto es difícil para ti, el integrador del sitio, y directamente imposible para tus clientes.
Por suerte, hay extensiones de Joomla de terceros que pueden manejar esto por ti. He utilizado XT Adaptive Images Pro en el pasado. También está Econa y posiblemente otros - puedes sumergirte en el Directorio de Extensiones de Joomla donde hay una extensión para cada necesidad y presupuesto.
Otra opción es seguir adelante con los overrides de diseño y un helper que crea automáticamente versiones adaptables de tus imágenes. Este es el código que he aportado a la plantilla Lightning de Charlie Lodder. Si hacer plantillas personalizadas es tu problema, puedes adaptar fácilmente estos overrides de diseño y la clase helper para usarlos en tu propia plantilla.
Ilustraciones vectoriales
Otra cuestión que hay que tener en cuenta sobre las imágenes es que las ilustraciones (a diferencia de las fotografías) suelen empezar su vida como archivo vectorial en algo como Adobe Illustrator o Affinity Designer. Lo que solemos ver es que éstas se convierten en archivos PNG transparentes antes de ser utilizadas en un sitio. Esta es la forma menos eficiente de hacerlo.
Hace tiempo que los navegadores admiten archivos de gráficos vectoriales escalables (SVG), pequeños archivos de texto que describen gráficos vectoriales. Suelen ser mucho más pequeños que los formatos de archivo optimizados para la fotografía (JPG, PNG e incluso WEBP), son mucho más comprimibles debido a que son texto plano y pueden ser escalados a cualquier tamaño, desde el más pequeño al más grande, en cualquier resolución de pantalla sin perder nitidez.
Mientras que en Joomla 3 había una llamativa ausencia de cualquier soporte para SVG - o incluso la posibilidad de añadirlo sin utilizar extensiones de terceros - esto es perfectamente posible en Joomla 4, siempre y cuando lo habilites manualmente. Ve a Contenido, Medios y haz clic en Opciones. Cambia las extensiones de imagen admitidas (tipos de archivo) para incluir SVG, es decir, cámbialo a
bmp,gif,jpg,png,svg
Si has activado la restricción de subidas (¡deberías hacerlo!), cambia también las extensiones permitidas para incluir svg, es decir
bmp,gif,jpg,jpeg,png,webp,ico,mp3,mp4,odg,odp,ods,odt,pdf,png,ppt,txt,xcf,xls,csv,svg
Si has activado Comprobar tipos MIME también tendrás que añadir image/svg+xml a Tipos MIME admitidos, es decir
image/jpeg,image/gif,image/png,image/bmp,application/msword,application/excel,application/pdf,application/powerpoint,text/plain,application/x-zip,image/svg+xml
Haga clic en Guardar y Cerrar. Ahora Joomla le permite subir archivos SVG y utilizarlos allí donde se permita insertar una imagen.
Una nota final de precaución: no trates de usar archivos SVG en elementos que esperan obtener su tamaño del contenido (los archivos SVG no tienen una anchura y altura fija intrínseca para todos los aspectos del navegador, aunque se especifique una en el archivo) y no trates de usar archivos SVG como imágenes de fondo. Hay formas de hacer ambas cosas, pero lo más probable es que sufras innecesariamente.
No te metas con JavaScript y CSS
En los últimos 15 años ha habido varias técnicas para hacer más rápida la carga de JavaScript y CSS. Normalmente se reducen a las siguientes técnicas: combinar archivos, minificar archivos, GZipear archivos y mover la carga de JS/CSS a la parte inferior del documento HTML.
No hagas nada de eso. No utilices ningún plugin que haga nada de eso. Estas son ideas increíblemente malas en Joomla 4 - ¡y no las necesitas!
La combinación de archivos provoca un montón de situaciones de huevo y gallina. Necesitas saber en qué orden deben combinarse los archivos en cada una de las páginas de tu sitio y depurar el desorden cuando algo no funciona. También resuelve exactamente cero problemas; el mes pasado hablamos de cómo los navegadores descargan cosas para preparar la página para su visualización.
Minificar los archivos JavaScript y CSS usando código PHP es completamente contraproducente. Esto funcionaba hace unos 12 años cuando estos archivos eran muy simples. Los archivos JavaScript y CSS modernos necesitan de un código más especializado, que no sea PHP, para minificarlos, por ejemplo, Babel y Closure. La mayoría de los desarrolladores minifican su código de todos modos y Joomla tiene soporte completo para archivos minificados desde los primeros días de Joomla 3.0.
Usar un plugin para comprimir tus archivos es increíblemente ineficiente y resultará en tiempos de carga de la página más largos. El mes pasado hablamos de cómo puedes hacer que tu servidor web lo haga de forma más eficiente y decirle al navegador que guarde en caché los archivos estáticos.
Mover los archivos JavaScript de la cabecera a la parte inferior de la página es buscarse problemas. Si hay un script en línea en la cabecera o en el cuerpo del documento que hace referencia a ese código que el desarrollador esperaba razonablemente que ya estuviera cargado, tu sitio aparecerá roto. Joomla 4 soporta la carga diferida y asíncrona de scripts. Si el desarrollador sabe que su JavaScript puede soportar eso, lo utilizará y tiene prácticamente el mismo efecto (¡en realidad, una ganancia de rendimiento aún mayor!) que mover el JavaScript a la parte inferior del documento HTML.
Por último, mover el CSS a la parte inferior del documento HTML crea un problema mayor del que resuelve. El navegador renderiza la página completa sin estilo, luego lee la hoja de estilos y tiene que empezar de nuevo. Esto causa un montón de trabajo extra y hace que tu sitio se renderice más lentamente mientras, al mismo tiempo, la página parpadea y se mueve mientras se vuelve a renderizar. Es una experiencia de usuario horrible.
Así que, por favor, no utilices ningún plugin que haga estas cosas para supuestamente "optimizar" tu sitio. Hace una década eran relevantes, pero ya no lo son.
Utilizar una CDN
El mayor cuello de botella del rendimiento de tu sitio es la entrega de tus archivos estáticos: imágenes, CSS, JavaScript, vídeos, audio. Esto se ve agravado por dos factores intrínsecos a tener un sitio: el ancho de banda disponible y la proximidad al usuario.
El ancho de banda disponible es el "límite de velocidad" al que el servidor de tu sitio puede enviar bytes a un cliente. Claro, puedes tener una conexión a Internet de un Gigabit de fibra o una conexión móvil 5G súper rápida en tu terminal. Si el servidor alcanza un máximo de 20 Mbps, esto, o más bien una fracción de esto, es la velocidad a la que todo el contenido de ese servidor llegará a su dispositivo.
La proximidad al usuario tiene que ver con el límite máximo de velocidad del universo: la velocidad de la luz. Algunos de vosotros os estáis riendo. Pues bien, ¡es cierto! Todos los datos de los servidores de tu sitio pasan por conexiones de fibra óptica, es decir, luz láser guiada por conductos de vidrio. Ese es el 99,9% de su recorrido. El otro 0,1% pueden ser cables de cobre (ADSL/VDSL), microondas (Internet por satélite, 5G, WiFi) o pulsos eléctricos (Ethernet). La luz láser no puede viajar más rápido que la velocidad de la luz; de hecho, viaja a aproximadamente 0,9c, el 90% de la velocidad de la luz o poco menos de 270.000 Kilómetros por segundo / 168.000 millas por segundo. Si su servidor está al otro lado del mundo, necesita recorrer unos 20.000 kilómetros, lo que nos da unos 75 milisegundos. La transferencia de datos requiere un viaje de ida y vuelta (enviar la solicitud, recibir el resultado), así que tenemos 150 mseg extra de espera antes de que algo llegue desde ese servidor al dispositivo del usuario. Cuanto más cerca esté el servidor del usuario, más rápida será la transferencia de datos.
Comprar más ancho de banda a tu proveedor de alojamiento puede ser posible pero caro. Cambiar la ubicación del servidor puede ser poco práctico, sobre todo si se da servicio a una ubicación geográfica mayor que un país del tamaño de Europa o un estado de Estados Unidos.
La solución a ambos problemas es utilizar una CDN (Red de Entrega de Contenidos). Una CDN tiene múltiples servidores, llamados nodos, en centros de datos de todo el mundo. Sus archivos estáticos se almacenan en caché en esos nodos. Cuando un cliente pide una página de tu sitio la CDN reenvía la petición a tu servidor, tu servidor ejecuta Joomla y envía el contenido HTML de vuelta al usuario a través del nodo de la CDN. Sin embargo, cuando el navegador pide el contenido estático de tu sitio -el JavaScript, el CSS, las imágenes, etc., necesarios para representar la página- el nodo de la CDN lo tiene almacenado en la caché y lo entrega desde el nodo más cercano al usuario. La CDN también tiene mucho ancho de banda, ya que lo compran al por mayor a un precio mucho más bajo que el de tu proveedor, lo que significa que pueden saturar una conexión rápida Gigabit o 5G aunque tu servidor no pueda. El efecto combinado es que tu sitio se carga mucho más rápido.
Hay un montón de CDNs por ahí. Yo uso CloudFlare porque es un servicio combinado de CDN, optimización del sitio y seguridad del sitio. Las características de optimización que ofrece pueden manejar automáticamente la compresión de tus recursos estáticos si tu servidor no lo soporta. Dependiendo de tus necesidades, hay un nivel gratuito pero también niveles de pago con muchas más características.
No es necesario utilizar una CDN. Si tienes un sitio que va a dar servicio a una gran área geográfica o esperas que se llene de peticiones, entonces sí, es algo que debes considerar. Pagar por una CDN suele ser mucho más barato y un dolor de cabeza mucho menor que pasar a un servidor dedicado.
Continuará
El mes que viene hablaremos de la calistenia de la construcción de sitios para aquellos de vosotros que construís o personalizáis vuestras plantillas. El último artículo de esta serie se publicará dentro de dos meses con consejos y trucos sobre la calidad del contenido y la optimización del mismo no sólo para los motores de búsqueda, sino también para los visitantes humanos. Hasta entonces, ¡feliz construcción del sitio!
Este artículo es una traducción de Joomla Performance Tuning III: Static Media Optimization.
