서치콘솔 켰다가 코어 웹 바이탈에 빨간불이 잔뜩 떠서 놀라신 적 있으실 텐데요, 용어는 낯설어도 원인은 대부분 정해져 있으니 오늘 하나씩 차근차근 짚어드리면서 실전 개선법까지 알려드릴게요.
서치콘솔을 켜봤다가 "코어 웹 바이탈" 리포트에 빨간색이나 노란색으로 잔뜩 표시된 걸 보고 뭔가 큰일 난 줄 알고 놀라신 사장님 많으실 거예요. 용어부터 낯설고 LCP니 CLS니 하는 알파벳 약자가 나오면 더 막막해지죠. 그런데 사실 이 지표들은 구글이 "사용자가 이 페이지를 얼마나 쾌적하게 경험했는가"를 숫자로 바꿔놓은 것뿐이라, 뜯어보면 그렇게 어려운 개념이 아니에요. 쇼핑몰에서는 특히 상품 이미지가 많고 배너나 팝업이 자주 뜨다 보니 이 지표들이 나쁘게 나오는 경우가 흔합니다. 오늘은 코어 웹 바이탈 중에서도 쇼핑몰 사장님이 가장 자주 마주치는 LCP와 CLS 두 가지를 중심으로, 뭘 고쳐야 하는지 실전 위주로 설명드리겠습니다.
LCP는 Largest Contentful Paint의 줄임말로, 화면에서 가장 큰 요소(보통은 대표 이미지나 배너)가 다 그려지기까지 걸리는 시간을 말해요. 구글 기준으로 2.5초 이내면 양호, 2.5초에서 4초 사이면 개선 필요, 4초를 넘으면 불량으로 분류됩니다. 쇼핑몰 페이지는 대부분 상단에 큰 배너나 대표 상품 이미지가 있는데, 이 이미지가 무겁거나 로딩 우선순위가 낮게 잡혀 있으면 LCP가 쉽게 나빠져요. 여기서 헷갈리기 쉬운 게 페이지 전체가 다 로딩되는 시간이 아니라, 화면에서 가장 눈에 띄는 요소 하나가 그려지는 시점만 잰다는 점이에요. 즉 페이지 하단에 무거운 요소가 잔뜩 있어도 상단의 대표 이미지만 빠르게 뜨면 LCP 자체는 좋게 나올 수 있습니다.
실제로 제가 봤던 사례 중에는 메인 배너 이미지 하나가 3.8MB짜리 원본 그대로 걸려있어서 LCP가 5초 넘게 나온 몰도 있었어요. 이 경우는 배너 이미지를 리사이즈하고 웹피로 바꾸는 것만으로 LCP가 2.1초까지 떨어졌습니다. 그 외에도 서버 응답 자체가 느리거나, 배너 위에 자바스크립트로 나중에 텍스트를 얹는 방식으로 만들어져 있으면 LCP가 늦어지는 원인이 되니 확인해보셔야 해요.
CLS는 Cumulative Layout Shift의 줄임말로, 페이지가 로딩되는 동안 요소들이 얼마나 갑자기 움직이는지를 나타내는 지표예요. 구글 기준으로 0.1 이하면 양호, 0.1에서 0.25 사이면 개선 필요, 0.25를 넘으면 불량입니다. 손님이 상품을 클릭하려는 순간 배너나 쿠폰 팝업이 갑자기 튀어나와서 엉뚱한 곳을 클릭하게 만드는 경험, 다들 한 번쯤 겪어보셨을 텐데 이게 바로 CLS가 나쁜 상태예요.
쇼핑몰에서 CLS가 나빠지는 가장 흔한 원인은 이미지에 가로세로 크기(width, height)를 미리 지정해두지 않은 경우입니다. 이미지가 로딩되기 전에는 브라우저가 그 자리에 얼마만큼의 공간을 잡아둬야 할지 몰라서, 이미지가 실제로 로딩되는 순간 주변 콘텐츠가 아래로 훅 밀리는 현상이 생기거든요. 쿠폰 팝업이나 상단 공지 배너가 페이지 로딩 후에 뒤늦게 삽입되는 구조도 CLS를 나쁘게 만드는 흔한 원인이고요.
세 가지 핵심 지표의 기준값을 표로 정리해봤어요. INP(Interaction to Next Paint)는 2024년부터 기존 FID를 대체해서 새로 추가된 지표로, 손님이 버튼을 클릭했을 때 화면이 반응하기까지 걸리는 시간을 측정합니다. 장바구니 담기 버튼이나 옵션 선택 버튼의 반응이 느리다고 느껴진다면 이 지표를 확인해보세요. INP가 나쁘게 나오는 쇼핑몰은 대체로 상세페이지에 걸어둔 자바스크립트가 너무 많거나, 옵션을 선택할 때마다 무거운 연산을 다시 돌리는 구조인 경우가 많습니다.
세 지표는 서로 완전히 독립적이지 않아요. 이미지 최적화를 하면 LCP가 좋아지면서 동시에 서버 부하가 줄어 INP도 함께 개선되는 경우가 많고, 이미지 크기를 명시해서 CLS를 잡으면 화면이 안정되면서 사용자가 버튼을 더 정확하게 눌러 INP 체감도 좋아지는 식으로 서로 영향을 주고받습니다. 그러니 세 지표를 따로따로 완벽하게 잡으려 하기보다, 이미지·폰트·스크립트 정리라는 기본기를 탄탄히 하면 세 지표가 함께 좋아지는 경우가 대부분이라는 점을 기억해두세요.
| 지표 | 측정 대상 | 양호 | 개선 필요 | 불량 |
|---|---|---|---|---|
| LCP | 가장 큰 요소 로딩 시간 | 2.5초 이하 | 2.5~4초 | 4초 초과 |
| CLS | 레이아웃 밀림 정도 | 0.1 이하 | 0.1~0.25 | 0.25 초과 |
| INP | 클릭 반응 속도 | 200ms 이하 | 200~500ms | 500ms 초과 |
| LCP 주요 원인 | - | 무거운 대표 이미지, 느린 서버 응답 | ||
| CLS 주요 원인 | - | 크기 미지정 이미지, 뒤늦은 팝업 삽입 | ||
| INP 주요 원인 | - | 무거운 자바스크립트, 과도한 이벤트 리스너 | ||
가장 정확한 확인 방법은 서치콘솔의 "핵심 웹 지표" 리포트예요. 여기서는 실제 방문자들의 데이터를 기반으로 모바일과 PC를 나눠서 URL 그룹별로 문제를 보여줍니다. 개별 페이지를 즉시 테스트해보고 싶다면 구글 PageSpeed Insights에 URL을 넣어서 실험실 데이터와 필드 데이터를 함께 확인하는 게 좋아요. 실험실 데이터는 도구가 그 자리에서 한 번 측정한 값이고, 필드 데이터는 실제 방문자들이 최근 28일간 경험한 값을 모은 거라서 두 값이 다르게 나올 수 있는데, 실제 손님 경험을 보려면 필드 데이터를 더 신뢰하시는 게 맞아요.
우선순위는 방문자와 매출이 많은 페이지부터 잡으시는 걸 추천드려요. 모든 페이지를 한 번에 다 고치려고 하면 지치기 쉬운데, 메인 페이지와 매출 상위 카테고리, 인기 상품 페이지 몇 개만 먼저 손봐도 전체 리포트 점수가 눈에 띄게 좋아지는 경우가 많습니다. 신상품이 계속 추가되는 쇼핑몰 특성상 완벽하게 다 고치기보다는 주기적으로 점검하는 루틴을 만드는 게 현실적이에요. 저는 매달 신상품 상세페이지 템플릿을 하나 골라서 PageSpeed Insights로 점검하는데, 템플릿 하나만 잘 관리해도 그 템플릿을 쓰는 수십, 수백 개 상품이 한꺼번에 좋아지는 효과가 있어서 시간 대비 효율이 좋습니다.
서치콘솔 리포트에서 URL이 "양호", "개선 필요", "불량" 세 그룹으로 나뉘어 표시되는데, 각 그룹을 클릭하면 어떤 URL들이 여기에 해당하는지 목록으로 보여줍니다. 이때 URL 하나하나를 개별로 고치기보다는, 같은 템플릿을 쓰는 URL들이 묶여서 같은 문제를 가지고 있는 경우가 대부분이니 템플릿 단위로 원인을 찾아서 고치는 게 훨씬 효율적이에요.
구글은 코어 웹 바이탈을 포함한 "페이지 경험"을 순위를 매기는 여러 요소 중 하나로 쓴다고 공식적으로 밝히고 있어요. 다만 콘텐츠의 관련성이나 품질만큼 절대적인 비중을 차지하는 건 아니라서, 코어 웹 바이탈만 완벽하게 만든다고 순위가 급상승하지는 않습니다. 그래도 같은 조건이라면 페이지 경험이 좋은 쪽이 유리하게 작용할 수 있고, 무엇보다 실제 손님의 이탈률과 전환율에 훨씬 직접적인 영향을 준다는 점이 더 중요해요.
저는 코어 웹 바이탈을 순위를 위한 숙제라기보다 "손님이 우리 몰에서 얼마나 쾌적하게 쇼핑하는가"를 재는 온도계처럼 생각하시길 권해드려요. 순위는 덤으로 따라오는 거고, 진짜 목적은 클릭한 손님이 짜증나서 나가버리지 않게 만드는 거니까요. 실제로 코어 웹 바이탈이 나쁜 페이지는 이탈률도 함께 높게 나오는 경우가 대부분이라, 순위 상승 여부와 별개로 개선할 이유는 충분합니다.
세일 기간처럼 트래픽이 몰리는 시점에는 코어 웹 바이탈이 평소보다 나빠지기 쉬운데, 이건 서버 응답이 느려지거나 동시 접속자가 늘면서 자연스럽게 나타나는 현상이에요. 대형 세일을 앞두고 있다면 며칠 전에 미리 PageSpeed Insights로 주요 페이지를 점검해서 여유가 있는지 확인해보시는 것도 좋은 습관입니다.
코어 웹 바이탈의 근본 원인은 결국 이미지·폰트·스크립트 속도 개선 글에서 다룬 내용과 많이 겹칩니다. 두 글을 같이 참고하시면 손볼 순서를 잡는 데 도움이 될 거예요.