이미지 최적화, 포맷만 바꾸면 LCP가 좋아질까?

결론부터 말하면 아니다. 포맷 변환은 이미지 최적화의 한 축일 뿐이고, 표시 크기·요청 우선순위·디코드 비용을 같이 조정하지 않으면 LCP 개선폭은 제한적이다. 파일 크기가 줄어도 네트워크 병목이나 디코드 지연이 남아 있으면 체감 속도는 크게 달라지지 않는다.

이 글의 핵심:

  • 사진류는 AVIF/WebP, 로고·아이콘은 SVG로 유형별 기본값을 분리해 판단한다.
  • 포맷보다 먼저 확인할 것은 표시 크기(srcset/sizes)와 LCP 이미지의 요청 우선순위다.
  • 파일 크기만 기록하지 말고 다운로드 시작·응답 완료·디코드 시간·LCP를 함께 측정한다.
  • 이미지보다 렌더 차단 CSS·동기 스크립트가 먼저 막고 있을 수 있어 워터폴부터 본다.
  • 적용 순서는 측정 → 가장 큰 병목 → 재측정이며, 변경은 커밋 단위로 나눠 효과를 분리한다.

판교에서 커머스 프로덕트 페이지를 맡으면서 처음 받은 요청이 "상품 이미지 로딩이 느리다"였다. JPEG를 WebP로 바꾸면 끝날 줄 알았는데, 실제로는 LCP가 3.9초에서 3.6초로만 줄었다. 뜯어보니 이미지 자체보다 <head>의 동기 스크립트와 1,400개 이미지 중 일부에 width/height가 빠져 있던 게 더 큰 원인이었다. 그 이후로 이미지 최적화를 "포맷 교체"가 아니라 표시 크기·우선순위·압축·렌더링 순서를 분리해서 보는 체크리스트로 바꿔 쓰고 있다.

AVIF·WebP·JPEG XL, 같은 사진인데 왜 용량 차이가 날까?

원인은 압축 알고리즘과 색 공간 처리 방식이 다르기 때문이다. DebugBear가 공개한 990KB 원본 사진 벤치마크에서 JPEG XL은 472KB, AVIF는 507KB, WebP는 700KB로 나타났다DebugBear 벤치마크. 같은 사진 한 장을 기준으로 포맷별 용량이 1.5배 가까이 벌어진 셈이다.

다만 이 숫자를 그대로 "JPEG XL이 제일 작다"로 일반화하면 곤란하다. 같은 자료에서도 로고나 투명 배경 이미지에서는 AVIF가 더 작게 나왔다. 사진처럼 복잡한 그라디언트가 많은 이미지와 로고처럼 단순한 플랫 컬러 이미지는 압축 알고리즘이 유리한 지점이 다르다. 그래서 실무에서는 이미지 유형별로 기본값을 나눠 판단하는 편이 안전하다. 사진·히어로 이미지는 AVIF와 WebP를 비교해서 고르고, 로고·아이콘류는 벡터 처리가 가능한 SVG를 먼저 검토한다JPEG XL 지원 현황.

JPEG XL은 압축률 수치만 보면 흥미롭지만 2026년 기준으로도 브라우저 지원 범위가 엇갈리는 포맷이라, 폴백 이미지 배포 전략까지 확인한 뒤 도입 여부를 정하는 게 맞다. 압축률 하나만 보고 포맷을 고르면 미지원 브라우저에서 이미지가 아예 안 뜨는 장애로 이어질 수 있다.

표시 크기와 srcset은 왜 포맷보다 먼저 봐야 할까?

포맷을 아무리 잘 골라도 실제 렌더링 크기보다 큰 원본을 내려보내면 그 차이만큼은 그대로 낭비된다. 데스크톱용 1,920px 원본을 모바일 360px 영역에 그대로 넣으면, 포맷이 AVIF든 WebP든 이미 필요 이상의 바이트를 전송한 뒤라 최적화 여지가 줄어든다. srcset과 sizes로 실제 표시 크기에 맞는 후보 이미지를 여러 개 제공하고, 브라우저가 뷰포트와 디바이스 픽셀 비율에 맞는 파일을 고르게 하는 게 포맷 선택보다 먼저 할 일이다Core Web Vitals 가이드.

<img
  src="hero-800.avif"
  srcset="hero-400.avif 400w, hero-800.avif 800w, hero-1600.avif 1600w"
  sizes="(max-width: 600px) 100vw, 800px"
  width="800" height="450"
  alt="상품 히어로 이미지"
/>

LCP 후보 이미지라면 fetchpriority="high"나 <link rel="preload">를 검토할 수 있다. 다만 실제 네트워크 워터폴에서 해당 이미지 요청이 늦게 시작되는 경우에만 쓰는 게 맞다. 페이지에 이미지가 여러 장 있는데 전부에 preload를 걸면 오히려 서로 대역폭을 다투면서 LCP가 더 늦어지는 역효과가 날 수 있다.

LCP 이미지는 왜 무조건 lazy-load하면 안 될까?

첫 화면(above-the-fold)에 걸리는 LCP 후보 이미지를 지연 로딩하면 브라우저가 스크롤 전까지 그 이미지를 요청조차 하지 않아 LCP가 늦어진다. loading="lazy"는 뷰포트 밖, 스크롤해야 보이는 이미지에만 적용하는 게 안전한 순서다. 실무에서 흔한 실수는 컴포넌트를 재사용하면서 리스트의 첫 번째 카드 이미지까지 일괄로 lazy 속성을 넣어버리는 경우다. 나도 상품 리스트 페이지에서 이 실수를 했고, 첫 번째 카드가 LCP 요소였던 페이지에서만 LCP가 늦어지는 걸 확인했다(모바일 에뮬레이션, 4G 조건, 단일 실행 기준이라 일반화보다는 해당 페이지 사례로만 참고했다).

우선순위 조정은 "LCP 이미지는 즉시 요청, 그 아래는 지연"이라는 단순한 순서로 가져가는 편이 유지보수하기 쉽다. preload나 fetchpriority를 여러 이미지에 겹쳐 쓰는 건 특정 요청이 워터폴에서 실제로 늦게 뜨는 걸 확인한 뒤에만 추가하는 걸 권한다.

오해: 파일 크기만 줄이면 LCP는 반드시 개선될까?

반드시 그렇지는 않다. 같은 파일 크기라도 디코드 비용과 네트워크 병목 위치에 따라 LCP 개선폭이 달라진다. 측정할 때는 파일 크기 외에 이미지 다운로드 시작 시점, 응답 완료 시점, 디코드 시간, LCP, 메모리 사용량을 따로 기록해야 실제 병목을 알 수 있다.

예를 들어 해상도는 낮췄지만 색 공간 변환이 무거운 포맷을 썼다면 네트워크 전송은 빨라져도 디코드 시간이 늘어나면서 LCP 개선폭이 기대보다 작게 나올 수 있다. 반대로 렌더 차단 CSS나 동기 스크립트가 <head>에서 첫 페인트를 막고 있다면, 이미지 파일 자체를 아무리 줄여도 LCP는 그 차단 지점 이후로 밀려서 개선 폭이 제한된다Core Web Vitals 가이드. 그래서 이미지 작업을 시작하기 전에 워터폴에서 렌더 차단 자원이 먼저 막고 있는지부터 확인하는 순서가 안전하다.

2025년에 공개된 한 React 애플리케이션 사례에서는 초기 JS가 2.4MB에서 380KB로 줄었고, LCP가 8.2초에서 2.1초, CLS가 0.42에서 0.08로 개선됐다고 보고됐다React 성능 최적화 사례. 다만 이 사례는 이미지·번들·렌더링 구조를 동시에 바꾼 결과라 LCP 개선을 이미지 최적화만의 공으로 단정할 수 없고, 네트워크·기기·캐시 조건도 충분히 공개되지 않아 참고 수치로만 받아들이는 게 맞다.

이미지 최적화는 언제 먼저 하고 언제 미뤄야 할까?

LCP 요소가 실제로 이미지라면 이미지 최적화를 먼저 하는 게 맞고, LCP 요소가 텍스트 블록이거나 렌더 차단 스크립트 뒤에 걸려 있다면 이미지 작업의 효과는 제한적이다. 적용 순서는 측정 → 가장 큰 병목 → 재측정으로 가져가는 편이 안전하다.

  1. 실사용자 LCP·INP·CLS와 이미지·번들 워터폴을 기준선으로 저장한다.
  2. LCP 요소가 이미지면 표시 크기·포맷·압축·우선순위를 조정한다.
  3. 초기 JS가 크면 라우트 단위 코드 스플리팅을 적용한다.
  4. 렌더 차단 CSS·동기 스크립트·사용하지 않는 자원을 정리한다.
  5. 동일 조건에서 재측정하고 raw/Brotli 크기와 CWV를 비교한다.

적합한 조건은 LCP 후보가 이미지이고 워터폴에서 그 이미지 요청이 실제로 늦게 끝나는 경우다. 반대로 LCP 요소가 텍스트거나 폰트 로딩에 걸려 있는 페이지에서는 이미지 포맷 작업의 우선순위를 낮추는 게 낫다. 회귀 방지를 위해서는 초기 JS 전송량, 초기 이미지 총 바이트, LCP 후보 이미지 크기, CSS 총량, LCP·INP·CLS의 75백분위수에 상한선을 두고, CI에서 초기 chunk 증가량·새 이미지의 원본과 파생 파일 크기·누락된 width/height·srcset 미사용·LCP 이미지의 잘못된 lazy-load를 자동 검사하는 편이 재발을 줄인다.

핵심 정리

  • 이미지 최적화는 포맷 교체 하나로 끝나지 않고 표시 크기·우선순위·디코드 비용을 함께 조정해야 LCP가 움직인다.
  • 사진류는 AVIF/WebP 비교, 로고·아이콘은 SVG를 기본값으로 분리해 판단한다(990KB 사진 기준 JPEG XL 472KB, AVIF 507KB, WebP 700KB, 단 이미지 유형에 따라 역전될 수 있음).
  • LCP 후보 이미지는 지연 로딩 대상에서 제외하고, 그 아래 이미지만 lazy-load 한다.
  • 파일 크기만이 아니라 다운로드 시작·완료, 디코드 시간, 메모리까지 측정해야 병목을 특정할 수 있다.
  • 적용 순서는 측정 → 가장 큰 병목(이미지 또는 렌더 차단 자원 또는 JS) → 재측정이며, 회귀 방지를 위해 CI에 크기·속성 검사를 넣는다.