실적을 개선하고, Core Web Vitals 통과율을 높이며, 주요 비즈니스 측정항목을 개선하기 위해 YouTube 웹팀에서 취한 조치에 관한 사례 연구입니다.
Chrome팀은 종종 '더 나은 웹 구축'에 대해 이야기하지만 이것이 무엇을 의미할까요? 웹 환경은 빠르고 접근 가능해야 하며 사용자가 가장 필요할 때 기기 기능을 사용해야 합니다. dogfooding은 Google 문화의 일부이므로 Chrome팀은 YouTube와 협력하여 '더 나은 웹 구축'이라는 새로운 시리즈를 통해 그 과정에서 얻은 교훈을 공유하고 있습니다. 이 시리즈의 첫 번째 부분에서는 YouTube가 더 빠른 웹 환경을 구축한 방법을 자세히 살펴봅니다.
YouTube에서 실적은 동영상과 맞춤 동영상, 댓글과 같은 기타 콘텐츠가 웹페이지에 얼마나 빠르게 로드되는지와 관련이 있습니다. 실적은 YouTube가 검색, 플레이어 컨트롤, 좋아요, 공유와 같은 사용자 상호작용에 얼마나 빠르게 반응하는지로도 측정됩니다.
브라질, 인도, 인도네시아와 같이 성장하는 개발도상국 시장은 YouTube 모바일 웹에 중요합니다. 이 지역의 많은 사용자는 느린 기기와 제한된 네트워크 대역폭을 사용하고 있으므로 빠르고 원활한 환경을 보장하는 것이 중요합니다.
모든 사용자에게 포용적인 환경을 제공하기 위해 YouTube는 지연 로드 및 코드 현대화를 통해 Core Web Vitals와 같은 성능 측정항목을 개선하기 시작했습니다.
Core Web Vitals 개선
YouTube팀은 개선이 필요한 영역을 파악하기 위해 Chrome 사용자 환경 보고서 (CrUX)를 사용하여 현장에서 실제 사용자가 모바일에서 동영상 시청 및 검색 결과 페이지를 어떻게 이용하고 있는지 확인했습니다. 또한 Core Web Vitals 측정항목의 경우 최대 콘텐츠 페인트 (LCP) 측정항목이 4~6초 만에 클락하는 경우도 많다는 사실을 깨달았습니다. 이는 목표인 2.5초보다 훨씬 높았습니다.
개선이 필요한 영역을 파악하기 위해 Lighthouse를 사용하여 YouTube 보기 페이지를 감사한 결과, 콘텐츠가 포함된 첫 페인트(FCP)가 3.5초, 최대 콘텐츠 렌더링 시간(LCP)이 8.5초로 Lighthouse(실험실) 점수가 낮았습니다.
YouTube팀은 FCP 및 LCP를 최적화하기 위해 여러 실험을 진행한 결과 두 가지 중요한 사실을 발견했습니다.
가장 먼저, 동영상 플레이어를 양방향으로 만드는 스크립트 위로 동영상 플레이어의 HTML을 이동하면 실적을 개선할 수 있다는 사실을 발견했습니다. 실험실 테스트 결과, 이렇게 하면 FCP와 LCP를 모두 4.4초에서 1.1초로 개선할 수 있는 것으로 나타났습니다.
두 번째로 LCP는 동영상 스트림 자체의 프레임이 아닌
<video>요소 포스터 이미지만 고려한다는 사실이 확인되었습니다. YouTube는 전통적으로 동영상 재생이 시작될 때까지 걸리는 가장 빠른 시간을 기준으로 최적화해 왔기 때문에 LCP를 개선하기 위해 포스터 이미지 게재 속도도 최적화하기 시작했습니다. 포스터 이미지의 몇 가지 변형을 실험한 후 사용자 테스트에서 가장 높은 점수를 받은 이미지를 선택했습니다. 이 작업의 결과 FCP와 LCP가 모두 눈에 띄게 개선되었으며 필드 LCP는 4.6초에서 2.0초로 개선되었습니다.
이러한 최적화로 LCP가 개선되었지만, LCP의 목표인 페이지의 '기본 콘텐츠'가 로드된 시점을 사용자 관점에서 완전히 포착하지 못하는 것 같다는 의견이 있었습니다.
이러한 우려사항을 해결하기 위해 YouTube팀은 Chrome팀과 협력하여 사용 사례에 맞게 LCP 측정항목을 개선할 수 있는 방법을 모색했습니다. 몇 가지 옵션의 실행 가능성과 영향을 검토한 후 동영상 요소의 첫 번째 프레임의 페인트 시간을 LCP 후보로 고려하는 제안에 도달했습니다.
이 변경사항이 Chrome에 적용되면 YouTube팀은 LCP 최적화를 위한 작업을 계속할 예정입니다. 업데이트된 버전의 측정항목에서는 이러한 최적화가 실제 사용자 경험에 더 직접적인 영향을 미칠 것입니다.
지연 로드를 사용한 모듈화
YouTube 페이지에 조기 로드된 모듈이 많이 포함되어 있었습니다. 50개가 넘는 구성요소가 렌더링되는 방식을 최적화하기 위해 팀은 클라이언트에게 로드할 모듈을 알려주는 구성요소-JS 모듈 맵을 빌드했습니다. 구성요소를 지연형으로 표시하면 JS 모듈이 나중에 로드되므로 페이지의 초기 로드 시간과 클라이언트로 전송되는 사용되지 않는 JavaScript의 양이 줄어듭니다.
하지만 지연 로드를 구현한 후 지연 로드 구성요소와 종속 항목이 최적이 아닌 시간에 로드되는 폭포식 구조 효과를 발견했습니다.
이 문제를 해결하기 위해 팀은 뷰에 필요한 최소한의 구성요소 집합을 결정하고 단일 네트워크 요청으로 일괄 처리했습니다. 그 결과 페이지 속도가 개선되고 JavaScript 파싱 시간이 단축되었으며 궁극적으로 초기 렌더링 시간이 개선되었습니다.
구성요소 전반의 상태 관리
특히 오래된 기기에서 플레이어 컨트롤로 인해 YouTube에 성능 문제가 발생했습니다. 코드 분석 결과 사용자가 재생 속도 및 진행률과 같은 기능을 제어할 수 있는 플레이어가 시간이 지남에 따라 과도하게 구성화된 것으로 나타났습니다.
각 진행률 표시줄의 터치-움직 이벤트에서 두 번의 추가 스타일 재계산이 트리거되었고, 실험실의 성능 테스트를 실행하는 동안 21.17ms가 걸렸습니다. 시간이 지남에 따라 새로운 컨트롤이 추가되면서 분산된 제어 패턴으로 인해 순환 종속 항목과 메모리 누수가 발생하여 보기 페이지 성능에 부정적인 영향을 미치는 경우가 많았습니다.
분산 제어로 인한 문제를 해결하기 위해 팀은 모든 업데이트를 동기화하도록 플레이어 UI를 업데이트하여 기본적으로 플레이어를 하위 요소에 데이터를 전달하는 하나의 최상위 구성요소로 리팩터링했습니다. 이렇게 하면 상태 변경에 대해 하나의 UI 업데이트 (렌더링) 주기만 실행되어 체이닝 업데이트가 제거되었습니다. 새로운 플레이어 진행률 표시줄 터치 이동 이벤트에서는 JavaScript 실행 중에 스타일을 재계산하지 않으며, 이제 기존 플레이어 시간의 25% 만 필요합니다.
또한 이 코드 현대화로 인해 이전 기기의 시청 로드 시간이 개선되고, 재생 중단이 줄고, 심각하지 않은 오류 수가 감소하는 등 성능이 추가로 개선되었습니다.
결과 및 최적화
YouTube가 성능에 투자한 결과, 시청 페이지가 훨씬 더 빠르게 로드되고 YouTube 모바일 웹사이트 URL의 76% 가 이제 현장에서 Core Web Vitals 측정항목 기준을 통과합니다. 데스크톱에서 보기 페이지의 실험실 LCP가 약 4.6초에서 1.6초로 줄었습니다. 사이트의 상호작용 및 렌더링 성능, 특히 YouTube 동영상 플레이어의 JavaScript 실행에 소요되는 시간이 이전보다 최대 75% 감소했습니다.
지난 1년간 YouTube 웹의 성능이 개선되면서 시청 시간 및 일일 활성 사용자 등 비즈니스 측정항목도 개선되었습니다. 이러한 노력의 성공을 바탕으로 앞으로도 더 많은 최적화 방법을 모색할 계획입니다.
이 작업에 기여해 주신 Gilberto Cocchi, Lauren Usui, Benji Bear, Bo Aye, Bogdan Balas, Kenny Tran, Matthew Smith, Phil Harnish, Leena Sahoni, Jeremy Wagner, Philip Walton, Harleen Batra, YouTube 및 Chrome팀에 특별히 감사드립니다.