Carga responsiva de fuentes web: una estrategia adaptada al dispositivo

Estrategia responsiva de font-display y precarga

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

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

La estrategia combina precarga responsiva con font-display: optional en escritorio (eliminando el Flash Of Unstyled Text). En móvil usa font-display: swap (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 crítica de renderizado más grande. Es decir, sitios que cargan múltiples fuentes, hojas de estilo y scripts antes del elemento LCP. Si tu sitio carga una sola fuente ligera, la complejidad añadida no vale 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 haces antes del Largest Contentful Paint retrasará 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 UX. Pero si tu sitio no logra alcanzar los umbrales de los Core Web Vitals, especialmente en ciertos tipos de dispositivos, debes 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 tu puntuación LCP. En el 76% restante de las páginas donde una imagen es el elemento LCP, las fuentes aún compiten por el ancho de banda temprano. Esto puede retrasar la carga de la imagen.

Considera el siguiente ejemplo de un periódico 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 primeros recursos de red y retrasen el tiempo de la imagen.

Comprender font-display: optional vs swap

Antes de detallar la estrategia responsiva, necesitas entender los dos valores de font-display en los que se basa. Para una visión más amplia de font-display, consulta cómo asegurar que el texto permanezca visible durante la carga de la fuente web.

font-display: swap muestra la fuente fallback inmediatamente. Luego la intercambia por la fuente personalizada cuando esta carga. Esto es genial para el LCP porque el texto es visible desde el principio. La desventaja: cuando la fuente personalizada llega y reemplaza a la fallback, las diferentes métricas de la fuente pueden causar un layout shift visible. Esto perjudica tu puntuación CLS. Cerca del 50% de los sitios usan swap, siendo el valor más popular con diferencia.

font-display: optional da al navegador unos 100ms para cargar la fuente. Si la fuente llega a tiempo (normalmente desde la caché o una precarga rápida), se usa. Si no, se usa la fuente fallback durante toda la carga de la página. Nunca ocurre un intercambio. Esto significa cero layout shifts, pero la fuente personalizada podría no mostrarse en la primera visita. Solo el 0,5% de los sitios usa optional, a pesar de ser la opción más segura para el CLS.

Desde Chrome 83, combinar font-display: optional con <link rel="preload"> bloquea el primer renderizado hasta ~100ms (con un máximo absoluto de 1500ms), esperando que llegue la fuente. Si la fuente está precargada, casi siempre llega dentro de esa ventana. El resultado: texto estilizado en el primer renderizado, cero FOUT, cero layout shifts. Por esto la parte de escritorio de la estrategia responsiva funciona tan bien.

¡La estrategia responsiva de fuentes al rescate!

En casos como este, donde hay mucha competencia temprana en la red, tiene sentido distinguir entre tipos de dispositivos. Normalmente, los dispositivos de escritorio son más rápidos. Utilizan conexiones por cable y redes más veloces. Pueden manejar más recursos de red tempranos a la vez. Por lo tanto, tiene perfecto sentido precargar algunos archivos de fuentes críticos.

Por otro lado, los dispositivos móviles pueden usarse de camino al trabajo en condiciones de red poco óptimas. Además, los móviles suelen tener CPUs más lentas y menos memoria disponible que los equipos de escritorio. Estas limitaciones indican que tratar la carga de fuentes de forma distinta según el tipo de dispositivo tiene sentido.

• Escritorio: Precargar las fuentes mejora el rendimiento de renderizado en dispositivos con mayor ancho de banda y potencia de procesamiento. Usa font-display: optional para eliminar los problemas de intercambio de fuentes. Combinado con una precarga, Chrome bloqueará brevemente el renderizado (hasta ~100ms) para esperar la fuente. Esto te da texto estilizado en el primer renderizado con cero CLS.
• Móvil: No precargues la fuente debido a la competencia en la red. Usa font-display: swap para un renderizado de texto más rápido. Este enfoque muestra las fuentes fallback inmediatamente mientras la fuente personalizada sigue cargando en segundo plano. Así ofreces una mejor experiencia en dispositivos menos potentes.

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

En lugar de cargar la fuente universalmente, puedes usar el atributo media en la etiqueta <link> del HTML junto con CSS. Esto te permite aplicar diferentes estrategias de fuentes basadas en los tipos de dispositivo.

Implementación completa

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

  <!-- Precarga la 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 asegura 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 estilizado en el primer renderizado */
    @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 precarga. El escáner de precarga 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 @font-face no caen en cascada. No puedes sobrescribir solo font-display en un segundo bloque sin volver a declarar el font face completo. El navegador descartará una regla @font-face incompleta.
3. El atributo crossorigin: Las fuentes precargadas sin crossorigin se obtendrán dos veces. Inclúyelo siempre en las precargas de fuentes, incluso para fuentes del mismo origen.
4. Coincidencia de breakpoints: El atributo media en la precarga (768px) debe coincidir con la media query de CSS (768px). Si no coinciden, precargarás en un breakpoint y aplicarás el font-display incorrecto en otro.

Reducir los layout shifts en móvil ajustando la fuente fallback

La estrategia móvil usa font-display: swap. Esto significa que habrá un breve Flash Of Unstyled Text cuando la fuente personalizada reemplace a la fallback. Puedes minimizar este salto visual usando CSS font metric overrides:

@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 te permiten igualar las dimensiones de la fuente fallback con la fuente personalizada. Cuando ocurre el intercambio, el texto apenas se mueve. Todos los navegadores modernos soportan estos descriptores. Bibliotecas como Capsize pueden calcular automáticamente los valores de override correctos para tus fuentes específicas.

Beneficios de este enfoque

• UX en escritorio: El escritorio renderiza con la fuente web en el primer renderizado. Esto previene tanto el FOUT como el FOIT. Cero layout shifts por la carga de fuentes.
• Rendimiento en móvil: font-display: swap asegura que los usuarios vean el texto inmediatamente, incluso si la fuente personalizada aún no ha cargado. No usar precarga significa que las fuentes no compiten por el ancho de banda con la imagen LCP.
• Simplicidad declarativa: Puro HTML y CSS. Sin JavaScript, sin bibliotecas de carga de fuentes y sin dependencias de frameworks. Esto también significa que funciona con cualquier estrategia de priorización de recursos que ya tengas implementada.

Impacto en el mundo real

Esta estrategia se basa en un ejemplo del mundo real que encontré al auditar un sitio de e-commerce. El sitio cargaba 3 fuentes personalizadas: una para los encabezados, otra para el cuerpo del texto y una de iconos. En escritorio todo cargaba lo suficientemente rápido como para que las fuentes rara vez causaran problemas. Pero en móvil sobre 4G, las tres precargas de fuentes competían con la imagen hero. Esto empujaba el LCP muy por encima del umbral de 2,5 segundos.

Después de implementar la estrategia responsiva (precargar solo en escritorio y eliminar las precargas de fuentes en móvil):

• Escritorio: Mejor CLS y UX gracias a las fuentes estilizadas apareciendo en el primer renderizado. La combinación de precarga + font-display: optional eliminó todos los layout shifts 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 cargó sin contención.

La investigación de DebugBear confirma el impacto: la precarga de fuentes puede mejorar el LCP en aproximadamente un 30% (de 1,82s a 1,24s) si se aplica correctamente. Pero cuando se abusa (un sitio tenía 38 fuentes precargadas), la precarga empeora las cosas. El enfoque responsivo te da el beneficio de la precarga en escritorio sin el costo en móvil.

En los sitios monitoreados por CoreDash, aproximadamente el 82% de las cargas de páginas móviles aprueban el LCP cuando las fuentes se precargan estratégicamente. Esto se compara con el 70% para las páginas que cargan todas las fuentes de la misma manera sin importar el tipo de dispositivo. En escritorio, donde la combinación precarga + optional funciona mejor, la diferencia es aún mayor.

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

Usa esta estrategia cuando:

• Tu sitio carga 2 o más archivos de fuentes personalizadas
• Móvil y escritorio tienen perfiles de rendimiento Core Web Vitals diferentes (común en sitios donde móvil tiene problemas con el LCP mientras escritorio lo aprueba)
• Las fuentes compiten con otros recursos críticos (imágenes hero, CSS crítico) en móvil
• Estás alojando tus propias fuentes (esta estrategia funciona con cualquier alojamiento de fuentes, pero alojarlas tú mismo te da control total sobre la ruta de precarga)

Evita esta estrategia cuando:

• Solo cargas una fuente WOFF2 ligera (menos de 20 KB). La sobrecarga de la carga responsiva no vale la pena.
• Tu sitio ya aprueba todos los Core Web Vitals tanto en móvil como en escritorio. No añadas complejidad a un problema que no tienes.
• Dependes de fuentes del sistema. Si ya estás usando font-family: system-ui, sans-serif, no hay nada que optimizar.

Después de implementar esta o cualquier estrategia de carga de fuentes, monitorea el impacto con Real User Monitoring para confirmar que el cambio realmente mejoró tu field data. Las pruebas de laboratorio pueden ignorar la variabilidad en las condiciones de red reales que hace valiosa a esta estrategia en primer lugar.