노트

Core Web Vitals

Core Web Vitals

프론트엔드#performance · 연결된 개념 26개

쉽게 말하면

Core Web Vitals는 페이지 건강검진표예요. 큰 내용이 얼마나 빨리 보이는지, 눌렀을 때 얼마나 빨리 반응하는지, 화면이 갑자기 밀리지 않는지 세 가지를 실제 사용자 기준으로 재요.

비유의 한계 병원에서 한 번 재는 검진과 달리 실제 방문 데이터의 p75로 판정해서 Lighthouse 결과와 다를 수 있어요. 또 지표 자체가 목표가 되면 엉뚱한 최적화로 흐르기 쉬워요.

실제 사용자가 느끼는 페이지 품질을 재기 위해 구글이 정한 지표 모음. 그중 로딩·반응성·시각적 안정성을 대표하는 세 가지를 Core Web Vitals라고 부른다.

지표재는 것'좋음' 기준
LCP(Largest Contentful Paint)화면에서 가장 큰 콘텐츠(히어로 이미지, 큰 글 덩어리)가 그려지기까지2.5초 이하
INP(Interaction to Next Paint)클릭·탭·키 입력부터 다음 화면이 그려지기까지200ms 이하
CLS(Cumulative Layout Shift)로딩 중 콘텐츠가 예기치 않게 밀린 정도0.1 이하
  • INP는 2024년 3월에 FID(First Input Delay)를 대체했다. FID는 첫 입력의 대기 시간만 봐서, 첫 클릭만 빠르면 이후가 느려도 좋은 점수를 받았다. INP는 페이지에서 일어난 상호작용 전체를 보고, 입력 지연·핸들러 실행·화면 갱신까지 모두 포함한다
  • 판정은 실제 방문 데이터(CrUX, Chrome User Experience Report)의 75번째 백분위(p75) 기준이다. 방문의 75%가 '좋음'이어야 통과다. 실험실 측정(Lighthouse)과 현장 데이터가 다를 수 있다
  • 검색 순위 요소이지만 결정적이지는 않다. 비슷한 페이지 사이에서 우열을 가르는 정도로 보는 편이 맞다

무엇이 지표를 나쁘게 하나

"반응이 400ms 안에 와야 몰입이 깨지지 않는다"는 도허티 임계도 INP와 같은 문제의식을 담고 있다. 지표 자체가 목표가 되면 엉뚱한 최적화로 흐르기 쉽다는 점(굿하트의 법칙)도 기억해 둘 만하다.

출처: web.dev — Web Vitals: Core Web Vitals

연결된 개념

이 노트를 가리키는 문서

뜻이 가까운 노트

  • 크로스 브라우징

    크로스 브라우징은 브라우저 종류·버전·기기가 달라도 웹 페이지가 같은 기능을 제공하도록 만드는 일이다. 모든 브라우저에서 픽셀까지 똑같이 보이게 하는 것이 목표가 아니라, 지원하기로 한 환경에서 핵심 기능이 동작하고 오래된 환경에서도 쓸 수는 있게(점진적 향상, Progressive Enhancement) 하는 것이 목표다.

  • content-visibility

    화면 밖에 있는 요소의 렌더링을 건너뛰어도 된다고 브라우저에 알려 주는 CSS 속성. auto를 주면 뷰포트에서 멀리 있는 요소의 레이아웃·페인트를 생략하므로, 긴 페이지의 첫 렌더링과 스크롤이 빨라진다.

  • 반응형 웹 디자인

    하나의 페이지가 화면 크기와 기기에 맞춰 레이아웃·이미지·글자 크기를 바꾸도록 만드는 접근. 미디어 쿼리(Media Query), 유연한 레이아웃(Flexible Layout), 반응형 미디어(Responsive Media)가 세 축이다.

  • XSS

    XSS(Cross-Site Scripting)는 공격자가 넣은 스크립트가 내 사이트의 출처(origin) 권한으로 사용자 브라우저에서 실행되는 공격이다. 같은 출처의 코드로 돌기 때문에 same-origin-policy가 막아 주지 못한다. 그 스크립트는 페이지를 바꾸고, 로그인한 사용자 행세를 하며 요청을 보내고, JS가 읽을 수 있는 데이터(localStorage의 토큰 등)를 빼 갈 수 있다.

  • 크롬 개발자 도구 팁

    크롬 DevTools에서 알아 두면 디버깅 시간이 줄어드는 기능 모음. 대부분 다른 크로미움(Chromium) 브라우저에서도 같다.

보기 옵션