Mengoptimalkan Largest Contentful Paint

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

Philip Walton

Barry Pollard

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

Untuk memberikan pengalaman pengguna yang baik, situs harus berupaya memiliki LCP sebesar 2,5 detik atau kurang untuk setidaknya 75% kunjungan halaman.

Sejumlah faktor dapat memengaruhi seberapa cepat browser dapat memuat dan merender halaman web, dan penundaan di dalamnya dapat memiliki dampak yang signifikan pada LCP.

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

Memahami metrik LCP

Sebelum mengoptimalkan LCP, developer sebaiknya berusaha memahami apakah mereka memiliki masalah LCP, dan seberapa besar masalah tersebut.

LCP dapat diukur menggunakan sejumlah alat dan tidak semua LCP diukur dengan cara yang sama. Untuk memahami LCP pengguna nyata, kita harus melihat apa yang dialami pengguna sebenarnya, bukan apa yang ditunjukkan 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 apa yang sebenarnya dialami pengguna Anda.

Data LCP berdasarkan pengguna nyata 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 sungguhan untuk jutaan situs.

Menggunakan data LCP CrUX PageSpeed Insights

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

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 bisa mengganti ini di kontrol di sisi kanan atas dan kanan atas bagian ini. Jika URL tidak memiliki cukup data untuk ditampilkan di tingkat URL, tetapi memiliki data untuk origin, PageSpeed Insights selalu menampilkan data origin.

LCP untuk seluruh origin mungkin sangat berbeda dengan LCP setiap halaman, bergantung pada cara LCP dimuat di halaman tersebut, dibandingkan dengan halaman lain di origin tersebut. Hal ini juga dapat dipengaruhi oleh cara pengunjung membuka halaman tersebut. Halaman beranda cenderung dikunjungi oleh pengguna baru dan sering kali dimuat secara "dingin", tanpa konten yang disimpan dalam cache, dan sering kali merupakan halaman paling lambat di situs.

Melihat keempat kategori data CrUX yang berbeda dapat membantu Anda memahami apakah masalah LCP khusus untuk halaman ini, atau masalah yang lebih umum di seluruh situs. Demikian pula, laporan ini dapat menunjukkan jenis perangkat mana 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 bagus 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 dilakukan.

TTFB yang tinggi dapat disebabkan oleh beberapa pengalihan server, pengunjung yang jauh dari server situs terdekat, pengunjung dengan kondisi jaringan yang buruk, atau tidak dapat menggunakan konten dalam cache karena parameter kueri.

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

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

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

Menggunakan data PageSpeed Insights Lighthouse

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

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

Selain Peluang yang perlu ditingkatkan, terdapat informasi Diagnostik yang dapat memberikan lebih banyak informasi untuk membantu mendiagnosis masalah. Diagnostik Largest Contentful Paint element menunjukkan perincian yang berguna dari berbagai pengaturan waktu yang membentuk LCP:

Kita akan mendalami sub-bagian ini.

Perincian LCP

Mengoptimalkan LCP dapat menjadi tugas yang lebih rumit jika PageSpeed Insights tidak memberikan jawaban tentang cara meningkatkan metrik ini. Dengan tugas yang kompleks, sebaiknya bagi tugas tersebut menjadi tugas-tugas yang lebih kecil dan lebih mudah dikelola serta atasi masing-masing tugas secara terpisah.

Bagian ini menyajikan metodologi tentang cara membagi LCP ke dalam sub-bagian yang paling penting, kemudian menyajikan rekomendasi dan praktik terbaik khusus untuk mengoptimalkan setiap bagian.

Sebagian besar pemuatan halaman biasanya mencakup sejumlah permintaan jaringan, tetapi untuk tujuan mengidentifikasi peluang meningkatkan LCP, sebaiknya mulai dengan melihat dua hal berikut:

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

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

Untuk mengidentifikasi resource LCP, Anda dapat menggunakan alat developer (seperti PageSpeed Insights yang dibahas di atas, 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 dari semua resource yang dimuat oleh halaman tersebut.

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

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

Time to First Byte (TTFB)

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

Durasi pemuatan resource

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

Penundaan render elemen

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

LCP setiap halaman terdiri dari empat subkategori ini. Tidak ada jeda atau tumpang tindih di antara keduanya, dan semuanya akan menghabiskan waktu LCP penuh.

Setiap halaman dapat memiliki nilai LCP yang dipecah menjadi empat sub-bagian ini. Tidak ada tumpang tindih atau kesenjangan di antara keduanya. Secara kolektif, waktu LCP bertambah secara penuh.

Saat mengoptimalkan LCP, sebaiknya coba optimalkan sub-bagian ini satu per satu. Namun, 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 mengubah waktu yang disimpan ke bagian lain.

Misalnya, dalam 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 tidak benar-benar meningkatkan LCP karena waktunya akan bergeser ke sub-bagian penundaan render elemen:

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 poin-poin penting bahwa Anda perlu mengoptimalkan semua sub-bagian ini untuk mencapai hasil LCP yang terbaik.

Waktu sub-bagian yang optimal

Untuk mengoptimalkan setiap sub-bagian LCP, penting untuk memahami bagaimana perincian ideal dari sub-bagian ini di halaman yang dioptimalkan dengan baik.

Dari empat sub-bagian, dua di antaranya memiliki kata "keterlambatan" dalam namanya. Itu adalah petunjuk bahwa Anda ingin mendapatkan waktu yang sedekat mungkin dengan nol. Dua bagian lainnya melibatkan permintaan jaringan, yang pada dasarnya membutuhkan waktu.

Perhatikan bahwa perincian waktu ini adalah pedoman, bukan aturan yang ketat. Jika waktu LCP di halaman Anda konsisten dalam waktu 2,5 detik, berapa proporsi relatifnya tidak terlalu penting. 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 memahami perincian waktu LCP adalah:

• Sebagian besar waktu LCP akan dihabiskan untuk memuat dokumen HTML dan sumber LCP.
• Setiap kali sebelum LCP, ketika salah satu dari dua resource ini tidak dimuat adalah peluang untuk melakukan peningkatan.

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. Mereka disajikan secara berurutan, dimulai dari pengoptimalan yang berpotensi memberikan dampak terbesar.

1. Menghilangkan penundaan pemuatan resource

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

Salah satu aturan praktisnya adalah resource LCP Anda akan 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, maka ada peluang untuk peningkatan.

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

• Saat resource ditemukan.
• Prioritas yang diberikan resource.

Mengoptimalkan saat resource ditemukan

Untuk memastikan resource LCP Anda mulai dimuat sedini mungkin, pastikan resource tersebut 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 di markup HTML awal.
• Elemen LCP memerlukan gambar latar CSS, tetapi gambar tersebut telah dimuat sebelumnya menggunakan <link rel="preload"> di markup HTML (atau menggunakan header Link).
• Elemen LCP adalah node teks yang memerlukan font web untuk dirender, dan font tersebut dimuat menggunakan <link rel="preload"> dalam markup HTML (atau menggunakan header Link).

Berikut adalah beberapa contoh yang mana resource LCP tidak dapat ditemukan setelah memindai respons dokumen HTML:

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

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

Untuk menghilangkan penundaan pemuatan resource yang tidak perlu, resource LCP Anda seharusnya dapat ditemukan dari sumber HTML. Jika resource hanya dirujuk dari file CSS atau JavaScript eksternal, resource LCP harus dimuat sebelumnya 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">

Mengoptimalkan prioritas yang diberikan resource

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

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

Bahkan tanpa pemuatan lambat, gambar pada awalnya tidak dimuat dengan prioritas tertinggi oleh browser karena bukan merupakan resource yang memblokir perenderan. Anda dapat memberikan petunjuk ke 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 tetapkan fetchpriority="high" di elemen <img> jika menurut Anda kemungkinan tersebut adalah elemen LCP halaman Anda. Namun, menetapkan prioritas tinggi di lebih dari satu atau dua gambar akan membuat setelan prioritas tidak membantu dalam mengurangi LCP.

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

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

Tidak memprioritaskan resource tertentu dapat menghasilkan bandwidth yang lebih besar ke resource yang lebih membutuhkannya—tapi hati-hati. Selalu periksa prioritas resource di DevTools dan uji perubahan dengan alat lab dan kolom.

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

2. Menghilangkan penundaan render elemen

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

Alasan utama elemen LCP tidak dapat dirender segera setelah resource-nya selesai dimuat adalah jika rendering diblokir karena beberapa 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 (sedang menunggu beberapa kode JavaScript dimuat).
• Elemen ini disembunyikan oleh beberapa kode lain, seperti library pengujian A/B yang masih menentukan eksperimen apa yang harus dilakukan pengguna.
• Thread utama diblokir karena tugas yang berjalan lama, dan tugas rendering harus menunggu hingga tugas yang panjang tersebut selesai.

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

Mengurangi atau menyisipkan stylesheet pemblokiran render inline

Style sheet yang dimuat dari markup HTML akan memblokir perenderan semua konten yang mengikutinya, dan itu bagus, karena Anda umumnya tidak ingin merender HTML tanpa gaya. Namun, jika lembar gaya berukuran sangat besar sehingga waktu pemuatannya jauh lebih lama daripada resource LCP, hal ini akan mencegah rendering elemen LCP—bahkan setelah resource-nya selesai dimuat, seperti yang ditunjukkan dalam contoh berikut:

Untuk memperbaikinya, opsi Anda adalah:

• menyisipkan lembar gaya ke dalam HTML untuk menghindari permintaan jaringan tambahan; atau,
• mengurangi ukuran {i>style sheet<i}.

Secara umum, menyisipkan style sheet hanya disarankan jika Anda berukuran kecil karena konten yang digarisbawahi dalam HTML tidak dapat memanfaatkan penyimpanan dalam cache pada pemuatan laman berikutnya. Jika lembar gaya terlalu besar sehingga membutuhkan waktu lebih lama untuk dimuat daripada resource LCP, kemungkinannya tidak akan cocok untuk digunakan sebagai kandidat yang baik untuk inline.

Dalam sebagian besar kasus, cara terbaik untuk memastikan lembar gaya tidak memblokir rendering elemen LCP adalah dengan mengurangi ukurannya sehingga lebih kecil daripada resource LCP. Hal ini akan memastikan bahwa hal tersebut tidak menjadi bottleneck bagi sebagian besar kunjungan.

Beberapa rekomendasi untuk mengurangi ukuran lembar gaya adalah:

• Hapus 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 lembar gaya 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 transfernya sebanyak mungkin.

Tunda atau ubah JavaScript yang memblokir perenderan inline

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

Jika kode JavaScript perlu dijalankan sedini mungkin saat pemuatan halaman, sebaiknya lakukan inline agar rendering tidak tertunda menunggu permintaan jaringan lainnya. Seperti halnya stylesheet, Anda sebaiknya hanya membuat skrip inline jika ukurannya sangat kecil.

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

<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 dari SSR:

• Resource gambar Anda akan dapat ditemukan dari sumber HTML (seperti yang dibahas pada 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. Kompromi ini biasanya bermanfaat karena waktu pemrosesan server berada dalam kendali Anda, sedangkan kemampuan jaringan dan perangkat pengguna Anda tidak.

Opsi yang serupa dengan SSR disebut pembuatan situs statis (SSG) atau pra-rendering. Ini adalah proses menghasilkan halaman HTML pada langkah pembuatan, bukan sesuai permintaan. Jika pra-rendering memungkinkan pada arsitektur Anda, biasanya ini adalah pilihan yang lebih baik untuk performa.

Pecah tugas yang panjang

Meskipun Anda telah mengikuti saran sebelumnya, dan kode JavaScript Anda tidak memblokir perenderan dan tidak bertanggung jawab untuk merender elemen Anda, kode ini masih dapat menunda LCP.

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

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

3. Mengurangi durasi pemuatan resource

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

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

Mengurangi ukuran resource

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

• Menayangkan ukuran gambar yang optimal
• Menggunakan format gambar modern
• Kompresi gambar
• Kurangi ukuran font web

Kurangi jarak yang harus ditempuh sumber daya

Selain mengurangi ukuran sumber daya, Anda juga dapat mengurangi waktu muat dengan menempatkan server Anda sedekat mungkin dengan pengguna. Cara terbaik untuk melakukannya adalah dengan menggunakan jaringan penayangan konten (CDN).

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

Mengurangi pertentangan untuk bandwidth jaringan

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

Jika Anda telah memberikan fetchpriority tinggi pada resource LCP dan mulai memuatnya sesegera mungkin, browser akan melakukan upaya terbaik untuk mencegah resource berprioritas lebih rendah bersaing dengan resource tersebut. Namun, jika Anda memuat banyak resource dengan fetchpriority yang tinggi, atau jika Anda hanya memuat banyak resource secara umum, hal ini dapat memengaruhi seberapa cepat resource LCP dimuat.

Menghilangkan waktu jaringan sepenuhnya

Cara terbaik untuk mengurangi durasi pemuatan sumber daya adalah menghilangkan jaringan sepenuhnya dari proses. Jika Anda menyediakan resource dengan kebijakan kontrol cache yang efisien, pengunjung yang meminta resource tersebut untuk kedua kalinya akan mendapatkan resource yang disalurkan dari cache, sehingga durasi pemuatan resource pada dasarnya menjadi nol.

Jika resource LCP Anda berupa font web, selain mengurangi ukuran font web, Anda juga harus mempertimbangkan apakah Anda perlu memblokir rendering pada pemuatan resource font web. Jika Anda menetapkan nilai font-display 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, sebaiknya sejajarkan resource tersebut sebagai URL data, yang juga akan menghilangkan permintaan jaringan tambahan. Namun, penggunaan URL data dilengkapi dengan peringatan karena resource tidak dapat disimpan dalam 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 untuk mengirimkan HTML awal secepat mungkin. Langkah ini tercantum terakhir karena sering kali merupakan hal yang paling tidak dapat dikontrol oleh developer. Namun, hal ini juga merupakan salah satu langkah terpenting karena secara langsung memengaruhi setiap langkah setelahnya. Tidak ada yang dapat terjadi di frontend hingga backend mengirimkan byte konten pertama tersebut, sehingga apa pun yang dapat Anda lakukan untuk mempercepat TTFB akan meningkatkan setiap metrik pemuatan lainnya.

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

Penyebab umum lainnya adalah ketika konten yang di-cache tidak dapat digunakan dari server edge CDN, dan semua permintaan harus diarahkan kembali ke server asal. Hal ini dapat terjadi jika parameter URL unik digunakan oleh pengunjung untuk analisis, meskipun parameter tersebut tidak menampilkan halaman yang berbeda.

Untuk mengetahui panduan khusus tentang cara mengoptimalkan TTFB, lihat panduan mengoptimalkan TTFB.

Memantau perincian LCP di JavaScript

Informasi pengaturan waktu untuk semua sub-bagian LCP yang dibahas sebelumnya tersedia untuk Anda di JavaScript melalui kombinasi API performa berikut:

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

Manfaat menghitung nilai pengaturan waktu ini dalam JavaScript adalah memungkinkan Anda 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 Waktu di panel Performa Chrome DevTools.

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

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

Screenshot ini menunjukkan contoh yang mencatat total waktu setiap sub-bagian LCP, serta persentasenya dari total waktu LCP ke konsol.

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 mengirim data ini ke penyedia analisis sehingga Anda dapat lebih memahami perincian LCP di halaman Anda untuk pengguna sungguhan.

Memantau perincian LCP menggunakan ekstensi Data Web

Ekstensi Data Web akan mencatat waktu LCP, elemen LCP, dan empat sub-bagian ini di konsol ke dalam log, agar Anda dapat melihat perincian ini dengan mudah.

Ringkasan

LCP itu rumit, dan waktunya dapat dipengaruhi oleh sejumlah faktor. Namun, jika Anda menganggap bahwa pengoptimalan LCP terutama ditujukan untuk mengoptimalkan pemuatan resource LCP, tindakan ini dapat menyederhanakan beberapa hal secara signifikan.

Secara umum, pengoptimalan LCP dapat dirangkum 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. Kirimkan dokumen HTML awal secepat mungkin.

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