En la Puesta a punto del rendimiento de Joomla 4 - Parte I describí por qué afinar el rendimiento de tu sitio es algo que deberías hacer por razones tanto filosóficas como prácticas, así como por dónde empezar. Ese artículo era necesariamente un poco genérico. En la segunda parte de esta serie nos sumergiremos en algunas de las cosas básicas que puedes hacer en Joomla para liberar una buena cantidad de rendimiento.
Ajustes básicos del sistema
Cuando construimos un sitio, nos centramos tanto en el diseño y la funcionalidad que nos olvidamos de que algunas configuraciones básicas y bastante sencillas del sistema pueden tener un gran impacto en el rendimiento de nuestros sitios. Unos simples cambios en la Configuración Global antes de publicar el sitio y unas simples comprobaciones del servidor pueden marcar la diferencia.
Caché
La mayor parte del tiempo invertido en el lado del servidor de un sitio tiene que ver con la construcción de la página que se mostrará al visitante. Joomla, a diferencia de WordPress, tiene un sistema de caché incorporado. Creo que la gente no le da suficiente crédito porque estaban acostumbrados a la mediocre experiencia de caché en Joomla 1.0 y 1.5. Eso fue hace 10 o 15 años.
Ve a la Configuración Global de tu sitio y establece el caché en " Activado - Caché progresiva". La opción de caché progresiva es la mejor implementación de la caché integrada de Joomla, asegurándose de que la salida de cada extensión utilizada para construir su página se almacena en caché de forma individual. Cuando llega una solicitud, la página se une a partir de esas piezas de contenido en caché siempre que sea posible. Esto puede incluso servir para mitigar la pérdida de rendimiento de una plantilla pre-construida y no optimizada. Definitivamente contribuirá a hacer más rápidas tus páginas públicas, en las que no se ha iniciado sesión, que es exactamente lo que más interesa para la posición de tu sitio en los motores de búsqueda.
En cuanto al back-end de la caché, la mayoría de los sitios pueden arreglárselas con el almacenamiento en caché de archivos, cuyo rendimiento es similar al de memcached o Redis, ejecutándose en un hosting decente, comercial, compartido o virtualizado, con mucho menos uso de memoria y, por tanto, mucho más barato de ejecutar. "¡Herejía!", gritan los más expertos entre vosotros. Estoy de acuerdo con tu sentimiento, hasta cierto punto. Si tienes un sitio realmente inmenso o extremadamente concurrido, tiene sentido utilizar un servidor memcached o Redis dedicado como backend de almacenamiento en caché. Será más rápido. Lo más probable es que, si estás leyendo esto, no tengas realmente este tipo de sitio, y estés buscando acelerar un sitio común y corriente. Incluso mi propio sitio profesional entra en esta categoría, a pesar de que recibimos un tráfico del orden de cientos de docenas de miles de visitantes únicos mensuales. Eso debería darte una idea de la dimensión del sitio que se beneficiaría del almacenamiento en caché utilizando un servidor de caché dedicado.
Compresión HTML
Si hubiera un concurso para la opción más ignorada en Joomla, la compresión de páginas Gzip ganaría sin duda alguna. Si aún no lo has hecho, no lo dudes y actívala.
Esta opción hace que el contenido HTML enviado por tu sitio al navegador se comprima utilizando el algoritmo GZip (también llamado "deflate"). Esto reduce sustancialmente el tamaño total de los datos transferidos al cliente. La cantidad de tiempo que se ahorra en la transferencia de datos tiene un impacto significativo en el rendimiento de tu sitio.
¿Esto no ralentiza el sitio? No, en realidad no. Las páginas HTML generadas por Joomla tienen un tamaño de pocas docenas de kilobytes. Se tarda una fracción de milisegundo en comprimirlas hasta un tercio o la mitad de ese tamaño. Con las velocidades de transferencia típicas entre un servidor y sus visitantes esto se traduce en un par de milisegundos de tiempo ganado. Se ganan entre el doble y el triple de tiempo del que se pierde en este caso.
Compresión de JavaScript y CSS
Muchas plantillas y plugins de terceros pretenden ahorrar tiempo comprimiendo tus archivos estáticos (JavaScript y CSS) sobre la marcha. Te recomiendo encarecidamente que no utilices este tipo de funciones. Mientras que la compresión de los archivos estáticos ahorra tiempo de transmisión, terminas con una pérdida neta de rendimiento.
La razón de este paradójico resultado requiere hablar de cómo los servidores entregan el contenido estático y dinámico. Un servidor web bien configurado almacena en la memoria los contenidos estáticos utilizados con frecuencia. Además, utiliza funciones avanzadas del sistema operativo, como la asignación de archivos a la memoria. Esto da como resultado una entrega muy rápida del contenido estático.
Cuando se utiliza una secuencia de comandos PHP para comprimir los archivos estáticos, el servidor web tiene que entregar la solicitud al ejecutable PHP. En el mejor de los casos (PHP FastCGI Process Manager o PHP-FPM, con un grupo de procesos lo suficientemente grande y PHP OPcache habilitado) esto todavía pierde algo de tiempo haciendo la comunicación entre procesos y restableciendo el estado del analizador PHP. La secuencia de comandos necesita ser confirmada como sin cambios, su representación binaria precompilada cargada e interpretada, ejecutada por el binario PHP, el archivo estático necesita ser abierto, su contenido comprimido y enviado a Apache para entregarlo al cliente. Todo esto lleva docenas de milisegundos. ¡A menos que esté comprimiendo un archivo de más de varios cientos de kilobytes, la cantidad de tiempo que pierde es mucho mayor -¡el doble o el triple! - a la cantidad de tiempo que se gana al entregar un archivo más pequeño y comprimido. Por lo tanto, es una pérdida neta.
Recomiendo encarecidamente hacer esto a través de tu propio servidor web. Si estás usando Apache puedes añadir lo siguiente a tu archivo .htaccess:
<IfModule mod_deflate.c>
AddOutputFilterByType DEFLATE text/plain text/xml text/css application/xml application/xhtml+xml application/rss+xml application/javascript application/x-javascript image/svg+xml
</IfModule>
<IfModule mod_gzip.c>
mod_gzip_on Yes
mod_gzip_dechunk Yes
mod_gzip_keep_workfiles No
mod_gzip_can_negotiate Yes
mod_gzip_add_header_count Yes
mod_gzip_send_vary Yes
mod_gzip_min_http 1000
mod_gzip_minimum_file_size 300
mod_gzip_maximum_file_size 512000
mod_gzip_maximum_inmem_size 60000
mod_gzip_handle_methods GET
mod_gzip_item_include file \.(html?|txt|css|js|php|pl|xml|rb|py|svg|scgz)$
mod_gzip_item_include mime ^text/plain$
mod_gzip_item_include mime ^text/xml$
mod_gzip_item_include mime ^text/css$
mod_gzip_item_include mime ^application/xml$
mod_gzip_item_include mime ^application/xhtml+xml$
mod_gzip_item_include mime ^application/rss+xml$
mod_gzip_item_include mime ^application/javascript$
mod_gzip_item_include mime ^application/x-javascript$
mod_gzip_item_include mime ^image/svg+xml$
mod_gzip_item_exclude rspheader ^Content-Encoding:.*gzip.*
mod_gzip_item_include handler ^cgi-script$
mod_gzip_item_include handler ^server-status$
mod_gzip_item_include handler ^server-info$
mod_gzip_item_include handler ^application/x-httpd-php
mod_gzip_item_exclude mime ^image/.*
</IfModule>
Tu servidor web es mucho más rápido en la compresión de archivos multimedia estáticos. Puede mantener los archivos comprimidos en la memoria para una entrega más rápida la próxima vez.
Joomla 4 también sube la apuesta permitiéndote comprimir tus archivos estáticos por adelantado con GZip, entregando los archivos precomprimidos en lugar de tener que comprimirlos tu servidor web bajo demanda. Funciona así. Digamos que tienes el archivo JavaScript media/com_example/js/something.min.js. Lo comprime con GZip en media/com_example/js/something.min.js.gz. Cuando un navegador solicite el archivo media/com_example/js/something.min.js, el servidor web comprobará tu cabecera HTTP Accepts para ver si admite recursos comprimidos con GZip. Si lo hace, entregará el archivo media/com_example/js/something.min.js.gz en lugar del archivo normal y sin comprimir media/com_example/js/something.min.js.
El prerrequisito para ello es que cambies el nombre del archivo htaccess.txt que viene con Joomla a .htaccess. Alternativamente, si estás gestionando tu propio archivo .htaccess, asegúrate de que el siguiente código está incluido en tu archivo:
## These directives are only enabled if the Apache mod_headers module is enabled.
## This section will check if a .gz file exists and if so will stream it
## directly or fallback to gzip any asset on the fly
## If your site starts to look strange after enabling this, and you see
## ERR_CONTENT_DECODING_FAILED in your browser console network tab,
## then your server is already gzipping css and js files and you don't need this
## block enabled in your .htaccess
<IfModule mod_headers.c>
# Serve gzip compressed CSS files if they exist
# and the client accepts gzip.
RewriteCond "%{HTTP:Accept-encoding}" "gzip"
RewriteCond "%{REQUEST_FILENAME}\.gz" -s
RewriteRule "^(.*)\.css" "$1\.css\.gz" [QSA]
# Serve gzip compressed JS files if they exist
# and the client accepts gzip.
RewriteCond "%{HTTP:Accept-encoding}" "gzip"
RewriteCond "%{REQUEST_FILENAME}\.gz" -s
RewriteRule "^(.*)\.js" "$1\.js\.gz" [QSA]
# Serve correct content types, and prevent mod_deflate double gzip.
RewriteRule "\.css\.gz$" "-" [T=text/css,E=no-gzip:1]
RewriteRule "\.js\.gz$" "-" [T=text/javascript,E=no-gzip:1]
<FilesMatch "(\.js\.gz|\.css\.gz)$">
# Serve correct encoding type.
Header append Content-Encoding gzip
# Force proxies to cache gzipped &
# non-gzipped css/js files separately.
Header append Vary Accept-Encoding
</FilesMatch>
</IfModule>
Joomla 4 proporciona los archivos .gz precomprimidos para todos los archivos JavaScript y CSS estáticos en su propia instalación. Habilitar este truco de .htaccess hará que tu sitio sea aún más rápido con un mínimo esfuerzo. ¡¿No es impresionante?!
Caché de medios estáticos
Reducir el tamaño de los medios estáticos con la compresión es la mitad de la batalla y es importante sobre todo para los que visitan el sitio por primera vez. Cuando alguien vuelve a tu sitio tiene sentido que su navegador sirva los medios estáticos desde la caché del navegador, sin utilizar la red en absoluto. Si estás usando Apache puedes incluir el siguiente código en tu archivo .htaccess:
<IfModule mod_expires.c> # Enable expiration control ExpiresActive On # Caducidad de CSS y JS: ExpiresByType text/css "now plus 1 year" ExpiresByType application/javascript "now plus 1 year" ExpiresByType application/x-javascript "now plus 1 year" # Caducidad de los archivos de imagen: 1 mes despues de la solicitud ExpiresByType image/bmp "now plus 1 year" ExpiresByType image/gif "now plus 1 year" ExpiresByType image/jpeg "now plus 1 month" ExpiresByType image/jp2 "now plus 1 month" ExpiresByType image/pipeg "now plus 1 month" ExpiresByType image/png "now plus 1 month" ExpiresByType image/svg+xml "now plus 1 month" ExpiresByType image/tiff "now plus 1 month" ExpiresByType image/vnd.microsoft.icon "now plus 1 month" ExpiresByType image/x-icon "now plus 1 month" ExpiresByType image/ico "now plus 1 month" ExpiresByType image/icon "now plus 1 month" ExpiresByType image/webp "now plus 1 month" ExpiresByType text/ico "now plus 1 month" ExpiresByType application/ico "now plus 1 month" ExpiresByType image/vnd.wap.wbmp "now plus 1 month" ExpiresByType application/vnd.wap.wbxml "now plus 1 month" ExpiresByType application/smil "now plus 1 month" # Caducidad de los archivos de tipografias: 1 mes despues de la solicitud ExpiresByType application/vnd.ms-fontobject "now plus 1 week" ExpiresByType application/x-font-ttf "now plus 1 week" ExpiresByType application/x-font-opentype "now plus 1 week" ExpiresByType application/x-font-woff "now plus 1 week" ExpiresByType font/woff2 "now plus 1 week" ExpiresByType image/svg+xml "now plus 1 week" # Caducidad de los archivos de audio: 1 mes despues de la solicitud ExpiresByType audio/ogg "now plus 1 month" ExpiresByType application/ogg "now plus 1 month" ExpiresByType audio/basic "now plus 1 month" ExpiresByType audio/mid "now plus 1 month" ExpiresByType audio/midi "now plus 1 month" ExpiresByType audio/mpeg "now plus 1 month" ExpiresByType audio/mp3 "now plus 1 month" ExpiresByType audio/x-aiff "now plus 1 month" ExpiresByType audio/x-mpegurl "now plus 1 month" ExpiresByType audio/x-pn-realaudio "now plus 1 month" ExpiresByType audio/x-wav "now plus 1 month" # Caducidad de los archivos de video: 1 mes despues de la solicitud ExpiresByType application/x-shockwave-flash "now plus 1 month" ExpiresByType x-world/x-vrml "now plus 1 month" ExpiresByType video/x-msvideo "now plus 1 month" ExpiresByType video/mpeg "now plus 1 month" ExpiresByType video/mp4 "now plus 1 month" ExpiresByType video/quicktime "now plus 1 month" ExpiresByType video/x-la-asf "now plus 1 month" ExpiresByType video/x-ms-asf "now plus 1 month" </IfModule>
Una pregunta razonable es qué pasa si se actualiza Joomla y/o las extensiones de terceros. Los archivos estáticos - JavaScript, CSS, imágenes, ... - cambian como parte de la actualización. No queremos que el navegador utilice el archivo antiguo. En el mejor de los casos el sitio se verá raro, en el peor estará roto para el visitante. Ahí es donde entra en juego el sistema de versiones multimedia con parámetros de consulta. Si miras el código fuente de tu sitio verás líneas como esta
<link href="/media/plg_system_webauthn/css/button.min.css?f15d039055248502c1a41bc99a31c0f3" rel="stylesheet">
Ese ?f15d039055248502c1a41bc99a31c0f3 se llama consulta de versionado de medios. Lo que hay después del signo de interrogación no importa, siempre y cuando cambie cada vez que el archivo estático cambie. Joomla - y las extensiones de terceros correctamente programadas - lo hacen automáticamente para los archivos CSS y JavaScript. Si incluyes otro contenido estático en tus artículos, como imágenes, vídeos, etc., recuerda añadir una consulta de versiones. Algo tan simple como ?20211205111300 (un signo de interrogación seguido del año, mes, día, hora, minutos y segundos - la hora en que escribiste esa consulta) es más que adecuado.
HTTPS y HSTS
Hay una idea generalizada y equivocada de que el HTTPS tiene que ver con la seguridad de tu sitio, que es caro, que es lento y que realmente no lo necesitas a menos que hagas comercio electrónico o algo así. Otra idea errónea es que hace que tu sitio sea más lento.
Estos mitos se originaron a finales de los años 90. Hace más de dos décadas que son claramente falsos.
HTTPS es prácticamente obligatorio hoy en día. Si no utilizas HTTPS tu sitio aparecerá con una gran advertencia roja diciendo a tus visitantes que es inseguro, ahuyentandoles. Será penalizado por los motores de búsqueda. Deberías usar HTTPS aunque sólo sea para solucionar estos dos problemas. Ni siquiera necesitas romper la hucha. Los certificados TLS son ahora gratuitos gracias a Let's Encrypt. La mayoría de los paneles de control de los alojamientos se integran con Let's Encrypt, lo que significa que literalmente puedes hacer que tu panel de control emita e instale un certificado TLS gratuito y lo renueve automáticamente. No hay ningún mantenimiento por tu parte. HTTPS también es súper rápido ya que cualquier CPU moderna, lanzada en los últimos diez años y pico, tiene aceleración de hardware para las operaciones criptográficas que utiliza.
Mientras estás con esto, recuerda establecer "Forzar HTTPS: Todo el sitio" en tu Configuración Global. Esto asegura que tu sitio Joomla siempre será entregado a través de HTTPS, haciendo que los inicios de sesión sean más seguros en el proceso. Una vez que lo hagas, y hayas confirmado que HTTPS funciona bien con tu sitio, añade lo siguiente a tu .htaccess:
<IfModule mod_headers.c> Header always set Strict-Transport-Security "max-age=31536000" env=HTTPS </IfModule>
Esto habilita una característica llamada HSTS (Seguridad de Transporte Estricto HTTP). En pocas palabras, le dice a su navegador que nunca intente conectarse a la versión HTTP de tu sitio, independientemente de lo que el visitante le diga. Dado que esto sucede en el lado del navegador, un visitante que escribe tu nombre de dominio en la barra de direcciones sin el prefijo https://, o hace clic en un enlace con el prefijo http://, siempre llegará a la versión HTTPS de tu sitio sin tener que visitar primero la versión HTTP normal y ser redirigido por Joomla. Esto es mucho más rápido, especialmente en las conexiones de alta latencia como Internet móvil o por satélite.
Otra optimización que puedes hacer es enviar tu sitio a la lista de precarga HSTS. Mientras que HSTS sólo funciona después de la primera vez que alguien visita tu sitio, tener tu sitio en la Lista de Precarga HSTS significa que el navegador sabe que tu sitio utiliza HSTS antes de la primera vez que tu visitante lo visita. Por lo tanto, el navegador nunca intentará cargarlo a través de HTTP normal. De nuevo, esto es un ahorro de tiempo para las conexiones de alta latencia, fácil y gratuito. ¿Cómo no enamorarse de esto?
HTTP/2 Server Push
Cuando hablaba de hacer Joomla más rápido en el pasado solía decirle a la gente cómo habilitar HTTP/2 Server Push para hacer los sitios más rápidos. Sin embargo, los desarrolladores de Google Chrome ya han propuesto eliminar el soporte para ello y declararon que de todos modos no se implementará para el protocolo HTTP/3 en absoluto. Por lo tanto, mi consejo actual es no molestarse con él.
Continuará
Esta es la segunda parte de una serie de cinco. La tercera parte: "Optimización de medios estáticos" estará disponible en la edición de enero de 2022 de la magazine de la comunidad Joomla.
Este artículo es una traducción de Joomla Performance Tuning II: Basic Settings.
