WordPress con TBT alto por scripts cómo reducirlo

Cuando un sitio WordPress muestra TBT alto por scripts, el problema suele estar en el trabajo que JavaScript obliga a hacer al navegador: descargar archivos, evaluarlos y ejecutarlos en el hilo principal. Eso puede volver la página menos reactiva durante la carga, aunque visualmente parezca rápida.

Para reducir un TBT alto por scripts en WordPress, normalmente conviene identificar qué archivos generan tareas largas, quitar carga innecesaria y retrasar solo el JavaScript no crítico. La clave no es desactivar cosas sin más, sino medir, probar y validar que la web sigue funcionando bien.

En términos de rendimiento, Total Blocking Time es una métrica de laboratorio usada por Lighthouse y visible en PageSpeed Insights. No es una métrica de campo principal de Core Web Vitals, pero sí ayuda a detectar problemas de capacidad de respuesta relacionados con scripts.

Qué significa tener un TBT alto por scripts en WordPress

Un TBT elevado indica que, durante la carga, el hilo principal del navegador ha quedado bloqueado por tareas largas de JavaScript. Una long task aparece cuando una tarea supera los 50 ms y retrasa otras acciones, como responder a un clic o procesar parte de la interfaz.

En WordPress esto puede venir de código del tema, plugins, constructores visuales, etiquetas de seguimiento o scripts de terceros. No siempre es cuestión de “tener muchos plugins”: a veces pocos plugins concentran gran parte del trabajo real del navegador.

Cómo detectar qué scripts están elevando el TBT

Lo más práctico es combinar PageSpeed Insights, Lighthouse y Chrome DevTools. En Lighthouse puedes revisar el tiempo en main thread, JavaScript no usado y tareas largas. En DevTools, la pestaña Performance permite ver qué script ejecuta cada tramo de bloqueo.

Conviene auditar por URL, no solo en la portada. Una ficha de producto, una landing con formularios o una página hecha con builder pueden tener un patrón distinto. Además, hay que separar tres fases: descarga, evaluación y ejecución. Un archivo pequeño puede seguir generando mucho bloqueo si ejecuta lógica compleja.

• Revisa qué URLs de scripts aparecen repetidas en las páginas lentas.
• Identifica si el impacto viene del tema, un plugin concreto o terceros.
• Compara antes y después de cada cambio en un entorno seguro.

Qué tipos de scripts suelen bloquear más el hilo principal

Los casos más habituales son los scripts de terceros de analítica, píxeles publicitarios, chats, mapas, reproductores embebidos o widgets sociales. También suelen influir sliders, builders, librerías heredadas con dependencia de jQuery y funcionalidades cargadas globalmente aunque solo se usen en una página.

Otro foco común es el exceso de JavaScript no usado, la minificación mal planteada o la combinación agresiva de archivos que termina empeorando la ejecución. Retrasar scripts críticos sin criterio también puede romper menús, formularios, consentimiento, seguimiento de conversiones o elementos above the fold.

Si el hosting, la caché o la CDN están bien configurados, el cuello de botella puede seguir estando en el trabajo del navegador. Por eso optimizar entrega ayuda, pero no sustituye una auditoría del código que realmente se ejecuta.

Qué cambios pueden reducir el TBT sin romper la web

Para reducir TBT en WordPress, suele funcionar mejor priorizar impacto real que aplicar ajustes masivos. Algunas acciones razonables son:

• Cargar scripts solo donde hacen falta mediante carga condicional de recursos.
• Retrasar o diferir JavaScript no crítico, comprobando exclusiones si hay dependencias sensibles.
• Eliminar plugins o módulos redundantes que duplican funciones.
• Reducir terceros y cuestionar cada etiqueta de seguimiento.
• Revisar builder, tema y librerías comunes para detectar sobrecarga estructural.

Si usas un plugin de optimización, conviene hacerlo con prudencia. Puede ayudar a retrasar JavaScript o a gestionar exclusiones, pero dependerá del stack del sitio, de cómo estén montados el tema y los plugins y de si hay scripts críticos para negocio o analítica.

Errores habituales al optimizar JavaScript en WordPress

El error más común es optimizar para “pasar PageSpeed” sin comprobar uso real. Un buen resultado no depende solo de la puntuación, sino de reducir trabajo del navegador y mantener la funcionalidad. También es frecuente aplicar defer, delay o minificación a todo sin distinguir scripts críticos y no críticos.

Otros fallos habituales son no medir por plantilla, ignorar el impacto de terceros, no validar conversiones tras los cambios o asumir que el problema siempre está en jQuery. A veces el mayor coste está en un widget concreto, en un constructor visual muy cargado o en código inline añadido por varios plugins.

Cuándo conviene pedir una revisión técnica del sitio

Si el TBT sigue alto tras ajustes básicos, si hay muchas dependencias cruzadas o si la web usa un builder pesado, una revisión técnica suele ahorrar tiempo. También conviene cuando no está claro qué scripts bloquean el hilo principal o cuando cualquier cambio rompe eventos, formularios o integraciones.

En esos casos, lo razonable es revisar cascada de carga, tareas largas, orden de ejecución y dependencias por plantilla. Google documenta este enfoque dentro de Lighthouse y las guías de rendimiento de Core Web Vitals.

La prioridad práctica es clara: medir, localizar scripts concretos, probar cambios con control y verificar que no se rompen funciones ni conversiones. Un TBT alto por scripts puede reducirse, pero el resultado dependerá del tema, plugins activos, terceros, caché, CDN y del trabajo real que ejecuta el navegador.

Si tu sitio sigue bloqueado pese a optimizaciones básicas, el siguiente paso razonable es una revisión técnica centrada en JavaScript, dependencias y carga condicional, no solo en la puntuación de la herramienta.