Cara Memperbaiki Masalah Pergeseran Tata Letak Kumulatif (CLS)

Pergeseran Tata Letak Kumulatif (CLS) mencoba mengukur pergerakan halaman yang menggelegar itu sebagai konten baru — baik itu gambar, iklan, atau apa pun — yang muncul lebih lambat dari halaman lainnya. Ini menghitung skor berdasarkan seberapa banyak halaman yang bergerak secara tidak terduga, dan seberapa sering. Pergeseran konten ini sangat mengganggu, membuat Anda kehilangan tempat di artikel yang Anda mulai baca atau, lebih buruk lagi, membuat Anda mengklik tombol yang salah!

Pada artikel ini, saya akan membahas beberapa pola front-end untuk mengurangi CLS . Saya tidak akan berbicara terlalu banyak tentang mengukur CLS karena saya sudah membahasnya di artikel sebelumnya. Saya juga tidak akan berbicara terlalu banyak tentang mekanisme bagaimana CLS dihitung: Google memiliki beberapa dokumentasi yang bagus tentang itu, dan Panduan Hampir-Lengkap Jess Peck untuk Pergeseran Tata Letak Kumulatif juga merupakan penyelaman mendalam yang mengagumkan. Namun, saya akan memberikan sedikit latar belakang yang diperlukan untuk memahami beberapa teknik.

Mengapa CLS Berbeda

CLS, menurut pendapat saya, adalah yang paling menarik dari Core Web Vitals, sebagian karena itu adalah sesuatu yang belum pernah kami ukur atau optimalkan sebelumnya. Sehingga seringkali membutuhkan teknik dan cara berpikir baru untuk mencoba mengoptimalkannya. Ini adalah binatang yang sangat berbeda dengan dua Core Web Vitals lainnya.

Melihat secara singkat dua Core Web Vitals lainnya, Largest Contentful Paint (LCP) melakukan persis seperti namanya dan lebih merupakan twist pada metrik pemuatan sebelumnya yang mengukur seberapa cepat halaman dimuat. Ya, kami telah mengubah cara kami mendefinisikan pengalaman pengguna pemuatan laman untuk melihat kecepatan pemuatan konten yang paling relevan , tetapi pada dasarnya ini menggunakan kembali teknik lama untuk memastikan bahwa konten dimuat secepat mungkin. Cara mengoptimalkan LCP Anda harus menjadi masalah yang relatif dipahami dengan baik untuk sebagian besar halaman web.

First Input Delay (FID) mengukur penundaan dalam interaksi dan tampaknya tidak menjadi masalah bagi sebagian besar situs. Mengoptimalkan itu biasanya masalah membersihkan (atau mengurangi!) JavaScript Anda dan biasanya khusus situs. Itu tidak berarti memecahkan masalah dengan dua metrik ini mudah, tetapi mereka adalah masalah yang cukup dipahami dengan baik.

Salah satu alasan mengapa CLS berbeda adalah karena CLS diukur melalui masa pakai halaman — itulah bagian "kumulatif" dari namanya! Dua Data Web Inti lainnya berhenti setelah komponen utama ditemukan di halaman setelah dimuat (untuk LCP), atau untuk interaksi pertama (untuk FID). Ini berarti bahwa alat berbasis lab tradisional kami, seperti Lighthouse, sering kali tidak sepenuhnya mencerminkan CLS karena hanya menghitung CLS beban awal. Dalam kehidupan nyata, pengguna akan menggulir halaman ke bawah dan mungkin mendapatkan lebih banyak konten yang menyebabkan lebih banyak pergeseran.

CLS juga merupakan angka buatan yang dihitung berdasarkan seberapa banyak halaman bergerak dan seberapa sering. Sementara LCP dan FID diukur dalam milidetik, CLS adalah keluaran angka tanpa unit dengan perhitungan yang rumit. Kami ingin halaman menjadi 0,1 atau di bawah untuk melewati Core Web Vital ini. Apa pun di atas 0,25 dipandang sebagai "miskin".

Pergeseran yang disebabkan oleh interaksi pengguna tidak dihitung . Ini didefinisikan sebagai dalam 500 md dari serangkaian interaksi pengguna tertentu meskipun peristiwa penunjuk dan gulir dikecualikan. Dianggap bahwa pengguna yang mengklik tombol mungkin mengharapkan konten muncul, misalnya dengan memperluas bagian yang diciutkan.

CLS adalah tentang mengukur pergeseran tak terduga . Menggulir seharusnya tidak menyebabkan konten berpindah-pindah jika halaman dibuat secara optimal, dan dengan cara yang sama mengarahkan kursor ke gambar produk untuk mendapatkan versi yang diperbesar misalnya juga tidak akan menyebabkan konten lain melompat-lompat. Tetapi tentu saja ada pengecualian dan situs-situs tersebut perlu mempertimbangkan bagaimana bereaksi terhadap hal ini.

CLS juga terus berkembang dengan tweak dan perbaikan bug. Itu baru saja mengumumkan perubahan yang lebih besar yang seharusnya memberi jeda pada halaman yang berumur panjang, seperti Single Page Apps (SPA) dan halaman gulir tak terbatas, yang menurut banyak orang dihukum secara tidak adil di CLS. Alih-alih mengumpulkan shift sepanjang waktu halaman untuk menghitung skor CLS seperti yang telah dilakukan sampai sekarang, skor akan dihitung berdasarkan set shift terbesar dalam jendela timebox tertentu.

Ini berarti bahwa jika Anda memiliki tiga potongan CLS 0,05, 0,06, dan 0,04 maka sebelumnya ini akan dicatat sebagai 0,15 (yaitu di atas batas "baik" 0,1), sedangkan sekarang akan diberi skor sebagai 0,06. Ini masih kumulatif dalam arti bahwa skor dapat terdiri dari pergeseran terpisah dalam jangka waktu tersebut (yaitu jika skor CLS 0,06 itu disebabkan oleh tiga pergeseran terpisah 0,02), tetapi itu tidak lagi kumulatif selama masa hidup total halaman lagi .

Mengatakan bahwa, jika Anda memecahkan penyebab pergeseran 0,06 itu, maka CLS Anda akan dilaporkan sebagai yang terbesar berikutnya (0,05) sehingga masih melihat semua perubahan selama masa halaman — itu hanya memilih untuk melaporkan saja yang terbesar sebagai skor CLS.

Dengan pengenalan singkat beberapa metodologi tentang CLS, mari beralih ke beberapa solusi ! Semua teknik ini pada dasarnya melibatkan penyisihan jumlah ruang yang tepat sebelum konten tambahan dimuat — apakah itu media atau konten yang disuntikkan JavaScript, tetapi ada beberapa opsi berbeda yang tersedia bagi pengembang web untuk melakukan ini.

Atur Lebar Dan Tinggi Pada Gambar Dan iFrames

Saya telah menulis tentang ini sebelumnya, tetapi salah satu hal termudah yang dapat Anda lakukan untuk mengurangi CLS adalah memastikan Anda memiliki atribut width dan height yang ditetapkan pada gambar Anda . Tanpa mereka, gambar akan menyebabkan konten berikutnya bergeser untuk memberi jalan setelah diunduh:

Ini hanyalah masalah mengubah markup gambar Anda dari:

 <img src="hero_image.jpg" alt="...">

Ke:

 <img src="hero_image.jpg" alt="..." width="400" height="400">

Anda dapat menemukan dimensi gambar dengan membuka DevTools dan mengarahkan kursor ke (atau mengetuk) elemen tersebut.

Saya menyarankan untuk menggunakan Ukuran Intrinsik (yang merupakan ukuran sebenarnya dari sumber gambar) dan browser kemudian akan menurunkannya ke ukuran yang dirender saat Anda menggunakan CSS untuk mengubahnya.

Tip Singkat : Jika, seperti saya, Anda tidak dapat mengingat apakah itu lebar dan tinggi atau tinggi dan lebar, anggap itu sebagai koordinat X dan Y jadi, seperti X, lebar selalu diberikan terlebih dahulu.

Jika Anda memiliki gambar responsif dan menggunakan CSS untuk mengubah dimensi gambar (mis. untuk membatasinya menjadi max-width 100% dari ukuran layar), maka atribut ini dapat digunakan untuk menghitung height — asalkan Anda ingat untuk menimpanya ke auto di CSS Anda:

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

Semua browser modern mendukung ini sekarang, meskipun tidak sampai baru-baru ini seperti yang dibahas dalam artikel saya. Ini juga berfungsi untuk elemen <picture> dan gambar srcset (mengatur width dan height pada elemen fallback img ), meskipun belum untuk gambar dengan rasio aspek yang berbeda — ini sedang dikerjakan, dan sampai saat itu Anda masih harus mengatur width dan height karena nilai apa pun akan lebih baik daripada 0 dengan 0 default!

Ini juga berfungsi pada gambar asli yang dimuat lambat (meskipun Safari belum mendukung pemuatan malas asli secara default).

Properti CSS aspect-ratio baru

Teknik width dan height di atas, untuk menghitung tinggi untuk gambar responsif, dapat digeneralisasi ke elemen lain menggunakan properti aspect-ratio CSS baru, yang sekarang didukung oleh browser berbasis Chromium dan Firefox, tetapi juga di Pratinjau Teknologi Safari jadi mudah-mudahan itu berarti akan segera datang ke versi stabil.

Jadi Anda bisa menggunakannya pada video yang disematkan misalnya dalam rasio 16:9:

 video { max-width: 100%; height: auto; aspect-ratio: 16 / 9; }

 <video controls width="1600" height="900" poster="..."> <source src="/media/video.webm" type="video/webm"> <source src="/media/video.mp4" type="video/mp4"> Sorry, your browser doesn't support embedded videos. </video>

Menariknya, tanpa mendefinisikan properti aspect-ratio , browser akan mengabaikan tinggi untuk elemen video responsif dan menggunakan rasio aspek default 2:1, sehingga hal di atas diperlukan untuk menghindari pergeseran tata letak di sini.

Di masa depan, bahkan mungkin untuk mengatur aspect-ratio secara dinamis berdasarkan atribut elemen dengan menggunakan aspect-ratio: attr(width) / attr(height); tapi sayangnya ini belum didukung.

Atau Anda bahkan dapat menggunakan aspect-ratio pada elemen <div> untuk semacam kontrol khusus yang Anda buat agar responsif:

 #my-square-custom-control { max-width: 100%; height: auto; width: 500px; aspect-ratio: 1; }

 <div></div>

Untuk browser yang tidak mendukung aspect-ratio Anda dapat menggunakan hack padding-bottom yang lebih lama tetapi, dengan kesederhanaan aspect-ratio yang lebih baru dan dukungan yang luas (terutama setelah ini berpindah dari Pratinjau Teknis Safari ke Safari biasa), ini sulit untuk membenarkan metode yang lebih tua itu.

Chrome adalah satu-satunya browser yang memberi umpan balik CLS ke Google dan mendukung arti aspect-ratio yang akan menyelesaikan masalah CLS Anda dalam hal Data Web Inti. Saya tidak suka memprioritaskan metrik di atas pengguna, tetapi fakta bahwa browser Chromium dan Firefox lainnya memiliki ini dan Safari mudah-mudahan akan segera, dan bahwa ini adalah peningkatan progresif berarti saya akan mengatakan bahwa kita berada di titik di mana kita dapat meninggalkan hack padding-bottom dan menulis kode yang lebih bersih.

Manfaatkan min-height secara Liberal

Untuk elemen yang tidak memerlukan ukuran responsif tetapi ketinggian tetap, pertimbangkan untuk menggunakan min-height . Ini bisa untuk header dengan tinggi tetap , misalnya dan kita bisa memiliki heading yang berbeda untuk break-point yang berbeda menggunakan kueri media seperti biasa:

 header { min-height: 50px; } @media (min-width: 600px) { header { min-height: 200px; } }

 <header> ... </header>

Tentu saja hal yang sama berlaku untuk min-width untuk elemen yang ditempatkan secara horizontal, tetapi biasanya ketinggian yang menyebabkan masalah CLS.

Teknik yang lebih maju untuk konten yang disuntikkan dan pemilih CSS tingkat lanjut adalah menargetkan saat konten yang diharapkan belum dimasukkan. Misalnya, jika Anda memiliki konten berikut:

 <div class="container"> <div class="main-content">...</div> </div>

Dan div tambahan dimasukkan melalui JavaScript:

 <div class="container"> <div class="additional-content">.../div> <div class="main-content">...</div> </div>

Kemudian Anda dapat menggunakan cuplikan berikut untuk meninggalkan ruang untuk konten tambahan saat div main-content dirender pada awalnya.

 .main-content:first-child { margin-top: 20px; }

Kode ini sebenarnya akan membuat pergeseran ke elemen main-content utama karena margin dihitung sebagai bagian dari elemen itu sehingga akan tampak bergeser saat dihapus (meskipun sebenarnya tidak bergerak di layar). Namun, setidaknya konten di bawahnya tidak akan bergeser sehingga harus mengurangi CLS.

Atau, Anda dapat menggunakan elemen semu ::before untuk menambahkan spasi guna menghindari pergeseran pada elemen main-content utama juga:

 .main-content:first-child::before { content: ''; min-height: 20px; display: block; }

Tetapi sejujurnya, solusi yang lebih baik adalah memiliki div dalam HTML dan memanfaatkan min-height untuk itu.

Periksa Elemen Pengganti

Saya suka menggunakan peningkatan progresif untuk menyediakan situs web dasar, bahkan tanpa JavaScript jika memungkinkan. Sayangnya, ini baru-baru ini menarik perhatian saya di satu situs yang saya kelola ketika versi non-JavaScript fallback berbeda dari saat JavaScript digunakan.

Masalahnya adalah karena tombol menu "Daftar Isi" di header. Sebelum JavaScript dimulai, ini adalah tautan sederhana, ditata agar terlihat seperti tombol yang membawa Anda ke halaman Daftar Isi. Setelah JavaScript masuk, itu menjadi menu dinamis untuk memungkinkan Anda menavigasi langsung ke halaman apa pun yang ingin Anda buka dari halaman itu.

Saya menggunakan elemen semantik dan menggunakan elemen jangkar ( <a href="#table-of-contents"> ) untuk tautan mundur tetapi menggantinya dengan <button> untuk menu dinamis berbasis JavaScript. Ini ditata agar terlihat sama, tetapi tautan mundur beberapa piksel lebih kecil dari tombol!

Ini sangat kecil, dan JavaScript biasanya muncul begitu cepat, sehingga saya tidak menyadarinya. Namun, Chrome menyadarinya saat menghitung CLS dan, karena ini ada di header, ia menggeser seluruh halaman ke bawah beberapa piksel. Jadi ini berdampak cukup besar pada skor CLS — cukup untuk menjatuhkan semua halaman kami ke dalam kategori “Perlu Peningkatan”.

Ini adalah kesalahan saya, dan perbaikannya hanya untuk menyelaraskan kedua elemen (itu juga bisa diperbaiki dengan mengatur min-height pada header seperti yang dibahas di atas), tetapi itu sedikit membingungkan saya. Saya yakin saya bukan satu-satunya yang membuat kesalahan ini, jadi perhatikan bagaimana halaman dirender tanpa JavaScript. Tidakkah menurut Anda pengguna Anda menonaktifkan JavaScript? Semua pengguna Anda bukan JS saat mereka mengunduh JS Anda.

Font Web Menyebabkan Pergeseran Tata Letak

Font web adalah penyebab umum CLS lainnya karena browser pada awalnya menghitung ruang yang dibutuhkan berdasarkan font fallback, lalu menghitung ulang saat font web diunduh. Biasanya, CLS berukuran kecil, menyediakan font fallback berukuran sama yang digunakan, sehingga sering kali mereka tidak menyebabkan cukup banyak masalah untuk menggagalkan Core Web Vitals, tetapi mereka tetap dapat menggelegar bagi pengguna.

Sayangnya bahkan pramuat webfonts tidak akan membantu di sini karena, sementara itu mengurangi waktu font fallback digunakan (begitu baik untuk memuat kinerja — LCP), masih membutuhkan waktu untuk mengambilnya , dan fallback akan tetap digunakan oleh browser dalam banyak kasus sehingga tidak menghindari CLS. Mengatakan itu, jika Anda tahu font web diperlukan di halaman berikutnya (misalnya Anda berada di halaman login dan tahu halaman berikutnya menggunakan font khusus) maka Anda dapat mengambilnya terlebih dahulu.

Untuk menghindari pergeseran tata letak yang disebabkan font sama sekali, tentu saja kami tidak dapat menggunakan font web sama sekali — termasuk menggunakan font sistem sebagai gantinya, atau menggunakan font-display: optional untuk tidak menggunakannya jika tidak diunduh tepat waktu untuk render awal. Tapi tak satu pun dari mereka sangat memuaskan, jujur.

Pilihan lain adalah memastikan bagian berukuran tepat (misalnya dengan min-height ) sehingga meskipun teks di dalamnya mungkin sedikit bergeser, konten di bawahnya tidak akan terdorong ke bawah meskipun hal ini terjadi. Misalnya, menyetel min-height pada elemen <h1> dapat mencegah seluruh artikel bergeser ke bawah jika font yang sedikit lebih tinggi dimuat — asalkan font yang berbeda tidak menyebabkan jumlah baris yang berbeda. Ini akan mengurangi dampak pergeseran, namun, untuk banyak kasus penggunaan (misalnya paragraf umum) akan sulit untuk menggeneralisasi ketinggian minimum.

Yang paling membuat saya bersemangat untuk menyelesaikan masalah ini, adalah CSS Font Descriptors baru yang memungkinkan Anda untuk lebih mudah menyesuaikan font fallback di CSS:

 @font-face { font-family: 'Lato'; src: url('/static/fonts/Lato.woff2') format('woff2'); font-weight: 400; } @font-face { font-family: "Lato-fallback"; size-adjust: 97.38%; ascent-override: 99%; src: local("Arial"); } h1 { font-family: Lato, Lato-fallback, sans-serif; }

Sebelum ini, menyesuaikan font cadangan yang diperlukan menggunakan API Pemuatan Font di JavaScript yang lebih rumit, tetapi opsi ini akan segera keluar akhirnya dapat memberi kita solusi yang lebih mudah yang lebih mungkin untuk mendapatkan daya tarik. Lihat artikel saya sebelumnya tentang subjek ini untuk detail lebih lanjut tentang inovasi yang akan datang ini dan lebih banyak sumber daya tentang itu.

Template Awal Untuk Halaman Render sisi Klien

Banyak halaman yang dirender sisi klien, atau Aplikasi Halaman Tunggal, merender halaman dasar awal hanya dengan menggunakan HTML dan CSS, lalu "menghidrasi" template setelah JavaScript diunduh dan dijalankan.

Sangat mudah bagi templat awal ini untuk tidak sinkron dengan versi JavaScript karena komponen dan fitur baru ditambahkan ke aplikasi dalam JavaScript tetapi tidak ditambahkan ke templat HTML awal yang dirender terlebih dahulu. Ini kemudian menyebabkan CLS ketika komponen ini disuntikkan oleh JavaScript.

Jadi tinjau semua template awal Anda untuk memastikan mereka masih merupakan placeholder awal yang baik. Dan jika template awal terdiri dari <div> s kosong, maka gunakan teknik di atas untuk memastikan ukurannya tepat untuk mencoba menghindari perubahan apa pun.

Selain itu, div awal yang disuntikkan dengan aplikasi harus memiliki min-height untuk menghindarinya dirender dengan tinggi 0 pada awalnya bahkan sebelum template awal dimasukkan.

 <div></div>

Selama min-height lebih besar dari sebagian besar area pandang , ini harus menghindari CLS untuk footer situs web, misalnya. CLS hanya diukur saat berada di area pandang sehingga berdampak pada pengguna. Secara default, div kosong memiliki ketinggian 0px, jadi berikan min-height yang mendekati ketinggian sebenarnya saat aplikasi dimuat.

Pastikan Interaksi Pengguna Selesai Dalam 500ms

Interaksi pengguna yang menyebabkan perubahan konten dikecualikan dari skor CLS. Ini dibatasi hingga 500 ms setelah interaksi. Jadi, jika Anda mengklik sebuah tombol, dan melakukan beberapa pemrosesan kompleks yang memakan waktu lebih dari 500 ms dan kemudian merender beberapa konten baru, maka skor CLS Anda akan menurun.

Anda dapat melihat apakah pergeseran dikecualikan di Chrome DevTools dengan menggunakan tab Performa untuk merekam halaman dan kemudian menemukan pergeseran seperti yang ditunjukkan pada tangkapan layar berikutnya. Buka DevTools pergi ke tab Performance yang sangat mengintimidasi (tetapi sangat berguna setelah Anda menguasainya!) lalu klik tombol rekam di kiri atas (dilingkari pada gambar di bawah) dan berinteraksi dengan halaman Anda, dan berhenti merekam sekali menyelesaikan.

Anda akan melihat strip film halaman di mana saya memuat beberapa komentar di artikel Majalah Smashing lain sehingga di bagian yang saya lingkari, Anda bisa melihat komentar dimuat dan footer merah digeser ke bawah layar. Lebih jauh ke bawah tab Kinerja , di bawah garis Pengalaman , Chrome akan menempatkan kotak merah muda kemerahan untuk setiap shift dan ketika Anda mengkliknya, Anda akan mendapatkan detail lebih lanjut di tab Ringkasan di bawah.

Di sini Anda dapat melihat bahwa kami mendapat skor 0,3359 yang sangat besar — ​​jauh melewati ambang 0,1 yang kami tuju, tetapi skor Kumulatif belum termasuk ini, karena masukan terbaru disetel ke Penggunaan.

Memastikan interaksi hanya menggeser konten dalam batas 500 ms pada apa yang coba diukur oleh First Input Delay, tetapi ada beberapa kasus ketika pengguna mungkin melihat bahwa input memiliki efek (misalnya pemintal pemuatan ditampilkan) sehingga FID bagus, tetapi konten mungkin tidak ditambahkan ke halaman sampai setelah batas 500 ms, jadi CLS buruk.

Idealnya, seluruh interaksi akan selesai dalam waktu 500 md, tetapi Anda dapat melakukan beberapa hal untuk menyisihkan ruang yang diperlukan menggunakan teknik di atas saat pemrosesan sedang berlangsung sehingga jika diperlukan lebih dari 500 md, maka Anda telah sudah ditangani shift dan tidak akan dikenakan sanksi untuk itu. Ini sangat berguna saat mengambil konten dari jaringan yang bisa berubah-ubah dan di luar kendali Anda.

Item lain yang harus diwaspadai adalah animasi yang membutuhkan waktu lebih dari 500 md sehingga dapat memengaruhi CLS. Meskipun ini mungkin tampak agak membatasi, tujuan CLS bukan untuk membatasi "kesenangan", tetapi untuk menetapkan harapan yang wajar dari pengalaman pengguna dan saya tidak berpikir itu tidak realistis untuk mengharapkan ini untuk mengambil 500ms atau di bawah. Namun jika Anda tidak setuju, atau memiliki kasus penggunaan yang mungkin tidak mereka pertimbangkan, tim Chrome terbuka untuk menerima masukan tentang hal ini.

JavaScript sinkron

Teknik terakhir yang akan saya diskusikan sedikit kontroversial karena bertentangan dengan saran kinerja web yang terkenal, tetapi ini bisa menjadi satu-satunya metode dalam situasi tertentu. Pada dasarnya, jika Anda memiliki konten yang Anda tahu akan menyebabkan perubahan, maka salah satu solusi untuk menghindari perubahan adalah dengan tidak merendernya sampai selesai!

HTML di bawah ini akan menyembunyikan div pada awalnya, lalu memuat beberapa JavaScript yang memblokir render untuk mengisi div , lalu memperlihatkannya. Karena JavaScript memblokir perenderan, tidak ada yang di bawah ini yang akan dirender (termasuk blok style kedua untuk menyembunyikannya) sehingga tidak ada perubahan yang akan terjadi.

 <style> .cls-inducing-div { display: none; } </style> <div class="cls-inducing-div"></div> <script> ... </script> <style> .cls-inducing-div { display: block; } </style>

Penting untuk menyelaraskan CSS dalam HTML dengan teknik ini, sehingga diterapkan secara berurutan. Alternatifnya adalah menampilkan konten dengan JavaScript itu sendiri, tetapi yang saya sukai dari teknik di atas adalah teknik ini tetap menampilkan konten meskipun JavaScript gagal atau dimatikan oleh browser.

Teknik ini bahkan dapat diterapkan dengan JavaScript eksternal, tetapi ini akan menyebabkan lebih banyak penundaan daripada script sebaris karena JavaScript eksternal diminta dan diunduh. Penundaan itu dapat diminimalkan dengan memuat sumber JavaScript terlebih dahulu sehingga tersedia lebih cepat setelah pengurai mencapai bagian kode tersebut:

 <head> ... <link rel="preload" href="cls-inducing-javascript.js" as="script"> ... </head> <body> ... <style> .cls-inducing-div { display: none; } </style> <div class="cls-inducing-div"></div> <script src="cls-inducing-javascript.js"></script> <style> .cls-inducing-div { display: block; } </style> ... </body>

Sekarang, seperti yang saya katakan, ini saya yakin akan membuat beberapa orang merasa ngeri kinerja web, karena sarannya adalah menggunakan async, defer atau yang lebih baru type="module" (yang defer -ed secara default) pada JavaScript khusus untuk menghindari pemblokiran render , sedangkan kita melakukan yang sebaliknya di sini! Namun, jika konten tidak dapat ditentukan sebelumnya dan akan menyebabkan pergeseran yang menggelegar, maka tidak ada gunanya merendernya lebih awal.

Saya menggunakan teknik ini untuk spanduk cookie yang dimuat di bagian atas halaman dan menggeser konten ke bawah:

Ini membutuhkan membaca cookie untuk melihat apakah akan menampilkan spanduk cookie atau tidak dan, sementara itu dapat diselesaikan di sisi server, ini adalah situs statis tanpa kemampuan untuk secara dinamis mengubah HTML yang dikembalikan.

Spanduk cookie dapat diterapkan dengan berbagai cara untuk menghindari CLS. Misalnya dengan menempatkannya di bagian bawah halaman, atau melapisinya di atas konten, daripada menggeser konten ke bawah. Kami lebih suka menyimpan konten di bagian atas halaman, jadi kami harus menggunakan teknik ini untuk menghindari pergeseran. Ada berbagai peringatan dan spanduk lain yang mungkin disukai pemilik situs untuk berada di bagian atas halaman karena berbagai alasan.

Saya juga menggunakan teknik ini di halaman lain di mana JavaScript memindahkan konten ke dalam kolom "utama" dan "selain" (karena alasan saya tidak akan membahasnya, tidak mungkin membuat ini dengan benar di sisi server HTML). Sekali lagi menyembunyikan konten, hingga JavaScript telah mengatur ulang konten, dan baru kemudian menampilkannya, menghindari masalah CLS yang menyeret skor CLS halaman ini ke bawah. Dan sekali lagi konten secara otomatis tidak disembunyikan meskipun JavaScript tidak berjalan karena alasan tertentu dan konten yang tidak diubah ditampilkan.

Menggunakan teknik ini dapat memengaruhi metrik lain (khususnya LCP dan juga First Contentful Paint) karena Anda menunda rendering, dan juga berpotensi memblokir prapemuat tampilan depan browser, tetapi ini adalah alat lain yang perlu dipertimbangkan untuk kasus-kasus di mana tidak ada opsi lain.

Kesimpulan

Pergeseran Tata Letak Kumulatif disebabkan oleh perubahan dimensi konten, atau konten baru dimasukkan ke dalam halaman dengan menjalankan JavaScript yang terlambat. Dalam posting ini, kami telah membahas berbagai tips dan trik untuk menghindari hal ini. Saya senang sorotan Core Web Vitals telah menyinari masalah yang menjengkelkan ini — terlalu lama kami para pengembang web (dan saya pasti menyertakan diri saya dalam hal ini) telah mengabaikan masalah ini.

Membersihkan situs web saya sendiri telah menghasilkan pengalaman yang lebih baik bagi semua pengunjung. Saya mendorong Anda untuk melihat masalah CLS Anda juga , dan semoga beberapa tips ini akan berguna saat Anda melakukannya. Siapa tahu, Anda bahkan dapat mencapai skor 0 CLS yang sulit dipahami untuk semua halaman Anda!

Lebih Banyak Sumber Daya

• Artikel Core Web Vitals di sini di Smashing Magazine, termasuk artikel saya sendiri tentang Setting Width and Heights on Images, Mengukur Core Web Vitals, dan CSS Font Descriptors.
• Dokumentasi Data Web Inti Google termasuk halaman mereka di CLS.
• Detail lebih lanjut tentang perubahan terbaru pada CLS dan kemudian perubahan ini mulai diperbarui di berbagai alat Google.
• CLS Changelog merinci perubahan di setiap versi Chrome.
• Panduan Hampir Lengkap untuk Pergeseran Tata Letak Kumulatif oleh Jess Peck.
• Pergeseran Tata Letak Kumulatif: Ukur dan Hindari Ketidakstabilan Visual oleh Karolina Szczur.
• Generator GIF Pergeseran Tata Letak untuk membantu menghasilkan demonstrasi CLS yang dapat dibagikan.