Hampir setiap website sekarang menyajikan gambar dalam format WebP atau AVIF. Keduanya memang revolusioner dibanding JPEG dan PNG, tapi ada satu format yang secara teknis lebih unggul dan sayangnya belum masuk browser mainstream: JPEG XL.
JPEG XL punya potensi untuk menggantikan WebP dan AVIF sebagai format gambar default website — bukan karena selalu paling kecil dalam semua kondisi, tapi karena punya kombinasi efisiensi, HDR, dan fleksibilitas decode yang tidak dimiliki format lain.
Apa Itu JPEG XL?
JPEG XL adalah standar kompresi gambar lossless dan lossy yang disahkan sebagai ISO/IEC 18181:2019. Format ini dikembangkan oleh Google, berakar dari proyek internal bernama PIK, dan menggabungkan beberapa generasi format eksperimental: JPEG XT, FUIF, dan JPEG Rext.
Istilah “XL” merujuk pada posisinya sebagai “eXtra Large” — menandakan kapasitas dan kapabilitas yang melampaui JPEG dan WebP.
Format ini punya tiga mode operasi utama yang bisa dipilih per-file:
- Lossless — data piksel identik dengan sumber, hanya di-encode ulang secara lossless
- Lossy — kompresi visual seperti JPEG/WebP, dengan kualitas jauh lebih baik di bitrate rendah
- Modular — mode lossless modern yang mengungguli PNG dan WebP lossless secara konsisten
Yang menarik, satu file JXL bisa menggabungkan lossless dan lossy sekaligus. Ini memungkinkan elemen gambar yang butuh presisi (teks, logo, UI) dan bagian yang butuh kompresi agresif berada dalam satu aset.
Keunggulan Utama JXL untuk Penggunaan Website
1. Ukuran File Lebih Kecil Dibanding Format Lain
Di sinilah JXL menunjukkan namanya. Berikut perbandingan umum dari hasil benchmark kompresi gambar:
| Skenario | Selisih |
|---|---|
| Rekompresi lossless JPEG yang sudah ada | ~33% lebih kecil |
| Rekompresi lossless PNG | ~35% lebih kecil |
| Lossy pada kualitas setara WebP | ~20–30% lebih kecil |
| Lossy pada kualitas setara AVIF | Bervariasi, JXL unggul di bitrate sangat rendah |
Yang paling menarik secara praktis adalah rekompresi lossless. Website yang selama ini menyimpan gambar JPEG hasil upload fotografer atau penulis bisa memproses ulang gambar-gambar tersebut ke JXL tanpa kehilangan satu pun piksel, dan langsung hemat ruang penyimpanan serta bandwidth.
Untuk gambar screenshot, infografik, logo, dan ilustrasi yang di-raster, jalur ini hampir selalu menjadi kombinasi terbaik antara kualitas dan ukuran.
2. HDR Natif — Keunggulan yang Belum Dimiliki Format Lain
Ini pembeda utama JXL dari WebP dan bahkan AVIF. JXL mendukung:
- Float 16-bit (16-bit floating point per channel)
- Ruang warna Rec. 2020, jauh lebih lebar dari sRGB
- Transfer function PQ (Perceptual Quantizer) dan HLG (Hybrid Log-Gamma) untuk konten HDR
WebP yang masih standar saat ini hanya mendukung 8-bit SDR. AVIF bisa membawa profil HDR, tapi implementasinya jauh lebih lambat dan sering bermasalah di browser maupun di color management pipeline.
Praktisnya, gambar produk, foto landscape, dan konten malam hari yang diambil dari kamera atau smartphone modern punya informasi highlight dan shadow jauh lebih kaya dari yang bisa ditampung format 8-bit. JXL bisa membawa informasi itu utuh sampai ke layar yang mendukungnya.
Catatan penting: kualitas HDR hanya berarti jika layar, sistem operasi, dan browser di sisi pengguna juga mendukungnya. Untuk mayoritas pengguna saat ini, benefit HDR bersifat “siap di masa depan” — tapi ketika prevalensi browser sudah tinggi, JXL akan langsung berada di posisi yang tidak bisa dicapai format lain.
3. Progressive Decoding yang Jauh Lebih Cepat
JXL punya tiga mode progressive decoding:
- Scanline — decoding per baris, decode cepat
- Patch — decode sebagian gambar lebih awal
- LF-image (low-frequency image) — browser menampilkan versi kasar resolusi rendah seketika, lalu detailnya dimuat belakangan
Yang paling menarik adalah LF-image. Untuk gambar besar di koneksi lambat, pengguna melihat struktur dan komposisi gambar dalam hitungan milidetik, bukan menunggu数十 detik. Ini persis masalah yang paling sering dikeluhkan pengguna web — dan satu dari alasan utama format gambar progresif JFIF lama (yang berbasis JPEG) masih dipakai luas.
4. Kompresi Lossless yang Sangat Efisien
JXL lossless bukan sekadar “seperti PNG tapi lebih baik sedikit”. Di Mode Modular, JXL secara rutin mengalahkan PNG dan WebP lossless dengan selisih yang signifikan, kadang hingga 30% lebih kecil.
Aset yang paling boros ruang penyimpanan di website modern — screenshot dokumentasi, diagram, grafik, mockup UI, thumbnail produk yang ada teks — semuanya berada di kategori yang paling diuntungkan oleh jalur ini.
5. Backward Compatibility yang Rapi
JXL punya mekanisme codestream nesting. Artinya file JXL bisa memuat gambar JPEG atau PNG asli di dalamnya, sehingga:
- Browser lama yang tidak mendukung JXL otomatis akan menampilkan fallback JPEG/PNG
- Tidak perlu
<picture>dengan fallback manual untuk setiap aset - Migrasi dari WebP ke JXL bisa dilakukan bertahap tanpa risiko breaking
Ini membuat adopsi JXL jauh lebih aman dibanding preseden seperti AVIF, yang wajib satu set <picture> fallback lengkap.
6. Resolusi Arbitrer dan Reposisi Tanpa Kehilangan
JXL mendukung pemrosesan gambar pada resolusi berbeda dari resolusi aslinya dengan kualitas yang sangat baik. Artinya satu aset master bisa melayani beberapa ukuran thumbnail — task yang biasanya butuh beberapa file terpisah.
7. Animated WebP yang Lebih Ringan
Format animasi (GIF, animated WebP, AVIF) sangat butuh perbaikan. JXL menyediakan mode animasi yang:
- Ukurannya lebih kecil dibanding animated WebP pada durasi dan fps yang sama
- Mendukung alpha channel pada animasi (banyak format lama tidak)
- Hemat bandwidth untuk hero section yang bergerak
8. Ringan untuk Encode, Ringan untuk Decode
JXL sengaja dirancang agar proses decode (membaca gambar) jauh lebih ringan dibanding format lain di era mobile. Ini penting karena sebagian besar beban CPU mobile bukan di server, tapi di perangkat pengguna saat merender halaman.
Benchmark CPU decode yang dipublikasikan menempatkan JXL di posisi yang kompetitif dengan WebP dan lebih baik dari AVIF pada gambar yang sama.
Kekurangan JXL yang Perlu Diketahui
Secara jujur: format ini bukan selalu plug-and-play.
Dukungan Browser Belum Merata
| Browser | Status |
|---|---|
| Chrome (desktop & Android) | ✅ Mendukung penuh sejak Chrome 93 |
| Safari (macOS & iOS) | ✅ Mendukung sejak Safari 17 |
| Firefox | ⚠️ Belum diaktifkan secara default (image.jxl.enabled) |
| Browser lama / Edge versi lama | ❌ Tidak mendukung |
Firefox adalah satu-satunya browser mainstream besar yang masih menahan dukungan. Untuk pasar Indonesia, pangsa Chrome dan Edge dominan — tapi Safari mobile juga populer di perangkat iPhone.
Ekosistem Tooling Belum Matang
- Plugin Photoshop untuk ekspor JXL masih terbatas dibanding WebP
- Pipeline build (webpack, Vite, imagemagick) membutuhkan konfigurasi tambahan
- Perkakas review dan CMS bawaan sering tidak mengenali
.jxl
Overhead Encoding di Server
Walaupun decode-nya ringan, encode JXL butuh lebih banyak CPU dan waktu dibanding WebP atau AVIF di speed preset rendah. Untuk website dengan ribuan aset yang harus diproses ulang saat build, ini belum tentu sepadan.
Dukungan CDN Belum Merata
CDN dan layanan edge belum semua mendukung JXL di jalur optimasi otomatisnya. Image CDN besar yang biasanya mendeteksi format dan mengonversi on-the-fly belum tentu punya preset JXL.
Kapan JXL Menggantikan WebP dan AVIF?
Jawaban jujur: belum untuk sebagian besar kasus produksi hari ini.
Yang masuk akal dilakukan sekarang:
- Chrome + Safari + Edge = >90% pangsa pasar Indonesia. Kalau target audience Anda mayoritas pengguna Android/Windows/Apple device modern, JXL layak dipakai sebagai format primer dengan fallback WebP.
- Format Checking Otomatis. Gunakan
Acceptheader negotiation via<picture>+type="image/jxl". - JXL untuk aset yang paling relevan — screenshot, diagram, logo, infografik. Di sinilah rekompresi lossless memberi hasil paling signifikan dan risikonya paling rendah.
Yang belum masuk akal:
- Mengganti seluruh pipeline gambar ke JXL hanya karena “secara teknis lebih unggul”
- Mengabaikan WebP sebagai baseline yang wajib ada
- Mengabaikan AVIF untuk kasus-kasus yang butuh kompresi lossy maksimal
Rekomendasi Praktis
Strategi Bertingkat
Level 1 (Wajib) : JPEG / PNG asli, dioptimasi
Level 2 (Baseline) : WebP — universal support, aman
Level 3 (Tambahan) : AVIF — untuk lossy, butuh kompresi ekstra
Level 4 (Opional) : JXL — untuk aset lossless + saat HDR mass adoption terjadi
Contoh <picture> yang lengkap:
<picture>
<source type="image/jxl" srcset="/img/diagram.jxl">
<source type="image/avif" srcset="/img/diagram.avif">
<source type="image/webp" srcset="/img/diagram.webp">
<img src="/img/diagram.jpg" alt="Diagram arsitektur sistem" width="1200" height="675">
</picture>
Browser mengambil format pertama yang didukung. Safari dan Chrome akan mengambil JXL, Firefox turun ke WebP, browser lama ke JPEG.
Kapan Mulai Pakai
- Sudah pakai WebP → tambahkan JXL hanya jika trafik Anda besar dan Core Web Vitals jadi prioritas
- Baru mulai → mulai dari WebP, siapkan JXL sebagai layer tambahan nanti
- Fokus pada foto produk resolusi tinggi → eksplorasi AVIF dulu, JXL belum mendesak
- Banyak diagram & screenshot → JXL rekompresi lossless memberi ROI paling cepat
Tooling
# Encode lossless dari JPEG/PNG
cjxl input.png output.jxl -d 1
# Encode lossy pada target quality
cjxl input.jpg output.jxl -q 85
# Decode kembali ke PNG
djxl input.jxl output.png
Untuk batch processing, libjxl menyediakan cjxl dan djxl CLI yang bisa dipanggil dari script CI/CD.
Kesimpulan
JPEG XL adalah format gambar yang secara teknis paling lengkap yang pernah tersedia untuk web. Kombinasi ukuran file lebih kecil, HDR native, alpha channel, progressive decoding yang cepat, dan backward compatibility yang rapi membuatnya sangat menarik untuk builder website yang serius stumbled performa.
Tapi keputusan teknis tidak pernah berdiri sendiri. Dibanding WebP dan AVIF, dibanding Firefox yang masih menahan, dan dibanding realita tooling yang belum matang — keputusan terbaik biasanya bukan “pilih satu”, tapi “siapkan layer tambahan yang siap dipakai saat momentnya tiba”.
Untuk sementara: WebP adalah standar baru, AVIF adalah bonus, dan JXL adalah format promising yang sedang menunggu adopsi.
Artikel ini disusun berdasarkan spesifikasi ISO/IEC 18181:2019 dan hasil benchmark kompresi gambar yang dipublikasikan. Untuk keputusan teknis di proyek Anda, selalu ukur sendiri dengan aset nyata — angka benchmark umum jarang mencerminkan kondisi spesifik Anda.
Eksplorasi konten lain dari Oentoro
Berlangganan untuk dapatkan pos terbaru lewat email.