Anda mungkin sudah familier dengan konsep inti dari jaringan penayangan konten (CDN): jaringan yang terdistribusi, tetapi saling terhubung server yang dengan cepat dan efisien mengirimkan aset kepada pengguna. Ketika file diupload ke penyedia CDN, duplikat akan dibuat di {i>node<i} lain dari jaringan CDN di seluruh dunia. Saat pengguna meminta file, data akan dikirim oleh node secara geografis terdekat dengan pengguna tersebut, sehingga mengurangi latensi. Sifat terdistribusi CDN juga memberikan redundansi jika terjadi pemadaman jaringan atau kegagalan hardware, dan load balancing untuk memitigasi lonjakan traffic.
CDN gambar dapat memberikan semua manfaat ini, dengan satu perbedaan utama: kemampuan untuk mengubah dan mengoptimalkan konten gambar berdasarkan {i>string<i} 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 sintaks yang tepat yang digunakan akan bervariasi dari satu penyedia layanan ke penyedia lainnya, setidaknya semua CDN gambar memungkinkan Anda mengubah sumber
setelan dimensi, encoding, dan kompresi gambar. Cloudinary, misalnya,
melakukan perubahan ukuran dinamis pada
gambar yang diupload melalui sintaksis berikut: h_ diikuti dengan tinggi numerik dalam piksel, w_ diikuti lebarnya,
dan nilai c_ yang memungkinkan Anda menentukan informasi mendetail tentang cara gambar harus diskalakan atau dipangkas.
Transformasi dapat diterapkan dalam jumlah berapa pun dengan menambahkan nilai yang dipisahkan koma ke URL, sebelum nama file dan ekstensi,
Artinya, gambar yang diupload dapat dimanipulasi sesuai kebutuhan melalui src 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 di-cache di seluruh CDN sehingga dapat dikirim
kepada pengguna yang meminta URL yang sama, bukan dibuat ulang sesuai permintaan.
Meskipun tidak jarang penyedia CDN gambar menawarkan software development kit
untuk memfasilitasi penggunaan dan integrasi lanjutan dengan berbagai rangkaian teknologi, dengan pola URL yang dapat diprediksi ini,
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 secara manual menentukan tingkat kompresi yang diinginkan menggunakan sintaksis yang kini sudah dikenal: q_, singkat
untuk "kualitas", diikuti oleh singkatan numerik untuk tingkat kompresi:
<img src="https://res.cloudinary.com/demo/image/upload/w_400,q_60/sample.jpg" alt="…">
Sangat jarang Anda perlu memasukkan informasi ini secara manual, namun, berkat serangkaian fitur yang sangat canggih yang disediakan oleh sebagian besar CDN gambar: kompresi, encoding, dan negosiasi konten konten yang sepenuhnya otomatis.
Kompresi otomatis
Dengan kemampuan komputasi {i>image<i} CDN yang dimilikinya, mereka dapat menawarkan fitur yang sangat kuat: menganalisis konten gambar untuk menentukan tingkat kompresi dan setelan encoding yang ideal secara algoritmis, seperti yang Anda atau saya menyempurnakan kompresi secara manual untuk setiap gambar.
Algoritma ini mengotomatiskan keputusan yang mungkin Anda buat menyeimbangkan ukuran file dan kualitas persepsi, serta menganalisis konten gambar untuk tanda-tanda degradasi yang terukur dan menyesuaikan setelan kompresi secara tepat. Hal ini sering kali berarti pengurangan besar dalam file ukuran dibandingkan dengan pendekatan manual satu ukuran untuk semua pada pengaturan kompresi.
Meskipun proses ini terdengar rumit, implementasinya tidak bisa jauh lebih sederhana: untuk Cloudinary, penambahan q_auto dalam
URL gambar mengaktifkan 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-->
Encoding otomatis dan negosiasi konten
Setelah menerima permintaan gambar, CDN gambar menentukan encoding paling modern yang didukung browser melalui
Header HTTP yang dikirim oleh browser bersama permintaan untuk aset—khususnya,
header Accept. Header ini menunjukkan pengkodean yang dapat dipahami oleh browser, dengan menggunakan
jenis media yang akan kita gunakan untuk mengisi 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 pengkodean tersebut dan meng-cache hasilnya untuk semua pengguna berikutnya dengan
tingkat dukungan browser. Respons tersebut mencakup header Content-Type
secara eksplisit memberi tahu browser tentang
pengkodean file, terlepas dari ekstensi file. Meskipun pengguna dengan {i>browser<i} modern akan membuat
untuk file yang diakhiri dengan .jpg, permintaan tersebut akan disertai dengan header yang memberi tahu server bahwa AVIF didukung, dan server
akan mengirim file berenkode AVIF bersama dengan
instruksi eksplisit untuk memperlakukannya sebagai AVIF.
Hasil akhirnya adalah proses yang tidak hanya membebaskan Anda dari pembuatan file yang dikodekan secara bergantian dan pengaturan kompresi Anda secara manual.
(atau mempertahankan sistem yang melakukan tugas ini untuk Anda), tetapi tidak perlu menggunakan atribut <picture> dan type untuk
mengirimkan file tersebut
ke pengguna. Jadi, menggunakan sintaksis srcset dan sizes saja masih dapat memberikan gambar yang dienkode sebagai—misalnya—AVIF,
kembali ke WebP (atau JPEG-2000, hanya untuk Safari), kembali lagi ke encoding lama yang paling logis.
Kelemahan penggunaan CDN gambar lebih bersifat logistik daripada teknis, yang utamanya adalah biaya. Meskipun umumnya CDN gambar menawarkan paket gratis fitur canggih untuk penggunaan pribadi, pembuatan aset gambar memerlukan bandwidth dan ruang penyimpanan untuk upload, pemrosesan server untuk mentransformasi gambar, dan ruang tambahan untuk hasil transformasi yang di-cache—sehingga penggunaan tingkat lanjut dan aplikasi dengan traffic tinggi mungkin memerlukan paket berbayar.