Anda mungkin sudah memahami konsep inti jaringan penayangan konten (CDN): jaringan server yang terdistribusi tetapi saling terhubung yang mengirimkan aset kepada pengguna dengan cepat dan efisien. Saat file diupload ke penyedia CDN, duplikat akan dibuat di node lain jaringan CDN di seluruh dunia. Saat pengguna meminta file, data akan dikirim oleh node yang secara geografis terdekat dengan pengguna tersebut, sehingga mengurangi latensi. Sifat CDN yang terdistribusi juga menyediakan redundansi jika terjadi pemadaman jaringan atau kegagalan hardware, dan load balancing untuk mengurangi lonjakan traffic.
CDN gambar dapat memberikan semua manfaat ini, dengan satu perbedaan utama: kemampuan untuk mengubah dan mengoptimalkan konten gambar berdasarkan string yang digunakan URL untuk mengaksesnya.
Pengguna akan mengupload gambar kanonis beresolusi tinggi ke penyedia, yang akan menghasilkan URL yang digunakan untuk mengaksesnya:
https://res.cloudinary.com/demo/image/upload/sample.jpg
Meskipun sintaksis yang tepat yang digunakan akan berbeda dari satu penyedia ke penyedia lainnya, setidaknya semua CDN gambar memungkinkan Anda mengubah setelan dimensi, encoding, dan kompresi gambar sumber. Cloudinary, misalnya, melakukan pengubahan ukuran dinamis dari gambar yang diupload melalui sintaksis berikut: h_ diikuti dengan tinggi numerik dalam piksel, w_ diikuti dengan lebar, dan nilai c_ yang memungkinkan Anda menentukan informasi mendetail tentang cara gambar harus diskalakan atau dipangkas.
Berapa pun angka transformasi dapat diterapkan dengan menambahkan nilai yang dipisahkan koma ke URL, sebelum nama file dan ekstensi,
yang berarti bahwa gambar yang diupload dapat dimanipulasi sesuai kebutuhan melalui src dari elemen img yang memintanya.
<img src="https://res.cloudinary.com/demo/image/upload/w_400/sample.jpg" alt="…">
Saat pertama kali pengguna mengunjungi URL yang berisi transformasi ini, versi baru gambar yang diskalakan secara proporsional dengan
lebar 400 piksel (w_400) akan dibuat dan dikirim. File yang baru dibuat tersebut kemudian disimpan dalam cache di seluruh CDN sehingga dapat dikirim ke pengguna mana pun yang meminta URL yang sama, bukan dibuat ulang sesuai permintaan.
Meskipun penyedia CDN gambar menawarkan software development kit untuk memfasilitasi penggunaan dan integrasi lanjutan dengan berbagai technology stack, pola URL yang dapat diprediksi ini saja memungkinkan kita dengan mudah mengubah satu file yang diupload menjadi atribut srcset yang valid tanpa memerlukan alat pengembangan lainnya:
<img
src="https://res.cloudinary.com/demo/image/upload/w_1000/sample.jpg 1000w"
srcset="https://res.cloudinary.com/demo/image/upload/w_1000/sample.jpg 1000w,
https://res.cloudinary.com/demo/image/upload/w_800/sample.jpg 800w,
https://res.cloudinary.com/demo/image/upload/w_600/sample.jpg 600w"
alt="…">
Kita dapat menentukan tingkat kompresi yang diinginkan secara manual menggunakan sintaksis yang seharusnya sudah dikenal: q_, singkatan dari "kualitas", diikuti dengan singkatan numerik untuk tingkat kompresi:
<img src="https://res.cloudinary.com/demo/image/upload/w_400,q_60/sample.jpg" alt="…">
Anda jarang sekali menyertakan informasi ini secara manual. Namun, berkat serangkaian fitur sangat canggih yang disediakan oleh sebagian besar CDN gambar: kompresi, encoding, dan negosiasi konten otomatis sepenuhnya.
Kompresi otomatis
Dengan kemampuan komputasi CDN yang tersedia, CDN dapat menawarkan fitur yang sangat canggih: menganalisis konten gambar untuk menentukan tingkat kompresi dan setelan encoding yang ideal secara algoritmis, sama seperti Anda atau saya akan secara manual menyempurnakan kompresi untuk setiap gambar.
Algoritma ini mengotomatiskan keputusan yang mungkin Anda buat dengan menyeimbangkan ukuran file dan kualitas persepsi, menganalisis konten gambar untuk melihat tanda-tanda degradasi terukur, dan menyesuaikan setelan kompresi secara tepat. Hal ini sering kali berarti pengurangan ukuran file dalam jumlah besar dibandingkan dengan pendekatan manual satu ukuran untuk semua untuk setelan kompresi.
Meskipun proses ini terdengar seru, implementasinya mungkin tidak jauh lebih sederhana: untuk Cloudinary, penambahan q_auto dalam URL gambar memungkinkan fitur ini:
<img src="https://res.cloudinary.com/demo/image/upload/w_1400/sample.jpg" alt="…">
<!-- 250 KB-->
<img src="https://res.cloudinary.com/demo/image/upload/w_1400,q_auto/sample.jpg" alt="…">
<!-- 134 KB-->
Negosiasi konten dan encoding otomatis
Setelah menerima permintaan gambar, CDN gambar menentukan encoding paling modern yang didukung browser melalui header HTTP yang dikirim oleh browser bersama dengan permintaan aset—khususnya, header Accept. Header ini menunjukkan encoding yang dapat dipahami browser, menggunakan
jenis media yang sama dengan yang akan kita gunakan untuk mengisi atribut type
dari <source> elemen <picture>.
Misalnya, menambahkan parameter f_auto ke daftar transformasi gambar di URL aset secara eksplisit memberi tahu Cloudinary untuk memberikan encoding paling efisien yang dapat dipahami browser:
<img src="https://res.cloudinary.com/demo/image/upload/w_1200,q_auto,f_auto/sample.jpg" alt="…">
Server kemudian membuat versi gambar dengan encoding tersebut dan men-cache hasilnya untuk semua pengguna berikutnya dengan tingkat
dukungan browser yang sama. Respons tersebut mencakup header Content-Type
untuk secara eksplisit memberi tahu browser tentang encoding file, apa pun ekstensi filenya. Meskipun pengguna dengan browser modern akan membuat
permintaan untuk file yang diakhiri dengan .jpg, permintaan tersebut akan disertai dengan header yang memberi tahu server bahwa AVIF didukung, dan server
akan mengirimkan file yang dienkode AVIF bersama dengan petunjuk eksplisit untuk memperlakukannya sebagai AVIF.
Hasil akhirnya adalah proses yang tidak hanya membebaskan Anda dari pembuatan file yang dienkode alternatifnya dan menyesuaikan setelan kompresi secara manual
(atau memelihara sistem yang melakukan tugas ini untuk Anda), tetapi juga menghilangkan kebutuhan untuk menggunakan atribut <picture> dan type untuk secara efektif
mengirimkan file tersebut kepada pengguna. Jadi, menggunakan sintaksis srcset dan sizes saja masih dapat memberi pengguna gambar yang dienkode sebagai—misalnya—AVIF,
kembali ke WebP (atau JPEG-2000, hanya untuk Safari), kembali menggunakan encoding lama yang paling masuk akal.
Kelemahan menggunakan gambar CDN lebih logistik daripada teknis, utamanya adalah biaya. Meskipun CDN gambar umumnya menawarkan paket gratis yang andal untuk penggunaan pribadi, pembuatan aset gambar memerlukan bandwidth dan ruang penyimpanan untuk upload, pemrosesan di server untuk mengubah gambar, dan ruang tambahan untuk hasil transformasi yang disimpan dalam cache—sehingga penggunaan lanjutan dan aplikasi dengan traffic tinggi mungkin memerlukan paket berbayar.