Resumen

  • Workers Cache cobra al precio estándar las solicitudes al Worker que tiene activada la función, incluidas las de archivos estáticos normalmente gratuitas. Un acierto de caché evita ejecutar código y consumir CPU, pero conserva el cargo por solicitud.
  • El ejemplo oficial intensivo en cálculo ahorra 11,20 dólares. Aplicar las reglas al ejemplo con mayoría de tráfico estático produce un aumento de 1,50 dólares, con las franquicias mensuales disponibles.

El procesador se toma un descanso. El contador de solicitudes consigue nuevos clientes.

Cloudflare explica ambas cosas en su documentación. Workers Cache busca una respuesta antes de ejecutar el código: si la encuentra, la entrega directamente. Al activar la función, todas las solicitudes a ese Worker pasan a la tarifa estándar por solicitud. La lista incluye archivos estáticos que, sin esa función, se sirven gratis.

La frase «sin precio separado» convive perfectamente con ese cambio. El proveedor no abre una casilla nueva en la tarifa; amplía la población que entra en una existente. Para decidir si conviene, hay que contar esa población.

El ejemplo pequeño que cambia de signo

Workers Paid Standard tiene un mínimo de 5 dólares mensuales por cuenta. Incluye 10 millones de solicitudes y 30 millones de milisegundos de CPU. El exceso cuesta 0,30 dólares por millón de solicitudes y 0,02 por millón de milisegundos de CPU. Las franquicias son de la cuenta; cada Worker adicional no trae otra ración.

El ejemplo 2 de la página de precios presenta 15 millones de solicitudes al mes: 12 millones de archivos estáticos y tres millones dinámicas, estas últimas con una media de 7 milisegundos de CPU. Los archivos son gratuitos. Los tres millones de solicitudes y sus 21 millones de milisegundos caben en lo incluido. La factura del ejemplo suma 5 dólares.

Mantengamos ese tráfico y activemos Workers Cache para todo ese Worker. El cálculo supone una sola cuenta Standard de pago, todas sus franquicias disponibles y ningún otro consumo, producto o ajuste. Las 15 millones de solicitudes entran ahora en el cómputo facturable. Los cinco millones por encima de lo incluido cuestan 1,50 dólares.

La CPU ya estaba por debajo de su franquicia. Incluso sin aciertos en las respuestas dinámicas, sigue en 21 millones de milisegundos. Su recargo continúa en cero. La suma resulta de 6,50 dólares.

Este resultado aplica las reglas documentadas a las cantidades del ejemplo 2; es un cálculo propio condicionado por esa configuración. El proveedor publica los ingredientes, no esa factura final como caso de cliente. Lo decisivo es que ahorrar CPU ya incluida no genera un descuento por debajo de cero, mientras las solicitudes que antes eran gratuitas sí pueden producir un cargo nuevo.

Cuando hay CPU que pagar, el ahorro aparece

Otro ejemplo oficial parte de 100 millones de solicitudes mensuales, con 7 milisegundos de CPU de media por solicitud. La cuenta es 5 dólares de base, 27 por solicitudes y 13,40 por CPU: 45,40 dólares.

Con un 80% de aciertos de caché, solo 20 millones de solicitudes ejecutan código. El consumo de CPU baja a 140 millones de milisegundos y su recargo a 2,20 dólares. La partida por solicitudes sigue en 27. Total: 34,20 dólares.

El ahorro asciende a 11,20 dólares, aproximadamente una cuarta parte del total. La tasa de aciertos del 80% describe ejecuciones evitadas. La factura también cobra entregar respuestas, y las franquicias modifican la relación entre milisegundos y dinero. Llevar el porcentaje de aciertos directamente a una promesa de ahorro monetario borra esas dos piezas.

Para un servicio dinámico con CPU facturable abundante, la función puede convertir una mejora técnica en ahorro inmediato. En el escenario de mayoría estática, el ahorro potencial afecta una partida que ya costaba cero. El mismo botón tiene economías distintas porque parte de trabajos distintos.

La frontera comercial sigue la configuración

Workers Cache es una función previa a la ejecución del Worker. Tiene un ámbito distinto del antiguo Cache API utilizado dentro del código y de la caché CDN ordinaria de una zona. La documentación indica que Cache Rules y Page Rules de zona no la configuran.

También incluye en la tarifa de solicitudes llamadas entre Workers que normalmente no añaden ese cargo en Standard. Elegir qué Worker tiene la función activada importa cuando una aplicación se divide en varios componentes. Para calcular una cadena concreta hacen falta su configuración y su recorrido efectivo; el número de componentes no basta.

La caché por niveles y la agrupación de solicitudes simultáneas pueden evitar ejecuciones repetidas. Las respuestas entregadas siguen siendo solicitudes. El proveedor vende también esa entrega, aunque la máquina haya hecho menos operaciones.

Para calcular una factura real faltan el reparto del tráfico, su CPU, el uso de las franquicias por otras cargas y las condiciones contratadas. Esos datos deciden cuál de los dos efectos domina.

La pregunta útil en la reunión de compras llega después de celebrar el acierto de caché: ¿qué solicitudes han entrado ahora en el contador? El procesador puede descansar. Quien aprueba el presupuesto todavía tiene una suma pendiente.

Fuentes