Resumen: cómo acelerar JavaScript en tu sitio web
- Diferir no basta: Cada guía de rendimiento de JavaScript te dice que difieras los scripts no esenciales, pero las mismas etiquetas que diferiste siguen enviando acceso al DOM no utilizado, dependencias de proveedores caducadas y riesgo estilo Polyfill de dominio expirado en 490.000 sitios que nunca las eliminaron.
- Ve qué se ejecuta y dónde: El agente JavaScript de origen de cside observa el comportamiento en tiempo de ejecución de cada script de terceros en el navegador, así ves qué código se ejecuta y dónde, a menudo sirve scripts estáticos más rápido gracias a la caché, sin muestreo y con bloqueo autónomo por encima.
- Un dueño, un panel: Antes de la próxima revisión de Core Web Vitals, decide si el rendimiento y la seguridad de los scripts de terceros tienen un único dueño y un único panel, o si siguen divididos entre ingeniería y marketing hasta que un CDN caducado los tumbe a ambos.
¿Poco tiempo? Consulta el bloqueo de Magecart y skimmers en el navegador de cside. Cubre todo lo de abajo en un solo despliegue.
Eliminar recursos que bloquean el renderizado, reducir el JavaScript no utilizado y minimizar el trabajo del hilo principal suelen aparecer justo arriba en el informe de PageSpeed Insights. Hablan de ahorros potenciales, pero aparte de usar la etiqueta defer, no hay mucha información sobre cómo hacerlo.
Aunque hay algunas formas adicionales de hacer que tus páginas carguen más rápido abordando JavaScript.
Primero hablemos del diferimiento, y luego te daremos algunas opciones adicionales.
¿Defer o async?
En resumen: diferir la carga de scripts hace que tu sitio parezca cargar más rápido que usar 'async'. Sin embargo, dependiendo de tu uso, puede o no ser la mejor opción.
El atributo 'defer' permite que el navegador continúe analizando el HTML mientras el script se descarga en segundo plano. Pero espera a ejecutar el script hasta que termine el análisis del HTML. Por eso el 'paint' del contenido en tu sitio carga más rápido. La página web se carga por completo para que tu visitante la vea antes que sin ese atributo o con el atributo 'async'.
El atributo 'async' permite que el navegador continúe analizando el contenido HTML mientras el script se descarga en segundo plano. Pero en cuanto el script se descarga, se ejecuta de inmediato. Si el análisis del HTML aún no ha terminado, esto lo interrumpiría. Así que, aunque el HTML carga más rápido que sin usar async, la posible interrupción de la carga del HTML podría hacer que tu sitio parezca cargar más lento.
¿Cuándo usar defer o async?
Los scripts 'async' se ejecutan en cuanto se descargan, lo que no es necesariamente en el orden en que aparecen en el documento. El atributo 'defer' preserva el orden y asegura que los scripts se ejecuten después de que el documento haya sido analizado.
'Async' es especialmente útil para scripts que NO dependen de ningún elemento del Document Object Model (DOM) ni de otros scripts. Un script diferido espera hasta que el DOM esté listo, lo que lo convierte en una apuesta más segura para scripts que necesitan manipular el DOM.
¿Qué tipo de scripts manipulan el DOM?
Bibliotecas como jQuery o scripts personalizados en general. Estos manipulan el DOM y deberían cargarse con el atributo 'defer' para asegurar que el DOM esté completamente cargado antes de que se ejecuten. Y si tienes scripts que dependen de que otros se carguen primero, usar 'defer' asegura que se ejecuten en el orden en que aparecen en el documento.
Los scripts de analítica, anuncios y otras cosas menos vitales, en general, no necesitan cargarse lo más rápido posible. Es una elección que tienes que hacer tú mismo, pero la mayoría prefiere un sitio que cargue más rápido antes que scripts que funcionen unos milisegundos más rápido.
Una buena regla general es usar defer para el JavaScript no esencial. Si el script no depende del DOM ni de otros scripts, usar async o ningún atributo está bien.
Reducir el JavaScript no utilizado
Es hora de hacer limpieza general. Sacude el árbol y deshazte del código muerto, es decir, del JavaScript no utilizado. Esto beneficia tanto la velocidad como la seguridad. Hemos escrito varios artículos hasta ahora sobre los problemas que puede traer el JavaScript de terceros. Toda nuestra empresa se fundó para ayudar a proteger frente a las vulnerabilidades asociadas a esto. Y a menudo, los sitios web siguen ejecutando scripts que ya no se usan, con los grandes riesgos que eso conlleva.
Este fue el caso reciente del ataque a la cadena de suministro web de Polyfill, donde un dominio antiguo fue comprado por un nuevo actor y luego usado con fines maliciosos. Más de 490.000 sitios web habían referenciado ese dominio y potencialmente sufrieron ataques.
Otras formas se dan con herramientas que en su día se usaron pero ya no, o frameworks que vienen con un montón de bibliotecas JavaScript que no se usan en un sitio en concreto. Lee más sobre los riesgos de cómo los dominios expirados pueden derivar en problemas de ciberseguridad aquí.
Cuanto más JavaScript tengas en tu sitio, mayor es el riesgo que corres.
Antes era prácticamente imposible detectar cambios en los scripts de terceros. Por suerte, esto ya no es así. Estamos muy orgullosos de haber construido una solución que monitoriza y alerta, e incluso puede bloquear scripts maliciosos de forma autónoma antes de que se produzcan los ataques.
Si usas una herramienta de monitorización como cside, podrás ver fácilmente qué código se carga y dónde, así como qué hace realmente ese código. Con esta información, es mucho más fácil hacer esta limpieza general y eliminar los scripts no deseados.
Pero cside va incluso un paso más allá, lo que nos lleva al siguiente punto.
Optimizar JavaScript para que cargue más rápido
cside carga todos los demás scripts de tu sitio en un proxy para analizarlos antes de que se carguen en el navegador. Esta es, con diferencia, la solución más segura. Nada malicioso puede tocar el navegador de tus usuarios, lo que os protege por completo a ellos y a ti.
Pero esto trae consigo algunos retos. Como el JavaScript se comprueba antes de cargarse, esto añade naturalmente latencia. Simplemente diferir no siempre es posible, ya que cargamos todos los scripts en el proxy, incluidos los necesarios que afectan a los elementos del Document Object Model (DOM), como se explicó antes.
Para algunas aplicaciones, esto seguiría estando bien. Para otras, sería un factor decisivo en contra.
Para nosotros, también fue un factor decisivo. Sí, la seguridad ante todo. Pero si las desventajas se vuelven demasiado grandes, las empresas dudarán en adoptar los mejores estándares. Y tenemos que asegurarnos de que haya el menor número de desventajas posible.
Por eso hemos diseñado cside para optimizar de verdad los scripts y que carguen más rápido de lo normal, mitigando la latencia por completo. A menudo, incluso hacemos que estos scripts, y por tanto los sitios web, sean más rápidos en lugar de más lentos.
Como comprobamos cada sesión en todo momento, nos encontramos con los mismos scripts miles de veces al día. Guardamos cada versión de un script y, si es posible, la almacenamos en caché. Esto hace que podamos cargar las versiones en caché, lo cual es más rápido incluso que cargar las versiones originales desde cero.
Reescribimos especialmente las cabeceras de caché para poder bloquear un script y que siga bloqueado para los clientes que ya podrían tenerlo en su caché, manteniendo al mismo tiempo el rendimiento de la caché.
También hemos diseñado nuestra infraestructura para funcionar increíblemente rápido. En comparación con otros proveedores que no mencionaremos, cside sirve un script de 20.3 kb más rápido de lo que ellos tardan en servir un script de 1.2 kb. El nuestro tardó 10ms mientras que el de ellos tardó 13ms en nuestras pruebas, una ganancia de velocidad de 22x, asumiendo que el resto de factores permanecen constantes.
Por último, el JavaScript suele estar minificado y ofuscado. La minificación es una forma habitual de conseguir pequeñas ganancias de velocidad. Lo segundo puede tener efectos negativos en el rendimiento. Solo ten en cuenta que en cside puedes ver las versiones desofuscadas de los scripts para entender mejor qué hace el código.
Compresión
Otra forma de optimizar JavaScript es usar GZip, Brotli u otro tipo de compresión. Son algoritmos que reducen el tamaño de los archivos enviados desde el servidor al navegador. Funcionan identificando y eliminando datos redundantes dentro de un archivo.
Hay algunos matices al respecto, pero por lo general es mejor usarla que no hacerlo. Comprimir y descomprimir los archivos lleva tiempo, pero normalmente menos que el tiempo que se ahorra al descargar un archivo más grande. Por lo tanto, sigues saliendo ganando.
Esto funciona especialmente bien en archivos de texto, como HTML, CSS y también JavaScript.
Precarga y prefetch
La precarga te permite obtener recursos críticos (como JavaScript) antes de que el navegador los necesite. Estos recursos están entonces disponibles en cuanto se requieren, lo que reduce los tiempos de carga. El navegador priorizará estos recursos, descargándolos durante la carga inicial de la página.
Por ejemplo, precargar un archivo JavaScript asegura que esté disponible cuando el navegador llegue al punto del HTML donde normalmente cargaría ese script. Esto evita los retrasos causados por el navegador al tener que ir a buscar el archivo en ese momento.
Esto puede sonar igual que los atributos 'defer' o 'async', pero hay algunas diferencias clave.
La precarga asegura que recursos críticos como CSS, fuentes y archivos JavaScript importantes se obtengan pronto y el navegador los priorice para que estén disponibles de inmediato.
Recuerda que el atributo 'defer' se usa para retrasar la ejecución de JavaScript hasta que el documento HTML se haya analizado por completo. Y, de nuevo, el atributo 'async' permite que los scripts se obtengan y se ejecuten en cuanto estén disponibles, sin esperar a que termine el análisis del HTML.
Otro ejemplo de precarga es usar una fuente personalizada en tu sitio. Si esta fuente no se carga con rapidez, los usuarios podrían ver primero una fuente predeterminada, lo que produce un destello de texto sin estilo. Al precargar la fuente, te aseguras de que esto no ocurra.
El prefetch, por su parte, se centra en obtener recursos durante el tiempo de inactividad del navegador para necesidades futuras, como los recursos de la siguiente página a la que probablemente navegue el usuario. Cargar durante esos tiempos de inactividad reduce de forma significativa los tiempos de espera.
Minimizar el trabajo del hilo principal
El hilo principal es donde el navegador realiza la mayor parte del trabajo necesario para mostrar una página, como analizar y ejecutar HTML, CSS y JavaScript. Mantenerlo rápido y eficiente es necesario para que la experiencia de usuario sea buena en general.
PageSpeed Insights da algunos consejos al respecto.
El renderizado se puede optimizar ciñéndose a propiedades exclusivas del compositor. Se trata de propiedades CSS que el compositor del navegador puede gestionar por completo, evitando el hilo principal y la necesidad de operaciones de diseño o pintura. Simplificar la complejidad de pintura reduciendo las áreas que hay que pintar puede ayudar aún más al navegador a renderizar la página de forma más eficiente, acelerando los tiempos de carga.
En cuanto al estilo y el diseño, simplificar tu CSS y evitar selectores complejos puede reducir de forma significativa el tiempo dedicado a los cálculos de estilo. Probablemente será un equilibrio entre diseño y rendimiento.
Evitar el layout thrashing es esencial. El layout thrashing ocurre cuando se realizan lecturas y escrituras consecutivas en el DOM, lo que impide que el navegador optimice el diseño. Esto obliga al navegador a calcular un diseño que nunca llega a renderizarse en pantalla.
Considera diferir el CSS no crítico, cargando los estilos no esenciales de forma asíncrona para evitar que bloqueen las operaciones del hilo principal durante la ruta de renderizado crítica.
Volvamos a JavaScript.
Para la evaluación de scripts, el debouncing de los manejadores de entrada es útil. Ayuda a reducir la frecuencia con la que se llaman los manejadores de eventos, lo que reduce la carga en el hilo principal. Ten en cuenta que los web workers tienen un entorno restringido: no pueden manipular directamente el DOM ni usar ciertas APIs disponibles para el hilo principal.
Por último, la recolección de basura se puede optimizar monitorizando el uso de memoria. Usar herramientas como 'measureMemory()' ayuda a rastrear y gestionar el uso de memoria, reduciendo el tiempo dedicado a la recolección de basura. Una gestión eficiente de la memoria ayuda a mantener el hilo principal libre para tareas más críticas.
Vincular rendimiento y seguridad
Todas estas soluciones te ayudarán a acelerar JavaScript para lograr un mejor rendimiento. cside también puede ayudar almacenando en caché y optimizando scripts.
Pero nos gustaría recalcar que, ante todo, nos centramos en la seguridad. El hecho de que aceleremos los scripts era necesario sobre todo para que nuestros usuarios lo adoptaran. Los ataques a la cadena de suministro del navegador están en aumento. Y los actores maliciosos suelen apuntar al JavaScript de terceros. cside analiza cada script antes de que se cargue en el navegador y bloquea cualquier cosa maliciosa.
Un enfoque proactivo que os protege, tanto a ti como a tus usuarios, antes de que ocurra algo malo.
Puedes empezar con cside gratis.
