Chrome mulai menyertakan dukungan dekode untuk format gambar JPEG XL dengan ekstensi .jxl mulai Chrome 155, sesuai pengumuman resmi yang diterbitkan 6 Oktober 2026. Menurut blog Chrome for Developers, format ini menawarkan kompresi 30 sampai 50 persen lebih baik dibanding JPEG, mendukung kompresi lossless, HDR bawaan, serta transcoding JPEG tanpa kehilangan data. Decoder-nya ditulis ulang dari nol dalam bahasa Rust demi keamanan memori.
TL;DR
- Chrome 155 adalah versi pertama yang mendekode JPEG XL (.jxl) secara bawaan.
- Kompresinya diklaim 30 sampai 50 persen lebih efisien dibanding JPEG, dengan opsi lossless.
- Decoder baru bernama jxl-rs ditulis dalam Rust, bukan C++, untuk menekan risiko kerentanan memori.
- Google menyarankan mencoba AVIF dan JPEG XL berdampingan, lalu memilih sesuai karakter gambar.
- JPEG XL menonjol untuk gambar fotografi berkualitas tinggi dan kompresi lossless.
Apa yang baru di Chrome 155 terkait JPEG XL?
Chrome 155 menambahkan kemampuan mendekode berkas .jxl secara langsung di peramban, sehingga gambar JPEG XL bisa ditampilkan tanpa polyfill atau pustaka JavaScript tambahan. Pengumuman ini menutup penantian panjang komunitas web, karena JPEG XL sempat menjadi usulan populer dalam proses Interop selama beberapa tahun sebelum akhirnya dikirim.
Yang menarik, ini bukan sekadar menyalakan flag fitur lama. Tim Chrome membangun ulang jalur dekode dari awal dengan implementasi Rust bernama jxl-rs, lalu mengintegrasikannya ke dalam renderer. Menurut blog tersebut, keputusan mengirim JPEG XL didasarkan pada umpan balik konsisten dari pengembang web, terutama lewat Interop Process, tempat format ini menjadi proposal populer pada 2026 dan tahun-tahun sebelumnya. Untuk memastikan interoperabilitas antar-peramban, tim ikut dalam Interop 2026 JPEG XL Investigation agar cakupan pengujian seluruh fitur JPEG XL tersedia dan lulus di Chrome.
Berapa besar penghematan ukuran berkas JPEG XL dibanding JPEG?
Blog Chrome menyebut kompresi JPEG XL sekitar 30 sampai 50 persen lebih baik dibanding JPEG, dan angka itu berlaku umum untuk gambar fotografi. Selain lebih kecil, format ini juga mendukung kompresi lossless serta transcoding JPEG lossless, artinya berkas JPEG lama bisa dipindahkan ke wadah JPEG XL tanpa generasi ulang yang menurunkan kualitas.
Angka 30 sampai 50 persen itu penting karena kompresi adalah salah satu tuas terbesar untuk performa web. Halaman yang memuat gambar lebih ringan cenderung punya Largest Contentful Paint lebih baik, yang berdampak langsung pada pengalaman pengguna dan metrik Core Web Vitals. Namun perlu dicatat, keunggulan ini tidak otomatis muncul: ia bergantung pada encoder yang dipakai, tingkat kualitas yang ditetapkan, dan karakter gambar. Foto dengan gradasi halus biasanya paling diuntungkan, sementara ikon sederhana bisa lebih efisien dengan format vektor.
Google sendiri tidak memposisikan JPEG XL sebagai pengganti tunggal semua format. Dalam pengumuman yang sama, mereka menyarankan mencoba AVIF dan JPEG XL untuk melihat hasil terbaik, dan memperkirakan JPEG XL paling membantu untuk kompresi high-fidelity atau lossless, khususnya pada gambar fotografi atau ketika dekode progresif yang halus lebih diutamakan.
Mengapa decoder JPEG XL ditulis ulang dalam bahasa Rust?
Decoder gambar adalah salah satu permukaan serangan paling kritis di peramban modern, karena ia memproses struktur biner kompleks dari jaringan dan berjalan di dalam proses renderer. Decoder lama yang ditulis dalam bahasa tanpa jaminan memori seperti C++ rawan terhadap out-of-bounds read, heap overflow, dan use-after-free. Untuk memangkas risiko itu di sumbernya, tim Chrome mengintegrasikan jxl-rs, implementasi decoder JPEG XL murni Rust.
Masalahnya, decoder yang aman tapi lambat bukan pilihan yang menarik. Karena itu tim menempuh beberapa langkah teknis agar keamanan tidak mengorbankan performa. Fitur bahasa target_feature_11 pada Rust distabilkan agar instruksi SIMD bisa dipakai tanpa kode unsafe, lalu dibangun lapisan abstraksi SIMD bernama jxl_simd yang terinspirasi pustaka C++ Highway, yang sebelumnya dikembangkan untuk libjxl. Kombinasi ini memungkinkan pustaka multiplatform yang tetap memakai optimasi SIMD, sementara operasi unsafe dibatasi pada sedikit titik yang diaudit ketat.
Hasilnya diklaim kuat: menurut blog tersebut, tim memverifikasi jxl-rs memakai beragam teknik mutakhir termasuk fuzzing dan tinjauan kode berbantuan AI, dan tidak menemukan satu pun bug keamanan memori sepanjang riwayat implementasinya. Ini menjadi contoh konkret argumen bahwa Rust memberi perbaikan besar untuk keamanan memori pada kode yang menangani input tak tepercaya. Performa implementasi Rust ini juga dilacak terbuka pada dasbor performa jxl-rs di jxl-rs-perf.lucaversari.it.
Bagaimana perbandingan AVIF dan JPEG XL untuk web?
AVIF dan JPEG XL sama-sama format generasi baru, tetapi kekuatannya berbeda. AVIF sudah lebih dulu didukung luas dan sangat baik untuk kompresi lossy agresif, sedangkan JPEG XL unggul pada kompresi lossless, transcoding JPEG tanpa generasi ulang, dan dekode progresif yang halus. Google menyarankan menguji keduanya daripada menganggap salah satunya selalu menang.
| Aspek | AVIF | JPEG XL |
|---|---|---|
| Kekuatan utama | Kompresi lossy agresif | Lossless dan high-fidelity |
| Transcoding JPEG lossless | Tidak | Ya |
| Dukungan HDR | Ada | Bawaan |
| Dukungan Chrome | Sudah lebih dulu | Mulai Chrome 155 |
| Paling cocok untuk | Gambar umum berukuran besar | Fotografi kualitas tinggi, arsip |
Karena keduanya punya ceruk masing-masing, strategi paling aman adalah menyajikan beberapa format dan membiarkan peramban memilih lewat elemen picture. Pendekatan ini memungkinkan pengguna Chrome 155 menerima JPEG XL sementara peramban lain menerima AVIF atau JPEG biasa. Cakupan dukungan peramban untuk JPEG XL bisa dipantau di caniuse.com/jpegxl sebelum Anda memutuskan untuk mengandalkannya secara luas.
Kapan sebaiknya memakai JPEG XL?
Pakai JPEG XL ketika prioritas Anda adalah kualitas gambar setinggi mungkin dengan ukuran sekecil mungkin, terutama untuk fotografi dan arsip yang tidak boleh kehilangan detail. Format ini juga tepat bila Anda ingin memindahkan koleksi JPEG lama ke format modern tanpa menurunkan kualitas. Sebaliknya, untuk gambar yang sudah sangat terkompresi atau ikon sederhana, keuntungannya bisa tipis.
Untuk situs produksi, mulailah dari uji A/B pada beberapa gambar representatif, ukur ukuran berkas dan metrik performa, lalu perluas hanya jika hasilnya konsisten. Perlu diingat pula bahwa mengandalkan satu format saja berisiko bagi pengguna peramban lama, sehingga penyajian multi-format tetap menjadi praktik yang aman.
Bagaimana cara mulai menguji JPEG XL di pipeline gambar Anda?
Mulailah dengan menambahkan JPEG XL sebagai format keluaran tambahan, bukan menggantikan format yang sudah ada. Konversikan beberapa gambar fotografi representatif memakai encoder berbasis libjxl, catat ukuran berkas hasilnya, lalu bandingkan dengan versi AVIF dan JPEG dari gambar yang sama. Setelah punya data, sajikan lewat elemen picture dengan urutan sumber JPEG XL, AVIF, lalu JPEG sebagai fallback.
Urutan fallback itu penting karena tidak semua peramban mendukung ketiga format. Dengan menaruh format paling efisien di depan dan yang paling kompatibel di belakang, Anda melayani pengguna Chrome 155 ke atas tanpa mengorbankan pengguna peramban lain. Pantau data dukungan di caniuse sebelum memutuskan seberapa jauh mengandalkan format ini, dan periksa hasil Interop 2026 untuk JPEG XL sebagai acuan interoperabilitas.
Untuk mengukur dampaknya, bandingkan ukuran total gambar pada halaman, waktu muat, serta metrik Largest Contentful Paint sebelum dan sesudah perubahan. Uji pada perangkat dan jaringan yang beragam, karena keuntungan kompresi paling terasa pada koneksi lambat. Jangan menyimpulkan dari satu halaman; jalankan uji pada beberapa halaman dengan karakter gambar berbeda.
Apa saja risiko mengandalkan format gambar baru?
Risiko terbesar adalah kompatibilitas. Mengirim .jxl ke peramban yang belum mendukungnya berarti gambar tidak muncul, sehingga fallback bukan pilihan tetapi keharusan. Risiko kedua adalah biaya konversi: mengubah pipeline gambar menuntut waktu, pengujian, dan mungkin penyesuaian di tahap build maupun CDN yang menyimpan cache.
Risiko ketiga adalah kualitas encoder. Karena JPEG XL masih relatif baru di ekosistem web, kualitas encoder dan alat pendukungnya bisa berbeda antar implementasi. Uji encoder yang Anda pakai pada gambar khas proyek, lalu verifikasi secara visual pada bagian gambar yang detail seperti tekstur dan tepi tajam. Pendekatan bertahap dengan pengukuran akan menekan risiko ini jauh lebih baik daripada migrasi menyeluruh sekaligus.
FAQ
Apakah semua peramban sudah mendukung JPEG XL?
Belum. Dukungan dekode bawaan baru dikirim Chrome mulai versi 155, sedangkan peramban lain punya jadwal dan sikap masing-masing. Karena itu, praktik aman adalah menyediakan fallback lewat elemen picture, bukan menggantungkan seluruh halaman pada .jxl.
Apakah JPEG XL benar-benar lossless?
Ya, JPEG XL mendukung kompresi lossless. Format ini juga bisa melakukan transcoding JPEG lossless, sehingga berkas JPEG lama dapat dipindahkan ke wadah JPEG XL tanpa generasi ulang yang menurunkan kualitas gambar.
Apakah saya perlu mengonversi semua gambar ke JPEG XL?
Tidak perlu sekaligus. Mulailah dari gambar fotografi berukuran besar yang paling terdampak pada performa, ukur hasilnya, lalu perluas bertahap. Gambar kecil atau ikon sederhana sering tidak memberi keuntungan berarti.
Bagaimana cara mencoba JPEG XL sekarang?
Konversikan beberapa gambar ke .jxl memakai encoder berbasis libjxl, lalu sajikan lewat elemen picture dengan fallback AVIF atau JPEG. Untuk pengguna Chrome 155 ke atas, peramban akan langsung mendekode format ini tanpa perlu pustaka tambahan.
Kesimpulan
Masuknya JPEG XL ke Chrome 155 adalah langkah yang ditunggu lama oleh pengembang web. Selain membuka opsi kompresi yang lebih efisien, keputusan menulis ulang decoder dalam Rust menunjukkan bahwa keamanan memori kini diperlakukan sebagai syarat, bukan tambahan. Kombinasi kompresi 30 sampai 50 persen lebih baik, dukungan lossless, dan HDR membuat format ini layak diuji dalam pipeline gambar Anda.
Untuk jangka pendek, dampak terbesar akan terasa pada situs yang banyak menampilkan gambar resolusi tinggi, seperti portal berita, galeri produk, dan portofolio fotografi. Untuk situs yang didominasi teks dan ikon, manfaatnya lebih tipis, sehingga prioritas pengujian bisa disesuaikan. Yang jelas, dukungan di Chrome 155 menandai bahwa format ini sudah keluar dari tahap eksperimen dan layak masuk daftar pertimbangan teknis Anda.
Rujukan utama artikel ini adalah pengumuman resmi dari Chrome for Developers, repositori libjxl, pustaka SIMD Highway, dasbor performa jxl-rs, dan data dukungan peramban dari caniuse. Semua tautannya tercantum di bagian sumber berikut.
💬 Komentar (0)
Belum ada komentar. Jadilah yang pertama! 💬