Hey everyone,

I’m currently building pokemonstats.com and ran into an interesting architectural “gotcha” regarding ISR and shared components that I wanted to double-check with the community.

Context

I’m generating 1,350+ static pages (one for every Pokémon) using generateStaticParams. The goal is for these to be largely static (force-cache) since Pokémon stats rarely change.

The Problem

I have a shared <Hero /> component on every page that fetches my GitHub repo stars. Since the star count doesn’t change that often, I added a revalidation time to that specific fetch of 1 week.

Everything was good, until I got a message that I was about to reach the limits of my free tier because of ISR reads/writes and thus, Fast Origin Transfer. I did noticed a spike on my recent traffic on the site, but still it felt unrealistic for this page to reach the free tier.

Looking at the build logs, I saw that the revalidate column sets for 1w on every static route:

I realized that every page shares the hero component that fetches the GitHub star count and that revalidate might propagate to every route. Even though the data (stars) is the same for every route, Next.js treats /pokemon/bulbasaur and /pokemon/mewtwo as separate “islands”.

Questions

Does this mean that after one week, I wouldn’t just be making 1 request to update the stars? Would I potentially be triggering 1,350 separate Serverless Function executions and ISR writes—one for every single Pokémon page visited—just to update that one shared number in the UI?

Just wanted to double check if my assumption is correct before thinking of upgrading to Vercel’s Pro plan. I really love this project and I’m eager to think of a better solution to avoid wasting resources unnecessarily.