방문자가 WordPress 홈페이지에 도착하고 기다립니다. 서버는 PHP를 시작하고, 데이터베이스를 17번 쿼리하고, 테마 함수를 실행하고, 플러그인 훅을 로드하고, DOM을 렌더링한 다음 마지막으로 텍스트를 그립니다 — 클릭 후 2.8초 경과. 이미 3개의 캐싱 플러그인을 설치했습니다. LCP는 여전히 3.1초, CLS는 폰트 전환으로 레이아웃이 튀어다니고, Google Search Console은 계속 같은 Core Web Vitals 실패를 플래그합니다. 문제는 호스팅이나 CDN이 아닙니다. WordPress는 2003년에 모든 요청에 대해 서버 측 PHP로 블로그 게시물을 렌더링하도록 설계되었습니다. 20년 후, 같은 런타임이 마케팅 사이트, 전자상거래 플랫폼, 웹 앱을 구동하는 동시에 Google의 Core Web Vitals 알고리즘이 누군가 콘텐츠를 찾는지 결정합니다. 실행 모델을 다시 쓸 수 있는 플러그인은 없지만, Next.js 마이그레이션은 할 수 있습니다. 다음은 무엇이 손상되는지와 정확히 어떤 패턴이 문제를 해결하는지에 대한 기술적 분석입니다.

이 기사는 WordPress 사이트가 느린 이유를 정확히 분석하고, 각 문제를 고통받는 Core Web Vitals 메트릭에 매핑하며, headless Next.js 아키텍처가 근본에서 어떻게 문제를 해결하는지 보여줍니다. 임시방편이 아닙니다. 근본에서.

목차

WordPress가 느린 이유와 Next.js가 어떻게 해결하는지

2026년 Core Web Vitals 이해하기

Google은 2024년 3월 Core Web Vitals를 업데이트하여 First Input Delay (FID)를 Interaction to Next Paint (INP)로 대체했습니다. 이 변화는 대부분 사람들이 깨닫는 것보다 더 중요합니다. 다음은 사이트의 성능 등급을 결정하는 4가지 메트릭입니다:

메트릭 측정 내용 좋음 개선 필요 나쁨
LCP (Largest Contentful Paint) 주요 콘텐츠가 얼마나 빨리 로드되는지 ≤ 2.5s 2.5s – 4.0s > 4.0s
INP (Interaction to Next Paint) 사용자 입력에 대한 반응성 ≤ 200ms 200ms – 500ms > 500ms
CLS (Cumulative Layout Shift) 로드 중 시각적 안정성 ≤ 0.1 0.1 – 0.25 > 0.25
TTFB (Time to First Byte) 서버 응답 시간 ≤ 800ms 800ms – 1800ms > 1800ms

Chrome UX Report의 2026년 초 자료에 따르면, WordPress 오리진의 42%만이 3가지 Core Web Vitals 임계값을 모두 통과합니다. 이를 Next.js 기반 오리진의 67%와 비교하면 차이는 미미하지 않습니다 — 완전히 다른 수준입니다.

이러한 메트릭이 실제로 중요한 이유

Google은 분명히 밝혔습니다: Core Web Vitals는 순위 신호입니다. 하지만 SEO를 떠나 이 메트릭들은 전환율과 직접적으로 관련이 있습니다. Vodafone은 LCP의 31% 개선이 매출 8% 증가로 이어졌다는 것을 발견했습니다. Shopify의 내부 데이터에 따르면 페이지 로드 시간이 100ms 감소할 때마다 전환이 1.3% 증가합니다.

WordPress 사이트는 단순히 느린 것이 아닙니다. 돈을 잃게 합니다.

WordPress가 아키텍처적으로 느린 이유

누군가가 일반적인 WordPress 페이지를 방문할 때 무엇이 일어나는지 살펴보겠습니다:

  1. DNS 조회 → 도메인 해석
  2. TCP/TLS 핸드셰이크 → 보안 연결 설정
  3. 요청이 서버에 도달 → Apache/Nginx가 수신
  4. PHP가 WordPress 부팅 → wp-config.php 로드, WordPress 코어 초기화
  5. 플러그인 초기화 → 모든 활성 플러그인이 init, wp_loaded 등으로 훅됨
  6. 테마 로드 → functions.php 실행, 템플릿 계층 해석
  7. 데이터베이스 쿼리 실행 → WP_Query 실행, 보통 페이지당 30-100+ 쿼리
  8. PHP가 HTML 렌더링 → 템플릿 파일이 전체 페이지 생성
  9. HTML을 브라우저로 전송 → 마지막으로 응답 시작
  10. 브라우저가 HTML 파싱 → CSS, JS, 폰트, 이미지 발견
  11. 렌더링 차단 리소스 로드 → 15개의 다른 플러그인의 스타일시트
  12. 페이지가 최종적으로 렌더링 → 사용자가 콘텐츠 확인

4단계에서 9단계는 캐시되지 않은 모든 요청에서 발생합니다. 이는 PHP가 200개 이상의 파일을 파싱하고, 수십 개의 데이터베이스 쿼리를 실행하고, HTML을 생성 — 브라우저가 한 바이트도 받기 전에.

PHP 문제

PHP 8.3은 PHP 7.x보다 훨씬 빠르며, 대부분의 WordPress 호스트는 이제 이를 지원합니다. 하지만 PHP 8.3과 OPcache가 활성화되어 있어도, 여전히 동기 차단 프로세스를 실행 중입니다. WordPress 코어만 해도 모든 요청에 약 100,000줄의 PHP 코드를 로드합니다. WooCommerce를 추가하면 400,000줄을 넘습니다.

여기서 핵심은: WP Super Cache나 W3 Total Cache 같은 캐싱 플러그인은 이 프로세스를 단락시켜서 작동합니다 — 미리 생성된 HTML 파일을 대신 제공합니다. 하지만 자체 복잡성을 도입하고, 개인화된 콘텐츠로 깨지고, 여전히 브라우저에서 일어나는 일을 고칠 수 없습니다.

테마 문제

대부분의 WordPress 테마는 유연성을 위해 구축되었으며, 성능을 위해서는 아닙니다. Avada, Divi, 또는 Elementor 같은 테마는 이러한 기능을 사용하는지 여부에 관계없이 모든 페이지에서 전체 CSS와 JavaScript 프레임워크를 로드합니다. 간단한 블로그 게시물에 2.5MB의 CSS와 1.8MB의 JavaScript를 로드하는 Elementor 사이트를 봤습니다.

<!-- 페이지 빌더 사이트의 전형적인 WordPress head -->
<link rel="stylesheet" href="/wp-content/plugins/elementor/assets/css/frontend.min.css">
<link rel="stylesheet" href="/wp-content/plugins/elementor-pro/assets/css/frontend.min.css">
<link rel="stylesheet" href="/wp-content/themes/hello-elementor/style.css">
<link rel="stylesheet" href="/wp-content/themes/hello-elementor/theme.min.css">
<link rel="stylesheet" href="/wp-content/plugins/contact-form-7/includes/css/styles.css">
<link rel="stylesheet" href="/wp-content/plugins/woocommerce/assets/css/woocommerce.css">
<!-- ... 12개 이상의 스타일시트 -->

각각은 렌더링을 차단하는 리소스입니다. LCP는 모두 다운로드되고 파싱될 때까지 발생할 수 없습니다.

플러그인 비대화: 조용한 성능 살인자

평균 WordPress 사이트는 20-30개의 플러그인을 실행합니다. 70개 이상의 플러그인이 있는 사이트도 봤습니다. 각 플러그인은 잠재적으로:

  • 자신의 CSS와 JS 파일을 추가 (보통 모든 페이지, 사용하지 않는 곳에서도)
  • WordPress 훅을 등록하여 모든 요청에서 실행
  • 자신의 데이터베이스 쿼리 실행
  • 부팅 단계 중에 자신의 PHP 파일 로드
  • 인라인 스크립트와 스타일을 <head>에 추가

실제 예

최근에 34개의 활성 플러그인이 있는 WordPress로 마케팅 사이트를 감시했습니다. 다음은 네트워크 워터폴이 어떻게 보였는지입니다:

  • 47개의 CSS 파일 홈페이지에서 로드
  • 38개의 JavaScript 파일 홈페이지에서 로드
  • 전체 페이지 가중치: 4.7MB
  • 전체 요청: 127
  • LCP: 4G에서 6.8초
  • TTFB: 2.1초

클라이언트는 이미 최적화 플러그인(Autoptimize)과 캐싱 플러그인(LiteSpeed Cache)을 설치했습니다. 둘 다 활성화되었음에도 LCP는 4.2초였습니다. 여전히 실패.

핵심 문제는? 필요하지 않은 코드를 로드하는 기본 문제를 최적화로 제거할 수 없습니다. 47개의 CSS 파일을 축소하고 결합해도 여전히 거대한 CSS 페이로드가 렌더링을 차단합니다.

플러그인 종속성 함정

이것을 더 나쁘게 하는 것: 플러그인은 다른 플러그인에 종속됩니다. WooCommerce를 설치하면, 결제 게이트웨이 플러그인이 필요하고, 그 다음 배송 계산기 플러그인, 그 다음 제품 필터 플러그인. 각각 가중치를 추가합니다. 기능을 깨뜨리지 않으면 어떤 것도 제거할 수 없습니다.

이것이 WordPress 함정입니다. 아키텍처는 모든 것에 플러그인을 추가하도록 권장하며, 사용하지 않는 코드를 tree-shake할 메커니즘이 없습니다.

WordPress가 느린 이유와 Next.js가 어떻게 해결하는지 - 아키텍처

플러그인이 고칠 수 없는 데이터베이스 쿼리 문제

WordPress는 악명 높은 평탄한 스키마의 단일 MySQL 데이터베이스를 사용합니다. wp_options 테이블은 모든 단일 요청에서 autoload='yes' 엔트리로 로드됩니다. 3,000개 이상의 자동 로드 행이 총 8MB의 데이터를 차지하는 wp_options 테이블을 봤습니다.

-- 자동 로드된 옵션 크기 확인
SELECT SUM(LENGTH(option_value)) as autoload_size 
FROM wp_options 
WHERE autoload = 'yes';

-- 이것이 > 1MB를 반환하면, 당신은 문제가 있습니다

wp_postmeta 테이블은 또 다른 악몽입니다. 모든 것을 키-값 쌍으로 저장하므로 WordPress는 효율적인 쿼리를 할 수 없습니다. $50 이하의 모든 제품을 찾고 싶으신가요? 이는 wp_postmeta에 대한 JOIN과 숫자를 저장하는 텍스트 필드에 대한 문자열 비교입니다. 어떤 인덱스도 당신을 구할 수 없습니다.

쿼리 개수 현실 확인

WordPress 사이트에 Query Monitor 플러그인을 설치하고 쿼리 개수를 봅니다. "간단한" WooCommerce 제품 페이지는 보통 150-300개의 데이터베이스 쿼리를 실행합니다. 관련 게시물, 인기 게시물 사이드바, 그리고 breadcrumb이 있는 블로그 게시물? 보통 80-120개 쿼리입니다.

필요한 모든 데이터를 얻기 위해 정확히 하나의 API 호출(또는 정적 생성을 사용하는 경우 0개)을 하는 headless 접근방식과 비교합니다.

WordPress 호스팅: 당신은 아마도 평범한 성능에 과도한 비용을 지불하고 있습니다

호스팅에 대해 얘기해봅시다, 왜냐하면 이곳에 많은 돈이 낭비되기 때문입니다.

호스팅 유형 월간 비용 일반적 TTFB 아키텍처를 고칠 수 있는가?
공유 (GoDaddy, Bluehost) $3-15 1.5-4.0s 아니오
관리형 WordPress (WP Engine, Flywheel) $25-300 400ms-1.2s 아니오
프리미엄 관리형 (Kinsta, Pagely) $35-600 200ms-600ms 아니오
VPS/전용 (DigitalOcean, AWS) $20-500 200ms-800ms 아니오
Vercel/Edge의 Next.js $0-20 50-150ms 예

마지막 열을 주의하세요. 호스팅 업그레이드는 아키텍처 문제를 고치지 않습니다. PHP를 더 빠르게 실행하기 위해 프리미엄 가격을 지불 중입니다, 실제 해결책은 모든 요청에서 PHP를 실행하지 않는 것입니다.

Kinsta는 스타터 플랜에 $35/월을 청구하며 방문자 25,000명을 지원합니다. Vercel의 무료 계층은 100GB의 대역폭을 처리합니다. Vercel의 Pro 플랜도 $20/월로 글로벌 CDN 전체에 edge 배포를 제공합니다. 수학은 거짓말을 하지 않습니다.

Next.js가 각 Core Web Vital을 어떻게 해결하는지

구체적으로 알아봅시다. 여기 Next.js (특히 Next.js 14/15의 App Router 포함)가 각 메트릭을 어떻게 해결하는지입니다:

TTFB 고치기

Next.js는 여러 렌더링 전략을 제공합니다:

// 정적 생성 - TTFB는 효과적으로 0 (CDN에서 제공)
export default async function BlogPost({ params }: { params: { slug: string } }) {
  const post = await getPost(params.slug);
  return <Article post={post} />;
}

// 이것은 빌드 시간에 미리 렌더링됩니다
export async function generateStaticParams() {
  const posts = await getAllPosts();
  return posts.map((post) => ({ slug: post.slug }));
}

정적 생성으로, 페이지는 전 세계 edge CDN 노드에서 제공되는 미리 구축된 HTML 파일입니다. TTFB는 사용자가 어디에 있든 50-100ms로 떨어집니다. PHP 실행, 데이터베이스 쿼리, 서버 측 처리 없음.

동적 콘텐츠의 경우, Next.js는 ISR(Incremental Static Regeneration)을 지원하며, 이는 백그라운드에서 재검증하면서 캐시된 정적 페이지를 제공합니다:

// 60초마다 재검증
export const revalidate = 60;

LCP 고치기

Next.js는 WordPress 플러그인이 시도하고 실패하는 모든 것을 처리하는 <Image> 컴포넌트를 포함합니다:

import Image from 'next/image';

export default function HeroBanner() {
  return (
    <Image
      src="/hero.jpg"
      alt="Hero banner"
      width={1200}
      height={600}
      priority // LCP 이미지를 미리 로드
      sizes="100vw"
      // 자동으로 srcset을 생성하고, WebP/AVIF를 사용하고,
      // 기본적으로 lazy 로드하고, CLS를 방지합니다
    />
  );
}

priority prop은 Next.js에 이미지를 미리 로드하도록 알려주며, LCP를 직접 개선합니다. 자동 형식 협상은 지원되는 브라우저에 WebP 또는 AVIF를 제공하여 JPEG에 비해 이미지 크기를 30-50% 감소시킵니다. 플러그인 필요 없음.

Next.js는 또한 CSS Modules와 자동 중요 CSS 추출을 통해 렌더링을 차단하는 CSS를 제거합니다. 특정 페이지에서만 사용되는 CSS만 로드됩니다.

INP 고치기

INP는 사이트가 사용자 상호작용에 얼마나 빨리 응답하는지 측정합니다. WordPress 사이트는 다음의 이유로 INP를 실패합니다:

  • 플러그인의 무거운 JavaScript가 메인 스레드를 차단
  • jQuery와 플러그인이 실행 시간을 놓고 경쟁
  • 코드 분할 없음 — 모든 것이 미리 로드됨

Next.js는 자동 코드 분할로 이를 처리합니다. 각 페이지는 필요한 JavaScript만 로드합니다:

// 이 컴포넌트는 사용자가 스크롤할 때만 로드됩니다
import dynamic from 'next/dynamic';

const HeavyChart = dynamic(() => import('@/components/HeavyChart'), {
  loading: () => <ChartSkeleton />,
  ssr: false, // 서버에서 렌더링하지 않음
});

React Server Components (App Router의 기본값)는 한 단계 더 나아갑니다: 상호작용이 필요하지 않은 컴포넌트는 브라우저로 JavaScript 0KB를 보냅니다. 상호작용이 없는 블로그 게시물? 0KB의 컴포넌트 JavaScript.

CLS 고치기

WordPress의 CLS는 보통 다음에서 옵니다:

  • 명시적 치수가 없는 이미지
  • 나중에 로드되어 콘텐츠를 아래로 밀어내는 광고
  • 웹 폰트가 FOUT/FOIT를 야기
  • 플러그인이 주입한 배너가 로드 후 나타남

Next.js는 기본적으로 CLS를 방지합니다. <Image> 컴포넌트는 치수를 요구하거나 fill을 크기 컨테이너와 함께 사용합니다. next/font 모듈은 폰트 선언을 인라인하고 레이아웃 변경 없이 font-display: swap을 사용합니다:

import { Inter } from 'next/font/google';

const inter = Inter({ subsets: ['latin'] });

export default function RootLayout({ children }) {
  return (
    <html lang="en" className={inter.className}>
      <body>{children}</body>
    </html>
  );
}

FOUT 없음. 폰트의 레이아웃 변경 없음. 그냥 작동합니다.

Headless 아키텍처: CMS로서의 WordPress, 프론트엔드로서의 Next.js

많은 사람들이 놓치는 부분은 다음과 같습니다: headless로 가는 것은 WordPress를 포기하는 것을 의미하지 않습니다. 이는 WordPress를 콘텐츠 관리에 실제로 좋은 것에 사용하는 것을 의미합니다 — 프론트엔드를 Next.js에 처리하게 하는 동안.

아키텍처는 다음과 같이 보입니다:

[WordPress Admin] → [REST API / WPGraphQL] → [Next.js Frontend] → [Vercel Edge CDN]
     ↑                                              ↑
  콘텐츠 편집자                                     사용자
  친숙한 WP 대시보드    빠른 페이지가
  를 사용합니다        edge에서 제공됩니다

콘텐츠 팀은 워크플로우를 유지합니다. 사용자는 빠른 사이트를 얻습니다. 깨끗하고 유지 가능한 코드를 얻습니다.

우리는 Next.js 개발 사례와 headless CMS 개발에서 이 종류의 작업을 많이 합니다. 패턴은 잘 확립되어 있고 전투 테스트를 거쳤습니다.

다른 Headless CMS 옵션은 어떨까요?

WordPress가 유일한 옵션이 아닙니다. 처음부터 시작한다면, Sanity, Contentful, 또는 Storyblok 같은 목적-구축 headless CMS 플랫폼이 종종 더 나은 선택입니다. 이들은 API-first로 구축되므로 레거시 짐이 없습니다.

하지만 WordPress에 수년간의 콘텐츠가 있고 그것을 학습한 팀이 있다면, WPGraphQL을 사용한 headless WordPress는 완전히 타당한 접근입니다.

실제 성능 벤치마크: WordPress vs Next.js

다음은 우리가 한 마이그레이션과 공개적으로 사용 가능한 사례 연구의 실제 숫자입니다:

메트릭 WordPress (최적화) Next.js (정적) 개선
TTFB 650ms 80ms 87% 더 빠름
LCP 3.8s 1.2s 68% 더 빠름
INP 380ms 90ms 76% 더 빠름
CLS 0.18 0.01 94% 더 나음
페이지 가중치 3.2MB 450KB 86% 더 가벼움
요청 85 12 86% 더 적음
Lighthouse 점수 45-65 95-100 하늘과 땅

"최적화"된 WordPress는 다음을 의미합니다: PHP 8.3, Redis 객체 캐시, CDN, 이미지 최적화 플러그인, 캐싱 플러그인, 데이터베이스 최적화. 해야 할 모든 것들. 그리고 여전히 가깝지 않습니다.

마이그레이션 경로: 모놀리식 WordPress에서 Headless Next.js로

마이그레이션은 전부 아니면 무로 할 필요가 없습니다. 다음은 일반적으로 권장하는 단계별 접근방식입니다:

단계 1: 평가 (1-2주)

  • PageSpeed Insights와 CrUX 데이터로 현재 WordPress 사이트 성능 감시
  • 모든 플러그인을 재고하고 프론트엔드 vs. 백엔드 기능에 매핑
  • 콘텐츠 모델과 커스텀 필드 식별
  • WordPress를 headless CMS로 유지할지 아니면 전체적으로 콘텐츠를 마이그레이션할지 평가

단계 2: 프론트엔드 구축 (4-8주)

  • App Router를 사용한 Next.js 프로젝트 설정
  • WordPress에 WPGraphQL 설치 및 구성
  • 현재 디자인과 일치하는 컴포넌트 라이브러리 구축 (또는 재설계 — 좋은 시간)
  • 콘텐츠 페이지에 정적 생성 구현
  • 콘텐츠 편집자용 미리보기 모드 설정

단계 3: 시작 및 리디렉션 (1-2주)

  • Vercel (또는 Netlify, 또는 Cloudflare Pages)로 Next.js 프론트엔드 배포
  • DNS 및 리디렉션 구성
  • 모든 URL이 적절히 리디렉션되는지 확인 (SEO 보존이 중요)
  • WordPress 관리자를 잠급니다 (공개 방문 제거)

단계 4: 최적화 (진행 중)

  • Google Search Console에서 Core Web Vitals 모니터링
  • ISR 재검증 간격 미세 조정
  • 개인화를 위해 edge 미들웨어 추가
  • WordPress가 병목이 되는 경우 목적-구축 headless CMS로 마이그레이션 고려

이 종류의 마이그레이션을 고려 중이라면, 가격 페이지에서 대략적인 수치를 확인하거나, 특정 상황을 논의하기 위해 직접 문의할 수 있습니다.

Astro를 사용해 구축된 사이트 (특히 콘텐츠 중심 블로그와 마케팅 사이트)의 경우, 우리는 또한 정적-첫 사이트에 대해 더 공격적인 성능을 제공하는 Astro 개발 사례도 있습니다.

FAQ

Next.js로 전환하지 않고 WordPress를 빠르게 할 수 있나요?

어느 정도까지는 가능합니다. 품질 호스트(Kinsta 또는 Cloudways)로 시작하고, Redis 객체 캐싱을 활성화하고, GeneratePress와 같은 가벼운 테마를 사용하고, 플러그인을 15개 미만으로 줄이고, CDN을 구성합니다. 이렇게 하면 WordPress 사이트를 Core Web Vitals의 "개선 필요" 범위로 가져올 수 있습니다. 하지만 모든 메트릭에서 특히 INP에서 "좋음" 범위로 지속적으로 돌입 — 전통적인 WordPress 아키텍처로는 극도로 어렵습니다.

WordPress에서 headless Next.js로 마이그레이션하는 비용은 얼마입니까?

사이트의 복잡도에 따라 다릅니다. 간단한 마케팅 사이트 (10-30페이지, 블로그)는 일반적으로 전체 마이그레이션에 $15,000-$40,000를 실행합니다. WooCommerce를 사용한 전자상거래 사이트는 더 관여하며 $50,000-$150,000+의 범위입니다. ROI는 보통 개선된 전환율과 감소된 호스팅 비용에서 나옵니다. 우리의 가격 페이지에는 더 많은 세부 정보가 있습니다.

Next.js로 전환하면 SEO 순위가 떨어지나요?

아니오 — 마이그레이션을 제대로 처리한다면. 적절한 301 리디렉션, 동일한 URL 구조 (또는 매핑된 리디렉션), 유효한 메타 태그, 구조화된 데이터, XML 사이트맵이 모두 필수적입니다. Next.js는 실제로 SEO 이점이 있습니다 — 더 빠른 Core Web Vitals가 순위를 직접 개선하고, Metadata API는 메타 태그를 프로그래매틱하게 관리하기 쉽게 합니다. 대부분의 사이트는 마이그레이션 후 2-3개월 내에 순위 개선을 봅니다.

headless로 가면 콘텐츠 편집자가 WordPress 관리자를 잃나요?

아니오. Headless 설정에서 WordPress는 계속 콘텐츠 관리 백엔드로 사용됩니다. 편집자는 같은 대시보드, 같은 편집기, 같은 워크플로우를 사용합니다. 그들은 프론트엔드 테마를 더 이상 보지 않습니다 — 대신, 그들은 Next.js 렌더링 버전을 표시하는 미리보기 버튼을 사용합니다. 일부 팀은 미리보기가 프로덕션 사이트의 정확한 표현이기 때문에 이것이 실제로 더 낫다고 생각합니다.

WooCommerce는 어떨까요 — Next.js가 전자상거래를 처리할 수 있나요?

예, 하지만 더 큰 프로젝트입니다. 당신은 REST API 또는 WPGraphQL WooCommerce 확장을 통해 WooCommerce를 headless로 사용할 수 있습니다. 또는, 많은 팀은 결제 백엔드로 Shopify의 Storefront API 또는 Saleor로 마이그레이션하고 프론트엔드로 Next.js를 사용합니다. 체크아웃 흐름은 결제 처리 및 PCI 준수와 관련되므로 신중한 처리가 필요합니다. 가능하지만 추가 개발 시간을 계획하세요.

Next.js가 빠른 프론트엔드의 유일한 옵션인가요?

아니오. Astro, Remix, SvelteKit, 그리고 Nuxt (Vue 팀의 경우)도 모두 실행 가능합니다. Astro는 특히 콘텐츠 중심 사이트에 우수합니다 — 기본적으로 JavaScript가 0입니다. Next.js는 상당한 상호작용, 동적 기능, 또는 전자상거래가 필요한 사이트에서 우승합니다. 우리는 프로젝트의 필요에 따라 Next.js와 Astro 모두로 작업합니다.

Incremental Static Regeneration (ISR)이 WordPress 콘텐츠와 어떻게 작동하나요?

WordPress에서 게시물을 게시하거나 업데이트하면, 웹훅이 발화되고 그 특정 페이지를 재검증하도록 Next.js 배포를 알립니다. 다음 방문자는 새로 생성된 정적 페이지를 얻으며, 이는 그 후 edge에서 캐시됩니다. 재검증은 백그라운드에서 발생하므로 사용자는 빌드를 기다리지 않습니다. 당신은 또한 시간-기반 재검증 (예: 60초마다 재구축)을 폴백으로 설정할 수 있습니다.

팀이 headless로 가을 때 하는 가장 큰 실수는 무엇인가요?

WordPress 사이트를 Next.js에서 1:1로 복제하려고 시도합니다. Headless 마이그레이션은 콘텐츠 아키텍처를 재고, 페이지 구조를 단순화, 그리고 수년에 걸친 축적된 부실을 제거할 기회입니다. 오래된 테마에서 모든 위젯과 사이드바를 복제하려는 팀보다 — 콘텐츠를 유지하지만 프리젠테이션을 재고하는 팀이 훨씬 더 나은 결과를 끝냅니다.