Core Web Vitals: 사이트를 진짜로 빠르게 만들기

「제 컴퓨터에선 잘 돼요」로는 부족하다

전형적인 함정: 개발자는 광랜, 최신 MacBook, 데워진 캐시로 테스트합니다. 반면 실제 사용자는 중급 휴대폰, 변덕스러운 4G, 빈 캐시로 도착합니다. 둘 사이의 경험에는 아무런 공통점이 없습니다.

Core Web Vitals는 사용자가 실제로 겪는 것을 측정하기 위해 존재합니다. Google은 이를 랭킹 요인으로 삼았고——무엇보다 전환을 예측합니다: 로딩이 1초 늘어날 때마다 방문자가 떠나갑니다.

정말 중요한 세 지표

• LCP(Largest Contentful Paint) — 주요 요소(대개 히어로 이미지나 제목)가 나타나기까지의 시간. 목표: 2.5초 미만.
• INP(Interaction to Next Paint) — 반응성: 클릭과 눈에 보이는 반응 사이의 지연. 목표: 200밀리초 미만. JavaScript가 많은 사이트에서는 여기가 승부처입니다.
• CLS(Cumulative Layout Shift) — 안정성: 이미지나 광고가 로드될 때 엉뚱한 곳을 클릭하게 만드는 그 레이아웃 이동. 목표: 0.1 미만.

아름답지만 느린 사이트는 실패한 사이트입니다. 성능은 디자인의 적이 아닙니다——명료한 선택을 강제하는 제약입니다.

제가 쓰는 수단

사이트를 빠르게 만드는 데 마법은 없습니다. 결정의 총합입니다:

• 이미지 — 최신 포맷(AVIF/WebP), 올바른 치수, 접힘 아래의 lazy loading, 그리고 이동(CLS)을 막기 위한 공간 확보.
• 폰트 — font-display: swap, 실제로 쓰는 굵기만 미리 로드, 그리고 무엇보다: 그것만 로드하기.
• JavaScript — 가능한 한 적게 내보내기. 가장 빠른 코드는 브라우저에 보내지 않는 코드입니다. 서버 컴포넌트, 비핵심 요소의 지연 로딩.
• 렌더링 — 콘텐츠가 허락하면 정적(빌드 시 사전 생성)을 우선: 이미 준비된 파일을 이길 것은 없습니다.
• 지속적 측정 — 성능 예산과 모니터링(Lighthouse, Speed Insights)으로 회귀를 프로덕션 이후가 아니라 이전에 발견하기.

실험실이 아니라 현장에서 측정하라

측정에는 두 가지 방식이 있습니다: 실험실 데이터(Lighthouse, 통제된 환경)와 현장 데이터(실제 사용자, Chrome UX Report 경유). 둘 다 유용하지만, 현실을 비추는 것은 후자뿐입니다. 사이트가 실험실에서 100점을 받고도, 느린 연결이나 수수한 기기 때문에 현장에서는 실망스러울 수 있습니다.

제 규율: 빨라지기 위해 실험실에서 최적화하되, 승리를 선언하기 전에 현장에서 검증하기.

그것이 클라이언트에게 왜 중요한가

빠른 사이트는 기술적인 멋 부리기가 아닙니다. 그것은 머무는 방문자가 늘고, Google 순위가 오르고, 전환이 늘어나는 것입니다. 속도는 사용자와 순위와 매출에 동시에 기여하는, 드문 개선 중 하나입니다. 그래서 저는 그것을 보너스가 아니라 요건으로 다룹니다.