JPEG XL과 Core Web Vitals: Chrome 지원에 따라 알아야 할 사항

JPEG XL이 마침내 Chrome으로 돌아옵니다

3년간의 논란 끝에 JPEG XL이 Chromium으로 돌아왔습니다. 2026년 2월 초에 출시된 Chrome 145에는 JPEG XL 디코더가 탑재되어 있습니다. 여전히 플래그 뒤에 숨겨져 있지만, 2022년 말 논란이 되었던 제거 조치 이후 처음으로 코드베이스에 기능적으로 존재하게 되었습니다. 이것이 중요한 이유는 JPEG XL이 대부분의 기술적 측면에서 기존의 모든 웹 이미지 형식보다 명백히 우수하기 때문입니다. JPEG보다 50~60% 더 작고, 동일한 인코딩 속도에서 AVIF보다 압축률이 10~15% 더 우수하며, 진정한 점진적 디코딩(progressive decoding)을 지원하는 유일한 최신 형식입니다. 웹 성능 전문가들에게 있어 ISO 표준에서 Chrome에서의 퇴출, 그리고 부활에 이르는 이 형식의 궤적은 기술적 기회이자 브라우저 공급업체가 웹 플랫폼에 행사하는 권력에 대한 경고의 메시지를 모두 나타냅니다.

최종 검토: 2026년 2월 Arjen Karel

2026년 2월 기준 브라우저 지원율은 12%에 불과합니다

JPEG XL의 전 세계 실질적인 브라우저 지원율은 약 12%이며, 이는 거의 전적으로 Safari 사용자에서 비롯됩니다. 이 수치는 곧 바뀔 예정입니다. 하지만 그 시기는 아직 불확실합니다.

Safari 17 이상(2023년 9월 출시)은 macOS Sonoma, iOS 17, iPadOS 17, watchOS 및 visionOS 전반에서 네이티브 JPEG XL 디코딩을 제공합니다. Apple의 구현은 디코딩을 OS 수준의 이미지 프레임워크에 위임하므로 Safari가 실행되는 모든 곳에서 작동합니다. 하지만 Safari의 지원은 명백히 부분적입니다. JPEG XL의 가장 특징적인 기능 두 가지인 애니메이션 지원과 점진적 디코딩이 제공되지 않습니다. 이는 Apple 기기에서 해당 형식이 제공하는 온전한 가치를 저하시키는 의미 있는 한계입니다.

Chrome 145(2026년 2월)는 이전의 C++ libjxl 구현을 대체하는 jxl-rs라는 순수 Rust 디코더를 통해 JPEG XL을 다시 도입합니다. 해당 디코더는 chrome://flags/#enable-jxl-image-format 뒤에 막혀 있으며 기본적으로 활성화되어 있지 않습니다. Google은 장기적인 유지보수 약속과 표준 출시 기준 충족이라는 기본 활성화를 위한 명확한 조건을 설정했습니다. Rust 디코더는 현재 C++ 참조 구현 속도의 15~25% 수준으로 작동하며, 2025년 12월에만 26개의 최적화 PR이 병합되었습니다. 확인된 작동 기능으로는 ICC 색상 프로필, 애니메이션, 알파/투명도, 넓은 색 영역(Display P3) 및 HDR(PQ/HLG)이 있습니다.

오늘 바로 Chrome에서 JPEG XL을 사용해 보려면 chrome://flags/#enable-jxl-image-format으로 이동하여 Enabled로 설정하세요. 그런 다음 Chrome을 다시 시작합니다. 이미 JXL 이미지를 제공하고 있는 모든 사이트(예: Cloudinary 고객)가 브라우저에 이를 전송하기 시작할 것입니다.

Firefox는 여전히 가장 뒤처져 있습니다. 이 형식은 Firefox Nightly에서 image.jxl.enabled 플래그 뒤에서만 사용할 수 있습니다. 결정적으로, 디코더 코드가 안정 빌드에 전혀 컴파일되지 않으므로 정식 Firefox 릴리스에서는 플래그가 아무런 역할을 하지 않습니다. Mozilla의 입장은 "부정적"에서 "중립적"으로 바뀌었습니다. jxl-rs Rust 디코더가 Firefox Nightly(Firefox 149 대상)에 도입되었지만, 안정 버전에 출시되기 위해서는 6가지 해결해야 할 문제(색상 프로필 지원, 점진적 디코딩, HDR, 프로파일러 통합, 릴리스 빌드에서의 컴파일, Web Platform Tests 통과)가 남아 있습니다. 안정적인 지원을 위한 일정은 존재하지 않습니다.

Edge는 Chromium 파생 브라우저로서 Chrome 145의 jxl-rs 코드를 포함하고 있을 가능성이 높지만, JPEG XL 지원을 공식적으로 발표하거나 문서화하지 않았습니다. Edge 145 릴리스 노트에는 이에 대한 언급이 없습니다.

Interop 2026에는 JPEG XL이 (완전한 중점 분야는 아니지만) 조사 분야로 포함되었으며 Apple, Google, Microsoft, Mozilla가 모두 참여하고 있습니다. 이는 일반적으로 더 광범위한 출시에 앞서 진행되는 포괄적인 테스트 스위트를 구축하려는 벤더 간의 의도를 나타냅니다.

JPEG XL이 모든 대안보다 우수한 방법과 그렇지 않은 부분

압축 효율성 이야기는 미묘하며 콘텐츠 유형 및 비트레이트에 크게 의존합니다. 최고 수준에서 볼 때, JPEG XL은 가장 중요한 실제 환경 비교에서 우위를 점합니다.

JPEG와 비교

이점은 극적입니다. JPEG가 2.4 bpp를 요구하는 반면, JPEG XL은 픽셀당 약 1.2비트(bpp)에서 시각적으로 무손실 품질을 달성합니다. 2:1의 개선입니다. 990KB 사진에 대한 DebugBear 벤치마크에 따르면 JPEG XL은 472KB(52% 절감)로, WebP의 700KB 및 AVIF의 507KB와 비교됩니다. 40,000개 이상의 이미지에 대한 Cloudinary의 테스트에서는 JPEG XL이 effort 6에서 AVIF보다 20% 더 작은 파일을 생성하는 동시에 인코딩 속도는 2.5배 더 빠른 것으로 나타났습니다.

AVIF와 비교

비교는 비트레이트에 따라 달라집니다. 0.4 bpp 미만의 낮은 비트레이트(강한 압축)에서는 AVIF가 JPEG XL보다 우수합니다. 노이즈(artifact)가 적고 더 부드러운 이미지를 생성합니다. 하지만 대부분의 웹 사진이 존재하는 중간에서 높은 비트레이트(0.4 bpp 이상)에서는 JPEG XL이 세부 묘사 보존 및 충실도 측면에서 지속적으로 앞섭니다. Google 자체의 AVIF 비교 연구에 따르면, 실용적인 인코더 속도 설정에서 13개의 품질 메트릭 중 9개가 JPEG XL을 선호하는 것으로 나타났습니다. 인코딩 속도 차이는 엄청납니다. 단일 스레드 인코딩에서 AVIF(libaom 사용)는 JPEG XL보다 자릿수가 다를 정도로 느립니다. AVIF의 가장 느린 설정(~0.5 Mpx/s)은 52 Mpx/s인 JPEG XL의 두 번째로 빠른 설정의 압축 밀도와 일치합니다. 무려 100배의 속도 차이입니다.

WebP와 비교

JPEG XL이 결정적으로 승리합니다. WebP는 손실 모드에서 8비트 색상 심도, 4:2:0 크로마 서브샘플링, 그리고 16,383 x 16,383 픽셀의 최대 해상도로 제한됩니다. JPEG XL은 채널당 최대 32비트(정수 또는 부동 소수점), 한 면당 10억 픽셀을 초과하는 해상도를 지원하며, 크로마 서브샘플링 제약이 없습니다.

콘텐츠 유형의 중요성

특정 콘텐츠 유형의 경우 DebugBear 벤치마크에서 다소 엇갈린 결과가 나타났습니다. 로고(2KB 대 JXL의 6KB) 및 투명도 이미지(18KB 대 63KB)에서는 AVIF가 우승한 반면, 사진(472KB 대 507KB) 및 99%의 압축률을 달성한 애니메이션 콘텐츠(1.3MB GIF에서 14KB 달성, AVIF는 56KB)에서는 JPEG XL이 우승했습니다. 이 결과는 Cloudinary의 기본 설정을 사용했으므로 최적화된 결과라기보다는 일반적인 출력을 나타냅니다.

기능 비교

다른 어떤 형식도 따라올 수 없는 두 가지 기능

JPEG XL의 가장 전략적으로 중요한 기능은 점진적 디코딩과 무손실 JPEG 트랜스코딩입니다. 어떤 경쟁사도 이 두 가지를 제공하지 않습니다.

점진적 디코딩

점진적 디코딩은 이미지 로드 방식을 근본적으로 바꿉니다. JPEG XL 파일은 항상 최소 8x8 프로그레시브 방식입니다. DC(저주파) 프레임이 항상 먼저 인코딩됩니다. 파일 데이터의 약 1%만 다운로드해도 사용할 수 있는 전체 이미지 미리보기가 나타납니다. 첫 번째 스캔에 10~15%가 필요한 프로그레시브 JPEG와 비교해 보세요. 더 중요한 것은 JPEG XL이 돌출도 기반 점진적 디코딩(saliency ordered progression)을 지원한다는 것입니다. 머신러닝 모델이 시각적으로 가장 중요한 영역(인물 사진의 얼굴, 전자상거래의 제품 세부 정보 등)을 식별하고 해당 영역이 먼저 도착하도록 인코딩할 수 있습니다. 디코더는 완료된 영역과 아직 로드 중인 영역 사이의 경계를 부드럽게 처리합니다.

이는 다른 렌더링 타임라인을 만듭니다. AVIF는 디코딩을 시작하기 전에 압축된 전체 이미지가 필요합니다. 즉, 전체 시간은 다운로드 시간과 디코딩 시간이 순차적으로 더해진 것과 같습니다. JPEG XL은 전송과 디코딩을 겹치게 하여 사용자가 의미 있는 콘텐츠를 훨씬 더 빨리 볼 수 있게 합니다. Cloudinary는 JPEG XL의 점진적 렌더링이 별도의 저품질 이미지 자리 표시자(LQIP, Low Quality Image Placeholder) 파일에 대한 필요성을 없애 중복되는 바이트를 완전히 제거한다고 언급했습니다. 그러나 Safari의 현재 구현은 점진적 디코딩을 지원하지 않으므로, 이러한 이점은 향후 Chrome 및 Firefox 구현으로 제한된다는 점은 주목할 가치가 있습니다.

무손실 JPEG 트랜스코딩

무손실 JPEG 트랜스코딩은 JPEG XL의 숨겨진 강력한 기능입니다. 이 형식은 JPEG의 DCT 블록 계수를 자체 VarDCT 블록으로 직접 복사하여 엔트로피 코딩만 개선할 수 있습니다. 결과적으로 JXL 파일에서 원본 JPEG 파일을 비트 단위로 완벽하게 재구성(bit for bit reconstructable)할 수 있으면서 평균 파일 크기가 약 20% 감소(범위: 13~22%)합니다. 다른 어떤 형식도 이를 수행할 수 없습니다. WebP 또는 AVIF로 트랜스코딩하려면 픽셀로 디코딩하고 다시 인코딩해야 하므로 세대 손실(generation loss)이 발생합니다. Google Cloud Platform의 DICOM API는 이미 이 기능을 사용하여 의료 영상 파일 크기를 20% 줄이고 있습니다.

웹 규모에서 볼 때, 현재의 모든 JPEG를 JXL로 무손실 트랜스코딩한다면 대역폭 절감 효과는 엄청날 것입니다. JPEG XL 커뮤니티는 하루에 한 시간 동안 약 487,000가구의 미국 가정에 전력을 공급하는 것과 맞먹는 에너지 절감 효과가 있을 것으로 추산합니다.

이것이 Core Web Vitals에 갖는 의미

JPEG XL은 다양한 메커니즘을 통해 각 Core Web Vitals 메트릭에 영향을 미치며, 그 관계는 단순한 "더 작은 파일 = 더 나은 점수"보다 복잡합니다.

LCP (Largest Contentful Paint)

LCP는 두 가지 복합적인 효과로 이점을 얻습니다. 첫째, 더 작은 파일 크기는 다운로드 단계인 Resource Load Duration을 줄입니다. JPEG에 비해 52% 감소했다는 것은 대역폭이 제한된 연결에서 hero image가 약 두 배 더 빨리 도착한다는 것을 의미합니다. 둘째, JPEG XL은 AVIF보다 빠르게 디코딩되어 Element Render Delay를 줄입니다. AVIF의 복잡한 비디오 코덱 파생 디코딩은 모바일 기기에서 의미 있는 CPU 오버헤드를 유발할 수 있으며, 더 빠르게 다운로드되는 더 작은 AVIF의 장점이 더 긴 디코딩 시간으로 인해 부분적으로 상쇄될 수 있습니다. 최대 132 Mpx/s에 달하는 JPEG XL의 디코딩 속도와 SIMD 최적화는 이 병목 현상을 최소화합니다. 그러나 LCP는 이미지가 완전히 렌더링되었을 때 측정되므로 점진적 디코딩이 LCP 타임스탬프를 직접적으로 개선하지는 않습니다. 하지만 측정 지표를 변경하지 않더라도 user experience에 중요한 체감 성능을 향상시킵니다. JPEG XL이 LCP 이미지 형식인 경우, 브라우저가 가능한 한 빨리 발견할 수 있도록 미리 로드(preload)하세요.

CLS (Cumulative Layout Shift)

CLS는 형식과 무관합니다. 모든 형식은 명시적인 너비 및 높이 속성의 이점을 똑같이 누립니다. JPEG XL은 초기 헤더에 크기 정보를 인코딩하므로 이론적으로 브라우저가 공간을 더 빨리 할당하는 데 도움이 될 수 있지만, HTML에서 치수를 설정하는 것과 비교하면 실제적인 영향은 무시할 수 있는 수준입니다.

INP (Interaction to Next Paint)

INP는 메인 스레드에서 무거운 이미지 디코딩에 영향을 받을 수 있습니다. JPEG XL의 더 빠른 디코딩 및 SIMD 최적화는 AVIF보다 메인 스레드 차단이 적다는 것을 의미하지만, 최신 브라우저에서는 두 형식 모두 일반적으로 메인 스레드 외부에서 디코딩됩니다.

실제 환경에서의 영향

2025 Web Almanac에 따르면 JPEG는 모바일과 데스크톱 모두에서 여전히 LCP 이미지의 57%를 차지합니다. WebP는 2024년보다 4% 포인트 증가한 11%로 성장했습니다. AVIF는 0.7%에 불과합니다. JPEG XL은 아직 측정조차 되지 않았습니다. 일반적인 웹 페이지는 모바일에서 총 911KB에 달하는 19개의 이미지를 로드합니다. 이를 JPEG에서 JPEG XL로 변환하면 페이지당 대략 450~550KB를 절약할 수 있습니다. 데스크톱 이미지 무게의 중간값인 1,058KB의 경우 500~630KB 정도 절약됩니다.

CoreDash에서 모니터링하는 사이트 전체에서 최신 형식(AVIF 또는 WebP)으로 이미지를 제공하는 페이지는 81%의 우수한 LCP 비율을 보이는 반면, 여전히 JPEG에만 의존하는 페이지는 64%에 불과합니다. JPEG XL이 더 광범위한 브라우저 지원을 달성함에 따라 그 격차는 더욱 벌어질 것입니다. JXL 전송을 활성화한 후 RUM 데이터(Real User Monitoring data)를 모니터링하면 실제 사용자가 얼마나 많은 이점을 얻는지 정확히 알 수 있습니다.

오늘날 적절한 fallback과 함께 JPEG XL 제공하기

구현에는 계층적 전략이 필요합니다. HTML 이미지용 <picture> 요소, CSS 및 동적으로 참조되는 이미지를 위한 서버 측 콘텐츠 협상(content negotiation), 그리고 가능한 경우 CDN 자동화가 필요합니다.

picture 요소

<picture> 요소는 가장 깔끔한 클라이언트 측 접근 방식을 제공합니다. 브라우저는 <source> 요소를 위에서 아래로 평가하고 지원되는 첫 번째 형식을 사용합니다.

<picture>
  
  <source srcset="hero.avif" type="image/avif">
  <source srcset="hero.webp" type="image/webp">
  <img src="hero.jpg" alt="Description" width="1200" height="800"
       loading="lazy" decoding="async">
</picture>

이 이미지가 hero image이고 LCP 요소(LCP element)일 가능성이 높다면 loading="lazy"를 제거하고 fetchpriority를 high로 설정하세요. 절대 LCP 이미지를 지연 로드(lazy load)하지 마세요.

반응형 이미지(responsive images)의 경우, 각 소스에는 너비 설명자(width descriptor)가 포함된 고유한 srcset이 필요합니다. 이는 이미지당 12개 이상의 변형(3~4개 형식 x 3~4개 크기)이라는 조합의 폭발을 일으킵니다. 바로 이 부분에서 CDN 자동화가 필수적이 됩니다.

서버 측 콘텐츠 협상

서버 측 콘텐츠 협상은 Accept 헤더를 검사합니다. Safari 17 이상은 Accept 헤더에 image/jxl을 보냅니다. Nginx 구성은 이를 파일 확장자에 매핑합니다.

map $http_accept $img_ext {
    ~image/jxl   '.jxl';
    ~image/avif  '.avif';
    ~image/webp  '.webp';
    default      '';
}

중요한 세부 사항: CDN 및 프록시 캐시가 형식별로 별도의 변형을 저장하도록 응답 헤더에 항상 Vary: Accept를 포함하세요. 이렇게 하지 않으면 캐시된 JXL 응답이 이를 디코딩할 수 없는 브라우저에 제공됩니다.

CDN 지원

CDN 지원은 고르지 않습니다. Cloudinary는 f_auto 매개변수를 통해 완전한 JPEG XL 지원을 제공합니다. Cloudinary가 형식을 공동으로 만들었고 이미 하루에 약 10억 개의 JPEG XL 이미지를 전송하고 있다는 점을 감안하면 놀라운 일이 아닙니다. Fastly의 Image Optimizer는 2024년 7월에 4개의 스레드와 effort 3의 인코딩을 사용하여 완전한 JPEG XL 지원을 추가했으며, JPEG에 비해 약 60%의 절감 효과가 있다고 주장했습니다. Cloudflare는 강력한 커뮤니티의 요구에도 불구하고 자사의 Image Resizing 제품에서 JPEG XL 변환을 지원하지 않습니다. Vary: Accept를 통해 원본 서버에서 JXL 변형을 캐시할 수는 있지만 생성할 수는 없습니다. Cloudflare를 사용하는 경우 도움이 되는 설정에 대해 Core Web Vitals를 위한 Cloudflare 구성 가이드를 확인해 보세요. AWS CloudFront, Akamai 및 Azure는 네이티브 JPEG XL을 지원하지 않습니다.

도구 지원

JPEG XL 파일을 생성하기 위한 도구는 libjxl 참조 구현의 cjxl을 중심으로 합니다. 주요 매개변수: -d는 거리(0 = 무손실, 1.0~2.0 = 웹 품질 손실 압축), -e는 effort(1~9, 기본값 7), -p는 점진적 인코딩을 나타냅니다. JPEG 입력의 경우 cjxl input.jpg output.jxl은 기본적으로 무손실 트랜스코딩을 수행합니다. 가장 간단한 마이그레이션 경로입니다. ImageMagick, libvips(8.11 이후) 및 Photoshop v25도 JXL을 지원합니다. 하지만 Next.js를 구동하는 Node.js 이미지 라이브러리인 sharp는 v0.31.3부터 실험적인 JXL 지원을 제공하지만, npm을 통해 배포되는 사전 빌드된 바이너리에는 JXL 코덱이 포함되어 있지 않습니다. libjxl을 지원하도록 직접 libvips를 컴파일해야 하며, 유지 관리자는 사전 빌드된 JXL 바이너리에 대한 요청을 닫았습니다. 이는 Next.js가 기본적으로 실용적인 JPEG XL 지원을 제공하지 않는다는 것을 의미합니다. WordPress 코어 지원은 티켓 #52788로 추적되지만 실제 장애물은 PHP의 GD 확장이 JPEG XL을 지원하지 않는다는 것입니다. PHP 8.5(2025년 11월)에도 여전히 JXL에 대한 GD 지원이 부족합니다.

할로윈 결정과 3년 만의 번복

Chrome에서 JPEG XL의 정치적 역사는 웹 표준에 대한 브라우저 공급업체의 권력을 보여주는 사례 연구입니다. 이를 이해하는 것이 중요한 이유는 어떤 기술이 사용자에게 도달할지를 결정하는 힘을 보여주기 때문입니다.

2022년 10월 31일, 빠르게 "할로윈 결정(Halloween decision)"이라는 별명이 붙은 사건에서 Google Chrome 팀의 Jim Bankoski는 JPEG XL 실험적 지원 제거를 발표했습니다. 명시된 이유는 네 가지였습니다. 실험적 플래그가 무기한 유지되어서는 안 되며, 생태계의 관심이 불충분하고, 기존 형식에 비해 점진적인 이점이 부족하며, 유지보수에 부담이 된다는 것이었습니다. Bankoski는 Chrome에서 JPEG XL을 원하는 사람들을 위한 "훌륭한 앞으로의 길"로 WebAssembly를 제안했습니다.

반발은 즉각적이고 지속적이었습니다. 이 Chromium 이슈는 Intel, Adobe, Meta, Shopify, The Guardian, Flickr, Krita Foundation 대표들의 댓글과 1,000개 이상의 찬성(upvotes)을 받으며 프로젝트 전체 역사상 두 번째로 많은 별을 받은(starred) 이슈가 되었습니다. Cloudinary의 JPEG XL 공동 개발자인 Jon Sneyers는 구글이 발표한 비교 테스트가 버그가 있는 JPEG XL 구현을 사용했으며 측정 지표가 AVIF에 편향되어 있음을 보여주는 상세한 기술적 반박문("The Case for JPEG XL")을 발표했습니다. 자유 소프트웨어 재단(Free Software Foundation)은 Google의 결정이 Google Chrome이 웹 표준의 중재자가 되었다는 증거라고 말하며 회사가 자사의 이익을 위해 행동한다고 비난했습니다. AVIF는 Google이 공동 설립한 Alliance for Open Media에서 개발한 AV1에서 파생되었기 때문입니다.

관찰자들은 이러한 아이러니를 놓치지 않았습니다. Google 스스로가 PIK 프로젝트를 통해 JPEG XL을 공동으로 만들었기 때문에, 이를 Chrome에서 없애기로 한 결정은 더욱 혼란스러웠습니다. JPEG XL이 Interop 2024에 제안되었을 때 646개의 커뮤니티 반응을 얻었습니다. 이는 2위 제안의 4.5배에 달하는 수치입니다. 그리고 "합의 부족"이라는 설명만으로 거절되었습니다.

결국 이 결정을 번복하게 만든 것은 Chrome이 빠져 있는 것을 지속 불가능하게 만든 생태계의 모멘텀이었습니다. 2023년 9월 Apple이 JPEG XL 지원을 포함한 Safari 17을 출시한 것이 첫 번째 주요 전환점이었습니다. Mozilla가 "부정적"에서 "중립적"으로, 그리고 적극적으로 (Rust 디코더를 사용하여) 구현할 의향이 있는 상태로 전환한 것이 압박을 더했습니다. 2025년 10월 PDF Association이 JPEG XL을 PDF의 선호 HDR 형식으로 발표한 것이 전환점이 되었을 수도 있습니다. Chrome의 내장 PDF 뷰어가 표준을 준수하려면 JXL 지원이 필요했을 것입니다. 2025년 11월 21일, Rick Byers(Chrome Architecture Tech Lead)는 번복을 게시하며 Chromium에 성능이 뛰어나고 메모리 측면에서 안전한 JPEG XL 디코더를 통합하기 위한 기여를 환영했습니다. 2026년 1월까지 Rust 기반 jxl-rs 디코더가 병합되었고, 2026년 2월 Chrome 145에서 플래그 뒤에 숨겨진 채로 출시되었습니다.

결론: 고품질 원본을 저장하고, 필요에 따라 변환하세요

JPEG XL은 기술적으로 사용할 수 있는 최고의 범용 이미지 형식입니다. 실용적인 인코딩 속도에서 AVIF보다 더 나은 압축률, 어떤 경쟁사도 제공하지 않는 점진적 디코딩, 품질 손실 없이 즉시 20%의 용량을 절감할 수 있는 무손실 JPEG 트랜스코딩을 제공합니다. 3년 동안 채택을 가로막았던 정치적 장애물이 해소되고 있습니다. Chrome의 소스 트리에 코드가 추가되었고, Firefox는 동일한 Rust 디코더를 적극적으로 통합하고 있으며, Safari는 2023년부터 지원을 시작했습니다.

앞으로의 실용적인 경로는 가능한 최고 품질의 원본 자료를 저장하고 전송 파이프라인(delivery pipeline)이 형식 변환을 처리하도록 하는 것입니다. 무손실 PNG 또는 고품질 마스터 JPEG를 원본으로 유지하세요. 형식 자동 협상을 지원하는 CDN을 사용하세요. Cloudinary의 f_auto, Fastly Image Optimizer 또는 Cloudflare Polish는 브라우저의 Accept 헤더를 검사하고 단일 변형을 미리 생성하지 않아도 JXL, AVIF, WebP 또는 JPEG를 제공합니다. 자체 호스팅하는 경우, 서버 측 캐시 뒤에 libvips 또는 ImageMagick을 사용하여 온디맨드 변환을 설정하고 이미지당 4개의 변형을 일괄 생성하는 대신 첫 번째 요청 시 형식별로 한 번씩 변환하세요. JPEG XL의 무손실 트랜스코딩은 이 모델에 완벽하게 들어맞습니다. 기존 JPEG가 소스이며 이를 JXL로 변환하는 것은 품질 손실이 전혀 없는 효과적인 온디맨드 변환입니다. 남은 질문은 JPEG XL이 광범위한 브라우저 지원을 달성할 것인지가 아니라 Chrome이 언제 기본값으로 플래그를 켤 것인지입니다. 유일하게 정직한 대답은 아직 일정이 발표되지 않았다는 것입니다. Chrome에서 3년 동안 추방되었던 이 형식에 대한 열정은 실용주의와 함께 조절되어야 합니다. 지원되는 곳에서는 제공하고 다른 곳에서는 우아하게 fallback으로 처리하며 나머지는 CDN 또는 변환 파이프라인에서 처리하도록 하세요.