Conceptos básicos del rendimiento de carga de fuentes

El rendimiento de carga de fuentes se reduce a tres palancas: pedir menos archivos de fuente, hacer cada archivo más pequeño y controlar lo que el navegador muestra mientras los archivos viajan. En la práctica eso significa un conjunto disciplinado de familias y pesos, WOFF2 como único formato en la red, font-display: swap para que el texto nunca sea invisible, y un preload para el uno o dos archivos que se renderizan primero.

El orden importa más de lo que sugieren la mayoría de las guías. Los formatos y las pistas de preload son ajustes finos; la palanca más grande está aguas arriba, en el diseño: un sistema tipográfico que necesita menos fuentes. Una herramienta que compone sistemas tipográficos no tiene nada de rendimiento que ofrecer aquí —Scale Composer desde luego no lo tiene—, pero un sistema construido a partir de dos familias y cuatro pesos simplemente tiene menos que cargar que una página que acumuló fuentes una decisión a la vez, y ningún ajuste cierra esa brecha. Este artículo forma parte de nuestra guía de tipografía.

¿Qué pasa mientras se carga una fuente web?

El texto con el estilo de una fuente que aún no ha llegado pone al navegador en una posición incómoda, y históricamente ha respondido de una de dos maneras. FOIT —un destello de texto invisible— oculta el texto hasta que la fuente aterriza; el layout es estable pero el lector se queda mirando un espacio en blanco. FOUT —un destello de texto sin estilo (en realidad: de reserva)— muestra el texto de inmediato en un tipo de reserva y luego lo intercambia cuando llega la fuente web; el lector puede leer al instante, pero el intercambio puede desplazar el layout, porque el tipo de reserva y la fuente web ocupan cantidades de espacio distintas.

Ambos son síntomas de la misma brecha entre el primer pintado y la llegada de la fuente. Todo en la práctica de carga de fuentes consiste en estrechar esa brecha o en elegir, deliberadamente, qué la llena.

¿Qué hace font-display: swap y qué cuesta?

font-display: swap elige el segundo comportamiento a propósito: mostrar el texto de inmediato en el tipo de reserva e intercambiarlo cuando se cargue la fuente web. Es la respuesta estándar porque el texto invisible casi siempre es el peor fallo: un lector que puede leer el texto de reserva no ha perdido nada salvo pulido.

El coste es el intercambio en sí. Si las letras del tipo de reserva son más anchas o más estrechas que las de la fuente web, el intercambio reajusta el layout de la página: el desplazamiento que los usuarios perciben como texto que salta a mitad de lectura. La mitigación moderna es el emparejamiento de métricas: el size-adjust de CSS y sus descriptores hermanos te permiten escalar un tipo de reserva para que sus anchos renderizados se aproximen a los de la fuente web, reduciendo el intercambio hasta casi la invisibilidad. Declarar un tipo de reserva ajustado por métricas es cada vez más una práctica estándar, y cada vez más algo que generan las herramientas en lugar de hacerse a mano.

¿Por qué “menos fuentes” es la mayor optimización?

Porque con familias de fuentes estáticas —a diferencia de las fuentes variables, que llevan muchos pesos en un solo archivo— cada familia × peso × estilo que usas es un archivo aparte y una petición aparte. La cuenta crece en silencio: un equipo añade una tercera familia para una página de marketing, otro añade el peso 300 para un hero, y pronto la página pide una docena de archivos antes de que se asiente el primer párrafo.

Un presupuesto disciplinado, en números reales:

Cuatro archivos, que habitualmente se quedan bastante por debajo de los 150 KB en conjunto —los tamaños varían según la cobertura de glifos, así que trata los rangos como formas y no como cifras exactas—. La versión indisciplinada —tres familias en cuatro pesos cada una, más un par de cursivas— son catorce archivos, a menudo varios cientos de kilobytes, para una página que no se ve mejor.

La razón por la que cuatro pesos bastan es el argumento del sistema tipográfico: la jerarquía viene de una escala tipográfica —pasos de tamaño y pasos de peso trabajando juntos— y no de añadir fuentes. Una escala más dos familias más cuatro pesos en total cubre la mayoría de los productos.

Mira un sistema completo con ese presupuesto en Scale Composer — cada nivel, desde la leyenda hasta el display, extraído de dos familias y cuatro pesos, en los tamaños de una escala real. Esa es toda la factura de fuentes de la página.

¿Qué más pertenece a la lista de comprobación?

Los elementos restantes son mecánicos. La guía de buenas prácticas de fuentes de web.dev trata cada uno en profundidad; las versiones de trabajo:

2. Solo WOFF2. Todos los navegadores actuales lo admiten, y comprime bastante mejor que WOFF. No hay razón alguna en 2026 para enviar TTF, OTF o EOT a un navegador.
3. Haz preload del uno o dos archivos críticos. <link rel="preload" as="font" type="font/woff2" crossorigin> para el tipo del cuerpo (y quizá el de los titulares) inicia esas descargas antes de que se analice el CSS. Hacer preload de todo pierde el sentido: el preload es una reclamación de prioridad, y reclamar prioridad para seis archivos no la reclama para ninguno.
4. Alojamiento propio o alojado en Google: ambos están bien. El argumento clásico a favor del CDN de Google —que una fuente cacheada en un sitio se reutilizaría en el tuyo— caducó cuando los navegadores particionaron sus cachés HTTP por sitio. El alojamiento propio te da control de versiones, preloads del mismo origen y una dependencia de terceros menos; el alojamiento de Google te da comodidad y creación automática de subconjuntos. Elige por control o por comodidad, no por el mito de la caché.
5. Crea subconjuntos si tu cadena de herramientas lo permite. Un archivo de fuente que lleva sistemas de escritura que tu producto nunca renderiza es peso muerto. La API CSS de Google ya sirve subconjuntos por sistema de escritura mediante unicode-range; si usas alojamiento propio, la creación de subconjuntos pasa a ser tu tarea, y existen herramientas para ello.

Carga menos diseñando de forma más ajustada

Ejecuta la lista de comprobación en orden y el primer elemento hace la mayor parte del trabajo: menos familias y pesos es una decisión de diseño con un beneficio mayor que cualquier ajuste de paso de compilación que venga después. El presupuesto más ajustado de todos —salvo no cargar ninguna fuente— es una sola familia. Prueba la versión de una sola familia del sistema — una jerarquía completa a partir de una única familia y cuatro pesos, con la jerarquía sostenida solo por el tamaño y el peso: la factura de fuentes más pequeña dentro de la que cabe un sistema tipográfico completo.