Rekomendasi Data Web Inti teratas kami untuk tahun 2023

Kumpulan praktik terbaik yang menurut tim Chrome DevRel adalah cara paling efektif untuk meningkatkan performa Data Web Inti pada tahun 2023.

Brian Kenny
Brendan Kenny
X GitHub
Jeremy Wagner
Fitri Wijaya
Rick Viscomi
Pollard Barry

Selama bertahun-tahun, kami di Google telah membuat banyak rekomendasi kepada developer web tentang cara meningkatkan performa.

Meskipun setiap rekomendasi ini, satu per satu, dapat meningkatkan performa untuk banyak situs, serangkaian rekomendasi yang lengkap diakui sangat berlebihan dan, secara realistis, tidak mungkin satu orang atau situs dapat mengikuti semuanya.

Kecuali performa web adalah pekerjaan sehari-hari Anda, rekomendasi mana yang akan memberikan dampak positif terbesar pada situs Anda mungkin tidak jelas. Misalnya, Anda mungkin telah membaca bahwa menerapkan CSS penting dapat meningkatkan performa pemuatan, dan Anda mungkin juga mendengar bahwa mengoptimalkan gambar adalah hal yang penting. Tetapi, jika Anda tidak punya waktu untuk mengerjakan kedua hal tersebut, bagaimana Anda akan memutuskan mana yang akan dipilih?

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

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

Singkatnya, kami ingin fokus pada rekomendasi performa web teratas kami:

  • Rekomendasi yang kami yakini akan memberikan dampak terbesar di dunia nyata
  • Rekomendasi yang relevan dan dapat diterapkan di sebagian besar situs
  • Rekomendasi yang realistis bagi sebagian besar developer untuk diterapkan

Selama setahun terakhir, kami menghabiskan banyak waktu untuk mengaudit rangkaian lengkap rekomendasi performa yang kami buat, dan menilai setiap rekomendasi tersebut (secara kualitatif maupun kuantitatif) terhadap tiga kriteria di atas.

Postingan ini menguraikan rekomendasi terbaik kami untuk meningkatkan performa setiap metrik Data Web Inti. Jika Anda baru mengenal performa web, atau jika Anda mencoba memutuskan apa yang akan memberikan keuntungan terbesar, 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 Data Web Inti, LCP adalah salah satu masalah yang paling banyak mengalami kesulitan, dan hanya sekitar setengah dari semua situs di web yang saat ini memenuhi nilai minimum yang direkomendasikan. Jadi, mari kita mulai dari sana.

Pastikan resource LCP dapat ditemukan dari sumber HTML

Berdasarkan Web Almanac 2022 dari HTTP Archive, 72% halaman seluler memiliki gambar sebagai elemen LCP. Artinya, agar sebagian besar situs dapat mengoptimalkan LCP, situs tersebut perlu memastikan bahwa 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 tantangannya. Bagian penting lainnya adalah waktu sebelum gambar mulai dimuat, dan data Arsip HTTP menunjukkan bahwa banyak situs yang mengalami kesulitan.

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

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

Sebagai aturan umum, jika elemen LCP Anda berupa gambar, URL gambar tersebut 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 dirender, karena atribut tersebut akan selalu lebih lambat. 9% halaman menyamarkan gambar LCP 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 mengharuskan JavaScript berjalan 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">. Perlu diketahui bahwa gambar yang dirujuk oleh gaya inline tidak dapat ditemukan oleh pemindai pramuat browser, jadi meskipun gambar tersebut ditemukan di sumber HTML, penemuannya mungkin masih terhalang pada 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 (diperkirakan Januari 2023).

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

Memastikan resource LCP diprioritaskan

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

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

Cara termudah untuk mengatasi masalah ini adalah memberikan petunjuk ke browser tentang resource apa yang memiliki prioritas tertinggi dengan menyetel atribut fetchpriority="high" baru pada tag <img> atau <link> yang memuat gambar LCP Anda. Hal ini akan memerintahkan 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.Artinya, ada banyak peluang bagi sebagian besar situs di web untuk meningkatkan LCP dengan sedikit upaya. Meskipun saat ini atribut fetchpriority hanya didukung di browser berbasis Chromium, API ini merupakan progressive enhancement yang diabaikan browser lain, jadi kami sangat menyarankan developer untuk menggunakannya sekarang.

Untuk browser non-Chromium, satu-satunya cara untuk memastikan resource LCP diprioritaskan di atas resource lainnya adalah dengan mereferensikannya di awal dokumen. Dengan menggunakan kembali contoh situs dengan banyak tag <script> dalam <head> dokumen, jika ingin memastikan resource LCP 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 dalam <body>. Meskipun berhasil, metode ini kurang ergonomis dibandingkan menggunakan fetchpriority, jadi kami berharap browser lain segera menambahkan dukungan.

Aspek penting lainnya dalam memprioritaskan resource LCP adalah memastikan Anda tidak melakukan hal apa pun yang menyebabkannya terhentikan, seperti menambahkan atribut loading="lazy". Saat ini, 10% halaman benar-benar menetapkan loading="lazy" pada gambar LCP. Waspadai solusi pengoptimalan gambar yang secara acak menerapkan perilaku pemuatan lambat ke semua gambar. Jika contoh tersebut menyediakan cara untuk mengganti perilaku tersebut, pastikan Anda 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 meningkatkan prioritas relatif resource LCP secara efektif. Misalnya, skrip yang tidak mendukung antarmuka pengguna (seperti skrip analisis atau widget sosial) dapat ditunda dengan aman hingga setelah peristiwa load aktif, yang memastikan skrip tersebut tidak akan bersaing dengan resource penting lainnya (seperti resource LCP) untuk bandwidth jaringan.

Ringkasnya, Anda harus mengikuti praktik terbaik berikut untuk memastikan 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> gambar LCP. Tindakan ini akan menurunkan prioritas gambar Anda dan menunda waktu pemuatan gambar tersebut.
  • 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.

Menggunakan CDN untuk mengoptimalkan TTFB dokumen dan resource

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

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

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

  • Sediakan konten Anda sedekat mungkin dengan pengguna
  • Menyimpan konten tersebut dalam cache agar konten yang baru saja diminta dapat ditayangkan lagi dengan cepat.

Cara terbaik untuk melakukan kedua hal tersebut 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 biasanya juga memiliki kontrol caching terperinci yang dapat disesuaikan dan dioptimalkan untuk kebutuhan situs Anda.

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

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

Beberapa tips untuk mengonfigurasi CDN adalah:

  • Pertimbangkan untuk menambah berapa lama konten di-cache (misalnya, apakah sebenarnya konten harus selalu baru? Atau mungkinkah sudah tidak berlaku beberapa menit?).
  • Pertimbangkan untuk menyimpan konten dalam cache tanpa batas waktu, lalu menghapus cache jika/saat Anda melakukan update.
  • Pelajari apakah Anda dapat memindahkan logika dinamis yang saat ini berjalan di server asal ke edge (fitur di sebagian besar CDN modern).

Secara umum, kapan pun Anda dapat menayangkan konten langsung dari edge (menghindari perjalanan ke server origin), ini adalah keunggulan performa. Dan bahkan jika Anda harus melakukan perjalanan kembali ke server asal, CDN umumnya dioptimalkan untuk melakukan hal itu jauh lebih cepat, jadi ini adalah sebuah keuntungan.

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 telah meningkat banyak di web sejak tahun 2020, sekitar seperempat situs masih belum memenuhi nilai minimum yang direkomendasikan, sehingga masih ada peluang besar bagi banyak situs untuk meningkatkan pengalaman pengguna mereka.

Tetapkan ukuran eksplisit pada konten apa pun yang dimuat dari halaman

Pergeseran 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 sebanyak mungkin.

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

Penting juga untuk diingat bahwa gambar bukan satu-satunya kontributor untuk CLS. Pergeseran tata letak dapat disebabkan oleh konten lain yang biasanya dimuat setelah halaman pertama kali dirender, termasuk iklan pihak ketiga atau video yang disematkan. Properti aspect-ratio dapat membantu mengatasi hal ini. Ini adalah fitur CSS yang relatif baru yang memungkinkan developer memberikan rasio aspek secara eksplisit 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, ukuran persis konten dinamis tidak dapat diketahui karena konten dinamis pada dasarnya bersifat dinamis. Namun, meskipun tidak mengetahui ukuran persisnya, Anda masih dapat mengambil langkah untuk mengurangi tingkat keparahan pergeseran tata letak. Menyetel min-height yang logis hampir selalu lebih baik daripada mengizinkan browser menggunakan tinggi default 0px untuk elemen kosong. Penggunaan min-height juga biasanya merupakan perbaikan yang mudah karena masih memungkinkan penampung untuk tumbuh ke tinggi konten akhir jika diperlukan—ini baru saja mengurangi jumlah pertumbuhan tersebut dari jumlah penuh ke 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 langsung memuat halaman dari versi sebelumnya atau berikutnya di histori browser langsung dari snapshot memori.

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

Meskipun demikian, sejumlah besar situs tidak memenuhi syarat untuk bfcache sehingga kehilangan keunggulan performa web gratis ini untuk sejumlah besar navigasi. Jika halaman Anda tidak memuat informasi sensitif yang tidak ingin Anda pulihkan dari memori, sebaiknya pastikan halaman Anda memenuhi syarat.

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

Meskipun kami telah menyertakan bfcache di bagian CLS, seperti yang telah kami lihat sejauh ini, bfcache umumnya juga akan meningkatkan Data Web Inti lainnya. Fungsi ini adalah salah satu dari sejumlah navigasi instan yang tersedia untuk meningkatkan navigasi halaman secara drastis.

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

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

Meskipun data Arsip HTTP tidak dapat menghubungkan animasi ke pergeseran tata letak secara meyakinkan, data menunjukkan bahwa halaman yang menganimasikan properti CSS apa pun 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 dibandingkan dengan rasio halaman secara keseluruhan dianggap buruk.

Hal ini mungkin tidak mengejutkan. Setiap kali Anda mentransisikan atau menganimasikan properti CSS apa pun yang menyebabkan tata letak, hal tersebut akan menghasilkan pergeseran tata letak, dan jika pergeseran tata letak tersebut tidak berada dalam waktu 500 milidetik dari interaksi pengguna, hal tersebut akan memengaruhi CLS.

Yang mungkin mengejutkan bagi sebagian developer adalah bahwa hal ini benar meskipun elemen tersebut diambil di luar alur dokumen normal. Misalnya, elemen yang diposisikan secara mutlak 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, tindakan 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, hal 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 jika 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 yang tidak digabungkan akan memberikan peringatan saat halaman menganimasikan properti CSS yang berpotensi lambat.

Penundaan Input Pertama (FID)

Kumpulan rekomendasi terakhir kami adalah Penundaan Input Pertama (FID), yang merupakan ukuran responsivitas halaman terhadap interaksi pengguna. Meskipun sebagian besar situs di web saat ini sangat baik dalam menggunakan FID, kami telah mendokumentasikan kekurangan metrik FID di masa lalu, dan kami percaya masih banyak peluang bagi situs untuk meningkatkan responsivitasnya secara keseluruhan terhadap interaksi pengguna.

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

Menghindari atau memecah tugas yang panjang

Tugas adalah setiap pekerjaan terpisah yang dilakukan browser. Tugas ini mencakup rendering, tata letak, penguraian, serta kompilasi dan eksekusi skrip. Jika tugas menjadi tugas panjang, yaitu 50 milidetik atau lebih, thread utama tidak dapat merespons input pengguna dengan cepat.

Berdasarkan Web Almanac, ada banyak bukti yang menunjukkan bahwa developer dapat melakukan lebih banyak hal untuk menghindari atau menghentikan tugas yang berjalan lama. Meskipun membagi tugas yang panjang mungkin tidak serendah rekomendasi lain dalam artikel ini, cara ini lebih mudah dibandingkan teknik lain yang tidak ditawarkan dalam artikel ini.

Meskipun Anda harus selalu berusaha melakukan pekerjaan sesedikit mungkin di JavaScript, Anda dapat sedikit membantu thread utama dengan memecah tugas yang panjang menjadi tugas yang lebih kecil. Anda dapat melakukannya dengan sering membuat ke thread utama sehingga update rendering 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 atau tidak. Jika metode tersebut menampilkan true, Anda dapat menyerahkan ke thread utama sehingga dapat menangani input pengguna yang tertunda.

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

Dengan memecah tugas yang panjang, Anda memberi browser lebih banyak kesempatan untuk memuat pekerjaan penting yang terlihat oleh pengguna, seperti berurusan dengan interaksi dan setiap pembaruan rendering yang dihasilkan.

Menghindari JavaScript yang tidak perlu

Tidak ada keraguan tentang hal ini: situs mengirimkan lebih banyak JavaScript daripada sebelumnya, dan trennya tidak terlihat seperti berubah dalam waktu dekat. Jika Anda mengirim terlalu banyak JavaScript, Anda membuat lingkungan tempat tugas bersaing untuk 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, situs Anda dapat menghemat waktu dalam mengurai dan mengompilasi kode, sehingga pengalaman pengguna awal akan lebih lancar.
  • Terkadang kode tidak terpakai yang Anda temukan menggunakan alat cakupan ditandai sebagai "tidak digunakan" 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 menggunakan tag manager, pastikan Anda memeriksa tag secara berkala untuk memastikan tag dioptimalkan, atau bahkan jika tag tersebut masih digunakan. Tag lama dengan kode yang tidak digunakan dapat dihapus untuk membuat JavaScript Tag Manager Anda lebih kecil dan lebih efisien.

Menghindari update rendering besar

JavaScript bukan satu-satunya hal yang dapat memengaruhi responsivitas situs Anda. Rendering dapat menjadi pekerjaan yang mahal, dan jika update rendering besar terjadi, rendering 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 bisa Anda lakukan untuk memastikan update rendering Anda wajar, dan tidak menjadi tugas yang panjang:

  • Hindari penggunaan requestAnimationFrame() untuk melakukan tugas 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 update rendering.
  • Pastikan ukuran DOM Anda tetap kecil. Ukuran DOM dan intensitas pekerjaan tata letak 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 kepada 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 pekerjaan tata letak dan rendering untuk area yang tidak diperlukan.

Kesimpulan

Meningkatkan performa halaman mungkin terlihat sulit, terutama karena ada sekumpulan panduan di web yang perlu dipertimbangkan. Namun, dengan berfokus pada rekomendasi ini, Anda dapat mendekati masalah dengan fokus dan tujuan, serta diharapkan mampu meningkatkan Data Web Inti situs Anda.

Meskipun rekomendasi yang tercantum di sini sama sekali belum lengkap, kami yakin—berdasarkan analisis kondisi web yang cermat—bahwa rekomendasi ini adalah cara paling efektif bagi situs untuk meningkatkan performa Data Web Intinya pada tahun 2023.

Jika Anda ingin lebih dari sekadar rekomendasi yang tercantum di sini, lihat panduan pengoptimalan ini untuk mendapatkan informasi selengkapnya:

Mari sambut tahun baru, dan web yang lebih cepat untuk semua! Semoga situs Anda cepat bagi pengguna dalam segala cara yang paling penting.

Foto oleh Devin Avery