ISR writes en Vercel: 325K con 60 visitas por día
En pocas palabras: El sitio promokoduz.uz llegó a 325K ISR writes en Vercel Hobby (tope: 200K) porque sus páginas generaban bytes distintos con los mismos datos. Eliminar horas, contadores y orden variable bajó las escrituras diarias de unas 23K a unas 10K, pero el sitio sigue sobre el límite.
Las ISR writes en Vercel se miden en unidades de 8 KB, y un sitio chico de Next.js 16 puede pasarse del tope gratis con casi cero tráfico. A mediados de septiembre de 2026, promokoduz.uz (unas 60 visitas por día) llegó a 325K ISR writes sobre las 200K incluidas en Hobby.
Una ISR write es la escritura de una página regenerada en la caché durable de Incremental Static Regeneration (ISR), la función de Next.js que vuelve a generar páginas estáticas sin rehacer todo el build. Según la documentación de Vercel, cada unidad equivale a 8 KB escritos, así que el costo depende del tamaño del HTML y del payload RSC, no de la cantidad de páginas.
En este artículo:
- En 30 segundos
- ¿Cómo cuenta Vercel una ISR write en el plan Hobby?
- ¿Por qué una página con los mismos datos genera ISR writes en Vercel?
- ¿Cuánto bajaron las ISR writes y por qué no alcanzó?
- ¿Por qué cada deploy vuelve a escribir las páginas en Next.js 16?
- ¿Qué conviene revisar en tu proyecto de Next.js en Vercel?
- Qué está confirmado y qué no
- Errores comunes al reducir ISR writes
- Preguntas Frecuentes
- Conclusión
- Fuentes
En 30 segundos
- La home de 450 KB del caso equivale a 57 unidades por escritura, y una página de marca de 187 KB a 24.
- Si una regeneración produce el mismo contenido que la copia guardada, Vercel no cobra unidades. Todo valor que cambia en cada render (hora, contador, orden de filas) dispara una escritura.
- El autor bajó las unidades diarias de unas 23K a unas 10K, pero 10K por día son unas 300K al mes, todavía sobre las 200K incluidas.
- Según su análisis, en Next.js 16.3 cada deploy vuelve a escribir cada página una vez por una diferencia en los hints de prefetch. Está medido en un solo sitio.
¿Cómo cuenta Vercel una ISR write en el plan Hobby?
Vercel cuenta una ISR write por cada 8 KB que guarda en la caché durable, no por página. La documentación aclara que leer y escribir en la caché del CDN es gratis; lo que cuesta es lo que baja al almacenamiento durable de la región de tu función. Y si una regeneración produce el mismo contenido que la copia guardada, no se incurre en unidades, ni en revalidación por tiempo ni en la on-demand.
Las cifras del caso publicado el 10 de octubre de 2026 lo bajan a tierra. En una build de producción local, la home pesa 450 KB entre HTML y payload RSC, o sea 57 unidades cada vez que se escribe, y una página de marca de 187 KB cuesta 24.
Para depurar escrituras inesperadas, la documentación manda revisar primero new Date() y Math.random() en el output.
La pregunta útil, entonces, es por qué una página con datos idénticos produce bytes distintos.
¿Por qué una página con los mismos datos genera ISR writes en Vercel?
Genera ISR writes cuando algo de su salida cambia entre regeneraciones: una hora, un contador, el orden de las filas del payload. El autor de promokoduz.uz (111 códigos, 75 marcas, Next.js 16 con App Router en Hobby) encontró cinco causas. Para más detalles técnicos, mirá desplegar tu web gratis en Vercel.
- Ventana real de cinco minutos. La página declaraba revalidate = 1800, pero leía datos con unstable_cache y revalidate: 300, y gana la ventana más corta. La tabla de rutas de next build mostraba “5m” desde el principio. Ahora todo tiene una ventana de un día, con purgas on-demand, y un test mantiene sincronizados los literales.
- Tiempo en el output. Un new Date().toISOString() dentro de un <time> y cuentas regresivas con precisión de minuto. Pasaron al navegador con un hook useNow, basado en useSyncExternalStore, que devuelve null en el servidor.
- Contadores en vivo. Las vistas y copias exactas viajaban en el HTML y en las props de componentes cliente. Ahora approximateCount redondea al primer dígito: 637 se muestra como “600+”.
- Orden distinto en el payload RSC. En Next 16.3 la metadata llega en streaming y las secciones async hermanas terminan según responda la base. Lo resolvió con un loader con cache() compartido y awaiteando las secciones en la página: tres renders con tres órdenes de llegada daban tres payloads, ahora dan uno.
- Sitemap con la hora del render. Home, listados y páginas estáticas llevaban lastModified: new Date(). Ahora lastmod sale solo de filas de la base.
Un detalle que muerde al mover fechas al cliente: toLocaleDateString(“uz-UZ”) imprime “16-sentabr, 2026” en Node y “2026 M09 16” en Chrome, que no trae nombres de meses en uzbeko. Si tu idioma es poco común, probablemente tengas que escribir la fecha a mano.
Mi lectura: ninguna de las cinco es un bug de Vercel, y todas se reducen a lo mismo: renderizás la página dos veces con los mismos datos y los bytes no coinciden porque alguien metió un reloj, un contador, un orden de llegada que depende de la base, una fecha de sitemap o una ventana de caché que nadie recordaba haber puesto.
Las causas 1, 2, 3 y 5 las podés revisar en tu código hoy. La 4 depende de la versión (el autor la observó en la 16.3), así que tomala con pinzas hasta reproducirla.
¿Cuánto bajaron las ISR writes y por qué no alcanzó?
Las unidades de escritura diarias bajaron de unas 23K a unas 10K, un recorte de más de la mitad, y el sitio sigue sobre las 200K incluidas porque 10K por día son unas 300K al mes. Los números son del propio autor, sin auditoría externa.
| Métrica | Mediados de septiembre | 10 de octubre |
|---|---|---|
| Revalidaciones por tiempo, 12 h | 490 | 62 |
| Unidades de ISR write por día | unas 23K | unas 10K |
| Fluid Active CPU, 30 días | 4h 28m | 3h 45m |
| ISR writes, 30 días | 325K | 307K |
Ojo con leer la tabla de corrido. El total de 30 días todavía incluye una semana previa a los arreglos, y la cifra de septiembre sale de cuatro días antes de los cambios (entre 19.5K y 27K por día). En errores de deploy en Vercel con Next.js profundizamos sobre esto.
La otra mitad de la cuenta fue CPU. El proxy.ts (el middleware de Next 16) consumía 1h 30m de las 4h 28m porque importaba un helper desde un módulo que arrastraba el cliente de Postgres. El autor movió el helper, sumó un test que recorre el grafo de imports y sacó los sitemaps por matcher, no con un return temprano, que igual cuesta la invocación. A octubre de 2026, Hobby incluye 4 horas de Active CPU, según la página de precios de Vercel.
Descartó experimental.inlineCss. La “mejora” de 890 ms en first contentful paint duplicaba el peso de la home (de 450 KB a 898 KB) y más que triplicaba el de una página de marca (de 187 KB a 636 KB), y cada byte extra se paga en unidades de 8 KB.
¿Por qué cada deploy vuelve a escribir las páginas en Next.js 16?
Según el autor, porque Next 16.3 activa experimental.prefetchInlining por defecto y la copia del build nunca coincide con la primera regeneración. Es un hallazgo propio: las páginas oficiales que leímos no lo documentan.
El dato de partida: en Observability → ISR → Paths, de 500 paths en 12 horas, 277 se habían escrito, y el 56% de esas escrituras eran de páginas que la edición del día no podía haber cambiado. Next 16 guarda por página el HTML, el payload RSC y cuatro archivos .segments/, o sea seis escrituras (unas 17 unidades en sus páginas). En el build, los hints se miden después del prerender y los segmentos quedan marcados como InliningHintsStale; la primera regeneración en runtime escribe valores reales (4608 contra 4256 en su ejemplo), con diferencias de 17 bytes. Con 726 URLs en el sitemap, son unas 12K unidades por deploy.
| Prueba en build local | Inlining activado (default) | prefetchInlining: false |
|---|---|---|
| Copia del build vs primera regeneración | Difieren, solo números de hints | Idénticas, en todos los segmentos |
| Primera vs segunda regeneración | Idénticas | Idénticas |
| Entradas de caché por página | 6 | 11 |
| Requests de prefetch (home, scroll, dos navegaciones) | 64 | 150 |
La decisión que te deja: si desplegás todos los días un sitio con cientos de URLs, el piso de escrituras por deploy puede pesar más que tus ediciones reales. El autor ya había limitado los deploys a uno por día, por otro límite (almacenamiento de deployments).
Lo que no podés concluir: que prefetchInlining: false te convenga. Con esa opción una página cuyos datos sí cambiaron cuesta más (once entradas) y el navegador pide 150 prefetches en vez de 64. Todo se verificó en una build local y en un solo sitio. Ya lo cubrimos antes en comparativa de costos entre Vercel y Amplify.
¿Qué conviene revisar en tu proyecto de Next.js en Vercel?
Revisá primero lo que cambia entre regeneraciones sin que cambien tus datos. La guía de Vercel sobre ISR writes (julio de 2026) separa tres frentes: frecuencia, alcance de la invalidación y tamaño del output. Este es un checklist armado con lo que respaldan las fuentes:
- Compará ventanas. El revalidate de la página contra el de cada unstable_cache que lee. La tabla de rutas de next build muestra la ventana efectiva.
- Buscá valores por render. new Date(), Date.now(), Math.random(), UUIDs generados y contadores exactos, tanto en el HTML como en las props que van a componentes cliente.
- Mirá Observability → ISR. En Hobby muestra las últimas 12 horas. La métrica Write Utilization requiere Observability+, según la documentación.
- Purgá con precisión. URLs y tags angostos, no familias enteras de rutas.
- Limitá los deploys si tenés cientos de URLs.
- Revisá qué importa tu proxy o middleware. Un import de más puede meter la base de datos en el bundle.
- Achicá el output. Pasá a los componentes cliente solo los campos que usan y bajá los límites de ‘use client’ en el árbol.
Propuesta editorial para verificar, no atribuida a Vercel ni al autor: en una build de producción local, forzá dos regeneraciones de la misma ruta sin tocar datos y comparalas con un diff. Ignorá la copia del build, porque según el autor difiere por otra razón. Si la primera y la segunda regeneración no son idénticas, la diferencia te marca la causa. Si lo son, el problema está en la frecuencia o en el alcance de las purgas.
Si tu sitio es chico y la lógica de ISR te cuesta más tiempo que valor, también podés evaluar un hosting tradicional (en Argentina, por ejemplo, donweb.com), donde no existe esta contabilidad por unidades de 8 KB.
Ninguna fuente promete que estas medidas te dejen bajo las 200K. El propio autor sigue arriba, y el multiplicador pendiente son los bytes por escritura.
Qué está confirmado y qué no
- Confirmado por la documentación de Vercel: unidades de 8 KB, sin cobro si el contenido regenerado es idéntico, y new Date() y Math.random() como primeros sospechosos.
- Observado por el autor en su sitio: las cinco causas, la reducción de 23K a 10K unidades diarias y los 307K a 30 días.
- Sin confirmar: que cualquier proyecto con Next 16.3 reescriba todas sus páginas en cada deploy. Medirlo en otro sitio sería la prueba.
¿Alguien lo reprodujo de forma independiente? Todavía no hay evidencia en las fuentes.
Errores comunes al reducir ISR writes
- Subir el revalidate de la página y olvidar la caché de datos. Gana la ventana más corta. Revisá cada unstable_cache que la página lee.
- Mover fechas al cliente sin probar el idioma. El formato de Node y el del navegador pueden no coincidir, como pasó con uz-UZ.
- Excluir rutas del proxy con un return temprano. La invocación se cobra igual. Sacalas en el matcher.
- Activar una optimización de rendimiento sin medir el output. inlineCss bajó el FCP, pero duplicó y hasta triplicó los bytes por escritura.
Preguntas Frecuentes
¿Qué es una ISR write en Vercel y cómo se cuenta?
Es una unidad de 8 KB escrita en la caché durable de ISR. Una página de 187 KB cuesta 24 unidades cada vez que cambia su contenido, según las mediciones del caso. Si la regeneración da el mismo contenido, no se cobra.
¿Por qué mi proyecto de Next.js supera las 200K ISR writes del plan Hobby?
Lo más probable es que tus páginas regeneren con bytes distintos aunque los datos no cambien, o que la ventana real sea más corta de lo que creés. En el caso analizado, un sitio de 60 visitas diarias llegó a 325K por una ventana de cinco minutos, relojes, contadores, orden de filas y un sitemap con la hora del render. Complementá con migrar Next.js a un servidor propio.
¿Usar new Date() en una página con ISR genera escrituras extra?
Sí, si el valor llega al output. Cambia los bytes en cada regeneración, y Vercel cobra solo cuando el contenido guardado cambia, así que cada regeneración se paga. La documentación lo lista, junto con Math.random(), como primera cosa a revisar.
¿Cada deploy en Vercel vuelve a escribir todas las páginas ISR?
Según el autor, en Next.js 16.3 sí, una vez por página, por una diferencia en los hints de prefetch. Lo midió en una build local y en un solo sitio, y las páginas oficiales leídas no lo documentan. Con 726 URLs calculó unas 12K unidades por deploy.
¿Cómo reduzco las ISR writes en Vercel?
Atacá tres frentes: frecuencia (ventanas más largas y purgas on-demand), contenido determinista (sin horas, azar ni contadores exactos) y tamaño del output. Con eso el caso recortó las unidades diarias de unas 23K a unas 10K, aunque sin quedar bajo el límite.
Conclusión
Las ISR writes en Vercel miden bytes que cambian, no visitas. Un sitio con 60 visitas diarias llegó a 325K por output no determinista, y arreglarlo redujo las unidades diarias en más de la mitad sin llevarlo bajo las 200K de Hobby.
Qué hacer: auditá ventanas, relojes, contadores y orden de render en tu código, comprobalo con dos regeneraciones locales y medí cuántos deploys hacés por semana. Lo del deploy en Next 16.3 tratalo como pista a validar en tu proyecto, no como regla.
