"사이트가 좀 느린 것 같은데, 뭘 먼저 고쳐야 하나요?" 속도 이야기가 나오면 가장 자주 듣는 질문입니다. 흔히 페이지스피드 점수 하나에 매달려 이것저것 손대다 지치는데, 정작 사용자가 느끼는 문제는 그대로인 경우가 많습니다. 구글이 사용자 경험을 재는 Core Web Vitals는 세 가지 지표로 나뉘고, 각각 재는 것도 고치는 방법도 다릅니다. 그래서 순서가 중요합니다. 이 글은 세 지표가 각각 무엇을 재는지, 흔한 원인과 대응은 무엇인지, 그리고 감이 아니라 실측 데이터로 무엇부터 고칠지 정하는 법과 현실적인 기대치를 정리합니다.
Core Web Vitals가 뭐고 왜 보나
Core Web Vitals는 구글이 실제 사용자 경험을 수치로 나타낸 세 가지 지표입니다. 페이지가 얼마나 빨리 뜨는지, 조작에 얼마나 빨리 반응하는지, 화면이 얼마나 안 흔들리는지를 봅니다. 검색 순위에 결정적으로 큰 요소는 아니지만, 비슷한 조건에서 갈릴 때 영향을 줄 수 있고 무엇보다 이탈과 전환에 직접 관련됩니다.
즉 이건 SEO 점수판이라기보다 사용자 체감의 문제입니다. 느리고 버벅이고 화면이 밀리는 사이트는 검색 이전에 방문자가 떠납니다. 그래서 "점수를 100점 만들기"가 아니라 "사용자가 답답함을 느끼는 지점을 없애기"로 목표를 잡는 게 맞습니다.
세 지표가 각각 재는 것
세 지표는 서로 다른 것을 잽니다. 헷갈리면 엉뚱한 곳을 고치게 됩니다.
- LCP(로딩) — 화면에서 가장 큰 콘텐츠(대개 큰 이미지나 제목 영역)가 뜨는 데 걸리는 시간. 대략 2.5초 이내가 양호로 통합니다.
- INP(반응성) — 사용자가 클릭·입력했을 때 화면이 반응하기까지의 지연. 2024년부터 기존 FID를 대체했고, 대략 200밀리초 이내가 양호입니다.
- CLS(시각 안정성) — 로딩 중 요소가 갑자기 밀려 화면이 흔들리는 정도. 버튼을 누르려는 순간 밀려 오작동하게 만드는 그 현상입니다.
이름이 낯설어도 뜻은 단순합니다. 빨리 뜨는가(LCP), 눌렀을 때 바로 반응하는가(INP), 보는 중에 안 흔들리는가(CLS). 이 셋을 구분해야 다음 단계인 "무엇부터"가 가능해집니다.
뭐부터? — 실측 데이터로 우선순위
가장 중요한 원칙입니다. 감으로 고치지 않습니다. 어떤 지표가 실제로 나쁜지부터 데이터로 확인합니다. 구글 서치콘솔의 Core Web Vitals 리포트는 실제 사용자 기준으로 어떤 URL 그룹이 어느 지표에서 "나쁨"인지 보여줍니다. 개별 페이지는 페이지스피드 인사이트에서 실사용 데이터와 진단을 함께 볼 수 있습니다.
여기서 "나쁨"으로 잡힌 지표, 그중에서도 가장 많은 페이지가 걸린 지표부터 손댑니다. 세 지표를 동시에 완벽히 만들려다 아무것도 못 끝내는 것보다, 실제로 문제인 하나를 "나쁨"에서 "양호"로 끌어올리는 게 체감 효과가 큽니다. 이미 양호한 지표를 붙잡고 소수점 점수를 올리는 건 대개 시간 낭비입니다.
LCP 흔한 원인과 대응
LCP가 느린 원인은 대체로 몇 가지로 좁혀집니다. 가장 흔한 건 큰 이미지입니다. 화면 상단의 대표 이미지가 무겁거나 크기가 과하면 로딩이 늦어집니다. 이미지를 적정 크기로 줄이고 webp 같은 효율적 포맷을 쓰며, 상단 대표 이미지는 우선 로딩되게 지정하는 게 기본입니다.
그 밖에 서버 응답이 느리거나, 화면을 그리기 전에 처리해야 하는 스크립트·스타일이 많거나, 웹폰트 로딩이 늦는 것도 원인이 됩니다. 워드프레스 환경에서 LCP를 단계적으로 줄인 사례는 워드프레스 LCP 4초→1.5초 작업 순서에서 구체적으로 다뤘습니다.
INP 흔한 원인과 대응
INP는 반응성이라 원인이 주로 자바스크립트에 있습니다. 클릭했는데 화면이 잠깐 멈춘 듯한 느낌은, 그 순간 브라우저가 무거운 스크립트를 처리하느라 반응할 겨를이 없기 때문입니다. 특히 광고·채팅 위젯·분석 도구 같은 서드파티 스크립트를 잔뜩 붙이면 이 문제가 커집니다.
대응은 안 쓰는 스크립트를 걷어내는 것에서 시작합니다. 정말 필요한 것만 남기고, 당장 필요 없는 스크립트는 나중에 불러오도록 미루면 초기 반응성이 좋아집니다. 기능을 늘릴수록 반응성은 나빠지기 쉬우므로, 위젯 하나를 더할 때마다 값을 하는지 따져보는 습관이 도움이 됩니다.
CLS 흔한 원인과 대응
CLS는 화면 밀림입니다. 가장 흔한 원인은 크기를 지정하지 않은 이미지·광고·임베드입니다. 자리를 미리 잡아두지 않으면, 그 요소가 뒤늦게 로딩되면서 아래 내용을 밀어냅니다. 글을 읽거나 버튼을 누르려던 사용자에겐 꽤 거슬리는 경험입니다.
대응은 공간을 미리 예약해 두는 것입니다. 이미지에는 가로·세로 크기를 지정해 브라우저가 자리를 먼저 확보하게 하고, 광고나 배너가 들어갈 영역도 높이를 정해둡니다. 나중에 삽입되는 요소가 기존 내용을 밀지 않도록 설계하면 화면이 안정됩니다. 웹폰트가 늦게 적용되며 글자가 튀는 것도 CLS를 키우니 함께 살핍니다.
측정과 현실적 기대
고친 뒤 기대치를 맞추는 게 마지막입니다. 서치콘솔이나 페이지스피드의 실사용 데이터는 최근 사용자 방문이 일정 기간 누적돼 반영되므로, 오늘 고쳤다고 내일 숫자가 바뀌지 않습니다. 반영에는 보통 몇 주가 걸립니다. 그사이 개선이 됐는지 확인하려면 랩 데이터(Lighthouse 같은 진단 도구)를 함께 봅니다.
목표도 현실적으로 잡습니다. 모든 지표를 만점으로 만드는 게 아니라, "나쁨"에 걸린 것을 "양호" 범위로 끌어올리는 데까지가 우선입니다. 완벽한 점수보다 사용자가 답답함을 느끼지 않는 수준이면 충분한 경우가 많습니다. 결국 속도 개선은 점수를 위한 게 아니라, 방문자가 떠나지 않고 원하는 행동을 하게 만들기 위한 일이라는 걸 기억하면 우선순위가 흔들리지 않습니다.