Core Web Vitals 는 이름 때문에 기술 담당자의 영역처럼 보이지만, 실제로 재는 것은 방문자가 화면에서 겪는 경험입니다. 세 지표는 각각 한 문장으로 옮겨집니다.
세 문장이 가리키는 것
LCP는 그 화면에서 가장 큰 주인공 — 대개 히어로 이미지나 큰 제목 — 이 언제 나타나는가입니다. 페이지가 “떴다” 고 느끼는 순간이라고 보면 됩니다. 배경만 하얗게 떠 있고 주인공이 늦게 나오면 사용자는 아직 안 열렸다고 판단합니다.
CLS는 읽는 도중에 화면이 흔들리는 정도입니다. 기사를 읽으려는데 위쪽에 이미지가 늦게 로드되면서 본문이 아래로 밀리는 경험, 버튼을 누르려는 순간 배너가 끼어들어 엉뚱한 것이 눌리는 경험이 여기 해당합니다. 사용자를 가장 확실하게 화나게 하는 종류의 문제입니다.
INP는 눌렀을 때 반응하는가입니다. 메뉴를 탭했는데 잠깐 아무 일도 일어나지 않는 그 시간입니다. 화면은 다 그려져 있는데 반응이 없으면 사용자는 한 번 더 누르고, 그러면 상태가 더 꼬입니다.
실사용자 데이터와 측정 도구는 다릅니다
보고에서 자주 부딪히는 지점입니다. 속도 측정 도구를 돌리면 좋게 나오는데 리포트에서는 나쁘게 나오거나, 그 반대인 경우가 있습니다. 둘은 다른 것을 재고 있으므로 어긋나는 것이 정상입니다.
보고할 때는 어느 쪽 수치인지 먼저 밝힙니다. 개선 작업의 효과를 확인할 때는 실험실 측정이 즉시 답을 주고, 실제로 나아졌는지는 실사용자 데이터가 시간을 두고 확인해 줍니다. 두 화면을 나란히 보는 것이 옳지, 어느 하나가 틀린 것이 아닙니다.
지표를 요청으로 바꾸기
마케터가 코드를 고칠 필요는 없지만, 어떤 지표가 나쁜지를 말할 수 있으면 요청이 좁아집니다. 세 지표는 대체로 서로 다른 원인 계열을 가지므로, 지표 이름만 정확해도 조사 범위가 크게 줄어듭니다.
LCP 가 나쁘면 주인공이 늦게 오는 것이므로 첫 화면에 필요한 것부터 먼저 오게 해 달라는 요청이 됩니다. CLS 가 나쁘면 무언가가 뒤늦게 끼어드는 것이므로 자리를 미리 잡아 달라는 요청입니다. INP 가 나쁘면 반응을 가로막는 것이 있다는 뜻이라 첫 화면에 꼭 필요하지 않은 스크립트를 뒤로 미뤄 달라는 요청이 됩니다. 원인 진단은 개발자의 몫이지만, 방향은 이 세 문장으로 충분히 전달됩니다.
그리고 수치를 목표로 삼지 않습니다. 이 지표들을 고치는 이유는 점수가 아니라, 가게 문이 뻑뻑하면 손님이 돌아서는 것과 같은 이유입니다. 점수만 좇으면 화면 경험은 그대로인데 숫자만 좋아지는 작업을 하게 됩니다.
지표별 원인과 개선 방법은 성능 최적화 아카이브에 이어지고, 측정 · 개선 · 재측정을 한 번에 맡기려면 최적화 지원 사업에 전후 측정이 포함돼 있습니다.
다음 회차
여기까지 원리를 알았다면 이제 그것을 움직이는 요청으로 바꿀 차례입니다. 다음 회차는 요청서 쓰기 — “SEO 좀 해 주세요” 가 왜 아무것도 바꾸지 못하는지부터 시작합니다.