PageSpeed Insights에 사이트 주소를 넣었더니 모바일 성능 점수가 빨갛게 나옵니다. 진단 목록에는 이미지, 자바스크립트, 캐시 등 익숙하지 않은 항목이 길게 이어집니다. 전부 고쳐야 할 것 같지만 개발팀에 ‘점수를 올려주세요’라고만 전달하면 어디까지 작업할지 정하기 어렵습니다.
먼저 구분할 것은 낮은 점수와 실제 사용자가 겪는 문제입니다. 저는 점수 옆에 어느 페이지, 어느 기기, 어떤 행동에서 문제가 생기는지를 적습니다. 첫 화면의 상품이 늦게 보이는 문제와 구매 버튼을 눌러도 반응이 없는 문제는 다른 작업을 요구하기 때문입니다.
1. 실제 사용자 데이터와 실험실 결과를 나눠 읽습니다
PageSpeed Insights에는 서로 다른 성격의 자료가 함께 있습니다. 실제 사용자 데이터는 Chrome 사용자 경험 보고서인 CrUX에서 가져온 관측값입니다. 실험실 결과는 Lighthouse가 특정 조건에서 페이지를 실행한 진단입니다. 한 번 측정한 실험실 점수가 곧 모든 방문자의 체감 속도라는 뜻은 아닙니다. 두 데이터의 범위는 PageSpeed Insights 공식 설명에서 확인할 수 있습니다.
실제 사용자 영역을 볼 때는 ‘이 URL’의 데이터인지 ‘출처’ 수준인지 먼저 확인하세요. URL 표본이 부족하면 같은 출처의 여러 페이지를 포함하는 자료가 표시될 수 있습니다. 이를 특정 상품 페이지의 결과라고 보고하면 범위가 어긋납니다. 둘 다 표본이 부족해 실제 사용자 데이터가 나오지 않을 수도 있는데, 데이터가 없다는 것이 빠르다는 판정은 아닙니다.
CrUX는 최근 28일의 관측을 반영하므로 오늘 배포한 수정이 즉시 전체 기간을 대표하지 않습니다. 실험실 결과는 오늘 변경한 코드의 영향을 빠르게 살펴보는 데 쓸 수 있고, 실제 사용자 데이터는 변화가 사용자 경험에도 나타나는지 이어서 확인하는 데 쓸 수 있습니다. 두 수치를 한 날짜의 같은 측정값처럼 비교하지 않습니다.
2. LCP·INP·CLS를 사용자의 불편으로 번역합니다
약어를 외우기보다 어떤 불편을 가리키는지 연결하면 다음 작업을 정하기 쉽습니다. 다음은 web.dev의 Core Web Vitals 안내에 따른 세 지표와 좋은 경험의 기준입니다. 실제 사용자 분포의 75번째 백분위수를 보며, 모바일과 데스크톱을 나눠 확인합니다. 평균 방문자 한 명의 결과가 아닙니다.
| 지표 | 무엇을 보는가 | 좋음 기준 | 확인할 장면 |
|---|---|---|---|
| LCP | 화면의 가장 큰 이미지나 텍스트 블록이 표시되는 시점 | 2.5초 이하 | 주요 상품 이미지나 본문이 늦게 보임 |
| INP | 클릭·탭·키 입력 이후 다음 화면 변화까지의 반응성 | 200밀리초 이하 | 옵션을 눌러도 선택 표시가 늦음 |
| CLS | 예상치 못한 화면 요소의 위치 이동 | 0.1 이하 | 누르려던 버튼이 다른 위치로 밀림 |
INP는 주문 완료까지 걸리는 서버 처리 시간 전체와 같은 뜻이 아닙니다. 버튼을 누른 뒤 처리 중이라는 반응은 즉시 보이지만 결제 완료는 늦을 수도 있습니다. 반대로 작업 자체는 간단해도 브라우저가 다른 일을 하느라 첫 반응이 늦을 수 있습니다. 어느 순간이 느린지 구분해서 전달해야 합니다.
실험실에서 보이는 TBT 역시 INP와 동일한 지표가 아닙니다. Core Web Vitals 도구 활용 안내처럼 로딩 중 긴 작업을 찾는 단서로 활용할 수 있지만, 이용자가 나중에 필터를 열고 입력하는 상황까지 대신 측정하지는 않습니다. 지표마다 무엇을 관측했는지 구분하는 것이 개선의 출발점입니다.
3. LCP가 느리면 큰 이미지의 용량만 보지 않습니다
첫 화면의 큰 이미지가 늦게 뜬다고 모든 이미지를 더 압축해야 하는 것은 아닙니다. 브라우저가 그 이미지의 존재를 늦게 알았는지, 다운로드가 오래 걸리는지, 받아놓고도 표시하지 못하는지에 따라 원인이 다릅니다. 처음 HTML을 받는 단계가 느리면 이미지 교체만으로 해결되지 않을 수도 있습니다.
운영 담당자는 먼저 어떤 요소가 LCP로 잡혔는지 개발팀과 확인할 수 있습니다. 대표 이미지라면 실제 표시 크기보다 지나치게 큰 파일을 쓰는지, 여러 배너를 한꺼번에 불러오는지, 첫 화면 이미지를 지연 로딩하도록 설정했는지 살펴봅니다. 화면 아래 이미지와 첫 화면의 핵심 이미지는 불러오는 우선순위가 같을 필요가 없습니다.
Google Chrome 팀의 LCP 최적화 가이드는 리소스 발견·다운로드·표시까지의 지연을 나눠보도록 설명합니다. 그래서 요청도 ‘이미지 최적화’보다 ‘모바일 첫 화면의 대표 이미지가 언제 요청되고 언제 표시되는지 확인’이라고 적는 편이 구체적입니다. 파일 형식 변경이나 압축 이후에는 화질과 상품 식별에 문제가 없는지도 직접 확인하세요.
4. 버튼이 늦게 반응하면 그 순간의 작업을 봅니다
메뉴, 상품 옵션, 검색 필터, 장바구니 버튼처럼 실제로 자주 쓰는 기능을 휴대전화에서 눌러보세요. 처음 열 때만 느린지, 항목이 많아졌을 때 느린지, 특정 기능에서만 발생하는지 기록합니다. ‘모바일이 느리다’는 문장보다 ‘옵션 목록을 연 뒤 색상을 바꾸면 선택 표시가 늦다’는 설명이 원인을 찾는 데 도움이 됩니다.
외부 채팅, 광고, 분석 도구의 스크립트도 확인 대상입니다. 다만 필요 없어 보인다는 이유로 운영 사이트에서 바로 지우면 측정이나 고객 응대가 함께 중단될 수 있습니다. 어떤 기능을 위해 쓰는지 담당자를 확인하고, 테스트 환경에서 실행 시점과 부담을 비교하는 편이 좋습니다.
INP 개선 안내는 느린 상호작용을 찾아 입력 지연, 처리, 화면 표시 지연을 분석하도록 설명합니다. 운영자가 그 내부 원인을 모두 판정할 필요는 없습니다. 재현 경로와 느린 순간의 화면을 전달하고, 개발팀이 원인을 확인한 뒤 필터·구매·측정 기능이 유지되는지 함께 검수하면 됩니다.
5. 화면이 흔들리면 늦게 끼어드는 요소를 찾습니다
글을 읽다가 광고가 들어오며 본문이 밀리거나, 상품 버튼을 누르려는 순간 배너가 늘어나면 사용자는 다시 위치를 찾아야 합니다. 이런 문제는 다운로드 속도가 빨라도 남아 있을 수 있습니다. 이미지나 광고가 들어갈 자리를 미리 확보했는지, 글꼴이 바뀌면서 줄 수가 크게 달라지는지 살펴보세요.
가령 상품 사진이 나타난 뒤 가격과 버튼이 아래로 밀린다면, 사진이 로드되기 전에도 필요한 가로세로 비율의 공간이 유지되는지 확인할 수 있습니다. 쿠키 안내, 프로모션 배너, 영상 삽입도 같은 관점에서 봅니다. 단순히 사진을 없애는 대신 사진이 들어와도 주변 요소가 예기치 않게 움직이지 않도록 만드는 작업입니다.
CLS 최적화 가이드는 크기가 지정되지 않은 이미지·광고·삽입 콘텐츠와 글꼴 등을 주요 원인으로 설명합니다. 기본 로딩 진단에서 문제가 없더라도 페이지를 읽고 스크롤하는 동안 발생하는 이동이 있을 수 있습니다. 첫 화면만 보지 말고 실제 과업을 끝까지 수행해보세요.
6. 점수보다 영향 범위로 수정 순서를 정합니다
홈페이지 첫 화면만 측정하면 검색으로 들어오는 글이나 광고 랜딩, 상품 상세페이지의 문제를 놓칠 수 있습니다. 우선 유입이 많은 페이지와 문의·구매에 중요한 페이지를 고르고, 같은 구조를 쓰는 페이지 중 대표 URL도 함께 봅니다. 공통 템플릿의 문제가 여러 페이지에 퍼져 있다면 한 번의 수정이 넓게 적용될 수 있습니다.
다음은 측정 결과가 아닌 작업 우선순위의 예시입니다. 방문이 적은 소개 페이지의 장식 효과와, 주요 상품 페이지에서 옵션 선택을 막는 지연이 동시에 발견됐다면 후자를 먼저 검토할 수 있습니다. 영향받는 방문 범위, 불편의 정도, 수정 비용, 기능 손상 가능성을 함께 적으면 개발 일정에 반영할 근거가 생깁니다.
Lighthouse 점수 설명에 따르면 종합 성능 점수는 측정 지표를 가중해 계산하며 실행 조건에 따라 달라질 수 있습니다. 진단 항목 수를 줄인다고 점수가 같은 폭으로 오르는 것도 아닙니다. 최고 점수가 나온 한 번만 골라 보고하지 말고, 같은 조건의 여러 실행에서 비슷한 개선이 나타나는지 확인하세요.
7. 개발팀에는 점수 대신 재현 가능한 요청을 전달합니다
요청서에는 URL, 모바일·데스크톱 구분, 측정 날짜와 결과 링크, 실제 사용자 데이터의 범위, 문제가 있는 지표, 재현 행동을 적습니다. 예를 들어 ‘모바일 상품 상세페이지에서 옵션 목록을 열고 색상을 변경할 때 반응이 늦다. 해당 행동의 처리와 외부 스크립트 영향을 확인하고, 수정 후 같은 조건에서 다시 비교한다’처럼 씁니다. 원인이 확인되기 전에는 특정 스크립트가 범인이라고 적지 않습니다.
수정 직후에는 실험실 재측정과 기능 검수를 하고, 이후 실제 사용자 지표의 변화도 관찰합니다. 구매 버튼이 잘 눌리는지, 분석 이벤트가 수집되는지, 이미지와 영상이 정상인지 함께 확인해야 합니다. 점수를 얻기 위해 중요한 기능이 사라졌다면 완료된 개선이라고 보기 어렵습니다.
Google은 Core Web Vitals와 검색에 관한 안내에서 좋은 사용자 경험을 권장합니다. 별도의 페이지 경험 안내에서는 좋은 지표만으로 검색 상단을 보장하지 않는다고 설명합니다. PageSpeed 100점을 순위나 매출 보장으로 받아들여서는 안 됩니다. 수정의 목표를 ‘100점’ 하나로 적기보다 ‘중요한 내용을 기다리지 않고 볼 수 있는가, 필요한 버튼이 반응하는가, 읽거나 누를 때 화면이 안정적인가’로 나눠 적어보세요. 그 질문에 대한 측정과 검수가 쌓이면 다음에 무엇을 고칠지도 훨씬 명확해집니다.
