Halaman ini diterjemahkan oleh Cloud Translation API.

Cara paling efektif untuk meningkatkan Core Web Vitals

Dari tahun ke tahun, komunitas web telah mengembangkan banyak pengetahuan pengoptimalan performa web. Meskipun satu pengoptimalan dapat meningkatkan kinerja untuk banyak situs, semuanya sekaligus dapat terasa membingungkan dan, pada kenyataannya, hanya beberapa di antaranya yang dapat diterapkan untuk situs tertentu.

Kecuali jika Anda bekerja di bidang performa web, mungkin Anda tidak tahu pengoptimalan mana yang akan paling berdampak pada situs Anda. Anda mungkin tidak akan memiliki waktu untuk semuanya, jadi penting untuk bertanya pada diri sendiri apa pengoptimalan yang paling berdampak yang dapat Anda pilih untuk meningkatkan performa bagi pengguna?

Berikut fakta tentang pengoptimalan performa: Anda tidak dapat menilainya hanya berdasarkan keunggulan teknisnya. Anda juga perlu mempertimbangkan faktor manusia dan organisasi yang memengaruhi seberapa besar kemungkinan Anda dapat menerapkan pengoptimalan yang diberikan. Beberapa peningkatan performa mungkin berdampak besar secara teori, tetapi pada kenyataannya, hanya sedikit developer yang memiliki waktu atau sumber daya untuk menerapkannya. Di sisi lain, mungkin ada praktik terbaik performa yang berdampak sangat besar yang sudah diikuti oleh hampir semua orang. Panduan ini mengidentifikasi pengoptimalan performa web yang:

Memiliki dampak terbesar di dunia nyata
Relevan dan berlaku untuk sebagian besar situs
Realistis untuk diterapkan oleh sebagian besar developer

Secara keseluruhan, ini adalah cara paling realistis dan berdampak yang dapat Anda lakukan untuk meningkatkan metrik Core Web Vitals. Jika Anda baru mengenal performa web—atau jika Anda masih memutuskan hal yang akan memberikan laba atas investasi terbesar—ini adalah tempat terbaik untuk memulai.

Interaction to Next Paint (INP)

Sebagai metrik Core Web Vitals terbaru, Interaction to Next Paint (INP) memiliki beberapa peluang terbesar untuk peningkatan. Namun, karena lebih sedikit situs yang melewati batas pengalaman "baik" dibandingkan dengan pendahulunya yang tidak digunakan lagi, Anda mungkin termasuk dari banyak developer yang baru mempelajari cara mengoptimalkan responsivitas interaksi untuk pertama kalinya. Mulailah dengan teknik yang harus diketahui ini untuk mengetahui cara paling efektif meningkatkan INP.

1. Sering kali menghasilkan untuk membagi tugas yang panjang

Tugas adalah bagian dari pekerjaan terpisah yang dilakukan browser, termasuk rendering, tata letak, penguraian, kompilasi, atau eksekusi skrip. Jika durasi tugas melebihi 50 milidetik, tugas tersebut menjadi tugas yang berjalan lama. Tugas yang lama dapat menimbulkan masalah karena dapat memblokir thread utama agar tidak merespons interaksi pengguna dengan cepat.

Meskipun Anda harus selalu berusaha melakukan pekerjaan sesedikit mungkin di JavaScript, Anda dapat membantu thread utama dengan memisahkan tugas yang panjang. Anda dapat melakukannya dengan sering beralih ke thread utama sehingga update rendering dan interaksi pengguna lainnya dapat terjadi lebih cepat.

Dukungan Browser

Sumber

Scheduler API memungkinkan Anda mengantrekan tugas menggunakan sistem prioritas. Secara khusus, API scheduler.yield() memecah tugas yang panjang sambil memastikan bahwa interaksi dapat ditangani tanpa melepaskan tempatnya dalam task queue.

Dengan membagi tugas yang panjang, Anda memberi browser lebih banyak peluang untuk menyesuaikan pekerjaan penting yang memblokir pengguna.

2. Menghindari JavaScript yang tidak perlu

Situs mengirimkan lebih banyak JavaScript daripada sebelumnya, dan tren ini tampaknya tidak berubah. Jika mengirimkan terlalu banyak JavaScript, Anda akan menciptakan lingkungan tempat tugas bersaing untuk mendapatkan perhatian thread utama. Hal ini dapat memengaruhi responsivitas situs Anda, terutama selama periode startup yang penting tersebut.

Namun, ini bukan masalah yang tidak dapat dipecahkan, dan Anda memiliki beberapa opsi:

Gunakan fitur platform web Baseline yang tersedia secara luas, bukan implementasi berbasis JavaScript yang redundan.
Gunakan alat cakupan di Chrome DevTools untuk menemukan kode yang tidak digunakan dalam skrip Anda. Dengan mengurangi ukuran resource yang diperlukan selama startup, Anda dapat memastikan bahwa halaman menghabiskan lebih sedikit waktu untuk mengurai dan mengompilasi kode, sehingga memberikan pengalaman pengguna awal yang lebih lancar.
Gunakan pemisahan kode untuk membuat paket terpisah bagi kode yang tidak diperlukan untuk rendering awal, tetapi akan tetap digunakan nanti.
Jika Anda menggunakan Tag Manager, optimalkan tag secara berkala. Tag lama dengan kode yang tidak digunakan dapat dihapus untuk mengurangi jejak JavaScript Tag Manager Anda.

3. Menghindari update rendering yang besar

Eksekusi JavaScript hanyalah salah satu hal yang memengaruhi responsivitas situs Anda. Rendering adalah jenis pekerjaan yang mahal dengan sendirinya—dan selama update rendering besar, situs Anda mungkin merespons interaksi pengguna dengan lebih lambat.

Mengoptimalkan pekerjaan rendering bukanlah proses yang mudah, dan bergantung pada apa yang ingin Anda capai. Meskipun demikian, berikut beberapa hal yang dapat Anda lakukan untuk memastikan bahwa tugas rendering tidak menjadi tugas yang lama:

Atur ulang operasi baca dan tulis DOM dalam kode JavaScript Anda untuk menghindari tata letak paksa dan pemborosan tata letak.
Pastikan ukuran DOM tetap kecil. Ukuran DOM dan intensitas pekerjaan tata letak berkorelasi. Saat perender harus memperbarui tata letak untuk DOM yang sangat besar, pekerjaan yang diperlukan untuk menghitung ulang tata letaknya dapat meningkat secara signifikan.
Gunakan pembatasan CSS untuk merender konten DOM di luar layar secara lambat. Hal ini tidak selalu mudah, tetapi dengan mengisolasi area yang berisi tata letak yang kompleks, Anda dapat menghindari pekerjaan tata letak dan rendering yang tidak perlu.

Largest Contentful Paint (LCP)

Largest Contentful Paint (LCP) adalah Core Web Vital yang paling sering menjadi masalah bagi developer—40% situs dalam Laporan UX Chrome tidak memenuhi nilai minimum LCP yang direkomendasikan untuk pengalaman pengguna yang baik. Tim Chrome merekomendasikan teknik berikut sebagai cara paling efektif untuk meningkatkan LCP.

1. Pastikan resource LCP dapat ditemukan dari sumber HTML dan diprioritaskan

Tim Chrome telah melihat hal berikut terkait LCP di web:

Menurut Almanak Web 2022 oleh HTTP Archive, 72% halaman seluler memiliki gambar sebagai elemen LCP-nya.
Analisis data pengguna sebenarnya dari Chrome menunjukkan bahwa sebagian besar origin dengan LCP yang buruk menghabiskan kurang dari 10% waktu LCP p75 mereka untuk mendownload gambar LCP.
Di antara halaman dengan LCP yang buruk, pemuatan gambar LCP-nya tertunda di klien sebesar 1.290 milidetik pada persentil ke-75—lebih dari setengah anggaran untuk pengalaman yang cepat.
Dari halaman yang elemen LCP adalah gambar, 39% dari gambar tersebut memiliki URL sumber yang tidak dapat ditemukan dalam respons HTML awal (seperti <img src="..."> atau <link rel="preload" href="...">), yang akan memungkinkan pemindai pramuat browser menemukannya sesegera mungkin.
Menurut Web Almanac, hanya 0,03% halaman yang memenuhi syarat yang memanfaatkan atribut HTML fetchpriority untuk memberikan prioritas yang lebih tinggi pada resource—termasuk resource yang dapat meningkatkan LCP halaman dengan relatif sedikit upaya.

Statistik ini menunjukkan bahwa developer memiliki peluang besar untuk mengurangi penundaan pemuatan resource dan durasi pemuatan resource untuk gambar LCP.

Dukungan Browser

Sumber

Jika penundaan pemuatan resource adalah masalahnya, penting untuk diingat bahwa mungkin sudah terlambat untuk mencapai LCP yang baik jika halaman harus menunggu CSS atau JavaScript dimuat sepenuhnya sebelum gambar dapat mulai dimuat. Selain itu, durasi pemuatan resource gambar LCP dapat dikurangi dengan memprioritaskannya ulang sehingga menerima lebih banyak bandwidth dan memuat lebih cepat menggunakan atribut HTML fetchpriority.

Jika elemen LCP Anda adalah gambar, URL gambar tersebut harus dapat ditemukan dalam respons HTML untuk mengurangi penundaan pemuatan resource. Beberapa tips untuk melakukannya adalah:

Muat gambar menggunakan elemen <img> dengan atribut src atau srcset. Jangan gunakan atribut non-standar seperti data-src yang memerlukan JavaScript untuk dirender, karena akan selalu lebih lambat. 9% halaman mengaburkan gambar LCP-nya di balik data-src.
Pilih rendering sisi server (SSR) daripada rendering sisi klien (CSR), karena SSR menyiratkan bahwa markup halaman lengkap (termasuk gambar) ada di sumber HTML. Solusi CSR memerlukan JavaScript untuk dijalankan sebelum gambar dapat ditemukan.
Jika gambar perlu direferensikan dari file CSS atau JS eksternal, Anda masih dapat menyertakannya dalam sumber HTML menggunakan tag <link rel="preload">. Perhatikan bahwa gambar yang dirujuk oleh gaya inline tidak dapat ditemukan oleh pemindai pramuat browser, sehingga meskipun ditemukan di sumber HTML, penemuannya mungkin masih diblokir saat memuat resource lain, sehingga pramuat dapat membantu dalam kasus ini.

Selain itu, Anda dapat mempersingkat durasi pemuatan resource dengan memastikan bahwa resource LCP dimuat lebih awal, dan dengan prioritas tinggi:

Tambahkan atribut fetchpriority="high" ke tag <img> atau <link rel="preload"> gambar LCP Anda. Tindakan ini akan meningkatkan prioritas resource gambar sehingga dapat mulai dimuat lebih cepat.
Hapus atribut loading="lazy" dari tag <img> pada gambar LCP Anda. Hal ini menghindari penundaan pemuatan yang disebabkan oleh konfirmasi bahwa gambar muncul di atau di dekat area pandang.
Tunda resource yang tidak penting jika memungkinkan. Memindahkan resource ini ke akhir dokumen, memuat gambar dengan lambat atau iframe, atau memuatnya secara asinkron menggunakan JavaScript akan membantu mempermudah proses pemuatan resource yang lebih penting seperti gambar LCP agar dapat dimuat lebih cepat.

2. Bertujuan untuk navigasi instan

Pengalaman pengguna yang ideal adalah tidak perlu menunggu halaman dimuat. Pengoptimalan LCP seperti visibilitas dan prioritas resource efektif dalam mengurangi waktu tunggu pengguna untuk memuat dan merender elemen LCP—tetapi ada batas fisik untuk kecepatan byte tersebut dimuat melalui jaringan dan dirender di halaman. Jauh sebelum Anda mencapai batas tersebut, ada upaya yang sangat besar yang diperlukan untuk memangkas beberapa milidetik lagi. Jadi, untuk mencapai navigasi instan, kita perlu menggunakan pendekatan yang sangat berbeda.

Navigasi instan mencoba memuat dan merender halaman sebelum pengguna mulai membukanya. Dengan cara ini, halaman yang dipra-render dapat langsung ditampilkan dengan LCP yang hampir nol. Restorasi dan spekulasi adalah dua cara untuk melakukannya. Saat pengguna membuka kembali atau melanjutkan ke halaman yang sebelumnya dikunjungi, halaman tersebut dapat dipulihkan dengan cepat dari cache dalam memori, yang muncul persis seperti saat pengguna meninggalkannya. Atau, aplikasi web dapat mencoba memprediksi tujuan pengguna selanjutnya—dan jika benar, halaman berikutnya akan dimuat dan dirender pada saat pengguna membukanya.

Pemulihan halaman yang sebelumnya dikunjungi dapat dilakukan dengan back-forward cache (bfcache). Untuk menggunakannya, Anda harus memastikan bahwa halaman Anda memenuhi kriteria kelayakan bfcache. Penyebab umum halaman tidak memenuhi syarat untuk bfcache adalah karena halaman ditayangkan dengan perintah caching no-store atau memiliki pemroses peristiwa unload.

Memulihkan halaman yang dirender sepenuhnya tidak hanya meningkatkan performa pemuatan, tetapi juga stabilitas tata letak. Anda dapat mempelajari bfcache lebih lanjut dan seberapa efektifnya untuk meningkatkan CLS di bagian Memastikan halaman memenuhi syarat untuk bfcache.

Dukungan Browser

Melakukan pra-rendering halaman berikutnya yang dikunjungi pengguna adalah cara efektif lainnya untuk meningkatkan performa LCP secara drastis, dan dapat dilakukan dengan Speculation Rules API. Namun, untuk merealisasikan keuntungan ini, pastikan bahwa halaman yang benar telah dipra-render. Spekulasi yang salah akan memboroskan resource pada server dan klien, sehingga dapat menurunkan performa. Jadi, semakin tidak yakin Anda dengan halaman berikutnya, semakin konservatif Anda harus melakukan pra-rendering. Jika ragu, data analisis dapat memberi Anda keyakinan untuk lebih cepat melakukan pra-rendering halaman dengan probabilitas tertinggi untuk dikunjungi berikutnya.

3. Menggunakan CDN untuk mengoptimalkan TTFB

Rekomendasi sebelumnya berfokus pada navigasi instan, yang memberikan pengalaman terbaik kepada pengguna, tetapi mungkin ada situasi saat teknik pemuatan spekulatif dan bfcache tidak berlaku. Pertimbangkan pengguna yang mengikuti link lintas-asal ke situs Anda, dengan respons dokumen HTML awal yang secara efektif memblokir LCP. Browser tidak dapat mulai memuat sub-resource apa pun hingga menerima byte pertama respons. Makin cepat hal itu terjadi, makin cepat hal lainnya dapat mulai terjadi.

Waktu ini dikenal sebagai Time to First Byte (TTFB). Cara terbaik untuk mengurangi TTFB adalah dengan:

Tayangkan konten Anda sedekat mungkin secara geografis dengan pengguna.
Simpan konten tersebut dalam cache agar dapat ditayangkan dengan cepat jika diminta lagi dalam waktu dekat.

Cara terbaik untuk melakukan kedua hal ini adalah dengan menggunakan CDN. CDN mendistribusikan resource Anda ke server edge di seluruh dunia, sehingga membatasi jarak yang harus dilalui resource tersebut melalui kabel ke pengguna. CDN juga biasanya memiliki kontrol penyimpanan dalam cache terperinci yang dapat disesuaikan untuk kebutuhan situs Anda.

CDN juga dapat menayangkan dan meng-cache dokumen HTML, tetapi menurut Web Almanac, hanya 29% permintaan dokumen HTML yang ditayangkan dari CDN. Artinya, ada peluang besar bagi situs untuk mewujudkan penghematan tambahan.

Beberapa tips untuk mengonfigurasi CDN meliputi:

Menyimpan dokumen HTML statis dalam cache meskipun untuk waktu yang singkat. Misalnya, apakah konten harus selalu terbaru? Atau apakah data tersebut dapat menjadi usang dalam beberapa menit?
Pelajari apakah Anda dapat memindahkan logika dinamis yang berjalan di server origin ke edge, yang merupakan fitur dari sebagian besar CDN modern.

Setiap kali Anda dapat menayangkan konten langsung dari edge dan menghindari perjalanan ke server origin, performa akan meningkat. Bahkan jika Anda harus melakukan perjalanan hingga ke origin, CDN umumnya dioptimalkan untuk melakukannya dengan lebih cepat, sehingga Anda tetap mendapatkan keuntungan.

Pergeseran Tata Letak Kumulatif (CLS)

Pergeseran Tata Letak Kumulatif (CLS) adalah ukuran stabilitas visual halaman web. Meskipun CLS adalah metrik yang cenderung baik untuk sebagian besar situs, sekitar seperempat dari situs tersebut masih belum memenuhi nilai minimum yang direkomendasikan, sehingga masih ada peluang besar bagi banyak situs untuk meningkatkan pengalaman pengguna mereka.

1. Setel ukuran eksplisit pada konten apa pun yang dimuat dari halaman

Perubahan tata letak biasanya terjadi saat konten yang ada berpindah setelah konten lain selesai dimuat. Cara utama untuk meningkatkan CLS adalah dengan mereservasi ruang yang diperlukan sebanyak mungkin di awal.

Cara terbaik untuk memperbaiki pergeseran tata letak yang disebabkan oleh gambar tanpa ukuran adalah dengan menetapkan atribut width dan height secara eksplisit atau properti CSS yang setara. 72% halaman memiliki setidaknya satu gambar tanpa ukuran. Tanpa ukuran yang jelas, gambar ini memiliki tinggi awal 0px, yang dapat menyebabkan pergeseran tata letak saat gambar ini dimuat dan browser menemukan dimensinya. Hal ini merupakan peluang besar bagi web kolektif—dan peluang tersebut memerlukan lebih sedikit upaya daripada beberapa rekomendasi lain yang disarankan dalam panduan ini.

Dukungan Browser

Sumber

Gambar bukan satu-satunya kontributor CLS. Pergeseran tata letak dapat disebabkan oleh konten lain yang biasanya dimuat setelah halaman dirender pada awalnya, termasuk iklan pihak ketiga atau video tersemat. Properti aspect-ratio dapat membantu Anda di sini. Ini adalah fitur CSS Dasar Pengukuran yang tersedia secara luas yang memungkinkan developer menetapkan rasio aspek secara eksplisit pada gambar serta elemen non-gambar. Hal ini memungkinkan Anda menetapkan width dinamis (misalnya berdasarkan ukuran layar), dan membuat browser otomatis menghitung tinggi yang sesuai, dengan cara yang sama seperti yang dilakukan untuk gambar dengan dimensi.

Namun, Anda tidak selalu dapat mengetahui ukuran persis konten dinamis. Meskipun tidak mengetahui ukuran persisnya, Anda tetap dapat mengurangi keparahan pergeseran tata letak. Menetapkan min-height yang wajar hampir selalu lebih baik daripada mengizinkan browser menggunakan tinggi default 0px untuk elemen kosong. Menggunakan min-height juga biasanya merupakan perbaikan yang mudah, karena masih memungkinkan penampung tumbuh hingga tinggi konten akhir jika diperlukan—penampung hanya mengurangi jumlah pertumbuhan tersebut ke tingkat yang diharapkan lebih dapat ditoleransi.

2. Memastikan halaman memenuhi syarat untuk bfcache

Seperti yang dinyatakan sebelumnya dalam panduan ini, back-forward cache (bfcache) langsung memuat halaman dari sebelumnya atau nanti di histori browser dari snapshot memori. Meskipun bfcache adalah pengoptimalan performa tingkat browser yang signifikan dan meningkatkan LCP, bfcache juga sepenuhnya menghilangkan pergeseran tata letak. Bahkan, pengenalan bfcache pada tahun 2022 bertanggung jawab atas peningkatan CLS terbesar yang kami lihat tahun itu.

Meskipun demikian, sejumlah besar situs tidak memenuhi syarat untuk bfcache, sehingga tidak mendapatkan manfaat dari peningkatan performa web gratis ini. Kecuali jika halaman Anda memuat informasi sensitif yang tidak ingin Anda pulihkan dari memori, pastikan halaman Anda memenuhi syarat untuk menggunakan bfcache.

Pemilik situs harus memeriksa apakah halaman memenuhi syarat untuk bfcache dan memperbaiki alasan halaman tidak memenuhi syarat. Chrome memiliki penguji bfcache di DevTools dan Anda juga dapat menggunakan Not Restored Reasons API untuk mendeteksi alasan ketidaklayakan di kolom.

3. Hindari animasi dan transisi yang menggunakan properti CSS yang memicu tata letak

Sumber umum lainnya dari pergeseran tata letak adalah saat elemen dianimasikan. Misalnya, banner cookie atau banner notifikasi lainnya yang bergeser masuk dari atas atau bawah sering kali berkontribusi pada CLS. Hal ini sangat bermasalah jika banner ini mendorong konten lain, tetapi meskipun tidak, menganimasikannya tetap dapat memengaruhi CLS.

Meskipun data HTTP Archive tidak dapat menghubungkan animasi secara meyakinkan ke pergeseran tata letak, data tersebut menunjukkan bahwa halaman yang menganimasikan properti CSS yang dapat memengaruhi tata letak memiliki kemungkinan 15% lebih kecil untuk memiliki CLS "baik" dibandingkan halaman secara keseluruhan. Beberapa properti dikaitkan dengan CLS yang lebih buruk daripada yang lain. Misalnya, halaman yang menganimasikan lebar margin atau border memiliki CLS "buruk" dengan rasio hampir dua kali lipat dari rasio halaman secara keseluruhan yang dinilai buruk.

Hal ini mungkin tidak mengejutkan, karena setiap kali Anda mentransisikan atau menganimasikan setiap properti CSS yang menyebabkan tata letak, hal itu akan menghasilkan perubahan tata letak. Jika pergeseran tata letak tersebut tidak berada dalam waktu 500 milidetik dari interaksi pengguna, pergeseran tata letak tersebut akan memengaruhi CLS.

Yang mungkin mengejutkan bagi beberapa developer adalah hal ini berlaku bahkan jika elemen diambil di luar alur dokumen normal. Misalnya, elemen yang benar-benar diposisikan yang menganimasikan top atau left menyebabkan pergeseran tata letak, meskipun elemen tersebut tidak mendorong konten lain. Namun, jika Anda menganimasikan transform:translateX() atau transform:translateY(), bukan menganimasikan top atau left, browser tidak akan memperbarui tata letak halaman, sehingga menghindari pergeseran tata letak.

Memilih animasi properti CSS yang dapat diperbarui di thread compositor browser telah lama menjadi praktik terbaik performa karena memindahkan pekerjaan tersebut dari thread utama ke GPU. Selain merupakan praktik terbaik performa umum, hal ini juga dapat membantu meningkatkan CLS.

Sebagai aturan umum, jangan pernah menganimasikan atau mentransisikan properti CSS yang mengharuskan browser memperbarui tata letak halaman, kecuali jika Anda melakukannya sebagai respons terhadap ketukan pengguna atau penekanan tombol (meskipun bukan hover). Jika memungkinkan, pilihlah transisi dan animasi menggunakan properti transform CSS.

Audit Lighthouse Hindari animasi non-gabungan memperingatkan saat halaman menganimasikan properti CSS yang berpotensi lambat.

Kesimpulan

Meningkatkan performa halaman mungkin tampak menakutkan, terutama karena ada banyak panduan di seluruh web yang perlu dipertimbangkan. Namun, dengan berfokus pada daftar singkat praktik terbaik yang paling efektif ini, Anda dapat mengatasi masalah dengan fokus baru, dan semoga dapat meningkatkan Core Web Vitals situs Anda.

Jika Anda ingin melakukan pengoptimalan di luar yang tercantum di sini, baca panduan ini untuk mengetahui informasi selengkapnya:

Lampiran: Log perubahan

Perubahan besar pada dokumen ini akan dilacak di sini untuk membantu menjelaskan kapan dan mengapa rekomendasi teratas berubah.

Oktober 2024

Pembaruan 2024:

INP
- Kami mengalihkan metrik ini dari FID ke INP sesuai dengan peluncuran INP sebagai metrik Core Web Vital dan menjadikannya metrik teratas dalam daftar.
- Kami membatalkan rekomendasi kami untuk menggunakan isInputPending API sebagai bagian dari pemisahan tugas yang panjang. Anda dapat mempelajari lebih lanjut alasan kami dalam artikel Mengoptimalkan Tugas Panjang.
LCP
- Kami menggabungkan rekomendasi visibilitas dan prioritas menjadi satu.
- Kami menambahkan rekomendasi baru untuk mengarahkan navigasi instan.

Januari 2023

Ini adalah daftar rekomendasi awal:

LCP
- Memastikan resource LCP dapat ditemukan dari sumber HTML
- Memastikan resource LCP diprioritaskan
- Gunakan CDN untuk mengoptimalkan TTFB dokumen dan sumber daya
CLS
- Setel ukuran eksplisit pada konten apa pun yang dimuat dari halaman
- Memastikan halaman memenuhi syarat untuk bfcache
- Hindari animasi dan transisi yang menggunakan properti CSS yang memicu tata letak
FID
- Menghindari atau menghentikan tugas yang lama
- Menghindari JavaScript yang tidak perlu
- Menghindari update rendering besar

Anda juga dapat menonton presentasi Google I/O 2023 ini untuk melihat ringkasan video.