Saat ini, gambar adalah aset terbesar di web dalam hal total ukuran transfer dan jumlah permintaan per halaman. Total ukuran transfer halaman web median sekitar 2 MB, per Juni 2022, dengan jumlah gambar saja yang mencapai hampir setengahnya. Ini tidak berlebihan mengatakan bahwa pengoptimalan permintaan gambar bisa menjadi satu-satunya pengoptimalan performa yang dapat Anda lakukan.
Nantinya, Anda akan mempelajari bagaimana gambar responsif telah berevolusi untuk membantu mengatasi masalah yang muncul dengan mencoba menampilkan satu gambar untuk semua kemungkinan. Di bagian ini, temukan metrik performa utama yang terkait dengan gambar, dan cara meningkatkannya.
Menunda permintaan gambar
Saat Anda akan mempelajari beberapa cara untuk memastikan permintaan gambar Anda sekecil dan seefisien mungkin, permintaan gambar tercepat
akan selalu menjadi item yang
tidak pernah dibuat. Jadi, sebelumnya, saya ingin menyampaikan perubahan
yang paling berdampak yang dapat Anda lakukan
Anda mengirimkan aset gambar ke pengguna: atribut loading="lazy".
<img src="image.jpg" loading="lazy" alt="…">
Atribut ini memastikan bahwa permintaan gambar tidak dibuat sampai berada di dekat area pandang pengguna, sehingga penundaan dari pemuatan halaman—waktu saat browser berada pada titik tersibuk—dan menghapus permintaan tersebut dari jalur rendering penting.
Sesederhana dalam praktiknya, penggunaan atribut ini dapat memberikan dampak positif yang besar pada performa: gambar yang tidak pernah berada dalam area pandang pengguna tidak akan pernah diminta, dan tidak ada bandwidth yang terbuang untuk gambar yang tidak akan pernah dilihat pengguna.
Namun, ada syaratnya: menunda permintaan itu berarti tidak memanfaatkan proses yang sangat dioptimalkan untuk meminta
gambar sedini mungkin. Jika loading="lazy" digunakan pada elemen img di bagian atas tata letak, sehingga kemungkinan besar
berada di area pandang pengguna saat halaman pertama kali dimuat—gambar ini bisa terasa jauh lebih lambat bagi pengguna akhir.
Ambil Prioritas
Atribut loading adalah contoh upaya standar web yang lebih besar untuk memberi developer kemampuan yang lebih besar atas cara browser web
memprioritaskan permintaan.
Anda mungkin mengetahui pendekatan dasar untuk mengambil prioritas:
misalnya, permintaan untuk file CSS eksternal di <head> dokumen dianggap cukup penting untuk memblokir render, sementara permintaan untuk
file JavaScript eksternal tepat di atas </body> akan ditunda hingga render selesai. Jika nilai atribut loading pada <img> adalah 'lambat',
permintaan gambar yang terkait akan ditunda hingga browser menentukan bahwa gambar akan ditampilkan kepada pengguna. Jika tidak, gambar itu akan memiliki
prioritasnya seperti gambar
lain di halaman tersebut.
Atribut fetchpriority dimaksudkan untuk memberikan
developer kontrol yang lebih mendetail atas prioritas aset, sehingga Anda dapat menandai resource
sebagai 'tinggi' dan 'rendah' prioritas relatif terhadap resource berjenis sama. Kasus penggunaan untuk fetchpriority mirip dengan loading
meskipun jauh lebih luas. Misalnya, Anda mungkin menggunakan fetchpriority="low" pada gambar yang hanya mengungkapkan interaksi pengguna setelah
(apakah gambar tersebut berada dalam area tampilan pengguna atau tidak) untuk memprioritaskan gambar yang terlihat di tempat lain pada halaman, atau fetchpriority="high"
untuk memprioritaskan gambar yang Anda tahu akan langsung terlihat di area pandang segera setelah halaman dirender.
Perlu diketahui bahwa fetchpriority berbeda dengan loading karena tidak mengubah perilaku browser pada dasarnya. Ini tidak menginstruksikan browser
memuat aset tertentu sebelum aset yang lain, dan memberikannya konteks penting untuk keputusan yang dibuat terkait permintaan aset.
Mengukur dampak gambar
Saat mengoptimalkan aset gambar, performa yang dipersepsikan sering kali lebih penting, dan lebih sulit diukur, dibandingkan total transfer hanya dalam jumlah besar.
Web Vitals menyediakan metrik yang dapat diukur dan dapat ditindaklanjuti serta panduan untuk meningkatkan pengalaman web, menyoroti masalah seperti seperti waktu respons lambat dari server web, masalah rendering, dan penundaan interaktivitas. Core Web Vitals adalah bagian dari sasaran ini, yang berfokus terhadap pengalaman langsung pengguna di halaman individu—serangkaian pengukuran teknis yang, bersama-sama, menentukan seberapa cepat perasaan sebuah pengalaman bagi pengguna.
Pergeseran Tata Letak Kumulatif (CLS)
Pergeseran Tata Letak Kumulatif (CLS) adalah ukuran stabilitas visual. Metrik ini adalah metrik untuk menangkap berapa banyak tata letak konten pada laman bergeser saat aset dimuat dan laman dirender. Siapa saja yang telah membelanjakan uang dalam jumlah besar waktu menggunakan web telah kehilangan posisi dalam jangka panjang teks karena laman "melompat" seperti webfont web atau sumber gambar yang terlambat tiba-tiba dirender—atau elemen interaktif tiba-tiba menjauh dari pointer Anda. CLS yang tinggi paling akan mengganggu, dan menyebabkan {i>user error <i}paling buruk—“batal” tombol beralih ke ruang yang sebelumnya ditempati oleh "konfirmasi" tombol sesuai klik, misalnya.
Dengan waktu pemuatan yang tinggi dan jumlah ruang yang dapat ditempati dalam suatu tata letak, merupakan alasan umum bahwa gambar adalah penyebab umum skor CLS yang tinggi.
Berkat perubahan yang relatif baru di browser modern, lebih mudah daripada yang Anda pikirkan untuk menghindari skor CLS yang tinggi karena gambar.
Jika Anda telah menangani frontend selama beberapa tahun, Anda akan terbiasa dengan atribut width dan height di <img>:
sebelum CSS diadopsi secara luas, ini adalah satu-satunya cara untuk mengontrol ukuran gambar.
<img src="image.jpg" height="200" width="400" alt="…">
Atribut ini tidak lagi digunakan dalam upaya untuk menjaga agar masalah gaya tetap terpisah dari markup kami, terutama karena
desain web mengharuskan untuk menentukan ukuran berdasarkan persentase melalui CSS. Pada masa-masa awal desain web responsif, "hapus
atribut width dan height yang tidak digunakan" adalah saran umum, seperti nilai yang kami tentukan dalam CSS—max-width: 100% dan
height: auto—akan menggantinya.
<img src="image.jpg" alt="…">
img {
max-width: 100%;
height: auto;
}
Setelah menghapus atribut height dan width seperti di contoh sebelumnya, satu-satunya metode yang dimiliki browser untuk menentukan
tinggi gambar dalam situasi ini adalah meminta sumber, mengurainya, dan merendernya pada rasio aspek intrinsiknya, berdasarkan
lebar ruang yang ditempati dalam tata letak setelah stylesheet diterapkan. Sebagian besar proses ini terjadi setelah laman
dirender, dengan tinggi yang baru dihitung yang menyebabkan pergeseran tata letak tambahan.
Mulai 2019, perilaku browser diupdate untuk menangani atribut width dan height secara berbeda. Daripada menggunakan nilai-nilai ini,
untuk menentukan ukuran tetap berbasis piksel dari elemen img dalam tata letak, atribut ini dapat dianggap mewakili
rasio aspek gambar, meskipun sintaksisnya sama. {i>Browser<i} modern akan membagi nilai-nilai ini satu sama lain untuk
menentukan rasio aspek intrinsik elemen img sebelum halaman dirender, yang memungkinkannya mencadangkan ruang yang akan ditempati gambar saat tata letak dirender.
Sebagai aturan, Anda harus selalu menggunakan atribut height dan width di <img>, dengan nilai yang sesuai dengan ukuran intrinsik sumber gambar Anda—jadi
selama Anda memastikan bahwa Anda telah menentukan height: auto bersama max-width: 100% untuk mengganti tinggi dari atribut HTML.
<img src="image.jpg" height="200" width="400" alt="…">
img {
max-width: 100%;
height: auto;
}
Dengan menggunakan atribut width dan height di elemen <img>, Anda akan menghindari skor CLS yang tinggi karena gambar.
Penting untuk dicatat bahwa pendekatan ini tidak memiliki kelemahan, karena pendekatan ini mengandalkan perilaku browser yang telah lama ada—browser apa pun
dengan dukungan untuk CSS dasar akan berfungsi seperti biasa, dengan atribut height dan width di markup Anda akan diganti oleh gaya Anda.
Sementara atribut width dan height dengan cekatan menghindari masalah CLS dengan menyediakan ruang tata letak yang diperlukan untuk gambar Anda,
pengguna dengan celah kosong atau placeholder berkualitas rendah sambil
proses menunggu gambar ditransfer dan
dirender juga tidak ideal. Meskipun ada hal-hal yang dapat Anda lakukan untuk mengurangi
gambar yang lambat dimuat, satu-satunya cara untuk menampilkan gambar yang dirender sepenuhnya kepada pengguna secara lebih cepat adalah dengan mengurangi ukuran transfernya.
Largest Contentful Paint (LCP)
Largest Contentful Paint (LCP) mengukur waktu yang diperlukan untuk merender elemen “contentful” terbesar yang terlihat di area pandang pengguna— elemen konten yang menempati persentase terbesar dari halaman yang terlihat. Ini mungkin tampak seperti metrik yang terlalu spesifik di permukaan, tetapi itu berfungsi sebagai proxy praktis untuk titik tempat sebagian besar halaman telah dirender, dari perspektif pengguna. LCP sangat penting, ukuran kinerja (yang dirasakan).
Metrik seperti DOMContentLoaded atau peristiwa window.onload dapat berguna untuk menentukan kapan proses pemuatan halaman saat ini
telah selesai secara teknis, tetapi belum tentu sesuai dengan pengalaman pengguna terhadap halaman. Sedikit keterlambatan dalam merender elemen
di luar area pandang pengguna akan diperhitungkan dalam salah satu metrik ini, tetapi kemungkinan besar akan sama sekali tidak terdeteksi oleh pengguna di dunia nyata.
LCP yang panjang berarti tayangan pertama pengguna atas suatu halaman—konten terpenting dalam area pandang saat ini—adalah halaman tersebut lambat,
atau langsung rusak.
Persepsi pengguna yang dicatat oleh LCP memiliki dampak langsung terhadap pengalaman pengguna. Eksperimen yang dilakukan oleh Vodafone baru saja tahun lalu menemukan bahwa peningkatan 31% dalam LCP tidak hanya menghasilkan 8% lebih banyak penjualan—hasil yang bagus itu sendiri—tetapi dari jumlah total pengguna mereka, menemukan 15% peningkatan jumlah pengunjung yang menjadi calon pelanggan ("rasio pengunjung-ke-prospek") dan peningkatan jumlah pengguna sebesar 11% yang mengunjungi keranjang mereka ("rasio keranjang ke kunjungan").
Di lebih dari 70% halaman web, elemen terbesar pada
area pandang melibatkan gambar, baik sebagai elemen <img> yang berdiri sendiri atau elemen dengan gambar latar. Dengan kata lain,
{i>SUMIF<i} memiliki daftar sel
70% halaman Skor LCP didasarkan pada performa gambar. Tidak perlu banyak imajinasi untuk mengetahui alasannya: besar, menarik perhatian
gambar dan logo sangat mungkin ditemukan "di paruh atas".
Ada beberapa langkah yang dapat Anda lakukan untuk menghindari penundaan LCP: pertama, jangan pernah menentukan loading="lazy" di "paruh atas" gambar,
karena menunda permintaan hingga halaman selesai dirender kemungkinan akan berdampak negatif pada skor LCP Anda.
Kedua, menggunakan fetchpriority="high" dapat memberi tahu browser bahwa transfer gambar ini harus diprioritaskan di atas gambar di tempat lain pada halaman.
Dengan mengingat aturan-aturan tersebut, hal terpenting yang dapat Anda lakukan untuk meningkatkan skor LCP halaman adalah mengurangi jumlah waktu yang diperlukan untuk mentransfer dan merender gambar-gambar tersebut. Agar bisa melakukannya, sumber gambar harus sekecil dan seefisien mungkin mungkin (tanpa mengorbankan kualitasnya) dan memastikan pengguna hanya mendapatkan aset gambar yang memaksimalkan masuk akal untuk konteks penjelajahan mereka.
Kesimpulan
Aset gambar adalah yang paling cepat menghabiskan daya pengguna Anda bandwidth—bandwidth yang diambil untuk mentransfer setiap aset lain yang diperlukan untuk merender halaman. Gambar menimbulkan masalah yang signifikan terkait performa yang dirasakan, baik selama maupun setelah halaman sekitarnya telah dirender. Singkatnya: aset gambar dapat merusak.
Sangat berbahaya, sementara "web akan lebih baik dengan lebih sedikit gambar" pasti akan benar dalam hal kinerja saja, hal itu juga akan merugikan penggunanya. Gambar adalah bagian penting dari web, dan Anda tidak boleh mengorbankan kualitas konten yang bermakna hanya untuk kinerja saja.
Dalam sisa kursus ini, Anda akan mempelajari teknologi yang mendukung aset gambar dan teknik kami dalam memitigasi dampak performa, tanpa mengorbankan kualitas.