preload y el coste real en bytes
Qué gana exactamente un preload de fuente, por qué crossorigin es obligatorio, los cuatro casos en que hace daño, y el presupuesto honesto de cada peso y estilo.
preload es la herramienta que rompe la dependencia entre el layout y la petición de la fuente: adelanta la descarga al momento en que el navegador analiza el HTML, antes de tener el CSS. Es potente y por eso es peligrosa, porque lo que hace es robar prioridad a otros recursos, y si la fuente que adelantas no era la crítica, has empeorado la carga a cambio de nada.
- Explicar qué adelanta un
preloadde fuente y cuánto puede ahorrar. - Justificar por qué el atributo
crossorigines obligatorio. - Enumerar los cuatro casos en que el preload perjudica.
- Estimar el presupuesto en bytes de una familia completa.
Qué compra el preload
<link rel="preload" href="/f/texto-latin.woff2" as="font" type="font/woff2" crossorigin>La petición sale al analizar el head, en paralelo con la descarga del CSS, en lugar de esperar a que el CSSOM esté construido y los estilos resueltos. En una conexión típica de móvil eso adelanta la fuente entre 200 y 600 milisegundos, y en una hoja de estilos grande puede ser más.
El atributo crossorigin es obligatorio, incluso para fuentes del mismo origen, y esta es la trampa que casi todo el mundo pisa una vez. Las fuentes se piden siempre en modo CORS anónimo, por razones históricas de licencias. Un preload sin crossorigin hace una petición en un modo distinto, así que el recurso que llega no coincide con el que después pide el motor de fuentes, y el navegador lo descarga otra vez. El síntoma es inconfundible: el archivo aparece dos veces en el panel de red. Si ves eso, falta el atributo.
as="font" fija la prioridad y el tipo de destino, y type permite al navegador descartar el preload si no soporta el formato.
Cuándo hace daño
Cuando la fuente no acaba usándose. Un preload descarga incondicionalmente. Si la fuente solo la usa un componente que aparece a mitad de página, o solo en una variante de un test, o solo en el modo oscuro, has gastado ancho de banda de la parte más crítica de la carga en algo que no se ve.
Cuando precargas más de lo que puedes permitirte. El preload sube la prioridad de un recurso, y las prioridades son relativas: si subes seis, no has subido ninguno. Compiten entre ellos y compiten con el CSS y con la imagen principal, que son lo que de verdad bloquea el primer pintado. La regla que funciona: como mucho dos archivos, y solo los que aparecen en el primer pantallazo.
Cuando hay unicode-range. El preload va por delante de toda la lógica de emparejamiento, así que se salta la comprobación de rango. Precargar los subconjuntos de una familia repartida en seis archivos descarga los seis, que es justo lo contrario de lo que la partición pretendía. Con subconjuntos, precarga como mucho el latino.
Cuando la fuente es de un tercero. El preload no elimina el coste de resolver el DNS ni de negociar TLS con otro dominio; solo adelanta la petición dentro de esa cadena. Ahí la herramienta correcta es preconnect al origen de las fuentes, y la solución de verdad es alojarlas tú, que elimina la conexión entera y te da control sobre las cabeceras de caché.
<!-- terceros: abre la conexion cuanto antes -->
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>El presupuesto en bytes
Los números dependen mucho del diseño de la tipografía —una fuente con muchos contornos, muchas características de OpenType o hinting extenso pesa el doble que una geométrica sencilla—, así que estos rangos son para hacer cuentas, no para citar:
| recurso | woff2 típico |
|---|---|
| subconjunto latino básico, un peso, una fuente de texto | 15 a 25 KB |
| lo mismo incluyendo latín extendido | 25 a 40 KB |
| cursiva del mismo peso | otro archivo, coste similar |
| variable con un solo eje de peso, latino básico | 35 a 60 KB |
| variable con tres o más ejes | 70 a 140 KB |
| fuente de titular con muchos glifos y características | 60 a 120 KB |
La cuenta que hay que hacer es la multiplicativa. Cuatro pesos por dos estilos son ocho archivos, y con 20 KB cada uno son 160 KB solo de tipografía, más que el JavaScript de muchos sitios. Esa multiplicación es la decisión de diseño más cara que se toma en un proyecto y normalmente se toma sin que nadie vea el número.
Tres formas de bajarla, en orden de impacto:
Quitar pesos. Una jerarquía tipográfica completa se puede construir con dos pesos si los tamaños y los espacios hacen su trabajo. Pasar de cuatro pesos a dos ahorra la mitad, y ninguna otra optimización se acerca.
Renunciar a la cursiva y aceptar la síntesis. La cursiva sintética es fea si la miras de cerca, y en un texto corrido a tamaño de lectura la mayoría de la gente no la distingue. Para un blog es un intercambio razonable; para una revista literaria no.
Recortar por bloques de escritura, con la técnica de la lección anterior.
Y la cabecera, que no cuesta nada y ahorra todas las visitas siguientes: los archivos de fuente son inmutables, así que van con el nombre versionado y con caducidad máxima.
Cache-Control: public, max-age=31536000, immutableSi tu servidor las soporta, una respuesta 103 Early Hints con la cabecera Link de preload adelanta la petición incluso antes de que empiece a llegar el HTML, mientras el servidor todavía está generando la respuesta. Es la misma técnica un escalón más arriba, y para fuentes es especialmente eficaz porque son recursos estáticos que no dependen del contenido de la página.
En casi todo lo demás, la relación entre una decisión de diseño y su coste de red es difusa: nadie sabe cuánto cuesta exactamente una sombra más o un componente más. Con las fuentes la relación es exacta y contable: cada peso son entre 15 y 25 kilobytes, cada estilo los duplica, y esos números se pueden poner encima de la mesa antes de decidir. Y sin embargo la conversación casi nunca ocurre, porque la elección tipográfica se hace en una herramienta de diseño donde todas las fuentes están instaladas y todos los pesos son gratis. El resultado es un patrón que se repite en todos los proyectos: se eligen seis pesos, se implementan seis pesos, y meses después alguien de rendimiento propone quitar cuatro y se abre una discusión política que se podría haber evitado enseñando la tabla al principio. Si trabajas en la parte técnica, el momento de aportar valor no es cuando llegan los archivos: es cuando se está eligiendo la tipografía, con una hoja donde ponga cuántos kilobytes cuesta cada fila. Casi nadie se opone a quitar un peso cuando ve el número al lado; casi todo el mundo se opone cuando ya está implementado y siente que le quitan algo.