Las fuentes web afectan dos métricas: pueden retrasar el primer renderizado si su hoja de estilos bloquea la carga, y pueden provocar saltos de diseño (CLS) cuando el texto cambia de tamaño al reemplazar la fuente de respaldo. Optimizarlas exige medir en datos de campo: una mejora en laboratorio no siempre se traduce en una mejor experiencia real. Lo comprobamos en una prueba propia.
Nuestra prueba (tres sitios propios)
En octubre de 2026 probamos cargar la hoja de estilos de Google Fonts y de Font Awesome sin bloquear el renderizado (con el patrón media=print y onload). En una prueba de laboratorio local, la puntuación móvil de una página subió de 63 a 96 y el LCP bajó de 6,2 a 1,2 s. En producción, medido con Lighthouse en la misma página, la puntuación no mejoró de forma sostenida (entre 54 y 65) y el CLS aumentó: una página pasó de 0 a 0,055 y la portada de otro sitio de 0,006 a 0,183. Revertimos el cambio. Es un caso propio y limitado, no una regla general, pero muestra por qué hay que medir en vivo.
Opciones para mejorar fuentes
- Autoalojar las fuentes (evitas una conexión extra a un tercero) y servir solo los pesos y subconjuntos necesarios, en formato WOFF2.
- font-display: controla cómo se muestra el texto mientras carga la fuente; «swap» muestra texto enseguida pero puede producir salto.
- Precarga de la fuente principal con rel=preload cuando se usa en el contenido visible.
- Ajustar métricas de la fuente de respaldo (size-adjust, ascent-override) para que el cambio produzca un salto mínimo.
- Reducir variantes (pesos y estilos) y usar fuentes del sistema cuando sea posible.
Cómo medir sin engañarte
Usa datos de campo en Search Console y en PageSpeed Insights cuando haya volumen, y compara el CLS antes y después de cada cambio con la misma página y dispositivo. Las definiciones de las métricas están en web.dev. Lee Core Web Vitals con datos de campo para el método completo.
Cómo aplicar un cambio con seguridad
- Haz el cambio en una sola plantilla y mide.
- Guarda la versión anterior para revertir.
- Revisa el CLS en varias páginas y dispositivos.
- Documenta los resultados, incluso los negativos.
Qué recomendamos a un cliente
Prioriza autoalojar y reducir variantes; usa precarga solo para lo crítico; ajusta la fuente de respaldo para minimizar el salto; y evita aplicar trucos genéricos sin medir. Si el sitio es WordPress, combina con mejorar el LCP en WordPress.
Un ejemplo práctico (ilustrativo)
Antes de generalizar una optimización de fuentes, la agencia la prueba en una sola plantilla, compara el CLS en datos de campo y revierte si empeora, tal como ocurrió en la prueba descrita arriba. Es un escenario hipotético para ilustrar el método, no un caso real ni una promesa de resultados.
Optimización de fuentes
- Reducir variantes.
- Autoalojar en WOFF2.
- font-display definido.
- Precarga solo de lo crítico.
- Ajuste de métricas de respaldo.
- Medición de campo.
- Plan de reversión.
¿Cómo puede ayudarte RankPro con esto?
RankPro mide el efecto de cada optimización de velocidad en datos reales antes de darla por buena, y te entrega informes con el antes y el después.
Preguntas frecuentes
¿Es malo usar Google Fonts?
No; el impacto depende de cómo se cargan y cuántas variantes uses.
¿font-display: swap siempre ayuda?
Muestra texto rápido, pero puede provocar salto; ajusta la fuente de respaldo.
¿Autoalojar siempre mejora?
Suele reducir conexiones externas, pero mide en tu caso.
¿Por qué la prueba local dio mejor resultado que producción?
El laboratorio local no reproduce la red, los terceros ni el uso real.