Setelah bertahun-tahun jadi format "yang katanya bagus tapi tidak didukung browser mana pun", JPEG XL akhirnya resmi masuk Chrome. Mulai Chrome 155, browser Google itu bisa men-decode file .jxl secara native, diumumkan tim Chrome for Developers pada 6 Oktober 2026. Bagi pengelola website, terutama situs instansi dan desa yang penuh foto kegiatan, ini artinya satu jalur baru untuk memangkas berat halaman tanpa mengorbankan kualitas gambar.

Apa yang ditawarkan JPEG XL

Menurut pengumuman resmi Chrome, JPEG XL menawarkan kompresi 30–50% lebih baik dibanding JPEG, mendukung kompresi lossless, HDR bawaan, progressive decoding yang halus, serta lossless JPEG transcoding. File JPEG lama bisa dikonversi ke JXL dan dikembalikan lagi ke JPEG tanpa perubahan piksel sama sekali.

Yang menarik, Google tidak menyarankan JXL sebagai pengganti AVIF. Rekomendasi mereka justru: coba keduanya. AVIF unggul untuk kompresi agresif berukuran kecil, sementara JPEG XL paling berguna untuk kompresi high-fidelity atau lossless, foto beresolusi besar, dan kasus yang butuh decoding bertahap (gambar muncul kasar dulu, lalu makin tajam).

Contoh di lapangan: foto kegiatan 4000 piksel yang biasanya jadi sekitar 1,8 MB sebagai JPEG kualitas 85 bisa turun cukup jauh sebagai JXL pada kualitas visual setara. Untuk situs dengan ratusan foto galeri, penghematan kuota hosting dan bandwidth-nya terasa langsung.

Decoder-nya ditulis ulang pakai Rust

Bagian teknis yang paling layak dicatat developer: Chrome tidak memakai ulang decoder C++ (libjxl), melainkan mengintegrasikan jxl-rs, implementasi decoder JPEG XL murni Rust. Alasannya keamanan: decoder gambar adalah salah satu permukaan serangan paling rawan di browser karena memproses data biner tak tepercaya dari jaringan.

Agar tetap cepat, tim Chrome menstabilkan fitur bahasa Rust target_feature_11 supaya instruksi SIMD bisa dipakai tanpa blok unsafe, lalu membangun lapisan abstraksi SIMD bernama jxl_simd. Pengujian mereka memakai fuzzing dan review kode berbantuan AI. Sepanjang riwayat implementasi, tidak ditemukan satu pun bug memory safety. Pelajaran untuk kita yang menulis layanan publik sederhana: pilihan bahasa bukan soal selera, tapi soal kelas bug yang mau dihindari.

Status dukungan browser per November 2026

• Chrome 155+ (desktop) dan Chrome Android 156+: mendukung penuh gambar diam.
• Firefox 158+: tercatat mendukung di data caniuse.
• Safari 27.x: dukungan sebagian, yaitu gambar diam bisa, animasi dan progressive decoding belum.
• Edge dan browser lain: belum seragam, jadi fallback tetap wajib.

Cara memasang JPEG XL tanpa merusak tampilan

Jangan ganti semua <img> jadi .jxl. Pakai elemen <picture> supaya browser yang belum mendukung otomatis mengambil file lama:

<picture>
  <source srcset="/img/kegiatan-2026.jxl" type="image/jxl">
  <source srcset="/img/kegiatan-2026.webp" type="image/webp">
  <img src="/img/kegiatan-2026.jpg" alt="Rapat koordinasi desa"
       width="1200" height="800" loading="lazy">
</picture>

Urutannya penting: format paling efisien di atas, fallback paling kompatibel di bawah. Browser memilih <source> pertama yang tipenya ia kenal, sisanya diabaikan.

Membuat file .jxl dari gambar yang sudah ada

Encoder resminya ada di paket libjxl (di Debian/Ubuntu tersedia sebagai libjxl-tools):

# konversi kualitas tinggi (mendekati visual lossless)
cjxl foto-kegiatan.jpg foto-kegiatan.jxl -d 1 -e 7

# benar-benar lossless
cjxl logo.png logo.jxl -d 0

# bandingkan ukuran sebelum dan sesudah
ls -lh foto-kegiatan.jpg foto-kegiatan.jxl

Untuk foto JPEG lama, transcoding lossless membuat file lebih kecil tanpa perlu encode ulang. Tidak ada penurunan kualitas generasi kedua. Setelah itu ukur hasil akhirnya dengan Lighthouse atau PageSpeed Insights, jangan cuma percaya angka dari artikel.

Satu jebakan server yang sering terlewat

Chrome hanya mau men-decode JXL kalau server mengirim MIME type yang benar, yaitu image/jxl. Di server kami sendiri, daftar MIME bawaan Nginx ternyata belum memetakan ekstensi jxl. Akibatnya, file dikirim sebagai application/octet-stream dan browser menolaknya. Perbaikannya sederhana: tambahkan pemetaan image/jxl jxl; di dalam blok types pada konfigurasi Nginx, lalu reload layanan web.

Uji header-nya dengan curl -I https://domain-anda.go.id/img/foto.jxl. Hasilnya harus menampilkan content-type: image/jxl. Ini kesalahan klasik yang sama seperti masa awal WebP dulu.

Strategi adopsi yang masuk akal

1. Mulai dari gambar terberat: hero image, galeri kegiatan, banner beranda. Itu yang paling terasa dampaknya.
2. Simpan master PNG/JPEG asli; hasilkan turunan JXL, AVIF, dan WebP lewat skrip otomatis saat upload.
3. Selalu sertakan fallback JPEG dan atribut width/height agar layout tidak bergeser.
4. Untuk situs instansi yang diaudit, catat perubahan ini di dokumentasi teknis, karena format gambar baru sering ditanya saat pemeriksaan kinerja dan keamanan.

Kesimpulannya: JPEG XL bukan lagi eksperimen. Dukungan Chrome 155 membuatnya layak masuk pipeline produksi, asalkan dipasang dengan fallback yang benar dan MIME type server yang sudah diperbaiki. Format yang lebih kecil berarti halaman lebih cepat, kuota lebih hemat, dan pengunjung di jaringan lambat, yang justru banyak di daerah, mendapat pengalaman yang jauh lebih baik.

Sumber: Shipping JPEG XL in Chrome, Chrome for Developers, 6 Oktober 2026; caniuse: JPEG XL (JXL) image format; MDN Blog: Image formats, codecs and compression tools.