Mengoptimalkan Pergeseran Tata Letak Kumulatif

Pelajari cara menghindari perubahan tata letak yang tiba-tiba untuk meningkatkan pengalaman pengguna

Addy Osmani

Barry Pollard

Dipublikasikan: 5 Mei 2020, Terakhir diperbarui: 7 Februari 2025

Pergeseran Tata Letak Kumulatif (CLS) adalah salah satu dari tiga metrik Core Web Vitals. CLS mengukur ketidakstabilan konten dengan menggabungkan seberapa banyak konten yang terlihat telah bergeser dalam area pandang dengan jarak elemen yang terpengaruh berpindah.

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

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

Nilai CLS yang baik adalah 0,1 atau kurang. Nilai buruk lebih besar dari 0,25.

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

Dalam panduan ini, kami akan membahas cara mengoptimalkan penyebab umum pergeseran tata letak.

Penyebab paling umum CLS yang buruk adalah:

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

Catatan: Untuk ringkasan visual beberapa konten yang disajikan dalam panduan ini, lihat video Mengoptimalkan untuk Metrik Web Inti dari Google I/O 2020:

Memahami penyebab pergeseran tata letak

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

CLS di alat lab versus lapangan

Sering kali developer menganggap CLS yang diukur oleh Laporan UX Chrome (CrUX) tidak akurat 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 dasar halaman untuk mengukur beberapa metrik performa web dan memberikan beberapa panduan (meskipun alur pengguna Lighthouse memungkinkan Anda mengukur di luar audit pemuatan halaman default).

CrUX adalah set data Google dari program Web Vitals, dan untuk itu, CLS diukur selama masa aktif halaman dan 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 setelah pemuatan dapat terjadi sebagai akibat dari interaksi pengguna dan oleh karena itu akan dikecualikan dari skor CLS karena merupakan pergeseran yang diharapkan—selama pergeseran tersebut terjadi dalam waktu 500 milidetik setelah interaksi tersebut.

Namun, pergeseran setelah pemuatan 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 CLS setelah pemuatan lainnya adalah interaksi transisi, misalnya di Aplikasi Halaman Tunggal, 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 "Mendiagnosis masalah performa". Perbedaan antara nilai ini kemungkinan merupakan hasil dari CLS setelah pemuatan.

Dalam contoh ini, CrUX mengukur CLS yang jauh lebih besar daripada Lighthouse.

Catatan: PageSpeed Insights akan menampilkan data tingkat URL jika ada, dan mencoba melakukan penggantian ke data tingkat asal jika tidak ada. Selalu periksa data yang ditampilkan untuk memastikan Anda tidak membuang waktu mencoba melacak masalah CLS yang sebenarnya ada di halaman lain di asal Anda. Pada contoh sebelumnya, Anda dapat melihat bahwa ini adalah data tingkat URL seperti yang ditunjukkan di kanan atas gambar.

Mengidentifikasi masalah CLS pemuatan

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

Diagnostik CLS mendetail Lighthouse.

Catatan: Lighthouse akan mengidentifikasi elemen yang bergeser, tetapi sering kali elemen ini adalah elemen yang terpengaruh, bukan elemen yang menyebabkan CLS. Misalnya, jika elemen baru dimasukkan ke dalam DOM, elemen yang berada di bawahnya akan ditampilkan dalam audit ini, tetapi penyebab utamanya adalah penambahan elemen baru di atasnya. Namun, elemen yang bergeser sudah cukup untuk membantu Anda mengidentifikasi dan mengatasi akar penyebabnya.

Panel performa di DevTools memberikan banyak informasi tentang pergeseran tata letak:

Setelah merekam rekaman aktivitas baru di panel Performance, jalur Pergeseran Tata Letak dari hasil akan diisi dengan batang ungu yang menampilkan cluster Layout Shift. Mengklik berlian akan menampilkan animasi pergeseran dan detail di panel Ringkasan.

Perubahan tata letak ditandai di jalur Perubahan tata letak. Garis ungu mengelompokkan pergeseran ke dalam cluster pergeseran dengan berlian yang menunjukkan pergeseran individual dalam cluster tersebut. Ukuran berlian sebanding dengan ukuran pergeseran sehingga Anda dapat memperkecil pergeseran terbesar.

Mengklik pergeseran akan menampilkan pop-up dengan animasi pergeseran dan menandai pergeseran elemen dengan warna ungu.

Selain itu, tampilan Ringkasan untuk rekaman Layout Shift mencakup waktu mulai, skor pergeseran, serta elemen yang bergeser. Hal ini sangat membantu untuk mendapatkan detail lebih lanjut tentang masalah CLS pemuatan karena masalah ini dapat direplikasi dengan mudah menggunakan profil performa pemuatan ulang.

Bagian ini juga ditautkan ke insight Penyebab pergeseran tata letak yang ditampilkan di panel Insight di sebelah kiri, yang menampilkan total CLS di bagian atas, serta kemungkinan alasan pergeseran tata letak.

Mengidentifikasi masalah CLS setelah pemuatan

Ketidakcocokan antara skor CLS CrUX dan Lighthouse sering kali menunjukkan CLS setelah pemuatan. Perubahan ini sulit dilacak tanpa data kolom. Untuk mengetahui informasi tentang pengumpulan data kolom, lihat Mengukur elemen CLS di lapangan.

Tampilan metrik live di Panel Performa memungkinkan Anda berinteraksi dengan halaman dan memantau skor CLS untuk mengidentifikasi interaksi yang menyebabkan pergeseran tata letak besar.

Tampilan metrik live di Panel Performa memungkinkan pemantauan skor CLS halaman web saat berinteraksi dengan halaman.

Sebagai alternatif untuk menggunakan DevTools, Anda dapat menjelajahi halaman web sambil merekam perubahan tata letak menggunakan Pengamat Performa yang ditempelkan ke konsol.

Setelah menyiapkan pemantauan pergeseran, Anda dapat mencoba mereplikasi masalah CLS pasca-pemuatan. CLS sering terjadi saat pengguna men-scroll halaman, ketika konten yang dimuat lambat dimuat sepenuhnya tanpa ruang yang dicadangkan untuknya. Pergeseran konten saat pengguna menahan kursor di atasnya adalah penyebab umum CLS setelah pemuatan 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 pengguna rentang waktu Lighthouse juga dapat digunakan untuk memastikan alur pengguna umum tidak mengalami regresi dengan memperkenalkan pergeseran tata letak.

Mengukur elemen CLS di lapangan

Memantau CLS di lapangan dapat sangat berharga dalam menentukan keadaan terjadinya CLS dan mempersempit kemungkinan penyebabnya. Seperti kebanyakan alat lab, alat lapangan hanya mengukur elemen yang berubah, tetapi biasanya memberikan informasi yang cukup untuk mengidentifikasi penyebabnya. Anda juga dapat menggunakan pengukuran kolom CLS untuk menentukan masalah mana yang menjadi prioritas tertinggi untuk diperbaiki.

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

Catatan: Solusi RUM yang mengukur CLS di lapangan, termasuk library web-vitals, dapat menunjukkan perbedaan dengan data CrUX seperti yang dijelaskan dalam postingan Mengapa data CrUX berbeda dengan data RUM saya?. Secara khusus, CLS yang terjadi di iframe tidak dapat diukur dari Web API, tetapi terlihat oleh pengguna, dan oleh karena itu disertakan dalam CrUX. Jadi, meskipun data kolom sangat berharga untuk mengidentifikasi masalah CLS, perlu diketahui bahwa data tersebut mungkin tidak lengkap dalam skenario tertentu.

Penyebab umum CLS

Setelah mengidentifikasi penyebab CLS, Anda dapat mulai memperbaiki masalahnya. Di bagian ini, kami akan menunjukkan beberapa alasan umum terjadinya CLS, 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, cadangkan ruang yang diperlukan dengan CSS aspect-ratio atau yang serupa. Pendekatan ini memastikan bahwa browser dapat mengalokasikan jumlah ruang yang tepat dalam dokumen saat gambar dimuat.

Gambar tanpa lebar dan tinggi yang ditentukan.

Gambar dengan lebar dan tinggi yang ditentukan.

Dampak Lighthouse 6.0 dari menyetel dimensi gambar pada CLS.

Histori atribut width dan height pada gambar

Pada awal kemunculan 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 penyesuaian ulang dan tata letak ulang.

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

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

Saat Desain Web 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 untuk gambar tersebut 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 antara lebar dan tingginya. Rasio aspek biasanya 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, lebar adalah 360 x (16 / 9) = 640 piksel
• Jika puppy.jpg memiliki lebar 640 piksel, tinggi adalah 640 x (9 / 16) = 360 piksel

Dengan mengetahui rasio aspek gambar, browser dapat menghitung dan mencadangkan 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 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 elemen yang ada.

Hal ini menghitung rasio aspek berdasarkan atribut width dan height sebelum gambar dimuat. Informasi ini diberikan di awal perhitungan tata letak. Segera setelah gambar diberi tahu untuk memiliki lebar tertentu (misalnya width: 100%), rasio aspek digunakan untuk menghitung tinggi.

Nilai aspect-ratio ini dihitung oleh browser utama saat HTML diproses, bukan dengan stylesheet Agen Pengguna default (lihat postingan ini untuk mengetahui alasan mendalamnya), sehingga nilai ditampilkan sedikit berbeda. Misalnya, Chrome menampilkannya seperti ini di bagian Styles pada panel Element:

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 Pemeriksa, tetapi menggunakannya untuk tata letak.

Bagian auto dari kode sebelumnya penting, karena menyebabkan dimensi gambar menggantikan 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 sebenarnya berbeda dari default, rasio ini tetap menyebabkan pergeseran tata letak yang lebih sedikit daripada ukuran default 0x0 gambar tanpa dimensi yang diberikan.

Tips: Jika Anda kesulitan memahami rasio aspek, kalkulator praktis tersedia untuk membantu.

Untuk mempelajari rasio aspek secara mendalam dan lebih lanjut tentang gambar responsif, lihat pemuatan halaman bebas jank dengan rasio aspek media.

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

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

Bagaimana dengan gambar responsif?

Saat menggunakan gambar responsif, srcset menentukan gambar yang Anda izinkan untuk dipilih oleh 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 Anda juga dapat berubah bergantung pada arah artistik Anda. Misalnya, Anda dapat menyertakan gambar yang dipangkas untuk area tampilan 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 lain yang dimuat terlambat

Gambar bukan satu-satunya jenis konten yang dapat menyebabkan perubahan tata letak. Iklan, sematan, iframe, dan konten lain yang disisipkan 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 mendukung ukuran iklan dinamis. Ukuran iklan meningkatkan performa dan pendapatan karena rasio klik yang lebih tinggi dan lebih banyak iklan yang bersaing dalam lelang. Sayangnya, hal ini dapat menyebabkan pengalaman pengguna yang tidak optimal karena iklan mendorong konten yang terlihat yang Anda lihat ke 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 mengetahui seberapa besar kontennya sebelum dimuat. Akibatnya, platform yang menawarkan sematan tidak selalu mencadangkan ruang untuk widgetnya, yang menyebabkan pergeseran tata letak saat widget akhirnya dimuat.

Teknik untuk menanganinya semuanya serupa. Perbedaan utamanya adalah seberapa besar kontrol yang Anda miliki atas konten yang akan disisipkan. Jika ini 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 sematan tersebut.

Menyediakan ruang untuk konten yang dimuat terlambat

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

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

Memesan ruang untuk iklan dapat mencegah pergeseran tata letak

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 memesan jumlah ruang yang tepat yang diperlukan untuk menghilangkan pergeseran tata letak sepenuhnya. Jika iklan yang lebih kecil ditayangkan, penayang dapat menata gaya penampung yang lebih besar untuk menghindari perubahan tata letak, atau memilih ukuran yang paling mungkin untuk slot iklan berdasarkan data historis. Kelemahan dari pendekatan ini adalah bertambahnya 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 bertambah sesuai kebutuhan sekaligus mengurangi dampak perubahan tata letak, dibandingkan dengan ukuran default 0 px dari elemen kosong.

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

Tempatkan konten yang dimuat terlambat lebih rendah di area pandang

Konten yang disisipkan secara dinamis di dekat bagian atas area tampilan biasanya menyebabkan pergeseran tata letak yang lebih besar daripada konten yang disisipkan di bagian bawah area tampilan. Namun, menyisipkan konten di mana pun di area pandang masih menyebabkan beberapa pergeseran. Jika Anda tidak dapat mencadangkan ruang untuk konten yang disisipkan, sebaiknya tempatkan konten tersebut di bagian bawah halaman untuk mengurangi dampaknya pada 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 tampilan saat Anda mencoba memuat situs. Mirip dengan iklan, hal ini sering terjadi pada banner dan formulir yang menggeser konten halaman lainnya:

Konten dinamis tanpa ruang yang dicadangkan.

Jika Anda perlu menampilkan jenis afordans UI ini, sediakan ruang yang cukup di area tampilan untuknya terlebih dahulu (misalnya, menggunakan placeholder atau UI kerangka) sehingga saat dimuat, afordans tersebut tidak menyebabkan konten di halaman bergeser secara tiba-tiba. Atau, pastikan elemen bukan bagian dari alur dokumen dengan menempatkan konten di tempat yang sesuai. Lihat postingan Praktik terbaik untuk pemberitahuan cookie untuk mengetahui rekomendasi lainnya 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 aktif. 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 memulai pemuatan konten baru, sehingga mereka tidak terkejut dengan perubahan tersebut (misalnya dengan tombol "Muat lebih banyak" atau "Muat ulang"). Sebaiknya lakukan pengambilan data konten terlebih dahulu sebelum interaksi pengguna sehingga konten muncul dengan segera. Sebagai pengingat, pergeseran tata letak yang terjadi dalam waktu 500 milidetik setelah input pengguna tidak dihitung dalam CLS.
• Muat konten di luar layar dengan lancar dan tampilkan notifikasi kepada pengguna bahwa konten tersebut tersedia (misalnya, dengan tombol "Scroll ke atas").

Contoh pemuatan konten dinamis tanpa menyebabkan perubahan tata letak yang tidak terduga. Kiri: Konten feed live dimuat di Twitter. Kanan: Contoh "Muat Lebih Banyak" di situs Chloé. Lihat cara tim YNAP mengoptimalkan CLS saat memuat lebih banyak konten.

Catatan: Jika konten kemungkinan memerlukan waktu lebih dari 500 milidetik—misalnya, memerlukan pengambilan data jaringan—maka mencadangkan ruang yang diharapkan dalam jangka waktu 500 milidetik tersebut dan memperhitungkan dampak pergeseran di masa mendatang sejak awal akan memastikan bahwa pergeseran tidak akan disertakan dalam skor CLS.

Animasi

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

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

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

Font web

Download dan rendering font web biasanya ditangani dengan salah satu dari dua cara sebelum font web didownload:

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

Kedua pendekatan dapat menyebabkan perubahan tata letak. Meskipun teks tidak terlihat, teks tersebut 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 ulang karena font web hanya digunakan jika tersedia pada saat tata letak awal.
• Pastikan font pengganti yang sesuai digunakan. Misalnya, menggunakan font-family: "Google Sans", sans-serif; akan memastikan font penggantian sans-serif browser digunakan saat "Google Sans" dimuat. Tidak menentukan font pengganti hanya dengan menggunakan font-family: "Google Sans" akan berarti font default digunakan, yang di Chrome adalah "Times"—font serif yang tidak cocok dengan font sans-serif default.
• Minimalkan perbedaan ukuran antara font pengganti dan font web menggunakan API size-adjust, ascent-override, descent-override, dan line-gap-override baru seperti yang dijelaskan dalam postingan Peningkatan font pengganti.
• 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 sudah dimuat sebelumnya akan memiliki peluang lebih tinggi untuk memenuhi paint 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 memastikan halaman web Anda memenuhi syarat untuk cache kembali/maju (bfcache).

Bfcache menyimpan halaman di memori browser untuk jangka waktu singkat setelah Anda keluar dari halaman tersebut. Jadi, jika Anda kembali ke halaman tersebut, halaman akan dipulihkan persis seperti saat Anda meninggalkannya. Artinya, halaman yang dimuat sepenuhnya langsung tersedia—tanpa pergeseran yang 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 ke halaman, mereka tidak akan melihat pergeseran tata letak yang sama berulang kali. Anda harus selalu berupaya menghindari pergeseran bahkan pada pemuatan awal, tetapi jika hal itu lebih sulit diselesaikan sepenuhnya, Anda setidaknya dapat mengurangi dampaknya dengan menghindarinya pada navigasi bfcache.

Navigasi mundur dan maju adalah hal yang umum di banyak situs. Misalnya, kembali ke halaman daftar isi, atau 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 guna memastikan Anda memanfaatkan fitur ini sepenuhnya untuk membantu skor CLS keseluruhan situs Anda.

Kesimpulan

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