점수보다 실제 사용자 데이터를 먼저 확인합니다
웹사이트 속도 점검은 체감이나 한 번의 테스트 점수만으로 결론 내리기 어렵습니다. PageSpeed Insights는 실제 방문 환경을 반영한 필드 데이터와 통제된 조건에서 재현하는 실험실 데이터를 함께 보여줍니다. 필드 데이터는 고객이 실제로 겪는 문제를 찾는 데, 실험실 데이터는 원인을 재현하고 수정 전후를 비교하는 데 적합합니다. 먼저 모바일과 데스크톱을 나눠 보고, 홈페이지뿐 아니라 상품·서비스·예약·문의처럼 매출 행동과 가까운 URL도 각각 검사하세요.
LCP·INP·CLS를 서로 다른 문제로 읽습니다
Core Web Vitals는 세 가지 경험을 구분합니다. LCP는 화면의 주요 콘텐츠가 보이는 속도, INP는 클릭·탭·키보드 입력 뒤 다음 화면 반응까지의 지연, CLS는 읽는 중 요소가 예기치 않게 움직이는 정도입니다. Google이 제시하는 ‘좋음’ 기준은 LCP 2.5초 이하, INP 200밀리초 이하, CLS 0.1 이하이며 페이지 방문의 75번째 백분위수를 기준으로 평가합니다. 세 지표를 하나의 속도 점수로 뭉개지 말고, 어느 경험이 기준을 벗어났는지부터 표시해야 합니다.
URL 한 개보다 페이지 유형을 묶어 봅니다
소상공인 사이트는 같은 템플릿을 여러 페이지가 공유하는 경우가 많습니다. 대표 URL만 고치기 전에 페이지를 ① 홈 ② 상품·메뉴 ③ 상세 콘텐츠 ④ 예약·문의로 묶고 각 유형에서 방문이 많은 URL과 전환에 가까운 URL을 하나씩 고르세요. Search Console의 Core Web Vitals 보고서가 비슷한 URL을 문제 그룹으로 보여준다면 공통 템플릿, 공통 스크립트, 공통 이미지부터 확인합니다. 개별 글보다 여러 핵심 페이지에 동시에 영향을 주는 수정이 우선입니다.
지표별 원인을 좁혀 한 번에 하나씩 수정합니다
LCP가 느리면 첫 화면의 큰 대표 이미지, 서버 응답, 웹폰트와 차단 리소스를 먼저 살펴봅니다. 첫 화면의 핵심 이미지는 적절한 크기와 형식으로 제공하고 불필요한 지연 로딩을 피합니다. INP가 나쁘면 예약 위젯·상담 버튼·분석 태그처럼 클릭 시 긴 작업을 만드는 자바스크립트를 점검하고, 사용하지 않는 코드는 줄이거나 늦게 실행합니다. CLS가 크면 이미지와 영상 공간을 미리 확보하고, 나중에 삽입되는 배너나 팝업이 기존 내용을 밀어내지 않게 합니다. 수정 항목을 한 번에 많이 바꾸면 효과의 원인을 알기 어려우므로 한 묶음씩 배포하고 기록하세요.
사업 영향과 수정 난이도로 우선순위를 정합니다
우선순위는 ‘문제 정도 × 사업 중요도 × 영향 URL 수 ÷ 수정 난이도’로 정하면 실무 판단이 쉬워집니다. 예를 들어 예약 페이지의 LCP가 기준을 벗어나고 같은 템플릿의 여러 서비스 페이지에도 영향을 준다면 우선순위를 높입니다. 반대로 방문이 거의 없는 과거 공지 한 건의 작은 차이는 뒤로 미룹니다. Core Web Vitals가 검색 시스템에 사용되지만, 좋은 점수만으로 상위 노출이 보장되는 것은 아닙니다. 콘텐츠 품질과 검색 의도 충족을 유지하면서 고객 행동을 방해하는 문제부터 고치는 것이 핵심입니다.
배포 전후를 같은 조건으로 검증합니다
실행 체크리스트는 다음과 같습니다. ① 모바일·데스크톱을 분리해 측정했는가 ② 홈·상품·예약 등 핵심 유형을 포함했는가 ③ LCP·INP·CLS의 문제 원인을 따로 기록했는가 ④ 사업 영향이 큰 공통 원인부터 수정했는가 ⑤ 같은 URL과 같은 기기 조건에서 실험실 데이터를 재측정했는가 ⑥ 배포 뒤 Search Console의 실제 사용자 데이터를 다시 확인할 담당일을 정했는가. 필드 데이터는 즉시 바뀌지 않을 수 있으므로, 당일에는 실험실 재측정으로 오류를 확인하고 이후 실제 사용자 데이터의 변화를 추적하세요. 숫자 하나보다 수정 내용·측정 조건·확인 날짜를 함께 남겨야 다음 점검이 빨라집니다.