Core Web Vitals 2026 itibarıyla SEO sıralama faktörlerinin %18’ini doğrudan etkiliyor ve Google Search Central 2024 verileri Core Web Vitals’ı geçen sayfaların organik trafikte %32 daha yüksek dönüşüm oranına ulaştığını gösterir. Mart 2024’te INP (Interaction to Next Paint) FID yerine resmi Core Web Vitals metriği olarak konumlanmış, doğru optimizasyon ile dönüşüm oranı %32, sayfa terk oranı ise %35 oranında iyileşmiştir. Yanlış öncelikler ve hatalı kurgular ise organik trafikte yıllık %25-40 kayba yol açabilir.
Bu rehberde web performans optimizasyonunu 2026 standartlarıyla detaylı inceliyoruz:
- INP, LCP, CLS metrikleri ve hedef eşikler
- JavaScript ana iş parçacığı (main thread) optimizasyonu
- Image, font ve resource hint optimizasyonları
- Server-side ve edge rendering stratejileri
- Real User Monitoring (RUM) ve lab data araçları
- Framework spesifik (React, Vue, Astro, Next.js) yaklaşımlar
Core Web Vitals 2026: INP, LCP, CLS
Google Core Web Vitals, kullanıcı deneyiminin üç boyutunu ölçen üç temel metrikten oluşur. Web.dev her metriğin “Good”, “Needs Improvement”, “Poor” eşiklerini tanımlar.
| Metrik | Açıklama | Good | Needs Improvement | Poor |
|---|---|---|---|---|
| LCP (Largest Contentful Paint) | En büyük içerik öğesinin render süresi | ≤ 2,5 s | 2,5-4 s | > 4 s |
| INP (Interaction to Next Paint) | Kullanıcı etkileşim yanıt süresi | ≤ 200 ms | 200-500 ms | > 500 ms |
| CLS (Cumulative Layout Shift) | Sayfa içeriği kayma toplam skoru | ≤ 0,1 | 0,1-0,25 | > 0,25 |
| FCP (First Contentful Paint) | İlk içerik render | ≤ 1,8 s | 1,8-3 s | > 3 s |
| TTFB (Time to First Byte) | Sunucu ilk yanıt süresi | ≤ 800 ms | 800-1800 ms | > 1800 ms |
| TBT (Total Blocking Time) | Ana iş parçacığı blokaj süresi (lab) | ≤ 200 ms | 200-600 ms | > 600 ms |
INP: 2024’te FID’in Yerine Geçen Metrik
INP (Interaction to Next Paint) Mart 2024’te Core Web Vitals’a girmiş ve FID (First Input Delay)’i replace etmiştir. INP, FID’in tek bir input olayını ölçmesine karşılık tüm sayfa yaşam döngüsü boyunca tüm etkileşimleri kapsar.
INP optimizasyonu için 7 strateji:
- Long task’ları parçalamak: 50ms üzeri task’ları yieldToMain() ile böl
- Web Worker kullanımı: Heavy computation’ı background thread’e taşı
- Debounce/throttle: Input event handler’larını rate limit et
- Optimistic UI updates: Server response beklemeden UI’yı güncelle
- Lazy hydration: Below-the-fold component’leri sonra hydrate et
- React useTransition: Non-urgent updates için low-priority queue
- requestIdleCallback: Browser idle time’ı kullanan task scheduling
LCP Optimizasyon Teknikleri
LCP, sayfanın en büyük içerik öğesinin render süresini ölçer. Tipik LCP element’leri hero image, video poster ve large heading’tir. Web.dev LCP guide 4 fazlı bir optimizasyon önerir.
| LCP Fazı | Tipik Süre (%) | Optimizasyon Tekniği |
|---|---|---|
| TTFB | %40 | CDN, server caching, edge computing |
| Resource Load Delay | %20 | fetchpriority=”high”, preload, no-render-blocking |
| Resource Load Time | %30 | Image format (WebP, AVIF), CDN, compression |
| Element Render Delay | %10 | Critical CSS inline, font display swap |
CLS Optimizasyon Teknikleri
CLS, sayfa içeriğinin yüklenirken kayması (jumping content) durumudur. Web.dev CLS guide 5 yaygın CLS kaynağını tanımlar.
- Width/height attribute eksikliği: Image’lere width + height zorunlu
- Web font swap: font-display: optional veya pre-load + preconnect
- Dynamic content injection: Banner, popup öncesi yer ayır
- Late-arriving content: Skeleton/placeholder ile yer rezerve et
- Animation frame’leri: transform/opacity kullan, top/left değil
- Iframe sizing: Container width/height tanımlı olmalı
- Third-party widget: Ad slot, social embed için sabit boyut
JavaScript Optimizasyon Stratejileri
JavaScript 2026 web performansının baş düşmanıdır; aşırı bundle size INP, LCP ve TTI’yi olumsuz etkiler. Web.dev 2024 verisi medyan bir web sayfasının 580 KB JavaScript yüklediğini belirtir.
| Teknik | Etki | Implementasyon Maliyeti | Önerilen Senaryo |
|---|---|---|---|
| Code splitting | %30-50 initial bundle azalır | Düşük (route-based) | SPA, multi-page |
| Tree shaking | %10-25 ölü kod azalır | Çok düşük (build config) | Modern bundler |
| Dynamic import() | %40-60 below-fold tasarrufu | Orta (refactoring) | Heavy widgets |
| Critical JS inline | ~30ms LCP iyileşmesi | Düşük | Above-the-fold logic |
| Module/nomodule | %15-30 modern browser tasarrufu | Düşük | Geniş tarayıcı desteği |
| ESM CDN | HTTP/2 paralelleştirme | Orta | Edge deployment |
| Web Workers | Main thread’i serbest bırakır | Yüksek (refactoring) | CPU-heavy logic |
Image Optimizasyonu: WebP, AVIF, Responsive
Image’ler tipik bir web sayfasının %50-65 boyutunu oluşturur. Doğru format ve responsive teknikleri ile %40-70 bandwidth tasarrufu sağlanır.
| Format | Boyut (JPG’ye göre) | Tarayıcı Desteği (%) | Önerilen Senaryo |
|---|---|---|---|
| JPG (baseline) | %100 | %100 | Fallback |
| WebP | %65-75 | %97 | Default modern |
| AVIF | %40-55 | %89 | 2026 default, fallback ile |
| PNG (lossless) | %150-200 | %100 | Logo, transparent |
| WebP (lossless) | %65-80 | %97 | Lossless modern |
| SVG | %5-15 | %99 | Vector graphics |
Responsive image stratejileri:
- srcset + sizes: Tarayıcının ekran boyutuna göre uygun image seçimi
- picture element: Art direction (farklı crop’lar) ve format fallback
- loading=”lazy”: Below-the-fold image’ler için native lazy loading
- fetchpriority=”high”: LCP image’i için yüksek öncelik
- width + height attribute: Aspect ratio koruyarak CLS engeller
- CDN image transform: Cloudinary, ImageKit, Vercel Image ile on-the-fly
Font Optimizasyonu
Web font’lar CLS ve LCP üzerinde önemli etkiye sahiptir. Yanlış font yükleme stratejisi 500-1.500 ms LCP gecikmesine yol açabilir.
- font-display: swap: Fallback font ile başla, sonra swap
- font-display: optional: En agresif, CLS sıfır
- preload: Critical font’lara
- Subsetting: Sadece kullanılan karakterleri yükle (Türkçe icin Latin Extended)
- Self-hosting: Google Fonts yerine self-host (~150ms TTFB tasarrufu)
- Variable fonts: Tek dosyada birden fazla weight/style
- System font stack: Critical text için system fallback
Server-side ve Edge Rendering Stratejileri
2026 itibarıyla SSR, SSG ve ISR (Incremental Static Regeneration) gibi server-side rendering pattern’leri Core Web Vitals optimizasyonunun temelidir.
| Strateji | LCP Etkisi | INP Etkisi | Uygulanabilirlik |
|---|---|---|---|
| SSR (Server-Side Rendering) | İyi (1,2-2,0 s) | Orta (150-300 ms) | Dinamik content |
| SSG (Static Site Generation) | Çok iyi (0,8-1,4 s) | Çok iyi (50-150 ms) | Blog, doc, marketing |
| ISR (Incremental Static) | Çok iyi (0,9-1,5 s) | İyi (100-200 ms) | Yarı-dinamik content |
| Edge SSR (Cloudflare Workers) | Çok iyi (0,7-1,3 s) | Orta (150-300 ms) | Personalized + dinamik |
| RSC (React Server Components) | İyi (1,1-1,8 s) | İyi (100-200 ms) | App-heavy modern web |
| SPA (Client-Side) | Zayıf (2,5-4,5 s) | Zayıf (250-500 ms) | Sadece dashboard, app |
Real User Monitoring (RUM) ve Lab Tools
Core Web Vitals optimizasyonu için lab data (Lighthouse, WebPageTest) ile field data (RUM) birlikte kullanılır. Google Developers Search Console Core Web Vitals raporu CrUX (Chrome User Experience Report) verisini kullanır.
- Google Search Console: CrUX RUM data, Search-impacting metrics
- PageSpeed Insights: Lab + field, actionable suggestions
- Lighthouse CI: Build-time performance budget
- WebPageTest: Detailed lab analysis, multi-geo
- Vercel Analytics / Speed Insights: RUM with Vercel hosting
- Sentry Performance: Application errors + performance
- Datadog RUM: Enterprise RUM, user journey tracking
- SpeedCurve: Continuous performance monitoring
- web-vitals.js: Native Web Vitals JS library
Resource Hint’ler ve Önceliklendirme
Resource hint’ler tarayıcıya hangi kaynakların ne zaman yükleneceği konusunda yön verir. Doğru kullanım ile LCP %15-25 iyileşir.
- preload: Mutlaka gerekli kritik kaynaklar (LCP image, hero font)
- preconnect: DNS + TCP + TLS handshake öne çek (Google Fonts, CDN)
- dns-prefetch: Sadece DNS, preconnect’ten hafif
- prefetch: Next-navigation tahmini, low priority
- fetchpriority: Tarayıcıya öncelik signal’i (LCP image için “high”)
- modulepreload: ES modules için preload eşdeğeri
- speculation rules: 2024 yeni standart, prerender + prefetch
SEO teknik optimizasyon rehberimizde detayları bulabilirsiniz. CDN ve edge optimization yazımız performans katmanını tamamlar.
Framework Spesifik Optimizasyon Pratikleri
Her modern framework’ün kendine özgü performans pattern’leri vardır:
| Framework | Anahtar Teknik | Tipik İyileşme |
|---|---|---|
| Next.js | App Router + RSC, next/image, next/font | %35 LCP iyileşmesi |
| Astro | Islands, default zero JS | %45 INP iyileşmesi |
| Remix | Loaders, deferred data | %28 TTFB iyileşmesi |
| SvelteKit | Compile-time, minimal runtime | %40 bundle azalması |
| Nuxt 3 | Nitro, edge SSR | %30 TTFB iyileşmesi |
| Gatsby | Gatsby Image, partial hydration | %25 LCP iyileşmesi |
| WordPress | WP Rocket, Cloudflare APO, lazy load | %30-50 LCP iyileşmesi |
Performance Budget ve Sürekli İyileştirme
Performance budget, ekibin performans regression’larını önleyen disiplini sağlar. Lighthouse CI ile her PR otomatik kontrol edilir.
| Metrik | Performance Budget | Fail Threshold |
|---|---|---|
| JavaScript bundle (gzipped) | ≤ 150 KB | 200 KB |
| CSS bundle (gzipped) | ≤ 30 KB | 50 KB |
| Toplam sayfa boyutu (gzipped) | ≤ 500 KB | 800 KB |
| LCP (lab) | ≤ 2 sn | 2,5 sn |
| TBT (lab) | ≤ 150 ms | 200 ms |
| CLS (lab) | ≤ 0,05 | 0,1 |
| Lighthouse Performance | ≥ 90 | 85 |
Kurumsal Web Performans Optimizasyonunda Karşılaşılan Tipik Sorunlar
Performans optimizasyonu projelerinde teknik uygulamalar kadar süreç ve sürekli izleme kritiktir. Danışmanlık projelerinde gözlemlenen örüntüler, performans iyileştirme programlarının %44’ünün 6 ay sonra regression’a uğradığını göstermektedir. Tipik sorunlar:
- RUM yok, sadece lab data: Lighthouse 95 ama gerçek kullanıcı LCP 4 sn
- Performance budget yok: Her PR bundle size’a ekliyor, 6 ayda %200 büyüme
- Third-party script kontrolsüz: Marketing analytics, chat widget’ları INP’yi 800 ms’e çıkarıyor
- Image optimization manuel: İçerik editörü WebP yüklemiyor, CDN yok
- INP’ye odaklanmamış: FID iyi olduğu için yanlış izlenim, INP gerçeği gösterince şok
- Mobile-first değerlendirme yok: Desktop’ta hızlı, mobile’da 3G simülasyonu çökmüyor
Sık Sorulan Sorular
INP ile FID arasındaki fark nedir?
FID (First Input Delay), kullanıcının sayfayla yaptığı ilk etkileşimin yanıt süresini ölçer. INP (Interaction to Next Paint) ise sayfa yaşam döngüsü boyunca tüm etkileşimleri kapsar ve en kötü %98’lik dilimini raporlar. INP gerçek kullanıcı deneyimini çok daha doğru yansıtır çünkü scroll, click, key press, hover gibi tüm etkileşimleri içerir. Mart 2024’te INP, FID’in yerine Core Web Vitals’ın resmi metriği olmuştur.
Core Web Vitals SEO sıralamasını ne kadar etkiler?
Core Web Vitals, Google’ın “Page Experience” sinyalinin bir parçasıdır ve toplam sıralama faktörlerinin yaklaşık %18’ini temsil eder. Mobile-first indexing ile birlikte mobile Core Web Vitals daha kritiktir. Aynı içerik kalitesi olan iki sayfa arasında Core Web Vitals’ı geçen sayfa ortalama 2-4 sıra yukarıda görünür. Trafik etkisi %15-32 organik trafik farkı yaratabilir. E-ticaret sitelerinde dönüşüm oranı LCP iyileştirmesi ile %32 artabilir.
Lighthouse skoru ve gerçek kullanıcı deneyimi neden farklı olur?
Lighthouse “lab data” üretir; sabit cihaz simülasyonu, sabit ağ koşulları, tek bir page load ile ölçüm yapar. Gerçek kullanıcılar farklı cihazlar (3 yaşında Android, son model iPhone), farklı ağ koşulları (5G, 3G, WiFi), farklı kullanım pattern’leri (çoklu tab, kötü RAM koşulu) ile siteyi deneyimler. CrUX RUM data Chrome kullanıcılarının gerçek performansını yansıtır ve Google’ın sıralama faktörü olarak kullandığı veri budur. Hem lab hem RUM birlikte izlenmelidir.
Web font’lar performans için sorun mu yaratır?
Yanlış kullanılan web font’lar LCP’yi 500-1.500 ms geciktirebilir ve CLS’i 0,1-0,3 artırabilir. Doğru optimizasyon ile font’lar minimum etki yaratır: (1) font-display: swap veya optional, (2) preload critical font’lar, (3) subsetting ile boyut küçültme, (4) self-hosting (Google Fonts CDN yerine), (5) variable font kullanımı, (6) system font fallback. Bu adımlarla font’lar performans bütçesinin %5’ini aşmaz.
Third-party script’ler nasıl optimize edilir?
Third-party script’ler (Google Analytics, Facebook Pixel, chat widget’lar) tipik bir kurumsal sitede toplam JS’in %35-50’sini oluşturur. Optimizasyon stratejileri: (1) async/defer attribute zorunlu, (2) lazy loading ile etkileşim sonrası yükleme, (3) Partytown ile Web Worker’a taşıma, (4) Tag Manager’ı dikkatli kullanma (Google Tag Manager 200+ KB), (5) consent-based loading (cookie consent sonrası), (6) self-hosted alternatifler (Plausible, Umami GA yerine), (7) Lighthouse 3rd party impact raporu ile gözlem. Doğru optimizasyon ile third-party impact %60-80 azaltılabilir.
Sonuç
Web performans optimizasyonu 2026 itibarıyla SEO sıralaması, kullanıcı deneyimi ve dönüşüm oranı için stratejik bir kaldıraçtır; Core Web Vitals’ı geçen sayfalar organik trafikte %32, dönüşüm oranında %32 ve sayfa terk oranında %35 iyileşme sağlar. INP’nin Mart 2024’te FID yerine geçmesi, JavaScript ana iş parçacığı optimizasyonunu kritik öncelik haline getirmiştir. LCP için server-side rendering, image optimization (WebP/AVIF), fetchpriority ve preload; INP için long task parçalama, Web Workers ve framework-specific optimizasyonlar (Next.js App Router, Astro Islands, RSC) temel araçlardır. CLS için aspect ratio, font-display: optional ve dynamic content placeholder’ları zorunludur. Performance budget, RUM monitoring ve continuous Lighthouse CI ile regression’lar önlenir. Doğru yapılandırma ile yıllık organik trafikten 200.000-800.000 USD’lik dönüşüm potansiyeli açığa çıkarılırken, yanlış öncelikler %25-40 trafik kaybına yol açar.
Ömer ÖNAL
Mayıs 17, 2026INP metriği 2024’te FID’in yerini aldı ama hâlâ çoğu sitede ölçülmüyor. Real User Monitoring (RUM) ile lab metriği (Lighthouse) arasındaki fark 2-3x olabiliyor — özellikle 3rd party script ağırlıklı sitelerde. Önce RUM kurulumu, sonra optimizasyon.