Saltar al contenido

Autoalojar fuentes vs CDN

Por qué Astro descarga las fuentes en el build y las sirve desde tu propio origen: el coste oculto del CDN de fuentes en privacidad y latencia, el mito de la cache compartida tras la partición por origen, el pipeline de descarga y optimización, y los directorios de cache y su vida útil.

El coste oculto del CDN de fuentes

Enlazar un CDN de fuentes parece inofensivo, pero cada visita dispara una cadena de consecuencias. El navegador debe abrir una conexión a un dominio ajeno, con su resolución DNS, su saludo TCP y su negociación TLS, antes de poder pedir un solo byte de fuente. Ese preámbulo de red, invisible en tu máquina de desarrollo rápida, se paga en cada dispositivo lento y en cada red congestionada.

Hay además un segundo coste, más silencioso. En esa petición viaja información del visitante, su dirección IP y su agente de usuario, hacia un tercero que no eligió. Leer tu texto se convierte, sin que nadie lo advierta, en un acto que expone datos a una empresa ajena a la relación entre tu sitio y tu lector.

HTML
<!-- el modelo clasico: cada visitante habla con un tercero --><link rel="preconnect" href="https://fonts.gstatic.com" crossorigin /><link href="https://fonts.googleapis.com/css2?family=Inter&display=swap" rel="stylesheet" />

Frente a esas dos líneas, el modelo de Astro no añade ningún enlace externo al documento: la familia se declara en la configuración y se emite localmente, sin que el HTML apunte jamás a otro dominio.

ASTRO
---// astro.config.mjs: ni una URL de terceros a la vistaexport default defineConfig({  fonts: [    { provider: fontProviders.google(), name: 'Inter', cssVariable: '--font-inter' },  ],});

El argumento histórico que justificaba el coste del CDN era la cache compartida: si muchos sitios enlazaban la misma fuente del mismo CDN, el navegador la descargaría una vez y la reutilizaría en todos. Ese argumento ya no es válido.

Para cerrar una vía de rastreo entre sitios, los navegadores modernos particionan la cache por origen, de modo que la fuente que un usuario descargó en un sitio no se reutiliza en el tuyo. La supuesta ventaja se evaporó, y solo quedaron los costes: los saludos de red hacia otro dominio y la fuga de datos del visitante. Con la partición de la cache, hasta las etiquetas preconnect que antes mitigaban la latencia pierden gran parte de su sentido.

El pipeline de build: descargar, optimizar, autoalojar

Cuando declaras una familia con un proveedor remoto, Astro no pospone el trabajo al navegador: lo hace una vez, en el build. El proveedor resuelve las URLs de los archivos y Astro los descarga a tu máquina de construcción, no a la del visitante.

A partir de ahí, los procesa: los optimiza según tus subsets y weights, genera las reglas @font-face que apuntan a copias locales y las emite a través del componente <Font />. En la salida, las fuentes se copian al directorio _astro/fonts con nombres que incluyen un hash de su contenido, listas para servirse como cualquier otro activo estático de tu proyecto.

TXT
dist/  _astro/    fonts/      inter-400.a1b2c3.woff2      inter-700.d4e5f6.woff2

Ese hash en el nombre es la clave de una cache agresiva. Como el nombre cambia si y solo si cambia el contenido, el archivo puede marcarse como inmutable y cachearse durante un año entero sin riesgo: mientras la fuente no cambie, ningún visitante recurrente vuelve a descargarla, y el día que la cambies, el nuevo hash fuerza la actualización automáticamente. Es la política que los activos hasheados sirven con una cabecera como esta.

HTTP
Cache-Control: public, max-age=31536000, immutable

Es lo mejor de ambos mundos, cache eterna y frescura garantizada: el visitante recurrente no paga ni un byte por fuentes que no han cambiado, y ninguna versión antigua sobrevive a una actualización real.

Los directorios de cache y su vida útil

Descargar fuentes en cada build sería lento, así que Astro cachea el trabajo. En desarrollo, las fuentes resueltas viven en .astro/fonts; en el build de producción, la cache está en node_modules/.astro/fonts.

TXT
.astro/fonts/                 # cache en desarrollonode_modules/.astro/fonts/    # cache del build de produccion

Mientras esa cache exista, las reconstrucciones no vuelven a salir a la red a por los mismos archivos, lo que hace que el segundo build y los sucesivos sean tan rápidos como si las fuentes fueran locales desde el principio.

Esto tiene una implicación operativa útil: si algo se corrompe o quieres forzar una resolución limpia, basta con borrar el directorio de cache correspondiente y volver a construir. La cache es una optimización transparente, no un estado del que dependa la corrección; puedes tirarla cuando quieras y Astro la reconstruirá.

Lo que sigues pagando

Conviene ser honesto: autoalojar no hace desaparecer los bytes, los cambia de origen. Las fuentes que antes servía el CDN del proveedor ahora las sirve tu infraestructura, así que pasas a pagar su ancho de banda y ocupan espacio en tu despliegue. Para la mayoría de sitios esto es despreciable, porque una fuente bien acotada pesa unos pocos kilobytes por variante, pero es un coste real que conviene reconocer en lugar de fingir que la fuente se volvió gratis.

Esa contabilidad explica por qué las lecciones anteriores insistían tanto en subsets, weights y font-display. El autoalojamiento te devuelve el control, y con el control, la responsabilidad de no servir de más. Un CDN te tentaba a olvidar el peso porque no lo veías salir de tu origen; tu propio dominio te obliga a mirarlo de frente. Bien entendida, esa obligación es otra ventaja disfrazada de coste: te empuja hacia la disciplina que un buen rendimiento tipográfico te exigía de todas formas.