Mengoptimalkan Pergeseran Tata Letak Kumulatif

Pelajari cara menghindari perubahan tata letak mendadak untuk meningkatkan pengalaman pengguna

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

Pergeseran tata letak dapat mengganggu pengguna. Bayangkan Anda mulai membaca artikel, lalu tiba-tiba elemen di halaman bergeser, sehingga Anda kehilangan fokus dan harus mencari lagi bagian yang terakhir dibaca. Hal ini sangat umum terjadi di web, termasuk saat membaca berita, atau mencoba mengklik tombol 'Telusuri' atau 'Tambahkan ke Keranjang'. Pengalaman seperti itu secara visual mengganggu dan membuat frustrasi. Hal ini sering kali terjadi saat elemen yang terlihat dipaksa untuk berpindah karena elemen lain tiba-tiba ditambahkan ke halaman atau diubah ukurannya.

Untuk memberikan pengalaman pengguna yang baik, situs harus mengusahakan agar CLS-nya 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 satuan berdasarkan penghitungan jumlah konten yang bergeser dan seberapa jauh.

Dalam panduan ini, kami akan membahas cara mengoptimalkan penyebab umum perubahan 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, penyematan, dan iframe tanpa dimensi.
• Font web.

Memahami penyebab pergeseran tata letak

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

CLS di alat lab versus di lapangan

Developer sering kali menganggap CLS yang diukur oleh Laporan UX Chrome (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 lengkap halaman karena biasanya melakukan pemuatan halaman sederhana untuk mengukur beberapa metrik performa web dan memberikan beberapa panduan (meskipun alur penggunaan Lighthouse memungkinkan Anda mengukur di luar audit pemuatan halaman default).

CrUX adalah set data resmi program Data Web, dan untuk itu, CLS diukur selama siklus proses halaman penuh, bukan hanya selama pemuatan halaman awal yang biasanya diukur oleh alat lab.

Pergeseran tata letak sangat umum terjadi selama pemuatan halaman, karena semua resource yang diperlukan diambil untuk merender halaman pada awalnya, tetapi pergeseran tata letak juga dapat terjadi setelah pemuatan awal. Banyak pergeseran pasca-muat yang dapat terjadi sebagai hasil dari interaksi pengguna dan oleh karena itu akan dikecualikan dari skor CLS karena merupakan pergeseran yang diharapkan—asalkan terjadi dalam waktu 500 milidetik setelah interaksi tersebut.

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

PageSpeed Insights menampilkan CLS yang dirasakan pengguna dari URL di bagian "Temukan pengalaman pengguna sebenarnya", dan CLS pemuatan berbasis lab di bagian "Diagnosa masalah performa". Perbedaan antara nilai ini kemungkinan merupakan hasil dari CLS pasca-muat.

Mengidentifikasi masalah CLS pemuatan

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

Panel Performa di DevTools juga menyoroti pergeseran tata letak di bagian Pengalaman. Tampilan Ringkasan untuk kumpulan data Layout Shift menyertakan skor pergeseran tata letak kumulatif serta overlay persegi panjang yang menampilkan area yang terpengaruh. Hal ini sangat membantu untuk mendapatkan detail selengkapnya tentang masalah CLS pemuatan karena mudah direplikasi dengan profil performa pemuatan ulang.

Mengidentifikasi masalah CLS pasca-muat

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

Ekstensi Chrome Data Vital Web dapat digunakan untuk memantau CLS saat Anda berinteraksi dengan halaman, baik di heads up display, maupun di konsol—tempat Anda dapat mendapatkan detail selengkapnya di atas elemen yang bergeser.

Sebagai alternatif penggunaan ekstensi, Anda dapat menjelajahi halaman web sambil mencatat perubahan tata letak menggunakan Performance Observer yang disisipkan ke konsol.

Setelah menyiapkan pemantauan pergeseran, Anda dapat mencoba mereplikasi masalah CLS pasca-muat. CLS sering terjadi saat pengguna men-scroll halaman, ketika konten yang dimuat lambat dimuat sepenuhnya tanpa ruang yang disediakan untuknya. Konten yang bergeser saat pengguna mengarahkan kursor ke atasnya adalah penyebab CLS pasca-muat umum lainnya. Setiap pergeseran konten selama salah satu interaksi ini dihitung sebagai tidak terduga, meskipun terjadi dalam waktu 500 milidetik.

Untuk mengetahui 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 lapangan

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

Library web-vitals memiliki fungsi atribusi yang memungkinkan Anda mengumpulkan informasi tambahan ini. Untuk mengetahui informasi selengkapnya, lihat Melakukan proses debug performa di lapangan. 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 menampilkan beberapa alasan CLS yang lebih umum, dan tindakan yang dapat Anda lakukan untuk menghindarinya.

Gambar tanpa dimensi

Selalu sertakan atribut ukuran width dan height pada elemen gambar dan video Anda. Atau, siapkan ruang yang diperlukan dengan CSS aspect-ratio 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 web, developer akan menambahkan atribut width dan height ke tag <img> untuk memastikan ruang yang cukup dialokasikan di halaman sebelum browser mulai mengambil gambar. Hal ini akan meminimalkan reflow dan tata letak ulang.

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

width dan height dalam contoh ini tidak menyertakan unit. Dimensi "piksel" ini akan memastikan bahwa browser mencadangkan area 640x360 di tata letak halaman. Gambar akan diregangkan agar sesuai dengan ruang ini, terlepas dari apakah dimensi sebenarnya cocok dengan ruang tersebut.

Saat Desain Web Responsif diperkenalkan, developer mulai menghilangkan width dan height dan 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 untuknya hingga browser mulai mendownloadnya dan dapat menentukan dimensinya. Saat gambar dimuat, teks bergeser ke bawah halaman untuk memberi ruang bagi gambar, sehingga menciptakan pengalaman pengguna yang membingungkan dan menjengkelkan.

Di sinilah rasio aspek berperan. Rasio aspek gambar adalah rasio lebar dan tingginya. Biasanya, rasio aspek 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 y unit.

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

Dengan mengetahui rasio aspek untuk gambar, browser dapat menghitung dan menyediakan ruang yang memadai untuk tinggi dan area terkait.

Praktik terbaik modern untuk menetapkan 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 di lembar gaya Anda.

<!-- 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 ada pada elemen.

Tindakan ini akan menghitung rasio aspek berdasarkan atribut width dan height sebelum gambar dimuat. Metode ini memberikan informasi ini di awal penghitungan tata letak. Segera setelah gambar diberi tahu untuk memiliki lebar tertentu (misalnya width: 100%), rasio aspek akan digunakan untuk menghitung tingginya.

Nilai aspect-ratio ini dihitung oleh browser utama saat HTML diproses, bukan dengan sheet gaya Agen Pengguna default (lihat postingan ini untuk mengetahui alasannya secara mendalam), sehingga nilainya ditampilkan dengan sedikit perbedaan. 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 Atribut HTML. 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 masih digunakan saat tersedia, jika HTML salah. Meskipun rasio aspek yang sebenarnya berbeda dengan default, rasio aspek tersebut masih menyebabkan lebih sedikit pergeseran tata letak daripada ukuran default 0x0 gambar tanpa dimensi yang diberikan.

Untuk pembahasan mendalam yang fantastis tentang rasio aspek dengan pemikiran lebih lanjut tentang gambar responsif, lihat pemuatan halaman bebas jank dengan rasio aspek media.

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

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

Bagaimana dengan gambar responsif?

Saat menangani gambar responsif, srcset menentukan gambar yang Anda izinkan untuk dipilih browser dan 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"
/>

Rasio aspek gambar juga dapat berubah bergantung pada arah seni Anda. Misalnya, Anda mungkin ingin menyertakan gambar yang dipangkas untuk area pandang yang sempit, dan menampilkan gambar lengkap 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 pada elemen <source> dalam elemen <picture> tertentu:

<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 lainnya yang dimuat terlambat

Gambar bukan satu-satunya jenis konten yang dapat menyebabkan perubahan tata letak. Iklan, penyematan, iframe, dan konten lain yang dimasukkan secara dinamis dapat menyebabkan konten yang muncul setelahnya bergeser ke bawah, sehingga meningkatkan CLS Anda.

Iklan adalah salah satu kontributor terbesar pergeseran tata letak di web. Jaringan iklan dan penayang sering kali 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, seperti video dari YouTube, peta dari Google Maps, dan postingan media sosial. Namun, widget ini sering kali tidak mengetahui seberapa besar kontennya sebelum dimuat. Akibatnya, platform yang menawarkan penyematan tidak selalu menyediakan ruang untuk widgetnya, yang menyebabkan pergeseran tata letak saat akhirnya dimuat.

Teknik untuk menanganinya semuanya serupa. Perbedaan utamanya adalah seberapa banyak kontrol yang Anda miliki atas konten yang akan disisipkan. Jika konten tersebut disisipkan oleh pihak ketiga seperti partner iklan, Anda mungkin tidak mengetahui ukuran pasti konten yang akan disisipkan, atau tidak dapat mengontrol perubahan tata letak yang terjadi dalam penyematan tersebut.

Menyiapkan ruang untuk konten yang dimuat terlambat

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

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

Anda mungkin perlu memperhitungkan perbedaan kecil dalam ukuran iklan atau placeholder di berbagai 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 ditayangkan berukuran lebih kecil, penayang dapat menata 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 menetapkan ukuran awal ke ukuran terkecil yang akan digunakan, dan menerima beberapa tingkat pergeseran untuk konten yang lebih besar. Penggunaan min-height, seperti yang disarankan sebelumnya, memungkinkan elemen induk berkembang sesuai kebutuhan sekaligus mengurangi dampak pergeseran tata letak, dibandingkan dengan ukuran default 0 piksel dari elemen kosong.

Cobalah untuk tidak menciutkan ruang yang dicadangkan dengan menampilkan placeholder jika, misalnya, tidak ada iklan yang ditampilkan. Menghapus ruang yang disediakan untuk elemen dapat menyebabkan CLS sebanyak menyisipkan konten.

Menempatkan konten yang lambat dimuat lebih rendah di area pandang

Konten yang dimasukkan secara dinamis lebih dekat ke bagian atas area pandang biasanya menyebabkan pergeseran tata letak yang 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 mencadangkan ruang untuk konten yang dimasukkan, sebaiknya tempatkan konten tersebut di halaman nanti untuk mengurangi dampaknya terhadap CLS.

Menghindari penyisipan konten baru tanpa interaksi pengguna

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

Jika Anda perlu menampilkan jenis kemampuan UI ini, siapkan ruang yang memadai di area pandang terlebih dahulu (misalnya, menggunakan placeholder atau UI kerangka) sehingga saat dimuat, konten di halaman tidak akan bergeser secara tiba-tiba. Atau, pastikan elemen tersebut bukan bagian dari alur dokumen dengan menempatkan konten di tempat yang sesuai. Lihat postingan Praktik terbaik untuk pemberitahuan cookie untuk mengetahui 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 berukuran tetap atau gunakan carousel dan hapus konten lama setelah transisi. Jangan lupa untuk menonaktifkan link dan kontrol apa pun hingga transisi selesai untuk mencegah klik atau ketukan yang tidak disengaja saat konten baru masuk.
• Minta pengguna untuk memulai pemuatan konten baru, sehingga mereka tidak terkejut dengan pergeseran (misalnya dengan tombol "Muat lainnya" atau "Muat ulang"). Sebaiknya lakukan pengambilan data sebelumnya pada konten sebelum interaksi pengguna sehingga konten akan langsung muncul. Sebagai pengingat, perubahan tata letak yang terjadi dalam waktu 500 milidetik setelah input pengguna tidak dihitung dalam CLS.
• Muat konten secara lancar di luar layar dan tampilkan pemberitahuan kepada pengguna bahwa konten tersebut 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 tata letak ulang, gambar, dan gabungan. Mengubah properti top dan left juga menyebabkan pergeseran tata letak, meskipun elemen yang dipindahkan berada di lapisannya sendiri. Hindari menganimasikan menggunakan properti ini.

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

Animasi gabungan yang menggunakan translate tidak dapat memengaruhi elemen lain, sehingga tidak diperhitungkan 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 sebelum font web didownload:

• Font pengganti ditukar dengan font web, sehingga menyebabkan Flash of Unstyled Text (FOUT).
• Teks "Tidak terlihat" ditampilkan menggunakan font penggantian hingga font web tersedia dan teks tersebut terlihat (FOIT—flash of invisible text).

Kedua pendekatan tersebut dapat menyebabkan perubahan tata letak. Meskipun tidak terlihat, teks tetap ditata menggunakan font pengganti, sehingga saat font web dimuat, blok teks dan konten di sekitarnya akan bergeser dengan cara yang sama seperti untuk 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 penggantian sans-serif browser digunakan saat "Google Sans" dimuat. Jika tidak menentukan font pengganti hanya menggunakan font-family: "Google Sans", berarti font default akan digunakan, yang di Chrome adalah "Times"—font serif yang kecocokannya 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 penting sedini mungkin menggunakan <link rel=preload>. Font yang dimuat sebelumnya akan memiliki peluang lebih tinggi untuk memenuhi gambar pertama, sehingga tidak ada pergeseran tata letak.

Baca Praktik terbaik untuk font untuk praktik terbaik font lainnya.

Mengurangi CLS dengan memastikan halaman memenuhi syarat untuk bfcache

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

BFcache menyimpan halaman di memori browser selama jangka waktu singkat setelah Anda beralih ke halaman lain. Jadi, jika Anda kembali ke halaman tersebut, halaman tersebut akan dipulihkan persis seperti saat Anda meninggalkannya. Artinya, halaman yang dimuat sepenuhnya akan langsung tersedia—tanpa pergeseran yang biasanya terlihat selama pemuatan karena alasan apa pun yang diberikan sebelumnya.

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

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

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

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 skor CLS situs Anda secara keseluruhan.

Kesimpulan

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