Pergeseran tata letak yang tidak terduga dapat mengganggu pengalaman pengguna dengan berbagai cara, mulai dari menyebabkan mereka kehilangan posisi saat membaca jika teks tiba-tiba berpindah, hingga membuat mereka mengklik link atau tombol yang salah. Dalam beberapa kasus, hal ini dapat menyebabkan kerusakan serius.
Pergerakan konten halaman yang tidak terduga biasanya terjadi saat resource dimuat secara asinkron atau elemen DOM ditambahkan secara dinamis ke halaman sebelum konten yang ada. Penyebab pergeseran tata letak dapat berupa gambar atau video dengan dimensi yang tidak diketahui, font yang dirender lebih besar atau lebih kecil daripada penggantian awalnya, atau iklan atau widget pihak ketiga yang ukurannya sendiri secara dinamis.
Perbedaan antara fungsi situs dalam pengembangan dan pengalaman penggunanya akan memperburuk masalah ini. Contoh:
- Konten yang dipersonalisasi atau konten pihak ketiga sering kali berperilaku berbeda dalam pengembangan dan produksi.
- Image pengujian sering kali sudah ada di cache browser developer, tetapi memerlukan waktu lebih lama untuk dimuat oleh pengguna akhir.
- Panggilan API yang berjalan secara lokal sering kali sangat cepat sehingga penundaan pengembangan yang tidak terlihat dapat menjadi substansial dalam produksi.
Metrik Pergeseran Tata Letak Kumulatif (CLS) membantu Anda mengatasi masalah ini dengan mengukur seberapa sering terjadi untuk pengguna nyata.
Apa itu CLS?
CLS adalah ukuran burst skor pergeseran tata letak terbesar untuk setiap pergeseran tata letak yang tidak terduga yang terjadi selama seluruh siklus proses halaman.
Pergeseran tata letak terjadi setiap kali elemen yang terlihat mengubah posisinya dari satu frame yang dirender ke frame berikutnya. (Detail tentang cara penghitungan skor pergeseran tata letak individual akan dibahas nanti dalam panduan ini.)
burst pergeseran tata letak, yang dikenal sebagai jendela sesi, adalah saat satu atau beberapa pergeseran tata letak individual terjadi secara berurutan dengan waktu kurang dari 1 detik di antara setiap pergeseran dan maksimum 5 detik untuk total durasi periode.
burst terbesar adalah jendela sesi dengan skor kumulatif maksimum dari semua pergeseran tata letak dalam periode tersebut.
Berapa skor CLS yang baik?
Untuk memberikan pengalaman pengguna yang baik, situs harus berupaya memiliki skor CLS sebesar 0,1 atau kurang. Guna memastikan Anda mencapai target ini untuk sebagian besar pengguna, nilai minimum yang baik untuk diukur adalah persentil ke-75 pemuatan halaman, yang tersegmentasi di seluruh perangkat seluler dan desktop.
Untuk mempelajari lebih lanjut penelitian dan metodologi di balik rekomendasi ini, lihat Menentukan nilai minimum metrik Data Web Inti.
Pergeseran tata letak secara mendetail
Pergeseran tata letak ditentukan oleh Layout Instability API, yang melaporkan entri layout-shift setiap kali elemen yang terlihat dalam area pandang mengubah posisi awalnya (misalnya, posisi atas dan kirinya dalam mode penulisan default) di antara dua frame. Elemen semacam itu dianggap sebagai elemen yang tidak stabil.
Perhatikan bahwa pergeseran tata letak hanya terjadi saat elemen yang ada mengubah posisi awalnya. Jika elemen baru ditambahkan ke DOM atau elemen yang ada mengubah ukuran, elemen tersebut tidak dianggap sebagai pergeseran tata letak—selama perubahan tersebut tidak menyebabkan elemen lain yang terlihat mengubah posisi awalnya.
Skor pergeseran tata letak
Untuk menghitung skor pergeseran tata letak, browser melihat ukuran area pandang dan pergerakan elemen yang tidak stabil di area pandang di antara dua frame yang dirender. Skor pergeseran tata letak adalah hasil kali dua ukuran gerakan tersebut: fraksi dampak dan fraksi jarak (keduanya didefinisikan di bawah ini).
layout shift score = impact fraction * distance fraction
Fraksi dampak
Faksi dampak mengukur bagaimana elemen yang tidak stabil memengaruhi area area pandang di antara dua frame.
Pecahan dampak untuk bingkai tertentu adalah kombinasi area yang terlihat dari semua elemen yang tidak stabil untuk bingkai tersebut dan bingkai sebelumnya, sebagai pecahan dari total area area pandang.
Pada gambar sebelumnya, ada elemen yang menempati setengah area pandang dalam satu bingkai. Kemudian, di frame berikutnya, elemen bergeser ke bawah sebesar 25% dari tinggi area pandang. Persegi panjang putus-putus berwarna merah menunjukkan gabungan area yang terlihat dari elemen di kedua bingkai, yang dalam hal ini adalah 75% dari total area pandang, sehingga fraksi dampaknya adalah 0.75.
Fraksi jarak
Bagian lain dari persamaan skor pergeseran tata letak mengukur jarak yang dipindahkan elemen yang tidak stabil secara relatif terhadap area pandang. fraksi jarak adalah jarak horizontal atau vertikal terbesar yang dipindahkan oleh elemen tidak stabil dalam bingkai yang dibagi dengan dimensi terbesar area pandang (lebar atau tinggi, mana saja yang lebih besar).
Pada contoh sebelumnya, dimensi area pandang terbesar adalah tinggi, dan elemen yang tidak stabil telah dipindahkan sebesar 25% dari tinggi area pandang, sehingga fraksi jarak menjadi 0,25.
Jadi, dalam contoh ini fraksi dampak adalah 0.75 dan fraksi jarak adalah 0.25, sehingga skor pergeseran tata letak adalah 0.75 * 0.25 = 0.1875.
Contoh
Contoh berikutnya mengilustrasikan bagaimana menambahkan konten ke elemen yang ada memengaruhi skor pergeseran tata letak:
Dalam contoh ini, kotak abu-abu berubah ukuran, tetapi posisi awalnya tidak berubah sehingga bukan merupakan elemen yang tidak stabil.
Tombol "Click Me!" sebelumnya tidak ada di DOM, jadi posisi awalnya juga tidak berubah.
Namun, posisi awal kotak hijau berubah, tetapi karena dipindahkan sebagian dari area pandang, area yang tidak terlihat tidak dipertimbangkan saat menghitung fraksi dampak. Penyatuan area yang terlihat untuk kotak hijau di kedua bingkai (diilustrasikan dengan persegi panjang bertitik merah) sama dengan area kotak hijau di bingkai pertama—50% dari area pandang. Faksi dampak adalah 0.5.
fraksi jarak diilustrasikan dengan panah ungu. Kotak hijau telah dipindahkan ke bawah sekitar 14% dari area pandang sehingga fraksi jarak adalah 0.14.
Skor pergeseran tata letak adalah 0.5 x 0.14 = 0.07.
Contoh berikut menunjukkan bagaimana beberapa elemen yang tidak stabil memengaruhi skor pergeseran tata letak halaman:
Di bingkai pertama di gambar sebelumnya, ada empat hasil permintaan API untuk hewan, yang diurutkan dalam urutan abjad. Di frame kedua, lebih banyak hasil ditambahkan ke daftar yang diurutkan.
Item pertama dalam daftar ("Kucing") tidak mengubah posisi awalnya di antara bingkai, sehingga stabil. Demikian pula, item baru yang ditambahkan ke daftar sebelumnya tidak ada di DOM, jadi posisi awalnya juga tidak berubah. Namun, item berlabel "", "Kuda", dan "Zebra" mengubah posisi awal mereka, sehingga menjadikannya elemen yang tidak stabil.
Sekali lagi, persegi panjang bertitik merah mewakili gabungan dari tiga elemen tidak stabil' sebelum dan sesudah area ini, yang dalam hal ini sekitar 60% dari area area pandang (fraksi dampak 0.60).
Tanda panah mewakili jarak yang telah dipindahkan elemen yang tidak stabil dari posisi awalnya. Elemen "Zebra", yang diwakili oleh panah biru, telah berpindah paling banyak, sekitar 30% dari tinggi area pandang. Hal tersebut membuat fraksi jarak dalam contoh ini adalah 0.3.
Skor pergeseran tata letak adalah 0.60 x 0.3 = 0.18.
Pergeseran tata letak yang diharapkan versus yang tidak diharapkan
Tidak semua pergeseran tata letak buruk. Faktanya, banyak aplikasi web dinamis sering mengubah posisi awal elemen di halaman. Pergeseran tata letak hanya buruk jika pengguna tidak mengharapkannya.
Pergeseran tata letak yang dimulai pengguna
Pergeseran tata letak yang terjadi sebagai respons terhadap interaksi pengguna (seperti mengklik atau mengetuk link, menekan tombol, atau mengetik di kotak penelusuran) umumnya tidak masalah, selama pergeseran terjadi cukup dekat dengan interaksi sehingga hubungan tersebut jelas bagi pengguna.
Misalnya, jika interaksi pengguna memicu permintaan jaringan yang mungkin memerlukan waktu beberapa saat untuk diselesaikan, yang terbaik adalah segera membuat beberapa ruang dan menampilkan indikator pemuatan untuk menghindari pergeseran tata letak yang tidak menyenangkan ketika permintaan selesai. Jika pengguna tidak menyadari sesuatu sedang dimuat, atau tidak mengetahui kapan sumber daya akan siap, mereka mungkin mencoba mengeklik sesuatu yang lain sambil menunggu—sesuatu yang dapat berpindah dari bawahnya.
Pergeseran tata letak yang terjadi dalam waktu 500 milidetik input pengguna akan memiliki tanda hadRecentInput yang ditetapkan, sehingga dapat dikecualikan dari penghitungan.
Animasi dan transisi
Animasi dan transisi, jika dikerjakan dengan baik, merupakan cara yang tepat untuk memperbarui konten pada halaman tanpa mengejutkan pengguna. Konten yang bergeser secara tiba-tiba dan tidak terduga di halaman hampir selalu memberikan pengalaman pengguna yang buruk. Namun, konten yang bergerak secara bertahap dan alami dari satu posisi ke posisi berikutnya sering kali dapat membantu pengguna lebih memahami apa yang terjadi, dan memandu mereka di antara perubahan status.
Pastikan untuk mematuhi setelan browser prefers-reduced-motion, karena beberapa pengunjung situs dapat mengalami efek buruk atau masalah perhatian dari animasi.
Properti transform CSS memungkinkan Anda menganimasikan elemen tanpa memicu pergeseran tata letak:
- Daripada mengubah properti
heightdanwidth, gunakantransform: scale(). - Untuk memindahkan elemen, hindari mengubah properti
top,right,bottom, atauleftdan gunakantransform: translate()sebagai gantinya.
Cara mengukur CLS
CLS dapat diukur di lab atau di lapangan, dan tersedia di alat berikut:
Alat lapangan
- Laporan Pengalaman Pengguna Chrome
- PageSpeed Insights
- Search Console (laporan Data Web Inti)
- Library JavaScript
web-vitals
Alat lab
Mengukur pergeseran tata letak di JavaScript
Untuk mengukur pergeseran tata letak dalam JavaScript, Anda menggunakan Layout Instability API.
Contoh berikut menunjukkan cara membuat PerformanceObserver untuk mencatat entri layout-shift ke konsol:
new PerformanceObserver((entryList) => {
for (const entry of entryList.getEntries()) {
console.log('Layout shift:', entry);
}
}).observe({type: 'layout-shift', buffered: true});
Mengukur CLS di JavaScript
Untuk mengukur CLS di JavaScript, Anda perlu mengelompokkan entri layout-shift yang tidak diharapkan ini ke dalam sesi, dan menghitung nilai sesi maksimum. Anda dapat melihat kode sumber library JavaScript web vitals yang berisi penerapan referensi tentang cara penghitungan CLS.
Umumnya, nilai CLS saat ini pada saat halaman dihapus muatannya adalah nilai CLS akhir untuk halaman tersebut, tetapi ada beberapa pengecualian penting seperti yang disebutkan di bagian berikutnya. Library JavaScript web vitals mempertimbangkan hal ini sebanyak mungkin, dalam batasan Web API.
Perbedaan antara metrik dan API
- Jika halaman dimuat di latar belakang, atau jika halaman dimuat di latar belakang sebelum browser melukis konten apa pun, halaman tersebut tidak boleh melaporkan nilai CLS apa pun.
- Jika halaman dipulihkan dari back/forward cache, nilai CLS-nya harus direset ke nol karena pengguna mengalaminya sebagai kunjungan halaman yang berbeda.
- API tidak melaporkan entri
layout-shiftuntuk pergeseran yang terjadi dalam iframe, tetapi metrik melakukannya karena entri tersebut merupakan bagian dari pengalaman pengguna di halaman tersebut. Hal ini dapat menunjukkan perbedaan antara CrUX dan RUM. Untuk mengukur CLS dengan benar, Anda harus mempertimbangkannya. Sub-frame dapat menggunakan API untuk melaporkan entrilayout-shift-nya ke frame induk untuk agregasi.
Selain pengecualian ini, CLS memiliki beberapa kerumitan tambahan karena mengukur seluruh masa aktif halaman:
- Pengguna mungkin membiarkan tab terbuka dalam waktu yang sangat lama—hari, minggu, atau bulan. Faktanya, pengguna mungkin tidak pernah menutup tab.
- Di sistem operasi seluler, browser biasanya tidak menjalankan callback penghapusan muatan halaman untuk tab latar belakang, sehingga menyulitkan pelaporan nilai "final".
Untuk menangani kasus tersebut, CLS harus dilaporkan setiap kali halaman berada di latar belakang—selain setiap kali halaman dihapus muatannya (peristiwa visibilitychange mencakup kedua skenario ini). Dan sistem analisis yang menerima data ini kemudian perlu menghitung nilai CLS akhir di backend.
Daripada menghafal dan menangani semua kasus ini sendiri, developer dapat menggunakan library JavaScript web-vitals untuk mengukur CLS, yang memperhitungkan semua yang disebutkan di atas kecuali kasus iframe:
import {onCLS} from 'web-vitals';
// Measure and log CLS in all situations
// where it needs to be reported.
onCLS(console.log);
Cara meningkatkan CLS
Untuk panduan selengkapnya tentang cara mengidentifikasi pergeseran tata letak di kolom dan cara menggunakan data lab untuk mengoptimalkannya, lihat panduan kami untuk mengoptimalkan CLS.
Referensi lainnya
- Panduan Tag Google Publisher tentang meminimalkan pergeseran tata letak
- Memahami Pergeseran Tata Letak Kumulatif oleh Annie Sullivan dan Steve Kobes dalam acara #Perfpan (2020)
Log perubahan
Terkadang, bug ditemukan di API yang digunakan untuk mengukur metrik, dan terkadang dalam definisi metrik itu sendiri. Oleh karena itu, perubahan terkadang harus dilakukan, dan perubahan ini dapat muncul sebagai peningkatan atau regresi dalam dasbor dan laporan internal Anda.
Untuk membantu Anda mengelola hal ini, semua perubahan pada penerapan atau definisi metrik ini akan ditampilkan di Log perubahan ini.
Jika memiliki masukan untuk metrik ini, Anda dapat memberikannya di grup Google web-vitals-feedback.