고객이 검색결과에서 매장 홈페이지를 눌렀는데 대표 이미지와 예약 버튼이 늦게 나타나면 좋은 콘텐츠도 읽히기 어렵다. 특히 이동 중 모바일 고객은 느린 화면을 기다리기보다 지도나 다른 매장으로 돌아갈 수 있다. 속도 개선은 개발자만의 일이 아니다. 점주는 어떤 페이지에서 고객 행동이 시작되는지 정하고, 무거운 이미지와 불필요한 외부 기능을 골라내며, 수정 전후의 실제 체감과 지표를 비교할 수 있다.
핵심 요약: 점수보다 고객이 기다리는 구간을 먼저 줄인다
① 모바일 핵심 페이지 세 개를 고른다 ② PageSpeed Insights의 현장·실험실 데이터를 구분한다 ③ LCP·INP·CLS 중 가장 나쁜 지표부터 본다 ④ 첫 화면 대표 이미지를 가볍게 만든다 ⑤ 예약·문의 버튼의 반응을 막는 스크립트를 줄인다 ⑥ 이미지와 광고 영역의 크기를 미리 확보한다 ⑦ 수정일과 실제 문의 변화를 함께 기록한다. 100점 자체보다 고객이 상품을 보고 행동할 때 생기는 지연을 줄이는 것이 목적이다.
1. 홈이 아니라 고객 행동 페이지 세 개부터 측정한다
홈페이지 한 곳만 검사하면 실제 병목을 놓칠 수 있다. 검색에서 많이 들어오는 글, 대표 상품·메뉴 페이지, 예약이나 문의 페이지의 주소를 각각 적고 PageSpeed Insights에서 모바일 기준으로 확인한다. 같은 날 같은 조건으로 URL, 측정 시각, 성능 점수, LCP·INP·CLS, 주요 개선 제안을 표에 남긴다. 신설 페이지처럼 방문 데이터가 적으면 실제 사용자 데이터가 표시되지 않을 수 있으므로 ‘데이터 없음’을 오류로 단정하지 말고 실험실 진단과 직접 체감을 함께 본다.
2. LCP·INP·CLS가 뜻하는 고객 불편을 구분한다
Google은 우수한 사용자 경험의 권장 기준으로 LCP 2.5초 이내, INP 200밀리초 미만, CLS 0.1 미만을 안내한다. LCP는 대표 이미지나 큰 제목처럼 주요 콘텐츠가 보이는 속도, INP는 버튼을 누른 뒤 화면이 반응하는 속도, CLS는 로딩 중 요소가 갑자기 밀리는 정도다. 세 지표를 하나의 ‘사이트가 느리다’로 묶지 말자. 이미지가 늦으면 LCP, 예약 버튼이 굼뜨면 INP, 배너가 나타나 메뉴가 밀리면 CLS 해결책을 먼저 찾는다.
3. 첫 화면 대표 이미지는 크기·형식·우선순위를 정리한다
첫 화면의 큰 사진은 LCP 대상이 되기 쉽다. 휴대전화에서 400픽셀 폭으로 보이는데 원본 4,000픽셀 사진을 그대로 보내지 말고, 화면 크기에 맞는 여러 버전과 WebP 같은 효율적인 형식을 검토한다. 품질을 알아보기 어려울 정도로 낮추기보다 실제 표시 크기에서 비교하며 압축한다. 첫 화면 대표 이미지는 지연 로딩을 무조건 적용하지 말고 브라우저가 일찍 찾도록 한다. 반대로 화면 아래 후기·갤러리 이미지는 지연 로딩으로 초기 전송량을 줄일 수 있다.
4. 예약·문의 반응을 늦추는 외부 기능을 한 번씩 뺀다
채팅 상담, 지도, 방문자 분석, 광고 태그, 리뷰 위젯을 모두 첫 화면에서 실행하면 휴대전화가 여러 작업을 동시에 처리해야 한다. 기능 목록에 제공업체, 사용 목적, 담당자, 마지막 확인일을 적고 실제로 쓰지 않는 코드는 제거한다. 반드시 필요한 기능도 예약 버튼보다 먼저 실행해야 하는지 검토한다. 한꺼번에 모두 지우지 말고 위젯 하나를 비활성화한 뒤 버튼 터치, 메뉴 열기, 양식 입력을 다시 시험하면 어떤 기능이 INP에 영향을 주는지 찾기 쉽다.
5. 이미지·배너·광고가 들어올 자리를 미리 확보한다
페이지를 읽는 중 사진이 늦게 나타나 문단과 버튼이 아래로 밀리면 잘못 누르기 쉽다. 이미지에는 실제 비율에 맞는 너비와 높이를 지정하고, 예약 달력·지도·광고처럼 나중에 로드되는 영역에도 최소 높이나 비율을 먼저 둔다. 공지 배너를 페이지 상단에 뒤늦게 삽입하기보다 처음부터 공간을 마련하거나 기존 콘텐츠 위를 덮지 않는 위치를 선택한다. 모바일에서 페이지를 새로고침하며 제목, 목차, 버튼이 움직이는지 화면 녹화로 확인하면 CLS 문제를 찾는 데 도움이 된다.
6. 서버 응답·글꼴·리디렉션은 첫 요청부터 줄인다
이미지만 줄였는데도 주요 콘텐츠가 늦다면 첫 HTML 응답, 리디렉션, 웹글꼴을 살핀다. http에서 https, www에서 기본 주소, 다시 특정 경로로 여러 번 이동하면 첫 화면 표시가 늦어진다. 대표 주소를 하나로 정하고 내부 링크가 그 주소를 바로 가리키게 한다. 사용하지 않는 글꼴 굵기와 문자 세트를 줄이고, 사이트 운영 서비스에서 압축·브라우저 캐시·CDN 제공 여부를 확인한다. 서버 변경은 장애 가능성이 있으므로 백업과 되돌리기 방법을 마련한 뒤 한 항목씩 적용한다.
7. 수정 전후를 같은 URL과 고객 행동으로 비교한다
수정 직후 실험실 점수는 확인할 수 있지만 실제 사용자 데이터는 최근 기간을 집계하므로 바로 바뀌지 않을 수 있다. 변경 전후를 다른 페이지나 다른 기기로 비교하지 말고 같은 URL, 같은 모바일 조건, 비슷한 시간대에서 세 번 측정해 중앙값을 기록한다. 동시에 예약 완료, 문의 전송, 전화 버튼 클릭과 실제 접수 건수를 주간 표에 적는다. 속도가 좋아져도 문의가 늘지 않으면 문구와 동선을 별도로 점검해야 하며, 좋은 Core Web Vitals가 검색 상위 노출을 보장하는 것은 아니다.
오늘 바로 실행하는 60분 모바일 속도 점검표
첫 10분은 검색 유입 글·상품 페이지·예약 페이지 주소를 정한다. 다음 10분은 PageSpeed Insights 모바일 결과와 직접 체감을 기록한다. 이어 15분은 첫 화면 이미지의 실제 표시 크기, 파일 용량, 지연 로딩 여부를 확인한다. 다음 10분은 채팅·지도·광고·분석 위젯의 필요성을 표시하고, 10분은 이미지와 배너 영역에 크기가 지정됐는지 본다. 마지막 5분은 우선 수정할 한 항목, 담당자, 점검일을 정한다. 여러 문제를 동시에 바꾸지 않아야 효과와 오류 원인을 구분할 수 있다.