Saran berbasis data untuk pemuatan lambat gambar dengan mempertimbangkan Data Web Inti.
Pemuatan lambat adalah teknik untuk menunda download resource hingga diperlukan, sehingga menghemat data
dan mengurangi pertentangan jaringan untuk aset penting. Ini menjadi standar web pada
2019, dan saat ini loading="lazy" untuk gambar
didukung oleh sebagian besar browser utama. Kedengarannya bagus, tetapi adakah
yang berupa pemuatan lambat yang berlebihan?
Postingan ini merangkum cara kami menganalisis data transparansi web yang tersedia untuk publik dan pengujian A/B ad hoc untuk memahami karakteristik adopsi dan performa pemuatan lambat gambar native. Kami menemukan 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. Konkretnya, analisis kami menunjukkan bahwa memuat gambar dengan lebih cepat di area pandang awal—meskipun pemuatan lambat sisanya—dapat memberi kami yang terbaik dari kedua hal tersebut: lebih sedikit byte yang dimuat dan meningkatkan Data Web Inti.
Adopsi
Menurut data terbaru di Arsip HTTP, pemuatan lambat gambar native digunakan oleh 17% situs dan penggunaannya berkembang dengan pesat. Pijakan dalam ekosistem ini sangat luar biasa untuk API yang relatif baru.
Membuat kueri data mentah di project Arsip HTTP memberi kami pemahaman yang lebih jelas tentang jenis situs apa yang mendorong adopsi: 84% situs yang menggunakan pemuatan lambat gambar native menggunakan WordPress, 2% menggunakan CMS lain, dan 14% sisanya tidak menggunakan CMS yang dikenal. Hasil ini memperjelas bagaimana WordPress memimpin tagihan dalam penggunaan.
Tingkat penggunaan juga perlu diperhatikan. Satu tahun yang lalu pada bulan Juli 2020, situs WordPress yang menggunakan pemuatan lambat menghasilkan puluhan ribu situs dalam korpus sekitar 6 juta (1% dari total). Adopsi pemuatan lambat di WordPress telah berkembang menjadi lebih dari 1 juta situs (14% dari total).
Performa korelasi
Menggali lebih dalam ke Arsip HTTP, kita dapat membandingkan performa halaman dengan dan tanpa pemuatan lambat gambar native dengan metrik Largest Contentful Paint (LCP). Data LCP berasal dari pengalaman pengguna nyata dari Laporan Pengalaman Pengguna Chrome (CrUX), bukan dari pengujian sintetis di lab. Diagram di bawah ini menggunakan box-and-whisker plot untuk memvisualisasikan distribusi LCP persentil ke-75 setiap halaman: garis tersebut mewakili persentil ke-10 dan ke-90, sedangkan kotak-kotak tersebut 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.
Perlu diperhatikan bahwa ini merupakan hasil korelasi dan tidak selalu mengarah pada pemuatan lambat sebagai penyebab performa yang lebih lambat. Hipotesis, jika situs WordPress cenderung sedikit lebih lambat, dan mengingat seberapa besar mereka membentuk kelompok pemuatan lambat, hal ini dapat menjelaskan perbedaannya. Jadi, mari kita coba menghilangkan variabilitas tersebut dengan hanya melihat situs WordPress.
Sayangnya, pola yang sama muncul saat kita melihat perincian halaman WordPress; mereka yang menggunakan pemuatan lambat cenderung memiliki performa LCP yang lebih lambat. Halaman WordPress median tanpa pemuatan lambat memiliki LCP persentil ke-75 sebesar 3.495 md, dibandingkan dengan 3.768 md untuk halaman median dengan pemuatan lambat.
Hal ini tetap tidak membuktikan bahwa pemuatan lambat menyebabkan halaman menjadi lebih lambat, tetapi penggunaannya bertepatan dengan performa yang lebih lambat. Untuk mencoba menjawab pertanyaan kausalitas, kami menyiapkan pengujian A/B berbasis lab.
Performa kausal
Tujuan pengujian A/B adalah untuk membuktikan atau menyangkal hipotesis bahwa pemuatan lambat gambar native, seperti yang diterapkan di inti WordPress, menghasilkan performa LCP yang lebih lambat dan jumlah byte gambar yang lebih sedikit. Metodologi yang kami gunakan adalah menguji demo situs WordPress dengan tema twentytwentyone. Kami menguji jenis halaman arsip dan halaman tunggal, yang seperti halaman beranda dan artikel, di desktop dan perangkat seluler teremulasi menggunakan WebPageTest. Kami menguji setiap kombinasi halaman dengan dan tanpa pengaktifan pemuatan lambat, dan kami menjalankan setiap pengujian sembilan kali untuk mendapatkan nilai LCP median dan jumlah byte gambar.
| Series | default | nonaktif | Perbedaan dari default |
|---|---|---|---|
| twentytwentyone-archive-desktop | 2.029 | 1.759 | -13% |
| twentytwentyone-archive-mobile | 1.657 | 1.403 | -15% |
| twentytwentyone-single-desktop | 1.655 | 1.726 | 4% |
| twentytwentyone-single-mobile | 1.352 | 1.384 | 2% |
Hasil di atas membandingkan LCP median dalam milidetik untuk pengujian pada arsip dan halaman tunggal untuk desktop dan seluler. Saat kami menonaktifkan pemuatan lambat di halaman arsip, kami mengamati peningkatan LCP sebesar margin yang signifikan. Namun, di satu halaman, perbedaannya lebih netral.
Perlu diperhatikan bahwa efek menonaktifkan pemuatan lambat sebenarnya membuat satu halaman menjadi sedikit lebih cepat. Namun, perbedaan LCP kurang dari satu deviasi standar untuk pengujian desktop dan seluler, jadi kami mengatribusikan ini ke varians dan mempertimbangkan perubahan yang netral secara keseluruhan. Sebagai perbandingan, perbedaan untuk halaman arsip lebih seperti dua hingga tiga deviasi standar.
| Series | default | nonaktif | Perbedaan dari default |
|---|---|---|---|
| twentytwentyone-archive-desktop | 577 | 1173 | 103% |
| twentytwentyone-archive-mobile | 172 | 378 | 120% |
| twentytwentyone-single-desktop | 301 | 850 | 183% |
| twentytwentyone-single-mobile | 114 | 378 | 233% |
Hasil di atas 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 sebenarnya men-scroll seluruh halaman ke bawah, semua gambar akan tetap dimuat saat melewati area pandang, tetapi hasil ini menunjukkan peningkatan performa dari pemuatan halaman awal.
Untuk meringkas hasil pengujian A/B, teknik pemuatan lambat yang digunakan oleh WordPress dengan sangat jelas membantu mengurangi byte gambar, tetapi pada mengorbankan LCP yang tertunda.
Menguji perbaikan
Sebelum membahas cara perbaikan tersebut diterapkan, mari kita lihat cara kerja pemuatan lambat di WordPress saat ini. Aspek terpenting dari implementasi saat ini adalah bahwa gambar secara lambat dimuat di paruh atas (di dalam area pandang). Postingan blog CMS mengonfirmasi hal ini sebagai pola yang harus dihindari, tetapi data eksperimental pada saat itu menunjukkan bahwa efek pada LCP berjumlah kecil dan layak untuk menyederhanakan implementasi di inti WordPress.
Mengingat data baru ini, kami membuat perbaikan eksperimental yang menghindari gambar pemuatan lambat yang berada di paruh atas dan kami mengujinya dalam kondisi yang sama seperti pengujian A/B pertama.
| Series | default | nonaktif | fix | Perbedaan dari 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-single-desktop | 1.655 | 1.726 | 1.676 | 1% | -3% |
| twentytwentyone-single-mobile | 1.352 | 1.384 | 1.342 | -1% | -3% |
Hasil ini jauh lebih menjanjikan. Pemuatan lambat hanya untuk gambar di paruh bawah mengakibatkan pembalikan penuh regresi LCP dan bahkan mungkin sedikit peningkatan dibandingkan menonaktifkan LCP sepenuhnya. Bagaimana bisa lebih cepat daripada tidak memuat lambat sama sekali? Salah satu penjelasannya adalah dengan tidak memuat gambar di paruh bawah, akan terjadi lebih sedikit pertentangan jaringan dengan gambar LCP, sehingga memungkinkannya dimuat lebih cepat.
| Series | default | nonaktif | fix | Perbedaan dari default | Perbedaan dengan yang dinonaktifkan |
|---|---|---|---|---|---|
| twentytwentyone-archive-desktop | 577 | 1173 | 577 | 0% | -51% |
| twentytwentyone-archive-mobile | 172 | 378 | 172 | 0% | -54% |
| twentytwentyone-single-desktop | 301 | 850 | 301 | 0% | -65% |
| twentytwentyone-single-mobile | 114 | 378 | 114 | 0% | -70% |
Dalam hal byte gambar, perbaikan sama sekali tidak mengalami perubahan dibandingkan dengan perilaku default. Hal ini sangat bagus karena merupakan salah satu keunggulan pendekatan saat ini.
Perbaikan ini memiliki sejumlah kekurangan. WordPress menentukan gambar yang akan dimuat dengan lambat di sisi server, yang berarti WordPress tidak mengetahui apa pun tentang ukuran area pandang pengguna atau apakah gambar akan dimuat pertama kali di dalamnya. Jadi, perbaikan menggunakan heuristik tentang lokasi relatif gambar dalam markup untuk menebak apakah gambar akan berada di area pandang atau tidak. Khususnya, jika gambar adalah gambar unggulan pertama di halaman atau gambar pertama di konten utama, gambar 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 pandang. Ada juga kondisi tingkat pengguna yang dapat memengaruhi akurasi heuristik, terutama ukuran area tampilan dan penggunaan link anchor yang mengubah posisi scroll halaman. Oleh karena itu, penting untuk mengonfirmasi bahwa perbaikan hanya dikalibrasi untuk memberikan performa yang baik dalam kasus umum dan penyesuaian mungkin diperlukan agar hasil ini berlaku untuk semua skenario dunia nyata.
Meluncurkan
Setelah kita mengidentifikasi cara yang lebih baik untuk memuat gambar secara lambat, semua penghematan gambar, dan performa LCP yang lebih cepat, bagaimana cara membuat situs mulai menggunakannya? Perubahan prioritas tertinggi adalah mengirimkan patch ke inti WordPress untuk menerapkan perbaikan eksperimental. Kami juga akan memperbarui panduan di postingan blog Pemuatan lambat tingkat browser untuk CMS guna mengklarifikasi efek negatif dari pemuatan lambat paruh atas dan cara CMS menggunakan heuristik untuk menghindarinya.
Karena praktik terbaik ini berlaku untuk semua developer web, ada baiknya Anda juga melaporkan antipola pemuatan lambat di alat seperti Lighthouse. Lihat permintaan fitur di GitHub jika Anda tertarik untuk mengikuti progres audit tersebut. Sebelum tanggal tersebut, 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 di atas akan mengevaluasi elemen LCP terbaru dan mencatat peringatan jika dimuat lambat.
Hal ini juga menyoroti keunggulan teknik pemuatan lambat dan potensi peningkatan
API di level platform. Misalnya, ada masalah terbuka di Chromium untuk
bereksperimen dengan pemuatan native
beberapa gambar pertama dengan segera, mirip dengan perbaikan, meskipun memiliki atribut loading.
Menyelesaikan
Jika situs Anda menggunakan pemuatan lambat gambar native, periksa cara situs tersebut diterapkan dan jalankan pengujian A/B untuk lebih memahami biaya performanya. Anda bisa mendapatkan manfaat dari pemuatan gambar yang lebih cepat di paruh atas. Jika Anda memiliki situs WordPress, diharapkan akan ada patch landing di inti WordPress dalam waktu dekat. Jika menggunakan CMS lain, pastikan Anda mengetahui potensi masalah performa yang dijelaskan di sini.
Mencoba API platform web yang relatif baru dapat memiliki risiko dan juga manfaat—keduanya disebut fitur canggih karena suatu alasan. Meskipun kami mulai memahami betapa sulitnya pemuatan lambat gambar native, kami juga melihat keuntungan dari penggunaannya untuk mencapai performa yang lebih baik.
Foto oleh Frankie Lopez di Unsplash