Saran berbasis data untuk pemuatan lambat gambar dengan mempertimbangkan Core Web Vitals.
Pemuatan lambat adalah teknik yang menunda download resource hingga diperlukan, untuk menghemat data dan mengurangi pertentangan jaringan untuk aset penting. Kebijakan ini menjadi standar web pada tahun 2019 dan kini loading="lazy" untuk gambar didukung oleh sebagian besar browser utama.
Panduan ini merangkum cara data transparansi web yang tersedia untuk umum dan pengujian A/B ad hoc dianalisis untuk memahami karakteristik adopsi dan performa dari pemuatan lambat gambar tingkat browser. Temuan ini menunjukkan bahwa pemuatan lambat dapat menjadi alat yang sangat efektif untuk mengurangi byte gambar yang tidak diperlukan, tetapi penggunaan yang berlebihan dapat berdampak negatif pada performa. Sebenarnya, analisis ini menunjukkan bahwa memuat gambar dengan lebih cepat di dalam area tampilan awal—sekaligus dengan lambat memuat sisanya—dapat memberi kita hasil terbaik dari kedua hal tersebut: lebih sedikit byte yang dimuat dan peningkatan Core Web Vitals.
Adopsi
Menurut data terbaru di HTTP Archive, pemuatan lambat gambar bawaan digunakan oleh 29% situs dan tingkat adopsi situs terus meningkat dengan pesat.
Membuat kueri data mentah dalam project Arsip HTTP memberi kami pemahaman yang lebih jelas tentang jenis situs apa yang mendorong adopsi: 84% situs yang menggunakan pemuatan lambat gambar tingkat browser menggunakan WordPress, 2% menggunakan CMS lain, dan 14% sisanya tidak menggunakan CMS yang dikenal. Hasil ini memperjelas bagaimana WordPress terdepan dalam penerapannya.
Tingkat adopsi juga perlu diperhatikan. Satu tahun lalu tepatnya pada bulan Juli 2020, situs WordPress yang menggunakan pemuatan lambat terdiri dari puluhan ribu situs dalam korpus sekitar 6 juta (1% dari total). Adopsi pemuatan lambat di WordPress saja telah berkembang menjadi lebih dari 1 juta situs (14% dari total).
Performa korelasi
Dengan mempelajari lebih dalam HTTP Archive, perbandingan performa halaman dengan dan tanpa pemuatan lambat gambar tingkat browser dapat dibandingkan dengan metrik Largest Contentful Paint (LCP). Data LCP berasal dari pengalaman pengguna nyata dari Laporan Pengalaman Pengguna Chrome (CrUX), bukan pengujian sintetis di lab. Diagram berikut menggunakan box-and-whisker plot untuk memvisualisasikan distribusi setiap halaman LCP ke-75 persentil: garis mewakili persentil ke-10 dan ke-90 dan kotak-kotak mewakili persentil ke-25 dan ke-75.
Halaman median tanpa pemuatan lambat memiliki LCP persentil ke-75 sebesar 2.922 milidetik, dibandingkan dengan 3.546 milidetik untuk halaman median dengan pemuatan lambat. Secara keseluruhan, situs yang menggunakan pemuatan lambat cenderung memiliki performa LCP yang lebih buruk.
Penting untuk menunjukkan bahwa ini adalah hasil korelasi dan tidak selalu merujuk pada pemuatan lambat sebagai penyebab performa yang lebih lambat. Bisa diduga, jika situs WordPress cenderung sedikit lebih lambat, dan mengingat betapa banyak mereka membentuk kelompok pemuatan lambat, itulah yang dapat menjelaskan perbedaannya. Untuk menghilangkan variabilitas tersebut, fokus dapat dipersempit secara khusus ke situs WordPress.
Sayangnya, pola yang sama muncul saat melihat perincian halaman WordPress; aplikasi yang menggunakan pemuatan lambat cenderung memiliki performa LCP yang lebih lambat. Halaman median WordPress tanpa pemuatan lambat memiliki LCP persentil ke-75 sebesar 3.495 milidetik, dibandingkan dengan 3.768 milidetik untuk halaman median dengan pemuatan lambat.
Hal ini masih tidak membuktikan bahwa pemuatan lambat menyebabkan halaman menjadi lebih lambat, tetapi penggunaannya bertepatan dengan performa yang lebih lambat. Untuk mencoba menjawab pertanyaan kausalitas, uji A/B berbasis lab telah disiapkan.
Kinerja kausal
Tujuan pengujian A/B ini adalah untuk membuktikan atau menyangkal hipotesis bahwa pemuatan lambat gambar bawaan, seperti yang diimplementasikan di WordPress core, menghasilkan performa LCP yang lebih lambat dan lebih sedikit byte gambar. Metodologi yang digunakan adalah menguji situs WordPress demo dengan tema twentytwentyone. Jenis arsip dan halaman tunggal diuji, seperti halaman beranda dan halaman artikel, di desktop dan perangkat seluler teremulasi menggunakan WebPageTest. Setiap kombinasi halaman dengan dan tanpa pemuatan lambat yang diaktifkan diuji, dan setiap pengujian dijalankan sembilan kali untuk mendapatkan nilai LCP median dan jumlah byte gambar.
| Seri | default | nonaktif | Perbedaan dengan default |
|---|---|---|---|
| twentytwentyone-archive-desktop | 2.029. | 1.759. | -13% |
| twentytwentyone-archive-mobile | 1.657. | 1.403. | -15% |
| twentytwentyone-desktop-tunggal | 1.655. | 1.726. | 4% |
| twentytwentyone-seluler tunggal | 1.352. | 1.384. | 2% |
Hasil ini membandingkan LCP median dalam milidetik untuk pengujian pada arsip dan satu halaman untuk desktop dan seluler. Saat pemuatan lambat dinonaktifkan di halaman arsip, LCP ditingkatkan dengan margin yang signifikan. Namun, pada satu halaman, perbedaannya tidak terlalu besar.
Menonaktifkan pemuatan lambat tampaknya membuat satu halaman sedikit lebih cepat. Namun, perbedaan dalam LCP kurang dari satu deviasi standar untuk pengujian desktop dan seluler, sehingga ini dapat dikaitkan dengan varians dan mempertimbangkan perubahan netral secara keseluruhan. Sebagai perbandingan, perbedaan untuk halaman arsip lebih mendekati dua hingga tiga deviasi standar.
| Seri | default | nonaktif | Perbedaan dengan default |
|---|---|---|---|
| twentytwentyone-archive-desktop | 577 | 1173 | 103% |
| twentytwentyone-archive-mobile | 172 | 378 | 120% |
| twentytwentyone-desktop-tunggal | 301 | 850 | 183% |
| twentytwentyone-seluler tunggal | 114 | 378 | 233% |
Hasil ini membandingkan jumlah median byte gambar (dalam KB) untuk setiap pengujian. Seperti yang diharapkan, pemuatan lambat memiliki efek positif yang sangat jelas dalam mengurangi jumlah byte gambar. Jika pengguna yang sebenarnya men-scroll seluruh halaman, semua gambar akan tetap dimuat saat melintas ke area pandang, tetapi hasil ini menunjukkan peningkatan performa pemuatan halaman awal.
Untuk meringkas hasil pengujian A/B, teknik pemuatan lambat yang digunakan oleh WordPress dengan sangat jelas membantu mengurangi byte gambar dengan mengorbankan LCP yang tertunda.
Menguji perbaikan
Aspek terpenting dari WordPress Implementasi pemuatan lambat saat ini untuk eksperimen ini adalah pemuatan gambar secara lambat dalam area tampilan (paruh atas). Postingan blog CMS mengonfirmasi hal ini sebagai pola yang harus dihindari, tetapi data eksperimental pada saat itu menunjukkan bahwa efeknya pada LCP minimal dan layak untuk menyederhanakan penerapan di WordPress core.
Dengan data baru ini, perbaikan eksperimental dibuat untuk menghindari pemuatan lambat gambar yang berada di paruh atas, dan perbaikan tersebut diuji dalam kondisi yang sama seperti pengujian A/B pertama.
| Seri | default | nonaktif | perbaiki | Perbedaan dengan default | Perbedaan dengan yang dinonaktifkan |
|---|---|---|---|---|---|
| twentytwentyone-archive-desktop | 2.029. | 1.759. | 1.749. | -14% | -1% |
| twentytwentyone-archive-mobile | 1.657. | 1.403. | 1.352. | -18% | -4% |
| twentytwentyone-desktop-tunggal | 1.655. | 1.726. | 1.676. | 1% | -3% |
| twentytwentyone-seluler tunggal | 1.352. | 1.384. | 1.342. | -1% | -3% |
Hasil ini jauh lebih menjanjikan. Pemuatan lambat hanya pada gambar di paruh bawah akan menghasilkan pembalikan penuh dari regresi LCP dan bahkan mungkin mendapatkan sedikit peningkatan atas penonaktifan pemuatan lambat sepenuhnya. Bagaimana bisa lebih cepat daripada pemuatan lambat sama sekali? Salah satu penjelasannya adalah dengan tidak memuat gambar paruh bawah, akan terjadi lebih sedikit pertentangan jaringan dengan gambar LCP, sehingga dapat dimuat lebih cepat.
| Seri | default | nonaktif | perbaiki | Perbedaan dengan default | Perbedaan dengan yang dinonaktifkan |
|---|---|---|---|---|---|
| twentytwentyone-archive-desktop | 577 | 1173 | 577 | 0% | -51% |
| twentytwentyone-archive-mobile | 172 | 378 | 172 | 0% | -54% |
| twentytwentyone-desktop-tunggal | 301 | 850 | 301 | 0% | -65% |
| twentytwentyone-seluler tunggal | 114 | 378 | 114 | 0% | -70% |
Terkait byte gambar, perbaikan ini sama sekali tidak memiliki perubahan jika dibandingkan dengan perilaku default. Hal ini sangat bagus karena itulah salah satu kekuatan pendekatan saat ini.
Perbaikan ini memiliki beberapa persyaratan. WordPress menentukan gambar mana yang akan dimuat lambat di sisi server, yang berarti WordPress tidak mengetahui apa pun tentang ukuran area pandang pengguna atau apakah gambar awalnya dimuat di dalamnya. Perbaikan menggunakan heuristik gambar di markup untuk menebak apakah konten dimuat di area pandang. Khususnya, jika gambar tersebut adalah gambar unggulan pertama di halaman atau gambar pertama di konten utama, gambar tersebut dianggap berada di paruh atas, atau dekat dengannya, dan tidak akan dimuat dengan lambat.
Kondisi tingkat halaman seperti jumlah kata dalam judul atau jumlah teks paragraf di awal konten utama dapat memengaruhi apakah gambar berada dalam area tampilan atau tidak. Ada juga kondisi tingkat pengguna yang mungkin memengaruhi akurasi heuristik, terutama ukuran area pandang dan penggunaan link anchor yang mengubah posisi scroll halaman.
Oleh karena itu, penting untuk dipahami bahwa perbaikan hanya dikalibrasi untuk memberikan performa yang baik dalam kasus umum, dan penyesuaian mungkin diperlukan agar hasil ini berlaku pada semua skenario di dunia nyata.
Penerapan
Setelah cara yang lebih baik untuk memuat gambar dengan lambat telah diidentifikasi, semua penghematan gambar, dan performa LCP yang lebih cepat, bagaimana situs dapat mulai menggunakannya? Perubahan prioritas tertinggi adalah mengirimkan patch ke WordPress core untuk menerapkan perbaikan eksperimental. Panduan dalam postingan blog Pemuatan lambat di tingkat browser untuk CMS juga akan diperbarui untuk menjelaskan efek negatif pemuatan lambat di paruh atas dan cara CMS menggunakan heuristik untuk menghindarinya.
Karena praktik terbaik ini berlaku untuk semua developer web, ada baiknya menandai anti-pola pemuatan lambat di alat seperti Lighthouse. Lihat permintaan fitur di GitHub jika Anda tertarik untuk mengikuti progres audit tersebut. Sebelum itu, satu hal yang dapat dilakukan developer untuk menemukan instance elemen LCP yang lambat dimuat adalah dengan menambahkan logging yang lebih mendetail ke data kolom mereka.
new PerformanceObserver((list) => {
const latestEntry = list.getEntries().at(-1);
if (latestEntry?.element?.getAttribute('loading') == 'lazy') {
console.warn('Warning: LCP element was lazy loaded', latestEntry);
}
}).observe({type: 'largest-contentful-paint', buffered: true});
Cuplikan JavaScript sebelumnya akan mengevaluasi elemen LCP terbaru dan mencatat peringatan jika pemuatannya lambat.
Hal ini juga menyoroti keunggulan teknik pemuatan lambat dan potensi peningkatan API di level platform. Misalnya, ada masalah yang belum terselesaikan di Chromium untuk bereksperimen dengan memuat beberapa gambar pertama secara native dengan segera, mirip dengan perbaikan, meskipun memiliki atribut loading.
Kesimpulan
Jika situs Anda menggunakan pemuatan lambat gambar tingkat browser, periksa cara penerapannya dan jalankan pengujian A/B untuk lebih memahami biaya performanya. Mungkin akan mendapatkan manfaat dari pemuatan gambar yang lebih cepat di paruh atas. Jika Anda memiliki situs WordPress, diharapkan akan segera ada patch landing di WordPress core. Jika Anda menggunakan CMS lain, pastikan CMS tersebut mengetahui potensi masalah performa yang dijelaskan di sini.
Mencoba API platform web yang relatif baru dapat menimbulkan risiko dan juga keuntungan—semuanya disebut fitur canggih karena suatu alasan. Meskipun kami mulai merasakan betapa sulitnya pemuatan lambat gambar tingkat browser, kami juga melihat keuntungan dari cara menggunakannya untuk mencapai performa yang lebih baik.
Foto oleh Frankie Lopez di Unsplash