Entender y optimizar precios de redes de entrega de contenido

Tim Koschützki

Cofundador · Berlín, Alemania · Mostrar bio

Las redes de entrega de contenido (CDN) son esenciales para optimizar el rendimiento de aplicaciones y sitios web en el panorama digital global actual. Sin embargo, entender los modelos de precios que hay detrás de las CDN puede ser complejo. Esta guía desglosa las estructuras de precios actuales de las CDN, analiza los principales factores de costo y ofrece estrategias prácticas para optimizar tus gastos de CDN.

¿Qué es una CDN?

Una red de entrega de contenido es un grupo distribuido de servidores ubicados estratégicamente por todo el mundo para entregar contenido de forma rápida y confiable. Al almacenar en caché los recursos más cerca de los usuarios finales, las CDN reducen la latencia, acortan los tiempos de carga y mejoran la experiencia general del usuario.

Panorama de los modelos de precios de CDN

Los proveedores de CDN suelen ofrecer varios modelos de precios para adaptarse a distintas necesidades. Las listas de tarifas cambian con la frecuencia suficiente como para que cualquier tabla impresa aquí te induzca a error en cuestión de meses, así que lo que sigue es la forma de cada modelo junto con la página que contiene las cifras autorizadas:

Consulta las cifras actuales directamente (enlaces verificados en septiembre de 2026): planes de Cloudflare⁠, precios de Amazon CloudFront⁠, precios de Fastly⁠ y precios de Akamai⁠. La mayoría de los proveedores también publica una calculadora, que le gana a cualquier tabla estática para estimar tu propia factura.

Factores clave que influyen en los costos de CDN

Ancho de banda y transferencia de datos

El uso del ancho de banda suele ser el mayor componente de los gastos de CDN. Los archivos multimedia de alta resolución, las descargas de archivos grandes y los servicios de streaming pueden disparar los costos de transferencia de datos. Todo proveedor con medición cobra además una tarifa por GB distinta según la región de entrega, y la diferencia es lo bastante amplia como para cambiar un presupuesto. Cualquier porcentaje citado aquí estaría desactualizado para cuando lo leas, así que toma el desglose regional de la propia lista de tarifas: tanto los precios de CloudFront⁠ como los precios de Fastly⁠ publican una tabla por región (verificado en septiembre de 2026).

Distribución geográfica

Los costos de entrega varían según la ubicación geográfica debido a las diferencias en infraestructura y gastos operativos. Entender la distribución geográfica de tu audiencia puede ayudarte a optimizar la ubicación de los servidores y las estrategias de enrutamiento, lo que en última instancia reduce los costos.

Conjuntos de funciones y seguridad

Los proveedores de CDN modernos agrupan funciones avanzadas de seguridad y rendimiento que pueden afectar los precios. Muchos ya ofrecen aprovisionamiento gratuito y automatizado de certificados SSL/TLS, protección robusta contra DDoS en la capa 7 y opciones integradas de firewall de aplicaciones web (WAF). Estas funciones refuerzan la seguridad sin perjudicar el rendimiento.

Computación en el borde y funciones modernas

Muchas CDN ya incorporan capacidades de computación en el borde, lo que permite el procesamiento de datos en tiempo real y funciones serverless en el borde de la red. Este enfoque te deja ejecutar código personalizado más cerca de tus usuarios, optimizando de forma dinámica la entrega de contenido mientras reduces la latencia.

Transformar los bytes de una imagen dentro de la propia función edge es la versión tentadora de esto, y también la cara: pagas tiempo de CPU en cada solicitud y el resultado es incómodo de almacenar en caché porque depende de un encabezado de la solicitud y no de la URL. El arreglo más barato pone la variante en la URL. Tu origen o tu paso de compilación publica /images/w/320/photo.avif junto a /images/w/1024/photo.avif, y lo único que queda es elegir cuál pedir. Este ejemplo de Node.js usa negotiator (npm install negotiator) para respetar los rangos de medios, las preferencias de calidad y los rechazos explícitos de formato en el encabezado Accept de la solicitud:

import Negotiator from 'negotiator'

// URL selection only. This converts nothing: your origin (or your build step)
// must already publish /images/w/320/... and /images/w/1024/... in each format,
// and your templates have to request the URL this returns. Because width and
// format land in the path, they are part of the cache key with no negotiation.
const WIDTHS = new Map([
  ['small', '320'],
  ['large', '1024'],
])
const SOURCE_EXTENSION = /\.(jpe?g|png)$/i
const PUBLIC_PREFIX = '/images/'
const VARIANT_PREFIX = '/images/w/'

function buildVariantUrl(requestUrl, accept) {
  const url = new URL(requestUrl)

  // Rewrite only the prefix that is public and has variants published under it,
  // and never rewrite a variant URL again: /w/1024/w/1024/... does not exist.
  if (!url.pathname.startsWith(PUBLIC_PREFIX)) return null
  if (url.pathname.startsWith(VARIANT_PREFIX)) return null

  const extension = url.pathname.match(SOURCE_EXTENSION)?.[1].toLowerCase()
  if (extension === undefined) return null

  // Prefer the original format when the client only offers a wildcard. Do not
  // turn a PNG into JPEG (losing alpha), or select a format rejected with q=0.
  const formats = new Map([
    [extension === 'png' ? 'image/png' : 'image/jpeg', extension],
    ['image/avif', 'avif'],
    ['image/webp', 'webp'],
  ])
  const accepted = new Negotiator({ headers: { accept: accept ?? '*/*' } }).mediaType([
    ...formats.keys(),
  ])
  const format = formats.get(accepted)
  if (format === undefined) return null

  // A Map, so an unexpected ?w= value cannot reach an inherited object key such
  // as 'constructor' and produce a width the origin never published.
  const width = WIDTHS.get(url.searchParams.get('w')) ?? WIDTHS.get('large')
  const name = url.pathname.slice(PUBLIC_PREFIX.length).replace(SOURCE_EXTENSION, `.${format}`)

  const variant = new URL(url)
  variant.pathname = `${VARIANT_PREFIX}${width}/${name}`
  // Drop the query string outright. Nothing in it changes these bytes, and a
  // surviving ?utm_source= would fragment the cache once per campaign.
  variant.search = ''
  return variant.toString()
}

Ten claro qué es y qué no es. Es selección de URL, así que corresponde a donde construyas las URL de imágenes: un helper de plantillas, un paso de compilación o una función edge que responda con una redirección. No codifica una imagen ni despliega nada en un proveedor. El origen todavía tiene que generar y servir cada variante, y el frontend todavía tiene que solicitar la URL devuelta, porque eso es lo que introduce el ancho y el formato en la clave de caché.

La alternativa, servir una sola URL y marcarla como Vary: Accept, es más débil de lo que parece. Cloudflare documenta el almacenamiento en caché por variante de una respuesta de imagen con Vary: Accept como una función aparte, Vary for Images⁠, listada como disponible en Pro, Business y Enterprise y no en Free (verificado en septiembre de 2026). Así que el encabezado por sí solo no es lo que te consigue entradas de caché por formato; comprueba qué hacen realmente tu propio plan y tu proveedor antes de confiar en ello. Mantener el formato en la ruta no necesita ningún ajuste de ese tipo en ninguna parte.

La lección de costos se generaliza: cada byte que reescribe una función edge es tiempo de CPU que se te factura, y una respuesta cuyo contenido depende de un encabezado de la solicitud es una respuesta que tu CDN quizá se niegue del todo a almacenar en caché.

Implementar un almacenamiento en caché eficaz

Un almacenamiento en caché eficaz minimiza las transferencias de datos innecesarias y reduce los costos totales de CDN. Dos reglas hacen la mayor parte del trabajo, y ambas son más acotadas que «almacena en caché los recursos estáticos durante mucho tiempo».

Primero, una vida útil de immutable de un año solo es segura cuando la URL cambia cada vez que cambian los bytes. Las herramientas de compilación te dan eso gratis mediante hashes de contenido como app.7f3a91c2.js. Aplicar el mismo encabezado a /logo.png significa que algún nodo perimetral seguirá sirviendo el logotipo del año pasado, y no hay forma de revocarlo.

Segundo, decide si algo se puede almacenar en caché a partir de la ruta, nunca a partir de la extensión del archivo. /account/avatar.jpg y /api/private.css terminan ambas en una extensión que una regla ingenua considera estática, y ambas pueden transportar bytes que pertenecen a un único usuario con sesión iniciada. Adjuntar la política al punto de montaje que sirve la salida de tu compilación vuelve irrepresentable ese error:

npm install express
npm pkg set type=module

// server.js - run with: node server.js
import express from 'express'

// A content hash in the filename is what makes 'immutable' safe: the URL is a
// promise that these bytes never change.
const FINGERPRINTED = /\.[0-9a-f]{8,}\.(?:css|js|jpe?g|png|gif|webp|avif|woff2?)$/

function cacheControlFor(filePath) {
  if (FINGERPRINTED.test(filePath)) return 'public, max-age=31536000, immutable'

  // Unversioned build output: let the edge serve it, but revalidate every hour
  // so a replaced file is picked up in an hour rather than in a year.
  return 'public, max-age=3600, stale-while-revalidate=86400'
}

const app = express()

// Everything under dist/assets is build output, so it is public by
// construction. setHeaders runs once the file has been resolved, which is why
// filePath is the real path rather than a guess made before routing.
app.use(
  '/assets',
  express.static('dist/assets', {
    setHeaders: (res, filePath) => {
      res.setHeader('Cache-Control', cacheControlFor(filePath))
    },
  }),
)

// Anything the mount did not serve is private until proven otherwise, including
// a 404 for a missing asset and every error below.
app.use((_req, res, next) => {
  res.setHeader('Cache-Control', 'no-store')
  next()
})

app.get('/account/avatar.jpg', (_req, res) => {
  // Per-user bytes in a real app. The point here is the header above: the path
  // ends in .jpg, and it still must not reach a shared cache.
  res.type('jpg').send('per-user bytes')
})

app.get('/api/private.css', (_req, res) => {
  res.type('css').send(':root{--brand:rebeccapurple}')
})

app.listen(3000)

Monitoreo y optimización del rendimiento

Monitorear las métricas clave de rendimiento es crucial para controlar los costos de CDN. Al hacer seguimiento de los tiempos de respuesta, las tasas de aciertos de caché, los tamaños de transferencia de datos y los códigos de estado, puedes identificar ineficiencias y afinar tu entrega de contenido. Una sonda en la que valga la pena confiar tiene que hacer cuatro cosas que la versión de una sola línea omite: limitarse en el tiempo, tratar un código que no sea 2xx como un fallo y no como una muestra sana, leer el cuerpo para que el número que informa sea un tiempo de transferencia en lugar de un tiempo hasta el primer byte, y liberar la conexión en todos los caminos.

// edge-monitor.js - run with: node edge-monitor.js
import { setTimeout as sleep } from 'node:timers/promises'

async function probeEdge(url, timeoutMs = 5000) {
  const start = performance.now()
  const response = await fetch(url, { signal: AbortSignal.timeout(timeoutMs) })
  try {
    // A 503 from the edge is a monitoring signal, not a sample to average in.
    if (!response.ok) return { url, ok: false, status: response.status }

    // Reading to completion is what makes `duration` a transfer time. Awaiting
    // fetch() alone stops at the response headers.
    let bytes = 0
    if (response.body) {
      for await (const chunk of response.body) bytes += chunk.byteLength
    }
    return {
      url,
      ok: true,
      status: response.status,
      bytes,
      duration: performance.now() - start,
      cache: response.headers.get('cf-cache-status') ?? 'unknown',
    }
  } finally {
    // A no-op once the body has been read. On the error path nothing consumed
    // it, and an unread body holds the connection until the GC gets to it.
    if (!response.bodyUsed) await response.body?.cancel()
  }
}

// Log the origin and path, never the query string: a monitored URL can carry a
// signed token, and these lines end up in a log sink other people can read.
function formatProbe(result) {
  const { origin, pathname } = new URL(result.url)
  if (!result.ok) {
    // An error name, not a message: fetch puts the full URL in `message`.
    return `${origin}${pathname} FAIL ${result.error ?? `HTTP ${result.status}`}`
  }
  const duration = `${result.duration.toFixed(0)}ms`
  return `${origin}${pathname} ${result.status} ${duration} ${result.bytes}B cache:${result.cache}`
}

// Sequential and stop-aware. setInterval with an async callback fires on a
// fixed clock whether or not the previous probe has finished, so a slow edge
// quietly turns your monitor into a load generator against it.
async function monitorEdge(url, signal, intervalMs = 300_000) {
  while (!signal.aborted) {
    const result = await probeEdge(url).catch((error) => ({ url, ok: false, error: error.name }))
    console.log(formatProbe(result))
    // Aborting the sleep rejects. That rejection is the stop signal, not a
    // failure, and the loop condition above picks it up on the next pass.
    await sleep(intervalMs, undefined, { signal }).catch(() => {})
  }
}

const controller = new AbortController()
process.once('SIGINT', () => controller.abort())
await monitorEdge('https://cdn.example.com/assets/app.js', controller.signal)

cf-cache-status es el encabezado de Cloudflare. Otros proveedores usan los suyos: Fastly y Akamai informan el estado de la caché en X-Cache, y CloudFront usa X-Cache junto con X-Amz-Cf-Pop. Lee el que documente tu proveedor y trata un encabezado ausente como desconocido en lugar de como un fallo de caché.

Dos límites honestos. duration es una única muestra sintética desde donde sea que se ejecute el proceso, así que mide tu ruta hacia un solo PoP y nada sobre las rutas de tus usuarios; trátalo como una alarma de regresión, no como una cifra de latencia para reportar. Y una sonda es en sí misma una solicitud facturable, por eso el intervalo predeterminado aquí es de cinco minutos y no de cinco segundos.

Estrategias para optimizar los costos de CDN

Optimizar los gastos de CDN requiere tanto minimizar las transferencias de datos como aprovechar el almacenamiento en caché de forma eficaz.

Minimizar las transferencias de datos innecesarias

Reducir el tamaño de las cargas útiles mediante compresión puede bajar los costos de forma sustancial. Agrega compresión al server.js mostrado más arriba, antes del montaje estático, para que los archivos que sirve salgan comprimidos:

npm install compression

// Add to server.js, directly after `const app = express()`.
import compression from 'compression'

app.use(
  compression({
    filter: (req, res) => {
      if (req.headers['x-no-compression']) return false
      return compression.filter(req, res)
    },
    level: 6,
    threshold: 0,
  }),
)

Comprimir en tu origen es el recurso de respaldo, no el objetivo: la mayoría de las CDN pueden comprimir en el borde y almacenar en caché ambas codificaciones, lo que te ahorra la CPU en cada fallo de caché. Comprueba qué hace ya tu proveedor antes de pagar por ello dos veces.

Aprovechar el almacenamiento en caché de forma eficaz

Más allá de los encabezados por solicitud, normaliza las claves de caché en el borde. Las cadenas de consulta de marketing como ?utm_source=newsletter producen una entrada de caché distinta por campaña para bytes idénticos, lo que convierte aciertos en fallos sin que te des cuenta. Toda CDN importante ofrece un ajuste de clave de caché o de manejo de cadenas de consulta para eliminar los parámetros que no cambian la respuesta; configurarlo suele ser la mejora de tasa de aciertos de caché más barata disponible. El helper buildVariantUrl de antes aplica la misma idea en el origen al negarse por completo a llevar una cadena de consulta a una URL de variante.

Conclusión

Optimizar los costos de CDN implica equilibrar el rendimiento con la eficiencia. Al entender los distintos modelos de precios, monitorear las métricas clave, implementar estrategias de almacenamiento en caché eficaces y aprovechar las funciones de computación en el borde, puedes desarrollar un enfoque rentable para la entrega de contenido.

En Transloadit, tenemos el compromiso de ayudar a los desarrolladores a crear aplicaciones eficientes y rentables. Para soluciones potentes de subida y procesamiento de archivos, echa un vistazo a Transloadit.