WordPress Lighthouse 점수가 50에서 멈춰있나요? 캐싱 플러그인으로는 해결 불가
WP Rocket를 설치했습니다. Lighthouse 점수가 35에서 52로 올랐습니다. Autoptimize를 추가했습니다. 52에서 58로. Perfmatters를 설치했습니다. 이제 당신은 세 개의 성능 플러그인을 실행 중입니다 -- 각각 자신의 JavaScript를 추가하여 다른 플러그인이 추가하는 JavaScript로 인한 성능 문제를 해결하려고 합니다. 아이러니를 보십니까?
저는 인정하고 싶은 것보다 더 많은 횟수로 이 정확한 상황에 있었습니다. 전체 주말을 WP Rocket 설정 조정, 중요 CSS 생성, 스크립트 지연, 이미지 지연 로딩, 미리로드 활성화, CDN 설정에 소비합니다. Lighthouse를 다시 실행합니다. 54. 좋은 날이면 58 정도. 경쟁사를 확인합니다 -- 그들은 90+ 정도에 앉아 있습니다. 당신이 뭘 잘못하고 있는지 궁금해합니다.
여기 것은: 당신은 아무것도 잘못하고 있지 않습니다. WordPress 성능 한계에 도달했습니다. 그것은 실제이고, 충분히 문서화되어 있으며, 캐싱 플러그인의 어떤 조합도 이를 뚫을 수 없습니다. 문제는 당신의 구성이 아닙니다. 아키텍처입니다.
이 문서는 캐싱이 WordPress 성능을 어떻게 수정할 수 없는지, 메트릭별로 실제로 낮은 점수의 원인이 무엇인지, 그리고 실제 클라이언트인 SleepDr을 Lighthouse 점수 35에서 94로 이동하기 위해 아키텍처를 완전히 변경하여 어떻게 마이그레이션했는지를 정확히 설명합니다.
목차
- 성능 플러그인 패러독스
- 렌더 차단 CSS: 캐싱은 더 작게가 아니라 더 빠르게 제공합니다
- JavaScript 비대화: jQuery와 페이지 빌더 세
- 데이터베이스 쿼리 오버헤드: 첫 번째 요청 문제
- 서버 측 렌더링: PHP의 구조적 병목
- Lighthouse 점수 분석 이해하기
- 사례 연구: SleepDr 마이그레이션 -- WordPress에서 Next.js로
- 실제로 성능을 수정하는 아키텍처
- 마이그레이션이 의미 있을 때 (그리고 의미 없을 때)
- FAQ
성능 플러그인 패러독스
매달 보는 그림을 그려보겠습니다. 사이트 소유자는 WordPress 사이트가 Lighthouse에서 35~55 사이의 점수를 받기 때문에 연락을 옵니다. 그들은 이미 이러한 플러그인의 일부 조합을 설치했습니다:
- WP Rocket ($59/년) -- 페이지 캐싱, CSS/JS 축소, 지연 로딩
- Autoptimize (무료) -- CSS/JS 집계, 중요 CSS
- Perfmatters ($24.95/년) -- 스크립트 관리자, 데이터베이스 정리
- Asset CleanUp (무료) -- 조건부 자산 로딩
- Flying Scripts (무료) -- JavaScript 실행 지연
그것은 WordPress가 상자에서 벗어나 성능을 나타내도록 만드는 것이 유일한 목적인 5개의 플러그인입니다. 각각은 자신의 PHP 실행 오버헤드를 추가합니다. 각각은 .htaccess에 자신의 규칙을 씁니다. 일부는 실제 부하 상황에서만 나타나는 미묘한 방식으로 서로 충돌합니다.
최선의 시나리오? 35에서 아마도 65로 갑니다. 이 플러그인과 그들의 다양한 상호 작용 조정에 40시간 이상을 소비한 팀을 본 적이 있습니다. 이것은 개발자 시간 1주일입니다 -- 쉽게 $4,000-$8,000의 노동 -- 20-30 Lighthouse 포인트를 얻고 여전히 "좋은" Core Web Vitals 임계값에 도달하지 못합니다.
그리고 아무도 말하지 않는 것은: 캐시된 페이지는 반환 방문자만 도움이 됩니다. 첫 번째 히트? 여전히 느립니다. Googlebot 크롤? 아마도 캐시되지 않은 페이지를 치고 있습니다. 검색에서 가장 중요한 트래픽 -- 새 방문자 -- 최악의 경험을 얻습니다.
렌더 차단 CSS: 캐싱은 더 작게가 아니라 더 빠르게 제공합니다
이것은 당신이 처음 칠 벽이고, 가장 많은 사람들이 오해하는 것입니다.
일반적인 WordPress 테마는 모든 단일 페이지에서 200KB ~ 800KB의 CSS를 로드합니다. 나는 과장하지 않습니다. 다음이 기여합니다:
- 테마 스타일시트: 150-400KB (Divi, Avada, 그리고 Elementor 테마가 최악의 범죄자입니다)
- 플러그인 스타일시트: 50-200KB (연락처 양식, 슬라이더, 소셜 공유, SEO 플러그인)
- Google 글꼴: 30-100KB (종종 당신이 사용하지 않는 3-5개의 글꼴 무게 로드)
- 아이콘 라이브러리: 50-80KB (6개 아이콘 모두 Font Awesome 로드)
다음은 중요한 통계입니다: 이 CSS의 약 70%는 주어진 페이지에서 사용되지 않습니다. 당신의 홈페이지는 WooCommerce 카트 스타일이 필요하지 않습니다. 당신의 블로그 포스트는 연락처 양식 CSS가 필요하지 않습니다. 그러나 WordPress는 모든 것을 모든 곳에 한 번에 로드합니다.
WP Rocket이 이에 대해 뭘 합니까? CSS를 축소합니다 (10-15% 절약), 파일을 결합하여 HTTP 요청을 줄이고, 폴드 위의 내용에 대한 중요 CSS를 생성합니다. 그것은 진정으로 도움이 됩니다. 그러나 브라우저는 여전히 400KB+를 다운로드합니다. 모두를 분석합니다. 사용되지 않는 CSS는 여전히 FCP 지연을 유발합니다.
WP Rocket은 당신의 CSS를 tree-shake할 수 없습니다. 각 페이지에 필요한 스타일을 결정하고 나머지를 제거할 수 없습니다. 이것은 빌드 시 HTML과 CSS 간의 관계를 이해해야 합니다 -- 이것이 정확히 최신 프레임워크가 하는 것입니다.
Next.js + Tailwind가 실제로 이것을 어떻게 해결하는가
Next.js와 Tailwind CSS를 사용하면, 사용되지 않는 스타일은 빌드 시 제거됩니다. 연기되지 않습니다. 축소되지 않습니다. 완전히 제거됩니다. 빌드 프로세스는 당신의 템플릿을 스캔하고, 실제로 사용되는 유틸리티 클래스를 식별하고, 그 스타일만 포함하는 CSS 파일을 생성합니다.
결과? 총 CSS 페이로드: 전체 사이트에 15-40KB. 페이지당이 아닙니다 -- 전체 사이트. 이것은 한계적 개선이 아닙니다. 그것은 한 수준의 차이입니다.
/* WordPress: 모든 것을 로드합니다 */
/* theme.min.css: 387KB */
/* elementor-frontend.min.css: 142KB */
/* woocommerce.min.css: 98KB */
/* contact-form-7.min.css: 12KB */
/* 총: 639KB CSS, 모든 페이지에서 약 70% 사용되지 않음 */
/* Next.js + Tailwind: 사용되는 것만 빌드합니다 */
/* globals.css: 22KB (전체 사이트) */
/* 페이지별 CSS: 0KB 추가 (모두 제거된 번들에 있습니다) */
JavaScript 비대화: jQuery와 페이지 빌더 세
이것은 TBT -- 총 차단 시간 -- 이 살해당하는 곳입니다. 그리고 TBT는 당신의 Lighthouse 성능 점수의 30%입니다. 당신은 리터럴하게 나쁜 TBT로 70 이상에 올 수 없습니다.
WordPress는 모든 페이지에 jQuery를 포함합니다. 그것은 축소되고 gzip된 87KB입니다. 메인 스레드에서 동기적으로 실행됩니다. 모든 단일 페이지 로드는 이 세금을 지급합니다, 페이지의 어떤 기능도 jQuery를 요구하지 않더라도.
그러나 jQuery는 단지 애피타이저입니다. 여기 일반적인 WordPress 페이지 빌더 사이트의 JavaScript 예산입니다:
| 출처 | 크기 (축소 + gzip) | 메인 스레드 시간 |
|---|---|---|
| jQuery + jQuery Migrate | 87KB + 10KB | 150-300ms |
| Elementor 프론트엔드 | 180-350KB | 200-500ms |
| WP Rocket (정말, 정말) | 15-25KB | 30-60ms |
| 슬라이더 플러그인 | 80-150KB | 100-250ms |
| 분석 + 추적 | 50-120KB | 80-200ms |
| 다른 플러그인 | 50-200KB | 100-300ms |
| 총 | 462KB - 855KB | 660ms - 1,610ms |
이것은 660ms에서 1.6초의 메인 스레드 차단입니다 단지 JavaScript 실행에서. Lighthouse는 좋은 점수를 위해 200ms 이하의 TBT를 원합니다. "개선 필요"의 경우 600ms 이하. 당신의 실제 콘텐츠가 렌더링되기 시작하기 전에 이미 날려버렸습니다.
캐싱 플러그인이 이것에 대해 뭘 할 수 있습니까? 축소할 수 있습니다 (5-10% 절약), 실행을 지연시킬 수 있습니다 (FCP를 돕지만 TBT는 같습니다 왜냐하면 작업은 여전히 일어나기 때문), 그리고 사용자 상호 작용까지 스크립트를 지연시킬 수 있습니다 (기능을 끊고 사용자가 무언가를 클릭하고 500ms 동안 아무것도 일어나지 않을 때 불안한 경험을 만듭니다).
Next.js: jQuery 없음, 똑똑한 코드 분할
Next.js는 jQuery를 로드하지 않습니다. 마침표. 동등한 것이 없습니다. React는 DOM 조작을 처리하고, 그것은 상호 작용을 위해 번들에 이미 있습니다. 그러나 실제 승리는: 자동 코드 분할입니다.
모든 페이지는 필요한 JavaScript만 로드합니다. 정적 "About" 페이지는 총 30KB JS를 배송할 수 있습니다. 당신의 대화식 예약 양식 페이지는 그 페이지에만 양식 라이브러리를 로드합니다. 동적 import는 무거운 구성 요소가 요청 시 로드함을 의미합니다.
// 이 구성 요소가 렌더링될 때만 예약 달력을 로드합니다
import dynamic from 'next/dynamic'
const BookingCalendar = dynamic(() => import('../components/BookingCalendar'), {
loading: () => <div className="h-96 animate-pulse bg-gray-100 rounded" />,
ssr: false // 서버 번들에도 포함하지 마십시오
})
export default function BookingPage() {
return (
<main>
<h1>상담 예약</h1>
<BookingCalendar />
</main>
)
}
그 ssr: false 플래그는 달력 JavaScript가 초기 페이지 로드에 존재하지 않음을 의미합니다. 사용자는 플레이스홀더를 즉시 보고, 대화식 구성 요소를 hydrate합니다. TBT는 최소한으로 유지됩니다.
데이터베이스 쿼리 오버헤드: 첫 번째 요청 문제
모든 WordPress 페이지 로드는 데이터베이스 쿼리를 트리거합니다. 몇 가지가 아닙니다. 많은.
지난해에 클라이언트의 사이트에 Query Monitor를 설치했습니다 -- 상당히 표준적인 WordPress + WooCommerce + Yoast 설정. 단일 홈페이지 로드가 생성한 것이 여기입니다:
- WordPress 코어: 8-12개 쿼리 (옵션, 사용자 세션, 재작성 규칙)
- Yoast SEO: 15+ 쿼리 (메타 데이터, 스키마 설정, 브레드크럼)
- WooCommerce: 20+ 쿼리 (제품 데이터, 카트, 세션)
- 테마 옵션: 10-15개 쿼리 (커스터마이저 설정, 위젯 데이터)
- 메뉴 렌더링: 5-8개 쿼리 (중첩된 메뉴 항목, 메타)
- 사이드바 위젯: 위젯당 5-10개 쿼리
총: 단일 페이지 로드에 대해 63-80개의 데이터베이스 쿼리. 200개의 다른 사이트도 제공하는 MySQL 데이터베이스를 가진 공유 호스팅에서? 이것이 어디로 가는지 볼 수 있습니다.
WP Rocket의 페이지 캐싱은 이를 제거합니다 -- 캐시된 페이지의 경우입니다. 그러나 캐시는 만료됩니다. 새 페이지는 첫 방문까지 캐시되지 않습니다. WooCommerce 카트 페이지는 캐시될 수 없습니다 (사용자별로 동적입니다). 관리자 사용자는 캐시를 우회합니다. 그리고 Googlebot은 종종 캐시에서 벗어난 페이지를 칩니다.
캐시되지 않은 모든 요청은 전체 데이터베이스 페널티를 지급합니다.
Next.js ISR: 미리 렌더링된 HTML, 요청 시 0 DB 쿼리
Next.js를 Incremental Static Regeneration (ISR)과 함께 사용하면, 페이지는 빌드 시에 정적 HTML로 미리 렌더링됩니다. 사용자가 페이지를 요청할 때, 서버는 미리 빌드된 HTML 파일을 반환합니다. PHP 실행 없음. 데이터베이스 쿼리 없음. 계산 없음.
// 이것은 빌드 시에 실행되며, 요청 시가 아닙니다
export async function getStaticProps() {
const posts = await fetchFromWordPressAPI('/wp-json/wp/v2/posts')
return {
props: { posts },
revalidate: 3600 // 매시간 이 페이지를 재구성합니다
}
}
revalidate: 3600은 페이지가 1시간마다 백그라운드에서 재구성됨을 의미합니다. 사용자는 항상 즉시 정적 HTML을 얻습니다. 콘텐츠는 신선합니다. 데이터베이스 쿼리는 재생성 중에만 일어나며, 모든 단일 방문자 요청에서는 아닙니다.
headless CMS 개발을 할 때, WordPress는 콘텐츠 백엔드가 됩니다 -- 편집자는 여전히 익숙한 관리자 인터페이스를 사용합니다 -- 그러나 프론트엔드는 완전히 분리됩니다. 데이터베이스는 빌드 또는 재검증 중에만 히트되며, 사용자 요청 중이 아닙니다.
서버 측 렌더링: PHP의 구조적 병목
TTFB에 대해 이야기해 봅시다 -- Time to First Byte. 요청 후 서버가 응답을 보내기 시작할 때까지 걸리는 시간입니다.
WordPress는 PHP를 실행하여 모든 페이지를 생성합니다. 간단한 블로그 포스트도 필요합니다:
- Apache/Nginx가 요청을 수신합니다
- PHP 프로세스가 생성됩니다 (또는 풀에서 재사용됨)
- WordPress bootstrap 로드 (~50개 파일)
- 활성 플러그인 로드 (각각: 파일 읽기, 데이터베이스 쿼리, hooks 등록)
- 테마 함수 로드
- 템플릿 계층 해결
- 데이터베이스 쿼리 실행
- 템플릿이 HTML로 렌더링됨
- 응답 전송
공유 호스팅에서 (대다수 WordPress 사이트가 있는 곳 -- SiteGround, Bluehost, GoDaddy), 이 프로세스는 2-4초 TTFB를 소비합니다, 어떤 CSS, JavaScript, 또는 이미지도 로드되기 전에. 당신의 사용자는 2초 이상 동안 빈 화면을 바라봅니다.
관리형 WordPress 호스팅 (Kinsta, WP Engine, Flywheel)은 이것을 0.8-1.5초 TTFB로 줄입니다. 더 낫습니다. 여전히 훌륭하지 않습니다.
Vercel의 Edge Network에서 Next.js? 50-200ms TTFB. 이것은 Vercel이 마법의 서버를 가지고 있기 때문이 아닙니다. HTML이 이미 존재하기 때문입니다. 가장자리 노드는 사용자에게 가장 가까운 것이 직접 제공합니다. PHP 없음. 데이터베이스 없음. 템플릿 렌더링 없음.
2초 이상 TTFB와 100ms TTFB 사이의 성능 간격은 캐싱 플러그인으로 다리를 놓을 수 없는 것입니다.
Lighthouse 점수 분석 이해하기
사례 연구를 보기 전에, Lighthouse가 실제로 측정하는 것과 WordPress가 각 메트릭에서 왜 어려움을 겪는지 이해해 봅시다:
| 메트릭 | 가중치 | 측정하는 것 | WordPress 문제 | Next.js 솔루션 |
|---|---|---|---|---|
| TBT | 30% | JS에 의한 메인 스레드 차단 | jQuery + 플러그인 JS = 600ms+ | 코드 분할 = <50ms |
| LCP | 25% | 가장 큰 보이는 요소가 칠해짐 | 느린 TTFB + 렌더 차단 CSS | 미리 렌더링된 HTML + 제거된 CSS |
| CLS | 25% | 시각적 레이아웃 이동 | 치수 없는 지연 로드 이미지, 동적 광고 | next/image 명시적 크기 지정 |
| 속도 지수 | 10% | 시간 경과에 따른 시각적 완성도 | 무거운 CSS가 렌더링을 차단합니다 | 최소 CSS, 즉시 HTML |
| FCP | 10% | 첫 콘텐츠 칠해짐 | 렌더 차단 리소스 | 중요 CSS 인라인, 아무것도 차단하지 않음 |
TBT 단독으로 30% 가중치에서는 1,200ms+ 차단 시간 (WordPress에서 일반적)을 치고 있다면, 당신은 거의 당신 점수의 1/3을 잃고 있습니다. 이미지 최적화나 캐싱도 보상할 수 없습니다.
사례 연구: SleepDr 마이그레이션 -- WordPress에서 Next.js로
SleepDr은 수십 번 본 것과 같은 문제로 우리에게 왔습니다. 그들은 프리미엄 테마 위에 구축된 WordPress 사이트를 가진 수면 건강 실습이며, WooCommerce를 예약 스케줄링을 위해 실행 중이며, Yoast를 SEO를 위해, Elementor를 페이지 빌딩을 위해, 그리고 -- 추측했습니다 -- WP Rocket, Autoptimize, 그리고 Perfmatters를 성능을 위해.
3개의 성능 플러그인. Lighthouse 점수: 35.
여기 before 및 after 숫자입니다:
| 메트릭 | WordPress (이전) | Next.js (이후) | 변화 |
|---|---|---|---|
| FCP | 4.2s | 1.1s | -74% |
| LCP | 6.8s | 1.8s | -74% |
| CLS | 0.28 | 0.01 | -96% |
| TBT | 1,200ms | 50ms | -96% |
| TTFB | 2.1s | 0.3s | -86% |
| Lighthouse 점수 | 35 | 94 | +169% |
캐싱 플러그인 조합도 이러한 결과를 달성할 수 없습니다. 아키텍처는 변경되어야 했습니다. 각 메트릭을 정복하겠습니다.
FCP: 4.2s → 1.1s (-74%)
WordPress 점수의 원인이 뭘 했습니까: WordPress 사이트는 2.1초 TTFB (공유 호스팅), Elementor, 테마, WooCommerce, 그리고 6개의 플러그인 스타일시트로부터 580KB의 렌더 차단 CSS를 가졌습니다. 브라우저는 모든 CSS를 다운로드하고 분석할 때까지 아무것도 칠할 수 없습니다. FCP는 리터럴하게 클릭 이후 4초 이상 시작할 수 없었습니다.
Next.js 수정: Vercel의 가장자리 (0.3초 TTFB)에서 제공되는 미리 렌더링된 HTML. 중요 CSS가 <head>에 인라인됨 -- 약 4KB. 브라우저는 HTML을 받은 거의 직후에 콘텐츠를 칠합니다. 전체 사이트의 총 CSS: 28KB, 첫 번째 칠한 후 비동기로 로드됨.
LCP: 6.8s → 1.8s (-74%)
WordPress 점수의 원인이 뭘 했습니까: 가장 큰 콘텐츠 요소는 hero 이미지였습니다. WordPress에서, 그것은 Elementor의 지연 로딩을 통해 로드했습니다 (WP Rocket의 지연 로딩과 충돌했습니다 -- 그 예, 그들은 서로 싸우고 있었습니다). 이미지는 2.4MB PNG였으며 next-gen 포맷 변환 없이 제공되었습니다. LCP는 이 거대한 이미지가 느린 TTFB 연결 위에 다운로드를 완료할 때까지 완료될 수 없었습니다.
Next.js 수정: next/image 자동 WebP/AVIF 변환, 반응형 srcset, 그리고 fold 위의 이미지를 위한 우선 로딩. hero 이미지는 2.4MB PNG에서 85KB AVIF로 갔습니다. 로딩 시퀀스에서 우선되었습니다 -- fold 위의 콘텐츠에 대한 지연 로딩 없음. 빠른 TTFB와 결합하면, LCP는 1.8초에 완료되었습니다.
CLS: 0.28 → 0.01 (-96%)
WordPress 점수의 원인이 뭘 했습니까: 세 가지 범죄자. 첫째, 명시적 너비/높이 속성 없는 이미지 (Elementor는 CSS를 통해 동적으로 크기를 조정했으며, reflow를 유발했습니다). 둘째, 페이지 로드 후 DOM에 자신을 삽입한 쿠키 동의 배너, 콘텐츠를 밀어내었습니다. 셋째, 웹 글꼴 로드 font-display: swap이 보이는 텍스트 reflow를 유발했습니다. 0.28의 CLS는 끔찍합니다 -- Google은 0.1 이상 무엇이든 "나쁨"으로 간주합니다.
Next.js 수정: next/image는 너비와 높이를 강제하며, 이미지가 로드되기 전에 공간을 예약합니다. 쿠키 배너는 인라인 콘텐츠 대신 고정 오버레이로 위치했습니다. 글꼴은 font-display: optional로 자체 호스팅되고 미리 로드되었습니다. 결과: 0.01 CLS. 효과적으로 0 레이아웃 이동.
TBT: 1,200ms → 50ms (-96%)
WordPress 점수의 원인이 뭘 했습니까: jQuery (87KB + 150ms 실행). Elementor 프론트엔드 JS (280KB + 400ms). WooCommerce 카트 조각 (35KB + 80ms). 3개의 성능 플러그인 JavaScript (결합 45KB + 90ms). 분석 및 추적 (60KB + 120ms). 다양한 플러그인 스크립트 (100KB + 200ms). 총: 1초 이상의 메인 스레드 차단.
Next.js 수정: jQuery 없음. 페이지 빌더 JS 없음. 예약 위젯에 대한 동적 import. next/script를 통해 strategy="lazyOnload"로 로드된 분석. 홈페이지의 총 JavaScript: 62KB. TBT: 50ms. 이것은 96% 감소입니다.
TTFB: 2.1s → 0.3s (-86%)
WordPress 점수의 원인이 뭘 했습니까: SleepDr은 SiteGround 공유 호스팅에 있었습니다. 모든 캐시되지 않은 요청은 WordPress bootstrap, 플러그인 로드, 60+ 데이터베이스 쿼리, PHP 템플릿 렌더링을 트리거했습니다. WP Rocket의 페이지 캐시에도, 캐시 무효화는 WooCommerce 카트 동역학 때문에 자주 일어났습니다. 실제 사용자에 대한 평균 TTFB: 2.1초.
Next.js 수정: Vercel의 전역 edge 네트워크에 배포된 정적 페이지. ISR은 콘텐츠 업데이트를 처리합니다 -- 페이지는 백그라운드에서 매 30분마다 재생성됩니다. 사용자 요청은 항상 사용자에게 가장 가까운 가장자리 노드에서 미리 빌드된 HTML을 칩니다. TTFB는 평균 0.3초로 떨어졌으며, 일부 지역은 100ms 미만을 보입니다.
실제로 성능을 수정하는 아키텍처
SleepDr 마이그레이션은 우리가 headless WordPress 패턴이라고 부르는 것을 사용했습니다. WordPress는 CMS로 유지됩니다 -- SleepDr 팀은 여전히 wp-admin에 로그인하고, Gutenberg에서 콘텐츠를 작성하고, WooCommerce에서 약속 타입을 관리합니다. 콘텐츠 관리 측에서 아무것도 변경되지 않았습니다.
그러나 프론트엔드는 완전히 Next.js입니다. 빌드 프로세스는 REST API를 통해 WordPress에서 콘텐츠를 끌어오고, 정적 페이지를 생성하고, Vercel에 배포합니다. 콘텐츠 편집자는 WordPress에 게시하고, webhook이 재검증을 트리거하고, 업데이트된 페이지는 30초 이내에 라이브됩니다.
유사한 접근을 고려하는 팀을 위해, Astro는 평가할 가치가 있는 또 다른 옵션입니다 -- 특히 최소한의 상호 작용을 가진 콘텐츠 중심 사이트입니다. Astro는 기본적으로 0 JavaScript를 배송하며, Lighthouse 점수를 훨씬 더 높이 밀어낼 수 있습니다.
핵심 통찰: 우리는 WordPress를 최적화하지 않았습니다. 느린 부분을 교체했습니다 (PHP 렌더링 및 프론트엔드 배달) 잘 작동하는 부분을 유지하면서 (콘텐츠 관리).
마이그레이션이 의미 있을 때 (그리고 의미 없을 때)
나는 모든 WordPress 사이트가 Next.js로 마이그레이션해야 한다고 말하지 않을 것입니다. 그것은 부정직합니다. 여기 제 정직한 평가입니다:
마이그레이션이 의미 있을 때:
- 최적화 노력에도 불구하고 Lighthouse 점수가 60 미만에서 멈춰 있습니다
- 성능이 수익에 직접 영향을 미칩니다 (e-커머스, 리드 생성, SaaS 마케팅 사이트)
- Core Web Vitals 실패를 위해 $200+/월을 관리형 WordPress 호스팅에 지불하고 있습니다
- 당신의 개발 팀은 React/JavaScript에 편합니다
- SEO 순위는 Core Web Vitals 실패로 고통받고 있습니다
마이그레이션이 의미 없을 때:
- 당신은 개인 블로그 또는 작은 브로슈어 사이트입니다 (투자가 비용 편익이 나지 않을 것입니다)
- 당신의 콘텐츠 팀은 API 동등한 없이 WordPress 특정 플러그인에 크게 의존합니다
- 60-70 Lighthouse에서 행복하고 당신의 Core Web Vitals 통과입니다
- 당신의 예산은 마이그레이션을 위해 $15,000 미만입니다
마이그레이션이 의미 있는 사이트의 경우, 전형적인 투자는 $15,000-$50,000+ 범위에 있으며 복잡성, 템플릿의 수, 그리고 커스텀 기능에 따라 다릅니다. 우리는 우리의 접근과 전형적인 프로젝트 구조를 우리의 가격 페이지에서 자세히 설명했습니다.
ROI 계산은 직관적입니다: 나쁜 성능이 월별 X의 전환 손실 비용이라면, 그리고 마이그레이션이 Y 비용이라면, 당신은 당신의 상환 기간을 알 수 있습니다. SleepDr의 경우, 개선된 페이지 속도는 첫 분기 내에 약속 예약에서 34% 증가에 기여했습니다.
FAQ
WP Rocket은 정말 내 WordPress Lighthouse 점수를 수정할 수 없습니까?
WP Rocket은 진정으로 사용 가능한 최고 중 하나입니다 WordPress 캐싱 플러그인. 캐싱 계층이 할 수 있는 모든 것을 합니다 -- 페이지 캐싱, 축소, 지연 로딩, CDN 통합, 중요 CSS 생성. 그러나 WordPress의 아키텍처 제약 내에서 작동합니다. 점수가 50 미만이면, WP Rocket은 전형적으로 55-65로 올릴 수 있습니다. 80 이상에 일관되게 도달하려면 WP Rocket이 단순히 제거할 수 없는 렌더 차단 CSS, jQuery 의존성, 그리고 PHP 렌더링 오버헤드를 제거해야 합니다. 배달을 최적화합니다. 아키텍처를 재구성할 수 없습니다.
WordPress는 캐싱 플러그인으로 현실적으로 어떤 Lighthouse 점수를 달성할 수 있습니까?
잘 최적화된 설정으로 -- 가벼운 테마, 최소 플러그인, 완전히 구성된 WP Rocket, Kinsta 또는 WP Engine 같은 관리형 호스팅 -- 당신은 현실적으로 모바일 Lighthouse에서 65-75에 도달할 수 있습니다. 데스크톱 점수는 더 높을 것입니다 (80-90) 테스트 기기가 더 많은 처리 능력을 가지고 있기 때문에. 모바일에서 80 이상에 일관되게 도달하려면 극히 최소한의 WordPress 설정 (거의 플러그인 없음, 커스텀 테마) 또는 아키텍처 변경이 필요합니다. Elementor 또는 Divi 같은 페이지 빌더를 가진 사이트는 전형적으로 50-65에서 최대입니다.
WordPress에서 Next.js로 마이그레이션 비용은 얼마입니까?
비용은 사이트 복잡성에 따라 크게 다릅니다. 간단한 브로슈어 사이트 (5-15개 페이지, 블로그, 연락처 양식)는 $15,000-$25,000입니다. 중간 복잡성 사이트는 커스텀 포스트 타입, 다중 템플릿, 그리고 통합으로 $25,000-$40,000입니다. 사용자 계정, 동적 데이터, 그리고 타사 통합을 가진 e-커머스 또는 복잡한 웹 애플리케이션은 $40,000+에서 시작합니다. 이것들은 2025년 증명된 headless 경험을 가진 기관의 시장 요율입니다. 우리에게 연락하여 당신의 사이트에 기반한 구체적인 추정을 얻을 수 있습니다.
headless WordPress는 당신의 콘텐츠 팀이 새로운 도구를 배워야 한다는 의미입니까?
아니오. 그것이 전체 요점입니다. 당신의 콘텐츠 팀은 wp-admin, Gutenberg, ACF, 또는 그들이 익숙한 무엇이든 계속 사용합니다. 유일한 보이는 변화는 그들이 콘텐츠 업데이트가 라이브 사이트에 나타나길 기다릴 수 있다는 것입니다 (ISR 재검증 때문에) 변경을 즉시 보는 대신 30-60초. 일부 팀은 이것을 거의 인지할 수 없다고 발견합니다. 편집 경험은 사실상 동일합니다.
TBT와 FCP의 차이는 뭐고, 둘 다 왜 중요합니까?
FCP (First Contentful Paint)는 사용자가 언제 무언가를 보는지 측정합니다 -- 어떤 콘텐츠든. TBT (Total Blocking Time)는 FCP와 Time to Interactive 사이에 JavaScript 실행으로 메인 스레드가 얼마나 오래 차단되는지 측정합니다. 당신은 decent FCP를 가질 수 있지만 끔찍한 TBT를 가질 수 있으며, 사용자가 콘텐츠를 빠르게 보지만 상호 작용할 수 없다는 것을 의미합니다. 이것은 WordPress 사이트에서 일반적이며, HTML이 캐시에서 렌더링되지만 800KB+ 의 JavaScript가 실행됩니다. 둘 다 중요합니다 왜냐하면 함께 그들이 당신의 Lighthouse 점수의 40%를 나타내기 때문입니다 (TBT 30%, FCP 10%).
마이그레이션이 내 SEO 순위를 일시적으로 해칠까요?
올바르게 수행되면, 아니오. 핵심은 URL 구조를 유지하고, URL이 변경되는 모든 것에 대해 적절한 301 리다이렉트를 구현하고, 모든 메타 데이터를 보존하고, XML 사이트맵이 올바른지 확인하는 것입니다. 우리는 전형적으로 순위가 약간 변동하는 1-2주의 안정화 기간을 보며, 그 뒤에 Google이 더 나은 Core Web Vitals를 인식하면서 개선됩니다. SleepDr은 마이그레이션 중에 순위 하락을 보지 못했고 6주 내에 위치를 얻었습니다. 위험은 느슨한 마이그레이션으로부터 옵니다 -- 끊어진 리다이렉트, 누락된 페이지, 리다이렉트 없는 변경된 URL 구조.
마이그레이션 대신 Astro를 사용할 수 있습니까?
절대적으로. Astro는 제한된 상호 작용을 가진 콘텐츠 중심 사이트에 훌륭한 선택입니다. Astro는 기본적으로 0 JavaScript를 배송하고 대화식 구성 요소만 hydrate합니다 -- 그들이 "islands 아키텍처"라고 부르는 것. 블로그, 문서 사이트, 또는 대부분의 페이지가 정적 콘텐츠인 마케팅 사이트의 경우, Astro는 Next.js보다 더 나은 Lighthouse 점수를 달성할 수 있습니다. 중요한 클라이언트 측 상호 작용이 필요할 때 (대시보드, 예약 시스템, e-커머스) Next.js를 추천하고, 콘텐츠가 주요일 때 Astro를 추천합니다.
Lighthouse 점수 개선이 투자를 할 가치가 있습니까?
이것은 전적으로 당신의 사이트가 뭘 하는지에 달려 있습니다. 개인 블로그의 경우, 아마도 아니오. 유기 검색 트래픽이 수익을 구동하는 비즈니스의 경우, 수학은 강력합니다. Google은 Core Web Vitals를 순위 요소로 확인했습니다. 2024-2025 연구는 LCP의 모든 100ms 개선이 e-커머스 사이트의 전환율 1.1% 증가와 상관관계가 있다고 보여줍니다. 당신의 사이트가 월별 $50,000의 수익을 생성하고 10-15% 전환 개선이 월별 $5,000-$7,500을 추가한다면, $30,000 마이그레이션은 4-6개월에 자신을 지급합니다. 당신 자신의 숫자를 실행합니다 -- 답변은 항상 당신의 비즈니스에 특정합니다.