히어로 영상은 어떻게 LCP를 잡아먹나 - 4,737ms에서 시작한 개선 실측기

저희 홈에 배경 영상을 올린 날, LCP(가장 큰 콘텐츠 그리기)는 4,737ms로 측정됐습니다(2026-08-04 실측, PageSpeed Insights). 원인은 명확했습니다 - webm 1.6MB와 mp4 1.75MB짜리 히어로 영상이 첫 로드에서 포스터·폰트와 대역폭을 다투고 있었고, 페이지 총 전송량은 2.16MB, 모바일 점수는 76점이었습니다. 이 글은 영상 파일을 한 바이트도 건드리지 않고 이 수치를 개선해 간 과정의 기록입니다.

왜 영상이 LCP를 밀어낼까?

브라우저는 첫 화면을 그리는 데 필요한 리소스와 그렇지 않은 리소스를 알아서 완벽하게 구분해주지 않습니다. 히어로 영역의 <video>는 poster가 있어도 소스 다운로드를 일찍 시작할 수 있고, 그 다운로드가 정작 첫 화면을 그릴 포스터 이미지·웹폰트와 같은 회선을 나눠 씁니다. LCP 후보(저희 경우 히어로 포스터)가 뒤로 밀리는 구조입니다.

영상을 지우지 않고 무엇을 바꿀 수 있었나?

순서대로 세 가지였습니다. 첫째, 포스터를 JPG 62KB에서 WebP 34KB로 변환해 절반 가까이 줄이고, 프리로드(fetchPriority: high)로 최우선 수신하게 했습니다. 둘째, 영상의 preload를 metadata로 낮췄습니다. 여기까지 반영한 재측정에서 LCP는 4,476ms, 모바일 점수는 78점이었습니다 - 방향은 맞지만 병목의 본체(영상 대역폭 경쟁)는 남아 있었습니다.

셋째가 핵심이었습니다. 영상 엘리먼트 자체를 페이지 로드 완료 + 브라우저 유휴 시점에 지연 마운트하도록 바꿨습니다. 첫 페인트는 CSS 배경으로 깔린 WebP 포스터가 즉시 담당하고, 영상은 준비되는 대로 그 위를 덮으며 재생을 시작합니다. 사용자 눈에는 정지 화면이 잠깐 먼저 보일 뿐 디자인 차이가 없고, LCP 경쟁에서 3.4MB의 영상이 완전히 빠집니다.

이 방식의 한계는 무엇일까?

정직하게 적어두면, 측정에는 변동성이 있습니다(같은 상태에서도 수백 ms가 흔들립니다). 또 지연 마운트는 "영상이 움직이기 시작하는 시점"을 뒤로 미루는 트레이드오프이므로, 영상이 곧 콘텐츠인 페이지(예: 데모 영상)에는 적합하지 않습니다. 배경 연출용 영상일 때만 유효한 처방입니다. 이런 개선이 검색 순위나 AI 인용을 보장하지도 않습니다 - 저희가 보장할 수 있는 것은 측정 가능한 지표가 개선됐는지 여부뿐이고, 그래서 저희는 같은 도구로 전후를 다시 잽니다. 참고로 이 개선 기간에 사이트 전체 자체 진단 점수는 SEO 90→91, GEO 90→92로 함께 움직였습니다.

비슷한 증상(첫 화면에 영상·대형 이미지가 있는데 LCP가 2.5초를 넘는 경우)이 의심된다면 무료 진단에서 성능 항목을 실측해 보세요. 어떤 리소스가 경쟁하고 있는지부터 확인하는 것이 순서입니다.

자주 묻는 질문 (FAQ)

Q. 영상 화질을 낮추는 게 먼저 아닌가요?
재인코딩도 유효한 수단이지만 화질 트레이드오프가 생깁니다. 저희는 자산을 건드리지 않는 로드 순서 개선(포스터 우선·지연 마운트)을 먼저 적용하고, 그래도 부족할 때 재인코딩을 검토하는 순서를 권합니다.

Q. 지연 마운트를 하면 SEO에 불이익이 없나요?
배경 영상은 콘텐츠 텍스트가 아니므로 색인에 불이익이 없습니다. 오히려 LCP 개선은 Core Web Vitals 신호에 긍정적입니다. 다만 본문 콘텐츠 자체를 지연 로드하는 것은 다른 문제이니 구분해야 합니다.

Q. LCP 수치는 어디서 확인하나요?
PageSpeed Insights에서 URL을 넣으면 실측(필드)과 실험실(랩) 수치를 함께 볼 수 있습니다. 이 글의 수치는 2026-08-04 실측 기준입니다.