Por qué uso font-display: block y no swap

Todas las guías de rendimiento dan el mismo consejo, y no es que esté mal: es que no pone condiciones. En un sitio con una única tipografía autoalojada, precargada y con subconjunto, swap cambia una ganancia invisible por un salto de layout muy visible — y Core Web Vitals te cobra el salto.

Fuentes Core Web Vitals WPO

El consejo que todo el mundo repite

Lighthouse, cualquier checklist de WPO y la propia documentación de Google coinciden: usa swap, para que el texto nunca sea invisible mientras carga la fuente.

Lo que swap cuesta de verdad

Las métricas de la fuente de fallback no son las de la webfont, así que cuando se produce el cambio el texto se recoloca. Esa recolocación es un salto de layout, y acaba en tu CLS.

Por qué block gana en este sitio

block solo es seguro bajo unas condiciones que este sitio cumple: una única tipografía, autoalojada, con subconjunto latino, en woff2 y precargada en el <head>. La fuente llega en decenas de milisegundos, así que la ventana de texto invisible de la que swap protege nunca llega a abrirse — y nada se recoloca.

Cuándo optional es la decisión correcta

optional da un bloqueo de ~100 ms y, si la fuente no ha llegado, simplemente no la usa en esa visita. Ni swap, ni salto, nunca — a cambio de que parte de tus visitantes no lleguen a ver tu tipografía.

Qué medir antes de copiarme

La regla no es «block gana a swap». Es que swap es un seguro contra una fuente lenta — y un seguro que no necesitas es solo una prima que estás pagando.

Lecturas relacionadas