Logo
BlogPricing

Core Web Vitals를 위한 이미지 최적화 방법

By Artur업데이트 5분 소요

웹사이트 로딩이 느리다. Lighthouse 테스트를 돌려본다. 리포트에 이미지가 문제라고 나온다.

빨간색 "Largest Contentful Paint" 점수? 거의 항상 최적화되지 않은 이미지 때문이다. 그리고 Google은 이 점수로 사이트 순위를 매긴다.

Core Web Vitals는 Google이 가장 중요하게 보는 지표다. 이미지가 가장 큰 지표에 영향을 준다. 이미지를 고치면 점수가 올라간다. 구체적인 방법을 알아보자.

Core Web Vitals란 무엇이고 이미지가 왜 중요한가?

Core Web Vitals는 Google이 모든 페이지에서 측정하는 세 가지 성능 지표다:

  • Largest Contentful Paint (LCP): 가장 큰 시각적 요소가 로딩되는 속도. 2.5초 이내여야 한다.
  • Interaction to Next Paint (INP): 클릭이나 탭할 때 페이지 반응 속도. 200밀리초 이내여야 한다.
  • Cumulative Layout Shift (CLS): 로딩 중 페이지 레이아웃이 얼마나 움직이는지. 0.1 이하여야 한다.

이미지는 이 세 가지 중 두 가지에 직접 영향을 준다. 무거운 히어로 이미지는 LCP 점수를 망친다. 크기가 설정되지 않은 이미지는 레이아웃 변경을 일으켜 CLS를 해친다.

이게 비즈니스에 왜 중요할까? Google은 Core Web Vitals가 순위 요인이라고 확인했다. 점수가 좋은 페이지는 더 많은 자연 트래픽을 얻는다. 점수가 나쁜 페이지는 검색 결과에서 밀려난다.

데이터가 이를 증명한다. LCP를 2초 이상 개선한 사이트들은 측정 가능한 순위 상승을 보였다. 경쟁이 치열한 키워드에서 이 속도 차이는 첫 페이지와 세 번째 페이지의 차이를 만들 수 있다.

그리고 이미지는 보통 페이지에서 가장 무거운 요소다. 평균 웹페이지는 1MB 이상의 이미지를 로딩한다. 스크립트, 폰트, HTML을 합친 것보다 많다. 이미지를 고치면 대부분의 성능 문제가 해결된다.

이미지 최적화로 Largest Contentful Paint를 어떻게 개선하나?

LCP는 가장 큰 시각적 요소가 렌더링을 완료하는 시점을 측정한다. 대부분의 페이지에서 이것은 히어로 이미지, 제품 사진, 또는 배너다.

그 이미지가 4초 걸려 로딩되면 LCP가 4초다. Google은 2.5초 이내를 원한다. 그 차이를 줄이는 방법을 알아보자.

이미지를 압축하라. 2MB 히어로 이미지는 너무 크다. 150-200KB로 압축하면 로딩 시간이 크게 줄어든다. 사진에는 75-85% 품질 설정을 사용하라. 시각적 차이는 거의 보이지 않지만 파일 크기는 80-90% 줄어든다.

현대적 포맷을 사용하라. WebP 파일은 JPEG보다 25-35% 작다. 같은 품질에서. AVIF는 더 많이 줄인다. 모든 현대 브라우저가 WebP를 지원한다. 포맷을 바꾸는 것만으로도 LCP를 쉽게 개선할 수 있다.

디스플레이 크기에 맞게 리사이즈하라. 페이지에서 800px로 보여주면서 4000px 이미지를 제공하지 마라. 먼저 리사이즈하고 그다음 압축하라. 이것만으로도 파일 크기를 70-80% 줄일 수 있다.

LCP 이미지를 프리로드하라. HTML에 프리로드 힌트를 추가해서 브라우저가 히어로 이미지를 즉시 가져오게 하라. 이것 없이는 브라우저가 CSS를 파싱한 후에야 이미지를 발견한다. 이 지연이 수백 밀리초를 추가한다.

<link rel="preload" as="image" href="/hero.webp" fetchpriority="high">

LCP 이미지에 fetchpriority="high"를 설정하라. 이것은 브라우저에게 이 이미지를 다른 리소스보다 우선시하라고 알려준다. 작은 변경이지만 LCP 시간을 실제로 줄여준다.

LCP 이미지에 lazy load를 사용하지 마라. 이것은 흔한 실수다. Lazy loading은 이미지가 뷰포트에 스크롤될 때까지 지연시킨다. 히어로 이미지는 페이지 로딩 시 이미 보이고 있다. 여기에 lazy load를 쓰면 불필요한 지연이 추가되고 LCP 점수가 떨어진다.

Lazy loading은 Core Web Vitals에 도움이 되나 해가 되나?

Lazy loading은 폴드 아래 이미지에는 좋다. 폴드 위 이미지에는 나쁘다.

이미지에 loading="lazy"를 추가하면 브라우저는 사용자가 근처까지 스크롤할 때까지 다운로드를 기다린다. 사용자가 절대 보지 않을 수 있는 이미지의 대역폭을 절약한다. 초기 페이지 무게를 줄이고 첫 로딩을 빠르게 한다.

하지만 히어로 이미지나 첫 화면에 보이는 이미지에 lazy load를 걸면, 페이지에서 가장 중요한 시각적 요소의 로딩을 지연시키는 것이다. 이것은 LCP를 직접적으로 증가시킨다.

규칙은 간단하다. 폴드 아래 모든 이미지에는 lazy load를 걸어라. 폴드 위 이미지에는 절대 lazy load를 걸지 마라. 히어로 이미지, 헤더 로고, 스크롤 없이 보이는 모든 콘텐츠는 즉시 로딩되어야 한다.

대부분의 페이지에서 이것은 1-3장의 이미지가 즉시 로딩된다는 의미다. 나머지는 모두 lazy loading이다. 이 균형이 대역폭을 절약하면서도 최고의 LCP 점수를 준다.

lazy load 이미지로 인한 레이아웃 변경도 주의하라. lazy 이미지가 로딩되면서 콘텐츠를 밀어내면 CLS 문제다. 항상 이미지에 명시적인 width와 height 속성을 설정하라. 브라우저가 이미지 로딩 전에 공간을 확보해서 레이아웃 점프를 방지한다.

어떤 이미지 포맷이 최고의 Core Web Vitals 점수를 주나?

선택하는 포맷이 파일 크기에 직접 영향을 준다. 더 작은 파일은 더 빨리 로딩된다. 더 빠른 로딩은 더 나은 LCP를 의미한다.

WebP는 현재 웹 이미지에 가장 좋은 기본 선택이다. JPEG보다 25-35% 더 효율적으로 압축하며 눈에 보이는 품질 손실이 없다. 브라우저 지원이 97% 이상이다. 아주 오래된 브라우저를 지원할 필요가 없다면 WebP가 최선이다.

AVIF는 WebP보다 더 잘 압축한다. JPEG보다 최대 50% 작다. 하지만 인코딩이 느리고 브라우저 지원이 아직 따라잡는 중이다. 빌드 파이프라인이 지원하고 폴백을 제공할 수 있다면 사용하라.

JPEG는 사진에 여전히 괜찮다. 잘 압축하면(품질 75-85) 든든한 선택이다. 하지만 WebP가 같은 시각적 품질에서 거의 항상 더 작은 파일을 준다.

PNG는 로고, 아이콘, 투명도가 필요한 이미지에 적합하다. 하지만 PNG 파일은 크다. 투명도가 필요 없으면 WebP나 JPEG로 변환하라.

<picture> 요소로 각 브라우저에 최적의 포맷을 제공할 수 있다:

<picture>
  <source srcset="/hero.avif" type="image/avif">
  <source srcset="/hero.webp" type="image/webp">
  <img src="/hero.jpg" alt="히어로 이미지" width="1200" height="600">
</picture>

이것은 AVIF를 지원하는 브라우저에 AVIF를, 다음 그룹에 WebP를, JPEG를 폴백으로 제공한다. 모든 방문자가 브라우저가 처리할 수 있는 가장 작은 파일을 받는다.

이미지로 인한 레이아웃 변경을 어떻게 방지하나?

레이아웃 변경은 이미지가 로딩되면서 다른 콘텐츠를 밀어낼 때 발생한다. 읽고 있던 텍스트가 갑자기 아래로 점프한다. 클릭하려던 버튼이 이동한다. 사용자에게 짜증나고 CLS 점수에도 나쁘다.

해결책은 간단하다. 항상 이미지가 로딩되기 전에 브라우저에게 이미지 크기를 알려주면 된다.

모든 이미지에 width와 height를 설정하라. 브라우저가 이 값으로 종횡비를 계산하고 적절한 공간을 확보한다. 이미지가 아직 로딩되지 않았어도 레이아웃은 안정적이다.

<img src="/photo.webp" alt="제품 사진" width="800" height="600">

반응형 이미지에는 CSS aspect-ratio를 사용하라. 이미지가 뷰포트에 따라 스케일되면 CSS에서 종횡비를 설정하라. 브라우저가 모든 화면 크기에서 올바른 비례 공간을 확보한다.

img {
  aspect-ratio: 4 / 3;
  width: 100%;
  height: auto;
}

기존 콘텐츠 위에 동적으로 이미지를 삽입하지 마라. JavaScript가 페이지 상단에 광고 배너나 캐러셀을 로딩하면 아래 모든 것이 이동한다. 동적 콘텐츠를 위한 공간을 확보하거나 폴드 아래에 로딩하라.

폰트 의존적 레이아웃을 주의하라. 때때로 레이아웃 변경은 이미지 때문이 아니다. 늦게 로딩되는 웹 폰트가 텍스트를 리플로우하고 이미지를 이동시킬 수 있다. font-display: swap을 사용하고 핵심 폰트를 프리로드하라.

Core Web Vitals를 위한 이미지 최적화 체크리스트

페이지마다 따를 수 있는 단계별 체크리스트:

업로드 전:

  • 이미지를 디스플레이 크기로 리사이즈 (레티나 화면은 2배).
  • 올바른 품질로 이미지 압축. 사진은 75-85%.
  • 가능하면 WebP나 AVIF로 변환.
  • 메타데이터 제거 (EXIF 데이터, GPS 좌표, 카메라 정보).

HTML에서:

  • 모든 <img> 태그에 width와 height 설정.
  • 폴드 아래 모든 이미지에 loading="lazy" 추가.
  • LCP 이미지에 fetchpriority="high" 추가.
  • <link rel="preload">로 LCP 이미지 프리로드.
  • <picture> 요소로 현대적 포맷과 폴백 제공.

배포 후:

  • Lighthouse 또는 PageSpeed Insights 실행. LCP와 CLS 점수 확인.
  • "개선 기회" 섹션 확인. 더 작아질 수 있는 이미지를 표시해준다.
  • 모바일에서 테스트. 모바일 연결이 느리므로 이미지 최적화가 더 중요하다.

이 체크리스트를 꾸준히 따르면 Core Web Vitals가 녹색으로 유지된다. 대부분의 사이트는 이미지 최적화만으로 LCP가 1-3초 줄어든다.

이미지 성능을 어떻게 테스트하고 모니터링하나?

한 번 최적화하는 것으로는 부족하다. 새로운 이미지가 추가된다. 콘텐츠가 바뀐다. 성능을 지속적으로 모니터링해야 한다.

Google PageSpeed Insights는 빠른 개요를 제공한다. 아무 URL이나 붙여넣으면 모바일과 데스크톱의 LCP, INP, CLS 점수를 볼 수 있다. 실제 Chrome 사용자의 필드 데이터도 제공된다.

Lighthouse(Chrome DevTools에 내장)는 완전한 감사를 실행한다. 과도한 이미지, 누락된 lazy loading, 크기가 없는 이미지, 구식 포맷의 이미지를 표시한다. 확장 프로그램 간섭을 피하려면 시크릿 모드에서 실행하라.

Google Search Console은 전체 사이트의 Core Web Vitals 데이터를 보여준다. URL을 상태별로 그룹화한다: 양호, 개선 필요, 불량. 매달 확인해서 퇴화를 일찍 발견하라.

WebPageTest는 페이지 로딩의 프레임별 필름스트립 뷰를 제공한다. 각 이미지가 언제 나타나는지, 렌더 타임라인에 어떻게 영향을 주는지 정확히 볼 수 있다.

인기 압축 도구 비교는 워크플로우에 맞는 도구를 선택하는 데 도움이 된다. 이미지를 하나씩 압축하든 수백 장을 일괄 처리하든, 올바른 도구가 최적화를 쉽게 유지시켜 준다.

Core Web Vitals를 고칠 준비가 되었나?

이미지는 대부분의 웹페이지에서 가장 큰 부담이다. 이미지를 최적화하는 것이 Core Web Vitals에 할 수 있는 가장 영향력 있는 변화다.

이미지를 압축하라. 현대적 포맷을 사용하라. 올바른 크기를 설정하라. 중요한 것은 프리로드하라. 중요하지 않은 것은 lazy load하라.

CompressIMG가 압축 단계를 처리한다. 이미지를 업로드하고, 품질을 선택하고, 몇 초 안에 최적화된 파일을 다운로드하라. 계정 필요 없음. 히어로 이미지부터 시작해서 차례로 작업하면 된다.

LCP 점수가 당신에게 감사할 것이다.

CompressIMG

품질 손실 없이 이미지를 압축하세요. 무료, 빠르고 브라우저에서 바로 가능합니다.

CompressIMG 무료 체험
Share