Cómo Eliminar CSS y JS que Bloquean el Renderizado: Async, Defer y CSS Crítico

Cómo Eliminar CSS y JS que Bloquean el Renderizado: Async, Defer y CSS Crítico

Última verificación: 13 de octubre de 2026
19 min de lectura
Guía
Core Web Vitals

#Qué son los recursos que bloquean el renderizado y por qué importan

Cuando el navegador carga tu página, lee el código HTML línea por línea. Cuando encuentra una etiqueta <script src="archivo-pesado.js"> o <link rel="stylesheet">, detiene todo lo demás, descarga ese archivo y lo ejecuta. Solo entonces continúa renderizando el resto de la página. Esto es lo que se conoce como “render-blocking” o bloqueo de renderizado.

Descubre nuestros servicios de optimización de velocidad WordPress en WPPoland.

En 2026, con las métricas de Core Web Vitals como factor de posicionamiento en Google, especialmente LCP (Largest Contentful Paint) e INP (Interaction to Next Paint), resolver los problemas de recursos que bloquean el renderizado es una de las optimizaciones técnicas de mayor impacto que puedes implementar.

El aviso de PageSpeed Insights que dice “Eliminar los recursos que bloquean el renderizado” es uno de los más frecuentes y, al mismo tiempo, uno de los que más confunden a los propietarios de sitios WordPress. Este artículo explica exactamente que significa, por qué ocurre y como resolverlo paso a paso.

#Cómo funciona el renderizado en el navegador

Para entender por qué ciertos recursos bloquean el renderizado, necesitas comprender como el navegador construye una página web:

#Cómo construye el navegador el DOM

  1. Descarga del HTML. El navegador descarga el documento HTML del servidor.
  2. Parsing del HTML. El parser recorre el HTML línea por línea, construyendo el DOM (Document Object Model), que es la estructura en árbol de la página.
  3. Encuentro con CSS. Cuando el parser encuentra una etiqueta <link rel="stylesheet">, necesita descargar y procesar ese archivo CSS para construir el CSSOM (CSS Object Model). Mientras tanto, el renderizado se detiene porque el navegador necesita los estilos para saber cómo pintar los elementos. Como resume web.dev, el navegador tiene que descargar y analizar los archivos CSS antes de mostrar la página, y eso convierte al CSS en un recurso que bloquea el renderizado.
  4. Encuentro con JS. Cuando el parser encuentra una etiqueta <script src="...">, se detiene completamente. Descarga el archivo JavaScript, lo parsea y lo ejecuta. Solo después continúa con el HTML restante. Esto ocurre porque el JavaScript podría modificar el DOM que se está construyendo.
  5. Render Tree. Solo cuando el DOM y el CSSOM están listos, el navegador puede combinarlos en el Render Tree y pintar la página.

Cada archivo CSS o JavaScript en el <head> de tu página que no tenga atributos especiales bloquea este proceso. Si tienes 5 archivos CSS y 8 archivos JavaScript en el head, el navegador tiene que descargar, parsear y ejecutar los 13 antes de mostrar un solo pixel al usuario.

#Cómo afecta el bloqueo de renderizado a Core Web Vitals

El bloqueo de renderizado afecta directamente a dos métricas críticas:

FCP (First Contentful Paint): El momento en que el navegador pinta el primer contenido (texto, imagen, SVG). Cuantos más recursos bloqueen el renderizado, más tarda en ocurrir el primer pintado. El objetivo es un FCP inferior a 1.8 segundos.

LCP (Largest Contentful Paint): El momento en que se renderiza el elemento más grande visible en la pantalla. Si un archivo CSS pesado impide que el navegador pinte la imagen hero o el bloque de texto principal, el LCP se dispara. El objetivo es un LCP inferior a 2.5 segundos.

En WordPress cada plugin puede encolar su propia hoja de estilos y su propio script en todas las páginas, también en las que no los usan, así que la lista de PageSpeed Insights crece con cada plugin instalado. Mientras esos archivos no llegan, el visitante ve una pantalla en blanco. En móvil cada petición tarda más por la latencia de la red, y el mismo número de archivos cuesta más tiempo que en escritorio.

#JavaScript: async y defer explicados en profundidad

La vieja escuela decía “pon los scripts en el footer (wp_footer)”. La nueva escuela dice “usa atributos”. Ambas estrategias buscan lo mismo: evitar que los scripts bloqueen el parsing del HTML. Pero los atributos ofrecen un control más fino.

#Cómo se carga un script sin async ni defer

<script src="archivo.js"></script>

El parser HTML se detiene. Descarga el archivo. Lo ejecuta. Solo entonces continúa con el HTML. Esto es el máximo bloqueo posible.

#Qué hace el atributo async

<script async src="archivo.js"></script>

El archivo se descarga en segundo plano mientras el parser continúa con el HTML. Sin embargo, en cuanto la descarga termina, el parser se detiene para ejecutar el script. Esto significa que el momento de la ejecución es impredecible y depende de la velocidad de descarga.

Cuando usar async:

  • Scripts de analítica (Google Analytics, Matomo).
  • Pixels de seguimiento (Facebook Pixel, Google Ads).
  • Scripts que no dependen de otros scripts ni del DOM.

Cuando NO usar async:

  • Scripts que dependen de jQuery u otra librería.
  • Scripts que manipulan elementos del DOM que aun no se han cargado.
  • Scripts que tienen dependencias de orden de ejecución entre sí.

#Qué hace el atributo defer

<script defer src="archivo.js"></script>

El archivo se descarga en segundo plano mientras el parser continúa con el HTML. Pero a diferencia de async, la ejecución se pospone hasta que el HTML está completamente parseado. Además, los scripts con defer se ejecutan en el orden en que aparecen en el HTML.

Cuando usar defer:

  • La mayoría de scripts de WordPress (es la opción segura por defecto).
  • Scripts que dependen del DOM.
  • Scripts con dependencias entre si (ya que se ejecutan en orden).
  • Plugins de WordPress que cargan su JS en el head.

Dos detalles de la referencia de MDN evitan sorpresas. defer y async no tienen efecto en scripts en línea sin atributo src. Y los scripts con type="module" ya se difieren por defecto, así que añadirles defer no cambia nada. Los scripts diferidos se ejecutan antes del evento DOMContentLoaded, por eso un fragmento en línea que necesite jQuery diferido puede esperar a ese evento.

#Cómo añadir defer en WordPress

La forma más directa es usar un plugin de cache/optimización. WP Rocket, Autoptimize y LiteSpeed Cache tienen una opción “Defer JS” que aplica el atributo automáticamente a los scripts. Después de activarla, revisa la consola del navegador en las páginas con sliders, formularios y galerías.

Para tus propios scripts no hace falta ningún filtro. Desde WordPress 6.3, el antiguo parámetro $in_footer de wp_enqueue_script() acepta un array con las claves in_footer y strategy, según la referencia de la función:

wp_enqueue_script(
    'tema-galeria',
    get_template_directory_uri() . '/js/galeria.js',
    array( 'jquery' ),
    '1.2.0',
    array(
        'in_footer' => true,
        'strategy'  => 'defer',
    )
);

WordPress revisa la cadena de dependencias antes de imprimir el atributo. La nota de desarrollo de WordPress 6.3 fija las reglas: para que un script se difiera, sus dependencias pueden ser diferidas o bloqueantes, pero todos los scripts que dependen de él tienen que ser diferidos. Si alguno de ellos es bloqueante, el script y sus dependencias vuelven a cargarse de forma bloqueante. Un script async puede bajar a defer o a bloqueante, nunca al revés. Y si le añades código en línea en posición after con wp_add_inline_script(), la estrategia se elimina.

Para scripts de un plugin que no controlas, la misma nota documenta wp_script_add_data(), que se ejecuta después de que el plugin registre su handle:

add_action( 'wp_enqueue_scripts', 'es_diferir_scripts_de_plugins', 100 );

function es_diferir_scripts_de_plugins(): void {
    foreach ( array( 'slider', 'lightbox', 'mapa' ) as $handle ) {
        wp_script_add_data( $handle, 'strategy', 'defer' );
    }
}

La lista nombra los handles que se pueden diferir. Una lista de exclusiones (“todo menos jQuery”) también diferiría cualquier script que añada el próximo plugin que instales, y el fallo aparecería sin que hayas tocado el código. En versiones anteriores a la 6.3 la clave strategy se ignora, así que el código no rompe nada, simplemente no tiene efecto.

Además de defer, puedes cargar tus propios scripts en el footer con la clave in_footer del mismo array:

wp_enqueue_script(
    'tema-menu',
    get_template_directory_uri() . '/js/menu.js',
    array(),
    '1.0.0',
    array( 'in_footer' => true )
);

Con in_footer el script se imprime antes de </body> en lugar de en el head. No conviene volver a registrar el script de un plugin con otra ruta para moverlo: en la siguiente actualización del plugin tu copia queda desfasada.

#Critical CSS en WordPress paso a paso

El CSS es más complejo que el JavaScript en lo que respecta al bloqueo de renderizado. No puedes simplemente “retrasar” la carga de CSS porque la página se mostraría como texto sin formato durante un momento, creando el efecto FOUC (Flash of Unstyled Content), que es una experiencia de usuario terrible.

#Qué es Critical CSS

Critical CSS es la técnica de extraer solo los estilos necesarios para renderizar el contenido “above the fold” (lo visible sin hacer scroll) e incrustarlo directamente en el HTML, mientras el resto del CSS se carga de forma asíncrona en segundo plano.

El proceso funciona así:

  1. Identificar los estilos críticos. Analizar que reglas CSS son necesarias para renderizar correctamente la parte visible de la página sin scroll.
  2. Incrustar los estilos críticos inline. Pegar esos estilos dentro de una etiqueta <style> en el <head> del HTML, eliminando la necesidad de descargar un archivo CSS externo antes de pintar.
  3. Cargar el CSS completo de forma asíncrona. El resto del CSS (estilos del footer, secciones inferiores, modals, etc.) se carga en segundo plano y se aplica cuando este listo.

#Cómo generar Critical CSS manualmente

Para un sitio simple, puedes generar Critical CSS manualmente:

<head>
    <!-- Critical CSS inline: solo estilos del above the fold -->
    <style>
        body { font-family: system-ui, sans-serif; margin: 0; }
        .header { background: #1a1a2e; color: white; padding: 1rem; }
        .hero { padding: 3rem 1rem; max-width: 1200px; margin: 0 auto; }
        .hero h1 { font-size: 2.5rem; line-height: 1.2; }
        /* ... solo los estilos necesarios para la parte visible */
    </style>

    <!-- CSS completo cargado de forma asincrona -->
    <link rel="preload" href="/styles/main.css" as="style"
          onload="this.onload=null;this.rel='stylesheet'">
    <noscript><link rel="stylesheet" href="/styles/main.css"></noscript>
</head>

El patrón preload con onload es el que recomienda web.dev para cargar CSS de forma asíncrona. El <noscript> fallback asegura que la hoja de estilos completa se cargue normalmente si JavaScript está deshabilitado.

Para el tamaño del bloque en línea, la guía de web.dev sobre CSS crítico recomienda mantener el contenido above the fold por debajo de 14 KB comprimidos, para minimizar los viajes de ida y vuelta hasta el primer pintado. La misma guía cita dos herramientas para extraerlo: Critical, que extrae, minifica e incrusta el CSS above the fold y funciona con Gulp, Grunt o webpack, y Penthouse, pensada para sitios con muchos estilos, en la que indicas tú los archivos HTML y CSS.

#Critical CSS con plugins de WordPress

La mayoría de los plugins de optimización modernos generan Critical CSS automáticamente:

WP Rocket: Genera Critical CSS automáticamente para cada página. Es la solución más completa y requiere mínima configuración. Al activar la opción “Optimizar la entrega de CSS”, el plugin analiza cada página, extrae los estilos críticos y los incrusta inline.

Autoptimize + CriticalCSS.com: Autoptimize puede integrarse con el servicio CriticalCSS.com para generar Critical CSS automáticamente. Requiere una API key pero el proceso es completamente automático.

LiteSpeed Cache: Genera Critical CSS a través del servicio QUIC.cloud, y su cache de página funciona en servidores LiteSpeed.

Perfmatters: Un plugin ligero cuyo Script Manager desactiva scripts y estilos por página, útil para los plugins que cargan sus archivos en todo el sitio.

#Eliminar CSS no utilizado

Además del Critical CSS, otra optimización importante es eliminar el CSS que no se usa en cada página. La pestaña Coverage de Chrome DevTools muestra cuánto de cada archivo cargado se usa realmente, y la documentación de Lighthouse la recomienda precisamente para encontrar el CSS y el JS no críticos.

Herramientas como PurgeCSS, UnCSS o las funcionalidades integradas de WP Rocket pueden analizar que selectores CSS se usan realmente en cada página y eliminar el resto. Esto reduce dramáticamente el tamaño de los archivos CSS que el navegador tiene que descargar y parsear.

En WordPress, puedes desencolar las hojas de estilo de plugins que no se usan en determinadas páginas:

function remove_unused_css() {
    // No cargar los estilos de WooCommerce en páginas que no son de tienda
    if (function_exists('is_woocommerce') && !is_woocommerce() && !is_cart() && !is_checkout()) {
        wp_dequeue_style('woocommerce-general');
        wp_dequeue_style('woocommerce-layout');
        wp_dequeue_style('woocommerce-smallscreen');
    }

    // No cargar los estilos de Contact Form 7 excepto en la página de contacto
    if (!is_page('contacto')) {
        wp_dequeue_style('contact-form-7');
    }
}
add_action('wp_enqueue_scripts', 'remove_unused_css', 100);

#Cómo evitar que las fuentes bloqueen el renderizado

Las fuentes web son otro recurso frecuente que bloquea el renderizado. Cuando el navegador encuentra una declaración @font-face en el CSS, necesita descargar el archivo de fuente antes de poder pintar el texto. Esto crea un retraso visible que afecta tanto al FCP como al LCP.

#Qué hace font-display: swap

La propiedad CSS font-display: swap indica al navegador que muestre el texto inmediatamente con una fuente del sistema (fallback) mientras la fuente web se descarga en segundo plano. Cuando la fuente web esta lista, el navegador la intercambia automáticamente.

@font-face {
    font-family: 'MiFuente';
    src: url('/fonts/mi-fuente.woff2') format('woff2');
    font-display: swap;
}

Esto elimina el periodo de texto invisible (FOIT, Flash of Invisible Text) y mejora significativamente el FCP.

#Cómo precargar fuentes críticas

Para las fuentes que se usan en el above the fold, añade una etiqueta de preload en el head:

<link rel="preload" href="/fonts/mi-fuente.woff2" as="font" type="font/woff2" crossorigin>

El atributo crossorigin es necesario incluso cuando las fuentes se sirven desde tu propio dominio, debido a como los navegadores manejan las peticiones de fuentes.

#Alojar fuentes localmente en lugar de Google Fonts

Google Fonts es la fuente de fuentes web más popular, pero tiene implicaciones de rendimiento y privacidad:

Rendimiento: Cargar fuentes de Google requiere conexiones DNS adicionales, handshakes TLS y peticiones HTTP al CDN de Google. Alojar las fuentes localmente elimina toda esta latencia.

Privacidad (RGPD): La carga dinámica de Google Fonts transmite la dirección IP del visitante a servidores de Google. En enero de 2022 el Landgericht München I, un tribunal alemán, consideró ilícita esa transmisión sin consentimiento, y la sentencia desató una ola de reclamaciones en Alemania.

Para alojar Google Fonts localmente:

  1. Descarga los archivos de fuente desde el repositorio de Google Fonts o con la herramienta google-webfonts-helper.
  2. Sube los archivos WOFF2 a tu servidor (WOFF2 ofrece la mejor compresión).
  3. Actualiza las declaraciones @font-face en tu CSS para apuntar a los archivos locales.
  4. Elimina las referencias a fonts.googleapis.com y fonts.gstatic.com de tu HTML.

En WordPress, el plugin OMGF (Optimize My Google Fonts) automatiza este proceso completamente.

#Minificar y combinar CSS y JS con HTTP/2 en WordPress

#Qué aporta la minificación de CSS y JS

La minificación elimina espacios en blanco, comentarios y caracteres innecesarios de los archivos CSS y JavaScript sin cambiar su funcionalidad. El ahorro depende de cuántos comentarios y espacios tenga el archivo original, y con compresión gzip o Brotli activa en el servidor la diferencia transferida es menor que la del archivo sin comprimir.

En WordPress, la minificación se gestiona típicamente con plugins de cache:

  • WP Rocket: Minifica CSS y JS automáticamente con una casilla.
  • Autoptimize: Especializado en minificación y combinación de archivos.
  • LiteSpeed Cache: Incluye minificación integrada.

#Combinar archivos CSS y JS con HTTP/2

Combinar múltiples archivos CSS en uno (y múltiples archivos JS en uno) reduce el número de peticiones HTTP. Sin embargo, en 2026 con HTTP/2 y HTTP/3, la combinación de archivos es menos crítica que antes, ya que estos protocolos permiten múltiples descargas simultaneas sobre una sola conexión.

La combinación puede incluso ser contraproducente si invalida la cache con demasiada frecuencia. Si combinas 15 archivos CSS en uno y cambias una sola línea en un plugin, todo el archivo combinado necesita re-descargarse. Con archivos separados, solo el archivo modificado necesita actualizarse.

La recomendación actual es minificar siempre, pero combinar solo cuando el sitio todavía usa HTTP/1.1 o cuando la cascada muestra decenas de archivos pequeños que esperan su turno.

#Preload, prefetch y fetchpriority en WordPress

Además de async, defer y Critical CSS, los navegadores modernos soportan directivas de priorización que permiten indicar que recursos son críticos y cuales pueden esperar:

#Cuándo usar preload

<link rel="preload" href="/critical-script.js" as="script">
<link rel="preload" href="/hero-image.webp" as="image">

Preload indica al navegador que descargue un recurso lo antes posible, antes de que lo descubra naturalmente durante el parsing del HTML. Úsalo para recursos críticos como la imagen LCP, la fuente principal o un script esencial.

#Cuándo usar prefetch

<link rel="prefetch" href="/pagina-siguiente/">
<link rel="prefetch" href="/estilos-pagina2.css">

Prefetch indica al navegador que descargue un recurso con baja prioridad durante el tiempo libre, anticipando que el usuario lo necesitara pronto. Es útil para precargar recursos de la siguiente página probable de navegación.

#Cuándo usar fetchpriority

<img src="/hero.webp" fetchpriority="high">
<img src="/decorativa.webp" fetchpriority="low">

El atributo fetchpriority permite ajustar la prioridad de descarga de recursos individuales. Úsalo para aumentar la prioridad de la imagen LCP y reducir la de imágenes decorativas o fuera de pantalla.

Según web.dev, el atributo funciona en link, img y script y admite los valores high, low y auto. Preload y fetchpriority hacen trabajos distintos: preload sirve para que el navegador descubra antes el recurso, fetchpriority cambia su prioridad pero no ayuda a descubrirlo. Una imagen LCP precargada puede seguir recibiendo prioridad baja, y la imagen de fondo en CSS que sea el elemento LCP sigue necesitando preload. En WordPress 6.9 la referencia de wp_enqueue_script() añade la clave fetchpriority al mismo array que strategy.

#Cómo identificar recursos que bloquean el renderizado

#Detectar bloqueos de renderizado con PageSpeed Insights

PageSpeed Insights lista los recursos que bloquean el renderizado en la sección “Oportunidades” bajo “Eliminar los recursos que bloquean el renderizado”. Cada recurso listado muestra:

  • El URL del archivo.
  • El tamaño del archivo.
  • El ahorro potencial en milisegundos.

Esto te da una lista clara de los archivos que necesitas optimizar, ordenados por impacto.

#Detectar bloqueos de renderizado con Chrome DevTools

  1. Abre Chrome DevTools (F12).
  2. Ve a la pestaña “Performance”.
  3. Graba una carga de página.
  4. Busca en el timeline las tareas largas de evaluación de scripts y de cálculo de estilos.
  5. Los bloques que aparecen antes del primer pintado son los recursos que bloquean el renderizado.

Lighthouse marca como bloqueante un <script> en el <head> sin defer ni async, y un <link rel="stylesheet"> sin atributo disabled cuyo media coincide con el dispositivo. Según la documentación de Lighthouse, media="all" cuenta como bloqueante.

La pestaña “Network” también es útil. Filtra por CSS y JS, ordena por prioridad y busca archivos que se descargan con prioridad “High” o “Highest” antes del primer pintado.

#Detectar bloqueos de renderizado con WebPageTest

WebPageTest ofrece un waterfall detallado que muestra visualmente la secuencia de carga de cada recurso, dividida en DNS, conexión, TLS y descarga. Busca los archivos CSS y JS que terminan antes de la línea vertical de Start Render: son los que el navegador esperó antes de pintar.

#Cómo combinar defer, Critical CSS y fuentes

Para un sitio WordPress, la estrategia óptima combina todas estas técnicas:

  1. JavaScript: Todo con defer excepto scripts absolutamente críticos (analítica básica, scripts de consentimiento de cookies). Nunca uses async para scripts que dependen de jQuery.

  2. CSS: Critical CSS inline en el head para cada tipo de página (home, artículo, producto, categoría). Resto del CSS cargado de forma asíncrona con la técnica preload/onload.

  3. Fuentes: Alojadas localmente, formato WOFF2, con font-display: swap y preload para la fuente principal.

  4. Imágenes: La imagen LCP con fetchpriority="high" y preload. Resto de imágenes con lazy loading nativo.

  5. Terceros: Scripts de terceros (analítica, chat, redes sociales) cargados con defer o, mejor aun, con carga diferida tras la interacción del usuario.

  6. Minificacion: Todos los archivos CSS y JS minificados. Combinación solo si es beneficiosa.

Con esta estrategia, el usuario ve contenido inmediatamente mientras los recursos pesados (scripts de galería, mapas, widgets) se cargan en segundo plano. Mide FCP y LCP antes y después de cada paso para saber qué cambio movió cada métrica.

#Errores comunes al aplicar defer y Critical CSS

#Por qué defer en jQuery rompe plugins

Muchos plugins de WordPress dependen de jQuery y esperan que esté disponible inmediatamente. Aplicar defer a jQuery puede romper sliders, modals, validación de formularios y otras funcionalidades. La solución es excluir jQuery del defer o migrar a una versión del plugin que no dependa de jQuery.

#Por qué purgar CSS rompe hovers y modales

Al purgar CSS no utilizado, herramientas automáticas pueden eliminar estilos que solo se activan con interacción del usuario (hovers, estados activos, modals) o que se aplican a contenido cargado dinámicamente. Siempre verifica el resultado visual después de purgar CSS, especialmente en dispositivos móviles.

#Por qué probar en móvil y no solo en escritorio

Un sitio puede cargar rápido en escritorio con una conexión de fibra y fallar completamente en móvil con 4G. Siempre prueba las optimizaciones en la vista móvil de PageSpeed Insights y en dispositivos reales.

#Sacar 100 en PageSpeed Insights no es el objetivo

PageSpeed Insights es una herramienta de diagnóstico, no un objetivo en si mismo. Un sitio con puntuación 100 pero que no convierte es inútil. Optimiza para la experiencia real del usuario, no para un número.

#Conclusión

Los recursos que bloquean el renderizado son uno de los problemas de rendimiento más comunes y más solucionables en sitios WordPress. La combinación de defer para JavaScript, Critical CSS para hojas de estilo y font-display: swap para fuentes web acorta el tiempo hasta el primer pintado sin quitar nada a la página.

La clave es entender el mecanismo: el navegador no puede pintar hasta que ha procesado los recursos en el head. Reducir, retrasar o eliminar esos recursos acelera directamente el primer pintado y mejora las métricas de Core Web Vitals que Google usa para posicionar.

Comienza por PageSpeed Insights para identificar los recursos problemáticos, implementa las soluciones con un plugin de cache como WP Rocket o mediante código personalizado, y verifica los resultados con la misma URL y la misma configuración de prueba.

Siguiente paso

Transforma el artículo en una implementación real

Este bloque refuerza el enlazado interno y lleva al lector al siguiente paso más útil dentro de la arquitectura del sitio.

¿Quieres implementar esto en tu sitio?

Si el problema está en los Core Web Vitals, en el rendering lento o en el peso de WordPress, puedo mapear e implementar la optimización.

Preguntas frecuentes

Respuestas prácticas para aplicar el tema en la ejecución real.

¿Qué diferencia hay entre async y defer?#
Ambos descargan el script en segundo plano. Con async el script se ejecuta en cuanto termina la descarga, en un orden impredecible, así que encaja con analítica y píxeles de seguimiento. Con defer se ejecuta cuando el HTML está completamente parseado y en el orden del documento, y es la opción segura para la mayoría de scripts de WordPress.
¿Qué es el Critical CSS?#
Es la técnica de incrustar en el head solo los estilos necesarios para el contenido visible sin scroll y cargar el resto del CSS de forma asíncrona con el patrón preload y onload. WP Rocket, Autoptimize con CriticalCSS.com, LiteSpeed Cache y Perfmatters pueden generarlo automáticamente.
¿Por qué aplicar defer a jQuery rompe plugins?#
Muchos plugins esperan que jQuery esté disponible de inmediato, así que diferirlo puede romper sliders, modales y la validación de formularios. La solución es excluir jQuery del defer o migrar a una versión del plugin que no dependa de jQuery.
¿Cómo evitar que las fuentes web bloqueen el renderizado?#
Usa font-display: swap para mostrar el texto con una fuente del sistema mientras se descarga la fuente web, precarga la fuente principal y alójala localmente en formato WOFF2. Alojar Google Fonts en tu servidor elimina la latencia extra y el envío de la IP del visitante a Google.

¿Necesitas un FAQ adaptado a tu sector y mercado? Preparamos una versión alineada con tus objetivos de negocio.

Hablemos

Artículos Relacionados