Search Console'da Core Web Vitals raporunu açtığınızda sayfalarınızın büyük kısmı "kötü" veya "iyileştirme gerekli" kategorisinde görünüyorsa yalnız değilsiniz. Birçok site bu metriklerle ilk kez karşılaştığında benzer bir tabloyla yüzleşiyor. Google bu metrikleri sıralama sinyali olarak kullanıyor ve "kötü" kategorisindeki sayfalar organik aramada geriye düşüyor. Teknik görünse de arkasındaki mantık basit: sayfa hızlı yükleniyor mu, etkileşimlere hızlı yanıt veriyor mu, yüklenirken içerik kayıyor mu?
Üç soru. Üç metrik. Her birinin kendine özgü eşik değerleri ve farklı teknik müdahaleleri var.
LCP: sayfanın en büyük öğesi ne kadar hızlı yükleniyor?
Largest Contentful Paint, sayfadaki en büyük görünür içerik öğesinin render süresini ölçer. Hero görseli, geniş bir metin bloğu, video poster'ı; hangisi piksel olarak en çok yer kaplıyorsa LCP öğesi o. Google'ın çizdiği sınır net: 2,5 saniyenin altı "iyi", 4 saniyeyi geçen her şey "kötü".
LCP'yi yavaşlatan dört temel sorun var ve bunların her biri farklı bir katmanda çözülüyor.
Sunucu yanıt süresi. İlk byte geç geliyorsa render da geç başlar, bu kadar basit. TTFB (Time to First Byte) değeriniz 200 milisaniyeyi aşıyorsa sunucu tarafında bir şeyler ters demektir. Önbellekleme katmanı eklemek, CDN'e geçmek veya veritabanı sorgularını gözden geçirmek TTFB'yi gözle görülür şekilde düşürür. Özellikle dinamik sayfalarda veritabanı sorguları beklenmedik darboğazlar yaratabilir. Bir sorgunun 300ms sürdüğünü fark ettiğinizde sorunun nerede olduğu netleşir.
Render'ı engelleyen kaynaklar da ciddi bir etken. Tarayıcı CSS'i indirip parse etmeden sayfayı çizmez. <head> içine koyduğunuz her senkron JavaScript dosyası da aynı etkiyi yapar. Ne yapmalı? Kritik CSS'i inline edin, kalanını asenkron yükleyin. JavaScript'te defer kullanın.
Kaynak yükleme süresi üçüncü mesele. LCP öğeniz bir görsel mi? O görselin indirme süresi doğrudan skoru belirliyor. Sıkıştırma, WebP formatı, doğru boyutlandırma gibi adımlar temel. Bir de <link rel="preload"> var: tarayıcıya "bu dosyayı hemen indir" demenin en kestirme yolu. Tek başına yüzlerce milisaniye fark yaratabilir.
Son olarak istemci tarafı render. Client-side rendering kullanan uygulamalarda tarayıcı JS'i indirir, parse eder, çalıştırır; içerik ancak ondan sonra ekrana gelir. Bu zincir LCP'yi fena halde şişirir. Server-side rendering veya static site generation bu sorunu kökünden çözer.
INP: etkileşimlere ne kadar hızlı yanıt veriliyor?
Interaction to Next Paint, kullanıcının sayfayla etkileşime girdiğinde (tıklama, dokunma, klavye girişi) sayfanın görsel olarak ne kadar çabuk karşılık verdiğini ölçer. 200 milisaniyenin altı "iyi", 500'ün üstü "kötü". Mart 2024'te eski FID metriğinin yerini aldı ve ondan çok daha kapsamlı: sadece ilk etkileşimi değil, sayfa boyunca gerçekleşen tüm etkileşimleri değerlendiriyor.
Suçlu neredeyse her zaman JavaScript.
En sık karşılaşılan sorun uzun görevler. Tarayıcının ana iş parçacığı 50 milisaniyeden uzun süren bir JS görevi çalıştırıyorsa o süre boyunca kullanıcı girdilerine sağır kalır. Butona tıklarsınız, hiçbir şey olmaz, sayfa donmuş gibi görünür. Chrome DevTools'un Performance sekmesinde bu görevler kırmızı bayrakla beliriyor, kaçırmanız zor.
Peki nasıl çözülür? Büyük görevleri parçalayın. requestAnimationFrame veya setTimeout ile işleri küçük dilimlere bölerseniz tarayıcı arada kullanıcı etkileşimlerini işleyebilir. Buna "yielding to the main thread" deniyor. Kulağa karmaşık geliyor ama pratikte birkaç satır kod meselesi.
Şişkin DOM yapısı da INP'yi vuruyor. Sayfanızda 1500'den fazla düğüm varsa her stil hesaplaması ve layout geçişi yavaşlar. 3000'i aştığınızda durum kritik. Gereksiz iç içe div'leri temizlemek, görünür olmayan bölümleri lazy load etmek DOM'u hafifletir ve etkisi düşündüğünüzden büyük olur.
Bir de üçüncü parti script'ler var. Chat widget'ları, reklam kodları, analytics pikselleri... Her biri ana iş parçacığından pay alıyor. Hangisinin ne kadar süre yediğini Performance sekmesinde görebilirsiniz. Gereksiz olanları kaldırmak, kalanları ertelenmiş yüklemek INP'de hissedilir fark yaratır.
CLS: sayfa yüklenirken içerik kayıyor mu?
Cumulative Layout Shift, sayfa yüklenirken veya kullanıcı etkileşimi olmadan içeriğin beklenmedik şekilde yer değiştirmesini ölçer. Hani bir makale okursunuz, tam ilginç kısma gelmişsinizdir, aniden reklam yüklenir ve metin aşağı kayar. CLS tam olarak bunu yakalıyor. 0,1'in altı "iyi", 0,25'in üstü "kötü".
En yaygın kaynak: boyutu belirtilmemiş görseller ve iframe'ler. Tarayıcı görseli indirmeden boyutunu bilemez, görsel geldiğinde etrafındaki her şey kayar. Çözümü kolay: tüm <img> ve <iframe> etiketlerine width ve height ekleyin. CSS tarafında aspect-ratio da aynı işi görür.
Sonradan enjekte edilen içerikler de sıkıntı. Sayfanın üstüne geç yüklenen reklam bannerları, çerez uyarıları, bildirim barları gibi öğeler mevcut içeriği aşağı iter ve CLS skorunu şişirir. Yapılması gereken şey bu öğeler için sayfada önceden yer ayırmak: sabit yükseklikte bir container koyun, içerik geldiğinde o alana otursun.
Font konusu biraz daha ince. Font dosyası yüklenene kadar tarayıcı iki yoldan birine gider: ya metni hiç göstermez (FOIT), ya da sistem fontuyla gösterip sonra değiştirir (FOUT). FOUT tercih edilir, en azından kullanıcı bir şeyler okuyabilir. font-display: swap bunu sağlar. Ama dikkat: font değişimi sırasında metin boyutu farklılaşırsa layout kayması olur. size-adjust ile fallback fontun ölçülerini web fontuna yaklaştırabilirsiniz, bu detayı atlayan çok site var.
Animasyonlarda da tuzak gizli. top, left, width, height gibi özellikleri animate etmek layout'u tetikler ve CLS'e yazılır. Bunların yerine transform ve opacity kullanın; compositor thread'de çalışırlar, layout'a dokunmazlar.
Core Web Vitals nasıl ölçülür ve takip edilir?
İki tür ölçüm aracı var ve ikisi de farklı bir hikaye anlatıyor.
Laboratuvar araçları kontrollü ortamda çalışır. Lighthouse, Chrome DevTools, PageSpeed Insights'ın laboratuvar bölümü, WebPageTest gibi araçlar hepsi aynı koşullarda tekrarlanabilir sonuçlar verir. Sorunları tespit etmek ve düzeltmeleri doğrulamak için birebir. Tek eksikleri gerçek kullanıcı deneyimini tam yansıtamamaları: kullanıcıların cihazları, bağlantı hızları, davranış kalıpları birbirinden çok farklı.
Saha araçları ise gerçek kullanıcı verisi toplar. Chrome UX Report (CrUX), Search Console'daki Core Web Vitals raporu, PageSpeed Insights'ın saha verisi bölümü. Google sıralama kararlarında saha verisine bakıyor, yani asıl önemli olan bu taraf. Dezavantajı mı? 28 günlük kayan ortalama kullandığı için yaptığınız iyileştirmenin rapora yansıması zaman alır. Sabır gerektiren bir süreç.
Search Console'daki rapor site genelinin fotoğrafını çeker. Sayfaları "iyi", "iyileştirme gerekli" ve "kötü" olarak gruplar, hangi URL'nin hangi metrikte sorunlu olduğunu gösterir. Periyodik SEO denetimi sırasında bu raporu atlamayın.
Kendi sitenizde gerçek zamanlı veri toplamak da mümkün. Google'ın geliştirdiği web-vitals kütüphanesi LCP, INP ve CLS değerlerini ölçüp analytics aracınıza gönderebilir. Sayfa bazında detaylı analiz yapmak istiyorsanız bu yöntem Search Console'dan daha granüler veri sunar.
Hangi metriğe önce el atmalı?
Hangisi "kötü" kategorisindeyse ona. Bu kadar basit.
Birden fazla metrik kötüyse LCP'den başlamak mantıklı çünkü LCP iyileştirmeleri (görsel optimizasyonu, sunucu hızlandırma, render engellerini kaldırma) genellikle diğer metriklere de olumlu yansır. Site hızı optimizasyonu kapsamında yaptığınız çalışmaların büyük kısmı zaten LCP'yi doğrudan etkiler.
CLS üçü arasında en kolay düzeltileni. Görsellere boyut eklemek, dinamik içerikler için yer ayırmak, font-display'i ayarlamak gibi küçük kod değişiklikleri etkisi orantısız büyük. Çoğu CLS sorunu birkaç saatte çözülür, bazen daha da kısa sürer.
INP ise en dikenli olanı. JavaScript performans optimizasyonu hem teknik bilgi ister hem de sonuçları hemen görünmeyebilir. Garip olan şu: en etkili hamle genellikle en basiti. Kullanılmayan bir analytics kodu veya gereksiz bir chat widget'ı kaldırmak INP'de gözle görülür düşüş sağlayabiliyor. Karmaşık optimizasyonlara girmeden önce bu düşük asılı meyveleri toplamakta fayda var.
Her değişiklikten sonra laboratuvar araçlarıyla test edin. Saha verisine yansıması 28 gün alır ama laboratuvar verisi anında sonuç verir, doğru yönde ilerlediğinizi teyit etmek için yeterli.
Core Web Vitals sabit bir hedef değil. Google metrikleri güncelliyor, FID'in yerini INP aldı, yarın yeni bir metrik gelebilir. Eşik değerleri de değişebilir. Temel prensip değişmiyor: hızlı yükle, etkileşimlere anında yanıt ver, yüklenirken içerik kaydırma. Bu üçünü tutturan siteler algoritma güncellemelerinden en az etkilenenler oluyor, ve muhtemelen olmaya da devam edecekler.