코어 웹 바이탈, 점수부터 올리면 왜 체감이 안 달라질까요?

속도 상담에서 자주 듣는 말이 있습니다.

"코어 웹 바이탈 점수가 낮다고 해서 작업을 맡겼는데, 점수는 올랐다는데 쓰는 느낌은 그대로입니다."

이런 경우 저도 같이 열어 봅니다. 사정이 대개 비슷합니다. 점수 항목에 맞춰 손을 본 것은 맞는데, 정작 방문자가 답답하다고 느끼는 지점은 그대로 남아 있습니다.

점수와 체감이 항상 같이 움직이지는 않습니다. 둘은 재는 방식 자체가 다릅니다.

그래서 저는 순서를 바꾸시라고 말씀드립니다. 점수를 목표로 두지 말고, 실제 방문자의 세 지표를 먼저 확인한 다음 거기서 나온 항목만 고치는 방식입니다.

이 순서를 거르면 비용이 두 번 듭니다. 점수용 작업을 한 달 하고 나서 원인을 처음부터 다시 찾는 경우를 여러 번 봤는데, 그때는 작업비와 그 한 달이 함께 사라집니다.

점수를 올렸는데 왜 체감은 그대로일까요?

점수와 체감이 재는 대상이 다르기 때문입니다.

PageSpeed Insights 위쪽의 0~100 점수는 한 번 측정한 실험실 환경의 결과를 여러 지표로 합산한 값입니다. 측정할 때의 상태에 따라 같은 페이지도 점수가 몇 점씩 흔들립니다.

반면 코어 웹 바이탈은 실제 방문자의 브라우저에서 모인 기록입니다. 느린 회선과 오래된 휴대폰까지 함께 섞여 있는 숫자입니다.

그래서 점수만 올리는 작업은 시험 성적만 올리는 것과 비슷해집니다. 방문자가 첫 화면을 흰 화면으로 몇 초간 보고 있는 문제는 점수가 올라도 그대로 남을 수 있습니다.

여기까지 정리되면 다음은 하나입니다. 지금 점수가 몇 점인지 묻기 전에, 실제 방문자 지표 중 어느 것이 '개선 필요'로 잡혀 있는지부터 확인하는 것입니다.

코어 웹 바이탈 세 지표는 각각 무엇을 재나요?

첫 화면이 언제 뜨는지, 읽는 중 화면이 밀리는지, 눌렀을 때 반응이 빠른지 세 가지입니다.

저는 상담에서 이 세 가지를 따로 적어 놓고 시작합니다. '느리다' 한 덩어리로 묶어서 이야기하면 엉뚱한 곳을 고치게 되기 때문입니다.

LCP는 화면에서 가장 큰 요소가 그려지는 시점입니다. 방문자가 "이제 보인다"고 느끼는 순간에 가깝습니다.

CLS는 읽는 중에 화면이 위아래로 밀리는 정도입니다. 버튼을 누르려는 순간 레이아웃이 움직여 엉뚱한 곳을 누르게 되는 그 현상입니다.

INP는 버튼이나 메뉴를 눌렀을 때 화면이 반응하기까지의 지연입니다. 눌렀는데 아무 일도 일어나지 않아 한 번 더 누르게 되는 경우가 여기에 해당합니다.

기준값에는 한 가지 전제가 있습니다. 평균이 아니라, 느린 쪽 방문자까지 포함해 대부분이 이 값을 넘지 않아야 '좋음'으로 잡힙니다.

그래서 평균으로 보면 괜찮아 보이는 페이지도 느린 환경의 방문자 몫이 섞이면 '개선 필요'로 내려갑니다. 내 사무실 컴퓨터에서 빠르게 뜨는 것과는 별개의 이야기입니다.

실제 방문자의 숫자는 어디서 확인하나요?

구글 서치콘솔의 '코어 웹 바이탈' 보고서가 기본입니다.

여기에는 실제 방문자의 기록이 모바일과 PC로 나뉘어 들어옵니다. 어느 지표가 문제이고 어느 페이지 그룹에서 생기는지까지 볼 수 있습니다.

PageSpeed Insights를 쓰신다면 위쪽 점수가 아니라 '실제 사용자 데이터' 항목을 먼저 보십시오. 데이터가 모일 만큼 방문자가 있는 주소에만 표시됩니다.

방문이 적어 실제 데이터가 나오지 않는 경우도 많습니다. 이때는 진단 항목만 참고하고, 직접 휴대폰으로 열어 확인하는 편이 낫습니다.

이 확인은 직접 하셔도 됩니다. 서치콘솔 계정이 이미 있다면 보고서를 열어 모바일 쪽에서 어느 지표가 걸렸는지 적어 두는 데 10분이면 충분합니다. 이 한 장이 있으면 그 뒤 작업 견적이 훨씬 또렷해집니다.

반대로 계정이 아직 없거나 소유 확인이 안 되어 있다면 그 단계만 맡기시는 편이 빠릅니다. 소유 확인을 잘못 걸어 두면 데이터가 쌓이지 않고, 그만큼 판단이 다음 달로 밀립니다.

첫 화면이 늦게 뜨는 문제는 무엇부터 손보나요?

첫 화면에 들어가는 이미지 한두 장과 웹폰트입니다. 실무에서 LCP 문제는 대부분 여기서 나옵니다.

촬영 원본을 그대로 올리면 한 장에 수 MB가 넘습니다. 모바일 화면에서는 가로 400px 정도로 보이는데 파일은 2,000px 이상인 경우가 흔합니다.

WebP로 바꾸고 실제 표시되는 크기에 맞춰 줄이면 용량이 크게 떨어집니다. 이 작업 하나로 LCP가 눈에 띄게 내려가는 경우가 많습니다.

첫 화면 이미지에 지연 로딩이 걸려 있는 경우도 자주 봅니다. 아래쪽 이미지에는 도움이 되지만 첫 화면 이미지에 걸면 오히려 늦어집니다.

웹폰트는 굵기를 몇 종류나 불러오는지 확인하십시오. 본문용 한 벌과 제목용 한 벌이면 대개 충분합니다. 한글 폰트는 파일이 무거워서 굵기 하나를 줄이는 효과가 큽니다.

첫 화면을 슬라이더로 만든 경우라면 첫 장만 먼저 불러오도록 바꾸는 것부터 확인합니다. 뒤 장을 미리 다 받아 오는 설정이 기본값인 도구도 있습니다.

이미지 용량을 줄이는 일은 직접 하셔도 됩니다. 저는 첫 화면에 쓰는 사진 두세 장만 다시 저장해서 올려 보시라고 권합니다. 반면 지연 로딩 해제나 슬라이더 설정은 템플릿 코드를 건드려야 하니 맡기시는 편이 안전합니다.

이 두 가지를 건너뛰고 서버부터 옮기는 경우를 자주 봅니다. 그러면 호스팅 비용은 매달 더 나가는데 LCP는 거의 그대로입니다. 원인이 이미지와 폰트에 있었다면 옮긴 돈과 이전에 쓴 시간이 둘 다 회수되지 않습니다.

화면이 덜컥 밀리는 현상은 왜 생기나요?

자리를 미리 잡아 두지 않은 요소가 나중에 끼어들기 때문입니다.

가장 흔한 것은 크기를 지정하지 않은 이미지입니다. 이미지가 로드되는 순간 그만큼의 높이가 생기면서 아래 내용이 전부 밀립니다.

이미지에 가로·세로 값을 넣어 두면 브라우저가 미리 자리를 비워 둡니다. 손이 적게 가는데 효과는 분명한 조치입니다.

상단 공지바와 이벤트 배너도 자주 원인이 됩니다. 스크립트로 나중에 붙이는 방식이면 그 순간 페이지 전체가 아래로 내려갑니다.

이 문제는 문의 전환에 바로 영향을 줍니다. 상담 신청 버튼을 누르려는 순간 화면이 밀려 다른 링크로 들어가면, 그 방문자는 대개 돌아오지 않습니다.

저는 이것을 속도 문제보다 전환 문제로 봅니다. 광고를 돌리는 경우라면 클릭 단가를 낸 방문자가 문의 직전에 튕기는 셈이라, 손실이 그대로 광고비로 계산됩니다.

여기까지 보셨다면 다음은 간단합니다. 휴대폰으로 첫 화면부터 문의 버튼까지 천천히 내려 보시고, 화면이 한 번이라도 덜컥 움직인 지점을 적어 두십시오. 그 목록이 CLS 작업 지시서가 됩니다.

버튼을 눌렀는데 반응이 늦다면 무엇을 봐야 하나요?

페이지에 붙어 있는 스크립트 목록부터 봐야 합니다.

INP는 브라우저가 다른 일로 바빠서 눌린 것을 처리할 틈이 없을 때 나빠집니다. 원인은 대개 한두 개의 무거운 스크립트입니다.

채팅 상담 위젯, 지도 삽입, 영상 삽입, 그리고 태그 매니저에 몇 년간 쌓인 추적 코드가 흔한 후보입니다.

실제로 태그 매니저를 열어 보면 지금 쓰지 않는 항목이 열 개 넘게 남아 있는 경우를 자주 봅니다. 예전 광고 캠페인용으로 넣은 코드가 그대로 있는 것인데, 이것만 정리해도 반응이 달라지는 경우가 있습니다.

무엇이 안 쓰는 태그인지는 대표님 쪽이 더 정확합니다. 어느 광고를 언제 멈췄는지는 저희가 알 수 없기 때문입니다. 목록만 주시면 지우는 작업은 금방 끝납니다.

채팅 위젯을 빼기 어렵다면 첫 화면이 뜬 다음에 불러오도록 순서를 미루는 방법이 있습니다. 방문자가 위젯을 찾는 시점은 보통 내용을 읽은 다음입니다.

▲ ▲ 지표 세 개는 결국 방문자가 겪는 이 세 순간에 대응합니다

고치는 순서는 어떻게 잡나요?

방문이 많은 페이지부터, 그리고 손이 적게 가는 것부터입니다.

전체 페이지를 한꺼번에 손볼 필요는 없습니다. 유입의 대부분은 보통 몇 개의 주소에서 나오기 때문입니다.

호스팅이 마지막에 있는 이유가 있습니다. 서버를 옮기는 일은 비용과 시간이 크게 드는데, 실제로는 앞의 여섯 가지에서 해결되는 경우가 훨씬 많습니다.

그리고 한 번에 하나씩 바꾸고 날짜를 적어 두십시오. 여러 개를 동시에 손보면 무엇이 효과를 냈는지 알 수 없게 됩니다.

이 기록을 생략하면 다음에 같은 증상이 생겼을 때 되돌릴 지점을 못 찾아 점검을 처음부터 다시 합니다. 저는 작업 날짜와 바꾼 항목 한 줄을 적는 것만으로 그 반복을 막을 수 있다고 봅니다. 드는 시간은 한 번에 1분입니다.

효과는 언제, 어떤 숫자로 확인하나요?

실제 방문자 데이터는 보통 3~4주 뒤에 움직입니다.

서치콘솔의 코어 웹 바이탈 보고서는 최근 4주가량의 방문 기록을 모아 보여줍니다. 오늘 고쳤다면 개선된 뒤의 방문이 그 기간을 채울 때까지 기다려야 합니다.

그 사이에 점수를 반복해서 재지 마십시오. 재는 시점마다 값이 흔들려서 판단이 오히려 흐려집니다.

대신 고친 직후에는 직접 확인하는 것으로 충분합니다. 캐시를 비운 휴대폰에서 첫 화면이 언제 뜨는지, 스크롤할 때 내용이 밀리는지, 버튼 반응이 바로 오는지 이 세 가지만 보십시오.

그리고 속도만으로 문의가 늘지는 않습니다. 속도는 방문자가 내용을 볼 기회를 만드는 조건이고, 문의로 갈지는 그 뒤의 문구와 전화 버튼, 문의 폼에서 갈립니다.

그래서 저는 속도 작업이 끝나면 다음 작업을 문의 동선으로 잡으시라고 말씀드립니다. 속도만 붙잡고 분기를 다 쓰면, 들어온 방문자가 어디서 멈추는지는 여전히 모르는 상태로 3개월이 지나갑니다.