Mengoptimalkan Largest Contentful Paint

Panduan langkah demi langkah tentang cara menguraikan LCP dan mengidentifikasi area utama yang perlu ditingkatkan.

Philip Walton

Barry Pollard

Dipublikasikan: 30 April 2020

Largest Contentful Paint (LCP) adalah salah satu dari tiga metrik Core Web Vitals, dan menunjukkan seberapa cepat konten utama halaman web dimuat. Secara khusus, LCP mengukur waktu dari saat pengguna memulai pemuatan halaman hingga gambar atau blok teks terbesar dirender dalam area pandang.

Untuk memberikan pengalaman pengguna yang baik, situs harus mengusahakan agar LCP-nya 2,5 detik atau kurang untuk setidaknya 75% kunjungan halaman.

Nilai LCP yang baik adalah 2,5 detik atau kurang.

Sejumlah faktor dapat memengaruhi kecepatan browser memuat dan merender halaman web, dan penundaan di salah satu faktor tersebut dapat berdampak signifikan pada LCP.

Perbaikan cepat pada satu bagian halaman jarang menghasilkan peningkatan yang signifikan pada LCP. Untuk meningkatkan LCP, Anda harus melihat keseluruhan proses pemuatan dan memastikan setiap langkah di sepanjang prosesnya sudah optimal.

Memahami metrik LCP Anda

Sebelum mengoptimalkan LCP, developer harus mencoba memahami apakah mereka memiliki masalah LCP, dan tingkat masalah tersebut.

LCP dapat diukur dengan sejumlah alat dan tidak semuanya mengukur LCP dengan cara yang sama. Untuk memahami LCP pengguna sebenarnya, kita harus melihat pengalaman pengguna sebenarnya, bukan yang ditampilkan oleh alat berbasis lab seperti Lighthouse atau pengujian lokal. Alat berbasis lab ini dapat memberikan banyak informasi untuk menjelaskan dan membantu Anda meningkatkan LCP, tetapi perlu diketahui bahwa pengujian lab saja mungkin tidak sepenuhnya mewakili pengalaman pengguna yang sebenarnya.

Data LCP berdasarkan pengguna sebenarnya dapat ditampilkan dari alat Real User Monitoring (RUM) yang diinstal di situs, atau dengan menggunakan Laporan Pengalaman Pengguna Chrome (CrUX) yang mengumpulkan data anonim dari pengguna Chrome sebenarnya untuk jutaan situs.

Menggunakan data LCP CrUX Chrome DevTools

Panel Performance Chrome DevTools menampilkan pengalaman LCP lokal Anda di samping LCP CrUX halaman atau origin di tampilan metrik langsung.

LCP lokal dan kolom di panel Performa Chrome DevTools.

Dengan menempatkan data kolom ke panel Performa, Anda dapat menilai apakah halaman memiliki masalah LCP pengguna sebenarnya dan menyesuaikan setelan lingkungan lokal untuk mereproduksi dan men-debug masalah tersebut dengan lebih baik.

Menggunakan data LCP CrUX PageSpeed Insights

PageSpeed Insights memberikan akses ke data CrUX di bagian atas yang berlabel Temukan pengalaman pengguna sebenarnya. Data berbasis lab yang lebih mendetail tersedia di bagian bawah yang berlabel Diagnosa masalah performa. Jika data CrUX tersedia untuk situs Anda, selalu berfokuslah pada data pengguna sebenarnya terlebih dahulu.

Data CrUX yang ditampilkan di PageSpeed Insights.

Catatan: Jika CrUX tidak menyediakan data (misalnya, halaman dengan traffic yang tidak memadai untuk mendapatkan data tingkat halaman), CrUX harus dilengkapi dengan data RUM yang dikumpulkan menggunakan JavaScript API yang berjalan di halaman web. Hal ini juga dapat memberikan lebih banyak data daripada yang dapat ditampilkan CrUX sebagai set data publik. Nanti dalam panduan ini, kami akan menjelaskan cara mengumpulkan data ini menggunakan JavaScript.

PageSpeed Insights menampilkan hingga empat data CrUX yang berbeda:

• Data seluler untuk URL Ini
• Data desktop untuk URL Ini
• Data Seluler untuk seluruh Asal
• Data desktop untuk seluruh Origin

Anda dapat mengubah tindakan ini pada kontrol di sisi atas dan kanan atas bagian ini. Jika URL tidak memiliki cukup data untuk ditampilkan di tingkat URL, tetapi memiliki data untuk origin, PageSpeed Insights akan selalu menampilkan data origin.

Jika tidak memiliki data tingkat URL, PageSpeed Insights akan menampilkan data tingkat origin.

LCP untuk seluruh origin mungkin sangat berbeda dengan LCP halaman individual, bergantung pada cara LCP dimuat di halaman tersebut dibandingkan dengan halaman lain di origin tersebut. Hal ini juga dapat dipengaruhi oleh bagaimana pengunjung menavigasi ke laman tersebut. Halaman beranda cenderung dikunjungi oleh pengguna baru sehingga sering kali dimuat "dingin", tanpa konten yang di-cache, sehingga sering kali menjadi halaman terlambat di situs.

Melihat empat kategori data CrUX yang berbeda dapat membantu Anda memahami apakah masalah LCP hanya untuk halaman ini, atau masalah yang lebih umum di seluruh situs. Demikian pula, laporan ini dapat menunjukkan jenis perangkat yang memiliki masalah LCP.

Menggunakan metrik tambahan CrUX PageSpeed Insights

Mereka yang ingin mengoptimalkan LCP juga harus menggunakan pengaturan waktu First Contentful Paint (FCP) dan Time to First Byte (TTFB), yang merupakan metrik diagnostik yang baik yang dapat memberikan insight berharga tentang LCP.

TTFB adalah waktu saat pengunjung mulai membuka halaman (misalnya, mengklik link), hingga byte pertama dokumen HTML diterima. TTFB yang tinggi dapat membuat pencapaian LCP 2,5 detik menjadi sulit, atau bahkan tidak mungkin.

TTFB yang tinggi dapat disebabkan oleh beberapa pengalihan server, pengunjung yang berada jauh dari server situs terdekat, pengunjung dengan kondisi jaringan yang buruk, atau ketidakmampuan untuk menggunakan konten yang di-cache karena parameter kueri.

Setelah halaman mulai dirender, mungkin ada gambar awal (misalnya, warna latar belakang), diikuti dengan beberapa konten yang muncul (misalnya, header situs). Tampilan konten awal diukur dengan FCP. Delta antara FCP dan metrik lainnya dapat sangat informatif.

Delta yang besar antara TTFB dan FCP dapat menunjukkan bahwa browser perlu mendownload banyak aset yang memblokir rendering. Hal ini juga bisa menjadi tanda bahwa situs harus menyelesaikan banyak upaya untuk merender konten yang bermakna—tanda klasik dari sebuah situs yang sangat bergantung pada rendering sisi klien.

Delta yang besar antara FCP dan LCP menunjukkan bahwa resource LCP tidak segera tersedia untuk diprioritaskan browser (misalnya, teks atau gambar yang dikelola oleh JavaScript dan bukan tersedia di HTML awal), atau bahwa browser sedang menyelesaikan pekerjaan lain sebelum dapat menampilkan konten LCP.

Menggunakan data Lighthouse PageSpeed Insights

Bagian Lighthouse di PageSpeed Insights menawarkan beberapa panduan untuk meningkatkan LCP, tetapi pertama-tama Anda harus memeriksa apakah LCP yang diberikan secara luas sesuai dengan data pengguna sebenarnya yang disediakan oleh CrUX. Jika Lighthouse dan CrUX tidak setuju, CrUX kemungkinan memberikan gambaran yang lebih akurat tentang pengalaman pengguna Anda. Pastikan data CrUX Anda adalah untuk halaman Anda, bukan asal lengkap, sebelum Anda menindaklanjutinya.

Jika Lighthouse dan CrUX menampilkan nilai LCP yang perlu ditingkatkan, bagian Lighthouse dapat memberikan panduan berharga tentang cara meningkatkan LCP. Gunakan filter LCP untuk hanya menampilkan audit yang relevan dengan LCP sebagai berikut:

Diagnostik dan saran Lighthouse untuk meningkatkan LCP.

Selain Peluang untuk meningkatkan kualitas, ada informasi Diagnostik yang dapat memberikan informasi lebih lanjut untuk membantu mendiagnosis masalah. Diagnostik elemen Largest Contentful Paint menunjukkan pengelompokan yang berguna dari berbagai pengaturan waktu yang membentuk LCP:

Pengelompokan elemen LCP Lighthouse.

Kita akan membahas subbagian ini selanjutnya.

Perincian LCP

Mengoptimalkan LCP dapat menjadi tugas yang lebih rumit jika PageSpeed Insights tidak memberi Anda jawaban tentang cara meningkatkan metrik ini. Untuk tugas yang kompleks, sebaiknya bagi tugas tersebut menjadi tugas yang lebih kecil dan lebih mudah dikelola, lalu tangani setiap tugas secara terpisah.

Bagian ini menyajikan metodologi tentang cara membagi LCP menjadi subbagian yang paling penting, lalu menyajikan rekomendasi dan praktik terbaik tertentu tentang cara mengoptimalkan setiap bagian.

Catatan: Untuk ringkasan visual tentang konteks yang disajikan dalam panduan ini, lihat Pendalaman tentang Mengoptimalkan LCP dari Google I/O '22:

Sebagian besar pemuatan halaman biasanya menyertakan sejumlah permintaan jaringan, tetapi untuk mengidentifikasi peluang guna meningkatkan LCP, Anda harus mulai dengan melihat hanya dua permintaan:

1. Dokumen HTML awal
2. Resource LCP (jika ada)

Meskipun permintaan lain di halaman dapat memengaruhi LCP, dua permintaan ini—khususnya saat resource LCP dimulai dan berakhir—menunjukkan apakah halaman Anda dioptimalkan untuk LCP atau tidak.

Untuk mengidentifikasi resource LCP, Anda dapat menggunakan alat developer (seperti PageSpeed Insights yang telah dibahas sebelumnya, Chrome DevTools, atau WebPageTest) untuk menentukan elemen LCP. Dari sana, Anda dapat mencocokkan URL (sekali lagi, jika berlaku) yang dimuat oleh elemen di Waterfall jaringan semua resource yang dimuat oleh halaman.

Misalnya, visualisasi berikut menunjukkan referensi yang ditandai pada diagram waterfall jaringan dari pemuatan halaman biasa, tempat elemen LCP memerlukan permintaan gambar untuk dirender.

Diagram waterfall yang menunjukkan waktu pemuatan untuk HTML halaman web dan resource yang diperlukan LCP.

Untuk halaman yang dioptimalkan dengan baik, Anda ingin permintaan resource LCP mulai dimuat sedini mungkin, dan ingin elemen LCP dirender secepat mungkin setelah resource LCP selesai dimuat. Untuk membantu memvisualisasikan apakah halaman tertentu mengikuti prinsip ini atau tidak, Anda dapat mengelompokkan total waktu LCP menjadi sub-bagian berikut:

Time to First Byte (TTFB)

Waktu dari saat pengguna memulai pemuatan 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 (misalnya, jika elemen adalah node teks yang dirender dengan font sistem), waktu ini adalah 0.

Durasi pemuatan resource

Durasi waktu yang diperlukan untuk memuat resource LCP itu sendiri. Jika elemen LCP tidak memerlukan pemuatan resource untuk dirender, waktu ini adalah 0.

Penundaan render elemen

Waktu antara saat resource LCP selesai dimuat dan elemen LCP dirender sepenuhnya.

LCP setiap halaman terdiri dari empat subkategori ini. Tidak ada celah atau tumpang-tindih di antara keduanya, dan keduanya akan ditambahkan ke waktu LCP penuh.

Diagram waterfall yang sama, dengan empat subkategori LCP yang ditempatkan di linimasa.

Setiap halaman dapat memiliki nilai LCP yang dipecah menjadi empat subbagian ini. Tidak ada tumpang-tindih atau celah di antara keduanya. Secara kolektif, waktu tersebut akan ditambahkan ke waktu LCP penuh.

Saat mengoptimalkan LCP, sebaiknya coba optimalkan sub-bagian ini satu per satu. Tetapi penting juga untuk diingat bahwa Anda perlu mengoptimalkan semuanya. Dalam beberapa kasus, pengoptimalan yang diterapkan ke satu bagian tidak akan meningkatkan LCP, tetapi hanya akan memindahkan waktu yang dihemat ke bagian lain.

Misalnya, pada waterfall jaringan sebelumnya, jika Anda mengurangi ukuran file gambar dengan mengompresinya lebih banyak atau beralih ke format yang lebih optimal (seperti AVIF atau WebP), hal itu akan mengurangi durasi pemuatan resource, tetapi sebenarnya tidak akan meningkatkan LCP karena waktu hanya akan bergeser ke sub-bagian penundaan render elemen:

Dengan mempersingkat durasi pemuatan resource, penundaan rendering elemen akan meningkat tanpa mengurangi LCP.

Alasan hal ini terjadi adalah karena, di halaman ini, elemen LCP disembunyikan hingga kode JavaScript selesai dimuat, lalu semuanya ditampilkan sekaligus.

Contoh ini membantu mengilustrasikan bahwa Anda perlu mengoptimalkan semua sub-bagian ini untuk mencapai hasil LCP terbaik.

Waktu sub-bagian yang optimal

Untuk mengoptimalkan setiap subbagian LCP, Anda harus memahami perincian ideal subbagian ini di halaman yang dioptimalkan dengan baik.

Dari empat subbagian, dua memiliki kata "delay" dalam namanya. Itu adalah petunjuk bahwa Anda ingin mendapatkan waktu yang sedekat mungkin dengan nol. Dua bagian lainnya melibatkan permintaan jaringan, yang pada dasarnya memerlukan waktu.

Sub-bagian LCP	% LCP
Time to first byte	~40%
Penundaan pemuatan resource	<10%
Durasi pemuatan resource	~40%
Penundaan render elemen	<10%
TOTAL	100%

Perhatikan bahwa pengelompokan waktu ini adalah pedoman, bukan aturan yang ketat. Jika waktu LCP di halaman Anda konsisten dalam 2,5 detik, tidak terlalu penting berapa proporsi relatifnya. Namun, jika Anda menghabiskan banyak waktu yang tidak perlu di salah satu bagian "penundaan", akan sangat sulit untuk terus mencapai target 2,5 detik.

Cara yang baik untuk memikirkan perincian waktu LCP adalah:

• Sebagian besar waktu LCP harus digunakan untuk memuat dokumen HTML dan sumber LCP.
• Setiap kali sebelum LCP, jika salah satu dari dua resource ini tidak dimuat, berarti ada peluang untuk meningkatkan performa.

Peringatan: Mengingat target 2,5 detik untuk LCP, Anda mungkin tergoda untuk mencoba mengonversi persentase ini menjadi angka absolut, tetapi hal ini tidak direkomendasikan. Sub-bagian ini hanya bermakna relatif terhadap satu sama lain, jadi sebaiknya selalu ukur dengan cara tersebut.

Cara mengoptimalkan setiap bagian

Setelah memahami bagaimana setiap waktu sub-bagian LCP seharusnya dikelompokkan pada halaman yang dioptimalkan dengan baik, Anda dapat mulai mengoptimalkan halaman Anda sendiri.

Empat bagian berikutnya akan menyajikan rekomendasi dan praktik terbaik tentang cara mengoptimalkan setiap bagian. Laporan tersebut disajikan secara berurutan, dimulai dengan pengoptimalan yang kemungkinan akan memberikan dampak terbesar.

1. Menghilangkan penundaan pemuatan resource

Sasaran dalam langkah ini adalah memastikan resource LCP mulai dimuat sedini mungkin. Meskipun secara teori, waktu paling awal resource dapat mulai dimuat adalah segera setelah TTFB, dalam praktiknya selalu ada beberapa penundaan sebelum browser benar-benar mulai memuat resource.

Aturan praktis yang baik adalah resource LCP Anda harus mulai dimuat pada saat yang sama dengan resource pertama yang dimuat oleh halaman tersebut. Atau, dengan kata lain, jika resource LCP mulai dimuat lebih lambat dari resource pertama, berarti ada peluang untuk peningkatan.

Di halaman ini, resource LCP mulai dimuat dengan baik setelah sheet gaya yang dimuat terlebih dahulu. Ada ruang untuk peningkatan di sini.

Secara umum, ada dua faktor yang memengaruhi seberapa cepat resource LCP dapat dimuat:

• Saat resource ditemukan.
• Prioritas yang diberikan ke resource.

Mengoptimalkan saat resource ditemukan

Untuk memastikan resource LCP mulai dimuat sedini mungkin, resource tersebut harus dapat ditemukan dalam respons dokumen HTML awal oleh pemindai pramuat browser. Misalnya, dalam kasus berikut, browser dapat menemukan resource LCP dengan memindai respons dokumen HTML:

• Elemen LCP adalah elemen <img>, dan atribut src atau srcset-nya ada dalam markup HTML awal.
• Elemen LCP memerlukan gambar latar CSS, tetapi gambar tersebut dipramuat menggunakan <link rel="preload"> dalam markup HTML (atau menggunakan header Link).
• Elemen LCP adalah node teks yang memerlukan font web untuk dirender, dan font dimuat menggunakan <link rel="preload"> dalam markup HTML (atau menggunakan header Link).

Berikut beberapa contoh saat resource LCP tidak dapat ditemukan dari pemindaian respons dokumen HTML:

• Elemen LCP adalah <img> yang ditambahkan secara dinamis ke halaman menggunakan JavaScript.
• Elemen LCP dimuat secara lambat dengan library JavaScript yang menyembunyikan atribut src atau srcset-nya (sering kali sebagai data-src atau data-srcset).
• Elemen LCP memerlukan gambar latar CSS.

Dalam setiap kasus ini, browser perlu menjalankan skrip atau menerapkan stylesheet—yang biasanya melibatkan menunggu permintaan jaringan selesai—sebelum dapat menemukan resource LCP dan mulai memuatnya. Hal ini tidak pernah optimal.

Untuk menghilangkan penundaan pemuatan resource yang tidak perlu, resource LCP Anda harus dapat ditemukan dari sumber HTML. Jika resource hanya dirujuk dari file CSS atau JavaScript eksternal, resource LCP harus dipramuat dengan prioritas pengambilan yang tinggi, misalnya:

<!-- Load the stylesheet that will reference the LCP image. -->
<link rel="stylesheet" href="/path/to/styles.css">

<!-- Preload the LCP image with a high fetchpriority so it starts loading with the stylesheet. -->
<link rel="preload" fetchpriority="high" as="image" href="/path/to/hero-image.webp" type="image/webp">

Peringatan: Di sebagian besar halaman, memastikan bahwa resource LCP mulai dimuat bersamaan dengan resource pertama sudah cukup baik, tetapi perlu diketahui bahwa Anda dapat membuat halaman yang tidak memiliki resource yang ditemukan lebih awal dan semuanya mulai dimuat jauh lebih lambat dari TTFB. Jadi, meskipun membandingkan dengan referensi pertama adalah cara yang baik untuk mengidentifikasi peluang peningkatan, dalam beberapa kasus hal ini mungkin tidak memadai, jadi pengukuran waktu ini masih penting dibandingkan dengan TTFB dan pastikan penggunaannya tetap kecil.

Mengoptimalkan prioritas yang diberikan resource

Meskipun resource LCP dapat ditemukan dari markup HTML, resource tersebut masih mungkin tidak mulai dimuat seawal resource pertama. Hal ini dapat terjadi jika heuristik prioritas pemindai pramuat browser tidak mengenali bahwa resource tersebut penting, atau jika menentukan bahwa resource lain lebih penting.

Misalnya, Anda dapat menunda gambar LCP menggunakan HTML jika menetapkan loading="lazy" pada elemen <img>. Menggunakan pemuatan lambat berarti resource tidak akan dimuat hingga setelah tata letak mengonfirmasi bahwa gambar berada di area pandang sehingga dapat mulai dimuat lebih lambat dari biasanya.

Peringatan: Jangan pernah melakukan pemuatan lambat pada gambar LCP, karena hal itu akan selalu menyebabkan penundaan pemuatan resource yang tidak perlu, dan akan berdampak negatif pada LCP.

Bahkan tanpa pemuatan lambat, gambar awalnya tidak dimuat dengan prioritas tertinggi oleh browser karena bukan merupakan resource pemblokir render. Anda dapat memberi petunjuk kepada browser tentang resource mana yang paling penting menggunakan atribut fetchpriority untuk resource yang dapat memanfaatkan prioritas yang lebih tinggi:

<img fetchpriority="high" src="/path/to/hero-image.webp">

Sebaiknya setel fetchpriority="high" pada elemen <img> jika menurut Anda elemen tersebut kemungkinan adalah elemen LCP halaman Anda. Namun, menetapkan prioritas tinggi pada lebih dari satu atau dua gambar akan membuat setelan prioritas tidak membantu dalam mengurangi LCP.

Anda juga dapat menurunkan prioritas gambar yang mungkin berada di awal respons dokumen, tetapi tidak terlihat karena gaya visual, seperti gambar di slide carousel yang tidak terlihat saat startup:

<img fetchpriority="low" src="/path/to/carousel-slide-3.webp">

Tidak memprioritaskan resource tertentu dapat menghasilkan lebih banyak bandwidth untuk resource yang lebih membutuhkannya—tetapi berhati-hatilah. Selalu periksa prioritas resource di DevTools dan uji perubahan dengan alat lab dan lapangan.

Setelah Anda mengoptimalkan prioritas dan waktu penemuan resource LCP, waterfall jaringan akan terlihat seperti ini (dengan resource LCP dimulai pada waktu yang sama dengan resource pertama):

Resource LCP kini mulai dimuat bersamaan dengan stylesheet.

Poin penting: Alasan lain resource LCP Anda mungkin tidak mulai dimuat seawal mungkin—meskipun dapat ditemukan dari sumber HTML—adalah jika dihosting di origin yang berbeda, karena permintaan ini mengharuskan browser terhubung ke origin tersebut sebelum resource dapat mulai dimuat. Jika memungkinkan, sebaiknya host resource penting di origin yang sama dengan resource dokumen HTML Anda karena resource tersebut dapat menghemat waktu dengan menggunakan kembali koneksi yang ada (selengkapnya tentang hal ini nanti).

2. Menghilangkan penundaan render elemen

Sasaran pada langkah ini adalah untuk memastikan elemen LCP dapat segera dirender setelah resource-nya selesai dimuat, kapan pun itu terjadi.

Alasan utama elemen LCP tidak dapat langsung dirender setelah resource-nya selesai dimuat adalah jika rendering diblokir karena alasan lain:

• Rendering seluruh halaman diblokir karena stylesheet atau skrip sinkron di <head> yang masih dimuat.
• Resource LCP telah selesai dimuat, tetapi elemen LCP belum ditambahkan ke DOM (elemen tersebut menunggu beberapa kode JavaScript dimuat).
• Elemen disembunyikan oleh beberapa kode lain, seperti library pengujian A/B yang masih menentukan eksperimen yang harus diikuti pengguna.
• Thread utama diblokir karena tugas yang lama, dan pekerjaan rendering harus menunggu hingga tugas yang lama tersebut selesai.

Bagian berikut menjelaskan cara mengatasi penyebab paling umum dari penundaan rendering elemen yang tidak perlu.

Mengurangi atau menjadikan stylesheet yang memblokir perenderan inline

Style sheet yang dimuat dari markup HTML akan memblokir rendering semua konten yang mengikutinya, yang merupakan hal yang baik, karena Anda biasanya tidak ingin merender HTML tanpa gaya. Namun, jika lembar gaya begitu besar sehingga membutuhkan waktu yang jauh lebih lama untuk dimuat daripada resource LCP, maka hal ini akan mencegah elemen LCP dirender—bahkan setelah resource-nya selesai dimuat, seperti yang ditunjukkan dalam contoh berikut:

Gambar dan sheet gaya mulai dimuat secara bersamaan, tetapi gambar tidak dapat dirender hingga sheet gaya siap.

Untuk memperbaikinya, Anda dapat:

• menyisipkan lembar gaya ke dalam HTML untuk menghindari permintaan jaringan tambahan; atau,
• mengurangi ukuran sheet gaya.

Secara umum, menyisipkan sheet gaya hanya direkomendasikan jika sheet gaya Anda berukuran kecil karena konten yang disisipkan dalam HTML tidak dapat memanfaatkan penyimpanan dalam cache saat halaman dimuat berikutnya. Jika ukuran sheet gaya sangat besar sehingga memerlukan waktu lebih lama untuk dimuat daripada resource LCP, sheet gaya tersebut kemungkinan bukan kandidat yang baik untuk inline.

Dalam sebagian besar kasus, cara terbaik untuk memastikan style sheet tidak memblokir rendering elemen LCP adalah dengan mengurangi ukurannya sehingga lebih kecil dari resource LCP. Hal ini akan memastikan bahwa proses ini tidak menjadi bottleneck untuk sebagian besar kunjungan.

Beberapa rekomendasi untuk mengurangi ukuran sheet gaya adalah:

• Menghapus CSS yang tidak digunakan: gunakan Chrome DevTools untuk menemukan aturan CSS yang tidak digunakan dan berpotensi dapat dihapus (atau ditangguhkan).
• Tunda CSS yang tidak penting: bagi style sheet Anda menjadi beberapa gaya yang diperlukan untuk pemuatan halaman awal, lalu gaya yang dapat dimuat dengan lambat.
• Perkecil dan kompresi CSS: untuk gaya yang sangat penting, pastikan Anda mengurangi ukuran transfer sebanyak mungkin.

Menunda atau menyisipkan JavaScript pemblokir render

Menambahkan skrip sinkron (skrip tanpa atribut async atau defer) ke <head> halaman Anda hampir tidak perlu lagi, dan tindakan ini hampir selalu berdampak negatif pada performa.

Jika kode JavaScript perlu dijalankan seawal mungkin saat halaman dimuat, sebaiknya gabungkan kode tersebut agar rendering tidak tertunda menunggu permintaan jaringan lain. Namun, seperti halnya stylesheet, Anda hanya boleh menyisipkan skrip jika skrip tersebut sangat kecil.

Larangan

<head>
  <script src="/path/to/main.js"></script>
</head>

Anjuran

<head>
  <script>
    // Inline script contents directly in the HTML.
    // IMPORTANT: only do this for very small scripts.
  </script>
</head>

Menggunakan rendering sisi server

Rendering sisi server (SSR) adalah proses menjalankan logika aplikasi sisi klien di server dan merespons permintaan dokumen HTML dengan markup HTML lengkap.

Dari perspektif pengoptimalan LCP, ada dua keuntungan utama SSR:

• Resource gambar Anda akan dapat ditemukan dari sumber HTML (seperti yang telah dibahas di langkah 1 sebelumnya).
• Konten halaman Anda tidak akan memerlukan permintaan JavaScript tambahan untuk selesai sebelum dapat dirender.

Kelemahan utama SSR adalah memerlukan waktu pemrosesan server tambahan, yang dapat memperlambat TTFB Anda. Namun, kompromi ini biasanya sepadan karena waktu pemrosesan server berada dalam kendali Anda, sedangkan kemampuan jaringan dan perangkat pengguna tidak.

Opsi yang serupa dengan SSR disebut pembuatan situs statis (SSG) atau pra-rendering. Ini adalah proses pembuatan halaman HTML dalam langkah build, bukan on demand. Jika pra-rendering dapat dilakukan dengan arsitektur Anda, biasanya ini adalah pilihan yang lebih baik untuk performa.

Membagi tugas yang panjang

Meskipun Anda telah mengikuti saran sebelumnya, dan kode JavaScript Anda tidak memblokir rendering atau bertanggung jawab untuk merender elemen, kode tersebut tetap dapat menunda LCP.

Alasan paling umum hal ini terjadi adalah saat halaman memuat file JavaScript berukuran besar, yang perlu diurai dan dieksekusi di thread utama browser. Artinya, meskipun resource gambar Anda didownload sepenuhnya, resource tersebut mungkin masih harus menunggu hingga skrip yang tidak terkait selesai dieksekusi sebelum dapat dirender.

Semua browser saat ini merender gambar di thread utama, yang berarti apa pun yang memblokir thread utama juga dapat menyebabkan penundaan rendering elemen yang tidak perlu.

3. Mengurangi durasi pemuatan resource

Tujuan langkah ini adalah untuk mengurangi waktu yang dihabiskan untuk mentransfer byte resource melalui jaringan ke perangkat pengguna. Secara umum, ada empat cara untuk melakukannya:

• Kurangi ukuran resource.
• Kurangi jarak yang harus ditempuh sumber daya.
• Mengurangi pertentangan untuk bandwidth jaringan.
• Menghilangkan waktu jaringan sepenuhnya.

Peringatan: Penelitian kami menunjukkan bahwa bagian durasi pemuatan LCP cenderung tidak menjadi bottleneck yang signifikan bagi sebagian besar situs. Jika memungkinkan, lihat data pengguna sebenarnya di situs Anda untuk membantu menentukan subbagian LCP yang akan menjadi fokus upaya Anda.

Mengurangi ukuran resource

Resource LCP halaman (jika ada) akan berupa gambar atau font web. Panduan berikut menjelaskan secara mendetail cara mengurangi ukuran keduanya:

• Menayangkan ukuran gambar yang optimal
• Menggunakan format gambar modern
• Mengompresi gambar
• Mengurangi ukuran font web

Mengurangi jarak yang harus ditempuh sumber daya

Selain mengurangi ukuran resource, Anda juga dapat mengurangi waktu pemuatan dengan menempatkan server sedekat mungkin dengan pengguna secara geografis. Dan cara terbaik untuk melakukannya adalah dengan menggunakan jaringan penayangan konten (CDN).

CDN Gambar khususnya sangat membantu karena tidak hanya mengurangi jarak yang harus ditempuh resource, tetapi juga umumnya mengurangi ukuran resource—secara otomatis menerapkan semua rekomendasi pengurangan ukuran dari sebelumnya untuk Anda.

Poin penting: Meskipun CDN gambar adalah cara yang bagus untuk mengurangi durasi pemuatan resource, penggunaan domain pihak ketiga untuk menghosting gambar akan menimbulkan biaya koneksi tambahan. Meskipun prakoneksi ke origin dapat mengurangi sebagian biaya ini, opsi terbaiknya adalah menayangkan gambar dari origin yang sama dengan dokumen HTML Anda. Banyak CDN memungkinkan Anda melakukan proxy permintaan dari origin Anda ke origin mereka, yang merupakan opsi bagus untuk dipertimbangkan jika tersedia.

Mengurangi pertentangan untuk bandwidth jaringan

Meskipun Anda telah mengurangi ukuran resource dan jarak yang harus dilaluinya, resource masih dapat memerlukan waktu lama untuk dimuat jika Anda memuat banyak resource lain secara bersamaan. Masalah ini dikenal sebagai persaingan jaringan.

Jika Anda telah memberikan fetchpriority tinggi ke resource LCP dan mulai memuat resource tersebut sesegera mungkin, browser akan melakukan yang terbaik untuk mencegah resource prioritas lebih rendah bersaing dengannya. Namun, jika Anda memuat banyak resource dengan fetchpriority tinggi, atau jika Anda hanya memuat banyak resource secara umum, hal ini dapat memengaruhi kecepatan pemuatan resource LCP.

Menghapus waktu jaringan sepenuhnya

Cara terbaik untuk mengurangi durasi pemuatan resource adalah dengan menghapus jaringan sepenuhnya dari proses. Jika Anda menayangkan resource dengan kebijakan kontrol cache yang efisien, pengunjung yang meminta resource tersebut untuk kedua kalinya akan menayangkannya dari cache—sehingga durasi pemuatan resource menjadi nol.

Jika resource LCP Anda adalah font web, selain mengurangi ukuran font web, Anda juga harus mempertimbangkan apakah perlu memblokir rendering pada pemuatan resource font web. Jika Anda menetapkan nilai font-display dari apa pun selain auto atau block, teks akan selalu terlihat selama pemuatan, dan LCP tidak akan diblokir pada permintaan jaringan tambahan.

Terakhir, jika resource LCP Anda kecil, mungkin masuk akal untuk menjadikan resource inline sebagai URL data, yang juga akan mengeliminasi permintaan jaringan tambahan. Namun, penggunaan URL data memiliki batasan karena resource tidak dapat di-cache dan dalam beberapa kasus dapat menyebabkan penundaan render yang lebih lama karena biaya dekode tambahan.

4. Mengurangi waktu ke byte pertama

Tujuan dari langkah ini adalah mengirimkan HTML awal secepat mungkin. Langkah ini dicantumkan terakhir karena sering kali merupakan langkah yang paling sedikit dikontrol oleh developer. Namun, ini juga merupakan salah satu langkah paling penting karena secara langsung memengaruhi setiap langkah berikutnya. Tidak ada yang dapat terjadi di frontend hingga backend mengirimkan byte konten pertama tersebut, sehingga apa pun yang dapat Anda lakukan untuk mempercepat TTFB juga akan meningkatkan setiap metrik pemuatan lainnya.

Penyebab umum TTFB lambat untuk situs yang seharusnya cepat adalah pengunjung yang datang melalui beberapa pengalihan, seperti dari iklan atau link singkat. Selalu minimalkan jumlah pengalihan yang harus ditunggu pengunjung.

Penyebab umum lainnya adalah saat konten dalam cache tidak dapat digunakan dari server edge CDN, dan semua permintaan harus diarahkan kembali ke server origin. Hal ini dapat terjadi jika parameter URL unik digunakan oleh pengunjung untuk analisis—meskipun parameter tersebut tidak menghasilkan halaman yang berbeda.

Untuk panduan spesifik tentang cara mengoptimalkan TTFB, lihat panduan mengoptimalkan TTFB.

Memantau pengelompokan LCP di JavaScript

Informasi pengaturan waktu untuk semua subbagian LCP yang telah dibahas sebelumnya tersedia untuk Anda dalam JavaScript melalui kombinasi API performa berikut:

• Largest Contentful Paint API
• Navigation Timing API
• Resource Timing API

Manfaat menghitung nilai pengaturan waktu ini di JavaScript adalah Anda dapat mengirimkannya ke penyedia analisis atau mencatatnya ke alat developer untuk membantu proses debug dan pengoptimalan.

Misalnya, screenshot berikut menggunakan metode performance.measure() dari User Timing API untuk menambahkan batang ke jalur Timings di panel Performance Chrome DevTools.

Jalur Waktu menampilkan linimasa untuk subkategori LCP.

Visualisasi di jalur Waktu sangat membantu jika dilihat bersama jalur Jaringan dan Rangkaian pesan utama, karena Anda dapat melihat sekilas hal lain yang terjadi di halaman selama rentang waktu ini.

Selain memvisualisasikan sub-bagian LCP dalam pelacakan pengaturan waktu, Anda juga dapat menggunakan JavaScript untuk menghitung berapa persentase setiap sub-bagian dari total waktu LCP. Dengan informasi tersebut, Anda dapat menentukan apakah halaman Anda memenuhi perincian persentase yang direkomendasikan yang dijelaskan sebelumnya.

Screenshot ini menunjukkan contoh yang mencatat log total waktu setiap subbagian LCP, serta persentasenya dari total waktu LCP ke konsol.

Waktu dan persentase subkategori LCP.

Kedua visualisasi ini dibuat dengan kode berikut:

const LCP_SUB_PARTS = [
  'Time to first byte',
  'Resource load delay',
  'Resource load duration',
  'Element render delay',
];

new PerformanceObserver((list) => {
  const lcpEntry = list.getEntries().at(-1);
  const navEntry = performance.getEntriesByType('navigation')[0];
  const lcpResEntry = performance
    .getEntriesByType('resource')
    .filter((e) => e.name === lcpEntry.url)[0];

  // Ignore LCP entries that aren't images to reduce DevTools noise.
  // Comment this line out if you want to include text entries.
  if (!lcpEntry.url) return;

  // Compute the start and end times of each LCP sub-part.
  // WARNING! If your LCP resource is loaded cross-origin, make sure to add
  // the `Timing-Allow-Origin` (TAO) header to get the most accurate results.
  const ttfb = navEntry.responseStart;
  const lcpRequestStart = Math.max(
    ttfb,
    // Prefer `requestStart` (if TOA is set), otherwise use `startTime`.
    lcpResEntry ? lcpResEntry.requestStart || lcpResEntry.startTime : 0
  );
  const lcpResponseEnd = Math.max(
    lcpRequestStart,
    lcpResEntry ? lcpResEntry.responseEnd : 0
  );
  const lcpRenderTime = Math.max(
    lcpResponseEnd,
    // Use LCP startTime (the final LCP time) because there are sometimes
    // slight differences between loadTime/renderTime and startTime
    // due to rounding precision.
    lcpEntry ? lcpEntry.startTime : 0
  );

  // Clear previous measures before making new ones.
  // Note: due to a bug, this doesn't work in Chrome DevTools.
  LCP_SUB_PARTS.forEach((part) => performance.clearMeasures(part));

  // Create measures for each LCP sub-part for easier
  // visualization in the Chrome DevTools Performance panel.
  const lcpSubPartMeasures = [
    performance.measure(LCP_SUB_PARTS[0], {
      start: 0,
      end: ttfb,
    }),
    performance.measure(LCP_SUB_PARTS[1], {
      start: ttfb,
      end: lcpRequestStart,
    }),
    performance.measure(LCP_SUB_PARTS[2], {
      start: lcpRequestStart,
      end: lcpResponseEnd,
    }),
    performance.measure(LCP_SUB_PARTS[3], {
      start: lcpResponseEnd,
      end: lcpRenderTime,
    }),
  ];

  // Log helpful debug information to the console.
  console.log('LCP value: ', lcpRenderTime);
  console.log('LCP element: ', lcpEntry.element, lcpEntry.url);
  console.table(
    lcpSubPartMeasures.map((measure) => ({
      'LCP sub-part': measure.name,
      'Time (ms)': measure.duration,
      '% of LCP': `${
        Math.round((1000 * measure.duration) / lcpRenderTime) / 10
      }%`,
    }))
  );
}).observe({type: 'largest-contentful-paint', buffered: true});

Anda dapat menggunakan kode ini sebagaimana adanya untuk proses debug lokal, atau mengubahnya untuk mengirimkan data ini ke penyedia analisis, sehingga Anda dapat lebih memahami perincian LCP apa yang ada di halaman Anda untuk pengguna sebenarnya.

Catatan: Kode sebelumnya berfungsi untuk navigasi standar, tetapi pertimbangan tambahan harus dilakukan untuk halaman yang diprarender, yang harus diukur dari waktu mulai aktivasi, tetapi telah dihapus dari kode ini untuk memudahkan.

Library web-vitals menyertakan pengelompokan ini dalam build atribusi, dan menyertakan pertimbangan ini.

Bagi yang ingin menerapkan solusi mereka sendiri, kode untuk ini adalah open source dan mirip dengan JavaScript ini, tetapi dengan logika tambahan untuk memulai aktivasi.

Ringkasan

LCP bersifat kompleks, dan waktunya dapat dipengaruhi oleh sejumlah faktor. Namun, jika Anda mempertimbangkan bahwa mengoptimalkan LCP terutama berkaitan dengan mengoptimalkan pemuatan resource LCP, hal ini dapat menyederhanakan prosesnya secara signifikan.

Pada dasarnya, pengoptimalan LCP dapat diringkas dalam empat langkah:

1. Pastikan resource LCP mulai dimuat sedini mungkin.
2. Pastikan elemen LCP dapat dirender segera setelah resource-nya selesai dimuat.
3. Kurangi waktu pemuatan resource LCP sebanyak mungkin tanpa mengorbankan kualitas.
4. Kirim dokumen HTML awal secepat mungkin.

Jika Anda dapat mengikuti langkah-langkah ini di halaman, Anda akan merasa yakin bahwa Anda memberikan pengalaman pemuatan yang optimal kepada pengguna, dan Anda akan melihat hal itu tercermin dalam skor LCP di dunia nyata.