Core Web Vitals 2026 Checklist: LCP, INP, CLS Optimizasyon Rehberi

Google'ın 2026 için Core Web Vitals güncellemesinde INP (Interaction to Next Paint) metriği FID'in yerini tamamen aldı ve eşik değerler sıkılaştırıldı. Sitenizin LCP 2.5 saniyenin altında, INP 200ms'nin altında ve CLS 0.1'in altında olması artık sadece "iyi olur" değil, sıralama için zorunlu. Ben FUTIA'da son iki yılda 40'tan fazla Türk sitesinin Core Web Vitals sorunlarını çözdüm ve şunu gördüm: çoğu site yanlış yerde optimizasyon yapıyor. Herkes önbellekleme eklentisi kuruyor ama kimse render-blocking CSS'ini temizlemiyor. Bu yazıda 2026 için güncel checklist ve gerçek vakalardan öğrendiklerimi paylaşacağım.

Core Web Vitals'ı optimize etmek için önce hangi metriğin sitenizde gerçekten sorun olduğunu anlamalısınız. Google Search Console'daki "Deneyim" sekmesi genel bir fikir verir ama PageSpeed Insights ve Chrome DevTools'daki Lighthouse raporları daha detaylı. Ben her projede önce 10 farklı sayfayı (ana sayfa, kategori, ürün, blog yazısı) mobil ve masaüstünde test ediyorum. Çünkü bir e-ticaret sitesinde ana sayfa 2.1 saniye LCP gösterirken ürün sayfası 4.8 saniye gösterebilir. Ortalama bakmak yanıltıcı.

LCP (Largest Contentful Paint) 2.5 Saniyenin Altına Çekme

LCP, sayfanın en büyük görsel öğesinin ekrana render edilme süresi. 2026'da Google bu metriği mobil-first indexing kapsamında daha ağır değerlendiriyor. Sitenizin LCP'si 2.5 saniyenin üzerindeyse, önce neyin yavaşlattığını bulun.

Chrome DevTools'u açın (F12), Performance sekmesine girin ve sayfayı yeniden yükleyin. Timeline'da "LCP" olarak işaretlenmiş öğeyi bulun. Çoğu sitede bu hero image, bazılarında video veya büyük bir metin bloğu. diolivo.com.tr projesinde LCP'yi 4.2 saniyeden 1.8 saniyeye düşürdük. Sorun, 1.2 MB boyutundaki hero görselin JPEG olarak sunulması ve lazy loading olmadan yüklenmesiydi.

İlk adım: görseli WebP formatına çevirin. JPEG'e göre %25-35 daha küçük dosya boyutu. WordPress kullanıyorsanız Imagify veya ShortPixel eklentileri otomatik dönüşüm yapar. Özel kodlanmış siteler için Cloudflare'in Polish özelliği veya Cloudinary gibi CDN'ler işi halleder. diolivo'da görseli WebP'ye çevirince 1.2 MB → 380 KB düştü.

İkinci adım: hero görselini preload edin. HTML head'e şu satırı ekleyin:

<link rel="preload" as="image" href="/hero.webp" fetchpriority="high">

Bu, tarayıcıya "bu görseli ilk öncelikle yükle" diye talimat verir. Ancak dikkat: sadece LCP öğesini preload edin. Her görseli preload ederseniz tarayıcı kafası karışır ve hiçbiri öncelik almaz.

Üçüncü adım: sunucu yanıt süresini (TTFB) düşürün. LCP'nin %40-50'si sunucunun HTML'i oluşturma süresi. Shared hosting kullanıyorsanız VPS'e geçin. WordPress için Redis object cache kurulumu TTFB'yi 800ms'den 200ms'ye düşürebilir. memuratamalari.com'da SiteGround'dan Hetzner VPS'e geçince TTFB 620ms → 180ms oldu.

Dördüncü adım: render-blocking kaynaklarını temizleyin. PageSpeed Insights "Eliminate render-blocking resources" uyarısı veriyorsa, CSS ve JS dosyalarınız HTML'in render edilmesini engelliyor. Critical CSS'i inline olarak head'e koyun, geri kalanını defer veya async ile yükleyin. WordPress'te Autoptimize veya WP Rocket bu işi otomatikleştirir ama bazen fazla agresif birleştirme yapıp siteyi bozar. Ben her zaman staging'de test ediyorum.

LCP İçin Göz Ardı Edilen Detay: Font Loading

Çoğu site Google Fonts'u render-blocking şekilde yüklüyor. Font dosyaları LCP'yi 400-600ms geciktirebilir. Çözüm: font-display: swap kullanın ve font dosyalarını preload edin.

<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
<link rel="preload" as="style" href="https://fonts.googleapis.com/css2?family=Inter:wght@400;600&display=swap">

italyanmutfagi.com'da font yükleme stratejisini değiştirince LCP 300ms düştü. Küçük görünüyor ama mobilde her 100ms önemli.

INP (Interaction to Next Paint) 200ms Altına Optimizasyon

INP, kullanıcı bir tıklama, kaydırma veya tuş basımı yaptığında sayfanın ne kadar hızlı tepki verdiğini ölçer. FID sadece ilk etkileşimi ölçerken INP tüm etkileşimleri izler. 2026'da bu metrik özellikle SPA (Single Page Application) ve ağır JS kullanan siteler için kritik.

INP sorunları genelde üç sebepten kaynaklanır: uzun JavaScript görevleri, main thread blokajı ve event handler'ların yavaş çalışması. Chrome DevTools'da Performance sekmesinde "Long Tasks" filtresi açın. 50ms'den uzun görevler sarı veya kırmızı işaretlenir. doktorbul.com projesinde 79.000 doktor profili olan bir sitede INP başlangıçta 420ms'ydi. Sorun, her sayfa yüklendiğinde tüm doktor listesinin DOM'a eklenmesiydi.

Çözüm: code splitting ve lazy loading. React kullanıyorsanız React.lazy() ve Suspense ile bileşenleri parçalara ayırın. Vanilla JS'de Intersection Observer API ile viewport'a girdiğinde yükleyin. doktorbul'da arama sonuçlarını sayfalara böldük ve sadece görünür 20 profili render ettik. INP 420ms → 180ms düştü.

İkinci yaygın sorun: third-party script'ler. Google Analytics, Facebook Pixel, Hotjar gibi araçlar main thread'i bloklar. Bu script'leri async veya defer ile yükleyin ve mümkünse Google Tag Manager üzerinden yönetin. GTM, script'leri asenkron yükler ve tek bir container'da toplar.

Üçüncü sorun: ağır event listener'lar. Özellikle scroll event'leri her 16ms'de (60 FPS için) tetiklenir. Her scroll'da karmaşık hesaplama yaparsanız INP patlak verir. Çözüm: debounce veya throttle kullanın. Lodash'in debounce fonksiyonu veya kendi implementasyonunuz:

function debounce(func, wait) {
  let timeout;
  return function executedFunction(...args) {
    clearTimeout(timeout);
    timeout = setTimeout(() => func(...args), wait);
  };
}

window.addEventListener('scroll', debounce(() => {
  // scroll işlemleri
}, 150));

Bu, scroll event'ini 150ms'de bir tetikler, her 16ms'de değil. INP'yi 100-200ms düşürebilir.

INP İçin Gelişmiş Teknik: Web Worker Kullanımı

Ağır hesaplamalar main thread'de değil Web Worker'da yapılmalı. Örneğin, büyük JSON parse işlemi veya veri filtreleme. kamupersonelhaber.com'da 50+ günlük ilan listesini filtrelemek için Web Worker kullandık. Main thread bloke olmadığı için INP 80ms düştü.

CLS (Cumulative Layout Shift) 0.1 Altına İndirme

CLS, sayfanın yüklenirken beklenmedik şekilde kaymasını ölçer. Kullanıcı bir butona tıklamak üzereyken sayfa kayar ve yanlış yere tıklar. 2026'da Google CLS'yi özellikle mobil deneyim için sıkı değerlendiriyor.

CLS'nin en yaygın nedeni: boyutu tanımlanmamış görseller ve iframe'ler. Tarayıcı görselin boyutunu bilmiyorsa, görsel yüklendiğinde sayfa aşağı kayar. Çözüm basit: her img ve iframe etiketine width ve height ekleyin.

<img src="/foto.jpg" width="800" height="600" alt="Açıklama">

Modern CSS'de aspect-ratio kullanabilirsiniz:

img {
  width: 100%;
  height: auto;
  aspect-ratio: 16 / 9;
}

diolivo.com.tr'de ürün kartlarındaki görsellere aspect-ratio ekleyince CLS 0.18 → 0.04 düştü. Tek satır CSS.

İkinci yaygın neden: dinamik içerik enjeksiyonu. Reklam banner'ları, bildirim popup'ları veya cookie consent'leri sayfa yüklendikten sonra içeriği aşağı iter. Çözüm: bu öğeler için önceden yer ayırın. Örneğin, üstte çıkacak 60px'lik bir bildirim için:

body {
  padding-top: 60px;
}

Ya da JavaScript ile dinamik içerik eklemeden önce min-height tanımlayın.

Üçüncü neden: web font'ların yüklenmesi. Font yüklendiğinde metin boyutu değişir ve sayfa kayar. Çözüm: font-display: optional kullanın. Bu, font yüklenmezse fallback font'u gösterir ve kayma olmaz. Veya font dosyalarını preload edin ki sayfa ilk render'da doğru fontla gelsin.

CLS İçin Kritik Detay: Infinite Scroll ve Lazy Load

Sonsuz kaydırma özelliği CLS'yi artırır çünkü yeni içerik eklenirken sayfa kayar. italyanmutfagi.com'da 618 tarif sayfasında lazy load yaparken her yeni batch için sabit yükseklik tanımladık. Skeleton loader kullandık, içerik yüklenene kadar placeholder gösterdik. CLS 0.22 → 0.07 düştü.

Server-Side Rendering ve Core Web Vitals İlişkisi

SSR (Server-Side Rendering) veya SSG (Static Site Generation) Core Web Vitals için büyük fark yaratır. Client-side rendering'de (örneğin React SPA) tarayıcı önce boş HTML alır, sonra JS indirir, çalıştırır ve içeriği render eder. Bu süreçte LCP 3-5 saniye olabilir.

SSR'da sunucu HTML'i render edilmiş halde gönderir. Tarayıcı hemen içeriği gösterir, JS arka planda hydrate olur. Next.js, Nuxt.js veya SvelteKit gibi frameworkler SSR'ı kolaylaştırır. futia.net'i Next.js ile SSG yaparak 3 ayda 2000+ video içeriği üretti ve LCP 1.4 saniyede tuttu.

Ancak SSR her zaman çözüm değil. Sunucu tarafında ağır işlem yaparsanız TTFB artar ve LCP yine kötü olur. Örneğin, her request'te veritabanı sorgusu yapıyorsanız caching şart. Redis veya Memcached ile sunucu tarafı cache, TTFB'yi 80-90% düşürür.

memuratamalari.com'da SSR + Redis cache kombinasyonu kullandık. 40.400 aylık organik arama trafiği var ve Core Web Vitals'ın üçü de yeşil. Gizli sos: Claude Haiku API ile ilan içeriklerini otomatik üretiyoruz ama her ilan statik HTML olarak cache'leniyor. Dinamik içerik gibi görünüyor ama aslında statik.

CDN ve Edge Computing ile Core Web Vitals İyileştirme

CDN (Content Delivery Network) sadece statik dosyaları hızlandırmaz, Core Web Vitals için kritik. Cloudflare, Fastly veya AWS CloudFront gibi CDN'ler kullanıcıya en yakın sunucudan içerik sunar. TTFB düşer, LCP iyileşir.

Ancak CDN'nin gerçek gücü edge computing'de. Cloudflare Workers veya Vercel Edge Functions ile HTML'i edge'de render edebilirsiniz. Kullanıcı İstanbul'daysa, sunucu Hollanda'da değil İstanbul'daki edge node'da çalışır. TTFB 400ms → 80ms düşebilir.

doktorbul.com'da Cloudflare Workers ile doktor arama sonuçlarını edge'de cache'ledik. Her arama sorgusu için edge'de 200ms'de HTML oluşturuluyor. Origin sunucu sadece yeni doktor eklendiğinde tetikleniyor. Sonuç: LCP 2.8 saniyeden 1.6 saniyeye, INP 340ms'den 190ms'ye düştü.

Edge computing'in bir başka kullanımı: A/B testing ve personalization. Kullanıcıya özel içerik göstermek için origin sunucuya gitmek yerine edge'de karar verirsiniz. CLS riski azalır çünkü içerik ilk render'da doğru gelir.

Core Web Vitals İçin Monitoring ve Sürekli İyileştirme

Core Web Vitals'ı bir kez optimize edip bırakamazsınız. Site güncellendikçe, yeni özellik eklendikçe metrikler değişir. Sürekli monitoring şart.

Google Search Console'daki "Deneyim" raporu 28 günlük gerçek kullanıcı verisi (CrUX) gösterir ama gecikmeli. PageSpeed Insights anlık test yapar ama sentetik veri. İkisini birlikte kullanın. Ben her hafta tüm projelerin Core Web Vitals raporunu kontrol ediyorum.

Daha detaylı monitoring için:

1. Google Analytics 4: Web Vitals event'lerini custom event olarak gönderin. GA4'te "page_speed" event'i oluşturun, LCP, INP, CLS değerlerini parametre olarak gönderin. Hangi sayfalarda sorun var görürsünüz.

2. Sentry veya LogRocket: Gerçek kullanıcı oturumlarını kaydeder. Bir kullanıcı CLS yaşadığında session replay'de neyin kaydığını görürsünüz.

3. Lighthouse CI: Her deploy'da otomatik Lighthouse testi. GitHub Actions veya GitLab CI ile entegre edin. Yeni bir özellik Core Web Vitals'ı bozarsa deploy öncesi fark edersiniz.

kamupersonelhaber.com'da Lighthouse CI kurduk. Her commit'te otomatik test, LCP 2.5 saniyeyi geçerse deploy fail oluyor. Bu sayede hiçbir güncelleme performansı bozmadı.

2026 İçin Core Web Vitals Checklist: Adım Adım

Buraya kadar anlattıklarımı checklist haline getirdim. Her projeye başlarken bu listeyi takip ediyorum.

LCP Checklist

• [ ] Hero görsel WebP veya AVIF formatında mı?
• [ ] LCP öğesi preload ediliyor mu?
• [ ] TTFB 200ms'nin altında mı?
• [ ] Render-blocking CSS ve JS temizlendi mi?
• [ ] Font dosyaları preload ve font-display: swap kullanılıyor mu?
• [ ] Görseller lazy load ama LCP öğesi hariç mi?
• [ ] CDN kullanılıyor mu?

INP Checklist

• [ ] 50ms'den uzun JavaScript görevleri var mı?
• [ ] Third-party script'ler async veya defer ile yükleniyor mu?
• [ ] Event listener'larda debounce/throttle kullanılıyor mu?
• [ ] Code splitting yapıldı mı?
• [ ] Ağır hesaplamalar Web Worker'da mı?
• [ ] React/Vue gibi framework'lerde virtual scrolling var mı?

CLS Checklist

• [ ] Tüm img ve iframe'lerde width/height tanımlı mı?
• [ ] Dinamik içerik için önceden yer ayrıldı mı?
• [ ] Font yükleme stratejisi doğru mu?
• [ ] Reklam ve popup'lar için reserved space var mı?
• [ ] Infinite scroll'da skeleton loader kullanılıyor mu?
• [ ] CSS animation'ları transform ve opacity ile mi yapılıyor?

Genel Checklist

• [ ] SSR veya SSG kullanılıyor mu?
• [ ] Redis veya Memcached cache var mı?
• [ ] Edge computing değerlendirildi mi?
• [ ] Lighthouse CI kurulu mu?
• [ ] Google Search Console'da Core Web Vitals takibi yapılıyor mu?

Bu checklist'i her 3 ayda bir gözden geçirin. Google, Core Web Vitals eşik değerlerini ve ölçüm yöntemlerini güncellediğinde (genelde yılda 2 kez) listeyi revize edin.

Gerçek Dünya Örneği: diolivo.com.tr Optimizasyonu

diolivo.com.tr'yi optimize ederken Core Web Vitals üçlüsü de kırmızıydı. LCP 4.2 saniye, INP 380ms, CLS 0.28. 6 haftalık çalışma sonunda LCP 1.8 saniye, INP 170ms, CLS 0.04 oldu. Trafik 6 ayda %340 arttı.

Yaptıklarımız:

1. LCP için: 1.2 MB hero görsel → 380 KB WebP. Cloudflare CDN + Polish. Font preload. Render-blocking CSS'i critical/non-critical'e ayırdık.

2. INP için: Ürün filtreleme JavaScript'ini Web Worker'a taşıdık. Third-party script'leri (Facebook Pixel, Google Analytics) GTM üzerinden async yüklemeye aldık. Scroll event'lerine 200ms debounce ekledik.

3. CLS için: Tüm ürün görselleri aspect-ratio: 1 / 1 aldı. Cookie consent için body'ye 50px padding-top. Lazy load'da skeleton loader.

4. Bonus: CartBounty sepet kurtarma sistemi kurduk. Terk edilen sepetler için otomatik e-mail + SMS. Bu teknik bir Core Web Vitals optimizasyonu değil ama conversion'ı %18 artırdı.

Sonuç: Google Search Console'da "İyi" URL oranı %23'ten %87'ye çıktı. Organik trafik 6 ayda 4.200 → 18.500 aylık ziyaretçi oldu. Core Web Vitals'ın direkt sıralamaya etkisi var.

Sizin sitenizde Core Web Vitals sorunları varsa, önce PageSpeed Insights'ta test edin. Hangi metrik kötüyse ona odaklanın. Hepsini aynı anda düzeltmeye çalışmayın, önce en kötü olanı yeşile çevirin. Sonra diğerine geçin. Eğer teknik destek gerekirse, FUTIA olarak site analizi + otomasyon + aylık bakım hizmeti veriyoruz. WhatsApp üzerinden +90 532 491 17 05 numarasından ulaşabilir veya info@futia.net'e detaylı açıklama gönderebilirsiniz. Hollanda'dan çalışıyorum ama Türk markalarına özel servisimiz var.