¿Aparece el aviso 'Reducir render-blocking resources' al probar la web en PageSpeed? Es normal sentir miedo a tocar código; muchos principiantes buscan soluciones fiables y fáciles que no rompan la web. Aquí hay un plan seguro, paso a paso, pensado para probar y revertir cambios sin estrés.
Si PageSpeed muestra 'Reducir render-blocking resources', significa que CSS y JS están impidiendo que la página se muestre rápido. Se explicará, sin tocar código, cómo usar plugins seguros (p. ej. WP Rocket o Autoptimize + Async JavaScript), qué activar/desactivar para inyectar critical CSS y deferir scripts, y cómo medir la mejora en PageSpeed. Empezar por "Resumen del proceso" garantiza cambios seguros y reversibles.
Resumen del proceso
Crear backup y staging: copia completa antes de tocar nada.
Medir línea base: 3 pasadas en PageSpeed Insights móvil, registrar LCP/FCP/CLS/TBT.
Instalar plugin optimizador: WP Rocket o Autoptimize según presupuesto.
Generar e inyectar Critical CSS automático o con servicio; probar visualmente.
Activar "Defer JS" y excluir jQuery/handles críticos; probar interacción.
Manejar fuentes externas: self-host y font-display: swap o preload.
Repetir tests y comparar; documentar para rollback.
Paso 1: preparar el entorno y medir antes de tocar nada
Crear un staging y un backup completo debe ser el primer paso. Esto tarda entre 10 y 20 minutos en la mayoría de paneles de hosting. No procedas sin staging.
Limpiar caché del navegador y abrir una ventana de incógnito. Ejecutar PageSpeed Insights móvil 3 veces seguidas y anotar LCP, FCP, CLS y TBT. Hacer captura de pantalla de cada resultado.
Ejecutar Lighthouse en Chrome DevTools (F12 → Lighthouse) con emulación móvil. Guardar el JSON. Esto suele llevar 2–3 minutos por pasada.
Si el sitio ya tiene datos de campo, comprobar los Core Web Vitals en Search Console y RUM (Chrome UX Report). Registrar fechas.
Checklist inicial: (1) backup + staging; (2) 3 pruebas PageSpeed móvil; (3) Lighthouse JSON; (4) nota de plugins activos.
Advertencia en este paso: si no se guarda la línea base, no habrá forma fiable de medir la mejora. No avances sin al menos 3 pasadas y un backup.
Paso 2: elegir el plugin correcto para el caso
Para principiantes con presupuesto: WP Rocket (pago). Instalar, activar y seguir la guía del asistente. WP Rocket genera Critical CSS automático y trae opciones fáciles para deferir JS. Precio aproximado 49 €/año en 2026.
Si el presupuesto es cero o se busca flexibilidad: Autoptimize (gratuito) más la extensión de Critical CSS o servicios externos. Autoptimize combina y minifica, pero la generación de Critical CSS suele requerir un addon o servicio.
Si el hosting usa LiteSpeed: LiteSpeed Cache (gratuito con servidor compatible). Ofrece generación de Critical CSS y optimización integrada.
Para control granular: Perfmatters o Asset CleanUp . Sirven para desactivar cargas por página y son ideales en sites con muchos plugins.
Elección rápida vs elección correcta: la rápida es instalar WP Rocket y aplicar las opciones recomendadas (tarda 15–30 minutos). La correcta es probar en staging, excluir dependencias y ajustar (tarda 60–120 minutos).
✉
¿Quieres más información? Escríbenos y te orientamos
Guía paso a paso para configurar los plugins
Instalar y activar el plugin en staging. Este paso suele tardar 5 minutos.
WP Rocket — ajustes clave:
1) Dashboard → Settings → File Optimization.
2) Activar Optimize CSS delivery o Generate Critical CSS . Guardar y esperar la generación automática (puede tardar hasta 10 minutos).
3) Activar Load JavaScript deferred y marcar "Safe mode for jQuery" si está disponible. Si el menú o sliders fallan, añadir exclusiones.
4) Activar minificación de CSS/JS si no existe otra herramienta similar activa.
Autoptimize + Critical CSS — pasos:
1) Instalar Autoptimize. En Settings → Autoptimize: activar Optimize CSS y Optimize JavaScript.
2) Si se dispone del add-on de CriticalCSS o del servicio CriticalCSS.com, conectar la API o subir los archivos generados.
3) Si no hay servicio, dejar Autoptimize combinando pero no inlinear todo el CSS: usar la opción "Aggregate inline CSS" con cautela.
Asset CleanUp / Perfmatters — pasos útiles:
1) Revisar cada plantilla y desactivar assets no usados (ej.: slider en páginas sin slider). Esto tarda según la cantidad de plugins: entre 30 minutos y 2 horas.
2) Registrar qué handles se desactivan para revertir fácilmente.
Dato práctico: no activar la misma optimización en dos plugins. Por ejemplo, no minificar y combinar CSS en ambos a la vez; provoca conflicto y CSS roto.
Flujo rápido: Reducir recursos que bloquean
Backup & Staging
Medir (3x PageSpeed móvil)
Instalar plugin (WP Rocket/Autoptimize)
Generar Critical CSS
Defer JS con exclusiones
Probar y comparar métricas
Paso 3: generar e inyectar critical CSS
Opción sin código (recomendada para principiantes): usar WP Rocket o FlyingPress y activar la generación automática de Critical CSS. Esto suele tardar entre 2 y 15 minutos por URL según complejidad.
Si se usa Autoptimize y un servicio de Critical CSS: generar desde el servicio, descargar el archivo y pegarlo en la opción "Inline Critical CSS" del plugin. Probar la home, una entrada y una plantilla de producto si hay tienda.
Método con Penthouse/CLI (avanzado): requiere Node.js. Comandos ejemplo:
bash
npx penthouse --url=https://ejemplo.es --css=styles.css --width=412 --height=915 > critical-mobile.css
npx penthouse --url=https://ejemplo.es --css=styles.css --width=1300 --height=900 > critical-desktop.css
Este enfoque es correcto para pipelines CI/CD, pero no es la opción recomendada para principiantes sin entorno de desarrollo.
Inyectar el Critical CSS con plugin: pegar el contenido en el campo de "Custom CSS" o en la opción de Critical CSS del plugin. Probar y retroceder si hay roturas.
Cuidado: inyectar demasiado CSS crítico rompe estilos. Extraer solo lo que impacta el primer pliegue (header, hero, menús). Si el diseño se rompe, comentar la inyección y purgar caché.
Si necesitas generar Critical CSS de forma repetible para muchas páginas o en un pipeline CI/CD, añade ejemplos y scripts:
instala penthouse y escribe un pequeño script Node que recorra una lista de URLs y cree archivos por plantilla (ej.: urls.txt con /, /categoria/, /producto/): for url in $(cat urls.txt)
do npx penthouse --url=https://miweb.es${url} --css=dist/combined.css --width=412 --height=915 > critical-mobile${url/////_}.css
done. Repite para desktop y guarda en /critical/. En WordPress puedes inyectar por plantilla usando wp_add_inline_style: cargar el CSS principal con wp_enqueue_style('theme-main', ...)
if ( is_front_page() ) { $critical = file_get_contents(get_stylesheet_directory() . '/critical/critical-home-mobile.css')
wp_add_inline_style('theme-main', $critical)
} Para sitios headless o estáticos, incorpora la generación en el build (Gulp/webpack/Rollup) y emite un CSS crítico por ruta, enlazándolo en el HTML prerenderizado
Documenta el proceso en el repositorio y añade tests de regresión visual o de Lighthouse en el pipeline para evitar roturas al cambiar estilos.
Paso 4: defer y async para JavaScript: cómo y cuándo excluir
Diferir y usar async en JavaScript mejora TTI y TBT. Sin exclusiones, puede romper menús y formularios. Por eso, siempre añade una lista de exclusión.
Regla práctica: excluir jQuery, handles de sliders y cualquier script que registre eventos en el DOM antes de la carga completa.
Ejemplo seguro para desarrolladores (colocar en staging o usar plugin Code Snippets):
php
function agregar_defer_a_scripts( $tag, $handle ) {
$excluir = array( 'jquery', 'jquery-core', 'slider-js-handle' );
if ( in_array( $handle, $excluir ) ) return $tag;
if ( strpos( $tag, 'script' ) !== false ) {
return str_replace( ' src', ' defer="defer" src', $tag );
}
return $tag;
}
add_filter( 'script_loader_tag', 'agregar_defer_a_scripts', 10, 2 );
Probar tras activar: verificar menú, sliders, formularios y widgets. Si algo falla, añadir el handle a $excluir y volver a purgar caché.
Dividir pruebas: realizar un cambio y testear durante 10–20 minutos. No aplicar múltiples cambios simultáneos.
✉
¿Quieres más información? Escríbenos y te orientamos
Paso 5: fuentes y terceros: mitigación sin perder funcionalidad
Google Fonts y Analytics suelen ser culpables. Self-hosting de fuentes reduce peticiones a terceros y puede ayudar a controlar la latencia, pero no elimina automáticamente el render-blocking: es necesario combinarlo con preload (as="font" crossorigin), font-display (p. ej. swap) y una estrategia de carga (Font Face Observer o CSS Font Loading) para evitar FOIT/FOUC.
Plugins útiles: OMGF para Fonts self-host, CAOS para Google Analytics local. Alternativa: usar la opción de preload en WP Rocket o Perfmatters.
Pasos concretos para Google Fonts:
1) Usar OMGF para descargar y servir las fuentes desde el propio servidor.
2) Añadir font-display: swap en la declaración para evitar FOIT.
3) Hacer preload de la fuente principal para reducir LCP.
Para Analytics/Tag Manager: cargar scripts tras consentimiento. GDPR y LSSI-CE exigen consentimiento para trackers; retrasar carga hasta que el usuario acepte.
Las fuentes merecen tratamiento propio al trabajar con Critical CSS. En lugar de inyectar la fuente entera en el critical, usa preload con crossorigin para la fuente principal y declara @font-face con font-display: swap; ejemplo de enlace:
. Para mitigar FOIT/FOUC considera usar Font Face Observer (carga asíncrona y aplica clases como .fonts-loaded) o la API CSS Font Loading; así puedes renderizar con una fuente de sistema temporal y aplicar la webfont cuando esté lista.
No conviertas todo el fichero de fuentes en CSS crítico: inyecta solo reglas mínimas para el layout del primer pliegue (tipografías base y tamaños) y deja la carga del resto a deferred/preloaded fonts. Con estas prácticas reducirás LCP y evitarás bloqueos visuales sin sacrificar tipografía.
Errores que arruinan el resultado
Activar todas las opciones "optimizar" sin probar. Este es el error típico; rompe estilos o funciones JS.
Diferir jQuery sin exclusión. Resultado común: menú inservible y sliders caídos.
Combinar 2 plugins que minifican/combinen CSS al mismo tiempo. Provoca CSS duplicado o mezclado.
Confiar en una sola ejecución de PageSpeed. Una sola prueba en laboratorio no refleja campo. Hacer 3 pasadas y comparar con datos reales en 3–7 días.
Cuándo no funciona este método / alternativas
No aplica si el hosting ya realiza optimizaciones a nivel servidor (HTTP/2, HTTP/3, server push) y el CDN bloquea cambios. En ese caso, contacta con el hosting.
Si la web es muy simple (una página HTML ligera), la ganancia será mínima.
Si existe un equipo de desarrollo que prefiere soluciones por código (SSR, pipeline CI), la opción correcta es extraer Critical CSS en el build.
Si el sitio depende de trackers por cumplimiento legal, no retrases scripts sin revisar la política de consentimiento.
Comparativa práctica de plugins y costes
Plugin
Enfoque
Facilidad
Coste aprox.
Caso recomendado
WP Rocket
Todo-en-uno
Muy fácil
~49 €/año (2026)
Principiantes con presupuesto
Autoptimize + Critical
Flexible
Media
Gratuito + pago por servicio
Control y coste cero inicial
LiteSpeed Cache
Servidor-integrado
Media
Gratuito (si hosting es LiteSpeed)
Hosting LiteSpeed
Perfmatters / Asset CleanUp
Granular
Media-Alta
~24–60 €/año
Sitios con muchos plugins
✉
¿Quieres más información? Escríbenos y te orientamos
Recuperación ante errores: rollback rápido
Si tras un cambio ocurre un fallo visual o funcional, seguir pasos:
1) Desactivar plugin problemático desde WP-Admin si es accesible. Esto suele tardar 1–2 minutos.
2) Si WP-Admin falla, renombrar la carpeta del plugin por FTP/Filestore para desactivarlo.
3) Comentar cualquier snippet añadido en functions.php o en Code Snippets. Esto revierte el efecto inmediato.
4) Restaurar backup si el problema persiste. Restauración completa suele tardar 10–30 minutos según hosting.
Para identificar errores:
abrir DevTools → Console para errores JS
Network para peticiones bloqueadas
Lighthouse para ver qué recursos siguen siendo render-blocking
Plantillas y snippets seguros para enqueue/dequeue
Dequeue CSS ejemplo (probar en staging):
php
function quitar_slider_css() {
if ( is_front_page() ) {
wp_dequeue_style( 'slider-style-handle' );
wp_deregister_style( 'slider-style-handle' );
}
}
add_action( 'wp_enqueue_scripts', 'quitar_slider_css', 20 );
Para revertir, comentar el add_action o borrar la función. Este cambio suele probarse en 5–10 minutos.
Protocolo reproducible de medición: antes y después
1) Registrar 3 pasadas PageSpeed Insights móvil, anotar LCP/FCP/CLS/TBT.
2) Ejecutar WebPageTest desde Madrid o Barcelona (ubicación) para video filmstrip y TTFB.
3) Repetir pruebas tras cada cambio importante.
Objetivos orientativos:
LCP < 2.5s ideal
CLS < 0.1
reducir TBT por debajo de 200 ms
Tomar datos de campo en 3–7 días para ver impacto real.
Para que las mejoras sean fiables y reproducibles, añade un protocolo de medición automatizable:
Recolecta una línea base con 3 pasadas lab por URL y guarda el JSON de Lighthouse (F12 → Lighthouse) o usa la API/CLI: por ejemplo npx psi https://tusitio.es --strategy=mobile --output=json o lighthouse --output=json --output-path=./lhr.json https://tusitio.es
Ejecuta pruebas antes y después, toma la mediana de 3–5 pasadas por URL y registra LCP, FCP, CLS y TBT en una hoja (columnas: fecha, URL, ejecución, LCP, FCP, CLS, TBT, comentarios)
Además, consulta datos de campo durante 7–14 días (Core Web Vitals en Search Console/CrUX) para validar mejora en producción. Establece umbrales objetivo (ej.: LCP < 2.5s, FCP < 1.8s, TBT < 150ms, CLS < 0.1) y una meta mínima de mejora (p. ej. reducción de TBT ≥ 100–200ms o mejora LCP de 0.5s) antes de promover cambios a producción. Para integración CI, usa Lighthouse CI (lighthouse-ci collect && lighthouse-ci assert) o scripts que llamen a la API de PSI y publiquen un diff en el pipeline
Preguntas frecuentes
How can I eliminate render-blocking resources?
Identificar con PageSpeed y generar Critical CSS. Luego diferir JS no crítico y excluir dependencias importantes. Aplicar en staging y medir. Este procedimiento reduce FCP y LCP sin tocar código si se usan plugins como WP Rocket o Autoptimize. Probar 3 pasadas y documentar resultados.
How do I fix render-blocking resources?
Generar e inlinear el CSS crítico y posponer el resto. Usar defer/async con exclusiones para jQuery y elementos interactivos. Priorizar fuentes críticos con preload o self-host. Testear en staging; revertir si hay fallos.
¿Cómo eliminar recursos que bloquean el renderizado en WordPress?
Instalar WP Rocket o Autoptimize y activar entrega optimizada de CSS. Generar Critical CSS y luego activar defer JS con exclusiones. Revisar menús y sliders en staging antes de pasar a producción.
What is render-blocking JavaScript and CSS?
Son recursos que el navegador debe procesar antes de pintar la página. Bloquean la construcción del render tree y retrasan FCP y LCP. Reducirlos mejora experiencia y SEO según Google Lighthouse (2024).
How to eliminate render-blocking CSS and JavaScript?
Inlinear solo el Critical CSS y cargar el resto de CSS asíncronamente. Defer/async JS no crítico y excluir jQuery. Medir con Lighthouse y WebPageTest. Mantener pruebas repetidas para evitar regresiones.
¿Puedo hacerlo sin pagar plugins?
Respuesta corta: sí, con más trabajo. Autoptimize + OMGF + Asset CleanUp pueden lograr la mayor parte gratis. Requiere más pruebas manuales y tiempo para identificar handles: entre 2 y 6 horas para un sitio medio.
¿Cuánto tiempo tarda en notarse la mejora real?
La mejora en laboratorio se ve en horas. Los datos de campo tardan entre 3 y 7 días en reflejarse en Core Web Vitals para usuarios reales. Registrar antes y después para comprobar impacto.
Notas finales y recursos
Basado en prácticas recomendadas por Google Lighthouse (2024) y en trabajos de Addy Osmani y Steve Souders. Para auditorías avanzadas, usar Penthouse o herramientas en CI. Mantener cumplimiento GDPR/LSSI-CE al retrasar trackers.
Regla práctica final: siempre aplicar cambios en staging, hacer 3 pruebas PageSpeed móvil, y documentar para rollback. Si hay duda, elegir la opción menos agresiva (generación automática de Critical CSS y exclusiones puntuales).
Guía Lighthouse (Google)
