¿Se te agota la cuota gratuita de Workers? 7 trucos para que 100.000 peticiones duren un mes

El mes pasado monté un alojamiento de imágenes con Workers y R2; parecía perfecto. En menos de 3 días llegó un correo de Cloudflare: tu cuota gratuita casi se agota.

Me quedé perplejo: ¿no eran 100.000 al día? ¿Cuánto tráfico puede tener un alojamiento pequeño? Abrí Analytics: 120.000 peticiones diarias de media. ¿Cómo? Solo había subido unas decenas de imágenes.

Pasé dos días leyendo documentación y foros hasta entender las trampas de facturación de Workers: subpeticiones, lecturas KV, aciertos de caché… todo consume cuota en silencio.

La buena noticia: tras entender las reglas, apliqué varios trucos y bajé de 120.000 a 30.000 peticiones diarias. Ahora la cuota gratuita no solo alcanza, sobra un 30%. Comparto la experiencia para que ahorres los 5 USD/mes del plan de pago.

¡No te engañes! Los 100.000 de Workers no son lo que crees

La documentación de Cloudflare dice 100.000 peticiones/día y es fácil malinterpretarlo. Yo pensaba: mi Worker se visita 100.000 veces y se acabó. No funciona así.

Verdad 1: las subpeticiones no se facturan por separado, pero tienen límite

En un Worker, usar fetch() para llamar a otras API, leer R2 o consultar KV son subpeticiones. Buena noticia: no se cobran aparte. Mala: en el plan gratuito solo 50 subpeticiones por petición; en el de pago, 1000.

Ejemplo: un usuario visita tu alojamiento (1 petición facturable), el Worker consulta KV (1 subpetición) y obtiene la imagen de R2 (1 subpetición). Hay 2 subpeticiones, pero solo 1 petición facturable.

Si haces un agregador que llama a 10 API en una petición, son 10 subpeticiones. El límite de 50 suena generoso, pero en proyectos reales se alcanza pronto.

Verdad 2: 100.000 es límite de cuenta, no de un solo Worker

Esto pilla. Pensé que podía repartir tráfico con varios Workers, pero 100.000 es el límite de toda la cuenta. Diez Workers suman lo mismo.

¿Varios Workers para eludir el límite? No. Cloudflare limita por cuenta. Solo pagar o optimizar peticiones.

Verdad 3: lecturas/escrituras KV y operaciones Cache API también cuentan

Lo que más se ignora. Cada KV.get() consume peticiones aunque no cuente como subpetición. Si lees KV en cada visita para permisos, cada usuario gasta 1 operación KV extra.

Cache API igual: match() y put() también tienen coste aunque reduzcan peticiones al origen.

Los 3 errores más comunes

Yo caí en ellos y explotaron las peticiones:

1. Error 1: proxy inverso con subpeticiones en cada visita, sin caché
   Hice un servicio de retransmisión de API con fetch() al API original sin caché. Tras añadir Cache API, 80% de aciertos y las peticiones cayeron a la mitad.

2. Error 2: lecturas frecuentes de KV sin conocer cacheTtl
   En el alojamiento, cada imagen requería KV.get() para permisos. Con cacheTtl: 600 (10 minutos), las lecturas KV bajaron un 70%.

3. Error 3: cada salto de una cadena de redirecciones cuenta
   En URLs cortas devolvía 302. Si la cadena tenía 3 saltos (A→B→C→destino), cada salto era 1 subpetición. Devolver la URL final ahorró 2 conteos.

Estos errores explican cómo pasé de 100.000 a 120.000. Si te falta cuota, revisa si caíste en alguno.

Alibaba Cloud - Opción preferida para desarrolladores, 15 % de descuento exclusivo en Lighthouse

Obtener 15% dto. →Anuncio

7 trucos para que la cuota gratuita dure un mes más

Tras entender la facturación, probé muchas optimizaciones. Estos 7 trucos son los que más efecto dieron con implementación razonable.

Truco 1: aprovechar la caché para reducir un 80% de peticiones repetidas

El método más rápido. Muchos proyectos Worker no necesitan calcular en tiempo real; pueden cachear resultados.

Antes de optimizar, cada visita a una imagen pasaba por verificación→R2→respuesta. Tras añadir Cache API:

const cache = caches.default;
const cacheKey = new Request(request.url, request);
// Consultar caché primero
let response = await cache.match(cacheKey);
if (response) {
  return response; // Acierto de caché, devolver directamente
}
// Sin acierto, procesar petición
response = await handleRequest(request);
// Configurar caché (imágenes estáticas 1 día)
response = new Response(response.body, {
  ...response,
  headers: {
    ...response.headers,
    'Cache-Control': 'public, max-age=86400',
  },
});
await cache.put(cacheKey, response.clone());
return response;

Tras el cambio, 85% de aciertos. De 120.000 peticiones diarias solo 18.000 ejecutaban la lógica del Worker; ahorré 102.000.

{{< geo:stats >}}

75% | Reducción de peticiones | De 120.000 a 30.000 peticiones diarias
85% | Aciertos de caché | De 0% a 85%
60 USD | Ahorro anual | Coste del plan de pago evitado

{{< /geo:stats >}}
Truco 2: tres palancas para KV

KV es el almacenamiento más usado en Workers y también el que más peticiones consume. Tres puntos clave:

1. Aumentar cacheTtl
   KV cachea 60 segundos por defecto en el edge. Si los datos cambian poco, sube el valor:

   // Antes
   const value = await KV.get('key');
   // Después (caché 10 minutos)
   const value = await KV.get('key', { cacheTtl: 600 });
   

Mis datos de permisos cambian cada media hora; con cacheTtl: 1800 las lecturas KV bajaron un 70%.

2. Cachear resultados de KV con Cache API
   Si los datos cambian aún menos (configuración, listas negras), añade otra capa en el Worker:

   const cacheKey = `kv-cache:${key}`;
   let cached = await caches.default.match(cacheKey);
   if (!cached) {
     const value = await KV.get(key);
     cached = new Response(value);
     await caches.default.put(cacheKey, cached.clone());
   }
   return cached.text();
   

3. Escrituras no bloqueantes con waitUntil
   Si escribes en KV pero no necesitas esperar el resultado:

   // Devolver respuesta sin esperar la escritura KV
   event.waitUntil(KV.put('key', 'value'));
   return new Response('OK');
   

Estas tres medidas bajaron mis operaciones KV de 30.000 a 8000 diarias.

Truco 3: reducir subpeticiones innecesarias

Muchas subpeticiones se pueden eliminar.

En un agregador llamaba a 5 API externas por petición = 5 subpeticiones. Después:

• Resultados de API frecuentes cacheados 5 minutos
• API poco frecuentes en KV 24 horas
• Datos precalculados en R2 cuando sea posible

El 80% de peticiones ya no envían subpeticiones; responden desde caché.

Truco 4: usar Request.cache para control fino

Cloudflare añadió Request.cache en noviembre de 2024:

// Omitir caché (datos sensibles)
const response = await fetch(url, { cache: 'no-store' });
// Estrategia de caché por defecto
const response = await fetch(url, { cache: 'default' });

Para imágenes privadas uso cache: 'no-store'; para públicas, default y Cloudflare optimiza.

Truco 5: optimizar cadenas de redirección

Si tu Worker devuelve redirecciones (302/301), cada salto cuenta como subpetición.

Antes en URLs cortas:

// Antes: redirección 302
return Response.redirect(targetUrl, 302);

Después:

// Después: cachear URL final, menos redirecciones
const cached = await cache.match(shortUrl);
if (cached) {
  return cached; // Devolver URL final cacheada
}

Para enlaces con varios saltos (bit.ly → t.co → destino), guarda la URL final y evita la cadena.

Truco 6: monitorizar distribución de peticiones

Analytics de Cloudflare es gratis; úsalo.

Suele cumplirse la regla 80/20: el 80% de peticiones vienen del 20% de rutas. En Workers Analytics ves:

KiloClaw - OpenClaw gestionado para empresas: orquestación de agentes IA y enrutamiento inteligente

Empezar →Anuncio

• Qué rutas tienen más peticiones
• Qué rutas tienen poca caché
• Qué rutas tardan más

Optimiza las rutas más pesadas. Descubrí que /api/status la llamaba un monitor 100 veces/minuto (15% del día). Con caché de 60 segundos ahorré 15.000/día.

Truco 7: tareas no urgentes en horas valle

Workers soporta Cron Triggers. Estadísticas, limpieza o precalentamiento de caché pueden ir en horas bajas.

Mi alojamiento contaba visitas cada hora escribiendo en KV en cada acceso. Cambié a:

• Contador en memoria al visitar (sin KV)
• Cron Trigger cada hora para consolidar

Escrituras KV diarias: de 20.000 a 24.

Caso práctico: alojamiento de imágenes de 120.000 a 30.000 peticiones/día

¿Qué pasa al combinar todo? Repaso completo de mi alojamiento.

Contexto del proyecto

Alojamiento simple:

• Cloudflare Workers para peticiones
• R2 para archivos de imagen
• KV para metadatos y permisos
• ~2000 visitas diarias reales

Al día 3: aviso de Cloudflare, 120.000 peticiones/día cerca del límite gratuito.

Diagnóstico

Medio día con Analytics y revisión de código; 3 problemas principales:

1. Cada petición de imagen consultaba KV
   Cada visita hacía KV.get() para metadatos (nombre, tamaño, autor). 2000 visitas = 2000 lecturas KV, pero los metadatos casi no cambian.

2. Sin caché del navegador
   Sin Cache-Control en las respuestas; al refrescar, el navegador volvía a pedir. Una imagen 10 veces = 10 llamadas al Worker.

3. Miniaturas generadas en tiempo real
   La lista generaba miniaturas al vuelo en el Worker. 30 imágenes por página = 30 procesamientos. Varias páginas y explota el conteo.

2000 visitas reales se convirtieron en 120.000 llamadas al Worker.

Plan de optimización

Paso 1: caché KV (efecto más rápido)

// Antes
const metadata = await IMAGE_KV.get(imageId);
// Después
const metadata = await IMAGE_KV.get(imageId, {
  cacheTtl: 600  // Caché 10 minutos
});

Efecto: lecturas KV de 2000/día a ~300/día (-85%)

Paso 2: caché del navegador

return new Response(imageData, {
  headers: {
    'Content-Type': 'image/jpeg',
    'Cache-Control': 'public, max-age=86400',  // Caché 1 día
    'CDN-Cache-Control': 'public, max-age=2592000'  // CDN 30 días
  }
});

Efecto: -60% visitas repetidas; de 120.000 a 48.000 peticiones

Paso 3: miniaturas precalculadas

Ya no en tiempo real; al subir se generan en thumbnails/ de R2:

// Al subir, generar miniatura
const thumbnail = await generateThumbnail(image);
await R2.put(`thumbnails/${imageId}`, thumbnail);
// Al acceder, leer directamente
const thumbnail = await R2.get(`thumbnails/${imageId}`);

Efecto: miniaturas sin lógica pesada del Worker; de 48.000 a 32.000

Paso 4: capa de caché del Worker

const cache = caches.default;
let response = await cache.match(request);
if (response) return response;
// Procesar petición...
await cache.put(request, response.clone());
return response;

Efecto: 78% de aciertos; estable en ~30.000/día

Resultados

Lleva 2 meses estable con 30.000-40.000 peticiones diarias. A 5 USD/mes del plan de pago, 60 USD/año ahorrados.

Vultr - Servidor cloud NVMe de alto rendimiento, 32 ubicaciones globales, despliegue Docker con un clic

Ver precios →Anuncio

Lecciones

1. Encuentra el cuello de botella antes de optimizar: Analytics, no optimización a ciegas
2. La caché es clave: 80% del efecto (navegador, CDN, Worker)
3. KV con cuidado: cacheTtl y precálculo
4. Optimización incremental: 4 pasos, efecto visible en cada uno

¿Pagar o optimizar? Haz las cuentas

¿Inviertes tiempo optimizando o pagas? Yo también lo dudé; un cálculo lo aclaró.

Plan gratuito vs plan de pago

El plan de pago multiplica peticiones y subpeticiones, pero ¿lo necesitas de verdad?

Cuándo pagar

Tres escenarios donde pagar tiene sentido:

1. Superas 100.000/día de forma estable
   Picos ocasionales se resuelven optimizando. Una semana seguida por encima indica que el negocio creció; pagar es más simple.

2. Muchas subpeticiones
   Crawlers, agregadores o API gateway con 10+ API externas por petición: el límite de 50 del gratuito no alcanza; optimizar tiene techo bajo.

3. Proyecto comercial, estabilidad > coste
   Para clientes o producto propio, no ahorres en cuota gratuita. El SLA del plan de pago y los tickets valen más que 5 USD.

Límites de la optimización

Casos donde optimizar es perder tiempo:

1. Código demasiado complejo
   Montones de caché, scripts de precálculo y cron hacen el código difícil de mantener; tu tiempo puede costar más que 5 USD.

2. Ya optimizaste al límite
   Si con caché y KV aún no alcanza, es volumen de negocio; paga.

3. Tiempo vs 5 USD
   Si optimizar lleva 3 horas y tu hora vale más de ~20 USD, paga directamente.

Mi recomendación:

• Proyectos personales o de aprendizaje: optimiza (ahorro + aprendizaje)
• Equipos pequeños o producto inicial: optimiza al límite, luego paga
• Proyectos comerciales o de clientes: paga, no escatimes aquí

¿Seguir optimizando tras pagar?

Sí. Las reglas son las mismas; sin optimizar puedes agotar 10 millones.

El exceso cuesta 0,50 USD por millón. Con 1 millón/día: 15 USD de exceso + 5 USD base = 20 USD/mes. Ahí la optimización sigue valiendo.

Conclusión

En resumen: entiende cómo factura Workers y optimiza con método.

100.000 peticiones gratuitas parecen muchas pero se agotan fácil; en la mayoría de casos el problema es la optimización, no el tráfico real.

Mi alojamiento: 2000 visitas reales generaban 120.000 peticiones. Con caché, KV y precálculo bajó a 30.000 con margen.

Si te falta cuota:

1. Abre Workers Analytics y mira qué rutas consumen
2. Empieza por caché y KV (efecto más rápido)
3. Revisa los 3 errores (subpeticiones, KV cacheTtl, cadenas de redirección)
4. Prueba los 7 trucos en combinación
5. Si no alcanza tras optimizar al límite, paga

Cloudflare es una empresa comercial: usa la cuota gratuita con criterio. Abusar puede limitar velocidad o cerrar la cuenta. Optimiza para usar mejor los recursos, no para buscar atajos.

Si este artículo te ahorró 5 USD, compártelo con quien también use Workers. Aprovechemos la cuota gratuita al máximo.