웹 이미지 최적화 완벽 가이드: AVIF·WebP·반응형 이미지로 LCP 잡기 (2026)

웹 페이지 용량의 50~70%가 이미지라는 건 아마 한 번쯤 들어보셨을 겁니다. 그런데 2025 Web Almanac 데이터를 직접 보면 좀 충격적인데요—데스크톱의 85%, 모바일의 76%에서 이미지가 LCP(Largest Contentful Paint) 요소입니다. 결국 이미지를 건드리지 않으면 LCP를 개선할 방법이 사실상 없다는 얘기죠.

그런데 솔직히, 한국어 자료 대부분은 "WebP 쓰세요, lazy loading 하세요" 수준에서 끝납니다.

실전은 훨씬 복잡합니다. AVIF가 모바일에서 오히려 독이 되는 경우, sizes 속성 하나 빠뜨려서 필요한 것의 3배 용량을 다운로드하는 경우, fetchpriority 한 줄로 LCP를 수백 밀리초 줄이는 경우—이런 디테일이 실제 성과를 좌우합니다.

이 글에서는 2026년 최신 데이터를 바탕으로, 이미지 포맷 선택부터 반응형 전략, CDN 자동 최적화까지 실전 코드와 함께 하나씩 정리해 보겠습니다. 기존 LCP 최적화 가이드와 CLS 가이드에서 다뤘던 내용을 이미지 관점에서 좀 더 깊이 파고들어 봅니다.

2026년 이미지 포맷 지형도: JPEG vs WebP vs AVIF

이미지 최적화의 출발점은 포맷 선택입니다. 2026년 현재 웹 이미지 시장은 사실상 세 가지 포맷이 지배하고 있습니다.

JPEG: 30년 넘은 웹의 기본값

JPEG는 1992년부터 지금까지 웹의 기본 이미지 포맷입니다. 2025 Web Almanac 기준으로 LCP 이미지의 57%가 여전히 JPEG이고요. 모든 브라우저, 모든 디바이스에서 100% 지원되고 인코딩·디코딩이 빠르다는 장점이 있습니다. 다만 압축 효율은 확실히 떨어지고, 투명도 지원이 안 되며, HDR 색공간도 사용 불가입니다.

WebP: 이제는 사실상 표준

구글이 2010년에 발표한 WebP는 VP8 비디오 코덱 기반 압축을 씁니다. JPEG 대비 25~35% 더 작은 파일이면서 화질은 동등한 수준이에요. 손실·무손실 압축, 투명도, 애니메이션까지 다 됩니다. 2026년 기준 글로벌 브라우저 지원율 약 97%, 웹 이미지 요청의 40% 이상이 이미 WebP로 제공되고 있으니, "차세대"라기보다는 이제 사실상 표준이라고 봐야겠죠.

AVIF: 최강의 압축률, 그러나 함정이 있다

AOMedia가 2019년에 공개한 AVIF는 AV1 비디오 코덱 기반 이미지 포맷입니다. 압축률이 진짜 인상적인데, JPEG 대비 50% 이상, WebP 대비 20~30% 더 작습니다. 거기에 HDR(10비트, 12비트 색심도)까지 지원해서 고품질 히어로 이미지에 특히 좋습니다.

2026년 3월 기준 글로벌 브라우저 지원율은 93~95%. Chrome 85+, Firefox 93+, Safari 16+, Edge 121+ 전부 네이티브 지원합니다. 그런데 재밌는 건, 실제 웹에서 AVIF가 사용되는 비율은 아직 1% 미만이라는 겁니다.

이 간극이 바로 기회입니다. 지금 AVIF를 도입하면 경쟁 사이트 대비 확실한 성능 우위를 가져갈 수 있다는 뜻이니까요.

포맷별 핵심 비교

항목	JPEG	WebP	AVIF
압축률 (JPEG 대비)	기준	25~35% ↓	50%+ ↓
브라우저 지원 (2026)	100%	~97%	~93~95%
투명도 (알파)	✗	✓	✓
HDR/광색역	✗	✗	✓
애니메이션	✗	✓	✓
인코딩 속도	빠름	보통	느림
디코딩 속도	빠름	빠름	느림 (주의)
권장 품질 설정	75~85	75~85	60~75

2026년 황금 규칙: AVIF → WebP → JPEG 순서로 제공하되, AVIF의 디코딩 비용은 반드시 체크하세요. (이 부분은 뒤에서 자세히 다룹니다.)

picture 태그로 포맷 자동 분기 처리하기

차세대 포맷 도입 시 가장 흔한 실수가 뭘까요? 특정 브라우저 사용자가 이미지를 아예 못 보게 되는 겁니다. <picture>와 <source>를 조합하면, 브라우저가 알아서 지원 가능한 최적 포맷을 골라갑니다.

<picture>
  <!-- 1순위: AVIF (최고 압축률) -->
  <source
    srcset="hero.avif"
    type="image/avif"
  >
  <!-- 2순위: WebP (높은 호환성) -->
  <source
    srcset="hero.webp"
    type="image/webp"
  >
  <!-- 3순위: JPEG (폴백) -->
  <img
    src="hero.jpg"
    alt="메인 히어로 배너"
    width="1200"
    height="600"
  >
</picture>

동작 방식은 단순합니다. 브라우저가 위에서부터 <source>를 하나씩 확인하고, AVIF를 지원하면 AVIF를, 안 되면 WebP를, 그것마저 안 되면 <img>의 JPEG를 가져옵니다. 네트워크 요청은 딱 하나만 발생하고요.

picture 태그 쓸 때 꼭 지켜야 할 것들

• <img> 태그는 반드시 포함. <picture> 안에 <img>가 없으면 아무것도 렌더링되지 않습니다.
• width와 height는 <img>에 지정. 브라우저가 로딩 전에 공간을 확보해 CLS를 방지합니다.
• alt 텍스트도 <img>에. 접근성과 SEO 둘 다를 위해 필수입니다.
• CSS aspect-ratio를 같이 쓰면 레이아웃 안정성을 한층 더 높일 수 있습니다.

/* CSS로 레이아웃 안정성 강화 */
img {
  aspect-ratio: attr(width) / attr(height);
  width: 100%;
  height: auto;
  object-fit: cover;
}

반응형 이미지: srcset과 sizes로 디바이스별 최적 이미지 보내기

포맷만큼 중요한 게 크기입니다. 데스크톱용 1920px 히어로 이미지를 375px 모바일 화면에 그대로 보내는 건, 솔직히 대역폭 낭비이자 LCP 저하의 직접적인 원인입니다.

srcset의 w 디스크립터

srcset은 브라우저한테 "이 이미지들 중 하나 골라"라고 후보군을 알려주는 속성입니다. w 디스크립터는 각 후보의 실제 픽셀 너비를 명시하고요.

<img
  srcset="
    hero-480.webp   480w,
    hero-768.webp   768w,
    hero-1200.webp 1200w,
    hero-1920.webp 1920w
  "
  sizes="
    (max-width: 480px) 100vw,
    (max-width: 768px) 100vw,
    (max-width: 1200px) 80vw,
    1200px
  "
  src="hero-1200.webp"
  alt="히어로 배너"
  width="1920"
  height="960"
>

sizes 속성 누락: 가장 흔하면서도 치명적인 실수

이 부분이 한국어 자료에서 거의 다뤄지지 않는 핵심입니다.

srcset에 w 디스크립터를 쓰면서 sizes를 빼먹으면, 브라우저는 이미지가 뷰포트 전체 너비(100vw)를 차지한다고 가정해 버립니다. 사이드바 옆에 놓인 600px짜리 이미지인데도 1920px 파일을 다운로드한다는 거예요. 필요량의 3배가 넘는 이미지를 받는 셈이죠.

제 경험상 실제 프로젝트에서 이 실수가 정말 흔합니다. Lighthouse에서 "Properly size images" 경고가 뜨는 사이트의 상당수가 바로 이 문제입니다.

<!-- ❌ 잘못된 예: sizes 누락 -->
<img
  srcset="photo-480.webp 480w, photo-960.webp 960w, photo-1920.webp 1920w"
  src="photo-960.webp"
  alt="상품 사진"
>
<!-- 브라우저가 100vw로 가정 → 불필요한 대용량 이미지 다운로드 -->

<!-- ✅ 올바른 예: sizes 명시 -->
<img
  srcset="photo-480.webp 480w, photo-960.webp 960w, photo-1920.webp 1920w"
  sizes="(max-width: 768px) 100vw, 600px"
  src="photo-960.webp"
  alt="상품 사진"
  width="960"
  height="640"
>
<!-- 768px 이하에서는 뷰포트 전체, 그 이상에서는 600px 기준으로 이미지 선택 -->

picture + srcset 조합: 포맷과 크기 동시 최적화

포맷 분기와 크기 최적화를 동시에 적용하면 효과가 극대화됩니다. 코드가 좀 길어 보이지만, 한번 세팅해두면 그 이후로는 복붙에 가깝습니다.

<picture>
  <source
    type="image/avif"
    srcset="
      hero-480.avif   480w,
      hero-768.avif   768w,
      hero-1200.avif 1200w
    "
    sizes="(max-width: 768px) 100vw, 80vw"
  >
  <source
    type="image/webp"
    srcset="
      hero-480.webp   480w,
      hero-768.webp   768w,
      hero-1200.webp 1200w
    "
    sizes="(max-width: 768px) 100vw, 80vw"
  >
  <img
    src="hero-1200.jpg"
    srcset="
      hero-480.jpg   480w,
      hero-768.jpg   768w,
      hero-1200.jpg 1200w
    "
    sizes="(max-width: 768px) 100vw, 80vw"
    alt="히어로 배너"
    width="1200"
    height="600"
    fetchpriority="high"
  >
</picture>

LCP 이미지 우선순위 높이기: fetchpriority와 preload

포맷과 크기를 최적화했으면, 이제 남은 건 브라우저가 LCP 이미지를 제일 먼저 가져오게 만드는 것입니다. 원래 브라우저는 레이아웃을 끝낸 다음에야 이미지 우선순위를 판단하거든요. 이 대기 시간을 없애주는 도구가 fetchpriority와 preload입니다.

fetchpriority="high": 코드 한 줄의 마법

2026년 현재 모든 주요 브라우저(Chrome 102+, Safari 17.2+, Firefox 132+, Edge 102+)가 지원합니다. 그런데 실제로 LCP 이미지에 이걸 적용한 사이트는 고작 17%입니다.

나머지 83%는 이 쉬운 최적화를 놓치고 있는 거예요. (개인적으로 가장 가성비 좋은 웹 성능 최적화 기법 중 하나라고 생각합니다.)

<!-- LCP 히어로 이미지에 fetchpriority="high" 적용 -->
<img
  src="/images/hero-banner.webp"
  alt="메인 배너"
  width="1200"
  height="600"
  fetchpriority="high"
>

<!-- 뷰포트 밖 이미지에는 fetchpriority="low" -->
<img
  src="/images/footer-promotion.webp"
  alt="푸터 프로모션"
  width="400"
  height="200"
  fetchpriority="low"
  loading="lazy"
>

실제 사례를 보면, Google Flights는 히어로 이미지에 fetchpriority="high"를 추가한 뒤 LCP가 2.6초에서 1.9초로 700ms나 줄었습니다. 일반적으로는 LCP가 평균 5~10%, 최대 30%까지 개선되는 것으로 보고됩니다.

한 가지 주의: fetchpriority="high"는 LCP 이미지 딱 하나에만 적용하세요. 여러 이미지에 high를 주면 서로 대역폭을 뺏어먹으면서 효과가 상쇄됩니다.

preload: CSS 배경 이미지의 LCP를 잡는 법

CSS background-image로 로드되는 히어로 이미지는 브라우저가 CSS를 파싱할 때까지 아예 발견되지 않습니다. 이럴 때 preload로 미리 알려줘야 합니다.

<head>
  <!-- CSS 배경 이미지를 preload로 조기 발견 -->
  <link
    rel="preload"
    href="/images/hero-bg.avif"
    as="image"
    type="image/avif"
    fetchpriority="high"
  >
  <!-- AVIF 미지원 브라우저 대비 WebP 폴백 preload -->
  <link
    rel="preload"
    href="/images/hero-bg.webp"
    as="image"
    type="image/webp"
  >
</head>

리소스 힌트에 대해 더 알고 싶다면 리소스 힌트 완벽 가이드를 참고하세요.

Lazy Loading: 제대로 적용하는 법

Lazy loading은 뷰포트 밖 이미지 로딩을 미뤄서 초기 로드 속도를 높이는 기법입니다. loading="lazy" 한 줄이면 되지만, 잘못 적용하면 LCP가 오히려 나빠집니다.

절대 lazy loading하면 안 되는 이미지

• LCP 히어로 이미지: lazy loading을 걸면 뷰포트에 진입해야 다운로드가 시작되니까 LCP가 크게 늦어집니다.
• 첫 화면(Above the fold)의 모든 이미지: 스크롤 전에 보이는 이미지에 lazy loading은 금물입니다.
• 로고, 네비게이션 아이콘: 페이지 구조의 핵심 요소는 즉시 로드돼야 합니다.

<!-- ✅ LCP 이미지: lazy loading 금지, 즉시 로드 -->
<img
  src="hero.webp"
  alt="메인 배너"
  width="1200"
  height="600"
  fetchpriority="high"
  decoding="sync"
>

<!-- ✅ 스크롤 아래 이미지: lazy loading 적용 -->
<img
  src="product-01.webp"
  alt="상품 1"
  width="400"
  height="300"
  loading="lazy"
  decoding="async"
>

<!-- ✅ 카드 리스트 이미지: lazy loading 적용 -->
<img
  src="article-thumb.webp"
  alt="아티클 썸네일"
  width="320"
  height="180"
  loading="lazy"
  decoding="async"
>

decoding 속성: sync vs async

의외로 잘 안 알려진 최적화 포인트입니다.

decoding 속성은 브라우저에게 이미지 디코딩 방식을 힌트로 줍니다. decoding="sync"는 디코딩이 끝날 때까지 다른 렌더링을 멈추는데, LCP 이미지에 쓰면 준비되는 즉시 화면에 표시됩니다. 반면 decoding="async"는 비동기로 디코딩해서 메인 스레드를 안 막으니까, 뷰포트 밖 이미지에 적합합니다. INP에도 도움이 되고요.

AVIF 디코딩 성능: 모바일에서 꼭 확인해야 할 함정

AVIF의 압축률은 최강이지만, 디코딩 비용이라는 숨겨진 대가가 있습니다. 솔직히 대부분의 이미지 최적화 가이드에서 이 부분을 그냥 넘어가는데, 실제로는 꽤 중요합니다.

왜 이런 일이 생기나

AVIF는 AV1 비디오 코덱 기반이라 디코딩이 CPU를 많이 먹습니다. 파일이 작아서 다운로드는 빠르지만, 디코딩에서 시간을 까먹는 거죠. 특히 저사양 모바일 기기에서 이 문제가 두드러집니다.

Chrome DevTools Performance 패널에서 LCP 요소와 연관된 "Decode Image" 태스크가 비정상적으로 길게 잡히면, AVIF 디코딩이 병목일 가능성이 높습니다.

실전 대응 전략

<!-- 전략 1: LCP 이미지는 WebP, 나머지는 AVIF -->
<picture>
  <!-- LCP 히어로: 디코딩이 빠른 WebP 우선 -->
  <source srcset="hero.webp" type="image/webp">
  <img
    src="hero.jpg"
    alt="메인 배너"
    width="1200"
    height="600"
    fetchpriority="high"
    decoding="sync"
  >
</picture>

<!-- 비-LCP 이미지: AVIF의 압축률 혜택을 최대한 활용 -->
<picture>
  <source srcset="product.avif" type="image/avif">
  <source srcset="product.webp" type="image/webp">
  <img
    src="product.jpg"
    alt="상품 이미지"
    width="400"
    height="300"
    loading="lazy"
    decoding="async"
  >
</picture>

그래서 AVIF를 LCP 이미지에 써도 되는 건 언제?

• 타겟 사용자 기기 수준이 높을 때: B2B SaaS나 개발자 대상 서비스처럼 고사양 디바이스 비율이 높으면 AVIF를 LCP에 써도 괜찮습니다.
• 이미지 크기가 아주 클 때: 2MB 이상 대형 이미지라면 AVIF의 압축률 이점이 디코딩 비용을 충분히 상쇄합니다.
• DevTools에서 직접 테스트한 결과가 괜찮을 때: 모바일 시뮬레이션(CPU 4x Slowdown)에서 Decode Image 태스크가 50ms 이하면 안전합니다.

확신이 안 서면 LCP는 WebP, 비-LCP는 AVIF. 이게 가장 안전한 전략입니다.

이미지 CDN으로 자동 최적화하기

매번 AVIF, WebP, JPEG 세 버전을 수동으로 만드는 건... 현실적으로 불가능하죠. 이미지 CDN을 쓰면 원본 하나만 올리면 되고, 브라우저의 Accept 헤더를 읽어 최적 포맷을 자동으로 골라서 보내줍니다.

Content Negotiation의 동작 원리

브라우저가 이미지를 요청할 때 HTTP Accept 헤더에 지원하는 포맷 목록을 담아 보냅니다. 이미지 CDN은 이걸 읽어서 최적의 포맷을 결정합니다.

# 최신 Chrome의 Accept 헤더 예시
Accept: image/avif,image/webp,image/apng,image/svg+xml,image/*,*/*;q=0.8

# CDN의 동작:
# 1. Accept에 image/avif가 있으면 → AVIF 제공
# 2. image/avif는 없고 image/webp가 있으면 → WebP 제공
# 3. 둘 다 없으면 → 최적화된 JPEG 제공

주요 이미지 CDN 비교 (2026)

항목	Cloudflare Images	Cloudinary	imgix
AVIF 자동 변환	✓ (best-effort)	✓ (f_auto)	✓ (auto=format)
WebP 폴백	자동	자동	자동
반응형 크기 조정	URL 파라미터	URL 파라미터	URL 파라미터
AI 스마트 크롭	제한적	고급 (얼굴 인식)	고급
Client Hints 지원	✓	✓	✓
추천 용도	콘텐츠 사이트, 퍼블리셔	미디어 중심 앱, DAM	e-commerce, 마케팅

Cloudflare의 숨은 장점 하나: HTML 문서와 이미지를 같은 에지 서버에서 캐시합니다. 서드파티 이미지 CDN에 별도로 DNS 연결을 열 필요가 없어서, LCP에서 결정적인 수십 밀리초를 아낄 수 있어요.

다만 format=auto를 사용하면 AVIF, WebP, JPEG 중 뭐가 나가든 하나의 고유 변환으로 카운트됩니다. 그리고 AVIF 인코딩이 너무 오래 걸리는 대형 이미지는 알아서 WebP로 폴백되니까 참고하세요.

Cloudinary 코드 예시

<!-- Cloudinary: f_auto로 포맷 자동 선택, w_auto로 크기 자동 조정 -->
<img
  src="https://res.cloudinary.com/demo/image/upload/f_auto,q_auto,w_auto/hero.jpg"
  alt="히어로 배너"
  width="1200"
  height="600"
  fetchpriority="high"
  sizes="(max-width: 768px) 100vw, 80vw"
>

<!--
  f_auto: 브라우저에 맞는 최적 포맷 자동 선택
  q_auto: 시각적 품질을 유지하면서 최적 압축률 자동 선택
  w_auto: Client Hints 기반 반응형 크기 자동 조정
-->

참고: Cloudinary는 5,000픽셀 미만의 작은 이미지는 AVIF로 변환하지 않습니다. 포맷 오버헤드가 바이트 절감을 넘어서기 때문인데, 이 경우 WebP가 자동으로 제공됩니다.

CLS 방지를 위한 이미지 레이아웃 안정성

이미지 로딩 중 레이아웃이 밀리는 현상, 다들 한번은 겪어보셨을 겁니다. 이게 CLS 점수를 크게 깎아먹는데, 방지법은 의외로 간단합니다. 브라우저가 이미지 로딩 전에 정확한 공간을 확보하게 만들면 됩니다.

width·height 속성은 기본 중의 기본

<!-- ❌ CLS 유발: 크기 미지정 -->
<img src="photo.webp" alt="사진">

<!-- ✅ CLS 방지: 원본 비율에 맞게 크기 지정 -->
<img
  src="photo.webp"
  alt="사진"
  width="800"
  height="600"
>

width와 height를 HTML에 명시하면 브라우저가 다운로드 전에 가로세로 비율을 계산해서 공간을 미리 잡아둡니다. CSS에서 width: 100%; height: auto;를 적용해도 비율은 그대로 유지되고요.

CSS aspect-ratio로 더 확실하게

/* 모던 브라우저에서 더 확실한 레이아웃 안정성 */
.hero-image {
  aspect-ratio: 16 / 9;
  width: 100%;
  height: auto;
  object-fit: cover;
  background-color: #f0f0f0; /* 로딩 중 빈 공간 색상 */
}

CLS에 대해 더 자세히 알고 싶다면 CLS 완벽 가이드를 참고하세요.

실전 이미지 최적화 체크리스트

여기까지 읽으셨다면, 이제 실전에 바로 적용할 수 있는 체크리스트로 정리해 드리겠습니다.

1단계: 포맷 최적화

• AVIF → WebP → JPEG 순서로 <picture> 태그 적용
• AVIF 품질: 60~75, WebP 품질: 75~85로 설정
• 이미지 CDN 사용 시 f_auto 또는 format=auto로 자동 포맷 협상 활성화

2단계: 크기 최적화

• 디바이스별 2~4개 크기 변형(480w, 768w, 1200w, 1920w) 생성
• srcset + sizes 반드시 같이 사용 (sizes 빠뜨리면 안 됩니다)
• 디스플레이 크기의 2배 해상도까지만 제공 (Retina 대응)

3단계: 로딩 우선순위

• LCP 이미지: fetchpriority="high" + decoding="sync"
• CSS 배경 LCP 이미지: <link rel="preload">
• 비-LCP 이미지: loading="lazy" + decoding="async"

4단계: 레이아웃 안정성

• 모든 <img>에 width·height 명시
• CSS aspect-ratio로 반응형 환경에서의 안정성 강화
• placeholder 배경색 또는 blur-up 기법으로 로딩 UX 개선

5단계: 모니터링

• Chrome DevTools Performance 패널에서 "Decode Image" 태스크 시간 확인
• Lighthouse에서 "Serve images in next-gen formats", "Properly size images" 점검
• CrUX(Chrome User Experience Report) 필드 데이터로 실사용자 LCP 추적

자주 묻는 질문 (FAQ)

WebP와 AVIF 중 뭘 써야 하나요?

둘 다 쓰는 게 정답입니다. <picture> 태그로 AVIF를 1순위, WebP를 2순위, JPEG를 폴백으로 설정하세요. 다만 LCP 히어로 이미지에서 모바일 디코딩 지연이 걱정된다면 WebP를 1순위로 올리는 게 더 안전합니다. 2026년 기준 AVIF 지원율 93~95%, WebP 97%이니까 대부분의 사용자는 차세대 포맷 혜택을 받을 수 있습니다.

srcset에서 sizes 속성을 꼭 넣어야 하나요?

네, 반드시요. srcset에 w 디스크립터를 쓰면서 sizes를 빼면, 브라우저가 이미지 너비를 100vw로 가정합니다. 사이드바 옆 600px 이미지도 1920px짜리를 받게 되니까 대역폭 낭비에 LCP 악화까지 따라옵니다. sizes는 브라우저에게 이미지의 실제 표시 크기를 알려주는 필수 속성이에요.

LCP 이미지에 lazy loading을 적용하면 왜 안 되나요?

loading="lazy"는 이미지가 뷰포트 근처에 와야 다운로드를 시작합니다. LCP 이미지는 가능한 한 빨리 로드돼야 하는데, lazy loading이 이걸 인위적으로 늦추는 거죠. LCP 이미지에는 fetchpriority="high"를 쓰고, lazy loading은 스크롤 아래(below the fold) 이미지에만 적용하세요.

이미지 CDN을 쓰면 picture 태그가 필요 없나요?

이미지 CDN의 format=auto 기능을 쓰면 서버 측에서 콘텐츠 협상이 일어나니까, <picture> 없이 단일 <img>로도 포맷 최적화가 가능합니다. 하지만 srcset과 sizes는 여전히 필요해요. CDN이 포맷을 자동 전환해도, 어떤 크기를 요청할지는 브라우저가 srcset/sizes를 보고 결정하니까요.

AVIF가 모바일에서 느리다는 게 사실인가요?

부분적으로는 맞습니다. AVIF는 AV1 코덱 기반이라 디코딩에 CPU를 더 많이 씁니다. 고사양 기기에서는 거의 차이가 없지만, 저사양 모바일에서는 파일이 작아서 다운로드는 빨라도 디코딩 지연 때문에 LCP가 오히려 나빠질 수 있습니다. Chrome DevTools Performance 패널에서 "Decode Image" 시간을 체크하고, CPU 4x Slowdown에서 50ms 넘으면 해당 이미지는 WebP로 가는 게 낫습니다.