실적을 개선하고 코어 웹 바이탈 통과율을 높이며 주요 비즈니스 측정항목을 높이기 위해 YouTube 웹팀이 변경한 우수사례입니다.
Chrome팀에서 '더 나은 웹 구축'이란 이야기를 나누는 경우가 많지만 그것이 의미하는 바는 무엇일까요? 웹 환경은 빠르고 액세스할 수 있어야 하며 사용자에게 가장 필요한 순간에 기기 기능을 사용해야 합니다. Dogfood는 Google 문화의 일부이므로 Chrome팀은 YouTube와 협력하여 '더 나은 웹 만들기'라는 새로운 시리즈를 통해 얻은 교훈을 공유했습니다. 시리즈의 1부에서는 YouTube가 어떻게 보다 빠른 웹 환경을 구축했는지 자세히 살펴봅니다.
더 빠른 웹 구축
YouTube에서 성능은 동영상과 기타 콘텐츠(예: 추천, 댓글)가 웹페이지에 로드되는 속도를 나타냅니다. 검색, 플레이어 컨트롤, 좋아요, 공유와 같은 사용자 상호작용에 YouTube가 얼마나 빠르게 반응하는지에 따라 실적도 측정됩니다.
YouTube 모바일 웹은 브라질, 인도, 인도네시아 등 개발도상국 시장을 키워 나가는 것이 중요합니다. 이러한 지역의 많은 사용자가 기기가 느리고 네트워크 대역폭이 제한되므로 빠르고 원활한 환경을 보장하는 것이 중요합니다.
모든 사용자에게 포용적인 환경을 제공하기 위해 YouTube는 지연 로드와 코드 현대화를 통해 코어 웹 바이탈과 같은 성능 측정항목을 개선하기 시작했습니다.
코어 웹 바이탈 개선
개선 영역을 파악하기 위해 YouTube팀은 Chrome 사용자 환경 보고서 (CrUX)를 사용하여 실제 사용자가 모바일에서 동영상 보기 및 검색결과 페이지를 경험하는 현장을 파악했습니다. 최대 콘텐츠 렌더링 시간 (LCP) 측정항목은 경우에 따라 4~6초로 기록되어 Core Web Vitals 측정항목을 개선할 여지가 많다는 것을 깨달았습니다. 이는 목표인 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를 개선하기 위해 포스터 이미지를 얼마나 빠르게 게재할 수 있는지도 최적화하기 시작했습니다. 포스터 이미지를 다양하게 실험해 사용자 테스트에서 가장 높은 점수를 받은 포스터를 선택했습니다. 이 작업의 결과, 필드 LCP가 4.6초에서 2.0초로 개선되는 등 FCP와 LCP 모두 현저한 개선을 보였습니다.
이러한 최적화를 통해 LCP가 개선되었지만, 팀에서는 LCP 측정항목의 현재 정의가 페이지의 '기본 콘텐츠'가 로드되었을 때(LCP의 목표)를 완전히 포착하지 못한다고 생각했습니다.
이러한 우려를 해결하기 위해 YouTube팀은 Chrome팀 구성원과 협력하여 LCP 측정항목을 개선하여 사용 사례를 해결할 방법을 모색했습니다. 팀은 몇 가지 옵션의 실행 가능성과 영향을 고려한 후 동영상 요소의 첫 번째 프레임의 페인트 시간을 LCP 후보로 고려하기 위한 제안에 도달했습니다.
이 변경사항이 Chrome에 적용되면 YouTube팀은 LCP를 위한 최적화 작업을 계속 진행하게 되어 기쁘게 생각합니다. 또한 측정항목이 업데이트되면 이러한 최적화가 실제 사용자 환경에 보다 직접적인 영향을 미칠 것입니다.
지연 로드를 사용한 모듈화
YouTube 페이지에는 로드가 빠른 모듈이 많은 모듈이 있습니다. 50개 이상의 구성요소가 렌더링되는 방식을 최적화하기 위해 팀은 클라이언트에게 로드할 모듈을 알려주는 구성요소를 JS 모듈 맵으로 빌드했습니다. 구성요소를 지연으로 표시하면 JS 모듈이 나중에 로드되어 페이지의 초기 로드 시간과 클라이언트에 전송되는 미사용 자바스크립트의 양이 줄어듭니다.
그러나 지연 로드를 구현한 후 팀은 지연 로드된 구성요소와 종속 항목이 최적화되지 않은 시간에 로드되는 폭포식 구조 효과를 발견했습니다.
이 문제를 해결하기 위해 팀은 뷰에 필요한 최소한의 구성요소 집합을 결정하여 단일 네트워크 요청으로 일괄 처리했습니다. 그 결과 페이지 속도가 개선되고, JavaScript 파싱 시간이 단축되었으며, 초기 렌더링 시간이 단축되었습니다.
구성요소 간 상태 관리
YouTube는 특히 오래된 기기에서 재생 컨트롤로 인해 성능 문제가 발생했습니다. 코드 분석에 따르면 사용자가 재생 속도 및 진행률과 같은 기능을 제어할 수 있는 플레이어가 시간이 지남에 따라 과잉 구성요소화되었습니다.
각 진행률 표시줄 터치 이동 이벤트는 두 번의 추가 스타일 재계산을 트리거했으며 실험실의 성능 테스트 실행 중에 21.17ms가 소요되었습니다. 시간이 지남에 따라 새로운 컨트롤이 추가됨에 따라 분산된 제어 패턴으로 인해 종종 순환 종속 항목 및 메모리 누수가 발생하여 보기 페이지 성능에 부정적인 영향을 미칩니다.
분산 제어로 인한 문제를 해결하기 위해 팀은 모든 업데이트를 동기화하도록 플레이어 UI를 업데이트하여 근본적으로 플레이어를 하위 요소에 전달하는 하나의 최상위 구성요소로 리팩터링했습니다. 이로 인해 상태 변경에 관해 하나의 UI 업데이트 (렌더링) 주기만 보장되어 연속된 업데이트가 제거되었습니다. 새 플레이어 진행률 표시줄 터치 이동 이벤트는 JavaScript 실행 중에 스타일을 다시 계산하지 않으며 이제 기존 플레이어에 비해 25% 만 사용하면 됩니다.
이러한 코드 현대화로 인해 이전 기기의 시청 로드 시간 개선, 포기된 재생 감소, 심각하지 않은 오류 수 감소와 같은 추가적인 성능 개선도 이루어졌습니다.
결론
YouTube가 실적에 투자한 결과, YouTube 모바일 웹사이트 URL의 76% 가 해당 분야의 Core Web Vitals 측정항목 기준을 통과하는 등 보기 페이지의 로드 속도가 훨씬 빨라졌습니다. 데스크톱에서 보기 페이지의 실습 LCP를 약 4.6초에서 1.6초로 줄였습니다. 특히 YouTube 동영상 플레이어에서 발생한 사이트의 상호작용 및 렌더링 성능에서 자바스크립트 실행 시간이 전보다 최대 75% 단축되었습니다.
작년에 YouTube 웹 실적이 향상되면서 시청 시간 및 일일 활성 사용자 수를 비롯한 비즈니스 측정항목도 개선되었습니다. 이러한 노력의 성공을 바탕으로 앞으로 더욱 다양한 최적화 방법을 모색할 계획입니다.
본 시리즈의 2부인 '접근성 높은 웹 구축'에서는 YouTube가 어떻게 스크린 리더 사용자가 더 쉽게 자사 웹사이트에 액세스할 수 있도록 만들었는지 알아봅니다.
이 작업에 기여해 주신 Gilberto Cocchi, 로렌 우스이, 벤지 베어, 보 아예, 보그단 발라스, 케니 트랜, 매튜 스미스, 필 하니시, 리나 사호니, 제레미 와그너, 필립 월튼, 할린 바트라와 YouTube팀, Chrome팀 모두에게 특별한 감사의 말씀을 전합니다.