Selama bertahun-tahun, komunitas web telah mengumpulkan banyak pengetahuan tentang pengoptimalan performa web. Meskipun satu pengoptimalan dapat meningkatkan performa untuk banyak situs, semua pengoptimalan sekaligus dapat terasa berlebihan dan, secara realistis, hanya beberapa pengoptimalan yang berlaku 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 adalah kebenaran tentang pengoptimalan performa: Anda tidak dapat menilainya hanya berdasarkan manfaat teknisnya. Anda juga perlu mempertimbangkan faktor manusia dan organisasi yang memengaruhi kemungkinan Anda dapat menerapkan pengoptimalan tertentu. Beberapa peningkatan performa mungkin sangat berdampak secara teori, tetapi pada kenyataannya, hanya sedikit developer yang memiliki waktu atau resource untuk menerapkannya. Di sisi lain, mungkin ada praktik terbaik performa yang sangat berdampak 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 lulus nilai minimum untuk pengalaman "baik" dibandingkan dengan pendahulunya yang tidak digunakan lagi, Anda mungkin termasuk salah satu dari banyak developer yang belajar 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 membagi tugas yang lama. Anda dapat melakukannya dengan sering beralih ke thread utama sehingga update rendering dan interaksi pengguna lainnya dapat terjadi lebih cepat.
Scheduler API memungkinkan Anda mengantrekan tugas menggunakan sistem prioritas. Secara khusus, scheduler.yield() API membagi tugas yang panjang sekaligus memastikan bahwa interaksi dapat ditangani tanpa mengorbankan tempatnya dalam antrean tugas.
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 trennya 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 pengelola tag, optimalkan tag Anda 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 tujuan yang Anda coba 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 2024 Web Almanac oleh Arsip HTTP, 73% 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-nya berupa gambar, 35% 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, 15% halaman yang memenuhi syarat 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.
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 harus dapat ditemukan dalam respons HTML untuk mengurangi penundaan pemuatan resource-nya. Beberapa tips untuk mewujudkannya adalah:
- Muat gambar menggunakan elemen
<img>
dengan atributsrc
atausrcset
. Jangan gunakan atribut non-standar sepertidata-src
yang memerlukan JavaScript untuk dirender, karena akan selalu lebih lambat. 7% halaman mengaburkan gambar LCP-nya di balikdata-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 berjalan sebelum gambar dapat ditemukan.
- Jika gambar perlu direferensikan dari file CSS atau JS eksternal, Anda tetap 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. Hal ini meningkatkan prioritas resource gambar sehingga dapat mulai dimuat lebih cepat. - Hapus atribut
loading="lazy"
dari tag<img>
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 secara lambat atau iframe, atau memuat resource secara asinkron menggunakan JavaScript akan membantu memperlancar pemuatan resource yang lebih penting seperti gambar LCP dengan 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, diperlukan upaya yang sangat besar untuk memangkas waktu beberapa milidetik saja. 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 cache 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.
Browser Support
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 mewujudkan peningkatan ini, pastikan halaman yang benar diprarender. Spekulasi yang salah akan membuang resource di server dan klien, yang 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 ke 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 ditempuh resource tersebut melalui jaringan 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 33% permintaan dokumen HTML yang ditayangkan dari CDN. Artinya, ada peluang yang signifikan bagi situs untuk mendapatkan penghematan tambahan.
Beberapa tips untuk mengonfigurasi CDN meliputi:
- Menyimpan dokumen HTML statis dalam cache meskipun untuk waktu yang singkat. Misalnya, apakah konten harus selalu baru? 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. Menetapkan ukuran eksplisit pada konten apa pun yang dimuat dari halaman
Perubahan tata letak biasanya terjadi saat konten yang ada dipindahkan setelah konten lain selesai dimuat. Cara utama untuk meningkatkan CLS adalah dengan mereservasi ruang yang diperlukan terlebih dahulu sebanyak mungkin.
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. 66% halaman memiliki setidaknya satu gambar tanpa ukuran. Tanpa ukuran eksplisit, 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.
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 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 masuk akal 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, cache kembali/maju (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. Menghindari animasi dan transisi yang menggunakan properti CSS yang menyebabkan tata letak
Sumber umum lainnya dari pergeseran tata letak adalah saat elemen dianimasikan. Misalnya, banner cookie atau banner notifikasi lainnya yang muncul 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 melakukan transisi atau menganimasikan setiap properti CSS yang menyebabkan tata letak, hal itu akan menghasilkan pergeseran tata letak. Jika pergeseran tata letak tersebut tidak terjadi dalam waktu 500 milidetik setelah interaksi pengguna, pergeseran 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 diposisikan secara mutlak yang menganimasikan top
atau left
menyebabkan pergeseran tata letak, meskipun 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 melakukan transisi 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, pilih transisi dan animasi menggunakan properti transform
CSS.
Audit Lighthouse Menghindari animasi yang tidak digabungkan memperingatkan saat halaman menganimasikan properti CSS yang berpotensi memperlambat.
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 untuk menggunakan
isInputPending
API sebagai bagian dari pemisahan tugas yang panjang. Anda dapat mempelajari lebih lanjut alasan kami di artikel Mengoptimalkan Tugas Panjang.
- LCP
- Kami menggabungkan rekomendasi visibilitas dan prioritas menjadi satu.
- Kami menambahkan rekomendasi baru untuk mengarahkan navigasi instan.
Januari 2023
Berikut adalah daftar rekomendasi awal:
- LCP
- Memastikan resource LCP dapat ditemukan dari sumber HTML
- Memastikan resource LCP diprioritaskan
- Menggunakan CDN untuk mengoptimalkan TTFB dokumen dan resource
- CLS
- Menetapkan ukuran eksplisit pada konten apa pun yang dimuat dari halaman
- Memastikan halaman memenuhi syarat untuk bfcache
- Menghindari animasi dan transisi yang menggunakan properti CSS yang menyebabkan tata letak
- FID
- Menghindari atau membagi tugas yang panjang
- Menghindari JavaScript yang tidak perlu
- Menghindari update rendering yang besar
Anda juga dapat menonton presentasi Google I/O 2023 ini untuk melihat ringkasan video.