When we first built venue profiles, we had 50 test pages. They loaded instantly because there was nothing to slow them down. 50 pages is nothing.
Then we connected the real database. 25,000 venues. 25,000 pages that needed to exist, be indexable by Google, load fast, and contain unique content.
That’s when the engineering got interesting.
Option 1: Generate all 25,000 pages at build time. Full static generation. Every page becomes an HTML file. Blazing fast. But the build takes forever. We’re talking 30+ minutes to regenerate the entire site. And if we update one venue’s hours? Rebuild everything. That’s not sustainable.
Option 2: Server-render every page on demand. No build time. Fresh data every request. But slower for users — every page load hits the database. And Google’s crawler gets slower responses, which can hurt rankings.
Option 3: Incremental Static Regeneration (ISR). The best of both worlds. Generate the most important pages at build time. Everything else gets generated on first request and then cached as static HTML. Periodically revalidate — re-generate the page in the background so the cached version stays fresh.
We went with Option 3. Here’s how it works in practice:
At build time, we generate the top-traffic pages: all 43 neighborhood pages, all category pages, and the most popular venue profiles. That’s maybe 500 pages. Build takes about 3 minutes. Totally reasonable.
The remaining 24,500+ venue pages use dynamic rendering with caching. When the first person visits a venue page we haven’t pre-built, Next.js renders it on the server, returns it to the user, and saves the result as a static HTML file on the edge. Every subsequent visitor gets the cached static version. Instant.
Revalidation happens on a schedule. Every hour, the most recently accessed pages get re-checked against the database. If a venue’s data changed — new hours, new tips, updated description — the cached page gets regenerated. Users always see fresh data without us having to manually rebuild anything.
The result: 25,000+ pages that load as fast as static HTML, stay fresh automatically, and don’t require a 30-minute build cycle.
There was a night early on where we turned this system on for the first time against the full database. We watched the Vercel logs as pages generated in real-time. 100. 200. 500. Each one a new venue appearing on the internet for the first time. A bar in Alphabet City. A restaurant in Harlem. A lounge in Meatpacking.
500 pages in one night. By the end of the week, thousands more. Each one indexable. Each one useful.
This is the advantage of choosing boring technology. Next.js and Vercel handle this out of the box. We didn’t have to build a custom static generation pipeline or manage CDN invalidation. We just configured the framework and let it work.
Sometimes the best engineering is choosing the tool that does the work for you.
— The Moodap™ Team