Kümülatif Düzen Kaydırma (CLS) Sorunları Nasıl Onarılır

Kümülatif Mizanpaj Kayması (CLS), sayfanın bu sarsıcı hareketlerini, ister görseller, ister reklamlar veya herhangi bir şey olsun, sayfanın geri kalanından daha sonra devreye giren yeni içerik olarak ölçmeye çalışır. Sayfanın ne kadarının beklenmedik bir şekilde ve ne sıklıkta hareket ettiğine bağlı olarak bir puan hesaplar. Bu içerik değişimleri çok can sıkıcıdır, okumaya başladığınız bir makalede yerinizi kaybetmenize veya daha da kötüsü yanlış düğmeye tıklamanıza neden olur!

Bu yazıda, CLS'yi azaltmak için bazı ön uç kalıplarını tartışacağım. Bunu daha önceki bir makalede ele aldığım için CLS ölçümü hakkında çok fazla konuşmayacağım. CLS'nin nasıl hesaplandığının mekaniği hakkında da çok fazla konuşmayacağım: Google'ın bununla ilgili bazı iyi belgeleri var ve Jess Peck'in Kümülatif Düzen Kaydırma için Neredeyse Tamamlanmış Kılavuzu da buna harika bir derin dalış. Bununla birlikte, bazı teknikleri anlamak için gereken biraz arka plan vereceğim.

CLS Neden Farklıdır?

CLS, bence, Temel Web Verilerinin en ilginç olanı, çünkü kısmen daha önce hiç gerçekten ölçmediğimiz veya optimize etmediğimiz bir şey. Bu nedenle, onu optimize etmeye çalışmak için genellikle yeni teknikler ve düşünme yolları gerekir. Diğer iki Önemli Web Verisinden çok farklı bir canavar.

Diğer iki Önemli Web Verisine kısaca bakıldığında, En Büyük İçerikli Boya (LCP) tam olarak adından da anlaşılacağı gibi yapar ve sayfanın ne kadar hızlı yüklendiğini ölçen önceki yükleme metriklerinde daha çok bir bükülmedir. Evet, en alakalı içeriğin yüklenme hızına bakmak için sayfa yükleme kullanıcı deneyimini tanımlama biçimimizi değiştirdik, ancak temelde içeriğin mümkün olduğunca çabuk yüklenmesini sağlamak için eski teknikleri yeniden kullanıyor. LCP'nizi nasıl optimize edeceğiniz, çoğu web sayfası için nispeten iyi anlaşılmış bir problem olmalıdır.

İlk Giriş Gecikmesi (FID), etkileşimlerdeki herhangi bir gecikmeyi ölçer ve çoğu site için sorun teşkil etmez. Bunu optimize etmek genellikle JavaScript'inizi temizleme (veya azaltma!) meselesidir ve genellikle siteye özeldir. Bu, bu iki ölçümle sorunları çözmenin kolay olduğu anlamına gelmez, ancak bunlar oldukça iyi anlaşılmış sorunlardır.

CLS'nin farklı olmasının bir nedeni , sayfanın kullanım ömrü boyunca ölçülmesidir - bu, adın "kümülatif" kısmıdır! Diğer iki Önemli Web Verisi, yüklemeden sonra (LCP için) veya ilk etkileşim için (FID için) ana bileşen sayfada bulunduktan sonra durur. Bu, Lighthouse gibi geleneksel laboratuvar tabanlı araçlarımızın yalnızca ilk yük CLS'sini hesapladıkları için genellikle CLS'yi tam olarak yansıtmadığı anlamına gelir. Gerçek hayatta, bir kullanıcı sayfayı aşağı kaydırır ve daha fazla içeriğin düşmesine neden olarak daha fazla kaymaya neden olabilir.

CLS ayrıca, sayfanın ne kadarının ve ne sıklıkta hareket ettiğine bağlı olarak hesaplanan biraz yapay bir sayıdır. LCP ve FID milisaniye cinsinden ölçülürken, CLS karmaşık bir hesaplama ile birimsiz bir sayı çıktısıdır. Bu Core Web Vital'i geçmek için sayfanın 0,1 veya altında olmasını istiyoruz. 0.25'in üzerindeki herhangi bir şey “zayıf” olarak görülüyor.

Kullanıcı etkileşiminden kaynaklanan kaymalar sayılmaz . Bu, işaretçi olayları ve kaydırma hariç tutulsa da, belirli bir dizi kullanıcı etkileşiminin 500 ms'si içinde olarak tanımlanır. Bir düğmeyi tıklayan kullanıcının, örneğin daraltılmış bir bölümü genişleterek içeriğin görünmesini bekleyebileceği varsayılır.

CLS, beklenmeyen kaymaları ölçmekle ilgilidir. Bir sayfa en iyi şekilde oluşturulmuşsa kaydırma, içeriğin hareket etmesine neden olmamalıdır ve benzer şekilde, örneğin yakınlaştırılmış bir sürüm elde etmek için bir ürün resminin üzerine gelindiğinde de diğer içeriğin atlanmasına neden olmamalıdır. Ancak elbette istisnalar da var ve bu sitelerin buna nasıl tepki vereceğini düşünmesi gerekiyor.

CLS ayrıca ince ayarlar ve hata düzeltmeleri ile sürekli olarak gelişmektedir. Tek Sayfa Uygulamaları (SPA) ve sonsuz kayan sayfalar gibi uzun ömürlü sayfalara biraz ara vermesi gereken ve birçok kişinin CLS'de haksız yere cezalandırıldığını düşündüğü daha büyük bir değişikliği duyurdu. Şimdiye kadar yapıldığı gibi CLS puanını hesaplamak için tüm sayfa süresi boyunca vardiyaları toplamak yerine, puan belirli bir zaman çerçevesi içindeki en büyük vardiya setine göre hesaplanacaktır.

Bu, 0,05, 0,06 ve 0,04'lük üç CLS öbeğiniz varsa, daha önce bunun 0,15 olarak kaydedileceği (yani "iyi" sınır olan 0,1'in üzerinde), şimdi ise 0,06 olarak puanlanacağı anlamına gelir. Puanın, bu zaman çerçevesindeki ayrı vardiyalardan oluşabileceği (yani, 0,06 CLS puanının 0,02'lik üç ayrı vardiyadan kaynaklanması durumunda) anlamında hala kümülatiftir , ancak artık sayfanın toplam ömrü boyunca kümülatif değildir. .

Bu 0.06 kaymasının nedenlerini çözerseniz, CLS'niz bir sonraki en büyük (0.05) olarak rapor edilecektir, bu nedenle hala sayfanın ömrü boyunca tüm kaymalara bakıyor - yalnızca raporlamayı seçiyor CLS puanı olarak en büyüğü.

CLS ile ilgili bazı metodolojilere ilişkin bu kısa girişle, bazı çözümlere geçelim! Bu tekniklerin tümü, temel olarak, ister medya ister JavaScript enjekte edilmiş içerik olsun, ek içerik yüklenmeden önce doğru miktarda alan ayırmayı içerir, ancak web geliştiricilerinin bunu yapması için birkaç farklı seçenek vardır.

Görüntülerde ve iFrame'lerde Genişlik ve Yükseklikleri Ayarlayın

Bunu daha önce yazmıştım, ancak CLS'yi azaltmak için yapabileceğiniz en kolay şeylerden biri, resimlerinizde width ve height niteliklerinin ayarlanmış olduğundan emin olmaktır. Bunlar olmadan, bir resim, indirildikten sonra sonraki içeriğin ona yer açmak için değişmesine neden olur:

Bu, yalnızca görüntü işaretlemenizi aşağıdakilerden değiştirme meselesidir:

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

İle:

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

DevTools'u açıp öğenin üzerine gelerek (veya üzerine dokunarak) görüntünün boyutlarını bulabilirsiniz.

Intrinsic Size (görüntü kaynağının gerçek boyutudur) kullanmanızı öneririm ve tarayıcı bunları değiştirmek için CSS kullandığınızda bunları oluşturulan boyuta küçültür.

Hızlı İpucu : Eğer benim gibi genişlik ve yükseklik mi yoksa yükseklik ve genişlik mi olduğunu hatırlayamıyorsanız, bunu X ve Y koordinatları olarak düşünün, X gibi, genişlik her zaman önce verilir.

Duyarlı resimleriniz varsa ve resim boyutlarını değiştirmek için CSS kullanıyorsanız (örneğin, onu ekran boyutunun %100'ü max-width sınırlamak için), bu nitelikler height hesaplamak için kullanılabilir - bunu geçersiz kılmayı hatırlamanız şartıyla CSS'nizde auto :

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

Tüm modern tarayıcılar artık bunu destekliyor, ancak makalemde ele alındığı gibi yakın zamana kadar desteklenmedi. Bu aynı zamanda <picture> öğeleri ve srcset görüntüleri için de çalışır (yedek img öğesinde width ve height ayarlayın), ancak henüz farklı en boy oranlarına sahip görüntüler için değil - üzerinde çalışılıyor ve o zamana kadar width ve height ayarlamanız gerekir herhangi bir değer 0 0 varsayılandan daha iyi olacağından!

Bu aynı zamanda yerel tembel yüklemeli görüntülerde de çalışır (ancak Safari henüz varsayılan olarak yerel tembel yüklemeyi desteklemez).

Yeni aspect-ratio CSS Özelliği

Duyarlı görüntülerin yüksekliğini hesaplamak için kullanılan yukarıdaki width ve height tekniği, artık Chromium tabanlı tarayıcılar ve Firefox tarafından desteklenen ve aynı zamanda Safari Teknoloji Önizlemesi'nde bulunan yeni CSS aspect-ratio özelliği kullanılarak diğer öğelere genelleştirilebilir. umarım bu, yakında kararlı sürüme geleceği anlamına gelir.

Böylece, örneğin 16:9 oranında gömülü bir videoda kullanabilirsiniz:

 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>

İlginç bir şekilde, en aspect-ratio özelliğini tanımlamadan, tarayıcılar duyarlı video öğelerinin yüksekliğini yok sayar ve varsayılan olarak 2:1 en boy oranını kullanır, bu nedenle burada bir düzen kaymasını önlemek için yukarıdakilere ihtiyaç vardır.

Gelecekte, en-boy oranı kullanılarak eleman niteliklerine dayalı olarak aspect-ratio dinamik olarak ayarlamak mümkün olacaktır aspect-ratio: attr(width) / attr(height); ama ne yazık ki bu henüz desteklenmiyor.

Veya, duyarlı hale getirmek için oluşturduğunuz bir tür özel kontrol için bir <div> öğesinde aspect-ratio bile kullanabilirsiniz:

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

 <div></div>

En aspect-ratio desteklemeyen tarayıcılar için eski dolgu-alt kesmeyi kullanabilirsiniz, ancak daha yeni aspect-ratio ve geniş desteğin sadeliği ile (özellikle bu Safari Teknik Önizleme'den normal Safari'ye geçtiğinde), bu eski yöntemi haklı çıkarmak zor.

Chrome, CLS'yi Google'a geri besleyen tek tarayıcıdır ve CLS sorunlarınızı Temel Web Verileri açısından çözecek aspect-ratio destekler. Metrikleri kullanıcılar yerine önceliklendirmekten hoşlanmıyorum, ancak diğer Chromium ve Firefox tarayıcılarının buna sahip olması ve Safari'nin umarım yakında olması ve bunun aşamalı bir geliştirme olması, şu anda bulunduğumuz noktada olduğumuzu söyleyebilirim. dolgu tabanlı hack'i geride bırakabilir ve daha temiz kod yazabilir.

min-height liberal kullanımını sağlayın

Duyarlı bir boyuta ihtiyaç duymayan, bunun yerine sabit bir yüksekliğe ihtiyaç duyan öğeler için min-height kullanmayı düşünün. Bu, örneğin sabit bir yükseklik başlığı için olabilir ve medya sorgularını her zamanki gibi kullanarak farklı kesme noktaları için farklı başlıklara sahip olabiliriz:

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

 <header> ... </header>

Tabii ki aynısı yatay olarak yerleştirilmiş öğeler için min-width için de geçerlidir, ancak normalde CLS sorunlarına neden olan yüksekliktir.

Enjekte edilen içerik ve gelişmiş CSS seçicileri için daha gelişmiş bir teknik, beklenen içerik henüz eklenmediğinde hedefleme yapmaktır. Örneğin, aşağıdaki içeriğe sahipseniz:

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

Ve JavaScript aracılığıyla fazladan bir div eklenir:

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

Ardından, main-content div'i başlangıçta oluşturulduğunda ek içerik için yer bırakmak için aşağıdaki parçacığı kullanabilirsiniz.

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

Kenar boşluğu o öğenin bir parçası olarak sayıldığından, bu kod aslında main-content öğesine bir kayma yaratacaktır , bu nedenle bu kaldırıldığında kayıyor gibi görünecektir (aslında ekranda hareket etmese bile). Bununla birlikte, en azından altındaki içerik kaydırılmayacaktır, bu nedenle CLS'yi azaltmalıdır.

Alternatif olarak, main-content öğesinde de kaymayı önlemek için boşluk eklemek için ::before sözde öğesini kullanabilirsiniz:

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

Ancak dürüst olmak gerekirse, daha iyi çözüm, HTML'de div sahip olmak ve bunun üzerinde min-height kullanmaktır.

Geri Dönüş Öğelerini Kontrol Edin

Mümkün olduğunda JavaScript olmadan bile temel bir web sitesi sağlamak için aşamalı geliştirmeyi kullanmayı seviyorum. Ne yazık ki, bu beni son zamanlarda JavaScript olmayan yedek sürümün JavaScript'in başladığı zamandan farklı olduğu zaman sürdürdüğüm bir sitede yakaladı.

Sorun, başlıktaki "İçindekiler" menü düğmesinden kaynaklanıyordu. JavaScript devreye girmeden önce bu, sizi İçindekiler sayfasına götüren düğme gibi görünecek şekilde tasarlanmış basit bir bağlantıdır. JavaScript devreye girdiğinde, o sayfadan gitmek istediğiniz sayfaya doğrudan gitmenizi sağlayan dinamik bir menü haline gelir.

Anlamsal öğeler kullandım ve bu nedenle geri dönüş bağlantısı için bir bağlantı öğesi ( <a href="#table-of-contents"> ) kullandım, ancak bunu JavaScript'e dayalı dinamik menü için bir <button> ile değiştirdim. Bunlar aynı görünecek şekilde tasarlandı, ancak geri dönüş bağlantısı düğmeden birkaç piksel daha küçüktü!

Bu çok küçüktü ve JavaScript genellikle o kadar hızlı devreye giriyor ki, kapalı olduğunu fark etmemiştim. Ancak Chrome, CLS'yi hesaplarken bunu fark etti ve bu başlıkta olduğu için tüm sayfayı birkaç piksel aşağı kaydırdı . Dolayısıyla bunun CLS puanı üzerinde oldukça etkisi oldu - tüm sayfalarımızı "İyileştirme Gerekiyor" kategorisine sokmaya yetecek kadar.

Bu benim açımdan bir hataydı ve düzeltme basitçe iki öğeyi senkronize etmekti (yukarıda tartışıldığı gibi başlıkta bir min-height ayarlanarak da çözülebilirdi), ancak biraz kafamı karıştırdı. Bu hatayı yapan tek kişi olmadığımdan eminim, bu yüzden sayfanın JavaScript olmadan nasıl işlendiğinin farkında olun. Kullanıcılarınızın JavaScript'i devre dışı bıraktığını düşünmüyor musunuz? JS'nizi indirirken tüm kullanıcılarınız JS değildir.

Web Yazı Tipleri Düzen Kaymalarına Neden Oluyor

Web yazı tipleri, tarayıcının başlangıçta gereken alanı yedek yazı tipine göre hesaplaması ve ardından web yazı tipi indirildiğinde yeniden hesaplaması nedeniyle CLS'nin başka bir yaygın nedenidir. Genellikle, CLS küçüktür ve benzer boyutta bir geri dönüş yazı tipinin kullanılmasını sağlar, bu nedenle genellikle Önemli Web Verilerinde başarısız olmak için yeterince soruna neden olmazlar, ancak yine de kullanıcılar için can sıkıcı olabilir.

Ne yazık ki, web yazı tiplerini önceden yüklemek bile burada yardımcı olmaz, çünkü bu, geri dönüş yazı tiplerinin kullanıldığı süreyi azaltır (bu nedenle yükleme performansı için iyidir - LCP), onları getirmek hala zaman alır ve bu nedenle, geri dönüşler kullanılmaya devam eder. tarayıcı tarafından çoğu durumda CLS'den kaçınmaz. Bunu söyleyerek, bir sonraki sayfada bir web yazı tipinin gerekli olduğunu biliyorsanız (bir giriş sayfasında olduğunuzu ve sonraki sayfanın özel bir yazı tipi kullandığını bildiğinizi söyleyin), bunları önceden getirebilirsiniz.

Yazı tipi kaynaklı düzen kaymalarını tamamen önlemek için, elbette web yazı tiplerini hiç kullanamazdık - bunun yerine sistem yazı tiplerini kullanmak veya font-display: optional . Ancak bunların hiçbiri dürüst olmak gerekirse çok tatmin edici değil.

Diğer bir seçenek de bölümlerin uygun şekilde boyutlandırılmasını sağlamaktır (örneğin min-height ile), böylece içlerindeki metin biraz kayabilirken, altındaki içerik bu olduğunda bile aşağı itilmeyecektir. Örneğin, <h1> öğesinde bir min-height ayarlamak, biraz daha uzun yazı tipleri yüklendiğinde tüm makalenin aşağı kaymasını önleyebilir - farklı yazı tiplerinin farklı sayıda satıra neden olmaması şartıyla. Bu, kaymaların etkisini azaltacaktır, ancak birçok kullanım durumu (örn. genel paragraflar) için minimum bir yüksekliği genellemek zor olacaktır.

Bu sorunu çözmek için beni en çok heyecanlandıran şey, CSS'de yedek yazı tiplerini daha kolay ayarlamanıza olanak tanıyan yeni CSS Yazı Tipi Tanımlayıcıları:

 @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; }

Bunlardan önce, JavaScript'te Yazı Tipi Yükleme API'sini kullanmak için gereken yedek yazı tipini ayarlamak, ki bu daha karmaşıktı, ancak bu seçenek çok yakında kullanıma sunulacaktı, sonunda bize, çekiş kazanma olasılığı daha yüksek olan daha kolay bir çözüm sağlayabilir. Yaklaşan bu yenilik hakkında daha fazla ayrıntı ve bununla ilgili daha fazla kaynak için bu konudaki önceki makaleme bakın.

İstemci Tarafında Oluşturulan Sayfalar İçin İlk Şablonlar

İstemci tarafında oluşturulan birçok sayfa veya Tek Sayfa Uygulaması, yalnızca HTML ve CSS kullanarak bir başlangıç ​​temel sayfası oluşturur ve ardından JavaScript indirilip yürütüldükten sonra şablonu "sulandır".

JavaScript'te uygulamaya yeni bileşenler ve özellikler eklendiğinden, ancak ilk oluşturulan ilk HTML şablonuna eklenmediğinden, bu ilk şablonların JavaScript sürümüyle senkronizasyondan çıkması kolaydır. Bu, bu bileşenler JavaScript tarafından enjekte edildiğinde CLS'ye neden olur.

Bu nedenle, hala iyi bir başlangıç ​​yer tutucusu olduklarından emin olmak için tüm başlangıç ​​şablonlarınızı gözden geçirin . Ve ilk şablon boş <div> 'lerden oluşuyorsa, herhangi bir kaymayı önlemek için uygun şekilde boyutlandırıldıklarından emin olmak için yukarıdaki teknikleri kullanın.

Ek olarak, uygulamaya enjekte edilen ilk div , ilk şablon eklenmeden önce başlangıçta 0 yükseklikte oluşturulmasını önlemek için bir min-height sahip olmalıdır.

 <div></div>

min-height , çoğu görünüm alanından daha büyük olduğu sürece, bu, örneğin web sitesi altbilgisi için herhangi bir CLS'den kaçınmalıdır. CLS yalnızca görünüm alanındayken ölçülür ve bu nedenle kullanıcıyı etkiler. Varsayılan olarak, boş bir div 0 piksel yüksekliğe sahiptir, bu nedenle, uygulama yüklendiğinde gerçek yüksekliğin ne olacağına daha yakın bir min-height verin.

Kullanıcı Etkileşimlerinin 500ms İçinde Tamamlandığından Emin Olun

İçeriğin değişmesine neden olan kullanıcı etkileşimleri, CLS puanlarından hariç tutulur. Bunlar etkileşimden sonra 500 ms ile sınırlıdır. Bu nedenle, bir düğmeye tıklarsanız ve 500 ms'den fazla süren karmaşık işlemler yaparsanız ve ardından yeni içerik oluşturursanız, CLS puanınız düşer.

Sayfayı kaydetmek için Performans sekmesini kullanarak ve ardından sonraki ekran görüntüsünde gösterildiği gibi vardiyaları bularak, Chrome Geliştirici Araçları'nda vardiyanın hariç tutulup tutulmadığını görebilirsiniz. DevTools'u açın, çok korkutucu (ama bir kez alıştığınızda çok kullanışlıdır!) Performans sekmesine gidin ve ardından sol üstteki kayıt düğmesine tıklayın (aşağıdaki resimde daire içine alınmış) ve sayfanızla etkileşime geçin ve kaydı bir kez durdurun tamamlamak.

Başka bir Smashing Magazine makalesine yorumlardan bazılarını yüklediğim sayfanın bir film şeridini göreceksiniz, böylece daire içine aldığım kısımda, yorumların yüklendiğini ve kırmızı altbilginin ekrandan aşağı kaydırıldığını hemen hemen görebilirsiniz. Performans sekmesinin daha aşağısında, Deneyim satırının altına Chrome, her vardiya için kırmızımsı-pembemsi bir kutu koyacak ve buna tıkladığınızda aşağıdaki Özet sekmesinde daha fazla ayrıntı göreceksiniz.

Burada, 0,3359 gibi muazzam bir puan aldığımızı görebilirsiniz - altında olmayı hedeflediğimiz 0,1 eşiğini epeyce aştık, ancak Kümülatif puan bunu içermiyor, çünkü Son girdiler Kullanımlar olarak ayarlandı.

Etkileşimlerin yalnızca İlk Girdi Gecikmesinin ölçmeye çalıştığı şeye göre içeriği 500 ms sınırları içinde kaydırmasını sağlamak, ancak kullanıcının girdinin bir etkisi olduğunu görebileceği (örneğin, bir yükleme döndürücü gösteriliyor), bu nedenle FID iyidir, ancak içerik değişebilir 500 ms sınırı sonrasına kadar sayfaya eklenmez, bu nedenle CLS kötüdür.

İdeal olarak, tüm etkileşim 500 ms içinde bitecektir, ancak bu işlem devam ederken yukarıdaki teknikleri kullanarak gerekli alanı bir kenara bırakmak için bazı şeyler yapabilirsiniz, böylece sihirli 500 ms'den fazla sürerse, o zaman zaten vardiyayı ele aldı ve bu nedenle bunun için cezalandırılmayacak. Bu, özellikle ağdan değişken olabilecek ve kontrolünüz dışında içerik alırken kullanışlıdır.

Dikkat edilmesi gereken diğer öğeler, 500 ms'den uzun süren ve dolayısıyla CLS'yi etkileyebilecek animasyonlardır . Bu biraz kısıtlayıcı gibi görünse de, CLS'nin amacı “eğlenceyi” sınırlamak değil, kullanıcı deneyimine ilişkin makul beklentiler belirlemektir ve bunların 500 ms veya daha kısa sürmesini beklemenin gerçekçi olmadığını düşünüyorum. Ancak aynı fikirde değilseniz veya dikkate almamış olabilecekleri bir kullanım durumunuz varsa, Chrome ekibi bu konuda geri bildirime açıktır.

Eşzamanlı JavaScript

Tartışacağım son teknik, iyi bilinen web performansı tavsiyelerine aykırı olduğu için biraz tartışmalı, ancak bazı durumlarda tek yöntem olabilir. Temel olarak, değişikliklere neden olacağını bildiğiniz bir içeriğiniz varsa, vardiyaları önlemek için bir çözüm, yerleşene kadar onu oluşturmamaktır!

Aşağıdaki HTML, başlangıçta div gizler, ardından div doldurmak için oluşturmayı engelleyen bazı JavaScript'leri yükler ve ardından onu gösterir. JavaScript oluşturmayı engellediği için, bunun altındaki hiçbir şey oluşturulmaz (göstermek için ikinci style bloğu dahil) ve bu nedenle herhangi bir kaydırma yapılmaz.

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

Bu teknikle CSS'yi HTML'de satır içi yapmak önemlidir, bu nedenle sırayla uygulanır. Alternatif, içeriği JavaScript ile göstermektir, ancak yukarıdaki teknikle ilgili sevdiğim şey, JavaScript başarısız olsa veya tarayıcı tarafından kapatılsa bile içeriği göstermeye devam etmesidir.

Bu teknik, harici JavaScript ile de uygulanabilir, ancak bu, harici JavaScript istenip indirildiğinden, satır içi bir script daha fazla gecikmeye neden olur. JavaScript kaynağı önceden yüklenerek bu gecikme en aza indirilebilir, böylece ayrıştırıcı kodun o bölümüne ulaştığında daha hızlı kullanılabilir:

 <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>

Şimdi, söylediğim gibi, bu eminim bazı web performansını insanları korkutacaktır, çünkü tavsiye özellikle engellemeyi önlemek için JavaScript'te async, defer veya daha yeni type="module" (varsayılan olarak defer -ed olan) kullanmaktır. render , burada ise tam tersini yapıyoruz! Bununla birlikte, içerik önceden belirlenemiyorsa ve sarsıcı değişimlere neden olacaksa, onu erken oluşturmanın pek bir anlamı yoktur.

Bu tekniği, sayfanın en üstüne yüklenen ve içeriği aşağı kaydıran bir çerez başlığı için kullandım:

Bu, tanımlama bilgisi başlığının görüntülenip görüntülenmeyeceğini görmek için bir tanımlama bilgisinin okunmasını gerektiriyordu ve bu, sunucu tarafında tamamlanabilse de, bu, döndürülen HTML'yi dinamik olarak değiştirme yeteneği olmayan statik bir siteydi.

Çerez afişleri, CLS'yi önlemek için farklı şekillerde uygulanabilir. Örneğin, içeriği aşağı kaydırmak yerine bunları sayfanın alt kısmında bulundurarak veya içeriğin üstüne yerleştirerek. İçeriği sayfanın en üstünde tutmayı tercih ettik, bu yüzden kaymaları önlemek için bu tekniği kullanmak zorunda kaldık. Site sahiplerinin çeşitli nedenlerle sayfanın en üstünde olmayı tercih edebilecekleri çeşitli uyarılar ve banner'lar da vardır.

Bu tekniği, JavaScript'in içeriği "ana" ve "kenara" sütunlara taşıdığı başka bir sayfada da kullandım (girmeyeceğim nedenlerden dolayı, bunu HTML sunucusu tarafında düzgün bir şekilde oluşturmak mümkün değildi). JavaScript içeriği yeniden düzenleyene kadar içeriği tekrar gizlemek ve ancak o zaman göstermek, bu sayfaların CLS puanını aşağı çeken CLS sorunlarından kaçındı. Ve yine, JavaScript herhangi bir nedenle çalışmasa ve kaydırılmamış içerik gösterilse bile içerik otomatik olarak gizlenir.

Bu tekniği kullanmak, oluşturmayı geciktirdiğiniz ve ayrıca tarayıcıların ileriye dönük ön yükleyicisini engellediğiniz için diğer ölçümleri (özellikle LCP ve ayrıca First Contentful Paint) etkileyebilir, ancak başka bir seçeneğin olmadığı durumlarda göz önünde bulundurulması gereken başka bir araçtır.

Çözüm

Kümülatif Düzen Kayması, içeriğin boyutlarının değişmesinden veya JavaScript'in geç çalıştırılmasıyla sayfaya yeni içeriğin eklenmesinden kaynaklanır. Bu yazıda, bundan kaçınmak için çeşitli ipuçlarını ve püf noktalarını tartıştık. Önemli Web Verilerinin bu rahatsız edici konuya ışık tutmasına sevindim - çok uzun zamandır biz web geliştiricileri (ve kesinlikle kendimi buna dahil ediyorum) bu sorunu görmezden geldik.

Kendi web sitelerimi temizlemek, tüm ziyaretçiler için daha iyi bir deneyim sağladı. Sizi de CLS sorunlarınıza bakmaya teşvik ediyorum ve umarım bu ipuçlarından bazıları bunu yaptığınızda faydalı olur. Kim bilir, tüm sayfalarınız için anlaşılması zor 0 CLS puanına bile inmeyi başarabilirsiniz!

Daha fazla kaynak

• Görüntülerde Genişlik ve Yükseklik Ayarlama, Önemli Web Verilerini Ölçme ve CSS Yazı Tipi Tanımlayıcıları da dahil olmak üzere Smashing Magazine'deki Temel Web Verileri makaleleri.
• CLS'deki sayfaları da dahil olmak üzere Google'ın Önemli Web Verileri belgeleri.
• CLS'de yapılan son değişiklikle ilgili daha fazla ayrıntı ve ardından bu değişiklik çeşitli Google araçlarında güncellenmeye başladı.
• Her Chrome sürümündeki değişiklikleri ayrıntılandıran CLS Değişiklik Günlüğü.
• Jess Peck'ten Kümülatif Mizanpaj Kaydırma için Neredeyse Eksiksiz Kılavuz.
• Kümülatif Düzen Kayması: Karolina Szczur'dan Görsel Dengesizliği Ölçün ve Önleyin.
• CLS'nin paylaşılabilir gösterimlerini oluşturmaya yardımcı olacak bir Düzen Kaydırma GIF Oluşturucu.