4 muros de rendimiento en Cloudflare Workers KV
Si alguna vez intentaste optimizar Cloudflare Workers KV en un proyecto real, sabés que los límites del tier gratuito te van a encontrar antes de que vos los encuentres a ellos. Max, el desarrollador detrás de Prismix, publicó el 19 de mayo de 2026 un relato detallado de los 4 muros de rendimiento que enfrentó desplegando un agregador de noticias de IA sobre Cloudflare Workers + Astro 5, con costo de hosting: $0/mes.
En 30 segundos
- El tier gratuito de Cloudflare KV da 100.000 reads/día pero solo 1.000 writes/día: si no lo sabés, lo descubrís en producción.
- Un índice JSON de 5.000 ítems (3,2 MB) puede costar 330ms solo en parsing; dividirlo en chunks lleva ese tiempo a 17ms.
- Los subrequests paralelos tienen un techo de ~6: 60 llamadas kv.get() simultáneas se serializan y generan 4,31 segundos de espera.
- El rendimiento percibido importa tanto como el SSR real: una progress bar en pointerdown puede cambiar la experiencia más que optimizar el backend.
- Con arquitectura Islands en Astro 5 y denormalización inteligente, Prismix pasó de 5.460ms a 380ms de SSR total.
Cloudflare es una empresa de infraestructura web fundada en 2010 que proporciona servicios de CDN, seguridad web, DNS y computación en el borde. Opera una red global de servidores para procesar y servir contenido web.
Cloudflare Workers KV es un almacenamiento clave-valor distribuido globalmente que Cloudflare ofrece como capa de datos para sus Workers. Funciona con lecturas muy rápidas (edge cache) y escrituras eventualmente consistentes, con límites asimétricos que penalizan las escrituras frecuentes mucho más que las lecturas.
Los 4 muros de rendimiento de Cloudflare Workers KV
Prismix resuelve tres frustraciones que cualquiera que siga el ecosistema de IA conoce: las páginas de status de OpenAI y Anthropic no tienen un agregador unificado (terminás con cinco tabs abiertos cada mañana), las noticias de IA están repartidas en 60 RSS feeds y cuentas de redes sociales, y los servidores MCP están dispersos en awesome-lists sin un índice centralizado. La solución fue construir todo en una sola URL, con Cloudflare Workers como backend y Astro 5 para el frontend, con arquitectura Islands. El constraint de $0 en hosting no fue opcional: fue lo que forzó a pensar con más cuidado cada decisión técnica.
Wall 1: el límite de escrituras en KV y el patrón diff-or-skip
El tier gratuito de Cloudflare KV ofrece 100.000 reads/día. Los writes son otra historia: 1.000 por día. Max se topó con el techo el día 12 de producción, a la 1pm.
El error clásico en este caso es reducir la frecuencia del cron. El fix real fue diferente: implementar un patrón diff-or-skip. Antes de escribir, leer el valor existente, comparar con el nuevo, y escribir solo si hubo cambio. El resultado fue bajar de 8.400 writes/día a 600/día, sin tocar la lógica de negocio.
Eso sí: las lecturas son 100 veces más generosas. Si podés convertir un write en un read más una decisión condicional, siempre conviene. Para más detalles técnicos, mirá herramientas de CI/CD para deployment.
Wall 2: JSON.parse tiene un precipicio alrededor del megabyte
El índice de noticias de Prismix creció a 5.000 ítems. Cada lectura de KV devolvía un blob JSON de 3,2 MB. El SSR de la página principal tardaba 330ms solo en parsear ese JSON, antes de hacer cualquier otra cosa.
Ponele que tenés una página de noticias y el 80% del tráfico aterriza en la primera página sin filtros activos. Esos usuarios no necesitan los 5.000 ítems: necesitan los primeros 250 y los metadatos de facetas para los filtros. La solución fue dividir el índice en dos claves KV: news:index:latest:firstpage:v1 (250 ítems, 165 KB) y news:index:latest:meta:v1 (conteos de facetas, 12 KB). El camino frío (filtros activos, paginación, sorting) sigue usando el índice completo, pero el camino caliente carga en 17ms de parsing en vez de 330ms.
La reducción es de más del 94% en tiempo de parsing para la mayoría de las visitas. El versioning en la clave (:v1) permite invalidar el cache de forma explícita cuando cambia el esquema.
Wall 3: subrequests concurrentes limitados a ~6 y la solución de denormalización
Cloudflare Workers limita los subrequests paralelos a aproximadamente 6 por invocación. El problema se hizo evidente en la página de servidores MCP: el código hacía 60 llamadas kv.get() simultáneas para construir la página. ¿Qué pasó cuando los subrequests se serializaron? 4,31 segundos de tiempo total en KV. SSR completo: 5.460ms.
¿Alguien lo anticipó en el diseño inicial? No, y es un error que se comete seguido cuando venís de entornos donde las conexiones paralelas no tienen ese techo. Te puede servir nuestra cobertura de SEO en aplicaciones distribuidas globalmente.
La solución fue denormalización: en lugar de 60 lecturas individuales en tiempo de request, un cron job genera un snapshot diario que pre-agrega todos los datos en una sola clave KV. El tiempo de lectura en KV bajó a 30ms. SSR total: 380ms. El trade-off es que los datos de MCP se actualizan una vez por día, no en tiempo real, pero para ese caso de uso es perfectamente aceptable.
Wall 4: el rendimiento percibido no es el mismo que el tiempo de SSR
Este es el muro más interesante porque no tiene nada que ver con código de backend.
El HTML del servidor llegaba en 200-400ms. Pero el usuario no ve nada hasta que el navegador completa la navegación y actualiza la barra de direcciones. Hay una ventana de 150-300ms donde la pantalla sigue mostrando la página anterior y el usuario asume que el sitio no respondió.
La solución fue doble: una progress bar que se dispara en pointerdown (antes del click, en el momento en que el dedo o el cursor presiona) y prefetch con la estrategia tap de Astro 5. El resultado visual es que la navegación se siente inmediata aunque el SSR tarde lo mismo. Métrica objetiva sin cambiar. Experiencia subjetiva: distinta.
Esto no es un truco de UI. Es que la latencia percibida y la latencia medida son cosas distintas, y optimizar solo la segunda sin tocar la primera deja performance real sobre la mesa. Esto se conecta con lo que analizamos en Cloudflare para acelerar tiendas online.
Stack técnico: Astro 5, Cloudflare Pages y Workers KV
Prismix corre SSR en Cloudflare Pages, con datos en Workers KV. La arquitectura Islands de Astro 5 permite hidratar solo los componentes interactivos del cliente, lo que mantiene el bundle JavaScript pequeño. El proyecto tiene 1.112 tests que corren en 8 segundos. Hosting: $0/mes.
Para autenticación propia (email + GitHub), descartaron Clerk y se ahorraron $25/mes con una implementación propia.
Cuándo estos límites importan (y cuándo no)
| Caso de uso | ¿Afectan estos límites? | Por qué |
|---|---|---|
| Agregadores de noticias / RSS | Sí, mucho | Writes frecuentes + índices grandes |
| Dashboards con datos dinámicos | Sí | Múltiples reads por request |
| Índices de herramientas (MCP, plugins) | Sí | Muchos subrequests por página |
| Sitios estáticos con poca actualización | No | Writes escasos, reads cacheados |
| Landing pages | No | Sin lógica de indexación dinámica |
| APIs de alto tráfico con datos fijos | Parcialmente | Reads bien, writes pueden ser problema |
Si tu proyecto está en la categoría de “sí”, los cuatro patrones de Prismix se pueden aplicar directamente: diff-or-skip para writes, chunking de índices grandes, snapshot pre-generado para reducir subrequests, y progress bar en pointerdown para mejorar la percepción sin tocar latencia real.
Para infraestructura web argentina, si tu proyecto crece más allá del tier gratuito o necesitás algo más predecible que el edge computing, vale mirar opciones de hosting con soporte local como donweb.com para el stack de aplicación mientras Cloudflare sigue manejando el CDN y los Workers.
Errores comunes al optimizar Cloudflare Workers KV
Tratar los writes como reads
El límite de 1.000 writes/día en el tier gratuito sorprende a muchos porque los 100.000 reads/día dan una falsa sensación de generosidad. Si tu cron job escribe sin comparar, llegás al techo antes del mediodía. Implementá diff-or-skip desde el día uno.
Guardar índices monolíticos sin pensar en el acceso
Un JSON de 3 MB en KV no es un problema de almacenamiento. Es un problema de parsing en cada request. Antes de escribir el índice, preguntate qué porcentaje del tráfico necesita todos los datos. Si es menos del 20%, dividí el índice en slices por caso de uso. Tema relacionado: alternativas de rendimiento con Cloudflare.
Asumir que los subrequests paralelos son ilimitados
Venir de Node.js o de un servidor propio con conexiones sin límite hace que el cap de ~6 subrequests paralelos de Workers sea invisible hasta que lo golpeás. Si tu página necesita más de 6 lecturas KV para renderizar, necesitás una estrategia de consolidación: snapshot diario, datos denormalizados, o paginación del backend.
Medir solo latencia de servidor, no latencia percibida
Un SSR de 250ms puede sentirse lento si no hay feedback visual hasta que el navegador completa la navegación. La progress bar en pointerdown y el prefetch en tap son los dos cambios con mejor ratio esfuerzo/impacto percibido que encontró Prismix. No los ignorés porque “el backend ya es rápido”.
Preguntas Frecuentes
¿Cuáles son los límites de Cloudflare Workers KV en el tier gratuito?
El tier gratuito de Cloudflare KV permite 100.000 reads/día, 1.000 writes/día, 1.000 deletes/día y 1.000 list operations/día. El límite de writes es el más crítico para proyectos con actualizaciones frecuentes. Cada valor puede tener hasta 25 MB de tamaño.
¿Cómo optimizar el rendimiento de Cloudflare Workers KV con índices grandes?
La estrategia más efectiva es dividir el índice en slices por patrón de acceso. Un “firstpage” con los primeros 250 ítems y un blob de metadatos separado reduce el parsing de 3,2 MB a 165 KB para la mayoría del tráfico. Para el camino frío (filtros, paginación), seguís usando el índice completo. El versioning en las claves (:v1) permite invalidar el cache sin romper requests en vuelo.
¿Cuál es el máximo de subrequests paralelos en Cloudflare Workers?
Cloudflare Workers limita los subrequests concurrentes a aproximadamente 6 por invocación. Más llamadas simultáneas se serializan, lo que convierte 60 reads KV en una cadena secuencial con tiempos de hasta 4-5 segundos. La solución es pre-agregar datos en un snapshot y leer una sola clave KV en tiempo de request.
¿Por qué mi sitio en Cloudflare Workers se siente lento aunque el SSR sea rápido?
El usuario percibe latencia desde que hace click hasta que ve el nuevo contenido, no desde que el servidor empieza a responder. Si no hay feedback visual durante la navegación, incluso 300ms de SSR se sienten lentos. Una progress bar disparada en pointerdown y prefetch con estrategia tap de Astro mejoran la percepción sin cambiar los tiempos reales de servidor.
¿Cómo manejar índices dinámicos grandes en Cloudflare Workers KV?
Para índices que crecen con el tiempo (noticias, herramientas, feeds RSS), la denormalización vía cron job diario es más efectiva que múltiples reads en tiempo real. Un snapshot pre-generado convierte 60 reads individuales en 1 sola lectura. El trade-off es que los datos se actualizan una vez por día, lo que es aceptable para la mayoría de los casos de uso de agregación.
Conclusión
Lo que documenta Prismix no es una crítica a Cloudflare KV. Es un mapa de sus bordes. El tier gratuito es genuinamente generoso para lecturas, pero los límites de escritura, el cap de subrequests paralelos y el comportamiento de JSON.parse con blobs grandes son restricciones que no están escritas en letras grandes en la documentación y que encontrás en producción.
Los cuatro patrones que salieron de este proyecto (diff-or-skip, chunking de índices, snapshot denormalizado, perceived performance con progress bar) son aplicables a cualquier proyecto sobre Workers KV que maneje datos dinámicos. No necesitás reescribir el proyecto: son cambios quirúrgicos, uno por vez, con impacto medible.
Si vas a construir sobre Cloudflare Workers KV, mirá los límites oficiales antes de diseñar el esquema de datos. Después de leer el caso de Prismix, vas a entender cuáles de esos números realmente importan.
