Cumulative Layout Shift (CLS) Nedir? Nasıl İyileştirilir?

Cumulative Layout Shift nedir?

Cumulative Layout Shift (CLS), sayfa yüklenirken ve kullanıcı sayfada kaldığı sürece görünen öğelerin beklenmedik biçimde yer değiştirmesini ölçen Core Web Vitals metriğidir. Skor ne kadar düşükse sayfa o kadar kararlı davranır. Google 0,1 ve altını iyi kabul eder.

Gündelik dilde anlatalım: bir haberi okurken görsel geç gelir ve metin aşağı kayar. Tam bir düğmeye basacakken reklam belirir ve yanlış yere tıklarsınız. Bu iki deneyimin ortak adı layout shift, yani düzen kayması.

Ekibimizin saha çalışmalarında gördüğü şu: kullanıcı kaymayı çoğu zaman adlandıramaz ama hisseder. Sayfaya güveni azalır ve çıkar. Bu yazıda ölçümü, eşikleri, nedenleri ve düzeltmeleri web.dev kaynaklarıyla birlikte adım adım ele alıyoruz.

LCP ve INP konusunu burada ayrıntılı anlatmıyoruz; üçünü birlikte görmek isterseniz Core Web Vitals rehberimiz sizi doğru yere götürür. Burada odağımız yalnızca görsel kararlılık.

Cumulative Layout Shift neden önemlidir?

CLS önemlidir, çünkü kullanıcıyı doğrudan hataya iter. Yanlış tıklama, kaybolan okuma yeri ve ödeme adımında beklenmedik kayma ilk akla gelen örneklerdir. Üstelik bu sorunlar dönüşümü düşürür.

İkinci boyut aramadır. Google, Core Web Vitals metriklerini sayfa deneyimi sinyalleri arasında değerlendirir. Ancak tek başına CLS'yi düzeltmek sıralamayı mucizevi biçimde yükseltmez; içerik alaka düzeyi her zaman önde gelir. Yine de iki benzer sayfa arasında deneyim farkı yaratabilir.

Hız ile ilişkisi için site hızının SEO etkisini anlattığımız yazıya da göz atabilirsiniz. Şu üç nedenle CLS'ye öncelik vermenizi öneririz:

• Yanlış tıklama kaynaklı hayal kırıklığını azaltır.
• Formlarda ve ödeme adımlarında terk oranını düşürmenize yardım eder.
• Teknik borcu erkenden görünür kılar, böylece ileride maliyet büyümez.

Kısacası CLS, küçük görünen ama güveni doğrudan etkileyen bir kalite göstergesidir. Üstelik düzeltmesi, diğer iki metriğe göre çoğu zaman daha ucuzdur. Bir görsele iki öznitelik eklemek, bir sunucuyu yeniden kurmaktan çok daha az emek ister.

Ayrıca kaymalar marka algısını da etkiler. Sayfası zıplayan bir kurumsal site, içerik ne kadar iyi olursa olsun özensiz görünür. Kurumsal siteler için bu, ciddi bir itibar meselesidir.

Cumulative Layout Shift skorunu nasıl hesaplarsınız?

Tek bir kayma için skoru şu formülle bulursunuz: etki oranı çarpı mesafe oranı. web.dev bunu layout shift score = impact fraction * distance fraction diye tanımlar.

Etki oranı, kararsız öğelerin iki kare arasında görüntü alanının ne kadarını etkilediğini gösterir. Mesafe oranı ise kararsız öğenin en çok hareket ettiği yatay ya da dikey mesafeyi, görüntü alanının en büyük boyutuna böler.

Şimdi bir örnek hesap yapalım (varsayımsal değerlerdir, gerçek bir siteye ait değildir). Bir görsel geç gelince altındaki içerik görüntü alanının yarısını etkilesin; yani etki oranı 0,5 olsun. İçerik ekran yüksekliğinin yüzde 20'si kadar aşağı insin; yani mesafe oranı 0,2 olsun. Skor 0,5 x 0,2 = 0,10 çıkar.

Sonuç olarak tek bir görsel bile sayfanızı eşiğe taşıyabilir. Bu nedenle küçük görünen kaymaları ciddiye almanız gerekir. Kaymalar birikir; dolayısıyla tek seferlik değil, toplam deneyim önemlidir.

Sayfada art arda üç kayma yaşarsanız her birinin skoru aynı pencerede toplanır. Örneğin 0,04 + 0,05 + 0,03 = 0,12 eder ve tek başına masum görünen üç kayma sizi eşiğin üstüne çıkarır.

Hangi CLS değeri iyi, hangisi kötü?

web.dev, sitelerin sayfa yüklemelerinin en az yüzde 75'inde CLS değerini 0,1 veya altında tutmayı hedeflemesini söyler. Yani değerlendirmeyi 75. yüzdelik dilim üzerinden yaparsınız; ortalama üzerinden değil.

Mobil ve masaüstü ayrı ölçülür. Mobilde ekran küçük olduğu için aynı kayma daha büyük etki oranı üretir; bu yüzden mobil skorunuz çoğu zaman daha kötü çıkar.

Bu eşikleri hedef olarak görün, mutlak hüküm olarak değil. Önemli olan trendin iyiye gitmesi ve gerçek kullanıcı verisinde 75. yüzdelikte yeşile ulaşmanızdır.

Örneğin masaüstünde 0,05, mobilde 0,22 görüyorsanız öncelik açıkça mobildir. Çünkü Google'ın değerlendirmesinde en zayıf halka belirleyici olur.

Bu yüzden raporlarken yalnızca tek bir sayı vermeyin. Mobil ve masaüstü değerlerini, hangi URL gruplarının etkilendiğini ve trendin yönünü birlikte sunun. Böylece karar vericiler önceliği daha kolay görür.

Kayma penceresi (session window) nedir?

Kayma penceresi, birbirine yakın gerçekleşen kaymaları tek grup sayan ölçüm birimidir. web.dev'e göre kaymalar arasında en fazla 1 saniye boşluk olur ve toplam pencere süresi en fazla 5 saniyedir.

CLS değeri, sayfa ömründeki en büyük pencerenin toplam skorudur. Yani sayfanın tüm ömrü boyunca biriken bütün kaymaları toplamazsınız; en kötü kayma öbeği esas olur.

Bu tanım uzun süre açık kalan sayfalar için önemlidir. Tek sayfalı uygulamalarda ve sonsuz kaydırmada eski yaklaşım, sayfa açık kaldıkça skoru şişirebiliyordu. Pencere yaklaşımı bu haksızlığı azaltır.

Pratik sonuç şu: sayfa açılışındaki kaymaları temizlemek kadar, kaydırma sırasında beliren öğeleri de kontrol etmelisiniz. Çünkü en kötü pencere, sayfanın ortasında da doğabilir.

Hangi kaymalar CLS hesabına girmez?

Kullanıcı etkileşiminden sonraki 500 milisaniye içinde gerçekleşen kaymalar beklenen kayma sayılır. Tıklama, dokunma ve klavye girişi bu kapsamdadır; tarayıcı bu kaymalarda hadRecentInput bayrağını işaretler ve CLS'ye eklemez.

Kaydırma, sürükleme ve çimdikleme gibi sürekli etkileşimler bu istisnaya girmez. Yani kullanıcı kaydırırken içerik zıplarsa skorunuza yansır.

Bu kural size bir tasarım ilkesi de verir. Kullanıcı bir düğmeye bastıktan sonra menünün açılması gibi beklenen değişiklikler sorun değildir. Buna karşılık kullanıcı bir şey yapmadan beliren öğeler sorundur.

• Kullanıcı tıklayınca açılan akordeon: hesaba girmez.
• Sayfa açılınca kendiliğinden beliren banner: hesaba girer.
• Sonsuz kaydırmada gelen kartlar: alan ayırmadıysanız hesaba girer.

Dolayısıyla bir içeriği kullanıcı eylemine bağlamak, CLS'yi düşürmenin hem ucuz hem de güvenilir yoludur.

CLS'yi nasıl ölçersiniz?

CLS'yi iki yolla ölçersiniz: laboratuvar ve saha verisi. Laboratuvar aracı kontrollü bir yüklemede skoru verir. Saha verisi ise gerçek ziyaretçilerin yaşadığı deneyimi yansıtır.

Başlangıç için şu araçları kullanabilirsiniz:

• PageSpeed Insights: gerçek kullanıcı verisini (CrUX) ve laboratuvar sonucunu yan yana gösterir.
• Chrome DevTools Performance paneli: Layout Shifts izinde kaymaları mor çubuklarla gösterir.
• Lighthouse: boyutsuz görselleri ve kayan öğeleri listeler.
• Search Console Core Web Vitals raporu: hangi URL gruplarının sorunlu olduğunu topluca gösterir.

Lighthouse kullanımı için Lighthouse ile performans testi yazımıza bakabilirsiniz. Ayrıca Chrome'un canlı ölçüm görünümü, sayfayla etkileşirken CLS'yi anlık izlemenize yardım eder.

Önce saha verisine bakın, sonra laboratuvarda nedeni bulun. Sırayı tersine çevirirseniz var olmayan sorunları kovalarsınız.

Saha ve laboratuvar CLS verisi neden farklı çıkar?

Laboratuvar testi tek bir cihazda, tek bir bağlantıyla ve genellikle sayfanın ilk açılışında çalışır. Gerçek kullanıcılar ise sayfayı kaydırır, çerez bannerını kapatır, sekmeler arasında dolaşır ve farklı cihazlar kullanır.

Bu yüzden laboratuvarda 0,02 görürken sahada 0,18 görmeniz şaşırtıcı değildir. Fark genellikle şu kaynaklardan gelir:

• Kaydırma sırasında geç gelen reklamlar ve gömülü içerikler.
• Çerez izni ya da kişiselleştirme betiklerinin yalnızca gerçek kullanıcıda çalışması.
• Yavaş bağlantıda fontların geç gelmesi.
• Farklı ekran boyutlarında değişen görsel oranları.

Dolayısıyla laboratuvar sonucunu yeşil görmek yeterli değildir. Kaymayı yeniden üretmek için ağı yavaşlatın, önbelleği temizleyin ve sayfayı aşağı kaydırarak test edin.

Saha verisi de zaman alır; CrUX verisi gün gün değil, toplu bir dönem üzerinden çalışır. Düzeltme yaptıktan sonra sonucu hemen beklemeyin.

CLS'nin en yaygın nedenleri nelerdir?

web.dev'in optimizasyon rehberi dört ana neden sayar: boyutsuz görseller, boyutsuz reklam ve gömülü içerikler, dinamik eklenen içerik ve web fontları. Bunlara animasyon hatalarını da eklemek gerekir.

Bu nedenlerin çoğu tek bir ortak köke dayanır: tarayıcı, içeriğin ne kadar yer kaplayacağını önceden bilmez. Dolayısıyla her çözümün özü aynıdır; yer kaplayacak her şey için boyutu önceden bildirmek.

Sırada bu nedenlerin her birini ayrı ayrı ele alıyoruz. Önce en sık karşılaştığımız olan görsellerle başlayalım.

Boyutsuz görseller CLS'yi nasıl bozar?

Tarayıcı, görselin boyutunu bilmezse yer ayırmaz. Görsel inince içerik aşağı kayar. Bu, CLS'nin en sık görülen ve en kolay çözülen nedenidir.

Çözüm basit: her img ve video öğesine width ve height özniteliklerini yazın. Modern tarayıcılar bu değerlerden en boy oranını hesaplar ve görsel gelmeden önce alanı ayırır. CSS'te genişliği yüzde 100 yapsanız bile oran korunur.

Duyarlı görsellerde srcset varyantlarının aynı en boy oranını taşıdığından emin olun. Oranlar farklıysa tarayıcı, gelen varyantta yine kayma yaratabilir.

Boyutsuz görselleri yakalamak için Lighthouse raporuna bakın. Dosya boyutunu küçültmek ayrı bir konudur; ayrıntı için görsel optimizasyonu rehberimizi okuyabilirsiniz.

Lazy load kullanıyorsanız da boyut bilgisini atlamayın. Tembel yükleme gecikmeyi azaltır ama alan ayırmazsanız kayma riskini artırır.

Reklam, gömme ve iframe alanlarını nasıl ayırırsınız?

Reklam alanları, video gömmeleri ve sosyal medya widget'ları çoğu zaman boyutsuz gelir. İçerik geç dolduğunda altındaki her şey aşağı iner.

web.dev şu yaklaşımı önerir: min-height ya da aspect-ratio ile önceden alan ayırın ve geç gelen içeriği görünür alanın daha aşağısına yerleştirin. Kullanıcı etkileşimi olmadan içerik enjekte etmek yerine yer tutucu kullanın.

Reklam ağlarında birden fazla boyut dönebilir. Bu durumda en sık dönen boyuta göre alan ayırın. Reklam gelmezse boş alan kalır; ancak boş alan, aşağı inen içerikten daha az zarar verir.

• Gömülü video için aspect-ratio: 16 / 9 gibi bir oran tanımlayın.
• Harita ve sosyal medya gömmelerine sabit yükseklik verin.
• Sayfanın üst kısmına geç dolan reklam koymaktan kaçının.

Gelir ile deneyim arasında denge kurmak gerekir; bu dengeyi kurarken kısa süreli gelir kaybını uzun vadeli güvenle karşılaştırın.

Web fontları CLS'ye nasıl yol açar?

Tarayıcı önce yedek fontla metni çizer, web fontu gelince yeniden çizer. İki fontun harf genişlikleri farklıysa satırlar yeniden bölünür ve metin bloğu kayar.

web.dev şu önlemleri sıralar. Kritik fontları link rel=preload ile erkenden yükleyin. font-display: optional değerini kullanarak yeniden yerleşimi tamamen önleyin. Uygun bir yedek font seçin ve size-adjust ile ascent-override gibi ayarlarla yedek fontu web fontuna yaklaştırın.

Font seçimi de performansı etkiler. Tipografi tarafı için web tipografisi yazımıza göz atın. Ayrıca gereksiz ağırlıkları (örneğin kullanmadığınız italik ve ultra ince stilleri) yüklemeyi bırakın; böylece hem hız kazanır hem de kayma ihtimalini azaltırsınız.

Dinamik içerik ve çerez bannerları kayma yapar mı?

Evet, yapabilir. Çerez bannerı sayfanın üstüne eklenirse tüm içeriği aşağı iter. Benzer biçimde bildirim çubukları, abonelik kutuları ve kampanya şeritleri de kayma üretir.

Çözüm, bu öğeleri akışın dışına almaktır. Banner'ı sayfanın altına sabitleyin ya da üstte baştan bir alan ayırın. Kullanıcı tetiklemesi gerektiren içeriklerde, örneğin Daha Fazla Yükle düğmesinde, yeni içerik kullanıcı girişinden sonra geldiği için kayma hesabına girmez.

Açılır pencereler için ayrıca çıkış niyeti pop-up'larını inceleyebilirsiniz; doğru tasarlanan pop-up akışı itmez, üzerine biner.

• Banner'ı sabit konumlu yapın ve içeriği itmesini engelleyin.
• Yeni içeriği sabit boyutlu bir kapsayıcıda yenileyin.
• Sunucudan gelen geç içeriği kullanıcı eylemine bağlayın.

Animasyonlar CLS'yi nasıl etkiler?

Top, left, box-shadow ve box-sizing gibi özellikleri animasyonla değiştirdiğinizde tarayıcı yerleşimi yeniden hesaplar ve çevredeki öğeler kayabilir. Bu kaymalar skorunuza yansır.

web.dev'in çözümü nettir: animasyonlarda transform kullanın. transform: translate() ve transform: scale() yerleşim akışını değiştirmez; bu yüzden kayma üretmez. Üstelik GPU üzerinde çalıştığı için akıcı da görünür.

Örneğin menüyü yukarıdan indiren bir animasyonda top değerini değiştirmek yerine translateY kullanabilirsiniz. Görsel sonuç aynıdır, ama çevre öğeler yerinde kalır.

Mikro animasyonlar konusunda ilham arıyorsanız mikro animasyon yazımıza bakın.

WordPress ve e-ticaret sitelerinde CLS nasıl düzelir?

Hazır tema ve eklenti kullanan sitelerde kayma çoğu zaman tek bir bileşenden gelir. Slider, pop-up, yorum eklentisi, canlı destek balonu ve ürün görseli galerisi en sık şüphelilerdir.

E-ticarette ürün kartlarının görsellerine boyut vermek, fiyat ve stok bilgisinin geç dolmasını önlemek ve sepet bildirimini sabit alana almak büyük fark yaratır. Ödeme adımındaki kaymanın maliyeti ise doğrudan sipariş kaybıdır.

Teknik tarafta şunları kontrol edin:

• Temanın slider bileşeni yükseklik tanımlıyor mu?
• Yorum ve puan eklentisi içeriği geç mi enjekte ediyor?
• Canlı destek balonu sayfayı itiyor mu, yoksa üzerine mi biniyor?
• Ürün galerisi görsellerinde width ve height var mı?

Platform seçimi hakkında fikir almak için WordPress mi özel kodlama mı yazımızı inceleyebilirsiniz. Kodun sizde olduğu projelerde kaymayı kaynağında düzeltmek, eklenti üstüne eklenti yığmaktan çok daha kalıcıdır.

Tek sayfalı uygulamalarda CLS nasıl ölçülür?

Tek sayfalı uygulamalarda (SPA) sayfa geçişleri tarayıcı yüklemesi sayılmaz. Bu yüzden kullanıcı birçok ekran gezse de tarayıcı bunu tek sayfa ömrü gibi görür.

Kayma penceresi yaklaşımı bu durumu hafifletir, çünkü yalnızca en kötü pencere sayılır. Yine de her rota değişiminde içerik iskeleti (skeleton) kullanmanız ve veriyi beklerken kapsayıcı boyutunu sabit tutmanız gerekir.

Veri gelmeden boş kalan bir liste, veri gelince yüzlerce piksel uzar. Bu nedenle tahmini yükseklikte yer tutucu çizin. Böylece içerik dolduğunda alttaki öğeler yerinde kalır.

Rota geçişlerinde bir başka tuzak, eski içeriği silip yenisini sonradan eklemektir. Eski ekranı yenisi hazır olana kadar yerinde tutmak ya da sabit boyutlu bir kapsayıcı kullanmak, bu sıçramayı ortadan kaldırır.

JavaScript ağırlığı da konuyla bağlantılıdır. Geç çalışan betikler içerik enjekte ederek kayma üretir; ayrıntı için JavaScript ve site hızı yazımıza bakın.

Cumulative Layout Shift'i nasıl iyileştirirsiniz?

Cumulative Layout Shift iyileştirmesini sistematik yürütürsünüz: önce ölçer, sonra en büyük kaymayı bulur, düzeltir ve yeniden ölçersiniz. Aşağıdaki sıra, ekibimizin projelerde izlediği çerçevedir.

1. Search Console'da sorunlu URL gruplarını belirleyin.
2. PageSpeed Insights ile aynı URL'nin saha ve laboratuvar verisini karşılaştırın.
3. DevTools Performance panelinde Layout Shifts izini açın ve en büyük kaymayı bulun.
4. Kaymaya yol açan öğeyi sınıflandırın: görsel, reklam, font, dinamik içerik veya animasyon.
5. Düzeltmeyi uygulayın: boyut öznitelikleri, alan ayırma, font ayarı ya da transform.
6. Yavaş ağda ve mobil cihazda kaymanın gerçekten kalktığını kontrol edin.
7. Saha verisinin güncellenmesini bekleyin ve sonucu raporlayın.

Burada önemli ilke şudur: önce en çok skor üreten tek kaymayı düzeltin. Çoğu sitede birkaç öğe, toplam kaymanın büyük bölümünü oluşturur.

Kod seviyesinde bir örnek: img etiketinde width="800" height="450" yazmak ve CSS'te height: auto kullanmak, oranı korur ve alanı önceden ayırır.

CLS düzeltmelerinde hangi sırayı izlemelisiniz?

Her düzeltme aynı çabayı ve aynı kazancı getirmez. Önceliği belirlemek için etkiyi, çabayı ve riski birlikte değerlendirin. Aşağıdaki tablo, genel bir başlangıç sıralaması sunar; sitenize göre değişebilir.

Bu sıralama saha tecrübesine dayalı bir başlangıç önerisidir, garanti değildir. Gerçek sırayı DevTools'ta gördüğünüz en büyük kayma belirler.

Ayrıca her adımdan sonra yeniden ölçün. Böylece hangi değişikliğin işe yaradığını görür, yaramayanı geri alırsınız.

Geri ve ileri önbellek (bfcache) CLS'yi etkiler mi?

Evet, olumlu yönde etkiler. web.dev'e göre sayfa geri ve ileri önbelleğinden geri gelirse CLS değeri sıfırlanmalıdır, çünkü kullanıcı bunu ayrı bir sayfa ziyareti olarak yaşar.

Bu yüzden bfcache uygunluğunu artırmak, geri tuşuyla dönen kullanıcılarda yeniden yükleme kaynaklı kaymaları tamamen ortadan kaldırır. Sayfanızın bfcache'e uygun olup olmadığını Chrome DevTools'un Application panelinden test edebilirsiniz.

Sayfada unload dinleyicisi kullanmak gibi bazı eski alışkanlıklar uygunluğu bozabilir. Bu nedenle teknik denetimlerinize bfcache kontrolünü ekleyin.

Genel teknik sağlık kontrolü için teknik SEO ipuçları listemize de göz atabilirsiniz.

CLS, LCP ve INP ile nasıl birlikte düşünmelisiniz?

Core Web Vitals üç metrikten oluşur: LCP yükleme hızını, INP etkileşim tepkisini, CLS görsel kararlılığı ölçer. Her biri farklı bir kullanıcı deneyimini yakalar.

Bu yazıda LCP'yi ayrıntılı ele almıyoruz; ancak birbirleriyle çakıştıkları noktaları bilmek yararlıdır. Örneğin hero görselini erken yüklemek LCP'yi iyileştirir, ama görsele boyut vermezseniz CLS'yi bozabilirsiniz.

Benzer biçimde ağır JavaScript hem INP'yi hem de geç enjekte ettiği içerik yüzünden CLS'yi bozabilir. Mobil tarafta ise sorunlar büyür; ayrıntı için mobil öncelikli tasarım yaklaşımına bakın.

Dolayısıyla tek metriğe odaklanıp diğerini bozmayın. Her değişiklikten sonra üçünü birlikte ölçün.

CLS'yi sürekli nasıl izlersiniz?

CLS düzeltmesi bir kez yapıp bırakacağınız iş değildir. Yeni bir eklenti, reklam ağı ya da tema güncellemesi kaymayı geri getirebilir. Bu yüzden izlemeyi rutine bağlayın.

• Search Console Core Web Vitals raporunu aylık kontrol edin.
• Önemli şablonlar için (ana sayfa, kategori, ürün, blog) PageSpeed Insights sonucunu kaydedin.
• Her büyük yayından sonra DevTools'ta hızlı bir kayma kontrolü yapın.
• Yeni reklam ya da üçüncü taraf betik eklemeden önce alan ayırma planını yazın.

Ekip içinde sorumluluğu netleştirin. Tasarımcı boyut ve alan ayırmayı, geliştirici font ve yükleme sırasını, pazarlama ekibi ise reklam ve banner eklemelerini kontrol etsin.

Sonuç olarak iyi CLS, bir kerelik düzeltme değil, yayın sürecine yerleşmiş bir alışkanlıktır.

CLS çalışmasında en sık yapılan hatalar nelerdir?

Denetimlerimizde şu hataları sık görüyoruz:

• Yalnızca laboratuvar skoruna bakmak ve sahadaki gerçek sorunu kaçırmak.
• Görsele width ve height yazıp CSS'te oranı bozmak.
• Reklam alanını ayırmak ama yanlış boyutu seçmek.
• Font yüklemesini düzeltmek yerine fontu tamamen kaldırmak.
• Mobil testini atlamak; oysa mobil skor çoğu zaman daha kötüdür.

Bir diğer hata, tek bir ölçüm anına güvenmektir. Kayma bazen yalnızca belirli bir cihazda ya da belirli bir bağlantı hızında görünür. Bu yüzden birkaç senaryoyla test edin.

Son olarak, yalnızca skora odaklanmayın. Sayfayı gerçek bir kullanıcı gibi açın, kaydırın ve düğmelere basın. Skor iyi olsa da kendinizi rahatsız eden bir zıplama varsa, kullanıcınız da aynısını yaşıyordur.

Örnek bir sayfada CLS teşhisi nasıl görünür?

Varsayımsal bir örnek üzerinden ilerleyelim (örnek senaryo, gerçek bir müşteriye ait değildir). Bir blog şablonunun mobil CLS değeri 0,21 çıkıyor ve Search Console sayfayı iyileştirme gerekli grubunda gösteriyor.

DevTools Performance panelinde Layout Shifts izini açtığınızda üç kayma görürsünüz. İlki kapak görselinin geç gelmesi, ikincisi çerez bannerının üstten eklenmesi, üçüncüsü ise yazı fontunun değişmesidir.

Bu tablodaki değerler örnek hesaptır. Toplam 0,21 eder; yalnızca görsel düzeltmesi bile sayfayı 0,09'a indirir ve eşiğin altına taşır.

Dikkat ederseniz en büyük kazanç, en basit düzeltmeden gelir. Bu yüzden teşhiste önce en büyük kaymaya bakarsınız; ardından kalanları sırayla kapatırsınız. Böylece her adımın etkisini ayrı ayrı görür, raporlarken de net bir hikaye anlatırsınız.

Ne zaman uzman desteği almalısınız?

Sorun tek bir görselden ibaretse kendiniz çözebilirsiniz. Ancak kayma tema, eklenti ve üçüncü taraf betiklerin birleşiminden geliyorsa nedeni bulmak zaman alır.

Talha Aslan ve ekibi olarak teknik SEO denetimlerinde CLS'yi saha verisiyle birlikte inceliyoruz. Gerekirse web tasarım tarafında şablonu yeniden kuruyor, SEO danışmanlığı kapsamında izleme süreci tanımlıyoruz.

Çalışmaya başlamadan önce hedefi netleştiriyoruz: hangi şablonlar, hangi cihazlar ve hangi eşik. Böylece iyileştirmenin sonunda ölçülebilir bir karşılaştırma sunabiliriz. İş bittikten sonra da izleme listesini size teslim ederiz.

Hazırlık olarak Search Console raporunuzu, kullandığınız eklenti listesini ve reklam ağlarınızı bir araya getirin; böylece ilk görüşmede doğrudan nedene inebiliriz.

Kaynaklar: web.dev CLS, web.dev CLS optimizasyonu ve Google Search Central Core Web Vitals sayfalarıdır.