작성: IILL Editorial · URL·기기·네트워크·배포 버전을 함께 기록해 결과를 비교하세요.

모바일 홈페이지가 느리다는 말만으로는 무엇을 고칠지 정하기 어렵습니다. 먼저 같은 URL을 같은 기기와 네트워크 조건에서 열고, **가장 큰 콘텐츠가 보이는 시점(LCP), 입력에 반응하는 시간(INP), 화면이 움직이는 정도(CLS)**를 따로 기록하세요. 세 지표는 진단을 돕는 기준이지 검색 순위나 문의 증가를 보장하는 점수가 아닙니다.

세 지표를 서로 다른 문제로 읽기

지표 묻는 질문 흔한 점검 대상
LCP 첫 화면의 핵심 콘텐츠가 언제 보이나요? 히어로 이미지, 서버 응답, 렌더 차단 CSS·폰트
INP 버튼·메뉴·폼을 눌렀을 때 언제 반응하나요? 긴 JavaScript 작업, 무거운 이벤트 핸들러, 제3자 스크립트
CLS 읽는 중 레이아웃이 갑자기 움직이나요? 크기 없는 이미지, 늦게 삽입되는 배너, 폰트 교체

web.dev의 Core Web Vitals 설명은 각 지표가 서로 다른 사용자 경험을 나타낸다고 설명합니다. LCP만 낮추고 폼 클릭이나 오류 상태를 확인하지 않으면 실제 문의 흐름의 문제를 놓칠 수 있습니다.

측정 전에 조건부터 고정하기

다음 값을 기록하지 않은 점수는 이전 배포와 공정하게 비교하기 어렵습니다.

  • 테스트한 최종 URL과 리디렉션 여부
  • 모바일 또는 데스크톱, 브라우저와 viewport
  • 네트워크·캐시 상태와 테스트 시각
  • 배포 commit 또는 주요 asset 버전
  • 로그인, 개인화, 광고와 외부 위젯의 사용 여부

한 번의 Lighthouse 결과를 고객 사례의 평균처럼 쓰지 마세요. 같은 조건에서 여러 번 확인하고, 어떤 변경 뒤에 값이 달라졌는지 함께 남깁니다.

오픈 전 모바일 점검 순서

1. 첫 화면의 가장 큰 요소를 확인하기

대표 이미지가 너무 크거나, 실제로 보이지 않는 carousel을 먼저 불러오고 있지 않은지 확인합니다. 이미지에는 표시 크기와 적절한 포맷을 지정하고, 첫 화면 아래의 미디어는 필요할 때만 늦게 불러옵니다. LCP 최적화 가이드의 원인별 점검 순서를 그대로 참고하되, 사이트의 실제 HTML과 응답을 기준으로 판단합니다.

2. 입력 반응을 실제로 눌러 보기

메뉴 열기, FAQ 펼치기, 문의 폼의 필드 이동과 오류 표시를 손가락으로 실행합니다. 클릭이 기록되는 것과 화면이 반응하는 것은 다릅니다. INP가 나쁘다면 큰 JavaScript 번들을 나누고, 한 번에 실행되는 분석·채팅·애니메이션을 줄이는 순서로 원인을 좁힙니다.

3. 화면이 움직이는 순간 찾기

이미지·동영상·광고 영역에 크기가 예약되어 있는지, 웹폰트가 바뀔 때 제목과 버튼이 밀리지 않는지 확인합니다. CLS를 낮추려고 콘텐츠를 숨기거나 중요한 정보를 늦게 보이게 만들면 사용성이 나빠질 수 있으니, 공간을 미리 확보하고 콘텐츠 순서를 안정시키는 편이 낫습니다.

4. 속도와 전환을 함께 확인하기

페이지가 빨라도 제출 버튼이 작동하지 않으면 홈페이지의 목적을 달성하지 못합니다. 모바일에서 CTA, 폼 시작, 유효하지 않은 제출, 성공 응답과 실패 메시지를 한 번씩 실행하고, GA4에는 성공 이벤트만 주요 전환으로 남기는지 확인합니다. 측정 계약은 랜딩페이지 GA4 전환 가이드와 연결하세요.

공개 뒤 1일·1주·28일에 볼 것

첫날에는 대표 URL, 모바일 메뉴, 폼 수신, 404와 canonical을 확인합니다. 첫 주에는 실제 배포 asset과 외부 스크립트가 바뀌었는지, Search Console의 색인·Core Web Vitals 상태에 오류가 생겼는지 봅니다. 28일에는 검색 유입과 GA4의 유효한 문의 완료를 별도로 비교합니다.

어떤 지표가 낮아졌다는 사실만으로 순위나 매출의 원인을 단정하지 마세요. 한 번에 한 가지 변경을 배포하고, 측정 조건과 관찰 기간을 남긴 뒤 다음 수정을 정합니다.

오픈 전 체크리스트

  • 최종 URL, 기기, viewport, 네트워크와 배포 버전을 기록했다.
  • LCP·INP·CLS를 같은 조건에서 비교했다.
  • 히어로 이미지와 폰트가 첫 화면을 막지 않는지 확인했다.
  • 모바일 메뉴·폼·오류·성공 상태를 손가락으로 실행했다.
  • 이미지·배너·폰트가 레이아웃을 밀지 않는다.
  • CTA 클릭과 문의 성공 이벤트가 중복 없이 수집된다.
  • canonical, sitemap, robots와 실제 화면의 제목·설명이 일치한다.
  • 한 번의 점수를 순위·전환 보장처럼 쓰지 않았다.

제작 전 일정과 QA 순서는 홈페이지 제작 기간 가이드에서, 공개 뒤의 반복 점검 범위는 홈페이지 유지보수 비용 가이드에서 이어 확인할 수 있습니다. IILL의 홈페이지 제작 서비스는 속도 점수만이 아니라 콘텐츠, 폼, 검색, 분석과 운영 책임을 함께 범위로 정합니다.

NEXT PROJECT

홈페이지 제작, 어디서부터 정할지 막막하신가요?

현재 상황과 필요한 결과를 들은 뒤, 만들 범위와 다음 단계를 먼저 정리합니다.

함께 읽을 글

  1. workflows 홈페이지 제작사가 폐업했다면 재제작보다 도메인부터 복구하세요
  2. engineering 홈페이지 백업은 실제 복원 테스트를 끝내야 증명됩니다
  3. privacy 홈페이지 문의폼 개인정보 안내에 출시 전 꼭 들어갈 내용