Selama bertahun-tahun, satu hal yang paling sering menggemukkan halaman web bukanlah JavaScript, melainkan gambar. Di banyak situs pemerintahan desa, sekolah, dan toko online yang kami kelola, foto produk dan banner sering menyumbang 60–80% dari total berat halaman. Format JPEG sendiri sudah berumur lebih dari tiga dekade. Kabar baiknya: pada 6 Oktober 2026, tim Chrome mengumumkan bahwa Chrome 155 resmi mendukung dekode JPEG XL (.jxl) — dan itu membuka jalan untuk memangkas berat gambar secara signifikan tanpa mengorbankan kualitas.

Apa yang berubah di Chrome 155

Menurut pengumuman resmi Chrome for Developers, JPEG XL menawarkan kompresi 30–50% lebih baik dibanding JPEG, mendukung kompresi lossless, HDR bawaan, serta lossless JPEG transcoding — yakni kemampuan mengubah JPEG lama menjadi .jxl tanpa kehilangan satu piksel pun. Dukungan ini aktif secara default di Chrome desktop dan Android mulai milestone 155, tanpa perlu mengaktifkan flag eksperimental.

Yang menarik dari sisi rekayasa: Chrome tidak memakai decoder C++ lama, melainkan jxl-rs, implementasi ulang decoder JPEG XL dalam Rust. Alasannya klasik — decoder gambar adalah salah satu permukaan serangan paling rawan di browser karena memproses data biner tak tepercaya langsung dari jaringan. Tim Chrome melaporkan bahwa sepanjang riwayat pengembangan jxl-rs, setelah pengujian fuzzing dan tinjauan kode dengan AI, tidak ditemukan bug memory safety. Agar tetap cepat, mereka menstabilkan fitur Rust target_feature_11 supaya instruksi SIMD bisa dipakai tanpa blok unsafe. Pelajaran yang bisa dibawa ke proyek kita sendiri: menulis decoder atau parser dalam bahasa memory-safe kini bukan lagi kemewahan, tapi cara termurah menghindari kelas bug yang paling mahal.

Praktik 1: ubah JPEG lama tanpa kehilangan kualitas

Cara paling aman mencoba JPEG XL hari ini adalah pada arsip foto. Pasang alat resmi libjxl, lalu konversi:

# Debian/Ubuntu
sudo apt install libjxl-tools

# JPEG -> JXL, defaultnya lossless recompression
cjxl foto-lama.jpg foto-lama.jxl

# balik lagi ke JPEG asli (bit-per-bit) bila perlu
djxl foto-lama.jxl foto-kembali.jpg

Untuk file JPEG, cjxl memang default menerapkan kompresi lossless, dan djxl dapat merekonstruksi JPEG aslinya. Artinya Anda bisa menguji penghematan ruang pada galeri foto kegiatan atau arsip dokumen tanpa risiko penurunan mutu sama sekali.

Praktik 2: encode ulang PNG dan foto dengan target kualitas

Untuk gambar baru, atur tingkat kualitas secara eksplisit. Parameter --distance memakai satuan just-noticeable difference: 0 berarti lossless, dan rentang lossy yang paling berguna ada di 0.5 sampai 3.0. Alternatifnya, --quality memakai skala 0–100 yang kurang lebih setara libjpeg. Naikkan --effort bila ingin file lebih kecil dengan waktu encode lebih lama:

# foto hero: kualitas tinggi, ukuran jauh lebih kecil dari JPEG
cjxl banner-desa.png banner-desa.jxl --distance 1.0 --effort 7

# ilustrasi atau logo: benar-benar lossless
cjxl logo-sekolah.png logo-sekolah.jxl --distance 0 --effort 7

Rekomendasi tim Chrome: uji AVIF dan JPEG XL berdampingan, lalu pilih yang paling pas. JPEG XL unggul terutama untuk kompresi high-fidelity atau lossless, foto, dan kebutuhan decoding progresif bertahap — cocok untuk galeri besar yang dibuka lewat jaringan seluler lambat.

Praktik 3: sajikan dengan fallback, jangan asal ganti ekstensi

Karena dukungan baru ada di Chrome, situs tetap harus punya cadangan. Gunakan elemen <picture> dengan atribut type; browser yang tidak mengenal image/jxl akan otomatis melewati sumber pertama dan memakai WebP atau JPEG:

<picture>
  <source srcset="/img/banner-desa.jxl" type="image/jxl">
  <source srcset="/img/banner-desa.webp" type="image/webp">
  <img src="/img/banner-desa.jpg" alt="Kantor desa" width="1200" height="630" loading="lazy">
</picture>

Jangan pernah sekadar mengganti nama .jpg menjadi .jxl: isi file tidak berubah dan browser akan gagal menampilkannya. Pastikan juga server mengirim MIME type yang benar. Di Nginx, mime.types bawaan versi 1.26 yang kami pakai sudah memuat image/avif dan image/webp, tetapi belum image/jxl, sehingga perlu ditambahkan manual:

# di dalam blok http { } pada nginx.conf
types {
    image/jxl  jxl;
}

Setelah itu uji dengan curl -I https://domain-anda/img/banner-desa.jxl dan pastikan responsnya Content-Type: image/jxl, bukan application/octet-stream.

Kapan sebaiknya belum pindah

Jangan buru-buru mengubah seluruh aset produksi. Tiga hal yang perlu diukur dulu: waktu decode di ponsel Android kelas menengah (bukan hanya laptop kantor), dukungan di browser lain yang dipakai warga, dan beban CPU server bila Anda mengencode ribuan gambar. Mulai dari aset statis paling berat — banner hero, galeri kegiatan, foto produk — lalu bandingkan ukuran file dan skor Lighthouse sebelum-sesudah. Pendekatan bertahap ini jauh lebih aman daripada migrasi serentak yang berakhir dengan gambar rusak di perangkat pengguna.

Sumber: Shipping JPEG XL in Chrome (Chrome for Developers, 6 Oktober 2026); Chrome Platform Status: JPEG XL decoding (image/jxl), milestone 155; libjxl: dokumentasi cjxl/djxl.