LCP

예전에는 페이지 속도를 브라우저가 다 받았다고 선언하는 시점으로 쟀습니다. 스크립트와 이미지와 글꼴을 마지막 하나까지 내려받은 순간에 시계를 멈추는 방식입니다. 숫자는 깔끔하게 나왔지만 사람이 느끼는 것과 자주 어긋났습니다.

어긋나는 방향은 양쪽이었습니다. 화면 맨 아래에만 쓰이는 이미지 하나가 늦게 도착하면 사용자는 진작에 글을 읽고 있는데 기록은 6초로 남았습니다. 반대로 측정은 1.2초에 끝났는데 정작 맨 위 사진 자리는 회색 네모로 3초를 더 버티는 경우도 있었습니다.

그래서 회의는 늘 같은 모양으로 흘렀습니다. 마케팅이 "광고로 들어온 사람들이 화면도 안 보고 나간다" 고 하면 개발팀이 "측정값은 1.2초인데요" 라고 답했습니다. 둘 다 거짓말은 아니었지만 한쪽은 파일 받기가 끝난 시각을, 다른 쪽은 볼 것이 보이기 시작한 시각을 말하고 있었습니다.

LCP 는 이 간극을 메우려고 측정 기준을 옮긴 지표입니다. 무엇을 다 받았는지가 아니라 화면에서 가장 큰 덩어리가 언제 나타났는지를 봅니다. 사람이 페이지가 떴다고 느끼는 순간이 대개 그 덩어리가 보이는 순간이라는 관찰이 근거입니다.

브라우저가 화면 안에 그려진 요소 가운데 면적이 가장 큰 것을 하나 고르고, 페이지 이동이 시작된 시각부터 그 요소가 그려진 시각까지를 잽니다. 단위는 초이고 값이 작을수록 좋습니다.

고르는 과정은 세 단계입니다.

1. 후보를 추립니다. 사진, 동영상의 대표 이미지, 배경으로 깔린 이미지, 그리고 글자 덩어리가 후보입니다. 화면 밖으로 넘어간 부분은 면적에서 빼고 지금 보이는 영역만 셉니다.
2. 그중 면적이 가장 큰 것을 고릅니다. 블로그 글이면 맨 위 대표 이미지가, 사진이 없는 화면이면 제목이나 첫 문단 덩어리가 대개 뽑힙니다.
3. 그 요소가 그려진 시각에서 사용자가 주소를 누른 시각을 뺍니다. 사진이 2.8초에 나타났다면 LCP 는 2.8초입니다.

값이 한 번에 확정되지 않는다는 점이 이 지표의 성격을 결정합니다. 로딩 도중에 더 큰 요소가 나타나면 후보가 바뀌어 기록이 갱신됩니다. 처음에는 제목이 가장 컸다가 뒤늦게 큰 사진이 도착하면 기준점이 사진 쪽으로 옮겨 가고, 그만큼 값도 뒤로 밀립니다. 사용자가 화면을 누르거나 스크롤하면 그 시점에 측정이 멈춥니다. 사람이 이미 손을 댔다면 그 뒤에 무엇이 나타나든 첫인상은 결정된 뒤이기 때문입니다.

판단은 한 사람의 값으로 하지 않습니다. 여러 사용자의 기록을 모아 75번째 백분위수를 봅니다. 100명의 값을 빠른 순서로 줄 세웠을 때 75번째 사람이 겪은 시간입니다. 평균을 쓰면 아주 느린 몇 명이 값을 끌어올려 나머지 대부분의 경험을 가리고, 가장 느린 값을 쓰면 지하철에서 접속한 한 명의 기록으로 모든 결정을 하게 됩니다.

2.5초 이하가 좋음, 2.5초에서 4초 사이가 개선 필요, 4초 초과가 나쁨입니다. 앞 절에서 말한 75번째 백분위수 값에 이 선을 긋습니다. 사용자 넷 중 셋이 2.5초 안에 화면을 봤다면 좋음 구간입니다.

이 선은 로딩·반응·안정성을 한 묶음으로 보는 코어 웹 바이탈이 정한 것입니다. 검색 엔진이 순위에 반영한다고 말할 때 가리키는 묶음이 이것이라, 개발팀뿐 아니라 마케팅도 같은 숫자를 들여다보게 됩니다.

재는 환경을 맞추는 일이 값 자체보다 자주 문제가 됩니다. 사무실 와이파이에 연결된 최신 노트북으로 재면 웬만한 페이지가 1초대로 나오지만, 같은 페이지를 3년 된 보급형 안드로이드에서 이동통신망으로 열면 4초가 넘습니다. 그래서 측정 도구로 뽑은 점수와 실제 사용자에게서 모은 기록을 따로 둡니다. 앞의 것은 고치기 전후를 비교할 때 쓰고, 뒤의 것이 지금 상태를 말해 줍니다.

값을 줄이는 손은 구간마다 다릅니다. 서버가 첫 응답을 늦게 주면 그 뒤 단계를 아무리 손봐도 줄지 않고, 응답은 빠른데 화면에 그릴 내용을 브라우저가 자바스크립트로 만들어 내느라 시간을 쓰면 서버 렌더링처럼 미리 그려 내려 주는 방식이 답이 됩니다. 어느 구간이 긴지 보지 않고 손부터 대면 이미 빠른 곳을 더 빠르게 만들게 됩니다.

"LCP 가 4.2초예요. 히어로 이미지가 원본 그대로 올라가 있습니다."

가장 큰 요소가 필요 이상으로 무거워서 느리다는 말입니다.

"이번 배포 이후로 75분위 LCP 가 2.1초에서 3.4초로 올랐어요. 뭐가 바뀌었죠?"

성능이 나빠진 시점을 특정했으니 그 사이 변경분을 뒤져 보자는 요청입니다.

"측정 도구로는 1.8초인데 실사용자 기준으로는 3.9초입니다. 모바일에서 다시 봐야 해요."

개발 환경이 실제보다 좋아서 숫자가 낙관적으로 나왔다는 지적입니다.

페이지덱에서 이 숫자가 자주 오르는 자리는 광고로 들어오는 랜딩 페이지입니다. 현우가 들어온 사람 수에 비해 가입이 너무 적다고 가져오면 태오가 실사용자 기록을 열어 LCP 를 봅니다. 맨 위 배경 사진이 3000픽셀짜리 원본이었던 적도 있고, 서버가 첫 응답에 1.4초를 쓰고 있던 적도 있었습니다.

고친 뒤에 다시 재는 것까지가 한 묶음입니다. 사진을 줄여 2.2초로 내려온 것을 확인하고 나서야 현우가 같은 광고를 다시 돌립니다. 마케팅이 성능 회의에 앉아 있는 이유가 여기 있습니다.

로딩 중에 회색 뼈대를 깔면 LCP 가 좋아진다고 생각하는 경우가 많습니다. 스켈레톤 UI를 넣은 화면은 실제로 훨씬 빨라 보이니 그렇게 믿기 쉽습니다. 하지만 색만 칠한 빈 상자는 콘텐츠로 세지 않아서 후보에 들지 못하고, 측정은 진짜 사진이나 글이 도착할 때까지 그대로 기다립니다. 이걸 모르면 스켈레톤을 깔아 두고 숫자가 꿈쩍도 하지 않는 것을 보며 지표가 이상하다는 결론으로 갑니다. 스켈레톤이 줄이는 것은 기다리는 동안의 불안이지 기다리는 시간이 아닙니다.

가장 큰 요소를 측정 대상에서 빼는 방식으로 숫자를 낮추는 것도 흔합니다. 맨 위 사진을 나중에 받도록 미뤄 두면 LCP 요소가 제목 덩어리로 바뀌면서 값이 3.8초에서 1.1초로 떨어집니다. 지표는 좋아졌지만 사용자가 사진을 기다리는 시간은 하나도 줄지 않았고, 오히려 사진이 늦게 끼어들면서 읽던 문장이 아래로 밀립니다. 그 밀림은 CLS가 따로 잡아내므로 한쪽을 속이면 다른 쪽에서 드러납니다. 지표를 낮추는 것과 화면을 빠르게 만드는 것은 다른 일입니다.