For the Netorigo Storefront edge cache we kept two serious options on the table: Vercel (already the frontend host) or AWS CloudFront standalone with an origin shield. After a year of decision review we stayed with Vercel. This article lays out the arguments, plus 90 days of cache hit rates per page type.
What's the question, actually
The Storefront runs on Next.js 16; the data layer is Prisma + Redis (on the backend side). The edge cache here is not app cache — it is a TWO-TIER thing:
- Page-level cache: rendered HTML / RSC payload. Vercel handles this via ISR (Incremental Static Regeneration), with on-demand revalidation alongside.
- Asset cache: images, fonts, CSS, static JS chunks. Both options (Vercel / CloudFront) handle this well; there is hardly a difference.
The decision really turns on the page-level layer.
Why Vercel
1. Framework alignment
Next.js ISR and the Vercel platform are from the same vendor. revalidatePath() and revalidateTag() calls take effect in roughly 1 second, no hand-rolled invalidation API needed. On CloudFront, every cache-key flush goes through a CreateInvalidation API, and the invalidation count is metered (above 1,000 paths / month). On the Storefront a single new product can touch ~150 paths (PDP + PLP + category + search). On CloudFront that is roughly 15-20 USD / month extra cost just to flush correctly.
2. Simpler quota model
Vercel pricing: build minutes + bandwidth + function invocation, straightforward to read. CloudFront pricing: request count + bandwidth + invalidation count + Edge Lambda execution, with regional pricing variance. The second is hard to forecast. Across six storefronts the baseline monthly bill differs by 200-300 USD in Vercel's favor, plus a leg-up on planning predictability.
3. On-demand revalidation: native
The backend's POST /api/revalidate endpoint runs a straight line into next/cache and the Vercel cache layer. CloudFront would need an Edge Lambda function running a tagger layer — extra moving part, extra failure surface.
When CloudFront would win
1. Large static media
If the Storefront carried 10+ TB of static media (think video PDP carousels, scanned schematics), CloudFront with an S3 origin shield would roughly halve bandwidth cost vs. Vercel. Not the case here — our high-water mark to date is 280 GB.
2. Multi-origin
One storefront, multiple backends (e.g., EU + US backend region split): CloudFront origin failover handles that natively. Vercel is EU-only.
3. Government-region hosting
Hungarian public-sector data-sovereignty rules require domestic hosting. Vercel is global-only. If such a partner arrives, CloudFront in EU-Central-1 is the answer.
The migration we did NOT do
In August 2025 we costed a CloudFront migration. Estimate: 6-8 engineer-weeks build + 4 engineer-weeks stabilisation. Annual cost savings: zero (the round number landed in Vercel's favour). Annual latency win: 8-12% reduction (from Hungary). 8-12% sounds like a lot, but the baseline was already 180 ms, so the gain is 14-22 ms — not perceivable to a human.
The 90-day cache hit rates
- PDP (product page,
/products/[slug]): 94% - PLP (category listing,
/categories/[slug]): 71% (filter combinations fragment the cache key) - Search (
/search?q=): 42% (the long tail of queries) - Home (
/): 99% (a single route) - Cart / Checkout: 0% (deliberate no-cache, dynamic user data)
The 94% PDP hit rate means 94 out of 100 PDP requests never reach the backend at all — the edge cache answers. That is exactly why the backend stays at its current size: a single 4 vCPU NestJS node can serve six storefronts behind Vercel.