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.
Durante más de una década, la forma canónica de usar una fuente web fue enlazar el CDN de un proveedor: una etiqueta que apuntaba a los servidores de Google y traía la fuente en cada visita. Era cómodo y se sentía gratis, pero escondía un precio que se pagaba en privacidad, en latencia y en control. La API de fuentes de Astro toma la decisión contraria por defecto: descarga los archivos durante el build y los sirve desde tu propio origen. Esta lección examina por qué ese cambio importa y cómo funciona el pipeline que lo hace posible.
- Contrastar enlazar un CDN de fuentes con autoalojarlas desde tu origen.
- Entender el problema de privacidad y el mito de la cache compartida entre sitios.
- Seguir el pipeline de descarga y optimización de fuentes en el build.
- Ubicar los directorios de cache y su vida útil, en desarrollo y en producción.
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.
<!-- 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.config.mjs: ni una URL de terceros a la vista
export 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.
Enviar la IP de cada visitante a un CDN de fuentes no es una abstracción teórica. En varias jurisdicciones europeas, tribunales han considerado que incrustar Google Fonts desde su CDN, y con ello transmitir la IP sin consentimiento, vulnera el RGPD. Autoalojar las fuentes elimina de raíz ese flujo de datos: si los archivos se sirven desde tu propio dominio, ningún tercero recibe información de tus visitantes por el hecho de que lean tu texto.
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.
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.
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.
flowchart LR DECL[familia declarada con provider remoto] --> RES[el proveedor resuelve las URLs] RES --> DL[Astro descarga los archivos en el build] DL --> OPT[optimiza subsets y formatos] OPT --> HASH[copia a barra astro fonts con hash] HASH --> ORIG[servido desde tu propio origen] ORIG --> CACHE[cache inmutable de un ano] style DECL fill:#89b4fa,color:#11111b style ORIG fill:#a6e3a1,color:#11111b
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.
.astro/fonts/ # cache en desarrollo
node_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á.
Autoalojar tiene un beneficio menos obvio que la privacidad: la consistencia. Cuando enlazas un CDN, el archivo exacto que recibe cada visitante puede variar según su navegador, su sistema o lo que el proveedor decida servir ese día. Al descargar y congelar las fuentes en el build, garantizas que todos tus visitantes reciben exactamente los mismos archivos que tú probaste, sin sorpresas de renderizado entre plataformas. La reproducibilidad deja de depender de un tercero.
El autoalojamiento no depende de generar un sitio estático. Aunque despliegues con un adaptador y renderizado bajo demanda, las fuentes siguen siendo activos resueltos en el build: se descargan y optimizan al construir, y se sirven desde tu infraestructura como cualquier otro recurso estático. El origen de tus visitantes para las fuentes es siempre tu dominio, no el del proveedor original.
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.
Servir desde tu origen y usar una red de distribución no son opuestos. Si tu sitio ya se sirve tras un CDN propio, como el de tu plataforma de despliegue, las fuentes autoalojadas se benefician de él igual que el resto de tus activos estáticos: viajan por los mismos nodos cercanos al usuario. La diferencia con el CDN de fuentes de un tercero es de gobernanza, no de geografía; sigues siendo tú quien controla qué se sirve y qué datos se recogen, aunque los bytes lleguen desde un nodo perimetral.
Privacidad
Cero peticiones a terceros por tus fuentes. La IP del visitante no viaja a ningun CDN.
Un solo origen
Sin DNS, TCP ni TLS extra hacia otro dominio. Las fuentes salen de donde sale tu HTML.
Cache inmutable
Nombres con hash cacheables un ano. Sin redescargas para el visitante recurrente.
Cache de build
En .astro/fonts y node_modules/.astro/fonts. Borrable para forzar una resolucion limpia.
La lección más profunda de esta unidad es una estrategia que reaparece por todo Astro: cuando dos virtudes parecen enfrentadas, a menudo es porque estás haciendo el trabajo en el momento equivocado. El CDN de fuentes planteaba un dilema aparentemente irreducible: por un lado, la comodidad de escribir una línea y tener una fuente preciosa; por otro, la privacidad, la latencia y el control de servir tú mismo los archivos. Durante años se aceptó como un pacto fáustico, cambiar los datos de tus visitantes por tu propia comodidad, y elegir un lado significaba renunciar al otro. La API de fuentes de Astro no elige un lado del dilema: lo disuelve, y lo hace desplazando el trabajo en el tiempo. La comodidad del CDN venía de que otro hacía el trabajo de resolver y servir la fuente; el coste venía de que ese otro lo hacía en tiempo de ejecución, en cada visita, con los datos de cada visitante. Al mover ese mismo trabajo al build, Astro se queda con la comodidad, tú sigues escribiendo una declaración de una línea, pero elimina el coste, porque la resolución ocurre una vez, en tu máquina, sin ningún visitante involucrado. El resultado ya no es un compromiso sino una suma: la ergonomía de declarar una fuente de Google y la privacidad y el rendimiento de autoalojarla, sin renunciar a nada. Este patrón, empujar el trabajo costoso e incierto hacia el build para que el runtime quede limpio, es la misma intuición que gobierna las imágenes optimizadas, los estilos agrupados o el HTML pregenerado. Cuando lo reconoces, dejas de ver los frameworks como cajas de funciones y empiezas a verlos como respuestas a una sola pregunta: ¿qué trabajo puede hacerse antes, una vez, para que nadie tenga que pagarlo después, muchas veces?
- Declara una familia con
fontProviders.google(), construye el sitio y localiza los archivos de fuente en_astro/fontscon sus nombres hasheados. - Abre el panel de red del navegador y confirma que no se realiza ninguna petición a un dominio de Google: todas las fuentes salen de tu origen.
- Borra el directorio de cache de build,
node_modules/.astro/fonts, reconstruye y observa que Astro vuelve a resolver y descargar limpiamente. - Razona, para un proyecto europeo con requisitos de RGPD, qué implicaciones tiene el autoalojamiento frente al viejo enlace al CDN.