Optimizing data cache reads
Unanswered
Eric Burel posted this in #help-forum
Hey folks,
I see many data cache reads on my hosted Next.js app, however I don't understand the remediation strategies
It states that we could use time-based revalidation or on-demand revalidation, but shouldn't this reduce only data cache writes, not reads? I don't get why a read would be billed, since it's equivalent to as static render that you access, having many reads is the sign of a correctly optimized app to me, but perhaps I don't understand what a "read" is in this context ?
https://vercel.com/docs/pricing/data-cache#optimizing-data-cache-reads-and-writes
(I know this might be Vercel specific currently however since the data cache is a generic Next.js concept I think it's relevant to ask here)
I see many data cache reads on my hosted Next.js app, however I don't understand the remediation strategies
It states that we could use time-based revalidation or on-demand revalidation, but shouldn't this reduce only data cache writes, not reads? I don't get why a read would be billed, since it's equivalent to as static render that you access, having many reads is the sign of a correctly optimized app to me, but perhaps I don't understand what a "read" is in this context ?
https://vercel.com/docs/pricing/data-cache#optimizing-data-cache-reads-and-writes
(I know this might be Vercel specific currently however since the data cache is a generic Next.js concept I think it's relevant to ask here)
7 Replies
I've actually experienced a similar issue which makes a single Next.js app exceeded 400% of the limit of Vercel
My Original Post: https://x.com/fuma_nama/status/1812872105832427631
Basically you can investigate the network usage on Vercel, and find the most used routes.
From what I know, it's unlikely the problem of your cache strategy, unless you're using the cache really intensely.
To me, it was caused by prefetching on Next.js Link component, I fixed it with static export because the app can be fully static (a docs). The usage immediately dropped by 90% after the migration and everything works well.
You may have to pay some attentions to the Link prefetching issue too, it's quite nerve-racking sometimes
My Original Post: https://x.com/fuma_nama/status/1812872105832427631
Basically you can investigate the network usage on Vercel, and find the most used routes.
From what I know, it's unlikely the problem of your cache strategy, unless you're using the cache really intensely.
To me, it was caused by prefetching on Next.js Link component, I fixed it with static export because the app can be fully static (a docs). The usage immediately dropped by 90% after the migration and everything works well.
You may have to pay some attentions to the Link prefetching issue too, it's quite nerve-racking sometimes
Nice tip for the Link prefetch! And you observed usage for the Cache reads specifically?
I think Next 15 will reduce the consumption a bit by not caching as a default, given that we already have Redis for dynamic calls in our app, we could stick to static rendering only when relevant
I also wonder about the impact of PPR, will the static part by billed as a data cache read
it's still beta so not a surprise that this is not very clear but I hope doc will improve a lot
when it's not cached by CDN, it causes a Data Cache read - basically all _rsc requests are not cached, so clicking on a page will cause a data cache read + more if you have
cache used in codethey didn't document it clearly so I only know some information by investigating the usage and devtools