이전 포스팅에서 이미지 형식을 기존의 JPEG, PNG에서 WebP로 전환하면서 눈에 띄는 이미지 최적화를 확인할 수 있었다.
[1편] JPEG → WebP 전환 후 성능은 어떻게 달라졌을까?
하지만 단순히 “이미지 최적화를 구현했다”라는 결과만 보고 넘어가기보다는 기술적으로 깊이 있게 공부해보려고 한다.
먼저 WebP 개념을 다시 한번 짚고가보자
WebP(Web Picture format)는 Google이 만든 최신 이미지 포맷이다.
JPEG처럼 손실 압축도 되고, PNG처럼 무손실 압축도 지원하며, 투명도(알파 채널), 애니메이션까지 모두 표현할 수 있는 올인원 포맷이다.
실제로 WebP는 다음과 같은 용량 절감 효과를 보여준다
- 무손실 WebP는 PNG보다 약 26% 더 작고
- 손실 WebP는 JPEG보다 25~34% 더 작으며
- 투명도가 포함된 손실 WebP는 PNG보다 최대 3배 더 작을 수 있다.
이러한 결과는 단순히 포맷을 바꿨기 때문만이 아니라, WebP의 압축 방식 자체가 기존 포맷들과 근본적으로 다르기 때문이다.
이제부터 기술적인 측면을 심층적으로 설명해보겠다.
Q) 왜 WebP로 바꾸면 이미지 용량이 줄어들까?
WebP는 Google의 동영상 기술인 VP8 코덱을 활용하여 이미지를 저장할 때 중복된 정보를 예측하고 차이만 저장하는 방식을 사용한다. 또한 무손실 압축은 이미 저장된 픽셀을 재사용하거나 색상 팔레트를 효율적으로 구성해 중복 데이터를 줄인다.
기존에는 투명한 이미지를 저장할 때 PNG를 사용했지만, WebP는 손실 압축과 투명도(알파 채널)를 동시에 지원해 PNG보다 3배 이상 작게 만들 수 있다. 여기에 JPEG보다 더 효율적인 산술 인코딩을 사용하고, 불필요한 메타데이터(EXIF, 색상 프로필 등)를 제거할 수 있어 전체 용량이 더욱 줄어든다.
즉, WebP는 저장방식, 압축 기술, 메타데이터 처리까지 모든 면에서 더 똑똑하게 이미지 데이터를 다루기 때문에 같은 이미지를 더 작게 만들 수 있다.
Q) 단순히 이미지 용량만 줄었는데, 왜 LCP까지 줄어든 이유는 뭘까?
LCP는 화면에서 가장 큰 콘텐츠 요소(주로 가장 큰 이미지나 텍스트)가 사용자 화면에 완전히 렌더링되는 시점까지의 시간을 측정한다.
이때 LCP에 가장 큰 영향을 주는 요소는 다음 두가지이다.
- 네트워크 지연: 이미지를 받아오는 데 걸리는 시간
- 브라우저 렌더링: 이미지 디코딩 및 그리기 과정
이전 포스팅에서 적었던 이미지 최적화 후 실제 수치 변화는 다음과 같았다.
- 이미지 용량: 787kB → 84.4kB (89% 감소)
- 네트워크 요청 시간: 662ms → 112ms (83% 감소)
- LCP: 6110ms → 5070ms (약 17% 감소)
- Performance 점수: 56 → 75 (19점 상승)이미지 용량: 787kB → 84.4kB (89% 감소)
- 네트워크 요청 시간: 662ms → 112ms (83% 감소)
- LCP: 6110ms → 5070ms (약 17% 감소)
- Performance 점수: 56 → 75 (19점 상승)
이미지 최적화를 통해 용량이 89% 감소하면서 네트워크에서 이미지를 받아오는 시간 또한 83% 감소했다.
브라우저는 이미지 리소스를 빠르게 내려받은 덕분에, 디코딩 → 렌더링 단계로 더 빨리 진입할 수 있었고, 결과적으로 LCP는 약 17% 줄어든 5070ms로 개선되었다.
이는 브라우저의 렌더링 타임라인에서 네트워크 지연이 렌더링 병목을 만드는 주요 원인이라는 것을 알 수 있다. 이미지 용량을 줄이면 단순히 “전송 속도”만 개선되는 게 아니라, 렌더링 타이밍도 빨라져 LCP까지 개선되는 것이다.
Q) 네트워크 상태가 안좋으면 최적화 효과는 어떻게 달라질까?
이미지 최적화를 통해 페이지 로딩 속도가 빨라진것을 확인할 수 있었다.
하지만 “네트워크 상태가 느릴 때는 최적화 효과가 어떻게 달라질까?”라는 궁금증이 생겼다.
그래서 Network 탭에 Throttling 기능을 활용해 3G 환경에서 실제로 측정해보았다.
- 이미지 용량: 787kB → 84.4kB (89% 감소)
- 네트워크 요청 시간: 662ms → 794ms (20% 증가)
- LCP: 6110ms → 5480ms (약 10%감소)
- Performance 점수: 56 → 56 (변화 없음)
위 결과를 통해 네트워크 상태에 따라 결과가 다름을 확인할 수 있었다. 이러한 차이는 네트워크 속도가 느려짐에 따라 브라우저의 리소스 처리 타이밍이 지연되기 때문이다.
느린 네트워크에서는 단순한 성능 점수보다는 병목이 어디서 발생했는지를 확인하는 것이 중요하다. 이때 핵심적으로 생각해야할 성능 지표는 크게 두가지이다.
- TTFB(Time to First Byte) - 서버로부터 첫 바이트가 도착하는 시간이다. 이는 서버 응답 속도, 캐싱 여부, CDN 적용 등에 영향 받는다.
- TTI(Time to Interactive) - 사용자가 페이지와 실제로 상호작용할 수 있게 되는 시간이다. 이는 JS 실행, 이미지 렌더링 등 리소스 처리 병목의 영향 받는다.
결과적으로 이미지 최적화로 용량은 줄었지만, 느린 네트워크에서는 전송 지연(TTFB 증가)과 렌더링 처리 지연(TTI 증가)이 발생하기 때문에, LCP 개선폭이 줄고 Performance 점수 상승 효과가 상쇄되었다.
Q) WebP를 쓰면 성능이 무조건 좋아질까?
WebP는 JPEG, PNG 대비 더 높은 압축률을 제공하지만, 성능이 무조건 좋아지는 건 아니다.
일부 iOS 구버전 Safari나 오래된 브라우저에선 WebP가 지원되지 않아 fallback 처리가 필요하고, WebP 디코딩이 브라우저에 따라 더 많은 CPU 자원을 소모 할 수도 있어 모바일 저사양 기기에서는 오히려 부하가 될 수 있다. 또한 WebP로 변환할 때 alt 태그 누락, 이미지 크기 비율 오류 등이 있으면 SEO나 접근성 측면에서도 문제가 생길 수 있다.
그러므로 무조건적인 포맷 전환보다는 환경에 따라 유연하게 대응하는 이미지 최적화 설계가 필요하다.
