Atlas Image Optimizer: Gambar Lebih Kecil, Halaman Lebih Cepat

Pengunjung di HP tidak butuh PNG selebar 4096 piksel. Sampai kemarin Atlas tetap mengirimnya: unggahan disimpan apa adanya, dan API pengiriman memberikan satu file itu. Akibatnya tiap situs brand harus membangun pipeline gambarnya sendiri, atau menyajikan file asli dan menanggung bebannya. Atlas Image Optimizer memperbaikinya dari sumbernya.

Apa yang dilakukannya

Begitu unggahan gambar selesai, sebuah job di latar belakang menulis tangga salinan berukuran lebih kecil di samping file asli, di storage milik brand itu sendiri: lebar 480, 768, 1200, dan 1920 piksel (hanya yang lebih kecil dari sumbernya), ditambah lebar sumber itu sendiri dengan batas 2560. Setiap lebar ditulis dua kali, sebagai WebP dan sebagai AVIF.

API pengiriman lalu menambahkan dua kolom pada gambar: srcset berisi kandidat WebP, dan sources dengan AVIF di urutan pertama. Penyaji blok mengubahnya menjadi elemen picture, jadi browser mengambil format yang dipahaminya dan lebar yang dibutuhkannya. Gambar tanpa salinan dikirim persis seperti dulu, jadi situs yang belum mengenal kolom baru ini tidak rusak.

Berapa yang dihemat

Kami menjalankan backfill pada dua pustaka brand di produksi, total 327 gambar. Bayangkan HP dengan layar selebar 390 piksel berdensitas 2x yang mengunduh setiap gambar sebesar layar. Pustaka yang lebih besar (300 gambar, 41,5 MB) menyusut sekitar 72 persen dengan WebP dan 84 persen dengan AVIF. Pustaka yang lebih kecil (27 gambar) menyusut lebih dari 90 persen. Ini perkiraan dari ukuran file yang tersimpan, bukan hasil pengukuran halaman.

Satu kasus nyata: screenshot produk di beranda atlascms.id adalah PNG 4096 piksel seberat 962 KB. Halaman sekarang menawarkan AVIF 1200 piksel sekitar 20 KB untuknya, dan di browser sungguhan selebar 1440 piksel, elemen picture memilih tepat file itu.

Pilihan yang kami ukur

• AVIF lawan WebP. Pada empat gambar nyata selebar 1200 piksel, AVIF kualitas 50 berukuran 45 sampai 52 persen lebih kecil dari WebP kualitas 80, dan pada perbesaran 1:1 terlihat mirip JPEG kualitas 80 dengan tekstur halus yang sedikit berkurang. Kami memilih kualitas 55.
• Kecepatan encoder. AVIF speed 4 lebih lambat 3 sampai 10 kali untuk keuntungan kurang dari 5 persen. Speed 8 lebih cepat tetapi filenya 30 sampai 80 persen lebih besar. Speed 6 ada di tengah.
• Tanpa infrastruktur baru. Server yang sudah kami jalankan sanggup menulis kedua format, jadi tidak ada layanan tambahan untuk dioperasikan dan tidak ada yang perlu dipasang.
• Biaya. Satu salinan AVIF 1200 sampai 1920 piksel butuh kira-kira 0,1 sampai 0,5 detik di satu CPU. Backfill 327 gambar selesai dalam beberapa menit.

Aturan yang menjaganya aman

• Salinan hanya disimpan kalau lebih kecil dari file asli, dan AVIF hanya kalau lebih kecil dari WebP selebar sama. WebP bisa lebih besar dari JPEG atau PNG yang sangat kecil, jadi aturan ini penting.
• Foto ditegakkan sesuai orientasi EXIF-nya, dan tidak ada metadata (EXIF, GPS) yang disalin ke salinan.
• File animasi, GIF, SVG, dan apa pun di atas 40 megapiksel dikirim apa adanya. Bitmap 8192 kali 8192 yang sudah didekode butuh sekitar 256 MB memori, jadi job menolak yang melewati batas sebelum mendekode, dan menaikkan batas memorinya sendiri.
• Nama file memuat hash dari file asli dan objeknya ditulis dengan header cache immutable satu tahun. Mengganti file menghasilkan URL baru, dan mengganti atau menghapus akan menghapus salinan lama.
• Job berjalan di dalam konteks brand dan hanya menyentuh storage brand itu.

Dua hal yang diajarkan produksi

Tiga PNG berindeks selebar 1920 piksel tidak mendapat salinan. Library gambar menolak menulis gambar palet sebagai WebP atau AVIF, dan anak tangga terlebar memakai sumber hasil dekode secara langsung. File asli tetap jadi satu-satunya yang dikirim, jadi aman, tetapi optimasinya hilang untuk gambar-gambar itu. Kami menemukannya dengan memeriksa pustaka setelah backfill, bukan lewat tes. Perbaikannya mengubah gambar palet ke warna penuh lebih dulu, melewati satu format yang gagal alih-alih menggagalkan seluruh job, dan sekarang ada tesnya.

Yang kedua soal cache. Kami menulis header satu tahun, tetapi browser menerima empat jam: CDN di depan storage kami menulis ulang header itu. Setelah mengaktifkan ini di stack kamu sendiri, kirim permintaan HEAD untuk salah satu salinan dan baca headernya. Di sisi kami, itu pengaturan CDN yang masih harus diubah.

Yang belum bisa dilakukannya

Ukuran di luar tangga, pemotongan cerdas, dan transformasi saat diminta belum termasuk. Kontraknya (lebar bernama, URL stabil, batas ukuran) dirancang agar semua itu bisa ditambahkan nanti tanpa mengubah cara situs membaca gambar. Kami baru mengukur byte dan file yang dipilih browser, belum Core Web Vitals.

Cara memakainya

Untuk unggahan baru tidak ada yang perlu dinyalakan. Gambar yang diunggah sebelumnya mendapat backfill sekali per brand, dan situs yang memakai layer situs Atlas terbaru merender elemen picture dengan sendirinya.

Kalau kamu mencobanya pada gambarmu sendiri, kabari kami seperti apa angkanya di tempatmu.