2026-07-31

웹사이트 애니메이션엔 GIF 대신 WebM: 페이지 속도 도구가 GIF를 지적하는 이유와 대안

제품 데모 루프, 애니메이션 로고, 혹은 누군가 GIF로 변환해 둔 화면 녹화 — 이런 애니메이션 GIF가 들어 있는 페이지를 PageSpeed Insights나 크롬 개발자도구의 Lighthouse 패널에 돌려보면, 영상 포맷을 쓰라는 경고를 볼 가능성이 크다. 이건 지나치게 까다로운 감사 도구의 트집이 아니다. 구글 자신의 web.dev 팀이 실제 전후 용량 비교 수치를 들어 똑같이 말하고 있는 내용이다. 그 비교가 실제로 무엇을 보여주는지, 이 감사가 정확히 무엇을 확인하는지, <video>를 GIF처럼 동작하게 만드는 마크업, 그리고 NearVid 같은 도구가 소스 클립을 페이지에 바로 쓸 수 있는 형태로 만드는 데 어디까지 도움이 되고 어디부터는 아닌지를 정리했다.

구글 자신의 실측 예시로 본 용량 차이

web.dev의 글은 막연한 경험칙 대신 구체적인 실제 예시 하나를 제시한다: 같은 짧은 클립이 애니메이션 GIF로는 3.7MB, MP4로 재인코딩하면 551KB, WebM으로 재인코딩하면 341KB가 된다 — WebM 버전만 놓고 보면 시각적으로 같은 내용인데도 GIF의 대략 10분의 1 크기다. 이건 이 글이 임의로 만들어낸 배율이 아니라, 구글 자신의 글에 실린 정확한 숫자다.

이런 차이가 나는 건 GIF 인코더가 못 만들어서가 아니라, 두 포맷이 애초에 무엇을 압축하도록 설계됐는지가 다르기 때문이다. H.264나 VP9 같은 영상 코덱은 대부분의 비트를 각 프레임을 인접 프레임으로부터 예측하는 데 쓴다 — 실제로 바뀐 픽셀만 다시 인코드하면 된다. GIF에는 그런 움직임 예측이 아예 없다. 프레임 단위로, 팔레트 수도 제한된 방식으로 설계됐고, 그것도 지금과는 완전히 다른 시절의 웹을 염두에 둔 설계다. GIF는 프레임 사이에 얼마나 적게 바뀌었든 상관없이 매 프레임마다 비트를 다시 써야 하고, 재생 시간이 조금만 길어져도 그 차이가 빠르게 누적된다.

페이지 속도 검사가 실제로 확인하는 것

"Use video formats for animated content"(애니메이션 콘텐츠에 영상 포맷을 사용하세요)라는 이 경고는 문서화된 Lighthouse 감사 항목이다 — Chrome for Developers 공식 문서에 따르면, 페이지에 있는 모든 애니메이션 GIF를 나열하고 각각을 변환했을 때 절약되는 예상 시간을 초 단위로 함께 보여준다. Lighthouse 13부터는 이 개별 감사 항목이 독립된 줄로 표시되는 대신 더 넓은 "Improve image delivery"(이미지 전달 개선) 인사이트로 통합됐다 — 하지만 밑바탕의 검사와 권고 내용은 그대로다: "네트워크 바이트를 아끼려면 애니메이션에는 GIF 대신 MPEG4/WebM 영상을 고려하라"는 것이다. 최근 Lighthouse 결과에서 예전 이름의 감사 항목이 안 보인다면, 그건 권고가 사라진 게 아니라 UI가 재구성된 것뿐이다.

영상을 진짜 GIF처럼 동작하게 만드는 마크업

애니메이션 GIF는 기본적으로 세 가지 동작을 갖는다: 자동 재생되고, 반복 재생되고, 소리가 없다. web.dev의 관련 코드랩에 따르면, <video> 엘리먼트가 이 세 가지를 재현하려면 네 가지 속성이 함께 필요하다 — autoplay loop muted playsinline. WebM과 MP4 소스를 둘 다 제공한다면 <source> 순서도 중요하다: 브라우저는 나열된 소스 중 어느 게 더 작거나 나은지 스스로 판단하지 않고, 재생 가능한 첫 번째 소스를 그냥 고른다. 그래서 더 작은 WebM 파일을 먼저 써야 그게 우선 선택된다. 영상이 모든 지표에서 무조건 GIF보다 낫다고 단정하기 전에 알아둘 만한 세부사항 하나: <img>는 페이지의 Largest Contentful Paint(LCP) 요소가 될 수 있지만, poster 속성이 없는 <video>는 보통 같은 방식으로 LCP 후보로 집계되지 않는다 — 이건 그 GIF가 페이지에서 정확히 무슨 역할을 하고 있었는지에 따라, 페이지의 LCP 점수가 실제로 무엇을 측정하고 있는지를 좋은 쪽으로든 나쁜 쪽으로든 바꿔놓을 수 있다는 뜻이다.

NearVid가 어디까지 도움이 되고, 어디부터는 아닌지

NearVid의 WebM 내보내기가 정확히 이 "GIF 대신 WebM을 만든다"의 절반을 담당한다: VP8 + Vorbis로, High/Medium/Low 품질 프리셋(2M/1M/500k 비트레이트)으로 브라우저 탭 안에서 전부 재인코딩하므로, GIF로 만들려던 원본 소스 클립 — 화면 녹화든, 렌더링해서 뽑은 애니메이션이든 — 이 변환을 위해 기기 밖으로 나갈 필요가 없다. 클립이 실제 루프에 필요한 길이보다 길다면 먼저 트림하면 된다. NearVid의 트림은 무손실 스트림 복사라서, WebM 재인코딩 전에 길이를 줄여도 추가 비용이 들지 않는다. 그리고 위 LCP 관련 세부사항이 poster 이미지를 제공하느냐에 달려 있으므로, NearVid의 프레임 추출 기능으로 같은 소스 클립의 원하는 시점에서 JPG나 PNG 한 장을 뽑아 그 poster로 쓸 수 있다 — 별도 도구나 별도 업로드 없이 말이다. 크롬이나 다른 크로미움 계열 브라우저에서 WebCodecs를 지원한다면, 같은 클립을 실제 MP4로도 내보내 WebM을 재생하지 못하는 브라우저를 위한 두 번째 <source>로 쓸 수 있다.

무엇을 하지 않는지도 정확히 짚어두자면: NearVid의 파일 선택창은 영상 파일만 받는다 — video/*와 정해진 영상 확장자 목록뿐, 이미 만들어진 .gif 파일은 받지 않는다. 이미 GIF로 내보내 버렸고 원본 클립이 남아 있지 않다면, NearVid가 그 GIF를 WebM으로 되돌려 주지는 못한다 — 이 워크플로 전체는 원본 영상을 여전히 갖고 있거나 다시 만들 수 있다는 걸 전제로 한다. 또한 NearVid는 <video> 마크업을 만들어 주거나 위 속성들을 대신 연결해 주지도 않는다 — WebM/MP4/포스터 이미지 파일을 만들어 줄 뿐, 그걸 페이지에 실제로 심는 HTML은 여전히 직접 작성해야 한다.

정직한 요약

이 글을 위해 지어낸 일반 법칙이 아니라 구글 자신의 숫자다: 같은 클립이 GIF로는 3.7MB, MP4로는 551KB, WebM으로는 341KB였다. 이걸 지적하는 Lighthouse 감사 항목은 실재하고 문서화돼 있으며, Lighthouse 13부터 이름은 재구성됐지만 여전히 작동한다. 이 이점을 실제로 얻으려면 이미 만들어 둔 GIF가 아니라 원본 영상에서부터 다시 시작해야 한다 — 필요한 길이로 트림하고, WebM으로(그리고 브라우저가 지원하면 대체 소스로 MP4까지) 변환하고, 필요하면 포스터 프레임을 하나 뽑은 뒤, autoplay loop muted playsinline 마크업은 직접 연결해야 한다. 변환 작업은 전부 기기 안에서 끝나지만, HTML을 연결하는 작업까지 대신해 주지는 않는다.