Vercel에서 ISR 활용: 25,000개 이상의 페이지 증분 정적 재생성
ISR 규모에서의 운영: Vercel에서 25,000+ 페이지를 사용한 증분 정적 재생성
지난해 우리는 Vercel에서 25,000개 이상의 정적으로 생성된 페이지를 가진 Next.js 사이트를 배포했습니다. 상품 페이지, 블로그 포스트, 지역 랜딩 페이지, 동적 카테고리 필터 -- 모든 것을 포함했습니다. 증분 정적 재생성(ISR)의 약속은 매력적입니다: 정적 사이트의 속도와 서버 렌더링 콘텐츠의 신선함을 얻을 수 있다는 것입니다. 솔직히 말해서? 대부분 전달됩니다. 하지만 25,000개 이상의 페이지에서 ISR은 50페이지 마케팅 사이트에서와는 다르게 작동합니다. 엣지 케이스가 주요 케이스가 됩니다. 비용이 증가합니다. 문서에서 이론적이라고 보이던 캐시 무효화 문제가 매우, 매우 현실적으로 변합니다.
이것은 우리가 시작하기 전에 존재했으면 좋았을 글입니다. 여기의 모든 것은 프로덕션 경험에서 나온 것입니다 -- 실제 메트릭, 실제 청구 놀라움, 그리고 우리가 한 실제 아키텍처 결정들(그리고 때때로 후회한 것들)입니다.
목차
- ISR이 실제로 어떻게 작동하는가
- 25,000개의 페이지가 모든 것을 바꾸는 이유
- 빌드 전략: 사전 렌더링할 것 vs 연기할 것
- 실제로 작동하는 재검증 패턴
- Vercel 특정 주의사항 및 제한
- 규모 있는 실제 프로덕션 비용
- 프로덕션에서 ISR 모니터링 및 디버깅
- 아키텍처 결정: ISR vs 대체 방안
- 배포에서의 성능 벤치마크
- FAQ
ISR이 실제로 어떻게 작동하는가
규모 문제로 들어가기 전에, ISR이 무엇을 하는지 같은 페이지에 있는지 확인해 봅시다. Next.js 페이지에서 revalidate: 60을 설정하면, 다음이 실제 흐름입니다:
배포 후 첫 요청: 페이지가 빌드 시간에 사전 렌더링되었다면, Vercel은 엣지 캐시에서 제공합니다. 그렇지 않다면(당신이
fallback: 'blocking'을 반환했거나 App Router에서dynamicParams: true를 사용했다면), 서버 측에서 렌더링되고, 결과가 캐시되고, 제공됩니다.재검증 윈도우 내의 이후 요청: 캐시에서 제공됩니다. 빠릅니다. 계산 없음.
재검증 윈도우가 만료된 후 첫 번째 요청: 오래된 페이지가 즉시 제공되고(이것이 "stale-while-revalidate" 부분입니다), 백그라운드 재생성이 트리거됩니다. 다음 방문자는 새로운 페이지를 얻습니다.
이것은 개념적으로 간단합니다. 하지만 25,000개 페이지에서 그 백그라운드 재생성 단계는 소방호가 됩니다.
// App Router (Next.js 14/15)
export const revalidate = 60; // 초
export async function generateStaticParams() {
// 25k 페이지에서, 당신은 아마 그것들을 모두 반환하고 싶지 않을 것입니다
const topPages = await getTop500Pages();
return topPages.map((page) => ({ slug: page.slug }));
}
export default async function ProductPage({ params }: { params: { slug: string } }) {
const product = await getProduct(params.slug);
return <ProductTemplate product={product} />;
}
Stale-While-Revalidate 트레이드오프
사람들을 헷갈리게 하는 것: ISR은 항상 재생성을 트리거하는 요청에 오래된 콘텐츠를 제공합니다. 이것은 버그가 아닌 기능입니다 -- 아무도 렌더링을 기다리지 않음을 의미합니다. 하지만 또한 당신의 콘텐츠가 항상 하나의 요청 뒤라는 의미입니다. 일부 페이지가 주에 한 번만 방문되는 25,000페이지 사이트에서, 재검증 윈도우가 지난 후 "하나의 요청 뒤"는 누군가가 재생성을 트리거하기 위해 방문할 수 없었기 때문에 며칠 전 콘텐츠를 본다는 의미일 수 있습니다.
25,000개의 페이지가 모든 것을 바꾸는 이유
작은 규모에서 ISR은 기본적으로 마법입니다. 큰 규모에서 세 가지가 변합니다:
빌드 시간이 병목이 됩니다
25,000개 페이지를 모두 빌드 시간에 사전 렌더링하려고 하면, 당신의 삶의 선택을 의문하게 만드는 빌드 시간을 보게 될 것입니다. 각 페이지는 데이터를 가져오고, React를 HTML로 렌더링하고, 정적 자산을 생성해야 합니다. 페이지당 200ms(CMS API를 맞추는 경우 낙관적입니다)에서도, 이것은 5,000초입니다 -- 83분 이상입니다. Vercel의 Pro 플랜은 45분의 빌드 타임아웃이 있습니다. Enterprise는 더 얻지만, 여전히 계산 크레딧을 태우고 있습니다.
캐시 무효화가 실제 문제가 됩니다
25,000개 페이지로 당신은 콘텐츠가 변경될 때 "모두 재구축"할 수 없습니다. 외과적 무효화가 필요합니다. Vercel의 revalidatePath()와 revalidateTag() API가 도움이 되지만, 규모에서 자신만의 이상한 점들을 가집니다.
백그라운드 재생성 로드 스파이크
5,000개 페이지가 모두 revalidate: 60을 가지고 있고 동시에 트래픽을 받는다고 상상해봅시다. 그것은 매분 5,000개의 서버리스 함수 호출이 백그라운드에서 일어나고 있습니다. 당신의 CMS API가 그것을 처리할 수 있어야 합니다.
빌드 전략: 사전 렌더링할 것 vs 연기할 것
이것은 큰 ISR 사이트에 대한 가장 중요한 아키텍처 결정입니다. 다음은 우리가 사용하는 프레임워크입니다:
| 페이지 카테고리 | 수(우리의 경우) | 전략 | 이유 |
|---|---|---|---|
| 높은 트래픽 페이지(상위 500) | 500 | 빌드 시 사전 렌더링 | 배포 직후에 즉시 히트됩니다. 콜드 스타트 페널티 없음. |
| 중간 트래픽 페이지 | 4,500 | fallback: 'blocking'으로 연기 |
첫 방문자는 ~300ms 대기, 그 다음 캐시됨. 수락 가능. |
| 롱테일 페이지 | 20,000 | fallback: 'blocking'으로 연기 |
대부분 배포 후 몇 시간/일 동안 방문되지 않음. 사전 렌더링할 이유 없음. |
핵심 통찰: 배포 후 첫 시간 내에 누군가 방문할 페이지를 사전 렌더링하지 마세요. 당신은 빌드 분과 돈을 낭비하고 있습니다.
// generateStaticParams - 높은 트래픽 페이지만 반환하세요
export async function generateStaticParams() {
// 우리는 분석 데이터를 사용하여 상위 페이지를 결정합니다
const topPages = await fetch('https://api.example.com/pages/top?limit=500', {
headers: { Authorization: `Bearer ${process.env.CMS_TOKEN}` },
}).then(r => r.json());
return topPages.map((page: { slug: string }) => ({
slug: page.slug,
}));
}
이 접근법으로 우리의 빌드는 타임아웃에서 약 8분 내에 완료되는 것으로 변했습니다. 그것은 엄청난 차이입니다. 우리는 Next.js 개발 작업 맥락에서 유사한 최적화 전략에 대해 썼습니다 -- 원칙은 광범위하게 적용됩니다.
`dynamicParams` 설정이 중요합니다
App Router에서, dynamicParams = true(기본값)를 설정하는 것은 generateStaticParams에 의해 반환되지 않은 페이지가 온디맨드로 렌더링되고 캐시됨을 의미합니다. false로 설정하면 사전 렌더링되지 않은 모든 페이지에 대해 404를 반환합니다. 25,000페이지 사이트의 경우, 당신은 거의 확실하게 true를 원합니다.
export const dynamicParams = true; // generateStaticParams에서 반환되지 않은 페이지의 온디맨드 렌더링 허용
실제로 작동하는 재검증 패턴
시간 기반 재검증
가장 간단한 접근법. revalidate를 초 수로 설정하세요. 하지만 어떤 수?
다음은 몇 달의 튜닝 후에 우리가 착지한 것입니다:
| 콘텐츠 유형 | 재검증 기간 | 이유 |
|---|---|---|
| 상품 가격 | 60초 | 가격이 자주 변경되고, 고객은 오래된 가격을 눈치챕니다 |
| 상품 설명 | 3600초(1시간) | 거의 변경되지 않음, 시간에 민감하지 않음 |
| 블로그 포스트 | 86400초(24시간) | 게시 후 거의 변경되지 않음 |
| 카테고리/리스팅 페이지 | 300초(5분) | 새로운 상품이 나타나지만, 약간의 지연은 괜찮음 |
| 위치 페이지 | 86400초(24시간) | 주소 정보는 거의 변경되지 않음 |
우리가 초반에 한 실수: 모든 것을 60초로 설정했습니다. 이것은 우리 CMS(우리의 경우 Contentful) API를 재생성 요청으로 해머했고 트래픽 스파이크 중에 속도 제한에 도달했습니다.
온디맨드 재검증
이것은 대부분의 콘텐츠 업데이트에 더 나은 접근법입니다. 시간 기반 재검증으로 폴링하는 대신, 콘텐츠가 실제로 변경될 때 재생성을 트리거합니다:
// app/api/revalidate/route.ts
import { revalidateTag, revalidatePath } from 'next/cache';
import { NextRequest, NextResponse } from 'next/server';
export async function POST(request: NextRequest) {
const secret = request.headers.get('x-revalidation-secret');
if (secret !== process.env.REVALIDATION_SECRET) {
return NextResponse.json({ error: '유효하지 않은 시크릿' }, { status: 401 });
}
const body = await request.json();
// 태그 기반 재검증 -- 이것이 방법입니다
if (body.tag) {
revalidateTag(body.tag);
return NextResponse.json({ revalidated: true, tag: body.tag });
}
// 경로 기반 재검증을 폴백으로
if (body.path) {
revalidatePath(body.path);
return NextResponse.json({ revalidated: true, path: body.path });
}
return NextResponse.json({ error: '태그 또는 경로가 제공되지 않았습니다' }, { status: 400 });
}
그 다음 콘텐츠가 게시될 때마다 이 엔드포인트를 히트하기 위해 당신의 CMS에서 웹훅을 설정합니다. 우리는 이것을 더 긴 시간 기반 재검증(예: 24시간)과 쌍을 이루어 안전 장치로 사용합니다.
규모에서의 태그 기반 재검증
이것은 Next.js 14+가 큰 사이트를 위해 정말 빛나는 곳입니다. 당신의 fetch 요청에 태그를 지정하고 태그로 무효화할 수 있습니다:
async function getProduct(slug: string) {
const res = await fetch(`https://api.cms.com/products/${slug}`, {
next: {
tags: [`product-${slug}`, 'products', 'all-content'],
revalidate: 86400 // 24시간 안전 장치
},
});
return res.json();
}
이제 단일 상품이 업데이트될 때, revalidateTag('product-blue-widget')을 호출하고 오직 그 페이지만 재생성됩니다. 당신이 대량 가격 업데이트를 할 때, revalidateTag('products')를 호출하고 모든 상품 페이지는 다음 방문 시 재생성됩니다.
주의사항: 25,000개 상품 페이지가 있는 사이트에서 revalidateTag('products')를 호출하는 것은 그들을 모두 즉시 재생성하지 않습니다. 그것은 그들을 모두 오래된 것으로 표시합니다. 그들은 다음 방문 시 재생성됩니다. 이것은 중요합니다 -- 일부 페이지는 낮은 트래픽을 가질 경우 실제로 며칠 동안 업데이트되지 않을 수 있습니다.
Vercel 특정 주의사항 및 제한
우리는 2024년 초부터 Vercel에서 이것을 실행하고 있습니다. 문서가 충분히 강조하지 않는 것들이 여기 있습니다:
ISR 캐시 저장소
Vercel은 ISR 페이지를 Edge Network 캐시에 저장합니다. 2025년 현재, Vercel Data Cache는 당신이 알아야 할 몇 가지 제한이 있습니다:
- Pro 플랜: 포함된 ISR 캐시는 관대하지만, 매우 높은 볼륨에서 캐시 읽기/쓰기에 대한 비용이 있습니다
- Enterprise: 사용자 지정 제한, 하지만 당신이 그것을 위해 지불하고 있습니다
- 캐시 항목이 영구적이지 않습니다:
revalidate: false로도, Vercel은 최근에 액세스되지 않은 캐시 항목을 제거할 수 있습니다. 우리는 Pro 플랜에서 약 30일의 트래픽이 없은 후 페이지가 캐시에서 사라지는 것을 보았습니다.
서버리스 함수 지속 시간
백그라운드 재생성은 서버리스 함수로 실행됩니다. Vercel Pro에서, 기본 타임아웃은 60초입니다(최대 300초까지 구성할 수 있습니다). 페이지를 재생성하는 데 그보다 더 오래 걸린다면 -- 예를 들어, 당신의 CMS가 느리거나 당신이 무거운 이미지 처리를 하고 있기 때문에 -- 재생성이 조용히 실패하고 오래된 페이지가 계속 제공됩니다.
우리는 세 가지 다른 API에서 데이터를 가져온 페이지로 이것을 칠했습니다. 수정은 가장 느린 API와 우리의 Next.js 앱 사이에 캐싱 계층(Upstash를 통한 Redis)을 추가하는 것이었습니다.
동시 재생성 제한
Vercel은 이것에 대해 하드 수치를 게시하지 않지만, 1,000개 이상의 ISR 재생성이 동시에 트리거될 때(예: 광범위하게 사용되는 태그에서 revalidateTag를 호출한 후) 스로틀링을 관찰했습니다. 재생성은 대기하고 여러 분에 걸쳐 처리됩니다. 이것을 계획하세요.
콜드 스타트
잠시 동안 방문되지 않은 페이지(그리고 엣지 캐시에서 제거된)는 다음 방문에서 콜드 스타트를 경험합니다. 우리의 벤치마크에서:
- 따뜻한 캐시 히트: 15-40ms TTFB
- 오래된 재검증(캐시에서 제공): 15-40ms TTFB (같음, 오래된 것은 제공되기 때문에)
- 콜드 재생성(캐시 없음, 차단): 400-1200ms TTFB (API 응답 시간에 따라)
규모 있는 실제 프로덕션 비용
돈에 대해 얘기해봅시다. 이것은 사람들이 놀라는 곳입니다.
Vercel Pro의 25,000페이지 사이트($20/월 기본) ISR 포함:
| 비용 구성요소 | 월간 | 노트 |
|---|---|---|
| Vercel Pro 구독 | $20 | 기본 플랜 |
| 서버리스 함수 실행 | $180-$340 | 트래픽에 따라 다름. ISR 재생성은 함수 호출로 계산됨. |
| 엣지 대역폭 | $90-$150 | 25k 페이지와 이미지가 더해집니다 |
| Vercel Data Cache | $40-$80 | ISR을 위한 캐시 읽기/쓰기 |
| 총 Vercel | $330-$590/월 | 트래픽 월에 따라 |
| Contentful (CMS) | $489/월 | 그들의 Team 플랜. ISR 재생성에서 API 호출이 무료 계층을 빠르게 초과했습니다. |
| Upstash Redis(캐싱) | $30/월 | CMS API 호출을 줄이기 위해 추가됨 |
| 총계 | $849-$1,109/월 | ~2M pageviews/월을 제공하는 사이트의 경우 |
이것은 비싼가요? 전통적인 서버 설정과 비교하면, 그것은 경쟁력이 있습니다. CDN에 있는 정적 사이트와 비교하면, 그것은 비싸습니다. ISR 재생성 함수 호출은 가장 큰 변수 비용입니다 -- 페이지가 재생성될 때마다, 그것은 1-5초 동안 실행되는 서버리스 함수입니다.
우리는 ISR의 비용이 이점을 능가하는 콘텐츠 집약적인 사이트를 위해 Astro 기반 접근법을 탐색한 클라이언트들과 일했습니다. 콘텐츠가 거의 변경되지 않는 사이트의 경우, Astro를 사용한 전체 정적 빌드는 호스팅 비용이 훨씬 저렴할 수 있습니다.
프로덕션에서 ISR 모니터링 및 디버깅
ISR 실패는 기본적으로 조용합니다. 오래된 페이지가 계속 제공되고, 당신의 재생성이 며칠 동안 실패하고 있음을 모를 수도 있습니다. 다음은 우리의 모니터링 설정입니다:
사용자 정의 재생성 로깅
// lib/with-regeneration-logging.ts
export async function fetchWithLogging(
url: string,
options: RequestInit & { next?: { tags?: string[]; revalidate?: number } }
) {
const start = Date.now();
try {
const res = await fetch(url, options);
const duration = Date.now() - start;
// 모니터링 서비스에 로그
if (duration > 5000) {
console.warn(`[ISR] 느린 fetch: ${url} ${duration}ms 소요`);
// Datadog/Sentry/등으로 전송
}
return res;
} catch (error) {
console.error(`[ISR] Fetch 실패: ${url}`, error);
// 이것은 중요합니다 -- fetch 실패하면, 재생성 실패
throw error;
}
}
Vercel의 내장 도구
Vercel의 대시보드는 ISR 캐시 히트율과 재생성 횟수를 보여줍니다. Analytics 탭에서, 다음을 찾으세요:
- 함수 로그의 캐시 상태:
HIT,MISS,STALE - 서버리스 함수 메트릭의 ISR 재생성 지속 시간
- ISR 경로의 오류율
`x-vercel-cache` 헤더
Vercel의 모든 응답은 이 헤더를 포함합니다:
HIT-- 엣지 캐시에서 제공, 신선함STALE-- 엣지 캐시에서 제공, 백그라운드에서 재생성 트리거됨MISS-- 캐시에 없음, 온디맨드로 렌더링됨
우리는 매시간 100개의 무작위 페이지를 확인하고 10% 이상이 MISS를 반환할 경우 경고하는 간단한 모니터를 설정했습니다 -- 이것은 캐시 제거 문제를 나타낼 것입니다.
아키텍처 결정: ISR vs 대체 방안
ISR을 이 규모로 1년 이상 실행한 후, 언제 이것을 사용할지와 언제 사용하지 않을지에 대한 내 솔직한 의견입니다:
ISR을 사용할 때:
- 당신은 다양한 빈도로 변경되는 5,000-100,000개 페이지를 가지고 있습니다
- 콘텐츠 신선함은 분(초가 아닙니다) 단위로 측정됩니다
- 당신은 이미 Next.js에 커밋되어 있습니다
- 당신의 팀은 캐시 무효화를 이해합니다(이 규모에서는 선택 사항이 아닙니다)
대체 방안을 고려할 때:
- 당신은 실시간 콘텐츠가 필요합니다(대신 SSR 또는 클라이언트 측 페칭을 사용하세요)
- 당신의 사이트는 거의 변경되지 않습니다(전체 정적 빌드가 더 간단하고 저렴합니다)
- 당신은 500,000+ 페이지를 가지고 있습니다(ISR은 매우 높은 페이지 수에서 긴장하기 시작합니다 -- 분산 빌드 접근법을 고려하세요)
- 비용이 주요 관심사입니다(자체 호스팅 Next.js와 자신의 CDN은 60-70% 저렴할 수 있습니다)
복잡한 콘텐츠 아키텍처를 가진 클라이언트의 경우, 우리는 종종 헤드리스 CMS 설정을 권장합니다. 이것은 콘텐츠 유형에 따라 ISR, SSR, 그리고 전체 정적 사이에 전환할 수 있는 유연성을 제공합니다.
우리가 실제로 사용하는 하이브리드 접근법
우리는 25k 페이지 사이트의 모든 것에 대해 ISR을 사용하지 않습니다. 다음은 분석입니다:
- ISR: 상품 페이지, 카테고리 페이지, 위치 페이지(22,000개 페이지)
- SSR: 검색 결과, 사용자 대시보드, 장바구니
- 정적: About, contact, legal 페이지(빌드 시간에 생성, 재검증 없음)
- 클라이언트 측: 실시간 재고 수, 사용자 특정 가격
이 하이브리드 접근법은 우리의 초기 "모든 것에 ISR" 전략과 비교하여 서버리스 함수 비용을 약 40% 감소시켰습니다.
배포에서의 성능 벤치마크
다음은 2025년 Q1에 걸쳐 측정된 우리의 프로덕션 배포에서 실제 수치입니다:
| 메트릭 | ISR 캐시 히트 | ISR 캐시 미스(차단) | 전체 SSR(캐시 없음) |
|---|---|---|---|
| TTFB (p50) | 22ms | 480ms | 620ms |
| TTFB (p95) | 58ms | 1,100ms | 1,450ms |
| TTFB (p99) | 120ms | 2,800ms | 3,200ms |
| LCP (p50) | 1.1s | 1.8s | 2.2s |
| CLS | 0.02 | 0.02 | 0.05 |
| Core Web Vitals Pass Rate | 96% | 78% | 64% |
캐시 히트와 미스 사이의 차이는 극적입니다. 이것이 왜 당신의 사전 렌더링 전략이 그렇게 중요한지입니다 -- 당신은 높은 트래픽 페이지가 항상 따뜻하기를 원합니다.
한 가지 흥미로운 발견: 우리의 Core Web Vitals 점수는 revalidate: 60에서 revalidate: 3600으로 변경되지 않는 콘텐츠로 이동했을 때 12% 향상되었습니다. 더 적은 재생성은 더 일관된 캐시 히트를 의미했고, 더 일관된 캐시 히트는 더 일관된 성능을 의미했습니다.
FAQ
ISR이 Vercel에서 성능이 저하되기 전에 몇 개의 페이지를 처리할 수 있나요?
우리는 25,000개 페이지를 상당한 문제 없이 실행했고, 100,000+ 페이지로 작동하는 배포를 들었습니다. 병목은 캐시의 페이지 수가 아닙니다 -- 동시 재생성의 속도입니다. 50,000개 페이지가 모두 revalidate: 60을 가지고 있다면, 당신은 문제를 실행할 것입니다. 콘텐츠 변경 빈도와 트래픽에 따라 재검증 기간을 분산시키면 괜찮을 것입니다.
ISR이 Vercel에서 SSR보다 비싼가요?
일반적으로, ISR은 동일한 트래픽 볼륨의 SSR보다 훨씬 저렴합니다. ISR을 사용하면, 대부분의 요청은 엣지 캐시에서 제공됩니다(본질적으로 무료 계산). SSR을 사용하면, 모든 요청이 서버리스 함수를 실행합니다. 우리의 2M pageviews/월 사이트의 경우, ISR의 함수 호출(재생성에서)은 전체 SSR이 있었을 것의 대략 15%였습니다.
ISR 재생성이 실패하면 어떻게 되나요?
오래된 버전이 계속 제공됩니다. 이것은 기능과 위험 모두입니다. 당신의 사용자는 오류를 보지 않지만, 그들은 오래된 콘텐츠를 볼 수 있습니다. 우리는 CMS API 중단이 페이지가 6시간 전의 콘텐츠를 제공하는 상황을 가진 적이 있고, 누구도 알아차릴 때까지는 오랜 시간이 걸렸습니다. 모니터링을 설정하세요.
Next.js App Router와 함께 ISR을 사용할 수 있나요?
예, 그리고 App Router에서는 실제로 더 깨끗합니다. 당신은 페이지 또는 레이아웃 레벨에서 export const revalidate = 60을 사용하고, fetch 호출에서 next: { revalidate, tags }를 사용합니다. generateStaticParams 함수는 getStaticPaths를 대체합니다. 이 글에서 설명한 모든 것은 Pages Router와 App Router 모두에서 작동하지만, App Router 구문은 2025년의 새 프로젝트에서 권장하는 것입니다.
ISR을 동적 쿼리 매개변수로 처리하려면 어떻게 하나요?
ISR은 쿼리 매개변수가 아닌 URL 경로에만 캐시합니다. ?color=red vs ?color=blue에 대해 다양한 캐시된 버전이 필요하다면, 당신은 실제 경로 세그먼트(/product/widget?color=red 대신 /product/widget/red)를 사용하거나 변경을 클라이언트 측에서 처리해야 합니다. 이것은 우리의 필터링 구현으로 우리를 놀라게 했습니다.
온디맨드 재검증이 규모에서 신뢰할 수 있나요?
대부분. 우리는 revalidateTag()를 호출하는 것과 캐시가 모든 엣지 위치에 걸쳐 무효화되는 것 사이의 10-30초 지연을 가끔 보았습니다. 99% 사용 사례에서 이것은 괜찮습니다. 즉각적인 글로벌 무효화가 필요하다면, 당신은 캐시 버스팅 쿼리 매개변수를 추가하거나 해당 특정 페이지에 SSR을 사용해야 할 수 있습니다.
큰 ISR 사이트의 경우 자체 호스팅 Next.js 대신 Vercel을 사용해야 하나요?
팀에 따라 다릅니다. 자체 호스팅(예: AWS에서)은 캐싱 동작을 더 많이 제어하고 규모에서 50-70% 저렴할 수 있습니다. 하지만 당신은 CDN 캐시 무효화를 설정하고, 빌드 파이프라인을 관리하고, 엣지 분산을 처리하는 책임이 있습니다. 우리는 팀이 Vercel이 기본으로 제공하는 것을 복제하는 데 몇 달을 보내는 것을 보았습니다. 옵션을 탐색하고 싶다면, 우리에게 연락하세요 -- 우리는 둘 다 했습니다.
25,000+ 페이지 ISR 사이트에 가장 좋은 CMS는 무엇인가요?
우리는 이 규모에서 Contentful, Sanity, Hygraph을 사용했습니다. Contentful은 웹훅 기반 재검증을 잘 처리하지만 속도 제한이 문제가 될 수 있습니다(캐싱을 계획하세요). Sanity의 GROQ 구독은 콘텐츠 변경을 실시간으로 인식하기에 좋습니다. Hygraph의 웹훅 시스템은 견고합니다. 핵심 요구사항은 신뢰할 수 있는 웹훅 전달과 재생성 폭주에서 버스트 트래픽을 처리할 수 있는 API입니다. 당신의 콘텐츠 모델에 따른 더 구체적인 권장사항은 우리의 헤드리스 CMS 개발 기능을 확인하세요.