Gambar DPI tinggi untuk kepadatan piksel variabel

Boris Smus

Salah satu fitur dari lanskap perangkat yang kompleks saat ini adalah adanya rentang kepadatan piksel layar yang sangat luas. Beberapa perangkat memiliki layar beresolusi sangat tinggi, sementara yang lain tertinggal di belakang. Developer aplikasi perlu mendukung berbagai kepadatan piksel, yang bisa jadi cukup menantang. Di web seluler, tantangan diperparah oleh beberapa faktor:

  • Berbagai macam perangkat dengan faktor bentuk yang berbeda.
  • Bandwidth jaringan dan masa pakai baterai terbatas.

Dalam hal gambar, tujuan developer aplikasi web adalah menayangkan gambar dengan kualitas terbaik seefisien mungkin. Artikel ini akan mencakup beberapa teknik yang berguna untuk melakukannya sekarang dan dalam waktu dekat.

Hindari gambar jika memungkinkan

Sebelum membuka masalah ini, ingatlah bahwa web memiliki banyak teknologi canggih yang sebagian besar tidak bergantung pada resolusi dan DPI. Secara khusus, teks, SVG, dan sebagian besar CSS akan "langsung berfungsi" karena fitur penskalaan piksel otomatis di web (melalui devicePixelRatio).

Meskipun demikian, Anda tidak selalu dapat menghindari gambar raster. Misalnya, Anda mungkin diberi aset yang akan cukup sulit direplikasi dalam SVG/CSS murni, atau Anda menangani foto. Meskipun Anda dapat mengonversi gambar menjadi SVG secara otomatis, memaketkan foto tidak masuk akal karena versi yang diskalakan biasanya tidak terlihat bagus.

Latar belakang

Histori kepadatan tampilan yang sangat singkat

Pada awalnya, layar komputer memiliki kepadatan piksel 72 atau 96 dpi (titik per inci).

Kepadatan piksel layar meningkat secara bertahap, sebagian besar didorong oleh kasus penggunaan seluler, saat pengguna umumnya memegang ponsel lebih dekat ke wajah mereka, sehingga piksel lebih terlihat. Pada tahun 2008, ponsel 150 dpi menjadi standar baru. Tren peningkatan kepadatan layar berlanjut, dan ponsel baru saat ini memiliki layar 300 dpi (bermerek "Retina" oleh Apple).

Tentu saja, hal terpenting adalah tampilan piksel yang sama sekali tidak terlihat. Untuk faktor bentuk ponsel, generasi layar Retina/HiDPI saat ini mungkin mendekati ideal. Namun, jenis hardware dan perangkat wearable baru seperti Project Glass kemungkinan akan terus mendorong peningkatan kepadatan piksel.

Dalam praktiknya, gambar dengan kepadatan rendah akan terlihat sama di layar baru seperti yang terlihat pada layar lama, tetapi dibandingkan dengan gambar tajam yang biasa dilihat pengguna kepadatan tinggi, gambar dengan kepadatan rendah akan terlihat janggal dan berbentuk piksel. Berikut adalah simulasi kasar tampilan gambar 1x di layar 2x. Sebaliknya, gambar 2x terlihat cukup bagus.

Baboon 1x
Baboon 2x
Baboons! dengan kepadatan piksel yang berbeda.

Piksel di web

Saat web didesain, 99% layar memiliki 96 dpi (atau dianggap sebagai sesuatu), dan beberapa ketentuan yang dibuat untuk variasi bagian ini. Karena besarnya variasi dalam ukuran dan kepadatan layar, kami memerlukan cara standar agar gambar terlihat bagus di berbagai kepadatan dan dimensi layar.

Spesifikasi HTML baru-baru ini mengatasi masalah ini dengan menentukan piksel referensi yang digunakan produsen untuk menentukan ukuran piksel CSS.

Dengan menggunakan piksel referensi, produsen dapat menentukan ukuran piksel fisik perangkat relatif terhadap piksel standar atau ideal. Rasio ini disebut rasio piksel perangkat.

Menghitung rasio piksel perangkat

Misalkan smartphone memiliki layar dengan ukuran piksel fisik 180 piksel per inci (ppi). Menghitung rasio piksel perangkat memerlukan tiga langkah:

  1. Bandingkan jarak sebenarnya saat perangkat dipegang dengan jarak untuk piksel referensi.

    Sesuai spesifikasi, kita tahu bahwa pada ukuran 28 inci, idealnya adalah 96 piksel per inci. Namun, karena ini adalah ponsel pintar, orang-orang memegang perangkat lebih dekat ke wajah mereka daripada memegang laptop. Mari kita perkirakan jarak itu 18 inci.

  2. Kalikan rasio jarak dengan kepadatan standar (96 ppi) untuk mendapatkan kepadatan piksel yang ideal untuk jarak yang diberikan.

    idealPixelDensity = (28/18) * 96 = 150 piksel per inci (sekitar)

  3. Ambil rasio kepadatan piksel fisik dengan kepadatan piksel ideal untuk mendapatkan rasio piksel perangkat.

    devicePixelRatio = 180/150 = 1,2

Cara penghitungan devicePixelRatio.
Diagram yang menunjukkan satu piksel sudut referensi, untuk membantu menggambarkan cara penghitungan devicePixelRatio.

Jadi, sekarang saat browser perlu mengetahui cara mengubah ukuran gambar agar sesuai dengan layar sesuai resolusi ideal atau standar, browser akan merujuk ke rasio piksel perangkat 1,2 - yang menyatakan, untuk setiap piksel ideal, perangkat ini memiliki 1,2 piksel fisik. Rumus untuk beralih antara piksel ideal (sebagaimana ditentukan oleh spesifikasi web) dan fisik (titik di layar perangkat) adalah sebagai berikut:

physicalPixels = window.devicePixelRatio * idealPixels

Secara historis, vendor perangkat cenderung membulatkan devicePixelRatios (DPR). iPhone dan iPad Apple melaporkan DPR 1, dan Retina yang setara melaporkan 2. Spesifikasi CSS merekomendasikan bahwa

unit piksel mengacu pada seluruh jumlah piksel perangkat yang paling mendekati piksel referensi.

Salah satu alasan rasio bulat dapat lebih baik adalah karena rasio tersebut dapat menghasilkan artefak sub-piksel yang lebih sedikit.

Namun, realitas lanskap perangkat jauh lebih bervariasi, dan ponsel Android sering kali memiliki DPR 1,5. Tablet Nexus 7 memiliki DPR ~1,33, yang diperoleh dengan penghitungan yang mirip dengan yang di atas. Nantikan lebih banyak perangkat dengan DPR variabel pada masa mendatang. Oleh karena itu, Anda tidak boleh berasumsi bahwa klien akan memiliki DPR bilangan bulat.

Ringkasan teknik gambar HiDPI

Ada banyak teknik untuk mengatasi masalah menampilkan gambar berkualitas terbaik secepat mungkin, yang secara luas terbagi menjadi dua kategori:

  1. Mengoptimalkan satu gambar, dan
  2. Mengoptimalkan pemilihan antara beberapa gambar.

Pendekatan gambar tunggal: gunakan satu gambar, tetapi lakukan sesuatu yang cerdik dengan gambar tersebut. Pendekatan ini memiliki kelemahan bahwa Anda pasti akan mengorbankan performa, karena Anda akan mendownload gambar HiDPI bahkan di perangkat lama dengan DPI yang lebih rendah. Berikut beberapa pendekatan untuk kasus gambar tunggal:

  • Gambar HiDPI yang dikompresi berat
  • Format gambar yang benar-benar mengagumkan
  • Format gambar progresif

Beberapa pendekatan gambar: gunakan beberapa gambar, tetapi lakukan sesuatu yang cerdas untuk memilih gambar yang akan dimuat. Pendekatan ini memiliki overhead bawaan bagi developer untuk membuat beberapa versi aset yang sama, lalu mencari strategi keputusan. Berikut ini opsinya:

  • JavaScript
  • Pengiriman sisi server
  • Kueri media CSS
  • Fitur browser bawaan (image-set(), <img srcset>)

Gambar HiDPI yang sangat terkompresi

Gambar sudah menggunakan bandwidth sebesar 60% yang dihabiskan untuk mendownload situs rata-rata. Dengan menayangkan gambar HiDPI ke semua klien, kami akan meningkatkan jumlah ini. Seberapa besar pertumbuhannya?

Saya menjalankan beberapa pengujian yang menghasilkan fragmen gambar 1x dan 2x dengan kualitas JPEG pada 90, 50, dan 20. Berikut adalah skrip shell yang saya gunakan (menggunakan ImageMagick) untuk membuatnya:

Contoh kartu 1. Contoh kartu 2. Contoh kartu 3.
Contoh gambar dengan kompresi dan kepadatan piksel yang berbeda.

Dari sampling kecil yang tidak ilmiah ini, tampaknya mengompresi gambar besar memberikan kompromi kualitas terhadap ukuran yang baik. Bagi saya, gambar 2x yang dikompresi berat sebenarnya terlihat lebih baik daripada gambar 1x yang tidak dikompresi.

Tentu saja, menayangkan gambar 2x yang berkualitas rendah dan sangat dikompresi ke perangkat 2x lebih buruk daripada menayangkan gambar berkualitas lebih tinggi, dan pendekatan di atas akan menimbulkan penalti kualitas gambar. Jika membandingkan kualitas: 90 gambar dengan kualitas: 20 gambar, Anda akan melihat penurunan ketajaman dan peningkatan granuler. Artefak ini mungkin tidak dapat diterima jika gambar berkualitas tinggi adalah kuncinya (misalnya, aplikasi penampil foto), atau untuk developer aplikasi yang tidak mau berkompromi.

Perbandingan di atas dibuat sepenuhnya dengan JPEG yang dikompresi. Perlu diperhatikan bahwa ada banyak kompromi antara format gambar yang diterapkan secara luas (JPEG, PNG, GIF), yang membawa kita ke…

Format gambar yang sangat keren

WebP adalah format gambar yang cukup menarik yang dikompresi dengan sangat baik sekaligus mempertahankan fidelitas gambar yang tinggi. Tentu saja, fitur ini belum diterapkan di mana-mana.

Salah satu caranya adalah dengan memeriksa dukungan WebP melalui JavaScript. Anda memuat gambar 1 piksel melalui data-uri, menunggu peristiwa pemuatan atau error diaktifkan, lalu memverifikasi bahwa ukurannya sudah benar. Modernizr dikirimkan dengan skrip deteksi fitur tersebut, yang tersedia melalui Modernizr.webp.

Namun, cara yang lebih baik untuk melakukannya adalah langsung di CSS menggunakan fungsi image(). Jadi, jika Anda memiliki gambar WebP dan penggantian JPEG, Anda dapat menulis hal berikut:

#pic {
  background: image("foo.webp", "foo.jpg");
}

Ada beberapa masalah dengan pendekatan ini. Pertama, image() sama sekali tidak diterapkan secara luas. Kedua, meskipun kompresi WebP jauh lebih baik daripada JPEG, tetapi masih merupakan peningkatan yang relatif inkremental – sekitar 30% lebih kecil berdasarkan galeri WebP ini. Dengan demikian, WebP saja tidak cukup untuk mengatasi masalah DPI tinggi.

Format gambar progresif

Format gambar progresif seperti JPEG 2000, Progressive JPEG, Progressive PNG, dan GIF memiliki manfaat (yang agak diperdebatkan) untuk melihat gambar muncul sebelum dimuat sepenuhnya. Hal ini dapat menimbulkan beberapa overhead ukuran, meskipun ada bukti yang bertentangan tentang hal ini. Jeff Atwood mengatakan bahwa mode progresif "menambahkan sekitar 20% ke ukuran gambar PNG, dan sekitar 10% ke ukuran gambar JPEG dan GIF". Namun, Stoyan Stefanov mengklaim bahwa mode progresif lebih efisien untuk file berukuran besar (dalam sebagian besar kasus).

Secara sekilas, gambar progresif terlihat sangat menjanjikan dalam konteks untuk menayangkan gambar dengan kualitas terbaik secepat mungkin. Idenya adalah browser dapat berhenti mendownload dan mendekode gambar setelah mengetahui bahwa data tambahan tidak akan meningkatkan kualitas gambar (yaitu semua peningkatan fidelitas adalah sub-piksel).

Meskipun mudah dihentikan, koneksi sering kali mahal untuk dimulai ulang. Untuk situs dengan banyak gambar, pendekatan yang paling efisien adalah mempertahankan satu koneksi HTTP, menggunakannya kembali selama mungkin. Jika koneksi dihentikan sebelum waktunya karena satu gambar sudah cukup didownload, browser kemudian perlu membuat koneksi baru, yang bisa sangat lambat di lingkungan latensi rendah.

Salah satu solusi untuk hal ini adalah menggunakan permintaan Rentang HTTP, yang memungkinkan browser menentukan rentang byte yang akan diambil. Browser cerdas dapat membuat permintaan HEAD untuk mendapatkan header, memprosesnya, menentukan jumlah gambar yang benar-benar diperlukan, lalu mengambilnya. Sayangnya, Rentang HTTP tidak didukung dengan baik di server web, sehingga pendekatan ini tidak praktis.

Terakhir, batasan yang jelas dari pendekatan ini adalah Anda tidak dapat memilih gambar yang akan dimuat, hanya fidelitas yang berbeda dari gambar yang sama. Akibatnya, hal ini tidak membahas kasus penggunaan "art direction".

Menggunakan JavaScript untuk menentukan gambar yang akan dimuat

Pendekatan pertama dan paling jelas untuk menentukan gambar yang akan dimuat adalah menggunakan JavaScript di klien. Pendekatan ini memungkinkan Anda mengetahui semua hal tentang agen pengguna dan melakukan tindakan yang tepat. Anda dapat menentukan rasio piksel perangkat melalui window.devicePixelRatio, mendapatkan lebar dan tinggi layar, dan bahkan berpotensi melakukan beberapa sniffing koneksi jaringan melalui navigator.connection atau mengeluarkan permintaan palsu, seperti yang dilakukan library foresight.js. Setelah mengumpulkan semua informasi ini, Anda dapat memutuskan gambar mana yang akan dimuat.

Ada sekitar satu juta library JavaScript yang melakukan hal seperti di atas, dan sayangnya tidak ada yang sangat luar biasa.

Salah satu kelemahan besar dalam pendekatan ini adalah bahwa menggunakan JavaScript berarti Anda akan menunda pemuatan gambar hingga setelah parser lihat-depan selesai. Pada dasarnya, hal ini berarti bahwa gambar tidak akan mulai didownload sampai setelah peristiwa pageload diaktifkan. Baca selengkapnya di artikel Jason Grigsby.

Tentukan gambar yang akan dimuat di server

Anda dapat menunda keputusan ke sisi server dengan menulis pengendali permintaan kustom untuk setiap gambar yang Anda tayangkan. Pengendali tersebut akan memeriksa dukungan Retina berdasarkan User-Agent (satu-satunya bagian informasi yang diteruskan ke server). Kemudian, berdasarkan apakah logika sisi server ingin menayangkan aset HiDPI, Anda memuat aset yang sesuai (diberi nama sesuai dengan beberapa konvensi yang diketahui).

Sayangnya, User-Agent tidak selalu memberikan informasi yang cukup untuk memutuskan apakah perangkat harus menerima gambar berkualitas tinggi atau rendah. Selain itu, tidak perlu dikatakan bahwa segala hal yang berhubungan dengan Agen Pengguna adalah peretasan dan harus dihindari jika memungkinkan.

Menggunakan kueri media CSS

Sebagai deklaratif, kueri media CSS memungkinkan Anda menyatakan niat, dan memungkinkan browser melakukan hal yang tepat atas nama Anda. Selain penggunaan kueri media yang paling umum — pencocokan ukuran perangkat — Anda juga dapat mencocokkan devicePixelRatio. Kueri media terkait adalah rasio piksel perangkat, dan memiliki varian minimum dan maksimum terkait, seperti yang mungkin Anda harapkan. Jika Anda ingin memuat gambar DPI tinggi dan rasio piksel perangkat melebihi nilai minimum, berikut yang dapat Anda lakukan:

#my-image { background: (low.png); }

@media only screen and (min-device-pixel-ratio: 1.5) {
  #my-image { background: (high.png); }
}

Hal ini menjadi sedikit lebih rumit dengan semua awalan vendor yang digabungkan, terutama karena perbedaan penempatan yang gila dari awalan "min" dan "max":

@media only screen and (min--moz-device-pixel-ratio: 1.5),
    (-o-min-device-pixel-ratio: 3/2),
    (-webkit-min-device-pixel-ratio: 1.5),
    (min-device-pixel-ratio: 1.5) {

  #my-image {
    background:url(high.png);
  }
}

Dengan pendekatan ini, Anda mendapatkan kembali manfaat penguraian look-ahead, yang hilang dengan solusi JS. Anda juga mendapatkan fleksibilitas dalam memilih titik henti sementara responsif (misalnya, Anda dapat memiliki gambar DPI rendah, sedang, dan tinggi), yang hilang dengan pendekatan sisi server.

Sayangnya, cara ini masih sedikit sulit digunakan, dan menghasilkan CSS yang terlihat aneh (atau memerlukan prapemrosesan). Selain itu, pendekatan ini dibatasi untuk properti CSS, sehingga tidak ada cara untuk menetapkan <img src>, dan semua gambar harus berupa elemen dengan latar belakang. Terakhir, dengan mengandalkan rasio piksel perangkat secara ketat, Anda dapat mengalami situasi saat ponsel cerdas High-DPI Anda akhirnya mendownload aset gambar 2x besar saat menggunakan koneksi EDGE. Ini bukan pengalaman pengguna terbaik.

Menggunakan fitur browser baru

Baru-baru ini, ada banyak diskusi tentang dukungan platform web untuk masalah gambar DPI tinggi. Apple baru-baru ini memasuki ruang ini, dengan menghadirkan fungsi CSS image-set() ke WebKit. Akibatnya, Safari dan Chrome mendukungnya. Karena merupakan fungsi CSS, image-set() tidak mengatasi masalah untuk tag <img>. Masukkan @srcset, yang mengatasi masalah ini, tetapi (pada saat penulisan ini) belum memiliki implementasi referensi (belum). Bagian berikutnya akan membahas image-set dan srcset lebih mendalam.

Fitur browser untuk dukungan DPI tinggi

Pada akhirnya, keputusan tentang pendekatan yang Anda ambil bergantung pada persyaratan tertentu Anda. Meskipun demikian, perlu diingat bahwa semua pendekatan yang disebutkan di atas memiliki kelemahan. Namun, ke depannya, setelah image-set dan srcset didukung secara luas, keduanya akan menjadi solusi yang sesuai untuk masalah ini. Untuk saat ini, mari kita bicara tentang beberapa praktik terbaik yang bisa membawa kita sedekat mungkin dengan masa depan yang ideal.

Pertama, apa perbedaan keduanya? image-set() adalah fungsi CSS, yang sesuai untuk digunakan sebagai nilai properti CSS latar belakang. srcset adalah atribut khusus untuk elemen <img>, dengan sintaksis serupa. Kedua tag ini memungkinkan Anda menentukan deklarasi gambar, tetapi atribut srcset juga memungkinkan Anda mengonfigurasi gambar yang akan dimuat berdasarkan ukuran tampilan.

Praktik terbaik untuk kumpulan gambar

Fungsi CSS image-set() tersedia dengan awalan -webkit-image-set(). Sintaksnya cukup sederhana, menggunakan satu atau beberapa deklarasi gambar yang dipisahkan koma, yang terdiri dari string URL atau fungsi url(), diikuti dengan resolusi terkait. Contoh:

background-image:  -webkit-image-set(
  url(icon1x.jpg) 1x,
  url(icon2x.jpg) 2x
);

Hal ini memberi tahu browser bahwa ada dua gambar yang dapat dipilih. Salah satunya dioptimalkan untuk layar 1x, dan satunya lagi untuk layar 2x. Browser kemudian dapat memilih mana yang akan dimuat, berdasarkan berbagai faktor, yang bahkan mungkin mencakup kecepatan jaringan, jika browser cukup pintar (saat ini tidak diterapkan sejauh yang saya tahu).

Selain memuat gambar yang benar, browser juga akan mengubah ukurannya secara sesuai. Dengan kata lain, browser berasumsi bahwa 2 gambar berukuran dua kali lebih besar dari gambar 1x, sehingga akan menskalakan gambar 2x dengan faktor 2, sehingga gambar akan tampak berukuran sama di halaman.

Daripada menentukan 1x, 1,5x, atau Nx, Anda juga dapat menentukan kepadatan piksel perangkat tertentu dalam dpi.

Cara ini berfungsi dengan baik, kecuali di browser yang tidak mendukung properti image-set, yang tidak akan menampilkan gambar sama sekali. Hal ini jelas buruk, sehingga Anda harus menggunakan penggantian (atau serangkaian penggantian) untuk mengatasi masalah tersebut:

background-image: url(icon1x.jpg);
background-image: -webkit-image-set(
  url(icon1x.jpg) 1x,
  url(icon2x.jpg) 2x
);
/* This will be useful if image-set gets into the platform, unprefixed.
    Also include other prefixed versions of this */
background-image: image-set(
  url(icon1x.jpg) 1x,
  url(icon2x.jpg) 2x
);

Hal di atas akan memuat aset yang tepat di browser yang mendukung set gambar, dan kembali ke aset 1x. Kekurangan yang jelas adalah meskipun dukungan browser image-set() rendah, sebagian besar agen pengguna akan mendapatkan aset 1x.

Demo ini menggunakan image-set() untuk memuat gambar yang benar, yang kembali ke aset 1x jika fungsi CSS ini tidak didukung.

Pada tahap ini, Anda mungkin bertanya-tanya mengapa tidak langsung melakukan polyfill (yaitu, mem-build shim JavaScript untuk) image-set() dan selesai? Ternyata, cukup sulit untuk menerapkan polyfill yang efisien untuk fungsi CSS. (Untuk penjelasan mendetail alasannya, lihat diskusi gaya www ini).

Srcset gambar

Berikut adalah contoh srcset:

<img alt="my awesome image"
  src="banner.jpeg"
  srcset="banner-HD.jpeg 2x, banner-phone.jpeg 640w, banner-phone-HD.jpeg 640w 2x">

Seperti yang dapat Anda lihat, selain deklarasi x yang disediakan image-set, elemen srcset juga menggunakan nilai w dan h yang sesuai dengan ukuran area pandang, yang mencoba menayangkan versi yang paling relevan. Contoh di atas akan menayangkan banner-phone.jpeg ke perangkat dengan lebar area tampilan di bawah 640 piksel, banner-phone-HD.jpeg ke perangkat dengan DPI tinggi layar kecil, banner-HD.jpeg ke perangkat DPI tinggi dengan layar lebih besar dari 640 piksel, dan banner.jpeg ke perangkat lainnya.

Menggunakan image-set untuk elemen gambar

Karena atribut srcset pada elemen img tidak diterapkan di sebagian besar browser, Anda mungkin tergoda untuk mengganti elemen img dengan <div> dengan latar belakang dan menggunakan pendekatan kumpulan gambar. Hal ini akan berhasil, dengan ketentuan. Kelemahannya di sini adalah tag <img> memiliki nilai semantik yang lama. Dalam praktiknya, hal ini penting terutama untuk crawler web dan alasan aksesibilitas.

Jika akhirnya menggunakan -webkit-image-set, Anda mungkin tergoda untuk menggunakan properti CSS latar belakang. Kelemahan pendekatan ini adalah Anda perlu menentukan ukuran gambar, yang tidak diketahui jika Anda menggunakan gambar non-1x. Sebagai gantinya, Anda dapat menggunakan properti CSS konten sebagai berikut:

<div id="my-content-image"
  style="content: -webkit-image-set(
    url(icon1x.jpg) 1x,
    url(icon2x.jpg) 2x);">
</div>

Tindakan ini akan otomatis menskalakan gambar berdasarkan devicePixelRatio. Lihat contoh ini penerapan teknik di atas, dengan penggantian tambahan ke url() untuk browser yang tidak mendukung image-set.

Polyfill srcset

Salah satu fitur praktis srcset adalah dilengkapi dengan penggantian alami. Jika atribut srcset tidak diterapkan, semua browser akan memproses atribut src. Selain itu, karena hanya merupakan atribut HTML, Anda dapat membuat polyfill dengan JavaScript.

Polyfill ini dilengkapi dengan pengujian unit untuk memastikan bahwa jumlahnya sedekat mungkin dengan spesifikasi. Selain itu, ada pemeriksaan yang mencegah polyfill mengeksekusi kode apa pun jika srcset diterapkan secara native.

Berikut adalah cara kerja demo polyfill.

Kesimpulan

Tidak ada solusi ajaib untuk mengatasi masalah gambar DPI tinggi.

Solusi termudah adalah menghindari gambar sepenuhnya, dengan memilih SVG dan CSS. Namun, hal ini tidak selalu realistis, terutama jika Anda memiliki gambar berkualitas tinggi di situs Anda.

Pendekatan dalam JS, CSS, dan penggunaan sisi server semuanya memiliki kelebihan dan kelemahan. Namun, pendekatan yang paling menjanjikan adalah memanfaatkan fitur browser baru. Meskipun dukungan browser untuk image-set dan srcset masih belum lengkap, ada penggantian yang wajar untuk digunakan saat ini.

Singkatnya, rekomendasi saya adalah sebagai berikut: