웹사이트 속도, 점수보다 먼저 봐야 할 세 가지.

속도가 느리다는 말에는 서로 다른 문제가 섞여 있습니다. 첫 화면이 늦게 나타나는 것과 버튼을 눌러도 반응하지 않는 것은 같은 문제가 아닙니다. 성능을 개선하려면 하나의 점수만 보기보다 사용자가 어느 순간에 불편을 겪는지 구분하는 것이 출발점입니다.

1. LCP·INP·CLS는 서로 다른 경험을 측정합니다

Core Web Vitals의 현재 지표는 LCP, INP, CLS입니다. LCP는 주요 콘텐츠가 나타나는 로딩 경험, INP는 상호작용에 대한 반응성, CLS는 예기치 않은 화면 이동과 관련된 시각적 안정성을 다룹니다. 정의는 web.dev의 Web Vitals 안내에 정리되어 있습니다.

좋음 기준: LCP는 2.5초 이하, INP는 200밀리초 이하, CLS는 0.1 이하입니다. CLS는 시간이 아니라 점수입니다. 평가는 모바일과 데스크톱을 구분한 실제 방문 데이터의 75번째 백분위 값을 기준으로 봅니다. 평균값이나 가장 빠른 한 번의 기록과는 다릅니다. 공식 임곗값 설명을 참고하세요.

2. 실험실 점수와 실제 방문 경험을 구분하세요

정해진 환경에서 실행하는 측정은 개발 중 원인을 찾는 데 유용하지만 실제 사용자 데이터를 대체하지는 못합니다. 사용자의 기기, 네트워크, 페이지에서 하는 행동이 다르기 때문입니다. 일반적인 Lighthouse 페이지 로딩 측정은 사용자 상호작용이 없어 INP를 직접 측정하지 못하며 TBT를 참고 지표로 사용합니다. Web Vitals의 실험실·현장 측정 설명에 나오는 구분입니다.

예를 들어 개발자의 노트북에서는 첫 화면이 빠르게 떠도, 사용자가 오래 머무르며 검색 필터를 조작할 때는 반응이 느릴 수 있습니다. 따라서 ‘메인 화면을 열었을 때’뿐 아니라 ‘상품을 찾을 때’, ‘문의 양식을 작성할 때’처럼 이용 흐름을 나눠 문제를 기록하는 방법을 권합니다.

3. 증상에 맞는 개선부터 시작하세요

첫 화면이 늦다면: LCP에 해당하는 이미지가 늦게 발견되거나 지연 로딩되고 있는지 살펴볼 수 있습니다. 버튼 반응이 느리다면: 불필요한 JavaScript와 긴 작업을 줄이거나 나누는 방향을 검토합니다. 화면이 밀린다면: 이미지와 임베드가 차지할 공간을 크기나 비율로 미리 확보하는 방법이 있습니다. 세 방향 모두 web.dev의 Core Web Vitals 개선 권장사항에 근거합니다.

모든 이미지에 같은 지연 로딩 정책을 적용하거나, 이유를 확인하지 않고 플러그인을 일괄 삭제하는 방식은 피하는 편이 좋습니다. 실제 병목이 무엇인지에 따라 필요한 수정이 달라지기 때문입니다. 기능을 없애지 않고도 자원이 실행되는 시점과 범위를 조정할 수 있는지 먼저 논의해 보세요.

4. 점수와 비즈니스 목표는 따로 기록하세요

Google은 Core Web Vitals를 실제 사용자 경험을 측정하는 지표로 설명하고 좋은 경험을 권장합니다. 하지만 이 설명을 특정 점수만으로 검색 순위나 매출이 보장된다는 뜻으로 확대해서는 안 됩니다. 근거 범위는 Google의 Core Web Vitals 안내를 참고하세요.

실무 기록에는 문제 화면, 사용자의 행동, 관련 지표, 수정 내용, 문의 완료 같은 운영 목표를 별도 항목으로 남기는 방식을 제안합니다. 측정값이 좋아졌다는 사실과 실제 성과가 달라졌다는 사실을 분리하면 다음 개선의 우선순위도 더 명확해집니다.

자료 확인일: 2026년 9월 7일. 공식 문서를 바탕으로 AI의 도움을 받아 작성한 정보성 콘텐츠입니다. 적용 예시는 이해를 돕기 위한 가상 예시이며, 특정 프로젝트의 성과나 검증 결과를 의미하지 않습니다. 서비스의 정책과 문서는 변경될 수 있습니다.