정기 성능 점검: Core Web Vitals를 지속적으로 확인하는 방법

반복 점검이 필요한 이유

성능은 콘텐츠를 불러오고 과제를 완료하는 편의성에 영향을 줍니다. 일반적인 전환 증가율을 적용하지 말고 자신의 사용자에게 미치는 영향을 측정하세요. Google은 순위 시스템에서 Core Web Vitals를 사용하지만 좋은 값이 순위나 유입을 보장하지는 않습니다.

추적할 지표

현재 Core Web Vitals는 다음 세 가지입니다.

LCP(Largest Contentful Paint): 조건에 맞는 가장 큰 가시 콘텐츠 요소의 표시 시점입니다. 2.5초 이하면 좋습니다.
INP(Interaction to Next Paint): 클릭, 탭, 키보드 입력에서 다음 화면 갱신까지의 응답성입니다. 200ms 이하면 좋습니다.
CLS(Cumulative Layout Shift): 예상하지 못한 레이아웃 이동입니다. 단위 없이 0.1 이하면 좋습니다.

INP는 2024년 3월 FID를 대체했습니다. 실제 방문은 모바일과 데스크톱을 나누어 75번째 백분위수로 평가합니다. 실험실 테스트는 선택한 조건과 동작을 설명하며 모든 방문자를 대표하지 않습니다. 실제 방문 데이터가 없다고 통과한 것은 아닙니다.

결과가 바뀌는 이유

새 콘텐츠, 기능, 외부 스크립트, 코드와 서버 부하는 동작을 바꿀 수 있습니다. 브라우저와 측정 규칙도 바뀌므로 버전을 기록하세요. 반복 점검은 성능 저하를 찾고 조사 우선순위를 정하는 데 도움이 되지만 사용자에게 영향을 주기 전의 발견을 보장하지는 않습니다.

위험에 따라 주기 정하기

초기 예로, 변경이 적은 안내 사이트는 3개월마다, 블로그는 매월, 온라인 상점은 2주마다 검토할 수 있습니다. 보편적인 기준은 아닙니다. 중요한 배포와 문제 신고가 있으면 일정과 별도로 검사해야 합니다. 자주 바뀌는 서비스에는 예약된 합성 테스트와 실제 방문 모니터링이 필요할 수 있습니다.

정기 테스트는 간격을 두고 실행됩니다. 영향과 자원에 맞춰 빈도, 페이지, 기기 프로필, 지역을 정하세요. ‘지속적인 모니터링’이 모든 동작을 시험하거나 모든 장애를 즉시 발견한다는 뜻은 아닙니다.

재현 가능한 점검 절차

홈, 상품·서비스, 폼, 중요한 상호작용 등 대표 페이지와 과제를 고릅니다. 최종 URL과 조건을 기록합니다.
실험실 측정과 가능한 실제 방문 데이터를 수집합니다. PageSpeed Insights에서 두 영역을 구분하고 데이터가 URL 단위인지 전체 오리진 단위인지 확인합니다.
문제에 따라 LCP, INP, CLS를 조사합니다. 로딩, 응답 지연, 레이아웃 이동에는 서로 다른 원인이 있을 수 있습니다.
이미지 크기·형식, 비싼 처리, 캐시나 전달 방식 등 제한된 수정을 시험합니다. 필요한 기능과 비공개 응답의 접근 규칙을 유지하고 LCP 이미지는 지연 로딩하지 않습니다.
게시 후 비슷한 조건에서 같은 테스트를 반복합니다. 시간뿐 아니라 과제 결과도 확인하고 게시일을 기록합니다.

자동 모니터링 설정

실제 일정, 알림 조건, 전달 채널, 이력 보관 기간을 확인하세요. 성능 저하, 실행 실패, 측정값 누락을 구분합니다. 알림 수신을 시험하고 유효한 경고를 조사할 담당자를 정하세요. 예약된 실험실 테스트와 실제 사용자 데이터는 다른 질문에 답합니다.

Google Analytics는 설정된 사용·전환 데이터를, Search Console은 검색 데이터와 Core Web Vitals 보고서를 제공합니다. 별개의 출처이며 이 글은 속도 스캐너와의 자동 연동을 입증하지 않습니다. 같은 기간을 비교하고 동시에 진행된 변경도 기록하세요.