Halaman ini diterjemahkan oleh Cloud Translation API.

Rekomendasi Data Web Inti teratas kami untuk tahun 2023

Kumpulan praktik terbaik yang dipercaya tim Chrome DevRel adalah cara paling efektif untuk meningkatkan performa Core Web Vitals pada tahun 2023.

Brendan Kenny

Jeremy Wagner

Philip Walton

Rick Viscomi

Barry Pollard

Dari tahun ke tahun, kami di Google telah membuat banyak rekomendasi bagi developer web tentang cara meningkatkan performa.

Meskipun setiap rekomendasi tersebut, satu per satu, dapat meningkatkan performa bagi banyak situs, rangkaian rekomendasi lengkap memang sangat berlebihan dan, secara realistis, tidak mungkin satu orang atau situs dapat mengikuti semuanya.

Kecuali jika kinerja web adalah pekerjaan harian Anda, rekomendasi mana yang akan memiliki dampak positif terbesar pada situs Anda tidak jelas. Misalnya, Anda mungkin pernah membaca bahwa menerapkan CSS penting dapat meningkatkan performa pemuatan, dan Anda mungkin juga pernah mendengar bahwa mengoptimalkan gambar itu penting. Namun, jika Anda tidak punya waktu untuk mengerjakan kedua hal tersebut, bagaimana Anda akan memutuskan mana yang akan dipilih?

Di tim Chrome, selama setahun terakhir kami mencoba menjawab pertanyaan ini: apa saja rekomendasi terpenting yang dapat kami berikan kepada developer untuk membantu mereka meningkatkan performa bagi pengguna?

Untuk menjawab pertanyaan ini secara memadai, kita harus mempertimbangkan tidak hanya manfaat teknis dari rekomendasi yang diberikan, tetapi juga faktor manusia dan organisasi yang memengaruhi kemungkinan bahwa developer benar-benar akan dapat mengadopsi rekomendasi ini. Dengan kata lain, beberapa rekomendasi mungkin berdampak besar secara teori, tetapi pada kenyataannya sangat sedikit situs yang memiliki waktu atau sumber daya untuk menerapkannya. Beberapa rekomendasi juga sangat penting, tetapi sebagian besar situs sudah mengikuti praktik ini.

Singkatnya, kami ingin agar daftar rekomendasi performa web teratas dapat menjadi fokus:

Rekomendasi yang kami yakini akan memiliki dampak terbesar pada dunia nyata
Rekomendasi yang relevan dan berlaku untuk sebagian besar situs
Rekomendasi yang realistis untuk diterapkan oleh sebagian besar developer

Selama setahun terakhir, kami telah menghabiskan banyak waktu untuk mengaudit serangkaian rekomendasi performa yang kami buat, dan menilai setiap rekomendasi tersebut (baik secara kualitatif maupun kuantitatif) berdasarkan ketiga kriteria di atas.

Postingan ini menguraikan rekomendasi terbaik kami untuk meningkatkan performa setiap metrik Data Web Inti. Jika Anda baru mengenal kinerja web, atau jika Anda mencoba menentukan apa yang akan memberikan keuntungan terbesar bagi Anda, menurut kami rekomendasi ini adalah tempat terbaik untuk memulai.

Largest Contentful Paint (LCP)

Kumpulan rekomendasi pertama kami adalah untuk Largest Contentful Paint (LCP), yang merupakan ukuran performa pemuatan. Dari tiga metrik Core Web Vitals, LCP adalah satu-satunya yang sulit ditangani oleh jumlah terbesar situs—hanya sekitar setengah dari semua situs di web saat ini yang memenuhi nilai minimum yang direkomendasikan—jadi mari kita mulai dari sana.

Pastikan resource LCP dapat ditemukan dari sumber HTML

Menurut 2022 Web Almanac dari HTTP Archive, 72% halaman seluler memiliki gambar sebagai elemen LCP. Artinya, sebagian besar situs harus mengoptimalkan LCP, mereka harus memastikan gambar tersebut dapat dimuat dengan cepat.

Yang mungkin tidak jelas bagi banyak developer adalah waktu yang diperlukan untuk memuat gambar hanyalah salah satu bagian dari tantangan. Bagian penting lainnya adalah waktu sebelum gambar mulai dimuat, dan data Arsip HTTP menunjukkan di sinilah banyak situs mengalami error.

Bahkan, untuk halaman yang elemen LCP adalah gambar, 39% dari gambar tersebut memiliki URL sumber yang tidak dapat ditemukan dari sumber dokumen HTML. Dengan kata lain, URL tersebut tidak ditemukan di atribut HTML standar (seperti <img src="..."> atau <link rel="preload" href="...">), yang akan memungkinkan browser menemukannya dengan cepat dan langsung mulai memuatnya.

Jika halaman harus menunggu file CSS atau JavaScript selesai didownload, diuraikan, dan diproses sebelum gambar dapat mulai dimuat, mungkin gambar sudah terlambat.

Sebagai aturan umum, jika elemen LCP Anda adalah gambar, URL gambar harus selalu dapat ditemukan dari sumber HTML. 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 merender, karena atribut tersebut akan selalu lebih lambat. 9% halaman mengaburkan gambar LCP-nya di belakang data-src.
Pilih rendering sisi server (SSR) daripada rendering sisi klien (CSR), karena SSR menyiratkan bahwa markup halaman penuh (termasuk gambar) ada di sumber HTML. Solusi CSR memerlukan JavaScript untuk dijalankan sebelum gambar dapat ditemukan.
Jika gambar Anda perlu dirujuk dari file CSS atau JS eksternal, Anda masih dapat menyertakannya dalam sumber HTML melalui tag <link rel="preload">. Perhatikan bahwa gambar yang direferensikan oleh gaya inline tidak dapat ditemukan oleh pemindai pramuat browser, jadi meskipun gambar tersebut ditemukan di sumber HTML, penemuannya mungkin masih diblokir saat pemuatan resource lain, sehingga pramuat dapat membantu dalam kasus ini.

Untuk membantu Anda memahami apakah gambar LCP Anda memiliki masalah visibilitas, Lighthouse akan merilis audit baru dalam versi 10.0 (perkiraan Januari 2023).

Memastikan resource LCP dapat ditemukan dari sumber HTML dapat menghasilkan peningkatan terukur dan juga membuka peluang tambahan untuk memprioritaskan resource tersebut, yang merupakan rekomendasi kami berikutnya.

Memastikan resource LCP diprioritaskan

Memastikan resource LCP dapat ditemukan dari sumber HTML merupakan langkah pertama yang penting dalam memastikan resource LCP dapat mulai dimuat lebih awal, tetapi langkah penting lainnya adalah memastikan bahwa pemuatan resource tersebut diprioritaskan dan tidak mengantre di belakang banyak resource lainnya yang kurang penting.

Misalnya, meskipun gambar LCP ada di sumber HTML menggunakan tag <img> standar, jika halaman Anda menyertakan puluhan tag <script> di <head> dokumen Anda sebelum tag <img> tersebut, mungkin perlu waktu beberapa saat sebelum resource gambar Anda mulai dimuat.

Cara termudah untuk menyelesaikan masalah ini adalah dengan memberikan petunjuk ke browser tentang resource apa yang merupakan prioritas tertinggi dengan menyetel atribut fetchpriority="high" baru pada tag <img> atau <link> yang memuat gambar LCP Anda. Tindakan ini menginstruksikan browser untuk memuatnya lebih awal, bukan menunggu skrip tersebut selesai.

Menurut Web Almanac, hanya 0,03% halaman yang memenuhi syarat yang memanfaatkan API baru ini, yang berarti ada banyak peluang bagi sebagian besar situs di web untuk meningkatkan LCP dengan upaya sangat sedikit. Meskipun atribut fetchpriority saat ini hanya didukung di browser berbasis Chromium, API ini merupakan peningkatan progresif yang diabaikan oleh browser lain, sehingga kami sangat menyarankan developer untuk menggunakannya sekarang.

Untuk browser non-Chromium, satu-satunya cara untuk memastikan resource LCP diprioritaskan daripada resource lainnya adalah dengan mereferensikannya di awal dalam dokumen. Dengan menggunakan contoh lagi situs yang memiliki banyak tag <script> di <head> dokumen, jika ingin memastikan resource LCP Anda diprioritaskan sebelum resource skrip tersebut, Anda dapat menambahkan tag <link rel="preload"> sebelum skrip tersebut, atau Anda dapat memindahkan skrip tersebut ke bawah <img> nanti di <body>. Meskipun berfungsi, aplikasi ini kurang ergonomis dibandingkan menggunakan fetchpriority, sehingga kami berharap browser lain segera menambahkan dukungan.

Aspek penting lainnya dalam memprioritaskan resource LCP adalah memastikan Anda tidak melakukan apa pun yang menyebabkan resource tersebut tidak diprioritaskan, seperti menambahkan atribut loading="lazy". Saat ini, 10% halaman benar-benar menetapkan loading="lazy" pada gambar LCP-nya. Waspadai solusi pengoptimalan gambar yang secara acak menerapkan perilaku pemuatan lambat untuk semua gambar. Jika mereka memberikan cara untuk mengganti perilaku tersebut, pastikan untuk menggunakannya untuk gambar LCP. Jika Anda tidak yakin gambar mana yang akan menjadi LCP, coba gunakan heuristik untuk memilih kandidat yang wajar.

Menunda resource yang tidak penting adalah cara lain untuk secara efektif meningkatkan prioritas relatif resource LCP. Misalnya, skrip yang tidak mendukung antarmuka pengguna (seperti skrip analisis atau widget media sosial) dapat ditunda dengan aman hingga peristiwa load diaktifkan, yang memastikannya tidak akan bersaing dengan resource penting lainnya (seperti resource LCP) untuk bandwidth jaringan.

Ringkasnya, Anda harus mengikuti praktik terbaik ini untuk memastikan bahwa resource LCP dimuat lebih awal, dan dengan prioritas tinggi:

Tambahkan fetchpriority="high" ke tag <img> gambar LCP Anda. Jika resource LCP dimuat melalui tag <link rel="preload">, jangan khawatir karena Anda juga dapat menetapkan fetchpriority="high" pada resource tersebut.
Jangan pernah menetapkan loading="lazy" pada tag <img> pada gambar LCP Anda. Tindakan ini akan mengurangi prioritas gambar dan menunda saat gambar mulai dimuat.
Tunda resource yang tidak penting jika memungkinkan. Anda dapat memindahkannya ke akhir dokumen, menggunakan pemuatan lambat native untuk gambar atau iframe, atau memuatnya secara asinkron melalui JavaScript.

Gunakan CDN untuk mengoptimalkan TTFB dokumen dan sumber daya

Dua rekomendasi sebelumnya berfokus pada memastikan resource LCP Anda ditemukan lebih awal dan diprioritaskan sehingga dapat segera mulai dimuat. Bagian terakhir dari teka-teki ini adalah memastikan respons dokumen awal tiba secepat mungkin.

Browser tidak dapat memulai pemuatan subresource apa pun hingga menerima byte pertama respons dokumen HTML awal, dan semakin cepat hal itu terjadi, semakin cepat semua hal lainnya juga mulai terjadi.

Waktu ini dikenal sebagai Time to First Byte (TTFB), dan cara terbaik untuk mengurangi TTFB adalah dengan:

Tayangkan konten Anda sedekat mungkin dengan pengguna secara geografis
Simpan konten tersebut ke dalam cache sehingga konten yang baru diminta dapat ditayangkan lagi dengan cepat.

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

Banyak developer yang terbiasa menggunakan CDN untuk menghosting aset statis, tetapi CDN juga dapat menyajikan dan menyimpan dokumen HTML dalam cache, bahkan dokumen yang dihasilkan secara dinamis.

Menurut Web Almanac, hanya 29% permintaan dokumen HTML yang dilayani dari CDN, yang berarti ada peluang signifikan bagi situs untuk mengklaim penghematan tambahan.

Beberapa tips untuk mengonfigurasi CDN Anda adalah:

Pertimbangkan untuk meningkatkan berapa lama konten disimpan dalam cache (misalnya, apakah konten harus selalu baru? Atau bisakah menjadi usang beberapa menit?).
Bahkan pertimbangkan untuk menyimpan konten di cache tanpa batas waktu, lalu bersihkan cache jika/saat Anda melakukan pembaruan.
Pelajari apakah Anda dapat memindahkan logika dinamis yang saat ini berjalan di server asal ke edge (fitur dari sebagian besar CDN modern).

Secara umum, kapan pun Anda dapat menayangkan konten langsung dari edge (menghindari perjalanan ke server asal), ini adalah performa yang menguntungkan. Dan bahkan jika Anda harus melakukan perjalanan kembali ke server asal, CDN umumnya dioptimalkan untuk melakukannya jauh lebih cepat, jadi tetaplah menguntungkan.

Pergeseran Tata Letak Kumulatif (CLS)

Kumpulan rekomendasi berikutnya adalah untuk Pergeseran Tata Letak Kumulatif (CLS), yang merupakan ukuran stabilitas visual di halaman web. Meskipun CLS semakin meningkat di web sejak tahun 2020, sekitar seperempat situs masih belum memenuhi batas yang direkomendasikan, sehingga masih ada peluang besar bagi banyak situs untuk meningkatkan pengalaman pengguna mereka.

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. Oleh karena itu, cara utama untuk mengurangi hal ini adalah dengan memesan ruang yang diperlukan terlebih dahulu.

Cara paling mudah untuk memperbaiki pergeseran tata letak yang disebabkan oleh gambar tidak berukuran adalah dengan secara eksplisit menetapkan atribut width dan height (atau properti CSS yang setara). Namun, menurut Arsip HTTP, 72% halaman memiliki setidaknya satu gambar tidak berukuran. Tanpa ukuran eksplisit, browser awalnya akan menetapkan tinggi default 0px dan dapat menyebabkan pergeseran tata letak yang kentara saat gambar akhirnya dimuat dan dimensi ditemukan. Hal ini merupakan peluang besar bagi web kolektif—dan peluang tersebut memerlukan upaya yang jauh lebih sedikit daripada beberapa rekomendasi lain yang disarankan dalam artikel ini.

Penting juga untuk diingat bahwa gambar bukan satu-satunya kontributor CLS. Pergeseran tata letak dapat disebabkan oleh konten lain yang biasanya dimuat setelah halaman pertama kali dirender, termasuk iklan pihak ketiga atau video sematan. Properti aspect-ratio dapat membantu mengatasi hal ini. Ini adalah fitur CSS yang relatif baru yang memungkinkan developer secara eksplisit memberikan rasio aspek ke gambar serta elemen non-gambar. Hal ini akan memungkinkan Anda menyetel 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.

Terkadang tidak mungkin mengetahui ukuran konten dinamis yang tepat karena, pada dasarnya, konten dinamis adalah hal yang dinamis. Namun, meskipun tidak mengetahui ukuran tepatnya, Anda tetap dapat mengambil langkah untuk mengurangi keparahan pergeseran tata letak. Menetapkan min-height yang logis hampir selalu lebih baik daripada mengizinkan browser menggunakan tinggi default 0px untuk elemen kosong. Menggunakan min-height biasanya juga merupakan perbaikan yang mudah karena masih memungkinkan penampung untuk tumbuh hingga tinggi konten akhir jika diperlukan. Penggunaan min-height baru saja mengurangi jumlah pertumbuhan tersebut dari jumlah penuh menjadi tingkat yang diharapkan lebih dapat ditoleransi.

Memastikan halaman memenuhi syarat untuk bfcache

Browser menggunakan mekanisme navigasi yang disebut back/forward cache—atau disingkat bfcache—untuk memuat halaman secara instan dari histori browser sebelumnya atau setelahnya, langsung dari snapshot memori.

bfcache adalah pengoptimalan performa tingkat browser yang signifikan, dan sepenuhnya menghilangkan pergeseran tata letak selama pemuatan halaman, yang bagi banyak situs adalah tempat sebagian besar CLS-nya terjadi. Pengenalan bfcache menyebabkan peningkatan CLS terbesar yang kami lihat pada tahun 2022.

Meskipun demikian, sejumlah besar situs tidak memenuhi syarat untuk bfcache, sehingga mereka tidak mendapatkan keunggulan performa web gratis untuk sejumlah besar navigasi ini. Kecuali jika halaman Anda memuat informasi sensitif yang tidak ingin dipulihkan dari memori, Anda harus memastikan bahwa halaman Anda memenuhi syarat.

Pemilik situs harus memeriksa apakah halaman mereka memenuhi syarat untuk bfcache dan mengatasi alasan apa pun yang tidak memenuhi syarat. Chrome sudah memiliki penguji bfcache di DevTools dan tahun ini kami berencana meningkatkan kualitas alat di sini dengan audit Lighthouse baru yang melakukan pengujian serupa dan API untuk mengukur hal ini di lapangan.

Meskipun kami telah menyertakan bfcache di bagian CLS, karena kami melihat peningkatan terbesar sejauh ini, bfcache secara umum juga akan meningkatkan Core Web Vitals lainnya. Navigasi ini merupakan salah satu dari sejumlah navigasi instan yang tersedia untuk meningkatkan kualitas navigasi halaman secara drastis.

Hindari animasi/transisi yang menggunakan properti CSS yang menyebabkan tata letak

Sumber pergeseran tata letak umum lainnya adalah ketika elemen dianimasikan. Misalnya, banner cookie atau banner notifikasi lainnya yang bergeser masuk dari atas atau bawah sering kali menjadi kontributor CLS. Hal ini sangat bermasalah jika banner ini mendorong konten lain sehingga tidak berhasil, tetapi meskipun tidak, animasinya masih dapat memengaruhi CLS.

Meskipun data Arsip HTTP tidak dapat secara pasti menghubungkan animasi ke pergeseran tata letak, data tersebut menunjukkan bahwa halaman yang menganimasikan properti CSS apa pun yang dapat memengaruhi tata letak memiliki kemungkinan 15% lebih kecil untuk memiliki CLS yang "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" hampir dua kali lipat rasio halaman secara keseluruhan yang dinilai buruk.

Hal ini mungkin tidak mengejutkan, karena setiap kali Anda melakukan transisi atau menganimasikan properti CSS apa pun yang memicu tata letak, hal ini akan menghasilkan pergeseran tata letak, dan jika pergeseran tata letak tersebut tidak terjadi dalam waktu 500 milidetik dari interaksi pengguna, perubahan tersebut akan memengaruhi CLS.

Yang mungkin mengejutkan bagi beberapa developer adalah bahwa hal ini berlaku bahkan saat elemen diambil di luar alur dokumen normal. Misalnya, elemen yang benar-benar diposisikan yang menganimasikan top atau left akan 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, hal ini tidak akan menyebabkan browser memperbarui tata letak halaman, sehingga tidak akan menghasilkan pergeseran tata letak apa pun.

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

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

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

Penundaan Input Pertama (FID)

Kumpulan rekomendasi terakhir kami adalah untuk Penundaan Input Pertama (FID), yang merupakan ukuran responsivitas halaman terhadap interaksi pengguna. Meskipun sebagian besar situs di web saat ini mendapat skor sangat baik dalam FID, kami telah mendokumentasikan kekurangan metrik FID sebelumnya, dan kami yakin masih ada banyak peluang bagi situs untuk meningkatkan responsivitas keseluruhannya terhadap interaksi pengguna.

Metrik Interaction to Next Paint (INP) baru kami adalah kemungkinan pengganti FID, dan semua rekomendasi di bawah ini juga berlaku untuk FID dan INP. Mengingat situs berperforma lebih buruk di INP daripada FID, terutama di perangkat seluler, sebaiknya developer dengan serius mempertimbangkan rekomendasi responsivitas ini, meskipun memiliki FID yang "baik".

Menghindari atau menghentikan tugas yang lama

Tugas adalah bagian pekerjaan terpisah yang dilakukan browser. Tugasnya meliputi rendering, tata letak, penguraian, kompilasi, dan eksekusi skrip. Jika tugas menjadi tugas yang panjang—yaitu, 50 milidetik atau lebih—tugas tersebut memblokir thread utama agar tidak dapat merespons input pengguna dengan cepat.

Menurut Web Almanak, ada banyak bukti yang menunjukkan bahwa developer dapat berbuat lebih banyak untuk menghindari atau menghentikan tugas yang lama. Meskipun memecah tugas yang lama mungkin tidak semudah rekomendasi lain dalam artikel ini, upaya ini lebih sedikit dibandingkan teknik lain yang tidak ditawarkan dalam artikel ini.

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

Opsi lainnya adalah mempertimbangkan penggunaan API seperti isInputPending dan Scheduler API. isInputPending adalah fungsi yang menampilkan nilai boolean yang menunjukkan apakah input pengguna tertunda. Jika metode tersebut menampilkan true, Anda dapat menyerah pada thread utama agar dapat menangani input pengguna yang tertunda.

Scheduler API adalah pendekatan yang lebih canggih, yang memungkinkan Anda menjadwalkan pekerjaan berdasarkan sistem prioritas yang memperhitungkan apakah pekerjaan yang dilakukan terlihat oleh pengguna atau berada di latar belakang.

Dengan memecah tugas yang berjalan lama, Anda memberikan browser lebih banyak peluang untuk cocok dengan pekerjaan penting yang terlihat oleh pengguna, seperti menangani interaksi dan semua update rendering yang dihasilkan.

Menghindari JavaScript yang tidak perlu

Tidak diragukan lagi: situs mengirimkan lebih banyak JavaScript daripada sebelumnya, dan trennya tidak terlihat berubah dalam waktu dekat. Jika Anda mengirimkan terlalu banyak JavaScript, artinya Anda membuat lingkungan tempat tugas-tugas yang bersaing mendapatkan perhatian thread utama. Hal ini pasti dapat memengaruhi responsivitas situs Anda, terutama selama periode startup yang penting tersebut.

Namun, ini bukan masalah yang tidak bisa dipecahkan. Anda memiliki beberapa opsi:

Gunakan alat cakupan di Chrome DevTools untuk menemukan kode yang tidak digunakan di resource situs Anda. Dengan mengurangi ukuran resource yang diperlukan selama startup, Anda dapat memastikan bahwa situs Anda menghabiskan lebih sedikit waktu untuk mengurai dan mengompilasi kode, yang akan menghasilkan pengalaman pengguna awal yang lebih lancar.
Terkadang, kode yang tidak digunakan yang Anda temukan dan menggunakan alat cakupan ditandai sebagai "unused" karena tidak dieksekusi selama startup, tetapi masih diperlukan untuk beberapa fungsi di masa mendatang. Ini adalah kode yang dapat Anda pindahkan ke paket terpisah melalui pemisahan kode.
Jika Anda menggunakan Tag Manager, pastikan untuk memeriksa tag secara berkala untuk memastikan tag dioptimalkan, atau meskipun tag masih digunakan. Tag lama dengan kode yang tidak digunakan dapat dihapus agar JavaScript Tag Manager Anda menjadi lebih kecil dan lebih efisien.

Menghindari update rendering besar

JavaScript bukan satu-satunya hal yang dapat memengaruhi responsivitas situs Anda. Rendering dapat menjadi jenis pekerjaan yang mahal—dan saat update rendering besar terjadi, update tersebut dapat mengganggu kemampuan situs Anda untuk merespons input pengguna.

Mengoptimalkan pekerjaan rendering bukanlah proses yang mudah, dan sering kali bergantung pada apa yang ingin Anda capai. Meski begitu, ada beberapa hal yang dapat Anda lakukan untuk memastikan update rendering wajar, dan tidak menyebar ke tugas yang berjalan lama:

Hindari penggunaan requestAnimationFrame() untuk melakukan pekerjaan non-visual. Panggilan requestAnimationFrame() ditangani selama fase rendering loop peristiwa, dan jika terlalu banyak pekerjaan yang dilakukan selama langkah ini, update rendering dapat tertunda. Setiap pekerjaan yang Anda lakukan dengan requestAnimationFrame() harus dicadangkan khusus untuk tugas yang melibatkan rendering update.
Pastikan ukuran DOM Anda tetap kecil. Ukuran DOM dan intensitas pekerjaan tata letak saling berkorelasi. Jika 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. Pembatasan CSS bergantung pada properti contain CSS, yang memberikan petunjuk ke browser tentang cara melakukan pekerjaan tata letak untuk penampung tempat properti contain ditetapkan, termasuk bahkan mengisolasi cakupan tata letak dan rendering ke root tertentu dalam DOM. Proses ini tidak selalu mudah, tetapi dengan mengisolasi area yang berisi tata letak kompleks, Anda dapat menghindari melakukan tugas tata letak dan rendering untuk area yang tidak diperlukan.

Kesimpulan

Meningkatkan performa halaman bisa jadi tampak sulit, terutama mengingat ada banyak panduan di seluruh web yang perlu dipertimbangkan. Namun, dengan berfokus pada rekomendasi ini, Anda dapat menyelesaikan masalah ini dengan fokus dan tujuan, dan semoga saja berhasil meningkatkan Core Web Vitals situs Anda.

Meskipun rekomendasi yang tercantum di sini sama sekali tidak lengkap, kami percaya—berdasarkan analisis yang cermat terhadap kondisi web—bahwa rekomendasi ini adalah cara paling efektif yang dapat digunakan situs untuk meningkatkan performa Core Web Vitals pada tahun 2023.

Jika Anda ingin lebih dari sekadar rekomendasi yang tercantum di sini, lihat panduan pengoptimalan berikut untuk informasi lebih lanjut:

Mari sambut tahun yang baru, dan web yang lebih cepat bagi semua orang! Semoga situs Anda cepat bagi pengguna dalam segala hal yang terpenting.

Foto oleh Devin Avery