Core Web Vitals İyileştirme: LCP, CLS ve INP Rehberi | ADWEBX

Google Search Console'unuzda 'Yetersiz URL' uyarısı büyüyorsa ya da PageSpeed Insights raporunuzda kırmızı metrikler görüyorsanız, büyük olasılıkla Core Web Vitals eşiklerini karşılayamıyorsunuzdur. Bu yalnızca bir teknik sorun değil; doğrudan arama sıralamanızı, hemen çıkma oranınızı ve sonuçta gelir kaybınızı etkileyen ölçülebilir bir kullanıcı deneyimi sorunudur. Bu rehberde LCP, CLS ve INP'in ne anlama geldiğini, neden kritik olduklarını ve somut adımlarla nasıl düzeltilebileceklerini bulacaksınız.

Core Web Vitals nedir ve Google sıralamasını nasıl etkiler?

Core Web Vitals, Google'ın 2021 yılında resmi bir sıralama sinyali olarak duyurduğu üç metrikten oluşan performans çerçevesidir. Bu metrikler; yükleme hızını, görsel kararlılığı ve etkileşim yanıt hızını sayısal biçimde ölçerek kullanıcı deneyimini nesnel veriye dönüştürür. Google'ın kendi açıklamalarına göre, bu sinyaller içerik kalitesi, backlink profili ve mobil uyumluluk gibi daha köklü faktörlerin önüne geçmez; ancak iki benzer sayfada belirleyici tie-breaker görevi görür.

Daha önemli olan ikincil etki: düşük Core Web Vitals skorları kullanıcıların sayfadan hızla ayrılmasına yol açar, bu da oturum süresi ve sayfa etkileşim sinyallerini olumsuz etkiler. Google'ın bu davranış sinyallerini sıralama hesabına kattığı bilinmektedir. Özetle Core Web Vitals hem doğrudan hem dolaylı bir sıralama faktörüdür.

Google web.dev'e göre üç temel eşik şöyledir: LCP (Largest Contentful Paint) 2,5 saniyenin altında 'İyi', 2,5-4 saniye arası 'Geliştirilmeli', 4 saniyenin üzeri 'Zayıf' olarak değerlendirilir. INP (Interaction to Next Paint) 200 milisaniyenin altında 'İyi', 200-500 milisaniye arası 'Geliştirilmeli', 500 milisaniyenin üzeri 'Zayıf'tır. CLS (Cumulative Layout Shift) 0,1'in altı 'İyi', 0,1-0,25 arası 'Geliştirilmeli', 0,25'in üzeri 'Zayıf' kabul edilir.

LCP neden yüksek çıkar ve nasıl düşürülür?

LCP, tarayıcının görünür alan içindeki en büyük içerik öğesini — çoğunlukla bir kapak görseli, hero bölümü veya büyük bir başlık — ne kadar sürede boyandığını ölçer. Türkiye'deki KOBİ sitelerinde LCP'yi etkileyen başlıca sebepler sıkıştırılmamış veya boyutlandırılmamış görsel dosyaları, render-blocking JavaScript ve CSS kaynakları, yavaş sunucu yanıt süreleri (TTFB) ve LCP kaynağına yönelik eksik preload direktifleridir.

LCP iyileştirmesi için öncelikle doğru soruyu sormalısınız: sayfanızın LCP öğesi hangisi? PageSpeed Insights veya Chrome DevTools ile bunu saniyeler içinde tespit edebilirsiniz. LCP öğesi bir görsel ise WebP veya AVIF formatına geçin ve srcset ile boyut belirtin. Görsel ise mutlaka fetchpriority='high' ve preload kullanın. Sunucu yanıtı yavaşsa CDN veya edge cache devreye alın.

• Görselleri WebP/AVIF'e çevirin, next-gen format kullanımı LCP süresini belirgin biçimde azaltır
• LCP öğesi için <link rel='preload'> direktifi ekleyin — kaynak keşfini erken başlatır
• Render-blocking kaynakları (kritik olmayan CSS/JS) defer veya async edin
• Sunucu TTFB'sini ölçün; 600 ms üzerindeyse CDN veya sunucu konumu değişikliği değerlendirin
• Lazy-load'u yalnızca ekran altı görsellere uygulayın; LCP öğesine uygulanan lazy-load skoru doğrudan bozar
• Büyük birinci taraf font dosyaları için font-display: optional veya swap tercih edin

E-ticaret sitelerinde özellikle dikkat edilmesi gereken nokta şudur: ürün listeleme sayfalarındaki ilk görsel genellikle LCP öğesidir ve dinamik olarak yüklenir. Sayfa mimarisini bu gerçeği göz önünde bulundurarak kurgulamak, özellikle Next.js gibi SSR çerçevelerinde kritik bir tasarım kararıdır.

CLS sayfanızı nasıl bozar, çözüm nedir?

CLS, sayfa yüklenirken veya etkileşim sırasında görsel öğelerin beklenmedik biçimde kaymasını ölçer. Kullanıcı deneyimi açısından en rahatsız edici sorunlardan biridir: bir butona tıklamak üzereyken reklam bloğu sayfayı iteler ve yanlış butona basarsınız. Google web.dev'e göre 0,1 eşiğini aşmak sıralama kaybına yol açar.

CLS'nin başlıca nedenleri boyutu belirtilmemiş görseller ve video öğeleri, geç yüklenen reklamlar veya embed'ler, dinamik olarak eklenen içerik (bildirim bantları, cookie popup'ları) ve FOUT (Flash of Unstyled Text) sorununa yol açan web fontlarıdır.

• Tüm <img> ve <video> öğelerine width ve height nitelikleri ekleyin; tarayıcı yerini önceden ayırır
• Reklam ve embed slotları için sabit boyutlu alan rezerve edin, içerik onları itemesin
• Font yüklenmesi sırasında FOUT önlemek için font-display: optional kullanın veya kritik fontları preload edin
• Cookie banner ve bildirim çubukları için position: fixed tercih edin; sayfa akışını bozmazlar
• Geç yüklenen dinamik içerikler için min-height değeri belirleyin

Sitenizin CLS değerini ölçmek için Chrome DevTools'un Performance sekmesi veya Web Vitals uzantısı kullanılabilir. Ancak asıl önemli olan laboratuvar değil, gerçek kullanıcı verisindeki CLS'dir. Bu ayrımı bir sonraki bölümde ele alacağız.

Sitenizin Core Web Vitals metriklerini düzeltmek için teknik bir ekibe ihtiyaç duyuyorsanız ADWEBX'in teknik SEO hizmetini inceleyebilir ya da /analiz sayfasından ücretsiz site analizi talep edebilirsiniz. WhatsApp üzerinden de ulaşabilirsiniz: 905322477388. Sorunun kaynağını bulmak genellikle birkaç saatlik ciddi analiz gerektiriyor; doğru tespit olmadan yapılan düzeltmeler metriği iyileştirmiyor.

INP nedir, FID'in yerini neden aldı?

INP (Interaction to Next Paint), kullanıcının sayfayla etkileşime geçmesinden (tıklama, dokunma veya klavye girişi) tarayıcının ekranda bir sonraki güncellemeyi göstermesine kadar geçen toplam gecikmeyi ölçer. Mart 2024'te FID (First Input Delay) resmi olarak kaldırılmış, yerini INP almıştır. Bu güncellemeyi henüz takip etmemiş ekiplerin raporlarında hâlâ FID referansı görebilirsiniz; raporlarınızı bu açıdan gözden geçirmenizi öneririz.

FID yalnızca sayfanın ilk etkileşimine bakarken INP, oturum boyunca tüm etkileşimlerin en kötüsünü raporlar. Bu nedenle INP çok daha kapsamlı bir ölçüttür. Google web.dev'e göre INP 200 milisaniyenin altında 'İyi' kabul edilir.

Yüksek INP genellikle şu nedenlere bağlıdır: ana iş parçacığını (main thread) bloke eden uzun JavaScript görevleri, React veya Vue gibi çerçevelerde ağır re-render döngüleri, etkileşim tetikleyicili network istekleri ve input handler içindeki ağır DOM güncellemeleridir.

• Chrome DevTools'un Performance sekmesiyle uzun görevleri (Long Tasks, 50ms üzeri) tespit edin
• Kritik olmayan JavaScript'i parçalara bölün (code splitting) ve async yükleyin
• React uygulamalarında gereksiz re-render'ları önlemek için useMemo ve useCallback kullanın
• Etkileşim başına tetiklenen DOM manipülasyonlarını batch hale getirin
• Üçüncü taraf script'leri (chat widget, analytics, reklam tag'leri) facade pattern ile yükleyin

INP iyileştirme teknikleri çoğunlukla JavaScript mimarisine dokunmayı gerektirir. E-ticaret ve kurumsal web sitelerinde bu iş frontend geliştirici müdahalesi olmadan çözülemiyor. ADWEBX'in e-ticaret SEO ve web uygulama geliştirme hizmetleri bu teknik boyutu kapsamaktadır.

Lab verisi mi gerçek kullanıcı (CrUX) verisi mi? Hangi araç?

Core Web Vitals ölçümünde iki farklı veri kaynağı vardır ve bunların arasındaki farkı anlamak kritik önemdedir. Lab verisi (laboratuvar verisi), PageSpeed Insights veya Lighthouse gibi araçların simüle edilmiş koşullarda tek seferlik çalıştırdığı testin sonucudur. Hızlı bir iyileştirme yapıp aracı yeniden çalıştırdığınızda anında değişim görürsünüz. Gerçek kullanıcı verisi ise Chrome kullanıcılarından toplanan ve CrUX (Chrome User Experience Report) adı verilen veri setine aktarılan gerçek oturum ölçümlerinden oluşur.

Google'ın sıralama algoritmasında kullandığı veri CrUX verisidir; yani lab skorunuzu 100'e çıkarmanız Google'ın sizi hemen ödüllendireceği anlamına gelmez. CrUX, son 28 güne ait gerçek kullanıcı oturumlarının 75. yüzdelik dilimine bakarak 'İyi', 'Geliştirilmeli' veya 'Zayıf' kararını verir. Siteye yeterli trafik gelmiyorsa CrUX veri tabanında sitenize ait kayıt olmayabilir ve Search Console'da 'yetersiz veri' uyarısı görürsünüz.

• PageSpeed Insights: Hem lab (Lighthouse) hem CrUX (field data) sonuçlarını tek ekranda gösterir — başlangıç noktanız burası olmalı
• Google Search Console Core Web Vitals raporu: Sitenizin URL grupları bazında CrUX sağlıklı/kötü/iyileştir dağılımını gösterir
• Chrome DevTools (Performance sekmesi): Uzun görevleri, render-blocking kaynakları, LCP öğesini tespit eder
• web-vitals JS kütüphanesi: Gerçek kullanıcı oturumlarından CWV metriklerini toplayıp Analytics veya özel dashboard'a göndermenizi sağlar
• CrUX Dashboard (Looker Studio): Aylık CrUX trendlerini alan adı bazında görselleştirir

Pratikte önerilen yaklaşım şudur: Search Console Core Web Vitals raporunda 'Zayıf' veya 'Geliştirilmeli' URL'leri tespit edin, PageSpeed Insights ile tek tek inceleyin, DevTools ile sorun kaynağını pinpoint edin, düzeltmeyi yapın ve 28 gün içinde CrUX trendini izleyin.

İyileştirme sonuçları sıralamaya ne zaman yansır?

Bu soru müşterilerin en sık sorduğu ve yönetilmesi en güç beklenti konusudur. CrUX verisi, son 28 günlük gerçek kullanıcı oturumlarının 75. yüzdelik dilimine bakarak güncellenir. Bir düzeltme yaptığınızda yeni oturumlar eski oturumların yerini almaya başlar; ancak 28 günlük pencerenin tamamen dolması gerekir. Bu, ciddi bir iyileştirme yapıp Search Console'da değişim görmek için en az 4 hafta beklemeniz gerektiği anlamına gelir.

Arama sıralamalarına yansıma ise biraz daha karmaşık bir süreçtir. Google, Core Web Vitals değişikliklerini sıralama hesabına aylık crawl ve indeks döngüleri içinde dahil eder. Dolayısıyla CrUX verisinin iyileşmesinden sonra organik sıralama hareketlerini fark etmek 6-12 haftalık bir zaman dilimi gerektirebilir. Bu bekleme süresini yönetmenin en iyi yolu lab verisi araçlarıyla ilerlemeyi haftalık takip etmek, CrUX trendini aylık raporlamak ve yalnızca CWV'ye değil genel teknik SEO sağlığına yatırım yapmaktır.

Düzeltme yaptıktan sonra sayfanın Googlebot tarafından yeniden crawl edilmesi için Search Console'dan URL denetimi ve yeniden dizine ekleme talebinde bulunmak süreci biraz hızlandırabilir. Ancak CrUX verisinin birikmesini hızlandıracak bir yol yoktur — bu tamamen gerçek kullanıcı trafiğine bağlıdır.

Core Web Vitals iyileştirme yol haritası çıkarmak, sorunları önceliklendirmek ve düzeltmeleri uygulamak için teknik bir ekiple çalışmak istiyorsanız /analiz sayfasından ücretsiz site analizi talep edebilirsiniz. ADWEBX olarak İstanbul merkezli teknik SEO hizmeti sunuyor; e-ticaret ve kurumsal siteler başta olmak üzere CWV iyileştirme projelerinde uygulama boyutunu da üstleniyoruz. WhatsApp'tan ulaşabilirsiniz: 905322477388.

Sık Sorulan Sorular

Core Web Vitals'ı geçmek Google sıralamasını garanti eder mi?

Hayır. Core Web Vitals iyi bir kullanıcı deneyimi için gerekli ama yeterli değildir. Google'ın sıralama sistemi 200'den fazla sinyal kullanır; içerik kalitesi, E-E-A-T, backlink profili ve arama niyeti uyumu CWV'nin önünde gelmektedir. Ancak rekabetçi bir anahtar kelimede iki benzer sayfa arasında CWV bir tie-breaker görevi görür.

PageSpeed Insights'ta 100 puan almak yeterli mi?

Hayır. PageSpeed Insights 100 puanı lab (simüle edilmiş) ortamda elde edilmiş bir skordur. Google'ın sıralamaya kullandığı veri CrUX adı verilen gerçek kullanıcı verisidir. Lab puanı 100 olsa bile düşük trafik nedeniyle CrUX eşiğini karşılamayan siteler 'yetersiz veri' durumunda kalabilir ya da gerçek kullanıcılar ağır cihaz ve bağlantı koşullarında daha kötü deneyim yaşayabilir.

INP ile FID arasındaki fark nedir?

FID yalnızca sayfanın ilk kullanıcı etkileşimine verilen yanıtı ölçerken INP, oturum boyunca gerçekleşen tüm etkileşimlerin en yüksek gecikmesini raporlar. Bu nedenle INP çok daha kapsamlı ve yanıltması daha zor bir metriktir. Google web.dev, INP'i Mart 2024'te resmi Core Web Vitals metriği olarak belirledi ve FID'i kaldırdı.

WordPress sitem için Core Web Vitals'ı iyileştirmek ne kadar sürer?

Sorunun kaynağına bağlıdır. LCP görsel optimizasyonu ve CLS boyut düzeltmeleri gibi yüzeysel sorunlar bir geliştirici günüyle çözülebilir. Ancak render-blocking kaynak analizi, JavaScript bölme veya sunucu altyapısı değişikliği gerektiren sorunlar 1-3 haftalık teknik çalışma anlamına gelebilir. Üçüncü taraf scriptler (reklam, chat, izleme araçları) sıklıkla INP ve LCP'yi etkiler; bunların denetimi de sürece dahildir.

CLS sorunumu nasıl tespit ederim?

Chrome DevTools Performance sekmesinde kaydı çalıştırın ve Layout Shift olaylarını işaretleyin; hangi öğenin kaydığını görebilirsiniz. Daha hızlı bir yöntem olarak Chrome Web Store'dan Web Vitals uzantısını indirin — sayfayı açtığınızda CLS değerini ve hangi öğenin sebep olduğunu anlık olarak gösterir. Search Console Core Web Vitals raporundaki 'Zayıf' URL listesi de başlangıç noktası olarak kullanılabilir.