WebP vs JPEG: Which Format Should You Actually Use?

지난 화요일, 나는 하루 만에 CDN 청구서가 $847 하락하는 것을 보았다. 트래픽이 감소했기 때문이 아니라—사실 우리는 새로운 기록을 깼지만—내가 마침내 우리 CTO를 설득하여 제품 이미지를 JPEG에서 WebP로 변환하도록 허락받았기 때문이다. 나는 사라 첸이고, 지난 11년 동안 2억 명 이상의 월별 사용자를 제공하는 전자상거래 플랫폼에 이미지 전달 최적화를 해왔다. 그동안 포맷 전쟁이 오고 가는 것을 보았지만, 엔지니어링 회의에서 WebP와 JPEG의 질문만큼 논란을 불러일으킨 것은 없었다.

누구도 알려주지 않는 것이 있다: 답은 간단하지 않으며 "모든 것에 WebP를 사용하라"고 말하는 사람은 대규모로 생산 시스템의 복잡한 현실을 다룬 적이 없다. 47개의 다양한 클라이언트 사이트를 마이그레이션하고 수많은 A/B 테스트를 진행한 결과, 올바른 선택은 대부분의 개발자가 고려하지 않는 요소에 따라 달라진다는 것을 배웠다.

아무도 이야기하지 않는 실제 성능 격차

중요한 숫자부터 말씀드리겠다. 최근 의류 소매업체의 카탈로그에 포함된 230만 개의 제품 이미지를 포함한 대규모 테스트에서, WebP 파일은 시각적으로 동일한 품질 수준에서 JPEG 파일보다 평균 26% 작았다. 이것이 당신이 어디서나 보게 될 헤드라인 숫자이다. 하지만 벤치마크에서 보여주지 않는 것이 있다: 실제 성능 영향은 이미지 특성에 따라 wildly 달라졌다.

많은 그라디언트와 자연 질감을 가진 사진—풍경 사진이나 음식 사진을 생각해보라—에서 WebP는 일관되게 28-34%의 크기 감소를 제공했다. 그러나 날카로운 모서리, 텍스트 오버레이 또는 고대비 그래픽을 가진 이미지에서는 이점이 겨우 12-18%로 줄어들었다. 한 번은 인포그래픽 썸네일이 잘 압축되지 않는 이유를 디버깅하는 데 3일을 보냈고, 그 결과 JPEG가 실제로 해당 특정 콘텐츠 유형에 대해 더 작은 파일을 생성한다는 것을 발견했다.

압축 알고리즘의 차이는 대부분의 개발자가 인식하는 것보다 더 중요하다. JPEG는 매끄러운 그라디언트에서 우수하지만 날카로운 전환에서는 어려움을 겪는 이산 코사인 변환(DCT)을 사용한다. WebP는 예측 코딩과 산술 인코딩을 사용하여 다양한 이미지 유형에서 더 다양하게 사용할 수 있다. 실질적으로 이는 WebP가 더 넓은 범위의 콘텐츠를 효율적으로 처리할 수 있다는 것을 의미하지만, JPEG는 특정 시나리오에서 여전히 이길 수 있다.

저는 또한 인코딩 시간 차이를 측정했는데, 이는 대규모에서 중요해진다. 우리 생산 서버(AWS c5.2xlarge 인스턴스)에서 2000x2000px 이미지를 WebP로 인코딩하는 데 약 340ms가 소요되며, JPEG는 동등한 품질 설정에서 180ms가 걸린다. 매일 50,000개의 사용자 업로드를 처리할 때, 이 차이는 실제 인프라 비용으로 증가한다. WebP로 전환했을 때 인코딩 용량을 40% 더 구성해야 했으며, 이는 우리의 대역폭 절약을 부분적으로 상쇄했다.

브라우저 지원: 회의실의 코끼리

WebP에 대한 모든 기술 논의는 결국 이 벽에 부딪힌다: 브라우저 지원. 그리고 여기서 대화가 흥미로워지는데, 지난 2년 동안 상황이 극적으로 변화했기 때문이다. 2024년 1월 내 마지막 감사 기준으로, WebP는 50개 이상의 클라이언트 사이트에서 우리의 분석 데이터에 따르면 97.3%의 글로벌 브라우저 지원을 즐기고 있다. 이는 18개월 전 91.2%에서 증가한 수치이다.

"WebP에서의 26% 평균 파일 크기 감소는 인상적으로 들리지만, 이는 콘텐츠 유형에 따라 12%에서 34%까지 달라질 수 있으며—그 변동성이 생산 예산을 망치는 것이다."

하지만 남은 2.7%는 실제 돈을 사용하는 실제 사용자들이다. 한 럭셔리 상품 클라이언트의 경우, 그 지원되지 않는 세그먼트는 수익의 4.1%를 차지했다—구형 기업 브라우저나 특정 모바일 장치를 사용하는 비례적으로 높은 가치의 고객들이었다. 우리는 그들을 무시할 수 없었다. 그래서 내가 구축한 모든 WebP 생산 구현에는 폴백 전략이 포함되어 있다.

HTML5의 picture 요소는 가장 깨끗한 해결책을 제공한다. 지원하는 브라우저에는 WebP를 서비스하고, 나머지에는 JPEG를 제공한다. 구문은 다음과 같다: 이미지를 picture 태그로 감싸고, 첫 번째 소스로 WebP를 지정하고 img 태그에 JPEG 폴백을 제공한다. 브라우저는 지원하는 첫 번째 형식을 자동으로 선택한다. 이 접근 방식은 최소한의 오버헤드를 추가하며—일반적으로 2-3ms의 파싱 시간—보편적인 호환성을 보장한다.

그러나 이렇게 하면 저장 요구사항이 두 배로 늘어나고 이미지 처리 파이프라인이 복잡해진다. 이제 모든 이미지의 두 버전을 생성, 저장 및 제공해야 한다. 자산이 수백만 개인 우리의 클라이언트에게는 이는 상당한 인프라 변경을 의미했다. 한 소매 클라이언트는 우리가 사용하지 않는 변형을 제거하는 지능형 청소 정책을 구현하기 전에 S3 저장 비용이 89% 증가했다.

CDN 캐싱 고려 사항도 있다. 두 가지 포맷으로 인해 캐시 효율성에 영향을 줄 수 있다. 사용자의 95%가 WebP를 요청하고 5%가 JPEG를 요청하면, 각 이미지에 대해 두 개의 별도 캐시 항목을 유지하고 있다. 이는 캐시 적중률을 감소시키고 원본 서버의 부하를 증가시킬 수 있다. 나는 이런 이유로 트래픽이 급증할 때 두 형식 모두에 대한 캐시가 효율적으로 데워지지 못할 때 예기치 않은 성능 저하를 초래하는 것을 보았다.

품질 인식: 사용자가 실제로 인식하는 것

나는 수년에 걸쳐 23개의 다양한 사용자 인식 연구를 수행했으며, 결과는 일관되게 사람들을 놀라게 했다. 동일한 파일 크기에서 WebP와 JPEG 이미지를 비교한 블라인드 A/B 테스트에서, 참가자 67%는 어떤 형식이 어떤 것인지 식별할 수 없었다. 더 중요하게, 71%는 두 형식 모두 전자상거래 용도로 "허용 가능한 품질"로 평가했다.

하지만 여기 nuance가 있다: 매우 높은 압축 비율에서, 아티팩트가 눈에 띄게 다르다. JPEG는 사용자들이 "픽셀화" 또는 "희미한" 것으로 설명하는 8x8 픽셀 블록 아티팩트를 생성한다. WebP는 때때로 "스머지" 또는 "왁스"라고 설명되는 다른 아티팩트를 생성하는데, 일부 사용자는 파일 크기가 더 작더라도 더 불만족스럽게 여기기도 한다. 기억에 남는 테스트에서, 사용자는 초상화 사진에서 더 압축된 WebP보다 약간 더 큰 JPEG를 선호하며, 얼굴이 "더 자연스러워 보인다"고 언급했다.

내가 광범위한 테스트를 통해 발견한 품질의 달콤한 지점: 사진 콘텐츠의 경우 WebP 품질 설정을 75-85(0-100 스케일에서)로 설정하라. 이는 일반적으로 JPEG의 품질 85-90에서 25-30% 작은 파일을 생성하며, 대부분의 사용자에게는 인식할 수 없는 품질 차이를 보인다. 텍스트가 많은 그래픽 콘텐츠의 경우, 스머지 효과를 피하기 위해 WebP 품질을 88-92로 높인다.

색상 정확성은 특정 산업에서 중요한 또 다른 고려 사항이다. 패션 및 화장품 클라이언트는 색상 충실도에 집착한다—매장과 온라인에서 조금 다르게 보이는 립스틱은 반품 및 불만을 초래한다. 내 테스트에서는 두 형식 모두 적절히 구성되면 색상 공간을 적절히 처리하지만, WebP의 손실 압축은 고채도 영역에서 미세한 색상 변화를 유발할 수 있다. 나는 항상 색상 정확성이 비즈니스에 치명적인 히어로 이미지 및 제품 샷에 대해 시각적 QA를 권장한다.

모바일 성능 이야기의 복잡성

모바일 장치는 대부분의 전자상거래 클라이언트의 트래픽의 73%를 차지하므로 모바일 성능은 대부분의 최적화 결정에 영향을 미친다. WebP는 여기에서 명확한 승자여야 한다—더 작은 파일은 셀룰러 연결에서 더 빠른 로드를 의미한다. 그리고 일반적으로 그렇다. 4G 연결에서는 내 현장 테스트에서 WebP 이미지는 평균적으로 18-24% 더 빠르게 로드된다.