Retrasar la ejecución de JavaScript rompió mi sitio: cómo encontrar el script culpable

Activa «Retrasar la ejecución de JavaScript», el informe de PageSpeed se dispara y empiezan a llegar los mensajes. El menú móvil no hace nada. El banner de cookies no se cierra. El formulario de contacto se queda cargando sin fin. El slider de la página de inicio está vacío. La burbuja del chat ha desaparecido. O, una semana después, la analítica muestra una caída de sesiones que nadie sabe explicar.

El consejo habitual es una lista de exclusiones para pegar, o desactivar la opción. Las dos cosas funcionan, y las dos tiran la ganancia sin decirle qué se rompió en realidad. Esta guía le da el método: por qué el retraso rompe cosas, cómo leer el síntoma y cómo encontrar el único script que hay que sacar.

Qué le hace el retraso a una página

Normalmente, cada script de la página se descarga y se ejecuta mientras la página carga. Con un retraso de JavaScript, los scripts quedan aparcados: sus etiquetas se reescriben para que el navegador las ignore. Un pequeño cargador espera a que el visitante haga algo (mover el ratón, hacer scroll, tocar la pantalla, pulsar una tecla), o a que se agote un temporizador, y solo entonces vuelve a poner los scripts, uno tras otro.

Por eso sube la puntuación de laboratorio: durante la prueba, casi no se ejecuta JavaScript. Y por eso se rompen cosas: cada script se ejecuta ahora más tarde, en una página que ya terminó de cargar, y solo si el cargador llega hasta ahí.

Las cinco maneras en que se rompe, y su firma

1. Falta una dependencia. Un script está excluido del retraso (así que se ejecuta en la carga) pero algo que necesita sigue aparcado. El caso clásico: un script de menú se ejecuta cuando jQuery todavía no existe. Firma: un error rojo en la consola, por ejemplo jQuery is not defined, $ is not a function o Cannot read properties of undefined.

2. El evento de la página ya se disparó. Muchos scripts esperan a DOMContentLoaded o a window.onload antes de arrancar. Cuando llega un script retrasado, esos eventos pasaron hace tiempo, así que su código de inicio espera algo que nunca ocurrirá. Firma: ningún error, la función simplemente nunca arranca. Sliders, galerías y lightboxes son víctimas frecuentes.

3. El primer clic se pierde. El primer toque del visitante es la interacción que despierta al cargador. Los scripts aún no están cuando llega ese toque, así que no hace nada. Firma: siempre funciona al segundo toque. Tratamos este caso en detalle en la guía del menú hamburguesa.

4. La cadena se atasca en un script. Los scripts retrasados suelen volver a ponerse en orden, uno tras otro, para que las dependencias sigan funcionando. Si uno de ellos queda retenido (un bloqueador de anuncios, un filtro DNS o un proxy corporativo que ni responde ni rechaza), todo lo que viene después espera para siempre. Firma: intermitente, solo para algunos visitantes, nunca en su equipo. A menudo son las funciones del pie de página las que mueren.

5. El visitante nunca se cuenta. Si su etiqueta de analítica está retrasada, un visitante que lee la página y se va sin interactuar (y antes del temporizador) nunca la carga. Firma: ningún fallo visual, solo menos sesiones y una mayor proporción de visitas cortas que faltan en los informes.

Paso 1: confirmar que el retraso es la causa

Desactive el retraso, vacíe cada capa de caché (caché de página, caché del hosting, CDN) y vuelva a probar en una ventana privada. Si la función va, el retraso es la causa. Si sigue fallando, pare aquí: el problema está en otra parte, a menudo una optimización CSS que quitó los estilos de un elemento oculto (vea la guía sobre el critical CSS).

Después vuelva a activarlo y reproduzca el fallo como es debido:

• Emulación móvil en DevTools, no su vista de escritorio. Muchas configuraciones guardan una versión optimizada distinta por dispositivo.
• Una ventana privada limpia, sin extensiones, para ver lo que ve un visitante nuevo.
• Toque primero el elemento roto, sin mover el ratón ni hacer scroll antes. Es la única forma de ver el caso 3.
• Luego una vez más con un bloqueador de anuncios activo, para que aparezca el caso 4.

Paso 2: encontrar el script detrás de la función rota

Abra DevTools antes de reproducir el fallo y mire en tres sitios.

La consola. Cualquier error rojo tras su interacción apunta al caso 1, y el nombre de archivo a la derecha del error es su primer sospechoso. Haga clic en él: DevTools muestra la línea exacta.

Los event listeners del elemento. Haga clic derecho en el botón roto, elija Inspeccionar y abra el panel Event Listeners. Lista cada manejador vinculado al elemento y el archivo que lo vinculó. Si la lista está vacía tras su interacción, el script que debía vincular el manejador nunca se ejecutó (caso 2 o 4).

Una búsqueda en todos los archivos cargados. En el panel Sources, busque en todos los archivos (Ctrl+Mayús+F, o Cmd+Option+F en Mac) la clase o el id del elemento roto, por ejemplo menu-toggle o cky-btn-accept. El archivo que lo menciona es el que lo controla.

// Péguelo en la consola cuando la página haya cargado, antes de cualquier interacción,
// y otra vez después de su primer clic. Ajuste el tipo al marcado de su herramienta.
[...document.querySelectorAll('script[type]')]
  .filter(s => !/^(text|application)\/(javascript|ld\+json|json)$|^module$/.test(s.type))
  .map(s => s.src || s.dataset.src || (s.textContent || '').slice(0, 60))

Si el script identificado sigue en esa lista tras su interacción, la cadena nunca llegó a él: mire lo que hay justo antes (caso 4).

Paso 3: excluir toda la cadena, no solo el archivo

Un script rara vez funciona solo. Antes de excluirlo, anote lo que necesita, en el orden en que aparece en el código fuente de la página:

• Sus librerías: jQuery, y a veces jQuery Migrate o el script principal del tema.
• Su configuración: WordPress suele imprimir un pequeño script inline justo antes del archivo, con un id que termina en -js-extra (por ejemplo var wpcf7 = {...} para Contact Form 7). El archivo no puede ejecutarse sin él.
• Su propio archivo, al final.

Exclúyalos juntos y apunte a cada uno por un fragmento único de su URL (como /contact-form-7/ o jquery.min.js) en lugar de una palabra genérica. Un fragmento como slider puede coincidir con muchos más archivos de lo que cree, y cada coincidencia de más devuelve parte de la ganancia.

Paso 4: cuando no lo encuentra, divida en dos

En una página pesada con 60 scripts retrasados, leerlos uno a uno lleva una tarde. Dividir en dos lleva seis pruebas. Excluya la primera mitad de los scripts retrasados y pruebe. Si la función va, el culpable está en esa mitad; si no, en la otra. Divida otra vez, y otra: 60, 30, 15, 8, 4, 2, 1.

Dos reglas lo hacen fiable: purgue cada capa de caché entre dos pruebas, y mantenga jQuery junto a la mitad que lo contiene, o cada prueba fallará por el motivo equivocado.

Los sospechosos habituales, familia por familia

Menús, acordeones, pestañas. Excluya la cadena (jQuery más el script del tema), o dé al menú un pequeño script autónomo. El compromiso se explica en la guía del menú hamburguesa, y por qué el menú a veces comparte archivo con el resto del tema, en la guía sobre scripts de tema monolíticos.

Banners de cookies y herramientas de consentimiento. No los retrase. El banner tiene que poder usarse al instante, y el consentimiento tiene que registrarse antes de que cualquier etiqueta decida qué cargar. Estos scripts son pequeños, excluirlos cuesta poco. Si sus etiquetas usan el modo de consentimiento, el estado por defecto también tiene que fijarse antes de que se ejecuten. Para Axeptio en concreto, consulte cómo acelerar la carga de Axeptio.

Formularios y captchas. Excluya la cadena del plugin de formularios en las páginas que tienen un formulario, no en todo el sitio. Un captcha que solo carga cuando el visitante empieza a escribir es un buen compromiso.

Sliders y todo lo que se ve sin hacer scroll. Si es lo primero que ve el visitante, retrasarlo da un hero vacío o sin estilos, y a menudo un peor Largest Contentful Paint. Nada visible en la carga debería retrasarse, solo lo que queda más abajo.

Widgets de chat y pop-ups. Son exactamente aquello para lo que existe el retraso. Manténgalos retrasados. Si el lanzador debe verse sin interacción, dé a ese único script un temporizador corto en lugar de excluirlo.

Analítica y etiquetas. Retrasarlas gana poco con una etiqueta bien configurada y cuesta datos. Decídalo a conciencia: o la etiqueta carga pronto y cada visita cuenta, o espera y usted acepta contar solo a los visitantes que interactúan.

Después del arreglo: comprobar lo que no se ve

• Pruebe otra vez con un bloqueador de anuncios: un arreglo que solo funciona en un navegador limpio sigue fallando para parte de sus visitantes.
• Compare una semana de sesiones antes y después de activar el retraso. Una caída sin motivo de tráfico es el caso 5.
• Vuelva a probar tras cada actualización de tema o plugin: los nombres de archivo cambian, y una exclusión por URL puede dejar de coincidir.
• Y siga el orden que mantiene un sitio a salvo: primero las optimizaciones inofensivas, las arriesgadas de una en una, como en nuestro método para optimizar sin romper.

Con Mantys Core

En resumen

• Un retraso de JavaScript ejecuta cada script más tarde, en una página ya cargada, y solo si el cargador llega hasta ahí.
• Cinco fallos, cinco firmas: un error en la consola, una función que nunca arranca, un segundo toque, un fallo solo para algunos visitantes y menos sesiones.
• Confirme con el retraso desactivado y luego encuentre el script con la consola, los event listeners del elemento y una búsqueda en los archivos.
• Excluya toda la cadena (librería, configuración inline, archivo) por fragmento de URL, y solo donde haga falta. Divida en dos cuando esté perdido.
• No retrase nunca la herramienta de consentimiento ni nada visible en la carga; mantenga retrasados los widgets de chat y los pop-ups.