Core Web Vitals: 점수 놀이가 아닌 사용자 경험

성능 지표를 처음 대시보드에 붙이면 팀이 자주 하는 말이 있습니다. “이번 주엔 90점 넘겼다.” 그런데 실제 CS를 보면 “버튼이 늦게 눌린다”, “읽는 중 화면이 밀린다” 같은 불만이 남아 있습니다. 저희도 한동안 점수만 보고 안심했다가, 실사용 구간에서 전환율이 떨어지는 걸 나중에 확인했습니다. 그 뒤로는 Core Web Vitals를 점수표가 아니라 사용자 흐름 점검 도구로 봅니다. 화면이 빨리 보이는지, 누르면 바로 반응하는지, 읽는 중 레이아웃이 흔들리지 않는지. 이 세 가지를 기준으로 잡으면 회의가 훨씬 현실적으로 바뀝니다.

1. 개선 우선순위를 페이지가 아니라 화면 흐름으로 잡기

페이지 단위 평균값만 보면 병목을 놓치기 쉽습니다. 실제로 느린 지점은 공통 컴포넌트에서 반복됐습니다. 상단 히어로, 공통 네비 스크립트, 외부 위젯 같은 항목이 대표적입니다. 그래서 우선순위를 페이지가 아니라 “사용자 첫 5초 흐름” 기준으로 정했습니다. 기본 콘텐츠, 필수 인터랙션, 비핵심 기능으로 나누고, 마지막 그룹은 과감하게 뒤로 미뤘습니다. 이 구조를 한번 잡아 두면 새 기능이 들어와도 어디까지 초기 렌더링에 실을지 합의가 빨라집니다.

2. 프론트엔드 최적화는 세트로 적용해야 한다

이미지 한 번 줄여서 점수가 오르는 경우는 많습니다. 문제는 두 번의 배포 뒤 다시 내려간다는 점입니다. 스크립트, 폰트, 레이아웃을 같이 관리하지 않으면 항상 되돌아옵니다. 그래서 세 축을 묶어서 보게 했습니다.

• 이미지: 화면 크기에 맞는 소스 제공, 우선 렌더링 대상 선별
• 스크립트: 초기 렌더링과 무관한 코드 지연 실행
• 레이아웃: 이미지/광고/임베드 영역의 크기 사전 확보

특히 레이아웃 안정성은 개발팀만으로 해결이 안 됩니다. 디자인 시스템에 크기 규칙이 없으면 새 배너 한 장으로도 CLS가 다시 올라갑니다. 저희는 컴포넌트 도입 체크리스트에 “자리 선점 규칙”을 넣은 뒤 재발이 크게 줄었습니다.

3. 릴리스 후 회귀 방지 루틴 만들기

성능은 고쳐 놓으면 다시 망가지는 영역입니다. 기능이 늘면 당연히 무거워집니다. 그래서 릴리스 파이프라인에 회귀 점검을 기본으로 넣었습니다. CI 랩 측정과 실사용 데이터 관측을 같이 두고, 임계치를 넘으면 배포를 미루거나 점진 배포로 돌립니다. 중요한 건 “누가 봐도 같은 결론이 나는 기준”입니다. 기준이 없으면 바쁜 주간에는 성능 이슈가 항상 후순위가 됩니다.

4. 운영 체크리스트

• 성능 이슈를 발견했을 때 영향 화면과 공통 컴포넌트를 먼저 분리했는가
• 초기 렌더링에 불필요한 스크립트가 포함되어 있지 않은가
• 레이아웃 변동 요소(이미지/광고/임베드)의 자리 고정 규칙이 있는가
• 릴리스 전후 성능 지표를 같은 조건으로 비교하고 있는가
• 성능 회귀가 반복되는 영역에 코드 소유자가 지정되어 있는가

결론적으로 Core Web Vitals는 점수 게임이 아니라 사용자 신뢰를 지키는 운영 지표입니다. 빠르게 보이고, 바로 반응하고, 흔들리지 않는 화면을 만드는 팀이 장기적으로 SEO와 전환을 동시에 가져갑니다.

5. 실무 적용 순서(2주 루틴)

첫 주에는 측정 기준부터 통일합니다. 핵심 화면 3개를 고르고 배포 전후를 같은 조건으로 비교할 리포트 템플릿을 만듭니다. 둘째 주에는 개선을 한 번에 몰지 말고 이미지, 스크립트, 레이아웃 순으로 나눠 반영합니다. 이렇게 해야 어떤 변경이 효과를 냈는지 분명해집니다. 성능 개선은 대형 프로젝트보다 작은 배포 루틴으로 굴릴 때 오래 유지됩니다. 점수보다 사용자 체감을 먼저 보는 팀이 결국 더 빠르고, 더 안정적으로 갑니다.