▲

Core Web Vitals의 역사

 (addyosmani.com)
13P by neo 4일전 | ★ favorite | 댓글과 토론
  • 웹사이트 성능을 측정하는 Core Web Vitals는 2014년부터 Google의 여러 팀이 협력하여 AMP 프로젝트의 한계를 극복하고, 모든 웹사이트에 적용 가능한 개방형 표준 성능 지표를 정의하려는 노력에서 시작됨
  • 2020년 5월 세 가지 핵심 지표(로딩 속도의 LCP, 상호작용 응답성의 FID, 시각적 안정성의 CLS)가 공식 발표되었으며, 실제 사용자 경험을 반영하는 필드 측정 가능한 지표로 설계됨
  • 2021년 Google Search의 Page Experience 업데이트를 통해 검색 순위 요소로 도입되었고, Top Stories에서 AMP 독점 요구사항이 제거되어 개방형 웹 경쟁 환경 조성
  • Chrome 브라우저 최적화, WordPress 등 주요 CMS 개선, JavaScript 프레임워크 협업을 통해 2023년 기준 사용자 대기 시간 누적 10,000년 이상 절약, 2024년에는 30,000년 절약 달성
  • 2024년 FID를 INP로 교체하고 SPA를 위한 Soft Navigation API를 도입하는 등 지속적으로 진화하며, 사용자 중심의 빠르고 안정적인 웹 생태계 구축에 기여

배경과 동기: AMP에서 개방형 웹 지표로

  • Google은 수년간 속도와 사용자 경험을 웹의 핵심 원칙으로 강조했으나, 여전히 많은 사이트가 느린 경험을 제공
  • 2010년 Google Search는 사이트 속도를 검색 순위 신호로 사용하기 시작했으며, 이는 성능을 SEO에 포함시킨 초기 시도
  • 2015년경 AMP(Accelerated Mobile Pages) 프로젝트가 도입되어 빠른 로딩을 위한 최적화된 페이지를 제공했지만, Google 캐시에서 제공되는 폐쇄적인 환경이라는 개방성과 유연성 문제 발생
  • 2018년 Speed Update를 통해 모바일 검색 순위에 페이지 속도를 적용하고, Google Ads도 모바일 랜딩 페이지 속도 점수를 도입하여 빠른 경험이 더 나은 전환율을 가져온다는 점을 강조
  • AMP 전용 접근 방식에서 벗어나기 위해 Chrome과 Search 팀이 협력하여 특별한 프레임워크 없이 모든 페이지에 적용 가능한 개방형 웹 성능 지표 정의 시작
    • 수백만 페이지를 분석하여 빠르고 사용자 친화적인 웹페이지의 공개 표준 정의
    • 실제 사용자 경험을 반영하는 필드 측정 가능한 지표를 목표로 설정
    • 사용자 참여도와 같은 결과와 상관관계가 있는 지표를 찾고자 함

Core Web Vitals 정의: 사용자 경험의 세 가지 기둥

  • 2020년 5월 Google이 Web Vitals 이니셔티브를 공식 발표하며 "모든 웹페이지에 적용되는 사용자 경험의 핵심 측면"에 초점을 맞춘 Core Web Vitals 도입

  • 초기 Core Web Vitals는 세 가지 핵심 지표로 구성

    • Largest Contentful Paint(LCP): 주요 콘텐츠가 렌더링되는 시점을 측정하는 로딩 속도 지표로, First Contentful Paint나 onload를 넘어 사용자가 실제로 의미 있는 콘텐츠를 보는 시점에 초점
    • First Input Delay(FID): 사용자의 첫 번째 상호작용과 브라우저 응답 사이의 지연을 측정하는 상호작용 응답성 지표로, 페이지가 즉시 반응하는지 또는 무거운 스크립트로 인해 지연되는지를 포착
    • Cumulative Layout Shift(CLS): 로딩 중 페이지 레이아웃이 얼마나 이동하는지 측정하는 시각적 안정성 지표로, 예상치 못한 레이아웃 이동을 합산하여 낮은 CLS는 안정적이고 쾌적한 경험을 의미

  • 지표 선정은 광범위한 연구와 실험을 기반으로 진행

    • Amar Sagoo, Annie Sullivan, Vivek Sekhar 등이 인간-컴퓨터 상호작용 연구를 통해 객관적인 성능 수치와 사용자 인식의 상관관계 발견
    • 로딩 시간은 2~3초 이내, 입력 응답은 100ms 이내, 레이아웃 이동은 최소화가 이상적
    • 실제 사용자 데이터를 분석하여 실용적인 임계값 목표 설정: LCP 2.5초 미만, FID 100ms 미만, CLS 0.1 미만(75번째 백분위수 기준)
    • 이 임계값을 충족하는 페이지는 사용자가 페이지 이탈 확률이 24% 낮음

  • Google은 이러한 지표를 표준화되고 개방적으로 만들기 위해 노력

    • WICG 및 웹 성능 표준 그룹을 통해 웹 사양 초안 발표
    • Chrome 및 다른 브라우저가 PerformanceObserver API를 통해 측정 가능하도록 구현
    • 2020년 5월 개발자가 사이트에 삽입하여 실제 사용자의 LCP, FID, CLS를 측정할 수 있는 오픈소스 web-vitals JavaScript 라이브러리 출시
    • Addy Osmani가 실시간으로 지표를 표시하는 Core Web Vitals 확장 프로그램 개발
    • 생태계 전체에서 접근 가능하고 유용하게 만들려는 광범위한 노력 반영

Page Experience: Google Search 순위에서의 Core Web Vitals

  • Google Search 팀이 Core Web Vitals를 Page Experience 업데이트의 일부로 신속하게 채택

  • 2020년 5월 28일 Google Search Central이 이러한 지표를 순위 알고리듬에 포함할 예정이라고 발표

    • 콘텐츠 관련성이 유사한 두 페이지가 있을 때 더 나은 사용자 경험을 제공하는 페이지를 상위에 랭크
    • Page Experience 신호는 Core Web Vitals와 기존 UX 관련 신호(모바일 친화성, HTTPS 보안, 방해 인터스티셜 회피)를 결합
    • 훌륭한 콘텐츠가 여전히 가장 중요하며, 빠른 사이트가 단지 속도 때문에 더 관련성 높은 사이트를 능가하지는 않음
    • 동점이나 근소한 차이의 경우 좋은 Web Vitals가 결정적 요인이 될 수 있음

  • 가장 주목할 만한 발표는 Top Stories 캐러셀에서 AMP 요구사항 제거

    • 이전에는 모바일에서 Google News/Top Stories가 AMP를 요구했으나, Page Experience 업데이트 후 AMP가 아닌 페이지도 Core Web Vitals 및 기타 기준을 충족하면 등록 가능
    • "AMP는 더 이상 모바일 Top Stories에 필수가 아니며, 좋은 페이지 경험을 가진 모든 페이지에 개방"
    • 개방형 웹이 AMP 프레임워크로 유입되지 않고도 개선되도록 장려하려는 Google의 신뢰를 나타냄

  • Google은 생태계에 충분한 사전 통지 제공

    • 2020년이 COVID-19 팬데믹으로 어려운 해임을 인식하고 순위 변경이 2021년까지 적용되지 않을 것이라고 발표하며 최소 6개월 경고 약속
    • 2020년 11월 업데이트를 통해 Page Experience 순위 변경이 2021년 5월부터 시작될 것이라고 제공
    • 최종적으로 Page Experience 업데이트는 2021년 6월 중순에 롤아웃 시작하여 8월 말까지 완전히 적용(모바일 검색)
    • 데스크톱 검색에 대한 유사한 업데이트는 2022년 2~3월에 진행

  • 업데이트가 적용되자 Google의 순위 알고리듬은 Core Web Vitals를 수백 가지 신호 중 하나로 사용 시작

    • 세 가지 CWV 지표 모두에서 "좋음" 임계값을 충족하는 페이지는 좋은 페이지 경험을 가진 것으로 간주
    • Google은 Google Search Console에 Page Experience 보고서 생성하여 사이트 소유자가 Chrome UX Report 데이터를 사용해 임계값을 통과하는 페이지 비율 확인 가능
    • 웹마스터와 SEO 전문가가 페이지 경험 신호 관점에서 사이트가 어떻게 수행되는지에 대한 직접적인 피드백 제공

  • Google은 검색 결과에서 좋은 페이지 경험을 가진 페이지에 대한 배지 표시를 고려했으나, 영구적인 배지 아이콘은 추가되지 않음

    • 보상은 주로 명시적 레이블보다는 순위 상승 형태로 제공
    • 한동안 Google은 Search Console 및 검색 결과 실험에서 임시 "Page Experience" 표시자를 보여줌
    • 핵심 내용: Google이 성능과 UX를 공개적으로 인센티브화하고 있으며, 좋은 Core Web Vitals 달성은 사용자를 만족시킬 뿐만 아니라 검색에서 페이지 가시성도 향상 가능

도구 및 데이터: Chrome UX Report와 성능 측정

  • Google은 Web Vitals를 위한 도구와 데이터에 대한 대규모 투자 진행

  • Chrome UX Report(CrUX) 가 이러한 노력의 핵심

    • 2017년부터 존재해온 실제 사용자 경험 지표의 공개 데이터셋으로, 수백만 Chrome 사용자로부터 수백만 사이트에 대한 익명화된 성능 데이터 수집
    • Core Web Vitals 출시 시 CrUX가 즉시 데이터셋의 모든 출처 URL에 대해 LCP, FID, CLS 보고 시작
    • 누구나 필드 성능 데이터 쿼리 가능
    • BigQuery를 통한 액세스 제공 후 CrUX API 및 CrUX Dashboard 출시하여 개발자와 SEO 전문가가 자신의 사이트(또는 경쟁사)가 필드에서 CWV 지표에서 어떻게 수행되는지 쉽게 확인 가능
    • CrUX History API 도입으로 이러한 지표의 시계열 데이터 제공하여 수개월에 걸친 진행 상황 추적 가능

  • 개발자 도구 측면에서 빠른 통합 진행

    • 2020년 말까지 Google의 대부분의 성능 도구가 Core Web Vitals를 강조하도록 업데이트
    • Lighthouse(Chrome DevTools 및 PageSpeed Insights에서 사용되는 오픈소스 감사 도구)가 CWV 관련 진단 및 점수 통합
      • "Largest Contentful Paint가 X초였습니다(목표 <2.5초)" 같은 감사 추가 및 개선 제안 제공
    • Chrome DevTools에 Core Web Vitals 패널 및 타임라인 마커 추가하여 페이지 로드 중 LCP 요소나 레이아웃 이동 확인 가능
    • PageSpeed Insights(PSI) 가 CWV에 초점을 맞추도록 전면 개편
      • CrUX에서 가져온 LCP, FID(나중에 INP), CLS에 대한 필드 데이터를 상단에 눈에 띄게 표시
    • Google Search Console은 각 지표에 대해 페이지를 "좋음", "개선 필요", "나쁨" 버킷으로 그룹화하는 전용 Core Web Vitals 보고서 제공하여 사이트 소유자가 문제 영역 정확히 파악 가능
    • Elizabeth Sweeny, Paul Irish, Addy Osmani 등이 주도한 도구 작업

  • 웹 개발 커뮤니티도 타사 도구로 호응

    • Real User Monitoring(RUM) 서비스 제공업체가 Core Web Vitals를 빠르게 통합
    • Akamai의 mPulse, New Relic의 Browser 에이전트, Dynatrace, Datadog, SpeedCurve 등이 LCP, FID, CLS를 일급 지표로 즉시 지원
    • Cloudflare도 스크립트를 삽입하여 Web Vitals를 수집할 수 있는 Browser Insights 서비스 도입
    • web-vitals JS 라이브러리의 존재로 모든 분석 도구가 이러한 지표를 쉽게 수집 가능
    • 2021년까지 Core Web Vitals가 웹 성능 모니터링 도구의 대시보드에서 보편화
    • 이러한 광범위한 가용성으로 인식 확산 및 개발자가 성능 개선을 주도할 수 있는 데이터 제공

  • Chrome User Experience Report 데이터는 웹 전체의 진행 상황 추적에도 필수적

    • 2021년과 2022년 동안 "좋은" CWV를 가진 트래픽 비율이 꾸준히 증가
    • HTTP Archive의 연간 Web Almanac이나 Google 자체 블로그 업데이트에서 자주 보고
    • 측정 가능하고 공개적으로 볼 수 있는 지표를 갖는 것이 일종의 선순환 경쟁을 만들어냄
    • 사이트 소유자와 플랫폼 제공업체가 Core Web Vitals에 대해 자랑하고 개선하려고 노력하기 시작

영향과 개선: 웹을 더 빠르고 안정적으로 만들기

Chrome 브라우저 최적화

  • Core Web Vitals가 확립되자 웹 생태계 전반에 걸쳐 이러한 지표를 개선하기 위한 대규모 다각적 노력 촉발

  • Google Chrome 엔지니어링 팀이 브라우저를 면밀히 검토하여 Chrome이 웹페이지를 로드하고 렌더링하는 방식 최적화

    • Chrome의 거대한 사용자 기반을 고려할 때 브라우저 수준의 작은 개선도 전체 웹에 이익 제공
    • 2020~2023년 사이 Chrome에서 출시된 주요 최적화 포함

  • LCP를 위한 콘텐츠 우선순위 지정

    • Chrome이 중요한 콘텐츠 로딩을 우선시하도록 변경
    • HTML의 처음 몇 개 이미지(종종 LCP 이미지 포함)를 식별하고 더 높은 네트워크 우선순위 부여
    • 처음 5개 이미지를 이렇게 우선순위 지정하면 일부 페이지에서 LCP가 3.1초에서 2.5초로 개선
    • fetchpriority 속성(Priority Hints 메커니즘) 같은 새로운 웹 표준 도입하여 개발자가 이미지나 iframe을 LCP를 위한 높은 우선순위로 표시 가능

  • Back/Forward Cache(BFCache)

    • Chrome이 기술적 복잡성으로 인해 역사적으로 페이지를 완전히 BFCache하지 않았으나, 최근 몇 년간 많은 페이지에 대해 BFCache 활성화
    • 2023년까지 데스크톱과 Android 모두에서 주목할 만한 BFCache 적중률 증가 달성
    • 페이지로 "뒤로" 가는 사용자가 즉시 볼 수 있음(LCP 제로, 입력 지연 제로, 페이지가 언로드되지 않기 때문)
    • Amazon 같은 대형 플랫폼이 Chrome의 BFCache로부터 혜택을 보고, Chrome의 개선(버전 M112) 후 back/forward 캐시 사용이 22.7%p 증가 보고

  • Prerendering(NoState Prefetch/Prerender2)

    • Chrome이 브라우저가 백그라운드에서 페이지를 완전히 로드하고 렌더링한 다음 사용자가 탐색할 때 즉시 교체할 수 있는 새로운 프리렌더러(Prerender2) 출시
    • 처음에는 Google Search(상위 결과 프리렌더링) 및 입력된 URL 예측에 사용되어 LCP를 극적으로 단축 가능
    • Chrome은 omnibox 검색 프리렌더링이 해당 탐색에서 500~700ms(약 15~25%) 중앙값 LCP 개선 제공한다고 보고
    • Chrome은 이를 신중하게 롤아웃 중(잘못된 예측이나 개인정보 보호 문제를 피하기 위해)

  • 네트워크 및 스케줄링 최적화

    • Chrome 팀이 입력 응답성의 다양한 작은 지연을 식별하고 해결
    • 포인터 다운 시 사전 연결 기능 도입(탭/클릭을 시작할 때, 릴리스하기 전)하여 링크 탐색을 위한 연결 설정에서 몇 밀리초 단축
    • 교차 출처 탐색에서 평균 약 6~10ms 더 빠른 LCP 제공
    • 여러 탭이 열려 있을 때 브라우저의 메인 스레드가 작업을 처리하는 방식 개선하여 경합 감소
    • 작업 스케줄링 조정 및 백그라운드 탭에 Windows 11의 EcoQOS 같은 메커니즘 사용으로 Chrome은 심하게 로드된 시나리오에서 INP를 약 5%, LCP를 약 2% 개선

  • 렌더링 및 JavaScript 엔진 개선

    • Chrome의 RenderingNG 아키텍처 개편(2021년경 완료)으로 렌더링이 더 효율적으로 변경
    • 이미지 로딩 우선순위 업그레이드(LCP 이미지가 덜 중요한 다른 작업 뒤에 차단되지 않도록) 및 V8의 더 스마트한 가비지 컬렉션 타이밍(유휴 시간 동안 실행)이 더 매끄러운 경험 보장
    • Chrome 개발자가 다중 프로세스 브라우저에서 쿠키에 액세스하는 방식이 jank를 유발한다는 것을 발견
      • 모든 document.cookie 호출이 별도 프로세스에서 동기적으로 가져와야 했음
      • 쿠키에 대한 공유 메모리 버전 관리 도입으로 Chrome의 쿠키 액세스 최적화하여 많은 중복 프로세스 홉 제거
      • 사이트가 모든 상호작용에서 쿠키 읽기를 스팸으로 보내는 경우 입력 지연 감소

  • 이러한 모든 Chrome 최적화가 측정 가능한 차이 제공

    • 2023년 말까지 Google은 Chrome의 평균 페이지 로드가 Core Web Vitals가 존재하기 전보다 166ms 빠르다고 보고
    • 전체 웹에 걸쳐 엄청난 영향: 절약된 시간을 합산하면 Chrome 팀은 2023년에만 속도 개선으로 사용자가 페이지 로딩을 위해 기다리는 누적 시간 10,000년 이상, 페이지가 입력에 응답하기를 기다리는 추가 1,200년 이상 절약했다고 계산
    • CWV "좋음" 기준을 충족하는 트래픽 비율도 크게 상승
    • 처음 발표 시 약 1/3의 페이지 로드가 CWV 기준으로 좋았으나, 2023년까지 Chrome의 데스크톱 페이지 방문 약 68%, 모바일 약 64%가 세 가지 CWV 임계값을 모두 충족

광범위한 웹 생태계 개선

  • 개선은 Google 측면만이 아니며, 더 광범위한 웹 개발자 커뮤니티, 프레임워크, 플랫폼 벤더가 Core Web Vitals로 식별된 성능 문제를 해결하기 위해 나섰음

  • 이미지 최적화 및 지연 로딩

    • 이미지가 종종 가장 큰 콘텐츠이자 일반적인 LCP 원인임을 인식하고 웹 프레임워크와 CMS가 더 스마트한 기본값 구현
    • 오프스크린 이미지에 대한 네이티브 HTML loading="lazy"가 표준화(Chrome 및 Yoav Weiss, Addy Osmani 같은 웹 표준 기여자의 도움으로)되고 WordPress 및 기타 플랫폼에서 채택되어 불필요한 이미지 로딩을 극적으로 감소
    • WordPress가 2020년 기본적으로 이미지에 대한 지연 로딩을 활성화한 후 LCP가 지연되지 않도록 맨 처음 배너 이미지를 지연 로딩하지 않도록 개선
    • 새로운 <img fetchpriority="high"> 속성이 프레임워크에서 빠르게 활용되어 더 빠른 로딩을 위해 메인 이미지 표시

  • WordPress Performance Team

    • WordPress가 모든 웹사이트의 약 40%를 차지하므로 성능이 엄청난 영향력 보유
    • 초기에 WordPress 사이트가 CWV 점수에서 뒤처졌으며, 2021년 보고서는 WordPress 사이트가 다른 일부 생태계에 비해 통과율이 낮다는 것을 보여주어 경각심을 불러일으킴
    • 커뮤니티가 WordPress 코어의 속도를 체계적으로 개선하기 위해 전용 Core Performance Team(Google 및 기타 회사의 기여자 포함) 구성하여 대응
    • 최근 릴리스에서 작업이 성과를 거둠
      • WordPress 6.3(2023) 은 테마 렌더링 및 자산 로딩에 대한 수많은 최적화를 포함하여 LCP 지표 기준으로 WordPress 6.2에 비해 블록 테마는 27% 빠르게, 클래식 테마는 18% 빠르게 로드되는 코어 테마 제공
      • 실제로 수백만 개의 사이트가 WordPress를 업그레이드하는 것만으로 더 빨라짐
    • WordPress 팀이 이미지 처리를 최적화하고, 특정 비용이 많이 드는 작업에 대한 캐싱을 추가하고, 성능을 새로운 기능과 동등한 우선순위로 만듦
    • 결과적으로 좋은 CWV 점수를 가진 WordPress 사이트 비율이 극적으로 증가(일부 데이터는 모든 CWV를 충족하는 WP 사이트 비율이 2020년에서 2022년 사이 4배 이상 증가했음을 보여줌)

  • Wix 및 웹사이트 빌더

    • Wix, Squarespace, Duda 같은 다른 호스팅 웹사이트 플랫폼도 Core Web Vitals를 성능 개선의 계기로 삼음
    • Wix는 주요 인프라 개편(캐싱, 더 빠른 서버, 더 나은 클라이언트 측 코드)을 수행하고 좋은 CWV 점수를 달성하는 Wix 사이트 비율을 몇 배 증가시킴
    • 사례 연구에서 Wix는 "좋은" CWV를 가진 사이트 비율을 약 1년 동안 4%에서 33% 이상으로 끌어올렸다고 보고
    • 플랫폼에서 성능 중심 문화 전환이 엄청난 수의 사용자에게 이익을 줄 수 있음을 입증
    • Duda 같은 다른 빌더들도 자주 대다수의 고객 사이트가 좋은 CWV에 도달한다고 광고하는데, 이는 해당 플랫폼이 모범 사례를 기본 제공(반응형 이미지, CDN 전송, 효율적인 템플릿 등)했기 때문
    • 이러한 경쟁 압력으로 개별 사이트 소유자가 성능 전문가가 아니더라도 사용하는 플랫폼이 내부적으로 개선을 추진

  • JavaScript 프레임워크(Chrome Aurora)

    • Chrome Aurora 팀은 인기 있는 JavaScript 프레임워크와 협력하기 위해 Chrome 내 특수 태스크포스로 2020년 중반에 출범
    • Aurora 멤버(Addy Osmani, Kara Erickson, Houssein Djirdeh 등)가 React/Next.js, Angular, Nuxt, Gatsby 등의 프레임워크 작성자와 긴밀히 협력하여 공통 병목 현상 식별 및 솔루션 제공
    • 이러한 협업으로 다음과 같은 기능 제공
      • Next.js의 next/script 컴포넌트(타사 스크립트를 메인 스레드 밖에서 더 효율적으로 로드)
      • Angular의 내장 NgOptimizedImage 지시문(이미지를 자동으로 지연 로딩하고 적절한 크기 및 우선순위 설정)
      • Nuxt의 Google Fonts 최적화 모듈
    • 영향이 상당함: 2022년 이러한 프레임워크로 구축된 사이트의 중앙값 Core Web Vitals 점수가 눈에 띄게 개선
      • Next.js 사이트의 CWV 통과율이 20.4%에서 27.3% 로
      • Angular가 7.6%에서 13.2% 로
      • Nuxt가 15.8%에서 20.2% 로 개선
    • 개별 성공 사례도 풍부
      • 전자상거래 사이트 Land's End가 Angular의 이미지 최적화를 채택한 후 모바일에서 LCP 40% 개선(랩 테스트)
      • CareerKarma가 Next.js의 개선된 스크립트 로딩을 사용하여 LCP 24% 감소

  • 실제 비즈니스 지표

    • 궁극적으로 더 나은 Core Web Vitals는 단지 Google을 만족시키기 위한 것이 아니라 실제 사용자 만족도 및 비즈니스 결과와 상관관계
    • 많은 회사가 CWV 개선을 사용자 참여와 연결하는 사례 연구 공유
      • 뉴스 사이트 Economic Times가 스크립트 처리를 최적화하여 INP를 개선하고 페이지뷰 42% 증가, 이탈률 49% 감소 달성
      • 여행 예약 사이트 RedBus가 INP를 개선하고 전환율 7% 증가 확인
      • 인도의 온라인 마켓플레이스 Meesho가 LCP를 6.9초에서 2.5초로 낮추어 이탈률 약 17% 감소 및 전환율 3% 증가 달성
    • 이러한 예시는 성능이 단순한 기술 지표가 아니라 사용자가 머물고, 더 많이 읽고, 더 많이 구매하는 것으로 전환됨을 강화
    • 이러한 성공 사례가 개발자와 제품 팀이 Web Vitals를 우선시하도록 더욱 동기 부여

전체 생태계 개선 성과

  • 브라우저 팀, 프레임워크 작성자, CMS 개발자, 수많은 개별 웹 개발자의 결합된 노력이 웹의 상태를 극적으로 개선
  • 명확하고 실행 가능한 지표를 확립함으로써 Core Web Vitals는 모두가 뒤따를 수 있는 공통 목표 창출
  • 중요한 점은 이것이 생태계를 독점 기술에 가두지 않고 개방형 표준과 데이터를 활용하여 달성되었다는 것
  • 2023년 기준 약 40%의 웹사이트(그리고 잘 관리되고 상업적인 사이트의 훨씬 더 높은 비율)가 이제 모든 Core Web Vitals 임계값을 통과하는 반면, 2020년 초에는 소수만이 통과
  • 완전히 통과하지 못한 사이트들도 일반적으로 예전보다 더 빠르고 매끄러워짐
  • 성능 인식 문화가 확산: 개발자들이 점점 더 CWV 지표를 모니터링(설문조사에 따르면 약 51%의 개발자가 Web Vitals를 적극적으로 추적하고 최적화)
  • Google은 이러한 속도 개선을 추진했음에도 불구하고 웹 플랫폼에 대한 개발자 만족도가 높게 유지되었다고 언급
    • 지침이 개발자를 절망으로 몰지 않고 달성 가능했음을 나타냄
    • 이러한 균형이 중요했으며, CWV 목표가 불가능하거나 도구가 불충분했다면 개발자들이 반발했을 수 있지만 대신 커뮤니티가 웹을 더 좋게 만드는 데 결집

지표의 진화: INP, Soft Navigation 등

  • Google은 처음부터 Core Web Vitals가 시간이 지남에 따라 진화할 것임을 인정
  • 2020년의 세 가지 지표 세트는 정적이거나 완전한 것으로 의도되지 않았음
  • 사용자 경험의 다른 측면(부드러운 스크롤링이나 페이지 후반부의 긴 작업 등)이 초기에 다루어지지 않았음
  • Chrome Web Platform 팀이 새로운 지표 및 기존 지표의 개선사항 연구 지속

Interaction to Next Paint(INP)

  • 원래 CWV의 명확한 격차는 첫 번째 클릭을 넘어선 상호작용성
  • FID는 첫 번째 입력 지연만 측정하여 첫인상에 중요하지만, 페이지가 나중에 더 많은 사용자 상호작용 중 응답하지 않을 수 있음
  • 이를 해결하기 위해 Annie Sullivan과 Michal Mocny 같은 Googler들이 INP 제안
    • 페이지의 모든(또는 적어도 많은) 사용자 상호작용을 살펴보고 일종의 최악의 경우(또는 98번째 백분위수) 지연을 보고
    • "사용자가 어느 시점에서든 페이지와 상호작용할 때 다음 프레임이 응답으로 페인팅될 때까지 얼마나 걸리는가?"라는 질문을 던지며 이벤트 처리 및 렌더링의 지연 시간 포착
  • INP는 2022년 실험적 필드 지표로 롤아웃되고 CrUX에 수집됨
  • 2023년 초까지 Google은 INP가 FID보다 전반적인 응답성 문제를 더 잘 예측한다는 것을 발견
  • 따라서 2024년 3월 INP가 FID를 Core Web Vital로 대체할 것이라고 발표
    • 이 변경 사항은 개발자에게 충분히 사전에 전달됨
    • Lighthouse 및 PageSpeed Insights 같은 도구가 INP를 표시하기 시작(그리고 "곧 CWV로 제공 예정"으로 표시)
    • Web.dev가 INP 개선에 대한 지침 제공, 이는 종종 일반적인 성능과 동일한 관행으로 귀결됨: 긴 작업 분해, 무거운 계산을 위한 웹 워커 사용 등
  • FID에서 INP로의 전환은 더 중요한 것을 더 잘 다루기 위해 지표를 반복하는 CWV 팀의 철학을 강조
    • 이 경우 페이지 로드뿐만 아니라 사용자 방문 전반에 걸친 일관된 응답성 보장

부드러움과 애니메이션

  • Chrome 팀이 조사한 또 다른 측면은 애니메이션 프레임 속도 및 스크롤 jank 같은 시각적 부드러움
  • 아직 공식 CWV 지표는 아니지만 여기에 진행 중인 작업 존재
  • Chrome 팀이 RUM 도구에 Smoothness 지표 제공(때로는 CrUX에서 "Jankiness"로 보고)하여 끊기는 애니메이션 같은 것을 정량화
  • 브라우저에 jank를 줄이기 위한 휴리스틱 도입
    • 예를 들어, 터치 이벤트가 디스플레이 프레임과 동기화되는 방식을 조정하여 Android에서 Chrome 자체 스크롤링의 부드러움을 두 배로 늘림(2023년 8월 Fast and Curious 게시물에서 자세히 설명)
  • 미래에 공식적인 "smoothness" Web Vital를 볼 수 있거나 INP가 특정 애니메이션 지연을 다루도록 확장될 가능성
  • 핵심은 Google이 이러한 측면을 인식하고 적극적으로 실험하고 있다는 것

Soft Navigation(SPA)

  • 초기 CWV 정의의 한 가지 한계는 전체 페이지 로드(소위 "하드 탐색")에 중점을 두었다는 것
  • 그러나 현대 Single-Page Application(SPA)은 종종 한 번 로드한 다음 전체 재로드 없이 콘텐츠와 경로를 동적으로 업데이트
  • 이러한 soft navigation(링크를 클릭해도 전체 브라우저 탐색을 수행하지 않고 JavaScript를 통해 콘텐츠가 변경됨)은 원래 구현에서 LCP 또는 CLS 측정에 포착되지 않음
    • 브라우저 관점에서는 여전히 동일한 페이지이므로 큰 DOM 업데이트가 새로운 LCP를 트리거하지 않음
  • 이는 SPA의 경우 개발자가 "페이지 전환"을 앱 내에서 평가하기 위해 사용자 지정 측정에 의존해야 했으며, CrUX(필드) 데이터도 해당 후속 탐색에 대해 블라인드 상태임을 의미(초기 페이지 로드 CWV만 기록됨)
  • 이를 수정하기 위해 Chrome이 Soft Navigation API 제안
    • Yoav Weiss가 이 작업에 대한 모든 공로
    • 2023년 중반 Chrome이 SPA 탐색을 휴리스틱으로 감지하는 실험 시작
    • 2025년 중반까지 Soft Navigations API에 대한 오리진 트라이얼 출시
  • Chrome 엔지니어 Barry Pollard와 Michal Mocny가 설명한 대로 _soft navigation_은 "JavaScript가 탐색을 가로채고(예: History API 또는 프레임워크 라우터를 통해) 전체 재로드 없이 history.pushState를 통해 URL을 업데이트하면서 기존 페이지의 콘텐츠를 업데이트하는 것"
  • 새로운 API를 통해 브라우저(및 개발자)가 이러한 이벤트를 표시하고 본질적으로 새 페이지 뷰처럼 취급 가능
  • 결정적으로 이를 통해 soft 경로 변경이 페이지 로드인 것처럼 SPA에서 Core Web Vitals 측정 가능
  • API를 사용하면 LCP 같은 지표가 soft navigation에서 재설정되고 새 뷰의 가장 큰 콘텐츠를 포착 가능(Performance Timeline의 "interaction-to-next-paint" 항목 개념 사용)
  • 마찬가지로 CLS는 탐색별로 분할 가능하고 INP는 현재 뷰와 연결 가능
  • 이는 클라이언트 측 라우팅 앱의 세계에 CWV를 가져오는 큰 진전(이는 매우 일반적)
  • 2025년 후반 현재 Soft Nav API는 트라이얼 중이며 개발자가 옵트인하고 피드백을 보낼 수 있음
  • 시간이 지남에 따라 Chrome이 soft nav 지표를 완전히 지원하고 필드 데이터(CrUX)도 이를 통합할 것으로 예상
  • 이러한 진화는 사용자 여정이 여러 단계로 구성되며 랜딩 페이지 로드만이 아니라는 것을 인정하며, 웹 플랫폼이 전체 여정을 측정하고 최적화해야 함

향후 진화

  • Google은 지표를 매년 계속 개선할 것이라고 표시
  • 새로운 임계값 같은 조정을 볼 수 있음
    • 예를 들어, 웹이 보편적으로 더 빨라지면 미래에 "좋은" LCP 목표가 2.5초보다 더 엄격해질 수 있음
    • 또는 명확한 격차가 나타나면 완전히 새로운 지표
  • 모든 추가 사항은 공개 프로세스를 거침(웹 성능 표준의 정의, 다른 브라우저 벤더와의 논의 등), INP의 경우처럼
  • Google은 시간이 지남에 따라 더 많은 페이지 경험 신호를 통합할 계획
    • 예를 들어, 사이트가 좋은 관행을 사용하는 경우 Chrome을 통해 "빠른 페이지" 배지를 표시하는 것과 같은 개인정보 보호 및 보안 실험
  • 그러나 Search 순위 컨텍스트에서 Google은 최근 메시징을 단순화
    • 2023년까지 개별 신호를 넘어서는 명시적인 "페이지 경험" 순위 부스터가 없을 것이라고 언급
    • 본질적으로 페이지 경험 고려 사항을 핵심 순위 알고리듬에 더 미묘하게 통합
    • 그러나 사이트 소유자 관점에서는 아무것도 변경되지 않음
    • 빠르고 응답성이 뛰어나고 안정적인 페이지는 사용자 만족도와 좋은 SEO 모두에 근본적으로 중요

정리

  • Core Web Vitals의 역사는 웹 플랫폼이 도전에 맞서는 이야기
    • 사용자 경험 품질이 측정 가능하고 보상받아야 한다는 통찰로 시작하여 지표, 브라우저, 검색 순위, 도구, 프레임워크, 호스팅 플랫폼을 건드리는 광범위한 운동으로 전환
    • 몇 년이라는 짧은 기간에 웹 성능 전반에 걸쳐 상당한 개선을 주도
    • 여정은 계속됨: SPA를 위한 soft navigation 측정 및 지표의 지속적인 개선 같은 향후 혁신으로 빠르고 즐거운 웹 경험에 대한 업계 약속이 여전히 강력
  • Core Web Vitals는 단지 지표 세트가 아니라 더 건강하고 빠르며 사용자 중심적인 웹을 위한 촉매로 입증
    • 많은 사람들의 협력으로 구축된 유산이며, 웹을 사용하는 모든 사람에게 이익이 될 유산