Skip to main content
Blog
Blog

Cómo acelerar JavaScript

Las tasas de conversión están correlacionadas con las velocidades de carga del sitio. Pero los sitios de e-commerce tienen una gran cantidad de JavaScript que ralentiza las cosas... la solución está aquí.

Sep 02, 2024 11 min read
how-to-speedup-javascript-image-cover

Eliminar recursos que bloquean el renderizado, reducir JavaScript no utilizado y minimizar el trabajo del hilo principal generalmente se encuentran en la parte superior del informe de PageSpeed Insights. Hablan sobre ahorros potenciales, pero además de usar la etiqueta defer, no hay mucha información sobre cómo hacer esto.

Informe de rendimiento de Google Lighthouse señalando el trabajo de JavaScript en el hilo principal

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.

Panel de cside mostrando el contenido del script de jsDelivr desofuscado

El atributo 'defer' permite que el navegador continúe analizando el HTML mientras el script se descarga en segundo plano. Pero espera la ejecución del script hasta después de que se complete 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 completamente para que tu visitante la vea más rápido que sin el 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 una vez que el script se descarga, se ejecuta inmediatamente. Si el análisis del HTML no está listo, esto lo interrumpiría. Entonces, 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 tan pronto como 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 particularmente útil para scripts que NO dependen de ningún elemento del Document Object Model (DOM) u otros scripts. Un script diferido espera hasta que el DOM esté listo, lo que los hace 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 deben 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 scripts 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 cosas menos vitales, en términos generales, no necesitan cargarse lo más rápido posible. Es una elección que debes hacer tú mismo, pero la mayoría de las personas prefieren un sitio que cargue más rápido en comparación con scripts que funcionen unos milisegundos más rápido.

Una buena regla general es usar defer para JavaScript no esencial. Si el script no depende del DOM o de otros scripts, entonces usar async o ningún atributo está bien.

Reducir JavaScript no utilizado

Es hora de hacer una limpieza de primavera. Sacude el árbol y deshazte del código muerto, aquí refiriéndonos a JavaScript no utilizado. Esto no solo beneficia la velocidad, sino también la seguridad. Hemos escrito múltiples artículos hasta ahora sobre los problemas que pueden venir con JavaScript de terceros. Toda nuestra empresa fue fundada para ayudar a proteger contra las vulnerabilidades asociadas con esto. Y a menudo, los sitios web continúan ejecutando scripts que ya no se usan con grandes riesgos que vienen con ello.

Este fue recientemente el caso en el ataque a la cadena de suministro web de Polyfill, donde un dominio antiguo fue comprado por una nueva parte y luego usado con fines maliciosos. Más de 490,000 sitios web habían referenciado este dominio y potencialmente sufrieron ataques.

Otras formas son en forma de herramientas que alguna vez se usaron pero ya no, o frameworks que vienen con una plétora de bibliotecas JavaScript que no están en uso en un sitio en particular. Lee más sobre los riesgos de cómo los dominios expirados pueden llevar a problemas de ciberseguridad aquí.

Cuanto más JavaScript tengas en tu sitio, mayor es el riesgo que corres.

Solía ser prácticamente imposible detectar cambios en scripts de terceros. Afortunadamente, esto ya no es el caso. Estamos muy orgullosos de haber construido una solución que no solo monitorea y alerta, sino que incluso es capaz de bloquear scripts maliciosos de forma autónoma antes de que lleguen los ataques.

Si usas una herramienta de monitoreo como cside, podrás ver fácilmente qué código se está cargando dónde, así como qué hace realmente ese código. Con esta información, es mucho más fácil realizar esta limpieza de primavera y eliminar scripts no deseados.

Pero cside va incluso un paso más allá, lo que nos lleva al siguiente punto.

Optimizar JavaScript para cargar más rápido

cside carga todos los demás scripts en tu sitio en un proxy para analizarlos antes de que se carguen en el navegador. Esta es, por mucho, la solución más segura. Nada malicioso puede tocar el navegador de tus usuarios, lo que los protege a ellos y a ti completamente.

Pero esto viene con algunos desafíos. Dado que el JavaScript se verifica antes de cargarse, esto naturalmente agrega latencia. Simplemente diferir no siempre es posible ya que cargamos todos los scripts en el proxy, también los necesarios que impactan los elementos del Document Object Model (DOM) como se explicó antes.

Para algunas aplicaciones, esto todavía estaría bien. Para otras, esto sería un factor decisivo.

Para nosotros, esto también fue un factor decisivo. Sí, seguridad primero. Pero si las desventajas se vuelven demasiado grandes, las empresas dudarán en adoptar los mejores estándares. Y debemos asegurarnos de que haya la menor cantidad de desventajas posible.

Por eso hemos diseñado cside para optimizar realmente los scripts para que carguen más rápido de lo normal, mitigando completamente la latencia. A menudo incluso haciendo que estos scripts, y por lo tanto los sitios web, sean más rápidos en lugar de más lentos.

Dado que verificamos cada sesión todo el tiempo, nos encontramos con los mismos scripts miles de veces al día. Almacenamos cada versión de un script y, si es posible, lo almacenamos en caché. Esto hace que podamos cargar las versiones en caché, lo cual es más rápido que incluso cargar las versiones originales de nuevo.

Reescribimos especialmente los encabezados de caché para que bloqueemos un script y aún así lo tengamos bloqueado para clientes que podrían ya tenerlo en su caché, mientras mantenemos el rendimiento del caché.

Además, hemos diseñado nuestra infraestructura para trabajar increíblemente rápido. Comparado con otros proveedores que no mencionaremos, nuestro proxy sirve un script de 20.3 kb más rápido de lo que ellos pueden servir un script de 1.2 kb. El nuestro tomó 10ms mientras que el de ellos tomó 13ms en nuestras pruebas, una ganancia de velocidad de 22x, asumiendo que todos los demás factores permanecen constantes.

Finalmente, JavaScript a menudo está minificado y ofuscado. La minificación es una forma común de obtener algunas pequeñas ganancias de velocidad. Lo último 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é está haciendo el código.

Panel de cside mostrando un script desofuscado para su inspección

Compresión

Otra forma de optimizar JavaScript es usar GZip, Brotli u otra compresión. Son algoritmos que reducen el tamaño de los archivos enviados desde el servidor al navegador. Funciona identificando y eliminando datos redundantes dentro de un archivo.

Hay algunas advertencias sobre esto, pero generalmente es mejor usarlo que no hacerlo. Toma tiempo comprimir y descomprimir los archivos, pero típicamente menos que el tiempo ahorrado al descargar un archivo más grande. Por lo tanto, aún sales 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 sean necesarios para el navegador. Estos recursos están entonces disponibles tan pronto como se requieren, reduciendo 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 en el HTML donde normalmente cargaría ese script. Esto previene retrasos causados por el navegador necesitando obtener el archivo en ese punto.

Esto podría 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 temprano y sean priorizados por el navegador para disponibilidad inmediata.

Recuerda que el atributo 'defer' se usa para retrasar la ejecución de JavaScript hasta que el documento HTML haya sido completamente analizado. Y luego nuevamente, el atributo 'async' permite que los scripts se obtengan y ejecuten tan pronto como estén disponibles, sin esperar a que se complete el análisis del HTML.

Otro ejemplo de precarga es usar una fuente personalizada en tu sitio. Si esta fuente no se carga rápidamente, los usuarios podrían ver una fuente predeterminada primero, llevando a un destello de texto sin estilo. Al precargar la fuente, aseguras que esto no ocurra.

El prefetch entonces, se enfoca en obtener recursos durante el tiempo de inactividad del navegador para necesidades futuras, como recursos para la próxima página a la que el usuario probablemente navegará. Cargar durante esos tiempos de inactividad reduce significativamente los tiempos de espera.

Minimizar el trabajo del hilo principal

El hilo principal es donde el navegador hace 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 una experiencia de usuario generalmente buena.

PageSpeed Insights da algunos consejos sobre esto.

Recomendación de PageSpeed Insights para minimizar el trabajo del hilo principal

El renderizado puede optimizarse adhiriéndose a propiedades solo del compositor. Estas son propiedades CSS que pueden ser manejadas completamente por el compositor del navegador, evitando el hilo principal y la necesidad de operaciones de diseño o pintura. Simplificar la complejidad de pintura reduciendo las áreas que necesitan ser pintadas puede ayudar aún más al navegador a renderizar la página de manera más eficiente, acelerando los tiempos de carga.

Cuando se trata de estilo y diseño, simplificar tu CSS y evitar selectores complejos puede reducir significativamente el tiempo dedicado a los cálculos de estilo. Esto se puede lograr reduciendo el alcance y la complejidad de 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 realizamos lecturas y escrituras consecutivas al DOM, impidiendo que el navegador optimice el diseño. Esto obliga al navegador a calcular un diseño que nunca se renderiza en la pantalla.

Considera diferir CSS no crítico, cargando estilos no esenciales de forma asíncrona para evitar que bloqueen las operaciones del hilo principal durante la ruta de renderizado crítica.

De vuelta a JavaScript.

Para la evaluación de scripts, el debouncing de manejadores de entrada es útil. Ayuda a reducir la frecuencia con la que se llaman los manejadores de eventos, disminuyendo así 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.

Finalmente, la recolección de basura puede optimizarse monitoreando 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. La gestión eficiente de la memoria ayuda a mantener el hilo principal libre para tareas más críticas.

Vinculando rendimiento con seguridad

Todas estas soluciones te ayudarán a acelerar JavaScript para lograr un mejor rendimiento. cside puede ayudar almacenando en caché y optimizando scripts también.

Pero nos gustaría enfatizar que, ante todo, nos preocupamos por la seguridad. El hecho de que aceleremos los scripts fue principalmente necesario para la adopción por parte de nuestros usuarios. Los ataques a la cadena de suministro del navegador están en aumento. Y los actores maliciosos a menudo apuntan a JavaScript de terceros. cside analiza cada script antes de que se cargue en el navegador y bloquea cualquier cosa maliciosa.

Un enfoque proactivo que te salva a ti y a tus usuarios antes de que suceda algo malo.

Puedes comenzar con cside gratis.

Simon Wijckmans
Founder & CEO

Founder and CEO of cside. Previously a product manager on Cloudflare Page Shield (now Cloudflare Client-Side Security). Co-chair of the W3C Anti-Fraud Community Group and a Forbes 30 Under 30 honoree. Building accessible security against client-side attacks — web security is not an enterprise-only problem.

FAQ

Frequently Asked Questions

Aplaza los scripts que no son necesarios para el primer pintado. Añadir `defer` (o `async` cuando sea seguro) y minimizar el trabajo del hilo principal en el camino crítico casi siempre supera a microoptimizar un bundle existente.

Usa `defer` cuando el orden de ejecución importa y los scripts dependen unos de otros; usa `async` cuando cada script es independiente y puede ejecutarse en cuanto se descargue. Ambos mantienen el parser desbloqueado.

Monitoriza y Asegura tus Scripts de Terceros

Gain full visibility and control over every script delivered to your users to enhance site security and performance.

Comienza gratis, o prueba Business con una prueba de 14 días.

Interfaz del panel de cside mostrando monitorización de scripts y análisis de seguridad
Related Articles
Reservar una demo