Mengoptimalkan Pergeseran Tata Letak Kumulatif

Pelajari cara menghindari pergeseran tata letak tiba-tiba untuk meningkatkan pengalaman pengguna

Pergeseran Tata Letak Kumulatif (CLS) adalah salah satu dari tiga metrik Data Web Inti. Hal ini mengukur ketidakstabilan konten dengan menggabungkan seberapa banyak konten terlihat yang bergeser di area pandang dengan jarak pergerakan elemen yang terpengaruh.

Pergeseran tata letak dapat mengganggu pengguna. Bayangkan Anda mulai membaca artikel ketika semua elemen tiba-tiba bergeser di sekitar halaman, membuat Anda keluar dan mengharuskan Anda menemukan posisi Anda lagi. Hal ini sangat umum di web, termasuk saat membaca berita atau mencoba mengeklik 'Telusuri' atau 'Tambahkan ke Keranjang' tombol. Pengalaman seperti itu secara visual menjengkelkan dan menjengkelkan. Error ini sering terjadi saat elemen yang terlihat terpaksa dipindahkan karena elemen lain tiba-tiba ditambahkan ke halaman atau diubah ukurannya.

Untuk memberikan pengalaman pengguna yang baik, situs harus berusaha memiliki CLS 0,1 atau kurang untuk setidaknya 75% kunjungan halaman.

Tidak seperti Core Web Vitals lainnya, yang merupakan nilai berbasis waktu yang diukur dalam detik atau milidetik, skor CLS adalah nilai tanpa unit berdasarkan penghitungan seberapa banyak konten yang berubah dan seberapa jauh.

Dalam panduan ini, kita akan membahas pengoptimalan penyebab umum pergeseran tata letak.

Penyebab paling umum CLS yang buruk adalah:

• Gambar tanpa dimensi.
• Iklan, sematan, dan iframe tanpa dimensi.
• Konten yang dimasukkan secara dinamis seperti iklan, sematan, dan iframe tanpa dimensi.
• Font web.

Memahami penyebab pergeseran tata letak

Sebelum mulai mencari solusi untuk masalah umum CLS, penting untuk memahami skor CLS Anda dan asal pergeseran.

CLS di alat lab versus kolom

Sering kali developer beranggapan bahwa CLS yang diukur oleh Chrome UX Report (CrUX) salah karena tidak cocok dengan CLS yang mereka ukur menggunakan Chrome DevTools atau alat lab lainnya. Alat lab performa web seperti Lighthouse mungkin tidak menampilkan CLS halaman sepenuhnya karena alat tersebut biasanya melakukan pemuatan sederhana halaman untuk mengukur beberapa metrik performa web dan memberikan beberapa panduan (meskipun alur pengguna Lighthouse memungkinkan Anda melakukan pengukuran di luar audit pemuatan halaman default).

CrUX adalah set data resmi program Data Web. Untuk itu, CLS diukur sepanjang masa aktif halaman, bukan hanya selama pemuatan halaman awal yang biasanya diukur oleh alat lab.

Pergeseran tata letak sangat umum selama pemuatan halaman, karena semua resource yang diperlukan diambil untuk merender halaman terlebih dahulu, tetapi pergeseran tata letak juga dapat terjadi setelah pemuatan awal. Banyak pergeseran pasca-pemuatan dapat terjadi sebagai akibat dari interaksi pengguna, sehingga akan dikecualikan dari skor CLS karena pergeseran tersebut diharapkan—selama terjadi dalam waktu 500 milidetik dari interaksi tersebut.

Namun, perubahan pasca-pemuatan lainnya yang tidak terduga oleh pengguna mungkin disertakan saat tidak ada interaksi yang memenuhi syarat—misalnya, jika Anda men-scroll lebih jauh di sepanjang halaman dan konten yang lambat dimuat, yang menyebabkan pergeseran. Penyebab umum CLS pasca-pemuatan lainnya adalah interaksi transisi, misalnya pada Aplikasi Satu Halaman, yang memerlukan waktu lebih lama dari masa tenggang 500 milidetik.

PageSpeed Insights menampilkan data yang dirasakan pengguna CLS dari URL di "Temukan apa yang dialami pengguna Anda yang sebenarnya" bagian ini, dan CLS pemuatan berbasis lab di "Mendiagnosis masalah performa" bagian. Perbedaan antara nilai-nilai ini mungkin disebabkan oleh CLS pasca-pemuatan.

Mengidentifikasi masalah CLS pemuatan

Jika skor CrUX dan Lighthouse CLS dari PageSpeed Insights diselaraskan secara luas, ini biasanya menunjukkan ada masalah CLS pemuatan yang terdeteksi oleh Lighthouse. Dalam hal ini, Lighthouse akan membantu dua audit untuk memberikan informasi selengkapnya tentang gambar yang menyebabkan CLS karena lebar dan tinggi yang tidak ada, serta mencantumkan semua elemen yang digeser untuk pemuatan halaman beserta kontribusi CLS-nya. Anda dapat melihat audit ini dengan memfilter audit CLS:

Panel Performance di DevTools juga menandai pergeseran tata letak di bagian Experience. Tampilan Ringkasan untuk data Layout Shift mencakup skor pergeseran tata letak kumulatif serta overlay persegi panjang yang menampilkan wilayah yang terpengaruh. Tindakan ini sangat membantu untuk mendapatkan detail selengkapnya tentang masalah CLS pemuatan karena mudah direplikasi dengan profil performa pemuatan ulang.

Mengidentifikasi masalah CLS pasca-pemuatan

Perbedaan antara skor CLS CrUX dan Lighthouse sering kali menunjukkan CLS pasca-pemuatan. Pergeseran ini bisa sulit untuk dilacak tanpa data lapangan. Untuk informasi tentang cara mengumpulkan data kolom, lihat Mengukur elemen CLS di kolom.

Ekstensi Chrome Web Vitals dapat digunakan untuk memantau CLS saat Anda berinteraksi dengan halaman, baik di heads-up display, atau di konsol—tempat Anda bisa mendapatkan detail selengkapnya di atas elemen yang digeser.

Sebagai alternatif menggunakan ekstensi, Anda dapat menjelajahi halaman web sambil merekam pergeseran tata letak menggunakan Performance Observer yang ditempelkan ke konsol.

Setelah menyiapkan pemantauan shift, Anda dapat mencoba mereplikasi masalah CLS pasca-pemuatan. CLS sering terjadi saat pengguna men-scroll halaman, saat konten yang dimuat dengan lambat dimuat sepenuhnya tanpa ruang yang disediakan untuknya. Pergeseran konten saat pengguna mengarahkan kursor ke konten tersebut adalah penyebab CLS pasca-pemuatan umum lainnya. Perubahan konten apa pun selama salah satu interaksi ini dianggap sebagai tidak terduga, meskipun terjadi dalam waktu 500 milidetik.

Untuk informasi selengkapnya, lihat Men-debug pergeseran tata letak.

Setelah Anda mengidentifikasi penyebab umum CLS, mode alur penggunaan rentang waktu Lighthouse juga dapat digunakan untuk memastikan alur penggunaan standar tidak mengalami regresi dengan memperkenalkan pergeseran tata letak.

Mengukur elemen CLS di kolom

Memantau CLS di kolom sangat bermanfaat dalam menentukan situasi yang terjadi saat CLS terjadi dan mempersempit kemungkinan penyebabnya. Seperti sebagian besar alat lab, alat lapangan hanya mengukur elemen-elemen yang berubah, tetapi biasanya memberikan informasi yang cukup untuk mengidentifikasi penyebabnya. Anda juga dapat menggunakan pengukuran kolom CLS untuk menentukan masalah mana yang merupakan prioritas tertinggi untuk diperbaiki.

Library web-vitals memiliki fungsi atribusi yang memungkinkan Anda mengumpulkan informasi tambahan ini. Untuk mengetahui informasi selengkapnya, lihat Performa debug di kolom. Penyedia RUM lainnya juga mulai mengumpulkan dan menyajikan data ini dengan cara yang sama.

Penyebab umum CLS

Setelah mengidentifikasi penyebab CLS, Anda dapat mulai memperbaiki masalahnya. Di bagian ini, kami akan menunjukkan beberapa alasan lebih umum untuk CLS, dan apa yang dapat Anda lakukan untuk menghindarinya.

Gambar tanpa dimensi

Selalu sertakan atribut ukuran width dan height pada elemen gambar dan video Anda. Atau, pesan ruang yang diperlukan dengan aspect-ratio CSS atau yang serupa. Pendekatan ini memastikan bahwa browser dapat mengalokasikan jumlah ruang yang benar dalam dokumen saat gambar dimuat.

Histori atribut width dan height pada gambar

Pada awal peluncuran web, developer akan menambahkan atribut width dan height ke tag <img> mereka untuk memastikan ketersediaan ruang yang cukup di halaman sebelum browser mulai mengambil gambar. Hal ini akan meminimalkan perubahan posisi/geometri dan tata letak.

<img src="puppy.jpg" width="640" height="360" alt="Puppy with balloons">

width dan height dalam contoh ini tidak menyertakan satuan. "Piksel" ini akan memastikan browser mencadangkan area 640x360 dalam tata letak halaman. Gambar akan direntangkan agar sesuai dengan ruang ini, terlepas dari apakah dimensi sebenarnya cocok dengannya.

Saat Desain Web yang Responsif diperkenalkan, developer mulai menghilangkan width dan height serta mulai menggunakan CSS untuk mengubah ukuran gambar:

img {
  width: 100%; /* or max-width: 100%; */
  height: auto;
}

Namun, karena ukuran gambar tidak ditentukan, ruang tidak dapat dialokasikan hingga browser mulai mengunduhnya dan dapat menentukan dimensinya. Saat gambar dimuat, teks bergeser ke bawah halaman untuk memberi ruang bagi gambar tersebut, sehingga menciptakan pengalaman pengguna yang membingungkan dan menjengkelkan.

Di sinilah rasio aspek berperan. Rasio aspek gambar adalah rasio lebar tinggi gambar. Hal ini umum untuk melihat ini dinyatakan sebagai dua angka yang dipisahkan oleh titik dua (misalnya, 16:9 atau 4:3). Untuk rasio aspek x:y, gambar memiliki lebar x unit dan tinggi unit y.

Artinya jika kita mengetahui salah satu dimensi, dimensi lainnya dapat ditentukan. Untuk rasio aspek 16:9:

• Jika puppy.jpg memiliki tinggi 360 piksel, lebarnya adalah 360 x (16 / 9) = 640 piksel
• Jika puppy.jpg memiliki lebar 640 piksel, tingginya adalah 640 x (9 / 16) = 360 piksel

Mengetahui rasio aspek untuk gambar memungkinkan browser menghitung dan menyediakan ruang yang cukup untuk tinggi dan area terkait.

Praktik terbaik modern untuk menyetel dimensi gambar

Karena browser modern menetapkan rasio aspek default gambar berdasarkan atribut width dan height gambar, Anda dapat mencegah pergeseran tata letak dengan menetapkan atribut tersebut pada gambar dan menyertakan CSS sebelumnya dalam lembar gaya.

<!-- set a 640:360 i.e a 16:9 aspect ratio -->
<img src="puppy.jpg" width="640" height="360" alt="Puppy with balloons">

Semua browser kemudian akan menambahkan rasio aspek default berdasarkan atribut width dan height yang sudah ada di elemen.

Fitur ini menghitung rasio aspek berdasarkan atribut width dan height sebelum gambar dimuat. Elemen ini menyediakan informasi ini pada awal penghitungan tata letak. Segera setelah gambar ditetapkan untuk memiliki lebar tertentu (misalnya, width: 100%), rasio aspek akan digunakan untuk menghitung tinggi.

Nilai aspect-ratio ini dihitung oleh browser utama saat HTML diproses, bukan dengan spreadsheet gaya Agen Pengguna default (lihat postingan ini untuk mempelajari alasannya), sehingga nilai ditampilkan sedikit berbeda. Misalnya, Chrome menampilkannya seperti ini di bagian Gaya pada panel Elemen:

img[Attributes Style] {
  aspect-ratio: auto 640 / 360;
}

Safari berperilaku serupa, menggunakan sumber gaya HTML Attributes. Firefox tidak menampilkan aspect-ratio yang dihitung ini sama sekali di panel Inspector, tetapi menggunakannya untuk tata letak.

Bagian auto dari kode sebelumnya penting, karena menyebabkan dimensi gambar mengganti rasio aspek default setelah gambar didownload. Jika dimensi gambar berbeda, hal ini masih menyebabkan beberapa pergeseran tata letak setelah gambar dimuat, tetapi hal ini memastikan rasio aspek gambar tetap digunakan saat tersedia, jika HTML salah. Meskipun rasio aspek yang sebenarnya berbeda dengan default, hal ini masih menyebabkan lebih sedikit pergeseran tata letak dibandingkan ukuran default 0x0 dari sebuah gambar tanpa dimensi yang diberikan.

Untuk memahami rasio aspek secara mendalam dengan mempertimbangkan gambar responsif secara mendalam, baca artikel pemuatan halaman bebas jank dengan rasio aspek media.

Jika gambar Anda berada dalam container, Anda dapat menggunakan CSS untuk mengubah ukuran gambar sesuai dengan lebar container. Kita menetapkan height: auto; untuk menghindari penggunaan nilai tetap untuk tinggi gambar.

img {
  height: auto;
  width: 100%;
}

Bagaimana dengan gambar responsif?

Saat bekerja dengan gambar responsif, srcset menentukan gambar yang Anda izinkan untuk dipilih oleh browser serta ukuran setiap gambar. Untuk memastikan atribut lebar dan tinggi <img> dapat ditetapkan, setiap gambar harus menggunakan rasio aspek yang sama.

<img
  width="1000"
  height="1000"
  src="puppy-1000.jpg"
  srcset="puppy-1000.jpg 1000w, puppy-2000.jpg 2000w, puppy-3000.jpg 3000w"
  alt="Puppy with balloons"
/>

Gambar Anda rasio aspek juga dapat berubah tergantung pada arah seni. Misalnya, Anda mungkin ingin menyertakan foto gambar yang dipangkas untuk area pandang, dan menampilkan gambar penuh di desktop:

<picture>
  <source media="(max-width: 799px)" srcset="puppy-480w-cropped.jpg" />
  <source media="(min-width: 800px)" srcset="puppy-800w.jpg" />
  <img src="puppy-800w.jpg" alt="Puppy with balloons" />
</picture>

Chrome, Firefox, dan Safari kini mendukung setelan width dan height di Elemen <source> dalam elemen <picture> yang diberikan:

<picture>
  <source media="(max-width: 799px)" srcset="puppy-480w-cropped.jpg" width="480" height="400" />
  <source media="(min-width: 800px)" srcset="puppy-800w.jpg" width="800" height="400" />
  <img src="puppy-800w.jpg" alt="Puppy with balloons" width="800" height="400" />
</picture>

Iklan, sematan, dan konten lain yang terlambat dimuat

Gambar bukan satu-satunya jenis konten yang dapat menyebabkan pergeseran tata letak. Iklan, sematan, iframe, dan konten yang dimasukkan secara dinamis lainnya dapat menyebabkan konten muncul setelah digeser ke bawah, sehingga meningkatkan CLS Anda.

Iklan adalah salah satu kontributor terbesar terhadap pergeseran tata letak di web. Jaringan iklan dan penayang sering mendukung ukuran iklan dinamis. Ukuran iklan meningkatkan performa/pendapatan karena rasio klik yang lebih tinggi dan lebih banyak iklan yang bersaing dalam lelang. Sayangnya, hal ini dapat menyebabkan pengalaman pengguna yang kurang optimal karena iklan mendorong konten yang terlihat yang Anda lihat ke bagian bawah halaman.

Widget yang dapat disematkan memungkinkan Anda menyertakan konten web portabel di halaman Anda, seperti video dari YouTube, peta dari Google Maps, dan postingan media sosial. Namun, widget ini sering kali tidak menyadari ukuran kontennya sebelum dimuat. Akibatnya, platform yang menawarkan sematan tidak selalu mencadangkan ruang untuk widgetnya, yang menyebabkan tata letak bergeser saat akhirnya dimuat.

Teknik untuk menanganinya semuanya serupa. Perbedaan utamanya adalah seberapa besar kontrol yang Anda miliki atas konten yang akan disisipkan. Jika teks ini disisipkan oleh pihak ketiga seperti partner iklan, Anda mungkin tidak mengetahui ukuran persis konten yang akan disisipkan, dan juga tidak dapat mengontrol pergeseran tata letak yang terjadi dalam sematan tersebut.

Sediakan ruang untuk konten yang terlambat dimuat

Saat menempatkan konten yang terlambat dimuat di alur konten, pergeseran tata letak dapat dihindari dengan menyediakan ruang untuk konten tersebut di tata letak awal.

Salah satu pendekatannya adalah menambahkan aturan CSS min-height untuk memesan ruang atau—untuk konten responsif seperti iklan, misalnya—gunakan properti CSS aspect-ratio dengan cara yang sama seperti cara browser otomatis menggunakannya untuk gambar dengan dimensi yang disediakan.

Anda mungkin perlu memperhitungkan perbedaan kecil dalam ukuran iklan atau placeholder di seluruh faktor bentuk menggunakan kueri media.

Untuk konten yang mungkin tidak memiliki tinggi tetap, seperti iklan, Anda mungkin tidak dapat mencadangkan jumlah ruang yang tepat yang diperlukan untuk menghilangkan pergeseran tata letak sepenuhnya. Jika iklan yang lebih kecil ditayangkan, penayang dapat menentukan gaya penampung yang lebih besar untuk menghindari pergeseran tata letak, atau memilih ukuran yang paling mungkin untuk slot iklan berdasarkan data historis. Kelemahan dari pendekatan ini adalah meningkatkan jumlah ruang kosong di halaman.

Sebagai gantinya, Anda dapat menyetel ukuran awal ke ukuran terkecil yang akan digunakan, dan menerima beberapa tingkat pergeseran untuk konten yang lebih besar. Menggunakan min-height, seperti yang disarankan sebelumnya, memungkinkan elemen induk tumbuh sesuai kebutuhan sekaligus mengurangi dampak pergeseran tata letak, dibandingkan dengan ukuran default 0 px elemen kosong.

Usahakan agar ruang yang dipesan tidak diciutkan dengan menampilkan placeholder, misalnya, jika tidak ada iklan yang ditampilkan. Menghapus ruang yang disisihkan untuk elemen dapat menyebabkan CLS sama pentingnya dengan memasukkan konten.

Tempatkan konten yang terlambat dimuat lebih rendah di area pandang

Konten yang dimasukkan secara dinamis lebih dekat ke bagian atas area pandang biasanya menyebabkan pergeseran tata letak lebih besar daripada konten yang dimasukkan lebih rendah di area pandang. Namun, memasukkan konten di mana saja di area pandang masih menyebabkan beberapa pergeseran. Jika Anda tidak dapat mereservasi ruang untuk konten yang dimasukkan, sebaiknya tempatkan nanti di halaman untuk mengurangi dampak CLS-nya.

Menghindari penyisipan konten baru tanpa interaksi pengguna

Anda mungkin mengalami pergeseran tata letak karena UI yang muncul di bagian atas atau bawah area pandang saat mencoba memuat situs. Serupa dengan iklan, hal ini sering terjadi pada banner dan formulir yang menggeser bagian konten halaman lainnya:

Jika Anda perlu menampilkan jenis kemampuan UI ini, cadangkan ruang yang cukup di area tampilan terlebih dahulu (misalnya, menggunakan UI placeholder atau kerangka) sehingga saat dimuat, hal ini tidak menyebabkan konten di halaman berpindah-pindah secara mengejutkan. Atau, pastikan elemen tersebut bukan bagian dari alur dokumen dengan menempatkan konten di tempat yang sesuai. Lihat postingan Praktik terbaik untuk pemberitahuan cookie untuk rekomendasi selengkapnya tentang jenis komponen ini.

Dalam beberapa kasus, menambahkan konten secara dinamis adalah bagian penting dari pengalaman pengguna. Misalnya, saat memuat lebih banyak produk ke daftar item atau saat memperbarui konten feed live. Ada beberapa cara untuk menghindari pergeseran tata letak yang tidak terduga dalam kasus tersebut:

• Ganti konten lama dengan konten baru dalam penampung ukuran tetap atau gunakan carousel dan hapus konten lama setelah transisi. Ingatlah untuk menonaktifkan semua link dan kontrol hingga transisi selesai guna mencegah klik atau ketukan yang tidak disengaja saat konten baru masuk.
• Minta pengguna memulai pemuatan konten baru, sehingga mereka tidak terkejut dengan peralihan tersebut (misalnya dengan tombol "Muat lebih banyak" atau "Muat ulang"). Sebaiknya ambil data konten sebelum interaksi pengguna agar konten segera muncul. Perlu diingat, pergeseran tata letak yang terjadi dalam waktu 500 milidetik dari input pengguna tidak akan dihitung sebagai CLS.
• Memuat konten dengan lancar di luar layar dan menempatkan pemberitahuan kepada pengguna bahwa konten tersedia (misalnya, dengan tombol "Scroll ke atas").

Animasi

Perubahan pada nilai properti CSS dapat mengharuskan browser bereaksi terhadap perubahan ini. Beberapa nilai, seperti box-shadow dan box-sizing, memicu penataan ulang, penggambaran, dan komposit. Mengubah properti top dan left juga menyebabkan pergeseran tata letak, meskipun elemen yang dipindahkan berada di lapisannya sendiri. Hindari membuat animasi menggunakan properti ini.

Properti CSS lainnya dapat diubah tanpa memicu tata letak ulang. Hal ini termasuk penggunaan animasi transform untuk menerjemahkan, menskalakan, memutar, atau memiringkan elemen.

Animasi gabungan yang menggunakan translate tidak dapat memengaruhi elemen lain, sehingga tidak dihitung dalam CLS. Animasi yang tidak digabungkan juga tidak menyebabkan tata letak ulang. Untuk mempelajari lebih lanjut properti CSS yang memicu pergeseran tata letak, lihat Animasi berperforma tinggi.

Font web

Mendownload dan merender font web biasanya ditangani dengan salah satu dari dua cara berikut sebelum font web didownload:

• Font fallback ditukar dengan font web, menimbulkan Flash of Unstyled Text (FOUT).
• "Tak terlihat" teks ditampilkan menggunakan font pengganti hingga font web tersedia dan teks menjadi terlihat (FOIT—flash teks yang tidak terlihat).

Kedua pendekatan ini dapat menyebabkan pergeseran tata letak. Meskipun tidak terlihat, teks masih ditata menggunakan font pengganti, sehingga saat font web dimuat, blok teks dan konten di sekitarnya akan bergeser dengan cara yang sama seperti font yang terlihat.

Alat berikut dapat membantu Anda meminimalkan pergeseran teks:

• font-display: optional dapat menghindari tata letak ulang karena font web hanya digunakan jika tersedia pada saat tata letak awal.
• Pastikan font penggantian yang sesuai digunakan. Misalnya, penggunaan font-family: "Google Sans", sans-serif; akan memastikan font pengganti sans-serif browser digunakan saat "Google Sans" dimuat. Tidak menentukan font penggantian hanya menggunakan font-family: "Google Sans" berarti font default akan digunakan, yang di Chrome adalah "Times"—font serif yang merupakan kecocokan yang lebih buruk daripada font sans-serif default.
• Minimalkan perbedaan ukuran antara font penggantian dan font web menggunakan API size-adjust, ascent-override, descent-override, dan line-gap-override baru seperti yang dijelaskan dalam postingan Penggantian font yang ditingkatkan.
• Font Loading API dapat mengurangi waktu yang diperlukan untuk mendapatkan font yang diperlukan.
• Muat font web yang penting sedini mungkin menggunakan <link rel=preload>. Font yang dimuat sebelumnya akan memiliki peluang lebih tinggi untuk memenuhi warna pertama, sehingga tidak ada pergeseran tata letak.

Baca Praktik terbaik untuk font guna mengetahui praktik terbaik lainnya.

Kurangi CLS dengan memastikan halaman memenuhi syarat untuk bfcache

Teknik yang sangat efektif untuk menjaga skor CLS tetap rendah adalah dengan memastikan halaman Anda memenuhi syarat untuk back/forward cache (bfcache).

Bfcache menyimpan halaman di memori browser untuk jangka waktu singkat setelah Anda menutupnya. Jadi, jika Anda membukanya kembali, halaman tersebut akan dipulihkan persis seperti yang Anda tinggalkan. Artinya, halaman yang dimuat sepenuhnya langsung tersedia—tanpa pergeseran yang mungkin biasanya terlihat selama pemuatan karena salah satu alasan yang diberikan sebelumnya.

Meskipun hal ini berpotensi masih berarti pemuatan halaman awal mengalami pergeseran tata letak, saat pengguna kembali melalui halaman, mereka tidak melihat pergeseran tata letak yang sama berulang kali. Anda harus selalu berusaha menghindari pergeseran bahkan pada pemuatan awal, tetapi jika lebih sulit untuk diselesaikan sepenuhnya, Anda setidaknya dapat mengurangi dampaknya dengan menghindarinya pada navigasi bfcache.

Navigasi mundur dan maju biasa digunakan di banyak situs. Misalnya, kembali ke halaman konten, halaman kategori, atau hasil penelusuran.

Saat diluncurkan ke Chrome, kami melihat peningkatan CLS yang signifikan.

Bfcache digunakan secara default oleh semua browser, tetapi beberapa situs tidak memenuhi syarat untuk bfcache karena berbagai alasan. Baca panduan bfcache untuk mengetahui detail selengkapnya tentang cara menguji dan mengidentifikasi masalah yang mencegah penggunaan bfcache untuk memastikan Anda memanfaatkan fitur ini sepenuhnya guna membantu keseluruhan skor CLS situs Anda.

Kesimpulan

Ada sejumlah teknik untuk mengidentifikasi dan meningkatkan CLS seperti yang dijelaskan sebelumnya dalam panduan ini. Ada kuota yang disertakan dalam Core Web Vitals, jadi meskipun Anda tidak dapat menghilangkan CLS sepenuhnya, menggunakan beberapa teknik ini akan memungkinkan Anda mengurangi dampaknya. Semoga hal ini memungkinkan Anda untuk tetap berada dalam batas tersebut, sehingga menciptakan pengalaman yang lebih baik bagi pengguna situs Anda.