Lighthouse·Speed Insights·모니터링
공식문서 기반의 Next.js 입문기
들어가며
지난 포스트에선 CWV를 개선하는 방법을 다뤘습니다. 이번 편에서는 그 개선 효과를 어떻게 확인하고 유지할지 살펴보겠습니다.
CWV 측정은 "개선 → 측정 → 재개선"의 실험 루프입니다. 최적화가 실제로 효과가 있는지 확인하고, 문제가 있으면 다음 주기를 준비합니다. 이 루프가 CWV를 지속적 운영으로 만듭니다.
CWV 측정 전략
CWV 측정은 타이밍별 접근과 자동화의 균형입니다. Next.js에서는 Lighthouse/Speed Insights/모니터링을 통합합니다.
주요 측정 도구 이해
Lighthouse: 브라우저에서 실행되는 자동화 도구로, 성능·접근성·SEO를 평가합니다. CWV에서는 LCP/FID/CLS의 실험실 데이터를 제공합니다. Chrome DevTools나 CLI로 실행하며, web.dev/lighthouse에서 확인할 수 있습니다.
Speed Insights: 실제 사용자 데이터를 기반으로 CWV를 측정합니다. 전 세계 사용자의 브라우저 데이터를 수집해 실제 네트워크 조건을 반영합니다. pagespeed.web.dev에서 사용하거나 Google Search Console에서 확인할 수 있으며, Next.js에서는 @vercel/speed-insights 패키지로 내장 컴포넌트 형태로 쉽게 통합할 수 있습니다.
모니터링: 시간에 따른 CWV 변화를 관찰합니다. 개선 효과를 유지하고 새로운 문제를 찾아냅니다. Vercel Analytics나 web-vitals 라이브러리로 구현하며, 대시보드에서 추세를 모니터링합니다.
이 전략은 검색 엔진 평가 방식과 유사합니다. 측정은 CWV 최적화를 검증하고 유지하는 피드백 루프로 작동합니다.
기능 구현 및 비교
이번 섹션에서는 "랜딩 페이지 히어로 섹션 CWV 측정" 시나리오를 기준으로, CSR에서 측정을 어떻게 수동 관리하는 한계를 보여드린 뒤 Next.js로 동일한 목표를 구현해보겠습니다.
리액트 단독 – 클라이언트 측 수동 측정
CSR에서는 모든 측정을 클라이언트에서 수동으로 처리합니다. Lighthouse는 브라우저 확장으로 실행하고, 사용자 데이터는 분석 스크립트로 수집하며, 모니터링은 별도 서비스로 구축합니다.
src/
├── components/
│ ├── Hero.jsx // 히어로 섹션 컴포넌트
│ ├── PerformanceMonitor.jsx // 성능 측정 컴포넌트
│ └── AnalyticsTracker.jsx // 분석 트래커 컴포넌트
├── pages/
│ └── index.jsx // 랜딩 페이지
└── utils/
└── performance.js // 성능 측정 유틸랜딩 페이지에서 성능을 수동으로 측정합니다:
// src/components/PerformanceMonitor.jsx
import { useEffect } from "react";
export function PerformanceMonitor() {
useEffect(() => {
// LCP 측정
const observer = new PerformanceObserver((list) => {
const entries = list.getEntries();
const lastEntry = entries[entries.length - 1];
console.log("LCP:", lastEntry.startTime);
});
observer.observe({ entryTypes: ["largest-contentful-paint"] });
// CLS 측정
let clsValue = 0;
new PerformanceObserver((list) => {
for (const entry of list.getEntries()) {
if (!entry.hadRecentInput) {
clsValue += entry.value;
}
}
console.log("CLS:", clsValue);
}).observe({ entryTypes: ["layout-shift"] });
return () => observer.disconnect();
}, []);
return null;
}이 코드는 CSR의 기본 측정 패턴입니다. PerformanceObserver로 CWV를 수동 측정하고, 분석 스크립트로 사용자 데이터를 수집합니다.
리액트 방식의 한계
CSR에서는 측정 타이밍이 “제대로 등록되는가”에 따라 크게 달라집니다. 브라우저가 LCP/CLS/FID를 계산하는 직후에 PerformanceObserver를 등록해야 하는데, 클라이언트 번들이 로드된 이후에야 관련 코드를 실행하고 외부 스크립트를 붙이기 때문에 초기 이벤트를 놓칠 수 있습니다. 조치를 취하지 않으면 측정이 불안정하게 느껴지지만, <head>에 인라인 스크립트를 두거나 리소스를 최대한 빨리 연결하면 개선할 수 있습니다. 그래도 사용자 데이터의 다양성을 반영하거나 측정 결과를 다음 개선 주기와 연결하는 피드백 루프는 여전히 약합니다.
Next.js 구성 – 서버 측 측정 제어
Next.js에서는 app/ 구조와 내장 도구로 측정을 서버에서 제어합니다. Speed Insights 측정과 모니터링 확인을 내장 도구로 지원하며, 히어로 섹션에 Lighthouse 기준을 적용하고 실제 데이터를 수집하며 추세를 관찰합니다.
app/
├── layout.tsx // Speed Insights 설정
├── page.tsx // 랜딩 페이지 + 히어로 섹션
├── components/
│ └── Hero.tsx // 히어로 컴포넌트 (성능 측정 포함)
└── instrumentation.ts // 모니터링 설정랜딩 페이지 히어로 섹션에서 Lighthouse 기준을 적용합니다:
// app/components/Hero.tsx
import Image from "next/image";
export function Hero() {
return (
<section className="hero">
<Image
src="/hero-image.jpg"
alt="Hero"
width={1200}
height={800}
priority
placeholder="blur"
sizes="(max-width: 768px) 100vw, 50vw"
/>
<h1>웰컴 투 마이 사이트</h1>
<p>최고의 경험을 제공합니다</p>
</section>
);
}루트 레이아웃에서 Speed Insights를 설정합니다. Next.js에서는 @vercel/speed-insights 패키지를 통해 실제 사용자 데이터를 자동으로 수집하고 Vercel 대시보드에서 확인할 수 있습니다:
// app/layout.tsx
import { SpeedInsights } from "@vercel/speed-insights/next";
export default function RootLayout({ children }: React.ReactNode) {
return (
<html lang="ko">
<body>
{children}
<SpeedInsights />
</body>
</html>
);
}모니터링을 위한 instrumentation을 설정합니다:
// app/instrumentation.ts
export async function register() {
if (process.env.NEXT_RUNTIME === "nodejs") {
const { WebVitals } = await import("@vercel/web-vitals");
WebVitals.register();
}
}이 구조가 측정의 핵심입니다. 서버에서 Lighthouse 기준을 적용해 일관된 품질을 보장하고, SpeedInsights 컴포넌트로 실제 사용자 데이터를 자동 수집하며, instrumentation.ts로 모니터링을 구축해 개선 효과를 지속적으로 추적합니다. 이를 통해 배포 전 예측부터 실제 운영까지 전체 사이클을 연결합니다.
리액트 vs Next.js 비교표
| 구분 | 리액트 (CSR + 수동 측정) | Next.js (서버 측 측정 제어 + 내장 도구) |
|---|---|---|
| 실행 환경 기본값 | 브라우저에서 수동 실행 | 서버에서 기준 적용 |
| 데이터 접근 모델 | 수동으로 pagespeed.web.dev 확인 | SpeedInsights 컴포넌트로 자동 수집 |
| 번들 관점 | 측정 로직이 번들에 포함 | 내장 도구로 영향 최소 |
| 컴포넌트 분리 의미 | 측정 로직이 비즈니스와 결합 | 측정/비즈니스로 관심사 분리 |
| 설계의 제약 | 측정 품질이 개발자 역량에 달려 | 내장 API로 자동화 |
측정의 트레이드오프
장점
- 객관적 판단: 실험실/실제 사용자 데이터로 개선 효과 정확히 측정
- 지속적 모니터링: 장기 추이 파악과 이슈 조기 발견
- 데이터 기반 의사결정: 측정 결과를 개선 주기와 연결
단점
- 데이터 해석 복잡성: 실험실 vs 실제 데이터 차이로 해석 어려움
- 타이밍 고려: 개선 효과가 배포 후 1-2주 지나야 안정화
- 다중 디바이스 관리: 환경별 다른 결과로 통합 판단 어려움
균형 맞추기 팁
Lighthouse로 예측을 수행하고 Speed Insights로 검증하세요. CWV 3지표에 우선순위를 두고, 배포 후 1-2주를 기다려 안정 데이터를 확인하세요.
예상 질문
Q1. Lighthouse 점수가 좋지 않은데 배포해야 하나요?
실험실 점수가 나쁘면 개선하는 게 좋지만, 완벽한 점수를 위해 출시를 미루지 마세요. 실제 사용자 데이터가 더 중요합니다. Lighthouse는 최적화 방향을 알려주는 가이드일 뿐입니다.
Q2. Speed Insights에 데이터가 안 쌓이면 어떻게 하나요?
실제 트래픽이 필요합니다. 리액트 단독에서는 pagespeed.web.dev에 URL을 입력해 수동으로 확인할 수 있지만, Next.js에서는 SpeedInsights 컴포넌트가 자동으로 데이터를 수집합니다. 배포 후 24-48시간 기다려보세요. 트래픽이 적으면 1주일 정도 걸릴 수 있습니다.
Q3. Lab Data와 Field Data의 차이가 너무 크면?
Lab Data는 예측치고 Field Data는 실제 환경입니다. Field Data를 우선으로 개선하세요.
Q4. 모니터링 알림이 너무 많이 오면 어떻게 하나요?
임계값을 조정하세요. CLS 0.1 이상, LCP 2.5초 초과 같은 수준으로 설정합니다.
Q5. CWV 측정이 검색 순위에 언제 반영되나요?
크롤링 주기에 따라 1-2주가 걸릴 수 있습니다. PageSpeed Insights로 현황을 확인하세요.
요약
이번 편에서는 CWV 측정을 개선 루프의 관점으로 다뤘습니다. CSR에서는 클라이언트에서 수동 관리해 측정이 불안정했지만, Next.js에서는 내장 도구로 서버 측에서 제어합니다.
핵심은 측정 타이밍의 균형입니다. 배포 전 Lighthouse로 예측을, 배포 후 Speed Insights로 검증을, 지속 모니터링으로 유지합니다.
이를 통해 측정 자동화, 실제 사용자 데이터의 자동 수집, 루프 구축, 품질 유지가 이루어지며, 검색 엔진 신뢰가 유지됩니다.