Scripts bloqueantes: por qué su sitio se congela al cargar
El test #07 analiza las etiquetas <script> y verifica si bloquean la primera visualización. Un problema común, fácil de corregir, que lo cambia todo para el usuario.
- Un script sin defer ni async bloquea el renderizado de la página: el visitante ve una pantalla blanca durante la descarga.
- Orilyt cuenta los scripts externos y calcula el porcentaje no bloqueante. ≥ 50 % = puntuación 100, 0 % = puntuación 30.
- La corrección es simple: agregar defer (o async) a cada etiqueta <script src="..."> es suficiente en la mayoría de los casos.
Cuando un navegador encuentra una etiqueta <script src="...">, se detiene, descarga el archivo, lo ejecuta y luego reanuda el renderizado de la página. Durante ese tiempo, el visitante no ve nada — o peor, una página a medio construir.
Este es el comportamiento predeterminado de HTML. Sin indicaciones explícitas, cada script externo es "bloqueante". Cuantos más scripts haya en el <head>, mayor será el retraso en la visualización.
El test #07 de Orilyt detecta este problema y mide la proporción de scripts no bloqueantes. Veamos cómo funciona y cómo aprovechar sus resultados.
¿Por qué los scripts bloqueantes son un problema?
Un sitio WordPress típico carga entre 5 y 15 archivos JavaScript externos: analytics, banner de cookies, sliders, formularios, diversos plugins. Si ninguno usa defer o async, el navegador los carga uno por uno antes de mostrar cualquier cosa.
El impacto en los Core Web Vitals es directo: el LCP (Largest Contentful Paint) y el FCP (First Contentful Paint) se retrasan. Google penaliza los sitios lentos en su clasificación.
Para el usuario, el efecto es inmediato: el sitio parece "congelado" durante 2 a 5 segundos en una conexión móvil. En 2026, eso es inaceptable.
¿Cómo funciona el test #07?
Orilyt analiza el código HTML de la página y extrae todas las etiquetas <script> con un atributo src (scripts externos). Se recopilan tres datos para cada script:
- Presencia del atributo defer — el script se descarga en paralelo y se ejecuta después del análisis HTML.
- Presencia del atributo async — el script se descarga en paralelo y se ejecuta en cuanto está listo.
- Posición en el <head> — un script bloqueante en el <head> es el peor caso.
La puntuación se calcula según el porcentaje de scripts no bloqueantes (defer o async):
Si no se detectan scripts externos, la puntuación es automáticamente 100/100 — sin riesgo de bloqueo.
El informe también muestra los "head offenders": scripts bloqueantes ubicados en el <head>, los que más impactan en la primera visualización.
defer vs async: ¿cuál es la diferencia?
Ambos atributos permiten al navegador descargar el script sin bloquear el renderizado. La diferencia está en el momento de la ejecución:
defer: el script se ejecuta después de que el HTML está completamente analizado, en orden de aparición. Ideal para la mayoría de los scripts (analytics, UI, plugins).
async: el script se ejecuta tan pronto como se descarga, sin esperar al HTML ni a otros scripts. Útil para scripts independientes (tracking, A/B testing).
En caso de duda, use defer — es la opción más segura porque preserva el orden de ejecución.
¿Cómo usar este test en sus propuestas?
Los scripts bloqueantes son un argumento particularmente eficaz en preventa: el problema es invisible para el propietario del sitio (tiene buena conexión) pero crítico para sus visitantes móviles.
Así se estructura la recomendación con el método FIA:
- Hecho: "Su sitio carga X archivos JavaScript sin defer ni async. Bloquean la visualización durante Y segundos."
- Impacto: "En móvil, los visitantes ven una pantalla blanca durante la carga. Google penaliza los sitios lentos en los resultados."
- Acción: "Agregar el atributo defer a cada etiqueta <script>. Tiempo estimado: 30 minutos (tema + plugins)."
El informe de Orilyt lista los scripts bloqueantes por URL — puede mostrar al cliente exactamente qué archivos causan el problema.
Integrar este test en su flujo de trabajo
El test #07 complementa los demás tests de rendimiento para un diagnóstico completo:
- Lance la auditoría Orilyt → la puntuación "Carga de scripts" aparece en la sección Rendimiento.
- Si la puntuación es roja o naranja, abra los detalles: verá el número de scripts bloqueantes, los "head offenders" y el porcentaje global.
- Después de la corrección (agregar defer/async), relance la auditoría y use la comparación antes/después para mostrar la mejora.
Combinado con los tests TTFB (#16), compresión (#04) y caché del navegador (#03), este test forma la base de un diagnóstico de rendimiento sólido.
Conclusión
Los scripts bloqueantes son una de las causas más frecuentes de lentitud en sitios WordPress. El problema es invisible a simple vista pero medible: es exactamente el tipo de hallazgo que justifica una auditoría profesional.
El test #07 de Orilyt le da un diagnóstico preciso: número de scripts, porcentaje no bloqueante, lista de infractores. Un argumento concreto, con datos, listo para incluir en su propuesta.
Pruebe un sitio de cliente ahora mismo — probablemente se sorprenderá por la cantidad de scripts bloqueantes.