검색 — 랭킹 시그널
Core Web Vitals는 Google 검색이 참고하는 페이지 경험 신호입니다. 관련성과 콘텐츠 품질이 우선이며, 경험 지표는 여러 신호 중 하나로 활용됩니다.
검색 기본 점검과 속도 확인하기Core Web Vitals
구매 흐름의 순간을 재는 세 가지 지표
LCP, CLS, INP는 점수가 아닙니다. 고객이 상품페이지에서 겪는 세 순간 — 첫 이미지가 뜨고, 화면이 안정되고, 클릭이 반응하는 — 을 측정하는 지표입니다.
Concept Map
세 지표는 구매 여정의 순서대로 작동합니다
고객이 페이지를 만나는 순서 위에 지표를 올려놓으면 각 지표가 무엇을 재는지 분명해집니다.
Why It Matters
커머스 담당자가 직접 확인해야 하는 이유
사용자 — 이탈과 전환
로딩이 길어질수록 이탈은 급격히 늘어납니다. 특히 모바일 상품 상세에서 첫 이미지 지연은 곧 구매 흐름의 이탈로 이어집니다.
운영 — 랩 데이터 / 필드 데이터(CrUX)
Lighthouse 랩 데이터가 좋아도 실사용자 필드 데이터(CrUX)는 나쁠 수 있습니다. “점수는 좋은데 고객은 느리다”가 생기는 이유 — 둘을 함께 봐야 합니다.
LCP Breakdown
LCP는 네 단계로 나눠야 원인이 보입니다
LCP 하나가 나쁘게 보이더라도 원인은 서버 응답, 리소스 발견, 이미지 전송, 렌더링 지연으로 갈립니다. 이 단계를 나눠야 어떤 M2 모듈부터 적용할지 결정할 수 있습니다.
측정 기준: Core Web Vitals 필드 데이터는 평균값이 아니라 실사용 75번째 백분위수 기준으로 봅니다. 모바일과 데스크톱은 별도로 판단합니다.
The Three Metrics
지표별로 보는 정의, 기준, 흔한 원인
등급 라벨은 web.dev 기준인 좋음, 개선 필요, 나쁨을 사용합니다.
LCP
Largest Contentful Paint화면에서 가장 큰 콘텐츠가 그려지기까지 걸린 시간.
상품 상세에서는 사실상 “첫 상품 이미지가 뜨는 시간”입니다.
좋음 ≤ 2.5초개선 필요 ~ 4.0초나쁨
상품 상세에서 흔한 원인
- ·원본 그대로 내려오는 무거운 상세 이미지
- ·이미지보다 먼저 로드되는 외부 스크립트
- ·느린 원본 서버 응답 (TTFB)
CLS
Cumulative Layout Shift로딩 중 화면 요소가 얼마나 밀려나는지의 누적 점수.
읽던 상품평이 갑자기 내려가거나, 누르려던 버튼 위로 배너가 끼어드는 정도입니다.
좋음 ≤ 0.1개선 필요 ~ 0.25나쁨
상품 상세에서 흔한 원인
- ·크기 지정 없이 삽입되는 이미지·배너
- ·늦게 로드되는 웹폰트로 인한 텍스트 밀림
- ·동적으로 삽입되는 쿠폰·추천 영역
INP
Interaction to Next Paint클릭·탭 등 상호작용 후 화면이 반응하기까지의 시간.
옵션을 선택하거나 장바구니를 눌렀을 때 화면 반응이 늦어지는 순간입니다.
좋음 ≤ 200ms개선 필요 ~ 500ms나쁨
상품 상세에서 흔한 원인
- ·메인 스레드를 점유하는 무거운 스크립트
- ·탭 직후 실행되는 트래킹·광고 코드
- ·복잡한 DOM에서의 렌더링 비용
Commerce Approach
지표를 통해 객관적으로 병목을 분석합니다
측정
URL 기준으로 CrUX 실사용 데이터와 Lighthouse 랩 데이터를 함께 확인합니다. 평균이 아니라 75번째 백분위수와 실제 LCP 요소를 먼저 봅니다.
해석
LCP, CLS, INP 중 어떤 지표가 구매 흐름을 막는지 분리합니다. 첫 상품 이미지, 화면 밀림, 클릭 반응을 각각 다른 병목으로 봅니다.
개선
확인된 병목부터 M2 Live 모듈과 연결합니다. 첫 이미지, 상품기술서, 캐시, 스크립트 순서로 PoC 범위를 좁혀 개선 효과를 검증합니다.
Metric → Module
각 지표는 서로 다른 M2 모듈과 연결됩니다
진단에서 문제가 드러난 지표를 기준으로 관련 모듈부터 좁혀 적용합니다. 전체 페이지를 한 번에 바꾸기보다 병목이 확인된 영역부터 검증합니다.
LCP
첫 상품 이미지를 빨리 띄운다- HyperDIMS · optimg이미지를 브라우저별 최적 포맷·크기로 실시간 변환 (AVIF 전환 61%, 전송량 −34%)
- PageFX · splitimg세로로 긴 상세 이미지를 분할해 병렬 로딩 — 첫 화면 노출 단축
- PageSpeedlazyload·LQIP로 첫 화면 콘텐츠를 우선 로딩
- gif2video무거운 GIF를 동일 화질 비디오로 대체 (전송량 −92%)
CLS
로딩 중에도 레이아웃이 밀리지 않는다- PageDesk DOM원본 무수정으로 태그·스타일을 제어해 셀러 HTML의 레이아웃 붕괴를 차단
- PageFX디바이스별 반응형 합성으로 화면 크기에 맞는 안정된 레이아웃 제공
- PageMixed차단된 HTTP 리소스를 자동 해소해 이미지 깨짐·재배치 방지
INP
클릭과 탐색에 바로 반응한다- 고객 애플리케이션 점검이벤트 처리와 애플리케이션 JavaScript의 실행 비용은 고객 개발팀이 먼저 확인합니다.
- PageSpeed · optscript외부 스크립트의 전달 순서를 제어할 수 있는 경우에 한해 PoC 범위를 별도로 검토합니다.
- M2 적용 범위 확인이미지·외부 리소스 전달이 반응 지연에 미치는 영향만 근거 데이터로 분리해 확인합니다.
모듈 설명의 수치는 국내 대형 커머스 운영 환경의 월간 실측 기준입니다.
모듈 동작 방식과 적용 순서는 M2 Live Cloud 작동 방식에서 자세히 다룹니다.
Learn Map
Learn 전체 맵 보기 →다음으로 이어서 볼 가이드
지금 읽은 주제와 연결되는 개념을 함께 확인하면 PoC 범위를 더 정확히 잡을 수 있습니다.
내 상품페이지, 검색 기본 점검과 속도는 어떨까요?
주소 하나로 제목·설명·크롤링과 페이지 속도를 함께 확인합니다. 실사용 데이터와 측정 데이터는 구분해 보여드립니다.
지표 정의와 임계값은 web.dev Core Web Vitals, LCP, CLS, INP 문서를 기준으로 정리했습니다. Google, CC BY 4.0.