Rendimiento de fuentes web en 2026: subset, self-host, swap

Al terminar este método tu sitio sirve su tipografía como archivo WOFF2 con subset, en primera parte, con un fallback ajustado para que, en cuanto llega la fuente real, nada en la página se mueva. Esa es la diferencia entre un Largest Contentful Paint por debajo de 1,5 segundos y otro que se va más allá de 3 mientras el navegador se bloquea esperando una petición de fuente.

Las fuentes son uno de los costes de rendimiento más ignorados de la web. Una sola familia sin optimizar añade 500KB a una página y retrasa varios segundos la aparición del texto legible (web.dev). Tras los core updates de Google de 2026, los Core Web Vitals dejaron de ser un desempate blando, así que una fuente lenta o inestable hoy es un coste en posiciones y en conversión, no una nota estética. Esta es la secuencia exacta que seguimos en cada SaaS con Next.js que publicamos.

Qué necesitas antes de empezar

• Los archivos de la fuente en un formato de origen (TTF u OTF), o una licencia que permita el self-host. Revisa la licencia primero: no todas las fundiciones permiten el self-host.
• Un paso de build o una CDN que controles para servir los recursos estáticos.
• Una forma de medir: Chrome DevTools, Lighthouse y una herramienta de datos de campo (nosotros usamos DebugBear o el Chrome UX Report).

Paso 1: audita lo que cargas de verdad

Abre el panel Network, filtra por fuente y recarga. La mayoría de los sitios pide de cuatro a ocho archivos de fuente y usa dos. Cada peso y estilo que cargas es una descarga aparte en la ruta crítica. Anota las familias, los pesos y los estilos que aparecen en el texto realmente renderizado, no los que están definidos en el CSS por si acaso. Esa lista corta es lo único que vas a publicar.

Paso 2: sirve WOFF2, y nada más

WOFF2 usa compresión Brotli y pesa alrededor de un 30% menos que el formato WOFF antiguo, con soporte en todos los navegadores publicados en los últimos años (web.dev). En 2026 no hay motivo para acompañarlo de TTF, EOT o WOFF. Un formato, una petición por cada corte.

Paso 3: decide variable o estática, luego haz el subset

Una fuente variable guarda todos los pesos y estilos en un solo archivo mediante datos de interpolación, así que pesa más que un peso estático suelto (entre 1,5 y 2,5 veces) pero mucho menos que la colección que reemplaza. Si tu diseño usa tres pesos o más, un único WOFF2 variable de 100 a 200KB suele ganar a 6 o 12 archivos estáticos que suman 400-800KB, y recorta la carga a la mitad o más. Si usas exactamente un peso, gana un archivo estático con subset.

Luego haz el subset. Quita cada glifo que no renderizas. Un sitio solo en latino no necesita cirílico, griego ni el rango completo de símbolos. Hacer el subset con una herramienta como glyphhanger, subfont o fonttools reduce un archivo un 80% o más. Haz un subset por idioma cuando sirves varios y deja que el navegador elija el archivo correcto con unicode-range.

Paso 4: self-host, en primera parte, con una CDN delante

Lleva los archivos a una infraestructura que controles. El self-host quita una conexión de terceros (el lookup DNS, el handshake TLS y el viaje de ida y vuelta a fonts.gstatic.com que cuesta un enlace a Google Fonts) y convierte cada petición de fuente en primera parte. También cierra una cuestión de RGPD, porque una CDN de fuentes de terceros ve las direcciones IP de tus visitantes, un punto sobre el que los tribunales alemanes ya se han pronunciado. El self-host no significa renunciar a una CDN: pon tu propia CDN delante del origen para que los archivos queden en caché cerca de los usuarios. El origen es tuyo, la CDN es el acelerador.

Paso 5: haz preload de la única fuente above the fold

Añade un solo <link rel="preload" as="font" type="font/woff2" crossorigin> para el corte que usa el primer texto visible. Le dice al navegador que lo descargue pronto en vez de descubrirlo al fondo del CSS. Haz preload de un archivo, no de cinco: saturar la cola de preload empuja hacia atrás recursos más importantes. El atributo crossorigin es obligatorio incluso para fuentes del mismo origen, y omitirlo es el motivo más común de que un preload no haga nada en silencio.

Paso 6: configura font-display por rol

font-display controla lo que muestra el navegador mientras carga una fuente. Aplícalo por rol, no de forma global.

• swap para el peso principal del cuerpo, para que el texto se vea de inmediato en un fallback y cambie a la fuente real cuando esté lista. El texto nunca queda invisible.
• optional para un corte con preload: el navegador usa la fuente solo si llega casi al instante y, si no, mantiene el fallback toda la sesión. Así el salto por swap desaparece en ese corte.
• fallback para los pesos secundarios: un breve periodo de bloqueo y luego un fallback permanente en conexiones lentas.

Paso 7: elimina el salto por swap con overrides de métricas

El cambio de fallback a web font provoca salto de layout cuando las dos fuentes tienen métricas distintas. Se arregla en el CSS. Declara un @font-face de fallback que apunte a una fuente del sistema local y corrige sus métricas para igualarlas a tu web font con size-adjust, ascent-override, descent-override y line-gap-override. Estos descriptores forman parte de CSS Fonts Level 4 y son baseline desde 2023 (MDN). Bien ajustado, el fallback ocupa el mismo espacio y el swap no mueve nada. En Next.js, next/font genera automáticamente estas métricas de fallback corregidas y aloja los archivos en self-host durante el build (documentación de Next.js), lo que cubre por ti los pasos 4, 5 y casi todo el 7.

Paso 8: cachea en serio

Los archivos de fuente cambian rara vez. Sírvelos con un Cache-Control: max-age largo (un año es lo estándar) y un hash de contenido en el nombre del archivo, para que una versión nueva invalide la caché de forma limpia. Un visitante que vuelve no debería descargar dos veces el mismo corte.

Cómo comprobar que funciona

Recarga con caché en frío y vigila tres números. En Lighthouse, confirma que no aparece el aviso "Ensure text remains visible during webfont load". En el panel Network, confirma un WOFF2 por corte y un preload que se dispara pronto. En los datos de campo (Chrome UX Report o DebugBear), confirma que el Cumulative Layout Shift se mantiene por debajo de 0,1 y que ningún salto se atribuye al texto. Si el CLS sigue moviéndose al cargar la fuente, tus métricas de fallback están mal, así que vuelve al paso 7.

Fallos comunes y cómo corregirlos

• El preload no hace nada. Falta el atributo crossorigin, así que el navegador trata el preload y la petición real como dos descargas distintas y baja la fuente dos veces.
• El texto parpadea invisible (FOIT). font-display está en su valor por defecto auto. Pon swap en el corte del cuerpo.
• La fuente variable pesa más, no menos. Estás sirviendo un solo peso. Haz el subset de un archivo estático.
• Un tercero se cuela de nuevo. Un @import de Google Fonts olvidado en una hoja de estilos vuelve a añadir la conexión que habías quitado. Busca fonts.googleapis.com antes de publicar.
• CLS al cargar. Las métricas de fallback no están ajustadas. Añade size-adjust y los descriptores de override del paso 7.

Para profundizar

Las fuentes son un ingrediente de los Core Web Vitals; para el resto mira cómo llegamos al verde en Core Web Vitals con Next.js. Los overrides de métricas del paso 7 se apoyan en las funciones CSS que cubre el CSS moderno en 2026. Y servir la tipografía en primera parte sigue la misma lógica que quitar Tailwind de producción: menos terceros, más control sobre lo que se publica.