SleepDr 사례 연구: WordPress에서 Next.js로 마이그레이션 (Lighthouse 35→94)
SleepDr 사례 연구: WordPress에서 Next.js로의 마이그레이션
지난 분기, 저희는 WordPress가 항상 올바른 도구가 아닌 이유를 완벽하게 보여주는 프로젝트를 진행했습니다. SleepDr.com — 228개의 블로그 게시물, 연락처 양식, 모바일 Lighthouse 점수 35점을 가진 수면 건강 콘텐츠 사이트 — 는 속도에 대한 간절한 요청으로 저희를 찾아왔습니다. 오가닉 트래픽이 몇 달 동안 감소하고 있었습니다. 전체 사이트 Core Web Vitals 점수를 도입한 Google의 2026년 3월 Core Update는 그들을 큰 타격을 입혔습니다. 모든 느린 블로그 게시물이 전체 도메인을 끌어내리고 있었습니다.
저희는 SleepDr을 Next.js 15 + Payload CMS 3 + Supabase + Vercel로 마이그레이션했습니다. 결과: 모바일 Lighthouse 94, 데스크톱 99. 오가닉 트래픽은 6주 내에 회복되었습니다. 여기서는 저희가 어떻게 도달했는지 — 모든 최적화, 모든 메트릭, 모든 결정 — 의 전체 이야기를 담았으므로 자신의 프로젝트에도 동일한 사고방식을 적용할 수 있습니다.
목차
- Before: WordPress가 SleepDr을 죽이고 있던 이유
- 마이그레이션 스택: 우리가 선택한 이유
- Before and After: 수치
- 최적화 1: 이미지 최적화 (LCP -3s)
- 최적화 2: 폰트 최적화 (FCP -1.5s)
- 최적화 3: JavaScript 감소 (TBT 1200ms → 50ms)
- 최적화 4: 서버 사이드 렌더링 및 Edge 배포 (TTFB -85%)
- 최적화 5: 제3자 스크립트 관리
- 최적화 6: CSS 최적화 (800KB → 35KB)
- 단계별 체크리스트
- 2026 Core Web Vitals가 사이트에 의미하는 것
- FAQ
Before: WordPress가 SleepDr을 죽이고 있던 이유
SleepDr의 WordPress 설정은 누적된 기술 부채의 교과서적 사례였습니다. 3년에 걸쳐 34개의 플러그인을 설치했습니다. 테마는 jQuery와 두 개의 추가 JavaScript 라이브러리를 로드했습니다. 모든 페이지 요청은 MySQL 데이터베이스에 hit되었고, HTML이 즉석에서 생성되었으며, 이미 과부하 상태인 공유 호스팅 계획을 통해 최적화되지 않은 이미지가 제공되었습니다.
초기 Lighthouse 감사가 모바일에서 어떻게 보였는지 다음과 같습니다:
- 전체 점수: 35 (빨간색, 실패)
- FCP: 4.2초
- LCP: 6.8초 — "Good" 임계값의 거의 3배
- CLS: 0.28 — 광고, 크기 없는 이미지, 웹 폰트 로딩으로 인해 레이아웃이 계속 점프함
- TBT: 1,200ms — 메인 스레드가 1초 이상 잠겨있음
- TTFB: 2.1초 — 서버 자체가 느려서 아무것도 렌더링되기 전부터 느림
사이트는 단지 느리기만 한 것이 아니었습니다. 모바일 장치의 사용자에게 적극적으로 적대적이었습니다. Google의 Lighthouse 모바일 시뮬레이션이 throttled 4G 연결의 중급 휴대폰을 모방하기 때문에, 점수는 이상적이지 않은 조건의 실제 사용자가 경험하는 것을 반영했습니다.
Google의 2026년 3월 Core Update가 전체 도메인의 성능을 집계하는 전체적인 CWV 점수를 도입한 후 — 페이지별 대신 — SleepDr의 228개의 느린 블로그 게시물이 사이트 전체의 순위를 망치고 있었습니다. 롤아웃의 초기 데이터는 영향을 받은 사이트에서 20-35% 트래픽 감소를 보였습니다. SleepDr은 대략 30% 감소를 경험했습니다.
뭔가 바꿔야 했습니다.
마이그레이션 스택: 우리가 선택한 이유
저희는 이 스택을 trendy하기 때문에 선택하지 않았습니다. SleepDr이 가진 특정 문제를 각 부분이 해결하기 때문에 선택했습니다.
- Next.js 15 (App Router): 하이브리드 렌더링. 블로그 게시물을 위한 정적 생성, 필요한 경우 서버 사이드 렌더링. React Server Components로 클라이언트 사이드 JavaScript를 최소화합니다. 이것이 저희의 핵심입니다 — 저희는 Next.js 개발 사례를 통해 이것으로 수십 개의 프로젝트를 구축했습니다.
- Payload CMS 3: WordPress와 동일한 편집 경험을 SleepDr의 콘텐츠 팀에 제공했지만 bloat 없이 자체 호스팅되는 headless CMS입니다. 저희는 많은 headless CMS 구현을 처리하며 Payload 3은 콘텐츠가 많은 사이트의 go-to가 되었습니다.
- Supabase: 실시간 기능이 있는 PostgreSQL 데이터베이스. 연락처 양식 제출, 분석 이벤트 및 모든 동적 데이터를 처리했습니다.
- Vercel: Edge 배포. 사이트는 사용자에게 가장 가까운 노드에서 제공됩니다. TTFB는 거의 무시할 수 있게 됩니다.
전체 마이그레이션은 7주가 걸렸습니다. 콘텐츠 마이그레이션 — 228개 게시물 모두와 그 이미지, 메타데이터, URL 구조 — 은 약 2주가 걸렸습니다. 저희는 WordPress REST API에서 콘텐츠를 가져와서 변환하고 Payload CMS에 push하는 사용자 정의 스크립트를 작성했습니다.
Before and After: 수치
완전한 분류입니다. 이들은 실제 이야기가 있는 Lighthouse 모바일 점수입니다.
| 메트릭 | Before (WordPress) | After (Next.js 15) | 개선 |
|---|---|---|---|
| First Contentful Paint (FCP) | 4.2s | 1.1s | -3.1s (74% 더 빠름) |
| Largest Contentful Paint (LCP) | 6.8s | 1.8s | -5.0s (74% 더 빠름) |
| Cumulative Layout Shift (CLS) | 0.28 | 0.01 | -0.27 (96% 감소) |
| Total Blocking Time (TBT) | 1,200ms | 50ms | -1,150ms (96% 감소) |
| Time to First Byte (TTFB) | 2.1s | 0.3s | -1.8s (85% 더 빠름) |
| 전체 모바일 점수 | 35 | 94 | +59점 |
| 전체 데스크톱 점수 | 61 | 99 | +38점 |
명확히 하고 싶습니다: 이들은 단일 페이지에서 cherry-picked된 수치가 아닙니다. 저희는 20개의 대표 페이지에서 Lighthouse를 실행하고 결과를 평균했습니다. 모바일 점수는 테스트된 모든 페이지에서 91-97 범위였습니다. 데스크톱은 97-100이었습니다.
이제 저희가 이러한 각 개선을 어떻게 달성했는지 자세히 설명하겠습니다.
최적화 1: 이미지 최적화 (LCP -3s)
이미지는 이전 사이트에서 가장 큰 성능 킬러였습니다. SleepDr의 블로그 게시물은 제품 사진과 인포그래픽으로 가득 찼습니다 — 디자이너 머신에서 나온 전체 해상도 PNG로 직접 업로드되었습니다. 일부 이미지는 3-4MB였습니다.
우리가 한 일
모든 단일 이미지에 next/image 사용. 이 component는 많은 heavy lifting을 합니다:
import Image from 'next/image';
export function HeroImage({ src, alt }) {
return (
<Image
src={src}
alt={alt}
width={1200}
height={630}
priority // 스크롤 위의 hero: preload 하기
sizes="(max-width: 768px) 100vw, (max-width: 1200px) 50vw, 1200px"
quality={80}
/>
);
}
next/image가 자동으로 처리하는 것:
- 포맷 변환: PNG/JPEG 대신 WebP (지원되는 곳에서는 AVIF)를 제공합니다. 이것만으로도 이미지 크기를 60-80% 줄였습니다.
- 반응형 srcset: 모바일 사용자가 데스크톱 크기 이미지를 다운로드하지 않도록 여러 크기를 생성합니다.
- 기본적으로 lazy loading: 스크롤 아래의 이미지는 사용자가 스크롤할 때까지 로드되지 않습니다.
- 명시적 크기:
width와heightprops는 레이아웃의 공간을 예약하므로 CLS를 직접 수정합니다.
핵심 통찰: LCP 요소에 대한 우선순위 로드
hero 이미지의 priority prop이 중요했습니다. 없으면 Next.js는 이미지를 lazy-load합니다. 하지만 hero 이미지가 LCP 요소인 경우 — SleepDr의 대부분의 페이지에서는 그랬습니다 — lazy loading하면 실제로 LCP 점수를 해칩니다. 즉시 다운로드를 시작하고 싶습니다.
저희는 모든 페이지 템플릿을 감사했고, 각각의 LCP 요소를 식별했으며, priority로 표시했습니다. 블로그 게시물 페이지는 featured 이미지를 사용했습니다. 홈페이지는 hero 배너를 사용했습니다. 단순하지만 LCP에 3초의 차이를 만들었습니다.
이미지 CDN
Vercel의 내장 이미지 최적화가 CDN으로 역할을 합니다. 이미지는 첫 요청 시 edge에서 처리되고 캐시됩니다. 후속 방문자는 캐시되고 최적화된 버전을 밀리초 단위로 얻습니다. Cloudinary 구독이 필요 없습니다. 동일한 작업을 하려고 하지만 더 나쁜 WordPress 플러그인도 필요 없습니다.
순 효과: 이미지 최적화만으로 LCP가 6.8초에서 약 3.8초로 드롭되었습니다. 나머지 LCP 개선은 TTFB 개선과 폰트 로딩에서 나왔습니다.
최적화 2: 폰트 최적화 (FCP -1.5s)
SleepDr의 WordPress 테마는 외부 스타일시트 링크를 통해 3개의 Google Fonts를 로드했습니다. 각각은 fonts.googleapis.com에 대한 render-blocking 요청이었고, fonts.gstatic.com에서 실제 폰트 파일에 대한 또 다른 요청이 뒤따랐습니다. 브라우저가 텍스트를 칠할 수 있기 전에 6개의 네트워크 왕복입니다.
우리가 한 일
next/font를 사용하여 폰트를 자체 호스팅:
import { Inter, Merriweather } from 'next/font/google';
const inter = Inter({
subsets: ['latin'],
display: 'swap',
variable: '--font-inter',
});
const merriweather = Merriweather({
weight: ['400', '700'],
subsets: ['latin'],
display: 'swap',
variable: '--font-merriweather',
});
next/font가 다르게 하는 것:
- 폰트 파일을 자체 호스팅: 외부 네트워크 요청이 없습니다. 폰트는 빌드와 함께 번들되고 동일한 CDN에서 제공됩니다.
- 자동 subsetting: 실제로 필요한 character set만 포함합니다. Inter의 Latin subset은 전체 100KB+ 파일 대신 약 20KB입니다.
display: 'swap': 텍스트는 fallback 폰트로 즉시 렌더링되고, 로드되면 웹 폰트로 바뀝니다. 보이지 않는 텍스트는 없습니다. FCP를 차단하는 unstyled 콘텐츠의 flash도 없습니다.- CSS 변수 주입: 폰트는 CSS 사용자 정의 속성을 통해 적용되므로, fallback 폰트 메트릭이 신중하게 일치되므로 폰트가 바뀔 때 레이아웃 shift는 없습니다.
저희는 또한 세 번째 폰트를 완전히 제거했습니다. 이전 사이트는 제목에 decorative 폰트를 사용했는데 이는 가독성을 개선하지 않고 시각적 noise를 추가했습니다. 2개의 폰트. 이게 다입니다.
순 효과: render-blocking 폰트 요청을 제거함으로써 FCP가 약 1.5초 개선되었습니다.
최적화 3: JavaScript 감소 (TBT 1200ms → 50ms)
이것은 가장 극적인 단일 개선이었습니다. 1,200ms의 TBT는 브라우저의 메인 스레드가 1초 이상 블록되었다는 의미입니다 — 사용자는 그 시간 동안 클릭, 스크롤 또는 상호작용을 할 수 없습니다.
모든 JavaScript는 어디에서 나왔나요?
WordPress 사이트는 다음을 로드했습니다:
- jQuery (87KB minified) — 테마와 대부분의 플러그인에서 사용
- 34개의 플러그인 스크립트 — 연락처 양식, 분석, 소셜 공유, 쿠키 동의, 2개의 다른 slider 라이브러리, lightbox 및 기타
- 테마 JavaScript — 메뉴 toggles와 animation 라이브러리의 또 다른 150KB
- 인라인 스크립트 — 다양한 플러그인의 random 스니펫이
<head>에 주입됨
페이지 로드 시 총 JavaScript: 약 1.8MB. throttled 모바일 연결에서 parsing 및 실행하는 데 1초 이상 걸립니다.
우리가 한 일
Zero jQuery. Next.js는 React를 사용합니다. jQuery가 필요하지 않습니다.
Zero plugins. 모든 기능은 purpose-built component로 다시 구축되었습니다:
- 연락처 양식: 4KB React component + Supabase server action
- 쿠키 동의:
next/scriptstrategy가 있는 2KB component - 소셜 공유: 대체 링크가 있는 native Web Share API — 라이브러리가 필요 없습니다
- 분석: Lightweight Plausible script (< 1KB)
아래 스크롤의 모든 것에 대한 동적 imports:
import dynamic from 'next/dynamic';
const NewsletterSignup = dynamic(
() => import('@/components/NewsletterSignup'),
{ ssr: false } // 클라이언트에서만 로드, 필요할 때만
);
const RelatedPosts = dynamic(
() => import('@/components/RelatedPosts')
);
React Server Components는 대부분의 렌더링을 처리했습니다. 블로그 게시물 콘텐츠, 헤더, 푸터, 네비게이션 — 모두 클라이언트 사이드 JavaScript가 없는 server-rendered입니다. 오직 상호작용 요소 (모바일 메뉴 toggle, 연락처 양식, 뉴스레터 가입)만 브라우저에 JS를 배송합니다.
마이그레이션 후 페이지 로드 시 총 JavaScript: 약 85KB. 이것은 95% 감소입니다.
순 효과: TBT가 1,200ms에서 50ms로 드롭되었습니다. 메인 스레드는 기본적으로 free입니다.
최적화 4: 서버 사이드 렌더링 및 Edge 배포 (TTFB -85%)
TTFB는 서버가 응답의 첫 바이트를 보내기 시작할 때까지 걸리는 시간을 측정합니다. SleepDr의 WordPress 사이트는 모바일에서 2.1초의 TTFB를 가졌습니다. 이는 아무것도 발생하기 전에 — 이미지가 로드되기 전에, 폰트가 다운로드되기 전에, JavaScript가 실행되기 전에 — 사용자가 서버 응답을 기다리며 빈 화면을 2초 이상 보고 있다는 의미입니다.
WordPress가 왜 그렇게 느렸나요?
WordPress의 모든 페이지 요청:
- 공유 호스팅 서버에 hit했습니다 (이미 느림)
- PHP를 로드했습니다
- WordPress core를 실행했습니다
- 34개의 플러그인 hooks를 실행했습니다
- MySQL을 여러 번 쿼리했습니다
- 동적으로 HTML을 생성했습니다
- 응답을 보냈습니다
WP Super Cache가 설치되어 있더라도, 캐시 hit rate는 일관성이 없었고 서버 자체는 underpowered였습니다.
우리가 한 일
모든 228개의 블로그 게시물에 대한 정적 생성. 빌드 시간에 Next.js는 모든 블로그 게시물을 정적 HTML로 pre-renders합니다. 결과는 Vercel의 Edge Network에 있는 .html 파일 세트입니다 — 80개 이상의 글로벌 위치에 분산되어 있습니다.
사용자가 블로그 게시물을 요청할 때, 그들은 가장 가까운 edge 노드에서 pre-built HTML 파일을 제공받습니다. 데이터베이스 쿼리 없음. 서버 사이드 처리 없음. CDN에서의 파일 읽기일 뿐입니다.
// app/blog/[slug]/page.tsx
export async function generateStaticParams() {
const posts = await payload.find({
collection: 'posts',
limit: 300,
});
return posts.docs.map((post) => ({
slug: post.slug,
}));
}
export default async function BlogPost({ params }: { params: { slug: string } }) {
const post = await payload.find({
collection: 'posts',
where: { slug: { equals: params.slug } },
limit: 1,
});
return <ArticleLayout post={post.docs[0]} />;
}
연락처 양식 페이지의 경우, 동적 동작이 필요했으므로 server-side rendering을 사용했습니다. 하지만 Vercel의 Edge Functions에 대한 SSR도 100ms 미만에서 실행됩니다. 중앙 데이터 센터가 아닌 edge에서 compute가 발생하기 때문입니다.
순 효과: TTFB가 2.1초에서 0.3초로 드롭되었습니다 — 85% 개선입니다. repeat 방문 시 캐싱을 사용하면 50ms에 가까워집니다.
최적화 5: 제3자 스크립트 관리
제3자 스크립트는 웹 성능의 silent killer입니다. SleepDr의 WordPress 사이트는 Google Analytics (GA4), Google Tag Manager, Facebook pixel, Hotjar recording script 및 쿠키 동의 관리자를 로드했습니다 — 모두 <head>에서 render-blocking이었습니다.
우리가 한 일
Next.js는 loading strategies를 가진 next/script component를 제공합니다. 저희는 의도적으로 사용했습니다:
import Script from 'next/script';
{/* 분석: 페이지가 상호작용 가능해진 후 로드 */}
<Script
src="https://plausible.io/js/script.js"
strategy="afterInteractive"
data-domain="sleepdr.com"
/>
{/* 쿠키 동의: 브라우저가 유휴 상태일 때 로드 */}
<Script
src="/scripts/cookie-consent.js"
strategy="lazyOnload"
/>
afterInteractive strategy는 Next.js hydration이 완료된 후 스크립트를 로드합니다. 사용자는 이미 페이지를 보고 상호작용할 수 있습니다. lazyOnload strategy는 브라우저가 완전히 유휴 상태가 될 때까지 기다립니다 — non-critical 스크립트에 좋습니다.
또한 Google Analytics를 Plausible (< 1KB, privacy-focused, 대부분의 관할권에서 쿠키 동의가 필요 없음)로 교체했습니다. Hotjar를 완전히 제거했습니다 — SleepDr은 실제로 recordings을 검토하지 않고 있었습니다. Facebook pixel을 제거했습니다. 6개월 전에 Facebook 광고 실행을 중단했기 때문입니다.
불필요한 제3자 스크립트를 제거하는 것은 웹 개발에서 가장 쉬운 성능 win입니다. 저는 계속 이것을 말합니다. 대부분의 사이트는 팀의 누구도 적극적으로 사용하지 않는 서비스를 위한 스크립트를 로드합니다.
최적화 6: CSS 최적화 (800KB → 35KB)
SleepDr의 WordPress 테마는 약 800KB의 CSS를 배송했습니다. 이것은 테마의 스타일시트, 플러그인 스타일시트, 전체 Bootstrap grid 시스템 (unused) 및 Font Awesome (약 12개의 아이콘)을 포함했습니다.
우리가 한 일
자동 purging이 있는 Tailwind CSS. Tailwind는 빌드 시간에 템플릿 파일을 스캔하고 실제로 사용하는 utility classes에 대해서만 CSS를 생성합니다. 저희의 프로덕션 CSS 번들: 35KB (gzipped: ~8KB).
// tailwind.config.ts
export default {
content: [
'./app/**/*.{ts,tsx}',
'./components/**/*.{ts,tsx}',
],
theme: {
extend: {
fontFamily: {
sans: ['var(--font-inter)'],
serif: ['var(--font-merriweather)'],
},
},
},
};
12개의 아이콘의 경우, 저희는 인라인 SVGs를 사용했습니다. icon 라이브러리가 없습니다. 각 SVG는 약 500바이트입니다. 전체 아이콘 weight: Font Awesome의 70KB+ 대신 ~6KB.
결과는 zero render-blocking CSS 요청입니다. Tailwind의 출력은 Next.js에 의해 초기 HTML payload에 인라인되므로 브라우저는 즉시 렌더링을 시작할 수 있습니다.
순 효과: CSS가 96% 감소, FCP 및 TBT 개선에 기여합니다.
단계별 체크리스트
비슷한 성능 문제에 직면하고 있다면, 여기에 제가 건드리는 정확한 순서입니다. 이것은 impact-to-effort ratio로 prioritized됩니다.
Phase 1: Quick Wins (1주)
- 10개의 최고 트래픽 페이지에서 Lighthouse 실행 (모바일 모드)
- 각 페이지 템플릿의 LCP 요소 식별
- 모든 이미지 및 iframes에 명시적
width및height추가 - 아래 스크롤 이미지에
loading="lazy"추가 - LCP 이미지에
fetchpriority="high"추가 - 제3자 스크립트 감사 — unused 항목 제거
- 남은 제3자 스크립트를
async또는defer로 이동
Phase 2: Font and CSS (2주)
- 웹 폰트를 자체 호스팅 (외부 폰트 요청 제거)
- 모든
@font-face선언에font-display: swap추가 - 필요한 character set만으로 폰트 subset
- CSS 감사 — unused stylesheets 제거
- icon fonts를 인라인 SVGs로 교체
Phase 3: JavaScript (3주)
- bundle analyze로 largest JS dependencies 식별
- 가능하면 jQuery 제거
- non-critical components를 동적으로 import
- non-essential JavaScript defer
- 경로별 code splitting 구현
Phase 4: Infrastructure (4주+)
- CDN / edge 배포 옵션 평가
- 콘텐츠 페이지에 대한 정적 생성 구현
- 적절한 캐시 헤더 설정
- WordPress가 bottleneck인 경우 full migration을 modern framework로 고려
마지막 지점을 고려하고 있다면 — 전체 마이그레이션 — 저희에게 연락하세요. 저희는 이 정확한 유형의 프로젝트를 많은 번 수행했습니다. 저희의 pricing page는 headless migrations이 일반적으로 비용이 얼마나 드는지에 대한 세부 사항을 가집니다.
2026 Core Web Vitals가 사이트에 의미하는 것
Google의 2026년 3월 Core Update는 게임을 바꿨습니다. CWV는 더 이상 페이지별로 평가되지 않습니다 — 전체 도메인에 걸쳐 aggregated되고 트래픽 가중치를 부여합니다. 이는:
- 200개의 블로그 게시물에서 사용하는 단일 느린 페이지 템플릿이 전체 사이트의 순위를 tank합니다
- 높은 트래픽 페이지는 aggregate 점수에서 더 많은 가중치를 갖습니다
- 홈페이지를 최적화하고 끝을 낼 수 없습니다
롤아웃의 초기 데이터는 poor CWV가 있는 사이트가 20-35% 오가닉 트래픽 감소를 경험했음을 보여줍니다. 일부는 50% 이상의 손실을 봤습니다. 가장 빠르게 회복한 사이트는 개별 페이지를 tweaking함으로써가 아닌 infrastructure 수준에서 성능을 해결한 사이트였습니다 — 228개의 개별 WordPress 페이지를 최적화함으로써가 아닌, 기본 delivery system을 재구축함으로써.
이것이 정확히 SleepDr의 마이그레이션이 그렇게 효과적인 이유입니다. 저희는 228개의 개별 WordPress 페이지를 최적화하지 않았습니다. 저희는 모든 페이지가 기본적으로 빠르도록 전체 delivery system을 재구축했습니다.
전체 마이그레이션을 할 준비가 되지 않은 사이트의 경우, Astro와 같은 frameworks는 또 다른 compelling path를 제공합니다 — 특히 기본적으로 near-zero JavaScript를 원하는 콘텐츠가 많은 사이트의 경우입니다.
| 접근 방식 | 전형적인 비용 | 타임라인 | 예상 Lighthouse 증가 |
|---|---|---|---|
| WordPress 플러그인 최적화 (WP Rocket, ShortPixel) | $100-500/yr | 1-2주 | +10-20점 |
| WordPress 테마 교체 | $2,000-5,000 | 2-4주 | +15-25점 |
| Headless CMS 마이그레이션 (Next.js/Astro) | $15,000-50,000 | 4-10주 | +30-60점 |
| 전체 플랫폼 rebuild | $30,000-100,000+ | 8-20주 | +40-65점 |
SleepDr의 프로젝트는 228개 게시물의 모든 콘텐츠 transfer, CMS 설정, 사용자 정의 components 및 성능 최적화를 포함하여 $20,000-25,000 범위에 해당했습니다. Vercel 호스팅은 Pro 계획에서 $20/month를 실행합니다. 이는 TTFB를 2초 미만으로 유지할 수 없었던 공유 호스팅을 위해 지불했던 $300/year 대략 $740/year입니다.
ROI는 무엇이었나요? 오가닉 트래픽은 6주 내에 회복되었고 10주차까지 pre-decline 수준을 넘었습니다. 오가닉 검색에 의존하는 비즈니스의 경우, 마이그레이션은 첫 분기 내에 자체로 비용을 지불했습니다.
FAQ
Core Web Vitals 개선이 Google 순위에 영향을 미치기까지 얼마나 걸리나요? 저희의 SleepDr 및 유사 프로젝트 경험상, Search Console은 배포 후 28일 내에 업데이트된 CWV 데이터를 표시하기 시작합니다. 순위 개선은 일반적으로 2-3개월 후에 따릅니다. Google은 페이지를 re-crawl해야 하고, 실제 Chrome 사용자 (CrUX 데이터)에서 fresh 데이터를 수집하고, 순위 알고리즘에 이를 factor해야 합니다. 밤새 결과를 기대하지 마세요 — 하지만 분기 내에 측정 가능한 개선을 기대하세요.
94의 Lighthouse 점수는 실제 프로덕션 사이트에서 실제로 달성 가능한가요? 그렇습니다. 하지만 처음부터 의도적인 architecture 선택이 필요합니다. 모바일에서 90 이상의 Lab 점수는 Next.js 또는 Astro와 같은 modern frameworks로 달성 가능합니다. 제3자 스크립트를 제어하고, 이미지를 적절히 최적화하며, edge network에 배포할 때 가능합니다. 핵심은 모든 component가 performance-aware여야 한다는 것입니다. 하나의 나쁜 embed 또는 최적화되지 않은 제3자 widget은 70대로 다시 떨어질 수 있습니다.
좋은 Core Web Vitals 점수를 얻기 위해 WordPress에서 떠나야 하나요? 반드시는 아닙니다. WordPress 사이트 는 올바른 테마, 공격적인 캐싱 (WP Rocket + Cloudflare), 최적화된 호스팅 (Kinsta, WP Engine) 및 최소한의 플러그인으로 잘 할 수 있습니다. 현실적으로, 저희가 감사하는 대부분의 WordPress 사이트는 누적된 플러그인 bloat 및 테마 overhead로 인해 모바일에서 30-60점을 얻습니다. 50 아래에 있다면, 플러그인 최적화만으로는 75 이상을 얻을 가능성이 없습니다. headless approach — WordPress가 콘텐츠 API로 역할하는 동안 frontend framework가 렌더링을 처리하는 곳 — 는 종종 explore할 가치가 있는 middle ground입니다.
Lighthouse 점수와 실제 Core Web Vitals 데이터의 차이점은 무엇입니까? Lighthouse는 lab tool입니다 — throttled 4G의 중급 휴대폰을 시뮬레이션하고 합성 점수를 제공합니다. Search Console의 Core Web Vitals는 field data입니다 — 실제 Chrome 사용자가 28일 rolling window에 걸쳐 사이트를 방문한 실제 측정입니다. Google은 ranking signals에 field data를 사용합니다, lab 점수가 아닙니다. Lighthouse는 문제를 진단하고 fixes를 테스트하는 데 유용하지만, 목표는 Search Console에서 75번째 percentile에서 green CWV 상태입니다.
LCP에 대한 가장 영향력 있는 단일 최적화는 무엇입니까?
이미지 최적화입니다. 저희가 감사하는 사이트의 약 60%에서, LCP 요소는 이미지입니다. 적절하게 크기를 지정하고, WebP/AVIF 형식으로 제공하고, fetchpriority="high"를 추가하고, lazy-load하지 않도록 하면 일반적으로 LCP를 2-4초 줄입니다. SleepDr에서 이미지 최적화만 LCP 개선의 약 3초를 차지했습니다.
Google의 2026 holistic CWV 점수는 어떻게 작동합니까? 2026년 3월 Core Update 이후, Google은 페이지별로 평가하지 않고 전체 도메인에 걸쳐 Core Web Vitals 데이터를 aggregates합니다. 높은 트래픽 페이지는 계산에서 더 많은 가중치를 갖습니다. 이는 수백 개의 페이지에서 사용하는 느린 블로그 archive template이 홈페이지 순위를 끌어내린다는 의미입니다. fix는 architectural입니다 — 모든 페이지 템플릿이 CWV 임계값을 통과해야 하지만, 주요 landing pages만은 아닙니다.
WordPress에서 Next.js 마이그레이션은 일반적으로 얼마나 비용이 드나요? SleepDr과 유사한 콘텐츠 사이트 (200+ 페이지, 표준 블로그 레이아웃, 연락처 양식, e-commerce 없음)의 경우, 경험이 있는 agency에서 $15,000-30,000을 기대합니다. e-commerce 마이그레이션은 complexity에 따라 $30,000-75,000+ 더 높게 실행됩니다. Vercel Pro에서의 지속적인 호스팅은 $20/month입니다. ROI는 오가닉 트래픽이 비즈니스에 얼마나 가치 있는지에 달려 있지만, poor CWV에서 트래픽 감소를 경험한 사이트의 경우, 마이그레이션은 일반적으로 3-6개월 내에 비용을 지불합니다.
모바일 또는 데스크톱 Lighthouse 점수에 중점을 두어야 하나요? 모바일. 항상 모바일 첫 번째입니다. Google은 mobile-first indexing을 사용하고, Lighthouse 모바일 점수는 constrained 장치와 네트워크를 시뮬레이션하기 때문에 데스크톱보다 훨씬 더 가혹합니다. 모바일 점수가 94라면 데스크톱 점수는 거의 확실히 95+ 될 것입니다. SleepDr의 99 데스크톱 점수는 모바일 최적화를 위해 한 일 이상으로 zero 추가 작업이 필요했습니다.