# Cómo reducir el tiempo de ejecución de JavaScript > Cómo reducir el tiempo de ejecución de JavaScript: graba la acción lenta en Chrome DevTools, encuentra el código responsable y prueba un cambio. Canonical: https://www.getdexseo.com/es/blog/rendimiento-web/tiempo-ejecucion-javascript/ Author: Dex SEO, Editorial team Published: Oct 24, 2026 · Updated: Oct 24, 2026 ## Key takeaways - Separa la descarga del script de su ejecución. - Graba una acción lenta concreta. - Conecta el trabajo costoso con una función y un responsable. - Comprueba que la página sigue funcionando tras el cambio. Para reducir el tiempo de ejecución de JavaScript, encuentra qué código mantiene ocupado al navegador durante la tarea que va lenta. Graba esa tarea, revisa el trabajo y prueba una carga menor o mejor programada. Un archivo que se descarga rápido ayuda, pero no prueba que el código se ejecute rápido. Esta guía forma parte de la guía de [rendimiento web](https://www.getdexseo.com/es/blog/rendimiento-web/). ## Qué significa el aviso “Reduce el tiempo de ejecución de JavaScript” Es una auditoría de Lighthouse. Según la documentación de Chrome sobre [reducir el tiempo de ejecución de JavaScript](https://developer.chrome.com/docs/lighthouse/performance/bootup-time?hl=es-419), aparece cuando la página dedica demasiado tiempo a analizar, compilar y ejecutar scripts. Ese trabajo ocupa el hilo principal del navegador, el mismo que tiene que responder a los toques y clics del visitante. El aviso es un punto de partida. No dice qué función del sitio causa el trabajo ni si afecta a una acción concreta. Para eso hace falta grabar la tarea. ## Separa la descarga del script de su ejecución Un script primero tiene que llegar al navegador. Después, el navegador lo procesa y lo ejecuta. Son etapas relacionadas pero distintas. Un archivo que llega rápido puede hacer que un menú tarde en abrirse. Un archivo grande puede gastar tiempo de descarga aunque solo una parte se ejecute. No uses el tamaño total de los archivos como veredicto sobre la velocidad de las interacciones. Si el problema es la reutilización de archivos, revisa cómo [comprobar si la caché funciona](https://www.getdexseo.com/es/blog/rendimiento-web/comprobar-cache-web/): una entrega más rápida no quita el trabajo de ejecutar el archivo. ## Elige una acción lenta y reprodúcela Escribe un recorrido de prueba preciso. Por ejemplo: abrir el artículo en una pantalla pequeña, esperar la primera vista y abrir el menú. Anota el navegador, el modo de dispositivo, el estado de la página y cualquier ralentización de red o de CPU usada en la prueba. Repite la acción antes de cambiar nada. Si el retraso no vuelve a aparecer, anota ese límite y busca más evidencia. Revisa también si el síntoma es otro: el texto que se mueve al aparecer una imagen necesita una revisión del [CLS](https://www.getdexseo.com/es/blog/rendimiento-web/reducir-cls-imagenes/), y un retraso antes de que llegue el documento es un problema de [TTFB](https://www.getdexseo.com/es/blog/rendimiento-web/mejorar-ttfb/), no del código del clic. ## Graba la acción en Chrome DevTools Abre el panel Rendimiento, empieza a grabar, haz la acción y para la grabación. Selecciona la parte de la línea de tiempo alrededor del retraso. No saques conclusiones de una grabación larga llena de trabajo sin relación. La [referencia del panel Rendimiento](https://developer.chrome.com/docs/devtools/performance/reference?hl=es-419) explica las vistas clave. La pista Main muestra la actividad del hilo principal. La pista Interactions ayuda a localizar la acción. La pestaña Bottom-up muestra qué actividades consumieron más tiempo, y el Árbol de llamadas ayuda a seguir el camino del trabajo. Revisa el origen y el camino de cada tarea costosa. Un nombre de función visible puede pertenecer a una biblioteca que usan varias funciones del sitio. Averigua quién la usa antes de quitar nada. Guarda la grabación y una nota clara de lo que pasó. ## Conecta el trabajo costoso con una función y un responsable Anota la función detrás de cada sospechoso: menú, buscador, chat, analítica, un widget o un paquete común. Nombra al equipo o proveedor que puede cambiarlo. No supongas que todo el código del mismo dominio tiene el mismo propósito. Comprueba cuándo hace falta esa función. Una herramienta que solo se usa tras un clic quizá no necesita todo su trabajo al inicio. Si el código viene de un plugin de WordPress, usa una [prueba controlada de plugins](https://www.getdexseo.com/es/blog/rendimiento-web/plugins-lentos-wordpress/): el problema puede estar en el navegador, en el servidor o en ambos. ## Cómo acelerar la ejecución de JavaScript Usa la evidencia para elegir un cambio. Las opciones habituales son quitar código que no se usa, dividir el código por tarea o cargar una función solo donde hace falta. Un desarrollador debe revisar las dependencias antes de tocar un paquete común. Retrasar el código sin más puede mover el retraso al siguiente clic. Si ese clic es la tarea que importa, el visitante gana poco. Repite todo el recorrido. Dividir tareas largas en partes pequeñas también ayuda a que el navegador responda entre una y otra. No retrases todos los scripts como respuesta general a un aviso. Mantén en la prueba las funciones necesarias: navegación, formularios, controles de acceso, consentimiento y analítica relevante. Una página que deja de funcionar no es un arreglo de rendimiento. Si un script carga imágenes, compara con el [lazy loading nativo](https://www.getdexseo.com/es/blog/rendimiento-web/lazy-loading-imagenes/) antes de añadir más trabajo propio. Y si te preocupa cómo procesa Google el contenido que crea JavaScript, es otra pregunta: la responde la guía de [renderizado de JavaScript para SEO](https://www.getdexseo.com/es/blog/rastreo-e-indexacion/renderizado-javascript-seo/). ## Prueba los scripts de terceros sin romper la página Una función de terceros puede añadir trabajo aunque su archivo sea pequeño. Acuerda con su responsable qué se puede cambiar y usa una versión de prueba del sitio. Comprueba si hace falta en esa página y en ese momento de la visita. Distingue entre desactivar una función para diagnosticar y quitarla del sitio publicado. Lo primero aísla una causa; lo segundo necesita un plan para la función que daba. Cambia una variable cada vez y mantén el mismo contenido y las mismas condiciones. ## Ejemplo: un menú espera detrás de un trabajo sin relación _Ejemplo ficticio._ En un sitio de servicios, abrir el menú tarda mientras arranca un widget. No es un resultado medido de DEX. 1. Graba la acción del menú y el trabajo que la rodea. 2. Identifica el código del widget y su responsable. 3. Prueba una versión que arranca el widget solo cuando se necesita. 4. Repite la acción del menú en las mismas condiciones. 5. Prueba también el primer uso del widget. 6. Mantén el cambio solo si el resultado útil supera esas pruebas. Quizá el menú mejora pero el primer uso del widget queda demasiado lento. Anota ese equilibrio en lugar de presentar el cambio como una victoria total. ## Comprueba la versión publicada y guarda la evidencia Repite la tarea original después de publicar. Revisa una carga nueva y una visita repetida. Compara varias ejecuciones en las mismas condiciones y revisa la tarea, no solo una puntuación general. Si el cambio afecta a los estilos o a la primera vista, revisa también el texto durante la [carga de fuentes](https://www.getdexseo.com/es/blog/rendimiento-web/optimizar-fuentes-web/). Revisa las funciones clave en las páginas que comparten el código y guarda la versión anterior para poder volver atrás. DEX conecta la investigación de búsquedas, la planificación de contenido, la redacción de artículos y la publicación en el sitio conectado. DEX Health ayuda a revisar la calidad y el SEO de la página, también en el plan gratuito, pero no es un perfilador de JavaScript. Úsalo junto a las grabaciones del navegador. Guarda juntos la grabación, el recorrido de prueba, el código cambiado, el responsable y el resultado. Así un aviso vago se convierte en una tarea concreta que alguien puede comprobar y mantener. ## FAQ ### ¿Un script pequeño siempre se ejecuta rápido? No. Un archivo pequeño puede hacer mucho trabajo al ejecutarse. ### ¿Diferir todos los scripts arregla un menú lento? No siempre. Puede mover el retraso al siguiente clic. ### ¿DEX Health es un perfilador de JavaScript? No. Úsalo junto a las grabaciones del navegador. ## Sources - [Reduce el tiempo de ejecución de JavaScript](https://developer.chrome.com/docs/lighthouse/performance/bootup-time?hl=es-419) — Chrome for Developers - [Referencia de las funciones de rendimiento](https://developer.chrome.com/docs/devtools/performance/reference?hl=es-419) — Chrome for Developers