웹에서 비디오 재생: 비디오의 현재 상태(1부)

장치와 네트워크가 더 빨라지고 비디오 콘텐츠를 처리할 수 있게 되면서 웹에서 비디오 사용이 증가하고 있습니다. 연구에 따르면 동영상이 있는 사이트는 참여도가 80% 증가합니다. 동영상이 있는 전자상거래 사이트는 동영상이 없는 사이트보다 전환율이 더 높습니다.

그러나 비디오를 추가하려면 비용이 발생할 수 있습니다. 비디오(더 큰 파일)는 페이지 로드 시간을 추가하고 성능 연구에 따르면 느린 페이지는 고객 참여 및 전환율을 낮추는 반대 효과를 나타냅니다. 이 기사에서는 웹에서 성능과 비디오 재생의 균형을 유지하기 위한 중요한 메트릭을 조사하고, 오늘날 비디오가 어떻게 사용되는지 살펴보고, 웹에서 비디오를 제공하는 모범 사례를 제공합니다.

고객 만족도를 높이는 첫 번째 단계 중 하나 는 페이지 로드 시간을 단축하는 것 입니다. Google은 로드하는 데 3초 이상 걸리는 모바일 페이지가 잠재고객의 53%를 포기하는 것으로 나타났습니다. 다른 연구에 따르면 사이트 성능을 개선하면 사용량과 매출이 증가합니다.

웹 사이트에 비디오를 추가하면 참여가 증가하지만 로드 시간이 크게 느려질 수도 있으므로 사이트에 비디오를 추가하는 것과 로드 시간에 너무 큰 영향을 주지 않는 것 사이에서 균형을 찾아야 합니다.

추천 자료 : 2018년 프론트엔드 성능 체크리스트 [PDF, Apple Pages]

오늘날 웹상의 비디오

오늘 웹상의 비디오 상태를 조사하기 위해 HTTP 아카이브의 데이터를 사용하겠습니다. HTTP 아카이브는 WebPageTest를 사용하여 2주마다 120만 모바일 및 데스크톱 웹사이트의 성능을 스캔한 다음 Google BigQuery에 데이터를 저장합니다.

일반적으로 각 도메인의 메인 페이지만 확인됩니다( www.cnn.com 은 실행되지만 www.cnn.com/politics 는 실행되지 않음). 이 데이터는 웹에서 비디오 사용이 웹사이트 성능에 어떤 영향을 미치는지 이해하는 데 도움이 될 수 있습니다. 모바일 테스트는 3G 인터넷 연결(1.6MBPS 아래로, 768KBPS 위로, 300ms RTT)로 에뮬레이트된 Motorola G4에서 실행되고 데스크톱 테스트는 케이블 연결(5MBPS 아래로, 1MBPS 위로, 28ms RTT)에서 Chrome을 실행합니다. 2018년 8월 1일부터 데이터 세트를 사용하겠습니다.

비디오를 다운로드하는 사이트

비디오가 있는 사이트를 연구하는 첫 번째 단계로 페이지가 로드될 때 비디오 파일을 다운로드하는 사이트를 살펴봐야 합니다. HTTP 아카이브 데이터 세트(모든 모바일 사이트의 3%, 모든 데스크톱 사이트의 4.5%)에 비디오 파일 다운로드가 있는 35,000개의 모바일 사이트와 55,000개의 데스크톱 사이트가 있습니다. 데스크톱과 모바일을 비교하면 이러한 사이트 중 30,000개에 모바일과 데스크톱 모두에 동영상이 있는 것으로 나타났습니다(모바일에는 최대 5,800개 사이트가 데스크톱에 동영상이 표시되지 않음).

비디오가 포함된 중앙값 모바일 페이지의 무게는 7MB입니다(중앙값 모바일 사이트에서 찾은 1.2MB보다 583% 더 큼). 이 증가는 비디오만으로는 완전히 설명되지 않습니다(2.5MB). 비디오가 있는 사이트는 기능이 더 풍부하고 시각적으로 매력적인 경향이 있기 때문에 더 많은 이미지(중앙 사이트에는 1MB 이상 더 있음), CSS 및 Javascript도 사용합니다. 아래 표는 또한 비디오가 있는 사이트의 평균 SpeedIndex(콘텐츠가 화면에 나타나는 속도 측정)가 일반적인 모바일 사이트보다 3.7초 느리고 로드하는 데 무려 11.5초가 걸린다는 것을 보여줍니다.

이것은 더 인터랙티브하고 비디오 콘텐츠가 있는 사이트가 비디오 없이 해당 사이트를 로드하는 데 (평균) 더 오래 걸린다는 것을 분명히 보여줍니다. 그러나 비디오 전송 속도를 높일 수 있습니까? 우리는 가까운 데이터에서 또 무엇을 배울 수 있습니까?

비디오 호스팅

비디오 전송을 검토할 때 파일이 CDN 또는 비디오 제공업체에서 제공되고 있습니까, 아니면 개발자가 자체 서버에서 비디오를 호스팅하고 있습니까? 모바일에서 제공되는 비디오의 도메인을 조사하여 12,163개의 도메인이 비디오를 제공하는 데 사용된다는 것을 알게 되었으며, 이는 사이트의 ~49%가 자체 비디오 파일을 제공하고 있음을 나타냅니다. 주파수별로 도메인의 순위를 매기면 가장 일반적인 비디오 호스팅 솔루션을 결정할 수 있습니다.

상위 CDN 및 도메인 Facebook, Akamai, Google, Cloudinary, AWS 및 Cloudfront가 선두를 달리고 있는데 이는 놀라운 일이 아닙니다. 그러나 YouTube와 Vimeo가 가장 인기 있는 동영상 공유 사이트이기 때문에 목록에서 가장 아래에 있는 것을 보는 것은 흥미로운 일입니다.

YouTube, Vimeo 및 Facebook 동영상 전송을 살펴보겠습니다.

YouTube 동영상 수

기본적으로 YouTube 비디오가 포함된 페이지는 실제로 비디오 파일을 다운로드하지 않습니다. 스크립트와 자리 표시자 이미지만 있으므로 비디오 다운로드가 있는 사이트를 검색하는 쿼리에 표시되지 않습니다. YouTube 비디오 플레이어용 Javascript 다운로드 중 하나는 www-embed-player.js 입니다. 이 파일을 검색하면 66,647 모바일 사이트에서 69k 인스턴스를 찾습니다. 이 사이트의 평균 SpeedIndex는 10,700이고 데이터 사용량은 3.31MB로 비디오가 다운로드된 사이트보다 낫지만 비디오가 전혀 없는 사이트보다는 여전히 느립니다. 데이터의 증가는 더 많은 이미지와 자바스크립트와 직접적으로 연관됩니다(아래 참조).

Vimeo 동영상 수

비디오 재생용 HTTP 아카이브에 Vimeo 비디오에 대한 14,148개의 요청이 있습니다. player.js 파일에 대한 요청은 5,848개뿐입니다( https://f.vimeocdn.com/p/3.2.0/js/player.js 형식 — 한 페이지에 많은 비디오가 있거나 아마도 비디오 플레이어 파일의 다른 위치 HTTP 아카이브에는 17가지 다른 버전의 플레이어가 있으며 가장 널리 사용되는 버전은 3.1.5 및 3.1.4입니다.

Vimeo 라이브러리에 대한 성능 향상은 없는 것으로 보입니다. 모든 페이지의 로드 시간이 비슷합니다.

참고 : YouTube 의 경우 www-embed-player.js 를 사용 하거나 Vimeo의 경우 https://f.vimeocdn.com/p/*/js/player.js 를 사용하는 것이 캐시가 깨끗한 브라우저에 좋은 지문이지만 고객이 이전에 포함된 비디오가 있는 사이트를 탐색한 경우 이 파일은 이미 브라우저 캐시에 있을 수 있으므로 다시 요청하지 않습니다. 그러나 Andy Davies가 최근에 언급했듯이 이것은 안전한 가정이 아닙니다.

페이스북 동영상 수

HTTP 아카이브 데이터에서 모든 비디오 요청의 67%가 Facebook의 CDN에서 온 것이 놀랍습니다. Chrome에서 타사 Facebook 위젯은 위젯 내부에 게시된 모든 비디오의 30%를 다운로드하는 것으로 나타났습니다(이 효과는 Safari 또는 Firefox에서는 발생하지 않습니다.). 몇 줄의 코드로 추가된 타사 위젯이 HTTP 아카이브에 표시되는 전체 비디오의 57%를 차지하는 것으로 나타났습니다.

비디오 파일 형식

테스트한 페이지의 대부분의 비디오는 Mp4입니다. 다운로드한 모든 비디오(Facebook의 비디오 제외)를 보면 다음과 같은 보기가 표시됩니다.

확장자가 없는 파일 중 10k는 googlevideo.com 파일입니다.

이 파일에 대해 무엇을 알 수 있습니까? 전달되는 콘텐츠에 대해 자세히 알아보기 위해 각 파일 형식을 살펴보겠습니다.

FFPROBE를 사용하여 34,000개의 고유한 MP4 파일을 쿼리하고 14,700개의 비디오에 대한 데이터를 얻었습니다(많은 비디오가 HTTP 아카이브 캡처에서 분석까지 3주 동안 변경되거나 제거되었습니다).

MP4 비디오 데이터

데이터 세트의 14.7k 비디오 중 8,564개에 오디오 트랙이 있습니다(58%). 자동 재생되는 짧은 동영상이나 백그라운드에서 재생되는 동영상에는 오디오가 필요하지 않으므로 오디오 트랙을 제거하면 동영상의 파일 크기를 줄이고 전송 속도를 높일 수 있습니다.

비디오를 빠르게 다운로드하기 위해 다음으로 가장 중요한 측면은 치수입니다. 크기가 클수록(비디오의 경우 고려해야 할 세 가지 차원이 있습니다: width × height × time ), 비디오 파일은 더 커집니다.

MP4 비디오 길이

연구된 14k 비디오의 대부분은 짧습니다. 중앙값(50번째 백분위수) 길이는 21초입니다. 그러나 조사된 비디오의 10%는 길이가 2분을 초과합니다. 물론 여기에서의 사용 사례는 나누어지지만 짧은 비디오 루프 또는 배경 비디오의 경우 — 더 짧은 비디오는 더 적은 데이터를 사용하고 더 빠르게 다운로드합니다.

MP4 비디오 너비 및 높이

화면의 비디오 크기는 각 프레임이 사용해야 하는 픽셀 수를 결정합니다. 아래 차트는 모바일 장치에 제공되는 다양한 비디오 너비를 보여줍니다. (참고로 Moto G4의 화면 크기는 1080×1920이며 페이지는 모두 세로 모드로 표시됩니다.)

데이터에서 알 수 있듯이 가장 많이 사용되는 두 개의 비디오 너비는 G4 화면(세로 모드로 유지했을 때)보다 훨씬 큽니다. 전체 동영상의 49%는 너비가 1080픽셀보다 큰 너비로 제공됩니다. 새로운 Android Go 기기인 Alcatel 1x는 480×960 픽셀 화면을 가지고 있습니다. 샘플 세트에 제공된 비디오의 77%는 너비가 480픽셀보다 큽니다.

비디오의 크기가 줄어들면 파일 크기도 줄어듭니다(따라서 비디오를 제공하는 데 걸리는 시간도). 이것이 비디오 크기를 조정하는 주된 이유입니다.

이 동영상이 왜 이렇게 큽니까? 모바일과 데스크톱에서 제공되는 동영상의 상관 관계를 파악하면 모바일에서 제공되는 동영상의 18%가 데스크톱에서 제공되는 것과 동일한 동영상임을 알 수 있습니다. 이것은 몇 년 전 반응형 이미지로 이미지에 대해 해결된 '문제'입니다. 다양한 크기의 동영상을 다양한 크기의 기기에 제공함으로써 아름다운 동영상이 기기에 적합한 크기와 크기로 제공되도록 할 수 있습니다.

MP4 비디오 비트레이트

장치에 전달되는 비디오의 비트 전송률은 비디오가 얼마나 잘 재생되는지에 큰 영향을 미칩니다. HTTP 아카이브 테스트는 3G 연결에서 1.6MBPS 다운로드 속도로 실행됩니다. 지연 없이 재생하려면 다운로드가 재생보다 빨라야 합니다. 사용 가능한 비트 전송률의 80%를 비디오 파일(1.3MBPS)에 제공하겠습니다. 샘플 세트에 있는 비디오의 47%는 1.3MBPS 이상의 비트 전송률을 가지고 있습니다. 즉, 이러한 비디오가 3G 연결에서 재생될 때 지연될 가능성이 더 높아 고객이 불만을 갖게 됩니다. 동영상의 27%는 2.5MBPS보다 높은 비트 전송률, 10%는 5MBPS보다 높은 전송률, 모바일 장치에 제공되는 동영상 중 35%는 10MBPS 이상의 비트 전송률을 가지고 있습니다. 이러한 대용량 비디오는 고정 또는 모바일과 같은 많은 연결에서 지연 없이 재생될 가능성이 낮습니다.

비트 전송률을 높이는 요인

더 큰 비디오는 더 큰 비트 전송률을 전달하는 경향이 있습니다. 더 큰 차원의 비디오는 장치의 추가 픽셀을 채우는 데 더 많은 데이터가 필요하기 때문입니다. 너비에 대한 각 비디오의 비트 전송률을 상호 참조하면 이를 확인할 수 있습니다. 너비가 1280(주황색) 및 1920(회색)인 비디오는 비트 전송률 분포가 훨씬 더 넓습니다(차트 오른쪽에 더 많은 데이터 포인트). 노란색으로 표시된 열은 너비가 1920이고 비트 전송률이 10-11MBPS인 136개의 비디오를 나타냅니다.

1.6MBPS 이상의 비디오만 시각화하면 더 높은 화면 해상도(1280 및 1920)가 더 높은 비트 전송률 비디오를 담당한다는 것이 분명해집니다.

MP4: HTTP 대 HTTPS

HTTP2는 서버당 하나의 연결만 필요한 다중 연결로 콘텐츠 전달을 재정의했습니다. 비디오와 같은 대용량 파일의 경우 HTTP2가 콘텐츠 전달에 의미 있는 개선을 제공합니까? HTTP 아카이브의 통계를 보면 다음과 같습니다.

116k Facebook 비디오(모두 HTTP2를 통해 전송됨)를 생략하면 HTTP 1.1과 HTTP2가 약 50:50으로 분할된다는 것을 알 수 있습니다. 그러나 HTTP1.1은 HTTPS를 사용할 수 있으며 HTTPS 사용을 필터링하면 비디오 스트림의 81%가 HTTPS를 통해 전송되고 HTTP2는 HTTPS1.1보다 약간 더 많이 사용됩니다(41%:36%).

보시다시피 HTTP와 HTTP2 비디오 전송 속도를 비교하는 작업이 진행 중입니다.

HLS 비디오 스트리밍

적응형 비트 전송률을 사용한 비디오 스트리밍은 최종 사용자에게 비디오를 제공하는 이상적인 방법입니다. 각 비디오의 여러 버전은 다양한 크기와 비트 전송률로 제작됩니다. 사용 가능한 스트림 목록이 재생 장치에 표시되고 장치의 비디오 플레이어는 장치 화면의 크기와 사용 가능한 네트워크 조건에 따라 가장 적합한 스트림을 선택할 수 있습니다. 내가 조사한 HTTP 아카이브 데이터 세트에는 1,065개의 매니페스트 파일(및 14k 비디오 스트림 파일)이 있습니다.

비디오 스트림 재생

비디오 스트리밍의 한 가지 핵심 메트릭은 비디오가 가능한 한 빨리 시작되도록 하는 것입니다. 매니페스트 파일에는 사용 가능한 스트림 목록이 있지만 플레이어는 재생 시작 시 네트워크의 사용 가능한 대역폭을 알지 못합니다. 스트리밍을 시작하려면 플레이어가 스트림을 선택해야 하므로 일반적으로 목록에서 첫 번째 스트림을 선택합니다. 빠른 비디오 시작을 용이하게 하려면 매니페스트 파일의 맨 위에 올바른 스트림을 배치하는 것이 중요합니다.

참고 : Chrome Network Info API를 활용하여 즉시 매니페스트 파일을 생성하는 것은 시작할 때 비디오 콘텐츠를 빠르게 최적화하는 좋은 방법일 수 있습니다.

비디오가 빨리 시작되도록 하는 한 가지 방법은 다운로드가 가장 빠르기 때문에 가장 낮은 품질의 비디오 세그먼트로 시작하는 것입니다. 초기 비디오 품질이 픽셀화될 수 있지만 플레이어가 네트워크 품질을 더 잘 이해함에 따라 더 적절한(더 높은 품질의) 비디오 스트림으로 빠르게 조정할 수 있습니다. 이를 염두에 두고 HTTP 아카이브의 초기 스트림 비트 전송률을 살펴보겠습니다.

위 차트의 빨간색 선은 1.5MBPS를 나타냅니다(모바일 테스트는 1.6MBPS에서 실행되며 비디오 콘텐츠만 다운로드되는 것이 아닙니다). 모든 스트림의 30.5%(줄 왼쪽에 있는 모든 항목)가 1.5MBPS보다 높은 초기 비트 전송률(따라서 3G 연결에서 재생될 가능성이 낮음)에서 17%가 2MBPS 이상으로 시작하는 것을 볼 수 있습니다.

비디오 다운로드가 비디오의 실제 재생보다 느리면 어떻게 될까요? 처음에 플레이어는 (너무) 큰 비트 전송률 파일을 다운로드하려고 시도하지만 다운로드 속도를 기반으로 문제를 인식합니다. 그러면 플레이어가 더 낮은 비트 전송률 비디오 다운로드로 전환하여 다운로드가 재생보다 빠릅니다. 문제는 초기 다운로드 시도에 시간이 걸리고 동영상 재생 시작을 지연시키면 고객 이탈로 이어진다는 점이다.

또한 .ts 파일(비디오 콘텐츠가 있는 파일)의 가장 일반적인 비트 전송률을 보고 모바일에서 다운로드되는 비트 전송률을 확인할 수 있습니다. 이 데이터에는 초기 비트 전송률과 WebPageTest 실행 중에 다운로드된 모든 후속 파일이 포함됩니다.

비디오 스트리밍 비트 전송률의 두 가지 주요 그룹(100-300KBPS 및 300-1,000MBPS의 더 넓은 피크)을 볼 수 있습니다. 네트워크 속도가 1.6MBPS로 제한되어 있는 경우 스트림이 나타날 것으로 예상되는 위치입니다.

데이터를 데스크톱과 비교하면 모바일은 낮은 비트 전송률에서 분명히 더 높고 데스크톱 스트림은 모바일에서 볼 수 없는 500-600 및 800-900KBPS 범위에서 높은 피크를 보입니다.

관찰된 초기 비트 전송률(파란색)을 다운로드한 실제 파일과 비교할 때 모바일의 경우 일반적으로 스트림 재생 중에 비트 전송률이 감소한다는 것이 매우 분명합니다. 이는 비디오 스트림의 초기 비트 전송률을 낮추면 비디오 시작 성능을 개선하고 지연을 방지할 수 있음을 나타냅니다. 비디오의 초기 재생에서. 데스크탑 비디오도 감소하는 것처럼 보이지만 일부 비디오는 더 높은 재생 속도로 이동할 수도 있습니다.

결론

웹의 비디오 콘텐츠는 고객 참여와 만족도를 높입니다. 빠르게 로드되는 페이지는 동일한 효과를 가집니다. 웹사이트에 비디오를 추가하면 페이지 렌더링 시간이 느려지므로 전체 페이지 로드와 비디오 콘텐츠 간의 균형이 필요합니다. 비디오 콘텐츠의 크기를 줄이려면 모바일 장치 크기에 적합한 크기의 버전이 있는지 확인하고 가능하면 더 짧은 비디오를 사용하십시오.

비디오 재생이 필수가 아닌 경우 YouTube 및 Vimeo 경로를 따르십시오. 재생 준비에 필요한 모든 부분을 다운로드하되 사용자가 재생을 누를 때까지 비디오 세그먼트를 실제로 다운로드하지 마십시오. 마지막으로 — 비디오를 스트리밍하는 경우 — 가장 낮은 품질 설정으로 시작하여 빠른 비디오 재생을 보장합니다.

비디오에 대한 다음 게시물에서는 이러한 일반적인 결과를 가져와 예제를 통해 잠재적인 문제를 해결하는 방법에 대해 더 깊이 파고들 것입니다.