성능 최적화를 할 때 처음에는 Lighthouse 점수만 확인했다.

하지만 실제 서비스에서는 Lighthouse 점수와 사용자 체감 성능이 항상 일치하지 않았다.

개발 환경에서는 괜찮아 보여도 실제 사용자는 전혀 다른 조건에서 서비스를 사용한다.

느린 네트워크
저사양 디바이스
모바일 브라우저
캐시 상태 차이
페이지 진입 경로 차이

Lighthouse만으로 부족했던 이유

Lighthouse는 성능 개선 방향을 잡는 데 유용하다. 하지만 기본적으로 정해진 테스트 환경에서 실행된다.

반면 실제 서비스에서는 사용자마다 조건이 다르다.

예를 들어 개발자 PC에서는 LCP가 1.5초로 나와도, 실제 모바일 사용자는 4초 이상 걸릴 수 있다.

또 특정 페이지는 전체 평균은 괜찮아 보여도, 일부 저사양 디바이스 사용자에게만 CLS가 높게 발생할 수 있다.

이런 문제는 Lighthouse만으로는 발견하기 어렵다.

그래서 운영 단계에서는 RUM, 즉 Real User Monitoring이 필요하다.

기본 사용 코드

'use client';

import { useReportWebVitals } from 'next/web-vitals';

export function WebVitals() {
  useReportWebVitals((metric) => {
    console.log(metric);
  });

  return null;
}

그리고 모든 페이지에서 공통으로 실행되도록 루트 레이아웃에 넣는다.

import { WebVitals } from './_components/web-vitals';

export default function Layout({
  children,
}: {
  children: React.ReactNode;
}) {
  return (
    <html>
      <body>
        <WebVitals />
        {children}
      </body>
    </html>
  );
}

WebVitals 컴포넌트는 UI를 렌더링하기 위한 컴포넌트가 아니다.

브라우저에서 성능 지표를 수집하기 위한 관찰자 역할에 가깝다.

그래서 화면에는 아무것도 렌더링하지 않고 null을 반환한다.

metric 구조

콜백으로 전달되는 metric에는 성능 지표 정보가 들어 있다.

{
  id: string;
  name: 'FCP' | 'LCP' | 'CLS' | 'FID' | 'TTFB' | 'INP';
  value: number;
  label: 'web-vital' | 'custom';
}

여기서 중요한 값은 보통 name과 value다.

useReportWebVitals((metric) => {
  console.log(metric.name, metric.value);
});

예를 들어

LCP 3200
CLS 0.18
INP 250

같은 식으로 실제 사용자 환경의 성능 데이터를 확인할 수 있다.

주요 지표

FCP

First Contentful Paint.

사용자가 화면에서 첫 번째 콘텐츠를 보기 시작한 시점이다.

빈 화면이 끝나는 타이밍을 보는 지표에 가깝다.

LCP

Largest Contentful Paint.

화면에서 가장 큰 콘텐츠가 렌더링되는 시점이다.

보통 메인 이미지, 제목, 큰 텍스트 블록이 대상이 된다.

실제 사용자가 “페이지가 거의 떴다”고 느끼는 시점과 가깝기 때문에 중요하다.

CLS

Cumulative Layout Shift.

화면 요소가 렌더링 중 얼마나 흔들렸는지 측정한다.

이미지 크기를 미리 잡지 않거나,
광고/배너가 늦게 삽입되면 CLS가 높아질 수 있다.

INP

Interaction to Next Paint.

사용자 입력에 페이지가 얼마나 빠르게 반응하는지 보는 지표다.

클릭, 탭, 키보드 입력 이후 화면이 반응하기까지의 지연을 측정한다.

TTFB

Time To First Byte.

브라우저가 서버로 요청을 보낸 뒤,
첫 번째 응답 바이트를 받기까지 걸린 시간이다.

서버 응답 속도, 캐싱, DB 조회, 네트워크 지연의 영향을 받는다.

동작 방식

useReportWebVitals는 클라이언트에서 실행된다.

'use client';

Web Vitals는 브라우저가 실제로 페이지를 렌더링하고,
사용자가 상호작용하는 과정에서 측정된다.

그래서 Server Component에서는 사용할 수 없다.

측정된 결과는 콜백으로 전달된다.

useReportWebVitals((metric) => {
  console.log(metric);
});

이 콜백 안에서 로그 서버나 분석 도구로 데이터를 전송하면 된다.

실무 활용 방식

개발 중에는 console.log로 확인할 수 있다.

하지만 운영 환경에서는 콘솔 출력이 아니라 별도의 수집 서버로 보내야 한다.

'use client';

import { useReportWebVitals } from 'next/web-vitals';

export function WebVitals() {
  useReportWebVitals((metric) => {
    void fetch('/analytics/web-vitals', {
      method: 'POST',
      headers: {
        'Content-Type': 'application/json',
      },
      body: JSON.stringify(metric),
      keepalive: true,
    });
  });

  return null;
}

여기서 keepalive를 사용하는 이유는
페이지 이동이나 종료 시점에도 요청이 최대한 전송되도록 하기 위해서다.

실제로 수집할 때는 metric만 보내기보다
아래 정보도 함께 보내는 편이 유용하다.

{
  metric,
  path: window.location.pathname,
  userAgent: navigator.userAgent,
  connection: navigator.connection?.effectiveType,
}

이렇게 하면 단순 평균이 아니라

어떤 페이지의 LCP가 느린지
어떤 디바이스에서 CLS가 높은지
모바일 네트워크에서 INP가 나쁜지
특정 경로에서만 TTFB가 높은지

를 분석할 수 있다.

Layout에 넣는 이유

<WebVitals />

이 컴포넌트를 Layout에 넣는 이유는 모든 페이지에서 공통으로 성능 지표를 수집하기 위해서다.

페이지마다 따로 넣으면 누락될 가능성이 크고, 중복 등록될 위험도 있다.

성능 측정은 기능 코드에 흩어지기보다 애플리케이션 공통 레이어에 한 번만 두는 편이 관리하기 좋다.

주의할 점

1. 반드시 Client Component여야 한다

Web Vitals는 브라우저에서 측정되는 값이다.

따라서 useReportWebVitals를 사용하는 컴포넌트에는 반드시 'use client'가 필요하다.

2. 중복 등록을 피해야 한다

Layout, Page, Component 여러 곳에서 동시에 등록하면
같은 지표가 중복 수집될 수 있다.

운영 데이터가 중복되면 평균값이나 비율이 왜곡된다.

그래서 루트에 한 번만 등록하는 구조가 안전하다.

3. 모든 데이터를 무조건 보내면 안 된다

성능 데이터도 결국 로그다.

사용자 수가 많아지면 요청 수가 빠르게 늘어난다.

그래서 운영 환경에서는

샘플링
페이지별 필터링
중요한 지표만 수집
배치 전송

같은 전략이 필요하다.

단순히 모든 metric을 매번 서버로 보내면
오히려 분석 비용과 서버 부하가 증가할 수 있다.