Largest Contentful Paint (LCP) halaman dapat menjadi rumit untuk ditingkatkan, karena sering kali melibatkan beberapa bagian yang bergerak dan kompromi. Postingan ini melihat data kolom dari pemuatan halaman sebenarnya di seluruh web untuk menentukan pada bagian mana developer harus memfokuskan upaya pengoptimalan mereka.
Saran LCP klasik: kurangi ukuran gambar Anda.
Untuk sebagian besar halaman di web, elemen LCP adalah gambar. Maka, wajar saja untuk mengasumsikan bahwa cara terbaik untuk meningkatkan LCP adalah dengan mengoptimalkan gambar LCP Anda.
Dalam lima tahun atau lebih sejak LCP diperkenalkan, sering kali hal tersebut merupakan saran judul. Pastikan gambar Anda memiliki ukuran yang tepat dan cukup terkompresi, dan mungkin gunakan format gambar abad ke-21 selagi Anda berada di sana. Lighthouse bahkan memiliki tiga audit berbeda untuk membuat saran ini.
Salah satu alasan mengapa hal ini menjadi saran umum adalah karena jumlah byte yang berlebihan mudah diukur dan alat kompresi gambar mudah disarankan. Bergantung pada pipeline build dan deployment Anda, pipeline ini juga mungkin mudah diimplementasikan.
Jika benar, lakukanlah! Mengirim lebih sedikit {i>byte<i} kepada pengguna Anda hampir selalu menguntungkan. Ada banyak situs di web yang masih menayangkan gambar berukuran sangat besar yang bahkan dapat diperbaiki dengan kompresi dasar.
Namun, saat kami mulai mengamati data performa lapangan bagi pengguna di Chrome untuk mengetahui durasi penggunaan LCP, kami menemukan bahwa waktu download gambar hampir tidak pernah menjadi bottleneck.
Sebaliknya, bagian lain dari LCP adalah masalah yang jauh lebih besar.
Perincian sub-bagian LCP
Untuk memahami area peluang terbesar untuk meningkatkan LCP, kami meninjau data dari sub-bagian LCP, seperti yang dijelaskan dalam Mengoptimalkan LCP.
Meskipun setiap halaman dan setiap framework dapat mengambil pendekatan yang berbeda untuk memuat dan menampilkan apa yang menjadi elemen LCP halaman, masing-masing dapat dibagi menjadi sub-bagian ini:
Mengutip dari artikel tersebut, sub-bagiannya adalah:
- Time to First Byte (TTFB)
- Waktu sejak pengguna mulai memuat halaman hingga browser menerima byte pertama respons dokumen HTML.
- Penundaan pemuatan resource
- Waktu antara TTFB dan saat browser mulai memuat resource LCP. Jika
elemen LCP tidak memerlukan pemuatan resource untuk dirender, kali ini adalah
0. - Durasi pemuatan resource
- Durasi waktu yang diperlukan untuk memuat resource LCP itu sendiri. Jika LCP
tidak memerlukan pemuatan resource untuk dirender, kali ini adalah
0. - Penundaan render elemen
- Waktu antara saat resource LCP selesai dimuat dan elemen LCP proses rendering sepenuhnya.
Data performa navigasi yang sebenarnya
| Rating LCP | TTFB (md) | Penundaan pemuatan gambar (md) | Durasi pemuatan gambar (md) | Penundaan render (md) |
|---|---|---|---|---|
| Baik | 600 | 350 | 160 | 230 |
| Perlu perbaikan | 1.360. | 720 | 270 | 310 |
| Buruk | 2.270. | 1.290. | 350 | 360 |
Untuk postingan ini, kami menggunakan data dari navigasi halaman dengan gambar subresource LCP di Chrome untuk melihat sub-bagian LCP. Kami telah melihat data semacam ini sebelumnya, tetapi tidak pernah menggunakan data lapangan untuk melihat di mana pengguna sungguhan menghabiskan waktu mereka sambil menunggu LCP halaman.
Seperti Core Web Vitals, kami mengambil persentil ke-75 (p75) dari setiap sub-bagian LCP untuk setiap origin dalam set data CrUX, sehingga menghasilkan empat distribusi nilai p75 (satu untuk setiap sub-bagian). Untuk meringkas distribusi ini, kami mengambil median nilai tersebut di semua origin untuk masing-masing dari empat sub-bagian LCP.
Terakhir, kita membagi origin ke dalam bucket berdasarkan apakah origin tersebut memiliki status "baik", "perlu peningkatan", atau "buruk" LCP pada persentil ke-75. Hal ini membantu menunjukkan perbedaan antara origin dengan LCP yang baik dan origin dengan LCP yang buruk.
Kurangi ukuran gambar LCP Anda? Kali ini dengan data
Durasi pemuatan adalah ukuran berapa lama waktu yang diperlukan untuk mengambil resource LCP, dalam hal ini, gambar. Waktu ini biasanya sebanding dengan jumlah byte dalam gambar, sehingga semua saran terkait performa untuk mengurangi jumlah byte tersebut.
Saat melihat ke mana waktu mengarah pada grafik sebelumnya, satu hal yang menarik adalah tidak ada banyak waktu yang dihabiskan dalam durasi pemuatan gambar. Bahkan, ini adalah sub-bagian LCP terpendek, di semua bucket LCP. Durasi pemuatan akan lebih lama untuk origin LCP yang buruk dibandingkan dengan origin LCP yang baik, tetapi itu masih belum menghabiskan sebagian besar waktu.
Sebagian besar origin dengan LCP buruk, menghabiskan kurang dari 10% waktu LCP p75-nya untuk mendownload gambar LCP.
Ya, Anda harus memastikan gambar sudah dioptimalkan, tetapi itu hanyalah salah satu bagian dari peningkatan LCP. Dan sudah jelas dari data ini bahwa untuk origin yang umum di web, potensi perolehan milidetik untuk LCP secara keseluruhan adalah kecil, tidak peduli seberapa canggih skema kompresinya.
Satu kejutan terakhir: durasi pemuatan lambat biasanya disebabkan oleh perangkat seluler dan kualitas jaringan seluler. Kita mungkin pernah memperkirakan ponsel biasa memerlukan waktu beberapa kali lebih lama untuk mendownload gambar yang sama dengan komputer desktop melalui koneksi berkabel. Data menunjukkan hal itu tidak lagi terjadi. Untuk origin dengan LCP yang buruk, median durasi pemuatan gambar p75 hanya 20% lebih lambat di perangkat seluler daripada desktop.
Time to First Byte (TTFB)
Untuk navigasi yang membuat permintaan jaringan, TTFB akan selalu memakan waktu. Dibutuhkan waktu untuk melakukan pencarian DNS dan memulai koneksi. Dan Anda tidak dapat mengalahkan fisika: sebuah permintaan harus melalui dunia nyata melalui kabel dan kabel optik untuk mencapai server, lalu responsnya harus melakukan perjalanan kembali. Bahkan median origin dengan LCP yang baik menghabiskan lebih dari setengah detik pada TTFB pada persentil ke-75.
Namun, perbedaan TTFB antara asal LCP yang baik dan yang buruk menunjukkan peluang untuk peningkatan. Untuk setidaknya setengah dari origin dengan LCP yang buruk, TTFB p75 sebesar 2.270 milidetik saja hampir menjamin bahwa LCP p75 tidak dapat lebih cepat daripada "baik" 2,5 detik nilai minimum. Bahkan pengurangan persentase yang sedang pada waktu tersebut akan berarti peningkatan LCP yang signifikan.
Anda mungkin tidak bisa mengalahkan fisika, tetapi ada hal-hal yang bisa dilakukan. Misalnya, jika pengguna sering kali berada di lokasi yang sangat berbeda dengan server, CDN dapat menempatkan konten lebih dekat dengan mereka.
Untuk informasi selengkapnya, lihat panduan Mengoptimalkan TTFB.
Penundaan pemuatan resource, penyebab LCP lambat yang diabaikan
Jika TTFB dapat ditingkatkan, tetapi peningkatan apa pun terikat oleh fisika, penundaan pemuatan sumber daya berpotensi dihilangkan, dalam praktiknya hanya terikat oleh arsitektur penyaluran Anda.
Sub-bagian ini mengukur waktu dari kedatangan byte pertama respons HTML (TTFB) hingga saat browser memulai permintaan untuk gambar LCP. Selama bertahun-tahun, kami telah berfokus pada waktu yang diperlukan untuk mendownload gambar LCP, tetapi kami sering mengabaikan waktu yang terbuang sebelum browser diminta untuk memulai download.
Situs median dengan LCP yang buruk menghabiskan hampir empat kali lebih lama untuk mulai mendownload gambar LCP karena benar-benar mendownloadnya, menunggu 1,3 detik antara TTFB dan permintaan gambar. Lebih dari setengah dari anggaran LCP 2,5 detik habis dalam satu sub-bagian.
Rantai dependensi adalah alasan umum untuk penundaan pemuatan yang lama. Cara yang lebih sederhana adalah memuat halaman style sheet, yang setelah browser mengatur tata letak, akan menetapkan gambar latar yang nantinya akan menjadi LCP. Semua langkah tersebut harus dilakukan sebelum browser tahu untuk mulai mendownload gambar LCP.
Menggunakan data crawl publik Arsip HTTP, yang mencatat "inisiator" rantai permintaan jaringan dari dokumen HTML ke gambar LCP, Anda dapat melihat korelasi yang jelas antara panjang rantai permintaan dengan LCP yang lebih lambat.
Kuncinya adalah memberi tahu browser sesegera mungkin akan seperti apa LCP sehingga dapat mulai memuatnya, bahkan sebelum ada tempat untuknya di tata letak halaman. Ada beberapa alat yang tersedia untuk melakukan hal ini, seperti tag <img> klasik di HTML sehingga pemindai pramuat dapat menemukannya dengan cepat dan mulai mendownloadnya, atau tag <link rel="preload"> (atau header HTTP) untuk gambar yang tidak akan menjadi <img>.
Membantu browser menentukan sumber daya mana yang harus diprioritaskan. Hal ini terutama berlaku jika halaman Anda membuat banyak permintaan selama pemuatan halaman, karena browser sering kali tidak akan mengetahui elemen LCP apa hingga setelah banyak resource tersebut dimuat dan tata letak terjadi. Menganotasi kemungkinan elemen LCP dengan atribut fetchpriority="high" (dan memastikan untuk menghindari loading="lazy") menjelaskan kepada browser untuk segera mulai memuat resource.
Baca saran selengkapnya tentang cara mengoptimalkan penundaan pemuatan.
Penundaan render
Penundaan render mengukur waktu dari saat browser memuat dan menyiapkan gambar LCP, tetapi karena alasan tertentu ada penundaan sebelum gambar tersebut ditampilkan di layar. Terkadang tugas panjang ini memblokir thread utama saat gambar siap, dalam kasus lain, mungkin berupa pilihan UI untuk menampilkan elemen tersembunyi.
Untuk origin yang biasa di web, tampaknya tidak ada peluang penundaan render yang besar, tetapi selama pengoptimalan, Anda terkadang dapat membuat penundaan render dari waktu yang sebelumnya dihabiskan di sub-bagian lain. Misalnya, jika sebuah halaman mulai melakukan pramuat gambar LCP sehingga tersedia dengan cepat, tidak akan ada lagi penundaan pemuatan yang lama, tetapi jika halaman itu sendiri belum siap untuk menampilkan gambar—seperti dari style sheet pemblokir render besar atau aplikasi rendering sisi klien yang harus menyelesaikan pemuatan semua JavaScript-nya sebelum apa pun dapat ditampilkan—LCP akan tetap lebih lambat dari yang seharusnya, dan waktu yang dihabiskan untuk menunggu sekarang akan muncul sebagai penundaan render. Inilah mengapa rendering sisi server atau HTML statis sering kali lebih diuntungkan dalam hal LCP.
Jika konten Anda terpengaruh, baca saran selengkapnya tentang cara mengoptimalkan penundaan render.
Centang semua sub-bagian tersebut
Sudah jelas bahwa untuk mengoptimalkan LCP secara efektif, developer perlu melihat pemuatan halaman secara menyeluruh, dan tidak hanya berfokus pada pengoptimalan gambar. Periksa setiap bagian waktu ke LCP, karena kemungkinan ada peluang peningkatan yang jauh lebih besar.
Untuk mengumpulkan data ini di kolom, build atribusi library web-vitals menyertakan pengaturan waktu untuk sub-bagian LCP. Chrome User Experience Report (CrUX) belum menyertakan semua data ini, tetapi memiliki entri untuk TTFB dan LCP, jadi ini merupakan permulaan. Kami berharap dapat menyertakan data yang digunakan untuk postingan ini di CrUX di masa mendatang, jadi nantikan berita lainnya tentang hal tersebut.
Untuk menguji sub-bagian LCP secara lokal, coba ekstensi Data Web atau cuplikan JavaScript di artikel ini. Lighthouse juga menyertakan pengelompokan dalam "elemen Largest Contentful Paint (LCP)" audit. Cari saran sub-bagian LCP selengkapnya di panel Performa DevTools, segera hadir.