Core Web Vitals ve Statik Siteler: Neden Daha Hızlı? (LCP, CLS, INP ile Teknik Açıklama)

Web performansı artık “güzel olsa iyi olur” seviyesinden çıktı; SEO, kullanıcı deneyimi ve dönüşüm oranlarını doğrudan etkileyen bir rekabet avantajına dönüştü. Google’ın sayfa deneyimi yaklaşımıyla birlikte Core Web Vitals (CWV) metrikleri; özellikle site hızı ve etkileşim kalitesi için ortak bir dil haline geldi. Ancak pratikte pek çok ekip şunu fark ediyor: Aynı içerik, aynı tasarım ve benzer görsellerle bile bazı siteler daha hızlı hissediliyor ve daha iyi CWV skorları alıyor.

Bu noktada “statik siteler neden daha hızlı?” sorusu gündeme geliyor. Statik site dediğimiz şey yalnızca “HTML dosyası” değildir; modern dünyada SSG (Static Site Generation), CDN dağıtımı, cache stratejileri ve daha az sunucu hesaplamasıyla birleşince statik site performans açısından ciddi avantajlar doğurur. Yine de önemli bir uyarı var: Statik olmak tek başına mucize yaratmaz; yanlış görsel, aşırı JavaScript veya üçüncü parti script’ler statik siteyi bile yavaşlatabilir.

Bu yazıda core web vitals, lcp cls inp, pagespeed ve lighthouse gibi ana kavramları netleştirip, statik mimarinin CWV’ye hangi mekanizmalarla katkı verdiğini örneklerle açıklayacağız. Amacımız sadece tanım yapmak değil; ölçüm, karşılaştırma ve uygulanabilir bir checklist ile “hızlı web tasarımı” hedefini somutlaştırmak.

Core Web Vitals nedir ve neden site hızı için kritik?

Core Web Vitals, Google’ın gerçek kullanıcı deneyimini ölçmek için öne çıkardığı metrik setidir. Temelde “sayfa hızlı mı açılıyor?”, “sayfa yerinden oynuyor mu?” ve “kullanıcı etkileşime geçtiğinde gecikme oluyor mu?” sorularına yanıt verir. Bugün CWV’nin merkezinde üç metrik var: LCP, CLS, INP (yani “lcp cls inp” üçlüsü).

• LCP (Largest Contentful Paint): Sayfadaki en büyük içerik parçasının (çoğunlukla hero görsel veya ana başlık alanı) ne kadar sürede yüklendiğini ölçer. Hedef genelde ≤ 2.5s.
• CLS (Cumulative Layout Shift): Sayfa yüklenirken beklenmedik kaymaların toplamını ölçer. Hedef ≤ 0.1.
• INP (Interaction to Next Paint): Kullanıcı tıklama/klavye gibi bir etkileşim yaptığında, arayüzün buna “ne kadar hızlı” cevap verdiğini ölçer. Hedef ≤ 200ms. (Not: INP, FID’ın yerine geçen daha güncel metriktir.)

Bu metrikler sadece SEO için değil, satış/pazarlama tarafı için de kritiktir. Yavaş bir sayfa; form doldurma, fiyat sayfası gezme veya demo talebi gibi aksiyonlarda kullanıcıyı düşürür. B2B sitelerde “ilk izlenim” çoğu zaman tek bir landing sayfada oluşur. Bu yüzden site hızı ve CWV iyileştirmeleri, teknik ekiple pazarlama ekibinin ortak hedefi olmalıdır.

LCP, CLS, INP nasıl ölçülür? PageSpeed, Lighthouse, CrUX farkı

Performans konuşurken en sık yapılan hata, tek bir pagespeed skoruna bakıp karar vermektir. Oysa ölçümün iki ana dünyası var: Lab (simülasyon) ve Field (gerçek kullanıcı) verisi.

Lab ölçüm: Lighthouse / PageSpeed Insights

Lighthouse, belirli bir cihaz/ağ profili varsayarak sayfayı test eder. PageSpeed Insights ise Lighthouse raporunu daha erişilebilir şekilde sunar. Lab ölçümün avantajı, geliştirme sırasında hızlı geri bildirim vermesidir: “Render blocking resources” var mı, görseller ağır mı, JS ana thread’i kilitliyor mu gibi.

Ancak lab verisi her zaman gerçeği temsil etmez. Örneğin CDN cache hit oranınız, kullanıcıların bulunduğu coğrafya, cihaz çeşitliliği gibi faktörler lab ölçümde tam karşılık bulmaz.

Field ölçüm: CrUX (Chrome UX Report)

CrUX, gerçek Chrome kullanıcılarından gelen anonimleştirilmiş verilerle CWV durumunu gösterir. Burada gördüğünüz LCP/CLS/INP, “gerçek hayatta” kullanıcıların yaşadığı deneyime daha yakındır. Bu nedenle SEO perspektifinde field verisi çok değerlidir.

RUM (Real User Monitoring): Kendi verinizi toplamak

En sağlıklı yaklaşım; kritik sayfalarda (ana sayfa, hizmet sayfası, landing page) RUM ile kendi LCP/CLS/INP verinizi toplamaktır. Böylece “hangi sayfa şablonu yavaş?”, “hangi üçüncü parti script INP’yi bozuyor?” gibi sorulara net yanıt alırsınız.

Bu ayrımı doğru kurduğunuzda, lighthouse ile hızlı iterasyon yapar, CrUX/RUM ile de yaptığınız iyileştirmenin sahada karşılık bulup bulmadığını doğrularsınız.

Statik site nedir? Statik site performansını artıran mimari mantık

“Statik site” denince akla bazen sadece “düz HTML” geliyor; ama modern web’de statik yaklaşım farklı biçimlerde karşımıza çıkar:

• Tam statik (ör. Hugo/Jekyll): Sayfalar build sırasında üretilir, sunucuda hesaplama yok denecek kadar azdır.
• SSG (Static Site Generation): Next.js/Astro gibi framework’ler içerikleri build aşamasında HTML’e çevirir. Sonuç yine CDN’den servis edilebilir.
• Hibrit modeller (ISR/SSR + cache): Bazı sayfalar statik, bazıları dinamik olabilir; doğru cache stratejisiyle CWV iyi tutulabilir.

Statik yaklaşımın performans avantajı genellikle üç yerden gelir:

1. Daha düşük TTFB (Time To First Byte): Sunucu tarafında her istek için veritabanı sorgusu, template render veya ağır işlem yoksa ilk byte daha hızlı gelir. CDN üzerinden servis edilen statik dosyalar TTFB’yi ciddi düşürür.
2. CDN ve cache uyumu: Statik dosyalar “immutable” varlıklar olarak cache’lenmeye çok uygundur. Doğru cache-control ile tarayıcı ve CDN cache’i verimli çalışır.
3. Daha öngörülebilir render: İçerik çoğu zaman önceden hazırdır; sayfa açılışında “beklenmedik” sürprizler azalır.

Burada kritik nokta: Statik site performansını belirleyen şey sadece statik HTML değil; görsel optimizasyonu, CSS/JS stratejisi ve üçüncü parti script yönetimidir. Yani statik site, iyi bir temel sunar; üzerine “hızlı web tasarımı” prensipleri eklenirse CWV’de kalıcı kazanım gelir.

Bu konuyu teknoloji seçimi açısından değerlendiriyorsanız, “ne zaman statik, ne zaman dinamik?” sorusunu ayrıca ele alan şu içerik de yardımcı olur: Statik Site mi Dinamik CMS mi? Hugo ve Drupal Ne Zaman?

Statik siteler neden daha hızlı? LCP, CLS, INP açısından neden–sonuç analizi

Bu bölüm, “statik siteler neden daha hızlı” sorusunun teknik cevabını CWV metriklerine göre netleştirir.

LCP: En büyük içerik daha hızlı görünür

LCP’yi genellikle şu faktörler yavaşlatır: yüksek TTFB, render-blocking CSS/JS, ağır hero görseli, geç gelen fontlar. Statik mimari LCP’yi şu mekanizmalarla iyileştirir:

• TTFB düşer: CDN’den yakın noktadan servis + cache hit.
• HTML daha hızlı gelir: Sunucu hesaplaması yoksa, tarayıcı parse/render sürecine daha erken başlar.
• Kritik içeriği öne almak kolaylaşır: Hero görsel için preload, kritik CSS için “critical CSS” yaklaşımı daha düzenli uygulanır.

Pratik öneriler (LCP iyileştirme):

• Hero görselini WebP/AVIF formatında sunun, doğru boyutlandırın.
• Hero görsel için preload kullanın; diğer görsellerde lazy-load.
• Gereksiz CSS/JS’yi azaltın; render blocking kaynakları temizleyin.

CLS: Kaymalar daha kolay kontrol edilir (ama fontlar hâlâ tuzak)

CLS çoğunlukla şu sebeplerle oluşur: görsellerin boyutsuz gelmesi, fontların geç yüklenmesi, reklam/iframe alanlarının sonradan büyümesi. Statik sitelerde layout daha öngörülebilir olduğu için CLS’yi kontrol etmek daha kolaydır.

Pratik öneriler (CLS nasıl düşürülür):

• Tüm görsellere width/height veya aspect-ratio verin.
• Fontlarda font-display: swap ve mümkünse kritik fontları preload edin.
• Iframe/referans widget alanlarını placeholder ile rezerve edin.

INP: Daha az JavaScript, daha hızlı etkileşim (ama “statik” olmak yetmez)

INP, kullanıcının tıklamasına sayfanın ne kadar hızlı yanıt verdiğini ölçer. Statik siteler genellikle daha az JS ile çalışabildiği için avantajlıdır; fakat SPA gibi davranan statik siteler (aşırı hydration, büyük bundle) INP’yi bozabilir.

Pratik öneriler (INP nasıl iyileştirilir):

• JavaScript’i azaltın, code splitting uygulayın.
• Üçüncü parti script’leri (chat, tag manager, heatmap) denetleyin; gerçekten gerekli olmayanı kaldırın.
• Etkileşim kodlarında “long task” üreten işlemleri bölün; ana thread’i kilitlemeyin.

Özetle: Statik mimari LCP ve CLS’de doğal bir avantaj sağlar; INP’de ise avantaj, “daha az JS” disiplinine bağlıdır. Bu disiplin, hızlı web tasarımı yaklaşımının da temelidir: daha hafif arayüz, daha az bağımlılık, daha net etkileşim.

Statik site her zaman hızlı mı? En sık performans tuzakları ve çözüm yolları

Statik siteler güçlü bir başlangıç sunar; ama “statik = hızlı” diye otomatik kabul etmek yanıltıcıdır. Aşağıdaki tuzaklar, statik bir projede bile Core Web Vitals’ı kötüleştirebilir:

1. Aşırı JavaScript bundle’ı: Tasarım animasyonları, UI kütüphaneleri, gereksiz framework katmanları INP’yi düşürür. Çözüm: gerçekten ihtiyaç duyulan JS, “islands architecture” (ör. Astro yaklaşımı), code splitting.
2. Üçüncü parti script enflasyonu: Analytics, reklam, chat, CRM widget’ları, A/B test araçları… Her biri ana thread ve ağ isteklerini artırır. Çözüm: script envanteri çıkarın; gecikmeli yükleme, consent yönetimi ve alternatif hafif çözümler.
3. Görsel optimizasyonu yapılmaması: Büyük JPG/PNG’ler LCP’yi bozar. Çözüm: AVIF/WebP, responsive image (srcset), doğru boyut ve sıkıştırma.
4. Font stratejisi hataları: Geç gelen fontlar CLS yaratır. Çözüm: font preload, subset, font-display.
5. Yanlış cache ayarları: Statik dosya üretip cache’i yanlış yönetmek, CDN avantajını öldürür. Çözüm: cache-control ve versiyonlanmış dosya isimleri (hash’li asset) kullanmak.

Bu noktada yayınlama altyapısı da önemlidir. Statik siteyi doğru CDN ve cache ile yayınlamak, TTFB ve istikrar açısından büyük fark yaratır. Örneğin Hugo tabanlı projelerde pratik bir yol arıyorsanız şu rehber işinize yarayabilir: Cloudflare Pages ile Hugo Sitesi Yayınlama

Statik site performans checklist’i: Core Web Vitals için hızlı kazanımlar

Aşağıdaki listeyi, “yayına çıkmadan önce” ve “her büyük güncellemeden sonra” kontrol listesi gibi kullanabilirsiniz. Amaç; core web vitals hedeflerini sistematik hale getirmek.

LCP checklist

• CDN aktif mi, cache hit oranı iyi mi? (TTFB kontrol)
• Hero görsel AVIF/WebP mi, doğru boyutta mı?
• Hero görsel için preload var mı?
• Render-blocking CSS/JS azaltıldı mı? (critical CSS / defer)

CLS checklist

• Görsellerde width/height veya aspect-ratio tanımlı mı?
• Fontlar için font-display: swap kullanılıyor mu?
• Iframe/reklam/widget alanları için placeholder ayrıldı mı?

INP checklist

• JS bundle boyutu makul mü, gereksiz kütüphaneler kaldırıldı mı?
• Üçüncü parti script’ler minimumda mı?
• Etkileşim anında ağır işlem yapan kodlar bölündü mü? (long task azaltma)

Ölçüm checklist (pagespeed + lighthouse + field)

• Lighthouse ile lab test yapıldı mı?
• PageSpeed Insights’ta CWV metrikleri kontrol edildi mi?
• CrUX/field verisi veya RUM ile gerçek kullanıcı sonuçları doğrulandı mı?

B2B tarafta performans iyileştirmelerini “daha çok lead” hedefiyle bağlamak da önemlidir. Formlar, CRM entegrasyonu ve ölçümleme zinciriyle performans ilişkisini kurgulamak için şu yazıya göz atabilirsiniz: Web Sitesinden Lead: Form, CRM ve Ölçümleme Zinciri

Sonuç: Hızlı web tasarımı için statik yaklaşım ne zaman doğru seçim?

Statik site performans odaklı projelerde statik yaklaşım çoğu zaman büyük avantaj sağlar: daha düşük TTFB, daha iyi LCP, daha öngörülebilir CLS ve doğru JS disipliniyle daha iyi INP. Özellikle kurumsal tanıtım siteleri, landing page’ler, içerik odaklı bloglar ve dokümantasyon sitelerinde statik mimari, site hızı hedefini daha az sürprizle yakalamanızı sağlar.

Yine de doğru karar, içerik güncelleme sıklığına ve kişiselleştirme ihtiyacına bağlıdır. Sık değişen fiyat/veri, üyelik, yoğun etkileşim veya e-ticaret gibi senaryolarda hibrit (SSG + ISR/SSR + cache) modeller daha uygun olabilir. En iyi yaklaşım; önce CWV metriklerini net hedeflemek, sonra mimariyi bu hedeflere göre seçmektir.

Eğer elinizde mevcut bir site varsa, ilk adım olarak PageSpeed/Lighthouse ile lab ölçüm yapın; ardından CrUX/field verisiyle doğrulayın. Sonra da bu yazıdaki checklist’i uygulayarak LCP, CLS ve INP tarafında sistematik iyileştirmeye gidin. Performans bir “tek seferlik proje” değil; ölç, iyileştir, doğrula döngüsüyle sürdürülen bir disiplindir.

İç Bağlantı Önerileri

• Statik Site mi Dinamik CMS mi? Hugo ve Drupal Ne Zaman?
• Cloudflare Pages ile Hugo Sitesi Yayınlama
• Web Sitesinden Lead: Form, CRM ve Ölçümleme Zinciri
• SEO ve GEO Birlikte Nasıl Planlanır?