Cómo arreglar los recursos que bloquean el renderizado en WordPress (2026) - ES

Cuando Vodafone redujo el JavaScript que bloquea el renderizado en su sitio italiano, Se cayó la pintura con contenido más grande 31% y las ventas aumentaron 8%. Eso no es un ajuste del margen de error. Esos son ingresos mensurables provenientes de una solución técnica. La misma optimización está disponible para todos los sitios de WordPress., y en la mayoría de las instalaciones se encuentra detrás de un único complemento.

respuesta rapida: Instale un complemento de rendimiento con “Retrasar JavaScript” y “Optimizar la entrega de CSS” caracteristicas (Prensa voladora, WP Rocket, o LiteSpeed ​​Cache para servidores LiteSpeed), habilitar ambos, luego vuelva a realizar la prueba en PageSpeed ​​Insights. por 90% de sitios de WordPress, ese solo paso borra la advertencia. El resto de esta guía cubre qué hacer cuando no es así..

Última revisión: abril 2026. Probado con versiones actuales de complementos y verificado con PageSpeed ​​Insights 2026 tanteo.

Qué “Bloqueo de renderizado” En realidad significa (Y por qué le cuesta dinero)

Los navegadores dejan de pintar píxeles en el momento en que encuentran un archivo CSS o JavaScript en el <cabeza>. Nada se muestra en la pantalla hasta que ese archivo termine de descargarse y ejecutarse.. Apila cinco archivos que bloquean el procesamiento en el encabezado, cada uno agrega 100-300 ms de retraso, y su visitante mira fijamente una pantalla blanca durante más de un segundo antes de que aparezca algo.

Esa pantalla blanca tiene un precio.. Pintura contenta más grande (LCP) es uno de los tres Core Web Vitals que utiliza Google para clasificar, y los recursos que bloquean el renderizado lo empujan más tarde por definición. Si lo tuyo se acabó 2.5 segundos, Google comienza a tratar la página como “Pobre.” Los competidores con LCP de menos de 1,5 segundos le superan en consultas comerciales incluso cuando su contenido es más débil.

Los estudios de caso de Google muestran un aumento de conversiones en el 5-15% rango cuando los sitios se mueven desde “Pobre” a “Bueno” en LCP. Eso la convierte en una de las pocas tareas de SEO que se amortiza por sí sola el primer mes después de la implementación..

primero, Descubra qué es lo que realmente bloquea su renderizado

No empieces a arreglar hasta que sepas qué arreglar. Tres herramientas te dan la respuesta en menos de un minuto:

PageSpeed ​​Insights (el oficial)

1. Ir a pagespeed.web.dev
2. Pegue su URL y ejecute la auditoría
3. Desplácese hasta el Diagnóstico sección
4. Expandir “Eliminar los recursos que bloquean el renderizado”
5. Verás una lista de archivos CSS y JS con su tamaño y los milisegundos que te cuesta cada uno.

La lista es tu lista de resultados. Las entradas principales suelen ser temas CSS, jQuery, y uno o dos complementos pesados (deslizadores, constructores de páginas, analítica).

DevTools de Chrome (gratis, tiempo real)

Haz clic derecho en tu página, elegir inspeccionar, luego abra el Actuación lengüeta. Golpear récord, refrescar, detener. La línea de tiempo muestra exactamente qué recursos bloquean la primera pintura.. DevTools es más preciso que PageSpeed ​​Insights para diagnosticar su propia visita, ya que usa tu conexión real.

La herramienta infrautilizada aquí es la Pestaña de cobertura. Presione Cmd+Mayús+P (Ctrl+Mayús+P en Windows), tipo “Cobertura,” presione Enter, luego recargar. Verá cada archivo CSS y JS anotado con cuánto se ejecuta realmente.. Archivos que muestran 80%+ sin usar son los cortes obvios. La mayoría de los sitios de WordPress tienen al menos una hoja de estilo con 90% bytes no utilizados que se cargan en cada página.

Prueba de página web (para los obsesivos)

webpagetest.org le ofrece un gráfico en cascada que muestra exactamente qué recursos bloquean la renderización. Gratis, interfaz densa. Merece la pena si PageSpeed ​​Insights y DevTools no te han dado una respuesta clara.

Una vez que tengas la lista, elija una ruta de solución a continuación. La ruta del complemento maneja 90% de los casos. La ruta manual es para sitios donde no puedes instalar otro complemento o necesitas un control preciso.

Solucionarlo con un complemento de rendimiento (El camino de 5 minutos)

Este es el camino que la mayoría de los sitios deberían tomar.. Un complemento de rendimiento moderno resuelve el bloqueo de renderizado en tres capas: aplazar JavaScript, optimizando la entrega de CSS, y eliminando CSS no utilizado. Tres complementos manejan esto bien en 2026, con diferencias significativas.

Prensa voladora (USD 60/año)

FlyingPress carga CSS usado como un archivo externo separado, que es más rápido para usuarios reales que la alternativa. Sus “Retrasar JavaScript” la implementación es granular: puede retrasar scripts específicos hasta la interacción del usuario, que a menudo borra por completo las advertencias de bloqueo de procesamiento sin interrumpir los análisis o los widgets de chat. Configuraciones para habilitar: Optimizar la entrega de CSS, Generar CSS crítico, Aplazar JavaScript, y Retrasar JavaScript con la lista de exclusión predeterminada. Eso es.

WP Rocket (59 dólares/año)

La opción paga más popular.. Conjunto de características comparables a FlyingPress con una compensación técnica: Cohetes WP “Eliminar CSS no utilizado” La característica integra el CSS usado directamente en tu HTML., que infla cada respuesta de página. FlyingPress y LiteSpeed ​​Cache lo cargan como un archivo externo. Para la mayoría de los sitios esta diferencia es insignificante.. Para sitios con mucho tráfico, suma. Habilitar: Optimizar la entrega de CSS, Cargar JavaScript diferido, y Retrasar la ejecución de JavaScript.

Caché LiteSpeed (gratis, Solo servidores LiteSpeed)

Si su host ejecuta LiteSpeed (Hostinger, Alojamiento A2, NombreHéroe, ChemiCloud, y la mayoría de los proveedores en nuestro alojamiento compartido barato resumen hacer), LiteSpeed ​​Cache es gratuito y coincide con los complementos pagos en correcciones de bloqueo de renderizado. La generación crítica de CSS se ejecuta en los servidores de LiteSpeed, no tuyo, para que no ralentice su sitio durante la construcción. Activar Carga asíncrona de CSS, CSS crítico, JS aplazar, y JS retrasado.

Opción gratuita: Autoptimizar + JavaScript asíncrono

Si no puedes pagar, el complemento Autoptimize combinado con el complemento Async JavaScript (ambos gratis, ambos mantenidos) cubre lo básico. No obtendrá el control granular de retraso hasta la interacción de FlyingPress, pero te encargarás 70-80% de las advertencias. Habilitar optimización automática Agregar archivos JS, CSS en línea y diferido, luego en el conjunto JavaScript asíncrono Aplicar asíncrono globalmente con jQuery excluido.

Después de habilitar cualquiera de estos, borrar todos los cachés, Espere 60 segundos, y vuelva a ejecutar PageSpeed ​​Insights. La advertencia de bloqueo de renderizado debería desaparecer o ser sustancialmente más pequeña.

Arreglarlo manualmente (Para desarrolladores y sitios de creación de páginas)

A veces un complemento no es una opción. Quizás su cliente bloqueó la lista de complementos. Quizás esté optimizando un tema personalizado con requisitos estrictos. Tal vez simplemente no confías en otra parte móvil. Asa de dos fragmentos 80% de casos manuales.

Aplazar todo JavaScript no esencial

Agregue esto al tema de su hijo funciones.php:

función htg_defer_scripts( $etiqueta, $manejar ) {

    Si ( es_admin() ) devolver $etiqueta;

    Si ( en_matriz( $manejar, [ 'jquery-núcleo’ ] ) ) devolver $etiqueta;

    devolver str_replace( ‘ origen=', ‘ diferir src = ', $etiqueta );

}

agregar_filtro( 'script_loader_tag', 'htg_defer_scripts', 10, 2 );

Este filtro captura todos los scripts que WordPress pone en cola, omite administrador y jQuery, y agrega el atributo de diferir a todo lo demás. Defer le dice al navegador que descargue el script en paralelo con el análisis de HTML, pero que lo ejecute solo después de que finalice el análisis.. Resultado: sin bloqueo de renderizado desde JavaScript.

La lista de exclusión es la parte que sintonizas. Si un script depende de que jQuery esté disponible antes de DOMContentLoaded, Verás errores de JavaScript después de implementar esto.. Agregue el identificador ofensivo a la matriz y vuelva a cargar. La mayoría de los sitios terminan excluyendo jquery-core, jquery-migrar, y uno o dos scripts de pasarela de pago.

CSS no crítico de carga asíncrona con consultas de medios

Para hojas de estilo que no son críticas para la primera pintura, cambiar el atributo multimedia de la etiqueta del enlace:

<enlace rel =”hoja de estilo” href =”no crítico.css” medios =”imprimir” cargar =”this.media = 'todo'”>

El navegador no bloquea la representación de estilos de impresión., luego el controlador de carga intercambia medios a “todas” una vez renderizada la página. WordPress no expone un filtro para este patrón, entonces editarás las llamadas del tema wp_enqueue_style o colocarás un pequeño complemento mu.

Incorpore su CSS crítico

CSS crítico es el subconjunto mínimo de estilos necesarios para hacer que todo sea visible en la mitad superior de la página.. Insertar ese subconjunto directamente en el <cabeza>, luego carga el resto de tu CSS de forma asincrónica. El navegador pinta al instante., luego aplica estilo progresivamente al resto de la página.

Generar CSS crítico a mano es brutal. Herramientas que lo automatizan:

• Prensa voladora, WP Rocket, Caché LiteSpeed generar CSS crítico automáticamente por tipo de página
• Generador CSS de ruta crítica (sitelocity.com/critical-path-css-generator) es una herramienta web gratuita para una generación única
• los “crítico” paquete npm se integra en una canalización de compilación si envía temas desde una cadena de herramientas JS

Para la mayoría de los sitios de WordPress, pagando USD 60 un año para que FlyingPress maneje la generación crítica de CSS es más barato que el tiempo que le toma al desarrollador mantenerlo manualmente. Las matemáticas se vuelven más feas cuando tienes 50 plantillas de página que necesitan calcular su propio CSS crítico.

La verdadera solución: Auditar y eliminar lo que no debería estar ahí

Los trucos del complemento aplazan la carga. Pero, ¿qué pasa si la carga no debería estar allí en absoluto?? La solución más duradera es la menos glamorosa: deja de cargar recursos que no necesitas.

Para cada entrada en tu lista de PageSpeed ​​Insights, haz tres preguntas:

1. ¿Realmente uso esto en esta página?? Un complemento de formulario de contacto que carga su CSS en cada página de producto bloquea la representación y ningún truco de aplazamiento soluciona por completo.
2. ¿Vale la pena el peso del complemento fuente?? Elementor, Dos, y WPBakery agrega rutinariamente entre 200 y 400 KB a cada página. Si no utiliza el constructor en cada página, estás pagando el costo de todos modos.
3. ¿Puedo reemplazar esto con algo más ligero?? control deslizante resbaladizo, FontAwesome a través de CDN, un script de análisis creado hace tres años y nunca utilizado. La mayoría de los sitios de WordPress de hace 5 años tienen una larga lista de scripts cortables.

Herramientas que ayudan:

• Perfimporta incluye un Administrador de secuencias de comandos para deshabilitar secuencias de comandos por página. El paquete Elementor JS, por ejemplo, se puede deshabilitar en páginas que no usan secciones de Elementor.
• Limpieza de activos (gratis) hace lo mismo con un conjunto de funciones más pequeño.
• Detective de complementos identifica de qué complemento proviene cada secuencia de comandos de bloqueo de renderizado cuando los nombres de los archivos están ofuscados.

Cortar scripts no utilizados en el origen produce mayores ganancias de PageSpeed ​​que cualquier optimización diferida. También es la única solución que sobrevive a un cambio de tema..

Común 2026 Culpables del bloqueo de renderizado en WordPress

Los mismos infractores aparecen en la mayoría de los sitios marcados por PageSpeed ​​Insights. Si tienes poco tiempo, revisa estos primero.

• jQuery (quieto!). El núcleo de WordPress carga jQuery en el front-end de forma predeterminada. Si tu tema no lo necesita, quitarlo de la cola. Perfmatters tiene una opción para alternar con un solo clic.
• Paquetes de creación de páginas. Frontend.min.js y frontend.css de Elementor bloquean el procesamiento en cada página que cargan. Audite el uso antes de pagar el costo en todas partes.
• Bloqueo cargado de fuentes de Google. Hospedar fuentes automáticamente o usar visualización de fuentes: intercambiar. Cargar tres pesos de fuente desde fonts.googleapis.com agrega entre 200 y 400 ms para renderizar.
• Banners de cookies y scripts de consentimiento. A menudo se cargan de forma sincrónica para cumplir con las normas de consentimiento de la UE., lo que los hace bloquear el renderizado por diseño. Utilice un complemento de consentimiento que posponga todo excepto su propio modal.
• Analítica, charla, y administradores de etiquetas. Administrador de etiquetas de Google, Intercomunicador, Deriva, y los scripts de Tawk.to pueden retrasarse hasta la interacción del usuario.. La mayoría de los complementos de rendimiento tienen un solo clic. “Demora” preestablecido para estos mangos.
• FontAwesome y otras fuentes de iconos. A menudo se carga el bloqueo cuando solo 4 Los iconos se utilizan en la página.. Cambie a iconos SVG o cargue FontAwesome asíncrono.

Hosts de WordPress administrados en nuestro resumen de EE. UU. normalmente incluyen CSS crítico a nivel de servidor, aplazamiento automático de JavaScript, y un CDN con optimización de fuentes. La misma configuración cuesta un complemento pago y varias horas de configuración en alojamiento compartido económico..

Cómo verificar que la solución funcionó

No confíes en los complementos “Configurado!” insignia. Verificar con tres cheques:

1. Vuelva a ejecutar PageSpeed ​​Insights en una URL nueva (añadir ?v=prueba para reventar el caché). La advertencia debería desaparecer o limitarse a uno o dos archivos esenciales..
2. Abra la página en Chrome Incógnito y esté atento a la rotura visual. Las reglas de aplazamiento mal configuradas provocan destellos de contenido sin estilo (FOUC).
3. Pruebe la ruta de conversión. Hacer clic “Añadir a la cesta,” enviar un formulario de contacto, acceso. JavaScript demasiado retrasado rompe elementos interactivos sin generar errores de consola.

Si PageSpeed ​​Insights sigue enumerando recursos que bloquean el procesamiento después de haber configurado todo correctamente, la auditoría probablemente se ejecutó antes de que su complemento terminara de optimizarse. Esperar 5 minutos, borrar todos los cachés (anfitrión, enchufar, CDN), luego vuelva a realizar la prueba desde una pestaña nueva.

Preguntas frecuentes

¿La eliminación de los recursos que bloquean el procesamiento realmente mejorará mi clasificación en Google??

Indirectamente, si. La solución mejora la pintura con contenido más grande, que es uno de los tres Core Web Vitals que Google utiliza como señal de clasificación. La señal no es enorme de forma aislada, pero es suficiente para romper lazos en consultas competitivas. La mayor ganancia es la conversión.: los usuarios abandonan las páginas de carga lenta, y una mejora de LCP de 100 ms produce constantemente un aumento de ingresos mensurable en los sitios comerciales.

¿Necesito WP Rocket?, ¿O puede un complemento gratuito hacer esto??

Un complemento gratuito puede hacer la mayor parte. Autoptimize más identificadores de JavaScript asíncronos 70-80% de advertencias de bloqueo de renderizado en un sitio típico de WordPress. WP Rocket y FlyingPress agregan controles granulares de retraso hasta la interacción y generación automática de CSS crítico, que valen el dólar 59-60 por año en sitios comerciales. Para un blog de hobby, el combo gratis esta bien.

¿Puedo arreglar los recursos que bloquean el renderizado sin ningún complemento??

si, pero espera escribir código. El filtro de aplazamiento anterior maneja JavaScript. CSS es más difícil: CSS crítico en línea manualmente, cambiar los atributos de los medios mediante anulaciones de temas, o generar CSS crítico con el “crítico” Paquete npm en una canalización de compilación. Plan 4-8 horas de tiempo de desarrollador, más tiempo si eres nuevo en los ganchos de WordPress.

¿Por qué PageSpeed ​​Insights sigue marcando el bloqueo de renderizado después de instalar un complemento??

Tres causas habituales: la configuración no está habilitada (Las instalaciones predeterminadas son conservadoras.), los cachés no se han borrado (la auditoría está probando HTML antiguo), o su tema pone en cola los recursos de una manera que el complemento no puede anular. Borrar todos los cachés, verificar la configuración, luego audite una página diferente para descartar problemas específicos del tema.

¿Cuál es la diferencia entre aplazar y asíncrono??

Ambos permiten la descarga de JavaScript en paralelo con el análisis de HTML., entonces ninguno de los bloques renderiza. La diferencia es la ejecución.. Async ejecuta el script tan pronto como se descarga, incluso a mitad del análisis. Aplazar espera a que el análisis termine primero. Utilice aplazar para scripts dependientes de DOM (la mayoría de los scripts de WordPress). Utilice async para scripts independientes como etiquetas de análisis.

¿Algo de esto romperá mi sitio??

Puede. Las reglas agresivas de retraso o aplazamiento de JavaScript ocasionalmente interrumpen los formularios de pago, widgets de chat, o características específicas del tema. Cada complemento le permite incluir scripts en la lista blanca a través de una lista de exclusión. Pruebe la ruta de conversión (carro, Formulario de contacto, iniciar sesión) después de cada cambio, y agregar scripts a la lista de exclusión cuando algo se rompe. La mayoría de los sitios llegan a una configuración estable en una hora.

¿Esto afecta por igual a dispositivos móviles y de escritorio??

El móvil ve la mayor mejora. Las sanciones por bloqueo de renderizado aumentan con la velocidad de conexión: un recurso que cuesta 200ms en fibra de escritorio cuesta 600-800ms en 4G. PageSpeed ​​Insights pondera la puntuación móvil de forma más agresiva por el mismo motivo. Optimizar primero para dispositivos móviles.

Pensamientos finales

“Eliminar los recursos que bloquean el renderizado” se lee como tarea, pero en realidad es una perilla de ingresos. El camino más corto es un complemento de rendimiento con valores predeterminados sensatos. El camino más duradero es auditar qué tema y complementos realmente necesitan cargar en cada página., luego cortando el resto. La combinación separa “suficientemente bueno” desde “pasando constantemente Core Web Vitals en cada plantilla.”

Si su sitio está luchando contra el host (plan compartido barato, PHP lento, sin LiteSpeed), ninguna cantidad de optimización del complemento resuelve completamente la advertencia. Almacenamiento en caché a nivel de servidor, PHP moderno, y una CDN real maneja una cantidad significativa de trabajo antes de que se ejecute cualquier complemento. Nuestro Alojamiento VPS WordPress guía y Alojamiento de comercio electrónico de WordPress filtro de resumen para hosts con los valores predeterminados correctos. Moderno Constructor de WordPress con IA Las plataformas también incluyen recursos predeterminados más eficientes que los creadores de páginas más antiguos., eludir todo el problema en lugar de luchar contra él.