CLS skoru ölçümden ölçüme farklı çıkıyorsa kaynak değişken bir dinamik elementtir. Geç gelen reklamlar, boyutsuz embed'ler, font metrik farkları ve JavaScript ile DOM'a eklenen banner'lar tutarsız kaymayı tetikler. DevTools Performance paneli ve alan verisiyle kaynağı izole etmek mümkündür.

CLS Skoru Rastgele Değişiyor: Hangi Dinamik Elementler Tetikliyor?

CLS (Cumulative Layout Shift) skoru ölçümden ölçüme değişiyorsa, bu salınımın kendisi bir veri noktasıdır. Sabit bir kayma kaynağı her ölçümde benzer sonuç üretir; skor tutarsız davranıyorsa kayma, değişken koşullar altında tetiklenen bir dinamik elementten geliyor olabilir. Reklam ağının yanıt verdiği ölçümde skor yüksek çıkar, yanıt vermediğinde temiz görünür.

Tutarsız CLS'i yakalamak zaman alır. Lab ortamı değişkeni sürekli üretemez; yenileme yetmez, koşulları değiştirmek gerekir. Yine de Chrome DevTools, bu değişkenleri görünür kılmak için yeterli araçlar sunar ve kaynağı sistematik biçimde daraltmak mümkündür.

Geç gelen reklamlar, embed'ler, web fontları ve DOM'a sonradan eklenen banner'lar, tutarsız CLS'in en sık karşılaşılan tetikleyicileridir. Her biri farklı bir zamanlama sorununa işaret eder ve her birini yakalamak için kullanılan teknik de farklıdır.

CLS neden her ölçümde farklı çıkar?

Lab ortamında tek seferlik bir ölçüm çoğu dinamik kaynağı atlayabilir. Lighthouse sayfayı belirli bir ağ hızı simülasyonuyla bir kez yükler; o an reklam ağı yanıt vermediyse, embed henüz gelmemişse veya font önbellekten karşılandıysa kayma gerçekleşmez ve skor temiz çıkar. Gerçek kullanıcılar ise farklı zamanlarda, farklı ağ koşullarında ve önbellek durumlarıyla sayfayı açar.

Alan verisi (field data) tutarlı biçimde kötüyken lab skoru iyi görünüyorsa, skor değil alan verisi gerçeği yansıtıyordur. Bu iki kaynağı yan yana değerlendirmek tanılamanın ilk adımıdır; düzenli alan verisi izleme yapılmadan bu fark çoğu zaman görünmez kalır.

Sayfayı ardarda beş kez normal hızda yükleyin. Skor her seferinde farklıysa kaynak değişkendir. Fark küçükse - birkaç yüzde birlik sapma - font veya boyut değişimi düşünülebilir; fark büyükse ve bazen sıfıra düşüyorsa reklam veya embed daha muhtemel kaynaktır.

Reklam slotları ve boyutsuz rezervasyon

Reklam ağından gelen içeriğin boyutu önceden bilinemez. Sayfa HTML'i render edilirken reklam slotu için yer ayrılmamışsa, reklam geldiği an üstteki tüm içerik aşağıya kayar. Bu kayma tam anlamıyla bir layout shift'tir ve CLS değerini doğrudan yükseltir.

Kaynağı zorlaştıran şey, reklam yükleme süresinin ağ gecikmelerine ve açık artırma sürecine bağlı olmasıdır. Bir ölçümde reklam 200 ms'de gelir ve sayfa yerleşimi tamamlanmadan önce slota oturur; CLS sıfır çıkar. Başka bir ölçümde reklam 1,5 saniyede gelir, sayfa çoktan düzenlenmiştir ve CLS yüksek çıkar. Aynı sayfa, iki farklı skor.

Çözüm CSS ile boyut rezervasyonu yapmaktır. Reklam slotuna min-height tanımlayın; reklam bu alanı kullanır, gelmediğinde yer boş kalır ama kayma olmaz. 320x50, 728x90 gibi sabit formatlarda bu basit bir uygulamadır. Responsive slotlar için aspect-ratio veya alt ve üst limit kombinasyonu da işe yarar.

Embed ve iframe'lerin geç gelme sorunu

Tweet, YouTube iframe'i, harita widget'ı veya benzeri üçüncü taraf embed'ler tarayıcıya baştan boyut bildirmez. iframe çerçevesi yüklenirken içeriğin nihai yüksekliği bilinmez; içerik gelince çerçeve büyür ve alttaki öğeler kayar.

Sorun iki aşamada gelebilir. Önce iframe kapsayıcısı yerleşirken bir kayma, ardından iframe içeriği yüklenince kapsayıcı yeniden boyutlanırken ikinci bir kayma. Her ikisi de CLS hesabına ayrı ayrı eklenebilir. Bu tür gecikmeli üçüncü taraf davranışı bazı durumlarda render zincirini de etkiler ve sorunun görünümünü karmaşıklaştırır.

Bunu test etmek için DevTools Network panelinde throttling'i "Slow 3G" yapın ve sayfayı yenileyin. Embed'ler geç geldiğinde kaymayı hangi element tetiklediği Performance panelinde "Experience" satırında görünür hale gelir. Embed kapsayıcısına sabit bir aspect-ratio (örneğin 16 / 9) veya net bir height tanımlamak, boyut belirsizliğini ortadan kaldırır.

Web fontlarının yarattığı sessiz kayma

Font yüklemesi CLS'e daha ince bir kanaldan katkı sunar. Tarayıcı font dosyasını indirirken sistem fontu veya görünmez metin kullanır; font gelince karakter genişlikleri değişebilir. Bu değişim satır sayısını, paragraf yüksekliğini ve alttaki öğelerin konumunu etkileyebilir.

font-display: swap yaygın bir öneri olarak öne çıksa da CLS açısından nüanslı bir seçimdir. swap metnin her zaman görünmesini sağlar, ancak font gelince yeniden çizim yapılır; metin yüksekliği değişirse alttaki öğeler kayar. font-display: optional bu riski büyük ölçüde azaltır: font belirli bir pencere içinde gelmezse sistem fontu kullanılır ve yeniden çizim olmaz. Dezavantajı ilk ziyarette özel fontu göstermeyebilmesidir.

İkinci yol font metrik dengeleme tekniğidir. size-adjust, ascent-override, descent-override tanımlayıcıları yedek fontun metriklerini özel fonta yaklaştırır; font değişimi olsa bile satır yükseklikleri değişmez ve kayma engellenir. Bu teknik için tarayıcı desteği artık geniş bir tabana oturmuştur ve pratik bir ilk tercih olarak değerlendirilebilir.

DevTools Performance panelinde kayma kaynağını bulmak

Chrome DevTools'un Performance paneli, her layout shift olayını zaman çizelgesinde işaretler. "Experience" satırındaki kırmızı dikdörtgenler kayma anlarını gösterir. Birinin üzerine tıkladığınızda sağ panelde hangi elementin hareket ettiği, ne kadar hareket ettiği ve kaymanın tam zamanı görünür. Bu veriden sonra kaynağa bakmak için "Sources" sütunundaki çağrı zincirine bakılır.

Kaymayı tetikleyen elementi bulduktan sonra aynı zaman noktasında hangi ağ isteğinin tamamlandığına bakın. Network panelini Performance kaydıyla eşzamanlı çalıştırmak bu ilişkiyi kurar. Reklam ağından gelen bir istek kaymanın hemen öncesine denk geliyorsa kaynak neredeyse kesindir. Embed'lerden gelen geç yanıtlar da aynı yöntemle izlenir.

Yavaş bağlantı koşulu yakalamayı kolaylaştırır. DevTools Network sekmesinde "Slow 3G" veya "Fast 3G" throttling seçin, ardından Performance kaydını başlatın. Geç gelen kaynaklar zaman çizelgesine yayılır ve aralarındaki ilişki daha okunur hale gelir. Aynı kayıt alınmadan önce cache'i temizlemek - "Disable cache" onay kutusu açık, sayfayı hard refresh - ilk ziyaret koşullarını simüle eder ve önbellek kaynaklı sapmayı engeller.

Sayfa yüklendikten sonra JavaScript tarafından DOM'a eklenen öğeler en zor yakalananlardır. Bir cookie bildirimi, bir promosyon banner'ı veya A/B testi tarafından enjekte edilen bir bölüm, kullanıcı sayfayı okurken belirirse alttaki içerik anında kayar. Bu kayma, sayfa yükleme sürecinin dışında gerçekleşir ve standart yükleme testinde görünmeyebilir.

Bir banner'ın sayfanın üst kısmına eklenmesi özellikle yüksek CLS üretir. Çünkü görünüm alanının tepesinde yapılan kayma alttaki tüm öğeleri etkiler; görünüm alanı yüksekliğiyle çarpılan mesafe CLS hesabını büyütür. Alttan çıkan toast bildirimler görünüm alanının dışında kaldığı için CLS'e katkı vermez; üstten çıkanlar ise doğrudan etkiler.

Bu tür geç eklentileri tespit etmek için Performance kaydını sayfa yüklendikten sonra birkaç saniye daha sürdürün. Kayma, zaman çizelgesinin ilk saniyelerinde değil daha geride görünüyorsa kaynak büyük olasılıkla JavaScript ile geciktirilmiş bir enjeksiyondur. Hangi script'in bunu tetiklediğini bulmak için kayma anındaki "Long task" veya "Script evaluation" bloğuna bakın. Performans sorununu daraltma yaklaşımı, bu tür JavaScript kökenli gecikmelerde de aynı mantıkla işler.

Alan verisiyle laboratuvar sonucunu karşılaştırmak

CrUX (Chrome User Experience Report) verisi, gerçek kullanıcı oturumlarından toplanan CLS dağılımını gösterir. PageSpeed Insights sayfasında "Field Data" bölümü bu dağılımı 75. yüzdelik dilimde raporlar. Lab skoru iyi olduğunda bile alan verisi kötüyse, koşulların ağırlıklı olarak gerçek kullanıcılarda tetiklendiği anlaşılır ve tanılama önceliği alan verisi tarafında kalır.

CLS için 75. yüzdelik dilim 0,1 eşiğinin üstündeyse sorun anlamlıdır. Ancak 75. yüzdelik dilim eşiğin altında ama skor oturum bazlı dalgalanıyorsa - kimi oturumlarda belirgin kayma var, çoğunda yok - kaynak değişken bir harici tetikleyiciye işaret eder. Lab ile alan verisi arasındaki bu tür kopukluk yalnızca CLS'de değil, diğer metriklerde de benzer yorumu gerektirir.

Search Console Core Web Vitals raporu sayfa grubu bazında bu dağılımı gösterir. Belirli bir sayfa şablonu veya kategori tutarlı biçimde kötüyse, o şablona özgü bir bileşen aday olabilir: şablon bazlı reklam konfigürasyonu, sayfa tipine göre değişen embed, farklı font ağırlıkları. Tanılama bu kırılımı görünce odaklanır.

Kaynağa göre müdahale sırası

Kaynağı belirledikten sonra müdahale sırası, kaymaya katkı büyüklüğüne göre şekillenir. Reklam slotu boyutsuzsa CSS rezervasyonu ilk adımdır; düşük maliyetli ve hemen doğrulanabilir bir değişikliktir. Font kayması varsa size-adjust ile metrik dengeleme veya font-display: optional değeri ikinci sıradaki uygulamadır.

Embed sorununun çözümü biraz daha bağlam gerektirir. React veya Next.js tabanlı projelerde embed kapsayıcıları bazen dinamik yükseklikle render edilir; bu durumda aspect-ratio ile sabit oran tanımlamak işe yararken, içeriğin boyutunun değişken olduğu durumda önce render sonra boyut ayarlaması yapan bir iskelet ekranı daha temiz sonuç verir.

JavaScript ile eklenen dinamik öğeler için ise en güvenli yol, alanı önceden rezerve etmek ve içeriği geldiğinde alanı doldurtmaktır. Büyük bir banner için sayfanın üstünde sabit yükseklikte bir yer tutucusu açmak, banner gelince bu alanı doldurmak CLS üretmez. WordPress tabanlı sitelerde bu tür banner enjeksiyonları çoğu zaman eklentilerden gelir ve tema katmanında çözümlenmesi gerekir.

Tutarsız CLS, deterministik olmayan bir sorunun semptomu olduğu için tek bir ölçümle kapatmak güçtür. Birden fazla koşulda - farklı ağ hızı, önbellek temizlenmiş ve önbellek dolu, farklı ekran genişliği - ayrı ayrı test etmek kaynağı görünür kılar. Bu test protokolünü aylık ölçüm planına eklemek, kaymayı taşıyan bir deploy'un fark edilmeden geçmesini engeller.

Kayma kaynağı bulununca doğrulama aynı koşullar altında tekrar ölçümle yapılır. Rezervasyon veya geciktirme düzeltmesi sayfaya uygulandıktan sonra hem lab ortamında hem de alan verisinde CLS'in istikrar kazanması beklenir. Alan verisi CrUX verisi olduğundan değişimi görmek birkaç gün sürebilir; bu arada DevTools kayıtları anlık onay için yeterlidir.

Dinamik elementlerin CLS'e katkısı her zaman kasıtlı değildir; bir reklam ağı konfigürasyon değişikliği veya A/B test aracının güncellenmesi sahneye sessizce girebilir. Bu nedenle regresyon izleme deploy sonrası rutin bir adım olmalıdır; skor iyi çıkıyor diye tutarsızlık araştırmasını ertelemek, gerçek kullanıcı deneyimini görmezden gelmek anlamına gelir.