Las fuentes web son uno de esos recursos que damos por sentados hasta que PageSpeed Insights nos avisa de que algo bloquea el renderizado. A diferencia de las imágenes, que pesan más pero el navegador puede pintar el contenido sin ellas, las fuentes tienen una particularidad: pueden bloquear la visualización del texto si no se configuran bien.
En WordPress esto es bastante común. Los temas cargan tipografías desde Google Fonts, los constructores web añaden las suyas, los plugins meten iconos en formato fuente y, sin darnos cuenta, acabamos con media docena de peticiones a fonts.googleapis.com que retrasan el primer renderizado.
En este artículo te explico cómo funciona la carga de fuentes web en el navegador, qué impacto tienen en las Core Web Vitals y qué acciones concretas puedes aplicar en tu WordPress para que las fuentes dejen de ser un cuello de botella.
- Qué son las fuentes web y cómo se cargan
- Cómo carga el navegador una fuente web
- font-display: el interruptor clave
- Google Fonts: problemas y optimización
- Self-hosting vs. Google Fonts y CDN
- Preload de fuentes
- Preconnect y dns-prefetch
- Impacto en CLS: reservar espacio para las fuentes
- Implementación práctica en WordPress
- Errores comunes
- Cómo medir el impacto de las fuentes
- Conclusión y checklist
- Recursos y enlaces oficiales
Qué son las fuentes web y cómo se cargan
Una fuente web es un archivo de tipografía que el navegador descarga para mostrar el texto con una apariencia concreta. A diferencia de las fuentes del sistema (las que ya vienen instaladas en el dispositivo del usuario), las fuentes web no están garantizadas: hay que pedirlas, descargarlas y procesarlas antes de poder usarlas.
En CSS, las fuentes web se declaran con la regla @font-face:
@font-face { font-family: 'MiFuente'; src: url('/fonts/mi-fuente.woff2') format('woff2'); font-weight: 400; font-style: normal; font-display: swap;}
El navegador, al encontrar @font-face en el CSS, programa la descarga del archivo de fuente. Pero aquí viene el problema: si el texto depende de esa fuente y el navegador no la tiene todavía, tiene que decidir qué hacer mientras llega.
Fuentes del sistema vs. fuentes web
Las fuentes del sistema (Arial, Helvetica, Georgia, system-ui…) no necesitan descarga. El navegador las tiene disponibles de inmediato y pinta el texto sin esperar. Son el caso base más rápido.
Las fuentes web requieren una petición HTTP adicional. Si esa petición es lenta, o si el CSS que declara la fuente es render-blocking, el texto puede tardar en aparecer o mostrarse con una fuente de respaldo (fallback) que luego cambia.
Formatos de fuente: WOFF2 primero
Los formatos de fuente relevantes hoy son:
| Formato | Compresión | Soporte | Cuándo usarlo |
|---|---|---|---|
| WOFF2 | Mejor compresión | Más del 97 % | Formato principal |
| WOFF | Buena | Más del 98 % | Fallback si se necesita |
| TTF/OTF | Sin compresión | Universal | Solo si no hay alternativa |
| EOT | Obsoleto | Solo IE antiguo | No usar |
WOFF2 es el formato recomendado en la actualidad. Ofrece la mejor compresión, tiene soporte prácticamente universal y es el que Google Fonts sirve por defecto cuando el navegador lo soporta.
Cómo carga el navegador una fuente web
Para entender por qué las fuentes pueden ser un problema de rendimiento, hay que entender el flujo que sigue el navegador cuando carga una página que usa fuentes web.

El flujo de carga
- El navegador descarga el HTML.
- Analiza el HTML y descubre referencias a CSS.
- Descarga y procesa el CSS (esto puede bloquear el renderizado).
- Dentro del CSS encuentra @font-face con la URL de la fuente.
- Programa la descarga del archivo de fuente.
- Cuando la fuente llega, la procesa y pinta el texto con ella.
El punto clave es que la fuente no se descarga en paralelo con el HTML desde el principio. El navegador primero necesita descargar y procesar el CSS para descubrir que la fuente existe. Esto crea una cadena: HTML → CSS → fuente → pintado.
FOIT y FOUT: dos comportamientos distintos
Cuando el navegador está esperando a que llegue una fuente web, puede comportarse de dos formas:
- FOIT (Flash of Invisible Text): el navegador oculta el texto mientras espera la fuente. Si la fuente tarda demasiado, el usuario ve un espacio en blanco donde debería haber texto. Es el comportamiento por defecto en muchos navegadores cuando no se especifica font-display.
- FOUT (Flash of Unstyled Text): el navegador muestra el texto con una fuente del sistema mientras llega la fuente web. Cuando la fuente llega, la sustituye. El usuario ve texto desde el principio, pero puede haber un cambio visual (lo que llamamos un «flash»).
El FOIT es peor para el rendimiento percibido porque el usuario no ve nada. El FOUT muestra contenido antes, pero puede causar CLS (Cumulative Layout Shift) si las métricas de la fuente de respaldo y la fuente final son diferentes.
La forma de controlar este comportamiento es con font-display, que veremos a continuación.
El hosting que rompe récords
Tiempos de carga ultrarrápidos y estabilidad inquebrantable para que nada te detenga.
font-display: el interruptor clave
La propiedad font-display dentro de @font-face es la herramienta más importante para controlar cómo el navegador gestiona la carga de fuentes. Define qué pasa en los periodos de bloqueo y de intercambio.
Los cinco valores de font-display
| Valor | Periodo de bloqueo | Periodo de intercambio | Comportamiento |
|---|---|---|---|
| auto | Depende del navegador | Depende del navegador | El navegador decide, normalmente como block. |
| block | Corto (3 s) | Infinito | Texto invisible hasta 3 s, luego fallback. |
| swap | Muy corto (~0 s) | Infinito | Texto con fallback inmediato, cambia al llegar. |
| fallback | Muy corto (~0 s) | Corto (~3 s) | Fallback rápido, cambio solo si llega pronto. |
| optional | Muy corto (~0 s) | Sin intercambio | El navegador decide según la red. |
Cuándo usar cada uno
swap es el valor más recomendado para la mayoría de sitios WordPress. Muestra el texto inmediatamente con una fuente del sistema y la sustituye cuando la fuente web está disponible. El usuario nunca ve un espacio en blanco.
@font-face { font-family: 'MiFuente'; src: url('/fonts/mi-fuente.woff2') format('woff2'); font-display: swap;}
optional es ideal para fuentes decorativas o de poco impacto. El navegador descarga la fuente con prioridad baja y, si no llega rápido, la descarta para esa visita. No hay cambio visual, pero la fuente se cachea para la siguiente página. Es útil cuando quieres mejorar la tipografía sin penalizar el rendimiento.
block oculta el texto hasta 3 segundos. No lo recomiendo salvo en casos muy específicos donde el texto invisible sea preferible a un cambio de fuente (por ejemplo, tipografías con métricas muy diferentes donde el FOUT cause un CLS severo).
auto deja la decisión al navegador, que normalmente se comporta como block. No lo recomiendo porque pierdes el control.
fallback es un compromiso: muestra texto con fallback rápido y solo cambia si la fuente llega en los primeros 3 segundos. Puede ser útil para fuentes donde el cambio visual es aceptable pero no deseado si llega tarde.
font-display en Google Fonts
Google Fonts añade font-display mediante el parámetro &display= en la URL:
<link href="https://fonts.googleapis.com/css2?family=Roboto:wght@400;700&display=swap" rel="stylesheet">
Si no añades &display=swap, Google Fonts no incluye font-display en el CSS generado, y el navegador usará su comportamiento por defecto, que normalmente equivale a block.
Esto significa que sin &display=swap, tu texto puede estar invisible durante hasta 3 segundos en conexiones lentas.
Google Fonts: problemas y optimización
Google Fonts es el servicio de fuentes web más usado en WordPress. Es gratuito, fácil de integrar y tiene un catálogo enorme. Pero si lo configuras mal, puede convertirse en uno de los mayores cuellos de botella de tu página.
El problema de las variantes
Cada peso, estilo y variante de una fuente es una petición HTTP adicional o un CSS más grande. Google Fonts genera un único CSS que incluye todos los pesos que solicitas, pero el navegador tiene que descargar cada archivo de fuente (.woff2) correspondiente.
Un caso real de una auditoría WPO que realicé hace poco (junio de 2026) sobre un sitio WordPress con el constructor Breakdance reveló esto claramente. La URL de Google Fonts cargaba 18 variantes de la fuente Lato:
<!-- Antes: 18 variantes, 833 ms de bloqueo --><link href="https://fonts.googleapis.com/css2?family=Lato:ital,wght@0,100;0,300;0,400;0,700;0,900;1,100;1,300;1,400;1,700;1,900&display=swap" rel="stylesheet">
Esa sola petición bloqueaba el renderizado durante 833 milisegundos en móvil, porque el navegador tenía que descargar y procesar un CSS con 18 declaraciones @font-face y luego descargar cada archivo de fuente referenciado.
La solución fue reducir a solo los 3 pesos que realmente se usaban en el diseño:
<!-- Después: 3 pesos, ~0 ms de bloqueo adicional --><link href="https://fonts.googleapis.com/css2?family=Lato:ital,wght@0,400;0,700;1,400&display=swap" rel="stylesheet">
Resultado: 833 ms menos de bloqueo y 12 KB menos de CSS de fuentes. El LCP (Largest Contentful Paint) móvil bajó de 13,1 segundos a un rango estimado de 2,0 a 2,5 segundos (junto con otras optimizaciones del mismo proyecto).
Cómo saber qué pesos usas realmente
Abre DevTools, ve a la pestaña Network, filtra por «font» y recarga la página. Verás cada archivo .woff2 que se descarga. Cada uno corresponde a un peso o variante que has declarado en la URL de Google Fonts.
Si ves 10 archivos de fuente y tu diseño solo usa 3 pesos, estás descargando 7 fuentes que no necesitas.
Otra forma es usar la pestaña Elements y buscar en el CSS calculado qué font-weight se aplica a cada elemento visible. Si tu cuerpo de texto usa 400 y tus títulos 700, no necesitas 300, 500 ni 900.

Preconnect a fonts.googleapis.com y fonts.gstatic.com
Google Fonts sirve el CSS desde fonts.googleapis.com y los archivos de fuente desde fonts.gstatic.com. Son dos dominios diferentes, lo que significa dos resoluciones DNS, dos conexiones TCP y dos negociaciones TLS.
Para reducir este coste, añade preconnect a ambos dominios en el <head>:
<link rel="preconnect" href="https://fonts.googleapis.com"><link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
El atributo crossorigin en el preconnect a fonts.gstatic.com es obligatorio porque las fuentes se solicitan con CORS (Cross-Origin Resource Sharing) habilitado. Sin él, el preconnect no se aprovecha para la descarga de fuentes.
El parámetro &display=swap
Como vimos en la sección anterior, añadir &display=swap a la URL de Google Fonts es la forma más sencilla de evitar el FOIT. Sin embargo, es importante entender que swap por sí solo no resuelve todo:
- Evita que el texto esté invisible, pero puede causar CLS si las métricas de la fuente de respaldo y la fuente final difieren.
- No reduce el número de variantes descargadas.
- No elimina el tiempo de descarga de la fuente, solo cambia qué se muestra mientras llega.
&display=swap es necesario, pero no suficiente. Hay que acompañarlo con selección de pesos, preconnect y, según el caso, preload.
Self-hosting vs. Google Fonts y CDN
La pregunta de si alojar las fuentes en tu propio servidor o seguir usando Google Fonts surge en casi cualquier proyecto de WPO serio. Ambas opciones tienen ventajas e inconvenientes.
Ventajas de self-hosting
- Una conexión menos: no necesitas preconnect a fonts.googleapis.com ni fonts.gstatic.com. Las fuentes se sirven desde tu propio dominio, que ya tiene conexión establecida.
- Control total: decides el formato, los pesos, el CSS y las cabeceras de caché.
- Sin redirecciones: Google Fonts puede añadir redirecciones 302 que retrasan la descarga.
- Mejor para privacidad: no envías la IP de tus visitantes a los servidores de Google (fundamental en Europa).
- Compatibilidad con CSP: si usas Content Security Policy, self-hosting elimina la necesidad de añadir dominios externos a la lista de permitidos.
Inconvenientes de self-hosting
- No hay CDN (red de distribución de contenidos) global por defecto: Google Fonts se sirve desde la red de Google, que tiene puntos de presencia en todo el mundo. Si tu hosting solo tiene un servidor en un centro de datos, tus fuentes pueden tardar más en llegar a usuarios lejanos.
- Mantenimiento: tienes que gestionar las actualizaciones de las fuentes, los formatos y los fallbacks.
- Configuración de caché: necesitas configurar correctamente las cabeceras Cache-Control y Expires para que las fuentes se cacheen en el navegador.
- Generación de subconjuntos: para optimizar al máximo, puede que necesites generar subsets (por ejemplo, solo caracteres latinos) para reducir el tamaño del archivo.
Cuándo usar cada opción
Google Fonts es adecuado cuando:
- Empiezas con WordPress y necesitas algo rápido.
- Tu hosting no tiene CDN y Google Fonts ofrece mejor latencia global.
- Usas fuentes que solo están en Google Fonts.
- No quieres gestionar archivos de fuente ni caché de fuentes.
Self-hosting es recomendable cuando:
- Ya usas un CDN (Cloudflare, CloudFront, etc.) y las fuentes se sirven desde ahí.
- Quieres maximizar el control sobre la entrega.
- Necesitas privacidad o cumplimiento de CSP.
- Tienes un sitio con mucho tráfico y quieres reducir dependencias externas.
- Quieres arañar los máximos milisegundos a la respuesta de la web.
Herramientas para self-hosting
Si decides alojar las fuentes, hay herramientas que facilitan el proceso:
- Google Webfonts Helper: genera los archivos de fuente y el CSS @font-face listo para descargar e integrar.
- Fontsource: paquetes npm de fuentes de código abierto con CSS y archivos listos para self-hosting.
- Subfont: herramienta que analiza tu HTML y genera un subconjunto de fuentes con solo los caracteres que usas.
Preload de fuentes
El <link rel="preload"> es una directiva que le dice al navegador: «descarga este recurso cuanto antes, lo voy a necesitar». Aplicado a fuentes, puede reducir el tiempo hasta que la fuente está disponible para pintar texto.
Cuándo precargar una fuente
Precargar una fuente tiene sentido cuando:
- La fuente se usa en el contenido above the fold (la parte visible de la página sin hacer scroll), especialmente en el elemento LCP.
- La fuente se carga vía CSS externo y el navegador tarda en descubrir la declaración @font-face.
- Has verificado en DevTools que la fuente se descarga tarde en el waterfall (la cascada de carga de recursos).
<link rel="preload" href="/fonts/mi-fuente-400.woff2" as="font" type="font/woff2" crossorigin>
El atributo crossorigin es obligatorio en el preload de fuentes, igual que en el preconnect, porque las fuentes siempre se solicitan con CORS.
Cuándo NO precargar una fuente
No es recomendable precargar fuentes cuando:
- La fuente no se usa en el above the fold.
- Ya has hecho preconnect a los dominios de Google Fonts y la fuente se descarga temprano.
- El LCP (Largest Contentful Paint) no depende de texto con esa fuente (por ejemplo, si el LCP es una imagen).
- Tienes muchas fuentes y precargar todas compite por el ancho de banda.
Preload no es magia: cada recurso precargado compite por el ancho de banda y la CPU con otros recursos críticos. Precargar 5 fuentes puede empeorar el rendimiento en lugar de mejorarlo.
Preload con Google Fonts
Si usas Google Fonts, precargar el archivo de fuente directamente es complicado, porque las URL de fonts.gstatic.com incluyen parámetros dinámicos y pueden cambiar. En este caso, lo más efectivo es el preconnect que vimos antes.
Si haces self-hosting, precargar es directo porque controlas la URL del archivo (otro punto a favor del self-hosting de las fuentes):
<link rel="preload" href="/fonts/inter-400.woff2" as="font" type="font/woff2" crossorigin><link rel="preload" href="/fonts/inter-700.woff2" as="font" type="font/woff2" crossorigin>
Precarga solo los pesos que se usan en el above the fold. Normalmente, uno o dos como máximo.
Preconnect y dns-prefetch
Además del preconnect a Google Fonts, hay otras conexiones tempranas que puedes establecer para reducir latencia.
Preconnect
<link rel="preconnect"> establece anticipadamente la conexión a un dominio: resolución DNS, conexión TCP y negociación TLS. Lo usas para dominios de los que vas a descargar recursos pronto.
<link rel="preconnect" href="https://fonts.googleapis.com"><link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
dns-prefetch
<link rel="dns-prefetch"> es más ligero: solo hace la resolución DNS, sin establecer conexión TCP ni TLS. Es útil para dominios de los que descargarás recursos más tarde o con menos prioridad.
<link rel="dns-prefetch" href="//fonts.gstatic.com">
En la práctica, preconnect es preferible para fuentes porque incluye DNS + TCP + TLS. dns-prefetch es más adecuado para dominios secundarios o analíticas.
Cuántos preconnect usar
Cada preconnect abre una conexión que consume recursos del navegador. No recomiendo más de 3 o 4 preconnects en una página. Para fuentes, normalmente necesitas 1 o 2.
Si ya haces self-hosting de las fuentes, no necesitas ningún preconnect de fuentes porque todo se sirve desde tu dominio.
El hosting para los desarrolladores más exigentes
Hosting con funcionalidades avanzadas para un control y rendimiento total de tus proyectos.
Impacto en CLS: reservar espacio para las fuentes
El CLS (Cumulative Layout Shift) mide cuánto se mueven los elementos de la página mientras se carga. Las fuentes web son una causa común de CLS, porque la fuente de respaldo y la fuente final suelen tener métricas diferentes.
Por qué las fuentes causan CLS
Cuando usas font-display: swap, el navegador muestra el texto con una fuente del sistema mientras llega la fuente web. Si la fuente del sistema es más estrecha, más alta o tiene un interlineado diferente, el texto cambia de tamaño cuando se sustituye la fuente. Ese cambio es un layout shift.
Por ejemplo, si tu fuente del sistema es Arial y tu fuente web es Lato, el texto puede ocupar una altura diferente con cada una. Cuando Lato reemplaza a Arial, el contenido de debajo del texto se desplaza.
Estrategias para reducir el CLS de fuentes
1. Elige fuentes de respaldo con métricas similares
El fallback stack (font-family: 'Lato', Arial, sans-serif) debería usar una fuente del sistema cuyas métricas se aproximen a la fuente web. Cuanto más parecidas sean, menor será el salto.
body { font-family: 'Inter', system-ui, -apple-system, sans-serif;}
system-ui y -apple-system usan la fuente del sistema nativa, que en muchos casos tiene métricas razonables como respaldo.
2. Ajusta el tamaño con size-adjust
La propiedad size-adjust dentro de @font-face permite escalar la fuente para que sus métricas coincidan con la fuente de respaldo. Esto reduce el salto visual:
@font-face { font-family: 'Inter'; src: url('/fonts/inter-400.woff2') format('woff2'); font-display: swap; size-adjust: 100%;}
Ajustar size-adjust requiere pruebas: comparas la fuente web con la fuente de respaldo y modificas el porcentaje hasta que las alturas coincidan.
3. Usa font-metric-override
Para un control más fino, CSS permite sobrescribir las métricas de la fuente de respaldo para que coincidan con la fuente web:
@font-face { font-family: 'Fallback-Inter'; src: local('Arial'); font-display: swap; ascent-override: 90%; descent-override: 22%; line-gap-override: 0%; size-adjust: 100%;}
Esto define una fuente de respaldo con métricas ajustadas. Luego la usas en el stack:
body { font-family: 'Inter', 'Fallback-Inter', sans-serif;}
4. Reserva altura con line-height
Si la fuente web es más alta que la de respaldo, puedes fijar un line-height que acomode ambas:
body { font-family: 'Lato', Arial, sans-serif; line-height: 1.6;}
Un line-height generoso reduce el impacto del cambio de fuente porque hay espacio de más que absorbe la diferencia.
CLS y fuentes de iconos
Las fuentes de iconos (Font Awesome, Material Icons, etc.) también pueden causar CLS si los iconos se renderizan inicialmente como texto o caracteres vacíos y luego se sustituyen por el icono. Asegúrate de que el contenedor del icono tiene un ancho y alto fijos para evitar el desplazamiento.
Si es posible, utiliza iconos SVG, que nos ofrecen muchas más ventajas.
Implementación práctica en WordPress
Veamos cómo aplicar todo lo anterior en un sitio WordPress real. Hay tres vías principales: por código, por plugin de WPO y por configuración del tema.
Opción 1: por código (functions.php o MU-plugin)
La forma más controlada es inyectar las etiquetas <link> en el <head> mediante un MU-plugin o el functions.php del tema hijo.
/** * Add preconnect and font preload to head. */function cl_font_optimization() { ?> <link rel="preconnect" href="https://fonts.googleapis.com"> <link rel="preconnect" href="https://fonts.gstatic.com" crossorigin> }add_action( 'wp_head', 'cl_font_optimization', 1 );
Si haces self-hosting, puedes hacer enqueue de las fuentes como cualquier otro recurso:
/** * Enqueue self-hosted fonts. */function cl_enqueue_self_hosted_fonts() { wp_enqueue_style( 'cl-fonts', get_stylesheet_directory_uri() . '/fonts/fonts.css', array(), '1.0.0' );}add_action( 'wp_enqueue_scripts', 'cl_enqueue_self_hosted_fonts', 1 );
Y el archivo fonts.css contendría las declaraciones @font-face con font-display: swap:
@font-face { font-family: 'Inter'; src: url('inter-400.woff2') format('woff2'); font-weight: 400; font-style: normal; font-display: swap;}@font-face { font-family: 'Inter'; src: url('inter-700.woff2') format('woff2'); font-weight: 700; font-style: normal; font-display: swap;}
Para inyectar el preload de fuentes self-hosted:
/** * Preload self-hosted fonts. */function cl_preload_fonts() { ?> <link rel="preload" href=" echo esc_url( get_stylesheet_directory_uri() . '/fonts/inter-400.woff2' ); " as="font" type="font/woff2" crossorigin> <link rel="preload" href=" echo esc_url( get_stylesheet_directory_uri() . '/fonts/inter-700.woff2' ); " as="font" type="font/woff2" crossorigin> }add_action( 'wp_head', 'cl_preload_fonts', 2 );
Opción 2: por plugin de WPO

Muchos plugins de caché y WPO incluyen opciones de optimización de fuentes:
- WP Rocket: en la pestaña de optimización de archivos, tiene opción para optimizar Google Fonts y añadir preconnect automáticamente.
- FlyingPress: incluye optimización de Google Fonts y preconnect.
- LiteSpeed Cache: con la opción de optimización CSS activada, puede diferir el CSS de fuentes.
- Perfmatters: permite desactivar Google Fonts del tema y añadir preconnect.
- Autoptimize: puede mover el CSS de fuentes al pie de página o diferirlo.
La ventaja de usar un plugin es que no necesitas tocar código. La desventaja es que no siempre sabes exactamente qué hace: algunos plugins eliminan font-display, otros no añaden preconnect correctamente y otros pueden romper la carga de fuentes del tema.
Opción 3: por configuración del tema
Algunos temas permiten configurar las fuentes desde el personalizador:
- Temas de bloques (editor del sitio): en theme.json puedes definir la tipografía y, si las fuentes están self-hosted en el tema, el propio tema se encarga de la carga.
- Kadence, GeneratePress, Astra: permiten elegir entre Google Fonts y fuentes del sistema desde sus ajustes.
- Breakdance, Elementor: cargan Google Fonts por defecto, pero permiten definir qué pesos se usan.
Revisa los ajustes de tu tema para ver si puedes limitar los pesos de las fuentes desde ahí antes de recurrir a código o plugins.
Errores comunes
1. Cargar todas las variantes de una fuente
Es el error más frecuente. Un tema o constructor web declara 10 o 20 pesos de Google Fonts «por si acaso», y el navegador descarga el CSS con todas las declaraciones @font-face. Aunque el navegador solo descarga los archivos de fuente que se usan realmente, el CSS de Google Fonts es más grande y tarda más en procesarse.
Solución: declara solo los pesos que uses en el diseño. Normalmente 400 para texto, 700 para títulos y, si necesitas itálica, 400 italic.
2. No usar font-display
Sin font-display, el navegador usa el comportamiento por defecto, que suele ser block: el texto está invisible hasta que la fuente llega o hasta que pasan 3 segundos. En conexiones móviles lentas, esto significa que el usuario ve una página en blanco donde debería haber texto.
Solución: siempre añade font-display: swap en @font-face o &display=swap en la URL de Google Fonts.
3. No hacer preconnect a los dominios de fuentes
Si usas Google Fonts sin preconnect, el navegador descubre la petición a fonts.googleapis.com cuando procesa el CSS, y entonces tiene que resolver DNS, conectar TCP y negociar TLS desde cero. Esto añade cientos de milisegundos.
Solución: añade preconnect a fonts.googleapis.com y fonts.gstatic.com en el <head>.
4. Precargar demasiadas fuentes
Precargar 5 o 6 fuentes compite por el ancho de banda con otros recursos críticos como el CSS principal, la imagen LCP o el JavaScript necesario para el renderizado. El resultado puede ser peor que no precargar nada.
Solución: precarga solo 1 o 2 fuentes, las que se usan en el above the fold.
5. Usar fuentes de iconos innecesarias

Las fuentes de iconos como Font Awesome cargan un archivo de fuente completo con cientos o miles de iconos cuando probablemente usas 10 o 15. Cada icono ocupa bytes en la fuente, pero el archivo completo se descarga aunque solo uses algunos.
Solución: sustituye las fuentes de iconos por SVG inline para los iconos que uses. Un SVG inline pesa unos pocos cientos de bytes y no requiere una petición HTTP adicional.
6. No configurar la caché de fuentes
Las fuentes son recursos estáticos que rara vez cambian. Si no configuras cabeceras de caché, el navegador las vuelve a descargar en cada visita.
Solución: configura Cache-Control: public, max-age=31536000 para los archivos de fuente. Si usas un CDN, configúralo también ahí.
Cómo medir el impacto de las fuentes
Para saber si tus optimizaciones de fuentes funcionan, necesitas medir antes y después. Estas son las herramientas y técnicas más útiles.
DevTools: pestaña Network
Abre DevTools (F12), ve a la pestaña Network, filtra por «font» y recarga la página con caché desactivada. Verás:
- Qué fuentes se descargan.
- Cuánto pesa cada una.
- Cuándo empieza y termina la descarga en el waterfall.
- Si hay fuentes que se descargan pero no se usan.
Busca peticiones a fonts.googleapis.com (el CSS) y fonts.gstatic.com (los archivos de fuente). Si ves muchas peticiones a fonts.gstatic.com, probablemente estás cargando demasiadas variantes.
Lighthouse
Lighthouse tiene varias auditorías relacionadas con fuentes:
- Elimina recursos que bloquean el renderizado: si el CSS de Google Fonts se carga como stylesheet normal, aparece aquí.
- Usa formatos de imagen modernos: no aplica a fuentes, pero a veces Lighthouse sugiere WebP/AVIF para recursos que no son imágenes.
- Tiempo hasta el primer renderizado: si las fuentes bloquean el renderizado, el FCP empeora.
PageSpeed Insights te muestra los mismos datos de Lighthouse pero con datos de campo de usuarios reales (CrUX).
Chrome DevTools — pestaña Performance
Para un análisis más detallado, graba una traza de rendimiento en la pestaña Performance con throttling de red (Slow 4G) y CPU (4x). En la traza puedes ver:
- Cuándo descubre la fuente el navegador.
- Cuándo termina de descargarla.
- Si hay un FOIT o FOUT visible en las capturas de pantalla.
- Cuánto tiempo pasa el hilo principal procesando CSS de fuentes.
Métricas a vigilar
Las métricas que se ven más afectadas por las fuentes son:
- FCP (First Contentful Paint): si el CSS de fuentes bloquea el renderizado, el FCP empeora.
- LCP (Largest Contentful Paint): si el elemento LCP es texto con una fuente web que tarda en llegar, el LCP se retrasa.
- CLS (Cumulative Layout Shift): si la fuente de respaldo y la final tienen métricas diferentes, el cambio de fuente causa desplazamientos.
Mide antes de optimizar, aplica los cambios y vuelve a medir. Si no hay mejora, probablemente las fuentes no eran tu cuello de botella principal.
Conclusión y checklist
Las fuentes web son un recurso que se optimiza con pocas acciones concretas pero que, si se descuida, puede añadir segundos enteros al tiempo de renderizado. En WordPress, donde temas y plugins cargan fuentes por defecto, revisar la configuración de fuentes es una de las optimizaciones con mejor relación esfuerzo-impacto.
Lista de optimización de fuentes
- Solo declara los pesos que uses en el diseño (normalmente 400 y 700).
- Añade font-display: swap en todas las declaraciones @font-face.
- Si usas Google Fonts, añade &display=swap a la URL.
- Haz preconnect a fonts.googleapis.com y fonts.gstatic.com (con crossorigin).
- Si haces self-hosting, preload solo las fuentes del above the fold (1 o 2 como máximo).
- Elige fuentes de respaldo con métricas similares para reducir CLS.
- Considera size-adjust y font-metric-override si el CLS por fuentes es problemático.
- Sustituye fuentes de iconos por SVG inline cuando sea posible.
- Configura Cache-Control con max-age de al menos 1 año para los archivos de fuente.
- Mide antes y después con DevTools Network y PageSpeed Insights.
Recomendación final
Empieza por lo que más impacto tiene: reducir variantes, añadir font-display: swap y hacer preconnect. Estas tres acciones suelen resolver el 80 % de los problemas de rendimiento relacionados con fuentes y se aplican en minutos.
Si después de eso sigues teniendo problemas de CLS o LCP por fuentes, entonces avanza hacia self-hosting, preload y ajuste de métricas. No apliques todo de golpe: mide, cambia una cosa, vuelve a medir.
Únete a la discusión a continuación. Si tienes alguna pregunta, solicitud de soporte o notificación de errores, utiliza en su lugar nuestros canales de soporte. Antes de comentar, dedica unos minutos a revisar nuestras directrices sobre comentarios.