Carga de fuentes web responsiva: una estrategia consciente del dispositivo

Estrategia de visualización de fuentes responsiva y preloading responsivo

Como especialista en Core Web Vitals, veo diferentes soluciones creativas todos los días. La mayoría no tiene mucho sentido, pero de vez en cuando me encuentro con una estrategia que es tan simple y elegante que realmente tiene sentido para ciertos sitios.

Según el Web Almanac 2025, el 88% de los sitios web utilizan fuentes web, cargando una mediana de 4 archivos de fuentes por página. Sin embargo, solo el 12% de los sitios realizan un preload de las fuentes, y apenas un 0,5% utiliza font-display: optional. La mayoría de los sitios tratan la carga de fuentes como un problema de talla única. Este artículo explica un enfoque más inteligente: cargar las fuentes de manera diferente para escritorio y móvil.

La estrategia combina el preloading responsivo con font-display: optional en escritorio (eliminando el Flash Of Unstyled Text) y font-display: swap en móvil (priorizando el renderizado rápido del texto sobre la consistencia visual).

Última revisión por Arjen Karel en marzo de 2026

consejo: esta estrategia funciona bien para sitios con una ruta de renderizado crítica extensa, es decir, sitios que cargan múltiples fuentes, hojas de estilo y scripts antes del elemento LCP. Si su sitio carga una sola fuente ligera, la complejidad añadida no merece la pena.

El problema con la carga temprana de fuentes

Al optimizar los Core Web Vitals, hay una regla simple que siempre se aplica:
"Todo lo que haga antes del Largest Contentful Paint ralentizará ese Largest Contentful Paint".

Este principio también se aplica a las fuentes web. Priorizar la carga de fuentes web durante la carga de la página puede mejorar la experiencia del usuario, pero si su sitio tiene dificultades para cumplir con los umbrales de Core Web Vitals, especialmente para tipos de dispositivos específicos, es posible que deba equilibrar la UX frente a la mejora del LCP.

El capítulo de rendimiento del Web Almanac 2025 muestra que el texto es el elemento LCP en casi el 24% de las páginas móviles. Cuando el texto es el elemento LCP, la estrategia de carga de fuentes afecta directamente a su puntuación de LCP. En el 76% restante de las páginas donde una imagen es el elemento LCP, las fuentes siguen compitiendo por el ancho de banda de red inicial y pueden retrasar la carga de la imagen.

Consideremos el ejemplo siguiente de un sitio de periódicos holandés. En un dispositivo móvil, se ponen en cola 3 fuentes antes del elemento LCP. Esto hace que las 3 fuentes compitan por los recursos de red iniciales y retrasen el tiempo de la imagen.

Entendiendo font-display: optional vs swap

Antes de profundizar en la estrategia responsiva, debe comprender los dos valores de font-display en los que se basa. Para una visión más amplia de font-display, consulte cómo garantizar que el texto permanezca visible durante la carga de webfonts.

font-display: swap muestra la fuente de respaldo (fallback) inmediatamente e intercambia la fuente personalizada una vez que se carga. Esto es excelente para el LCP porque el texto es visible desde el principio. La desventaja: cuando llega la fuente personalizada y reemplaza a la de respaldo, las diferentes métricas de la fuente pueden causar un cambio de diseño visible, perjudicando su puntuación de CLS. Aproximadamente el 50% de los sitios utilizan swap, lo que lo convierte, con diferencia, en el valor más popular.

font-display: optional le da al navegador aproximadamente 100ms para cargar la fuente. Si la fuente llega a tiempo (normalmente desde la caché o un preload rápido), se utiliza. Si no, se utiliza la fuente de respaldo para toda la carga de la página y nunca se produce un intercambio. Esto significa cero cambios de diseño, pero la fuente personalizada puede no mostrarse en la primera visita. Solo el 0,5% de los sitios utilizan optional, a pesar de ser la opción más segura para el CLS.

Desde Chrome 83, la combinación de font-display: optional con <link rel="preload"> bloquea el primer renderizado (first paint) hasta ~100ms (con un máximo absoluto de 1500ms), esperando a que llegue la fuente. Si se realiza un preload de la fuente, casi siempre llega dentro de ese intervalo. El resultado: texto con estilo en el first paint, cero FOUT, cero cambios de diseño. Es por esto que la parte de escritorio de la estrategia responsiva funciona tan bien.

¡Estrategia de fuentes responsiva al rescate!

En casos como este, donde hay mucha competencia de red temprana, tiene sentido distinguir entre tipos de dispositivos. Normalmente, los dispositivos de escritorio más rápidos con conexiones por cable (y conexiones de red más veloces) pueden manejar más recursos de red tempranos a la vez y tiene todo el sentido del mundo realizar un preload de algunos archivos de fuentes críticos.

Los dispositivos móviles, por otro lado, podrían usarse en el trayecto al trabajo bajo condiciones de red menos que óptimas. Los dispositivos móviles también suelen tener CPUs más lentas y menos memoria disponible en comparación con los ordenadores de escritorio. Estas limitaciones significan que tratar la carga de fuentes de manera diferente según el tipo de dispositivo puede tener sentido.

• Escritorio: El preloading de fuentes mejora el rendimiento de renderizado en dispositivos con mejor ancho de banda y potencia de procesamiento. Utilice font-display: optional para eliminar los problemas de intercambio de fuentes. Combinado con un preload, Chrome bloqueará brevemente el renderizado (hasta ~100ms) para esperar a la fuente, ofreciéndole texto con estilo en el first paint con cero CLS.
• Móvil: No realice un preload de la fuente debido a la competencia de red. Utilice font-display: swap para un renderizado de texto más rápido. Este enfoque muestra las fuentes de respaldo inmediatamente mientras la fuente personalizada continúa cargándose en segundo plano, ofreciendo una mejor experiencia en dispositivos menos potentes.

Implementación usando <link rel="preload"> y media queries

En lugar de cargar la fuente de forma universal, puede utilizar el atributo media en la etiqueta <link> del HTML junto con CSS para aplicar diferentes estrategias de fuentes basadas en los tipos de dispositivos.

Implementación completa

<head>
  <!-- la meta viewport DEBE ir antes de los preloads condicionales por media -->
  <meta name="viewport" content="width=device-width, initial-scale=1">

  <!-- Preload de fuente solo para escritorio -->
  <link rel="preload" href="/fonts/custom-font.woff2"
        as="font" type="font/woff2" crossorigin
        media="(min-width: 768px)">

  <style>
    \/* Móvil: swap garantiza un renderizado de texto rápido *\/    @font-face {
        font-family: 'CustomFont';
        src: url('/fonts/custom-font.woff2') format('woff2');
        font-display: swap;
    }

    \/* Escritorio: optional + preload = texto con estilo en el first paint *\/    @media (min-width: 768px) {
        @font-face {
            font-family: 'CustomFont';
            src: url('/fonts/custom-font.woff2') format('woff2');
            font-display: optional;
        }
    }

    body {
        font-family: 'CustomFont', sans-serif;
    }
  </style>
</head>

Algunos detalles importantes sobre esta implementación:

1. Orden de la etiqueta meta viewport: La etiqueta <meta name="viewport"> debe aparecer antes del enlace de preload. El preload scanner del navegador evalúa el atributo media antes de analizar otras etiquetas meta. Si el viewport no está configurado, la media query se evaluará con las dimensiones incorrectas en dispositivos móviles.
2. Declaraciones @font-face completas: Cada bloque @font-face debe incluir tanto font-family como src. A diferencia de las propiedades CSS normales, los descriptores de @font-face no se aplican en cascada. No puede sobrescribir solo font-display en un segundo bloque sin volver a declarar la fuente completa. El navegador descartará una regla @font-face incompleta.
3. El atributo crossorigin: Las fuentes con preload sin crossorigin se descargarán dos veces. Inclúyalo siempre en los preloads de fuentes, incluso para fuentes del mismo origen.
4. Coincidencia de breakpoints: El atributo media en el preload (768px) debe coincidir con la media query de CSS (768px). Si no coinciden, realizará el preload en un breakpoint y aplicará el font-display incorrecto en otro.

Reduciendo los cambios de diseño en móvil con el emparejamiento de fuentes de respaldo

La estrategia móvil utiliza font-display: swap, lo que significa que habrá un breve Flash Of Unstyled Text cuando la fuente personalizada reemplace a la de respaldo. Puede minimizar este salto visual utilizando sobrescrituras de métricas de fuentes CSS:

@font-face {
    font-family: 'CustomFont Fallback';
    src: local('Arial');
    ascent-override: 105%;
    descent-override: 25%;
    size-adjust: 97%;
}

body {
    font-family: 'CustomFont', 'CustomFont Fallback', sans-serif;
}

Los descriptores ascent-override, descent-override y size-adjust le permiten hacer coincidir las dimensiones de la fuente de respaldo con la fuente personalizada. Cuando ocurre el intercambio, el texto apenas se mueve. Estos descriptores son compatibles con todos los navegadores modernos. Bibliotecas como Capsize pueden calcular automáticamente los valores de sobrescritura adecuados para sus fuentes específicas.

Beneficios de este enfoque

• UX de escritorio: El escritorio renderiza con la fuente web en el first paint, evitando tanto el FOUT como el FOIT. Cero cambios de diseño por la carga de fuentes.
• Rendimiento móvil: font-display: swap garantiza que los usuarios vean el texto inmediatamente, incluso si la fuente personalizada aún no se ha cargado. La ausencia de preload significa que las fuentes no compiten con la imagen LCP por el ancho de banda.
• Simplicidad declarativa: HTML y CSS puros. Sin JavaScript, sin bibliotecas de carga de fuentes, sin dependencias de frameworks. Esto también significa que funciona con cualquier estrategia de prioritización de recursos que ya tenga implementada.

Impacto en el mundo real

Esta estrategia se basa en un ejemplo del mundo real que encontré al auditar un sitio de comercio electrónico. El sitio cargaba 3 fuentes personalizadas: una fuente para encabezados, una fuente para el cuerpo y una fuente de iconos. En escritorio, todo cargaba lo suficientemente rápido como para que las fuentes rara vez causaran problemas. Pero en móvil a través de 4G, los tres preloads de fuentes competían con la imagen hero y empujaban el LCP muy por encima del umbral de 2,5 segundos.

Después de implementar la estrategia responsiva (preloading solo en escritorio, eliminando los preloads de fuentes en móvil):

• Escritorio: Mejora del CLS y la UX con fuentes estilizadas que aparecen en el first paint. La combinación de preload + font-display: optional eliminó todos los cambios de diseño relacionados con las fuentes.
• Móvil: First Contentful Paint y Largest Contentful Paint más rápidos porque las fuentes ya no competían por el ancho de banda temprano. La imagen hero se cargó sin competencia.

La investigación de DebugBear confirma el impacto: el preloading de fuentes puede mejorar el LCP en aproximadamente un 30% (de 1,82s a 1,24s) cuando se aplica correctamente. Pero cuando se usa en exceso (un sitio tenía 38 fuentes con preload), el preloading empeora las cosas. El enfoque responsivo le brinda el beneficio del preloading en escritorio sin el coste en móvil.

En los sitios monitorizados por CoreDash, aproximadamente el 82% de las cargas de páginas móviles pasan el LCP cuando las fuentes se pre-cargan estratégicamente, en comparación con el 70% de las páginas que cargan todas las fuentes de la misma manera independientemente del tipo de dispositivo. En escritorio, donde la combinación de preload + optional funciona mejor, la brecha es aún mayor.

Cuándo usar esta estrategia (y cuándo no)

Utilice esta estrategia cuando:

• Su sitio cargue 2 o más archivos de fuentes personalizadas
• El móvil y el escritorio tengan diferentes perfiles de rendimiento de Core Web Vitals (común en sitios donde el móvil tiene dificultades con el LCP mientras que el escritorio lo supera)
• Las fuentes compitan con otros recursos críticos (imágenes hero, CSS crítico) en móvil
• Usted esté auto-alojando sus fuentes (esta estrategia funciona con cualquier alojamiento de fuentes, pero el auto-alojamiento le da un control total sobre la ruta de preload)

Omita esta estrategia cuando:

• Solo cargue una fuente WOFF2 ligera (menos de 20 KB). La sobrecarga de la carga responsiva no merece la pena.
• Su sitio ya supere todos los Core Web Vitals tanto en móvil como en escritorio. No añada complejidad a un problema que no tiene.
• Dependa de fuentes del sistema. Si ya está utilizando font-family: system-ui, sans-serif, no hay nada que optimizar.

Después de implementar esta o cualquier estrategia de carga de fuentes, monitorice el impacto con Real User Monitoring para confirmar que el cambio realmente mejoró sus datos de campo. Las pruebas de laboratorio pueden pasar por alto la variabilidad en las condiciones reales de red que hace que esta estrategia sea valiosa en primer lugar.