# Core Web Vitals ve PageSpeed 100: Hızlı Web Sitesinin Teknik Rehberi

> LCP, INP ve CLS nedir, "İyi" eşikleri nelerdir, Google bunları nasıl ölçer ve PageSpeed Insights'ta 100'e yaklaşmak için hangi teknik adımlar gerekir? Bu sitenin altyapısında ölçtüğüm sonuçlar ve platforma göre çözümlerle anlattım.

- URL: https://atakankademli.com.tr/blog/core-web-vitals-pagespeed-100
- Yazar: Atakan Kademli
- Yayın: 2026-08-05
- Güncelleme: 2026-10-08
- Kategori: Web Tasarım & Performans

## Kısa Cevap

Core Web Vitals, Google'ın gerçek kullanıcı deneyimini ölçen üç metriğidir. **LCP** en büyük içeriğin yüklenme süresidir (iyi: ≤ 2,5 sn). **INP** etkileşime yanıt süresidir (iyi: ≤ 200 ms). **CLS** görsel kaymadır (iyi: ≤ 0,1). Google bunları gerçek Chrome kullanıcılarının **75. yüzdelik** değerine göre, mobil ve masaüstü için ayrı ayrı değerlendirir. Yüksek skor için sunucu yanıtını hızlandırın, LCP görselini önceliklendirin, render'ı engelleyen CSS'i ve gereksiz JavaScript'i kaldırın, görsellere boyut verin. Hız, sonradan eklenen bir ayar değil, mimari bir karardır.

## Önemli Çıkarımlar

- Core Web Vitals; LCP (≤ 2,5 sn), INP (≤ 200 ms) ve CLS (≤ 0,1) metriklerinden oluşur.
- Google, gerçek kullanıcı verisinin 75. yüzdeliğine bakar; mobil ve masaüstü ayrı değerlendirilir.
- PageSpeed skoru laboratuvar verisidir; Core Web Vitals değerlendirmesi son 28 günün saha verisine dayanır.
- LCP sorununu TTFB, kaynak gecikmesi, yükleme süresi ve render gecikmesi olarak dörde bölerek teşhis edin.
- INP sorunlarının kaynağı genellikle ana iş parçacığını meşgul eden JavaScript'tir.
- Sayfa deneyimi sıralamada sınırlı bir etkendir; alaka düzeyi her zaman önce gelir, ama hız dönüşümü doğrudan etkiler.

Bir web sitesinin hızı hem kullanıcı deneyiminin hem de SEO'nun sessiz kahramanıdır. Yavaş bir site en iyi içeriği bile okunmadan terk ettirir, reklam bütçesini boşa harcatır ve mobilde formların doldurulmasını zorlaştırır.

Bu rehberde **Core Web Vitals**'ı temelden anlatıyorum: metrikler ne ölçer, Google nasıl değerlendirir, PageSpeed skoru ile farkı ne? Ardından her metrik için teşhis ve çözüm yollarını, WordPress ve hazır e-ticaret altyapılarına özel önerileri ve bu sitenin altyapısında ölçtüğüm gerçek sonuçları paylaşıyorum.

## Core Web Vitals nedir?

Core Web Vitals, Google'ın bir sayfanın **yüklenme hızı**, **etkileşime yanıt verme** ve **görsel kararlılık** deneyimini ölçen üç temel metriğidir. Bu metrikler Google'ın sayfa deneyimi sinyallerinin bir parçasıdır.

| Metrik | Ne ölçer? | İyi | İyileştirilmeli | Zayıf |
|---|---|---|---|---|
| **LCP** (Largest Contentful Paint) | Sayfadaki en büyük içeriğin görünme süresi | ≤ 2,5 sn | 2,5–4 sn | > 4 sn |
| **INP** (Interaction to Next Paint) | Kullanıcı etkileşimine yanıt süresi | ≤ 200 ms | 200–500 ms | > 500 ms |
| **CLS** (Cumulative Layout Shift) | Yükleme sırasında öğelerin beklenmedik kayması | ≤ 0,1 | 0,1–0,25 | > 0,25 |

**INP, FID'in yerini aldı**
INP, 12 Mart 2024'te eski metrik FID'in (First Input Delay) yerini aldı. FID yalnızca ilk etkileşimin gecikmesini ölçerken INP, sayfa boyunca yapılan tıklama, dokunma ve tuş basma etkileşimlerini dikkate alır ve en kötülerden birini raporlar. Bu yüzden FID'de sorunsuz görünen birçok site INP'de zorlanıyor.


### Google nasıl değerlendirir?

Bu üç nokta, sonuçları yorumlarken en çok karıştırılan konular:

- **75. yüzdelik:** Bir sayfanın "iyi" sayılması için ziyaretlerin en az %75'inde eşiğin altında kalması gerekir. Yani ortalama değil, yavaş kullanıcılarınızın deneyimi belirleyicidir.
- **Mobil ve masaüstü ayrı:** Masaüstünde her şey yeşil olabilir, mobilde kırmızı. Türkiye'de trafiğin büyük kısmı mobilden geldiği için önce mobile bakın.
- **28 günlük pencere:** Saha verisi, Chrome Kullanıcı Deneyimi Raporu'ndan (CrUX) gelir ve son 28 günün kayan ortalamasıdır. Bugün yaptığınız iyileştirme raporlara kademeli olarak yansır.

Yeterli trafiği olmayan sayfalar için CrUX verisi oluşmaz. Bu durumda Search Console benzer URL gruplarının verisini veya sitenin genel verisini kullanır, PageSpeed Insights ise "veri yok" der.

## PageSpeed skoru ile Core Web Vitals aynı şey mi?

Hayır, ve bu fark önemli. PageSpeed Insights iki tür veri gösterir:

| | Saha verisi (Field) | Laboratuvar verisi (Lab) |
|---|---|---|
| Kaynak | Gerçek Chrome kullanıcıları (CrUX) | Lighthouse simülasyonu |
| Zaman | Son 28 gün | Test anı |
| Ne verir? | Core Web Vitals değerlendirmesi (geçti/geçmedi) | 0–100 performans skoru |
| SEO ile ilişkisi | Google'ın sayfa deneyimi değerlendirmesinde kullanılır | Doğrudan kullanılmaz, teşhis aracıdır |

Lighthouse performans skoru beş metriğin ağırlıklı ortalamasıdır: **Total Blocking Time (%30)**, **LCP (%25)**, **CLS (%25)**, **First Contentful Paint (%10)** ve **Speed Index (%10)**. Laboratuvarda INP ölçülemediği için yerine onunla ilişkili olan TBT kullanılır.

Yani 100 skor almak güzel bir hedef, ama asıl önemli olan **gerçek kullanıcılarınızın** deneyimi. Laboratuvarda 100 alıp sahada kalan siteler de var: ağır bir canlı sohbet widget'ı, test sırasında yüklenmeyen ama gerçek kullanıcıda açılan bir çerez bannerı, yavaş mobil ağlar.

### Core Web Vitals sıralamayı ne kadar etkiler?

Dürüst cevap: **sınırlı ama gerçek**. Google, sayfa deneyiminin sıralama sistemlerinde kullanıldığını ama **alaka düzeyinin her zaman önce geldiğini** açıkça belirtiyor. Hızlı ama soruyu cevaplamayan bir sayfa, yavaş ama mükemmel cevap veren bir sayfayı geçemez. Benzer kalitede sayfalar arasında ise hız fark yaratabilir.

Hızın asıl etkisi çoğu zaman sıralamadan çok **dönüşümde** görülür. Formun daha hızlı açılması, butonun dokunur dokunmaz tepki vermesi ve sayfanın kaymaması doğrudan daha fazla teklif talebi demektir.

## LCP'yi iyileştirmek

LCP öğesi genellikle sayfanın üst kısmındaki büyük başlık, kapak görseli veya ürün fotoğrafıdır. PageSpeed Insights raporunda "Largest Contentful Paint öğesi" bölümü hangi öğe olduğunu gösterir.

### LCP'yi dört parçaya ayırarak teşhis edin

Google'ın önerdiği yöntem, LCP süresini dört alt parçaya bölmektir. Hangi parça uzunsa çözüm oradadır:

| Alt parça | Ne demek? | Uzunsa tipik sebep | Çözüm |
|---|---|---|---|
| **TTFB** (sunucu yanıt süresi) | Tarayıcının HTML'in ilk baytını alması | Yavaş hosting, önbellek yok, ağır veritabanı sorguları | Tam sayfa önbelleği, OPcache, daha iyi hosting, CDN |
| **Kaynak yükleme gecikmesi** | HTML geldikten sonra LCP görselinin indirilmeye başlamasına kadar geçen süre | Görsel CSS arka planında veya JavaScript ile ekleniyor, lazy-load açık | Görseli HTML'de `<img>` olarak verin, `fetchpriority="high"`, gerekirse `preload` |
| **Kaynak yükleme süresi** | Görselin indirilmesi | Büyük dosya, eski format | WebP/AVIF, doğru boyut, `srcset` |
| **Render gecikmesi** | İndirme bittikten sonra ekrana çizilmesi | Render'ı engelleyen CSS/JS, web fontu bekleme | Kritik CSS'i gömün, JS'yi erteleyin, `font-display: swap` |

Web.dev'in genel önerisi TTFB'nin 800 ms'nin altında olmasıdır. Paylaşımlı hostingde önbelleksiz çalışan bir WordPress sitesinde TTFB tek başına 1–2 saniyeyi bulabilir; bu durumda diğer optimizasyonlar LCP'yi yeşile taşımaya yetmez.

### LCP için kontrol listesi

1. **Sayfaları önbellekten sunun.** Bu sitede her sayfa ilk ziyaretten sonra tam sayfa önbelleğine alınıyor ve milisaniyeler içinde sunuluyor.
2. **LCP görselini asla lazy-load etmeyin.** Ekranın üst kısmındaki görsele `loading="lazy"` vermek en sık gördüğüm hatalardan biri. Bunun yerine `fetchpriority="high"` kullanın.
3. **Render'ı engelleyen CSS'i azaltın.** Kritik CSS'i sayfaya gömün veya tek, küçük bir dosyada tutun.
4. **Fontları kendi sunucunuzdan verin ve önceden yükleyin.** Kritik font için `<link rel="preload">` ve `font-display: swap` kullanın.
5. **Kaydırıcıdan (slider) kaçının.** Ana sayfa kaydırıcıları genellikle büyük görseller ve JavaScript yükler; LCP öğesi de çoğu zaman JS çalışana kadar görünmez.

## INP'yi iyileştirmek

INP sorunlarının neredeyse tamamı **ana iş parçacığını meşgul eden JavaScript**'ten kaynaklanır. Kullanıcı dokunduğunda tarayıcı başka bir işle uğraşıyorsa yanıt gecikir.

1. **JavaScript'i azaltın.** Kullanmadığınız eklentileri, kaydırıcıları ve üçüncü taraf scriptleri kaldırın. Her eklenen "küçük" script toplam yükü artırır.
2. **Uzun görevleri bölün.** 50 ms'den uzun süren JavaScript görevleri "uzun görev" sayılır. Ağır işleri küçük parçalara ayırın ve aralarında tarayıcıya nefes aldırın (ör. `scheduler.yield()` veya `setTimeout` ile).
3. **Üçüncü taraf scriptleri erteleyin.** Analitik, sohbet widget'ları, reklam pikselleri ve harita gömmeleri sayfa yüklendikten veya kullanıcı etkileşime geçtikten sonra yüklenebilir.
4. **Önce görsel geri bildirim verin.** Tıklanan butonun hemen tepki vermesini sağlayın (renk değişimi, yükleniyor durumu); ağır işi ondan sonra yapın.
5. **Büyük DOM'dan kaçının.** Binlerce öğe içeren sayfalarda her etkileşim daha pahalıdır. Uzun listeleri sayfalayın veya `content-visibility: auto` kullanın.

## CLS'yi iyileştirmek

1. **Görsellere ve videolara boyut verin.** Her `<img>` etiketinde `width` ve `height` niteliklerini belirtin veya CSS'te `aspect-ratio` kullanın.
2. **Dinamik içerik için alan ayırın.** Reklam, banner, çerez bildirimi ve gömülü içeriklere sabit bir yükseklik verin. Çerez bannerını içeriği itmeden, üstte sabit katman olarak gösterin.
3. **Font kaymasını önleyin.** Yedek fontun ölçülerini web fontuna yaklaştırın (`size-adjust`, `ascent-override`) veya fontu önceden yükleyin.
4. **Animasyonlarda yalnızca `transform` ve `opacity` kullanın.** `top`, `height`, `margin` gibi özellikleri canlandırmak hem kayma hem de performans sorunu yaratır.
5. **bfcache'i bozmayın.** Geri/ileri tuşuyla anında açılan sayfalar CLS ve LCP açısından da avantajlıdır; `unload` olay dinleyicileri bu önbelleği devre dışı bırakır.

## Platforma göre öncelikler

### WordPress

- **Sayfa oluşturucu yükü:** Ağır sayfa oluşturucular her sayfaya büyük CSS ve JS paketleri ekler. Mümkünse yerleşik blok editörü ve hafif bir tema kullanın.
- **Eklenti envanteri:** Her eklentinin ön yüze script ekleyip eklemediğini kontrol edin. Kullanılmayanları silin, yalnızca devre dışı bırakmak yetmez.
- **Önbellek:** Sunucu seviyesinde (LiteSpeed Cache, Nginx FastCGI cache gibi) veya bir önbellek eklentisiyle tam sayfa önbellek kurun.
- **Görseller:** WebP dönüşümü ve otomatik `srcset` sağlayan bir çözüm kullanın; medya kütüphanesine 4000 px fotoğraf yüklemeyin.

### Hazır e-ticaret altyapıları

- Tema seçiminde demo sitenin mobil PageSpeed sonucunu kontrol edin.
- Uygulama/eklenti mağazasından eklenen her uygulamanın (yorum, sohbet, pop-up, sadakat) sayfaya script eklediğini unutmayın.
- Ürün görsellerini platformun önerdiği boyutlarda yükleyin; kategori sayfalarında lazy-load'ın yalnızca ekran dışı görsellere uygulandığından emin olun.

### Özel yazılım

- Sunucu tarafında render (HTML'in hazır gelmesi) hem hız hem de yapay zekâ tarayıcıları için avantajlıdır. Detaylar: [ChatGPT aramasında görünmek](/blog/chatgpt-aramasinda-gorunmek).
- Tam sayfa önbellek, OPcache, HTTP/2 veya HTTP/3 ve Brotli/Gzip sıkıştırma temel gereksinimlerdir.

## Bu sitede neler yaptım ve sonuç ne oldu?

Bu siteyi baştan hız hedefiyle kurdum. Uyguladıklarım:

- Tüm CSS minify edilip sayfaya gömülü; render'ı engelleyen harici CSS isteği yok.
- Fontlar kendi sunucumda barındırılıyor, Türkçe karakterler için ayrı küçük bir alt küme kullanılıyor ve önceden yükleniyor.
- Yüklenen görseller otomatik olarak WebP'ye çevriliyor ve 480/960/1600 px boyutlarında `srcset` ile sunuluyor.
- Sayfalar tam sayfa önbellekten sunuluyor.
- Ana sayfadaki kaydırmaya bağlı animasyonlar yalnızca `transform` ve `opacity` kullanıyor; "hareketi azalt" tercihine saygı gösteriyor.
- Yerleşik analitik çerezsiz ve sayfa yüklendikten sonra küçük bir istekle çalışıyor; Google Analytics açıldığında da sayfa yüklendikten birkaç saniye sonra yükleniyor.

**Sonuç (Lighthouse, mobil, laboratuvar):** Blog yazılarında performans **95–100**, animasyonlu ana sayfada **93–99** (test makinesine göre değişiyor); erişilebilirlik, en iyi uygulamalar ve SEO **100**; LCP **1,4–1,8 sn**, CLS **0**.

**Gerçek bir hata ve dersi**
Yeniden tasarım sırasında ana sayfadaki büyük başlığa sürekli dönen bir renk geçişi animasyonu eklemiştim. Görsel olarak hoştu ama tarayıcı her karede yeniden boyama yaptığı için mobil testte Total Blocking Time **290 ms**'ye çıktı ve skor düştü. Animasyonu kaldırıp yerine sabit bir geçiş kullandığımda skor tekrar 99'a döndü. Ders: "küçük" görsel efektlerin bile maliyeti olabilir; her değişiklikten sonra mobilde test edin.

Rehberleri uzattıktan sonra benzer bir şey daha yaşadım: sayfalar büyüyünce ekranın altındaki bölümlerin (alt bilgi, ilgili yazılar, bülten) çizimi de ana iş parçacığını meşgul etmeye başladı. Bu bölümlere `content-visibility: auto` vermek ve ilk kaydırma hesaplamasını `requestAnimationFrame`'e taşımak, mobil testteki ana iş parçacığı süresini yaklaşık yarıya indirdi.


## Hangi araçlarla ölçmeli?

| Araç | Ne için? |
|---|---|
| **PageSpeed Insights** | Tek bir URL için hem saha hem laboratuvar verisi |
| **Search Console → Core Web Vitals raporu** | Tüm sitenin URL grupları bazında durumu ve sorunlu sayfa listeleri |
| **Chrome DevTools → Performance paneli** | LCP alt parçaları, uzun görevler, INP'ye yol açan etkileşimler |
| **Lighthouse (Chrome içinde)** | Geliştirme sırasında hızlı tekrar testleri |
| **web-vitals JavaScript kütüphanesi** | Kendi analitiğinizde gerçek kullanıcı ölçümü |

Ölçüm yaparken laboratuvar testini en az üç kez çalıştırın ve ortancaya bakın; tek bir test sunucu veya ağ dalgalanmasından etkilenebilir.

## Sık yapılan hatalar

1. **Yalnızca masaüstüne bakmak:** Asıl sorun neredeyse her zaman mobildedir.
2. **Skor için kullanıcıyı feda etmek:** Gerekli bir sohbet widget'ını veya formu sırf skor için kaldırmak yerine yüklenme zamanını erteleyin.
3. **LCP görselini lazy-load etmek:** En hızlı yüklenmesi gereken görseli en son yükletmek.
4. **Optimizasyon eklentisi üstüne eklenti kurmak:** Birbiriyle çakışan önbellek ve küçültme eklentileri siteyi bozabilir.
5. **Bir kez düzeltip unutmak:** Yeni eklenen bir pop-up, kampanya bannerı veya pazarlama scripti tüm emeği sıfırlayabilir. Ayda bir kontrol edin.

## Sonuç

PageSpeed'de 100 almak bir hedef değil, **iyi kurulmuş bir altyapının doğal sonucu**dur. Önce saha verisine bakın; sorun varsa LCP'yi alt parçalarına ayırarak teşhis edin, INP için JavaScript yükünü, CLS için boyutsuz öğeleri hedefleyin. Yeni bir web sitesi planlıyorsanız hızı baştan gereksinim listesine koyun. Diğer kriterler için [Web sitesi yaptırırken dikkat edilmesi gerekenler](/blog/web-sitesi-yaptirirken-dikkat-edilmesi-gerekenler) rehberime göz atabilirsiniz. Hız odaklı web siteleri için [floopping](https://floopping.com) ile çalışabilirsiniz.

## Sıkça Sorulan Sorular

### Core Web Vitals nedir?

Core Web Vitals, Google'ın sayfa yükleme hızı (LCP), etkileşime yanıt (INP) ve görsel kararlılığı (CLS) ölçen üç temel kullanıcı deneyimi metriğidir.

### İyi bir LCP değeri nedir?

Google'a göre LCP'nin, ziyaretlerin en az %75'inde 2,5 saniye veya altında olması "iyi" kabul edilir.

### PageSpeed skoru SEO'yu doğrudan etkiler mi?

Laboratuvar skoru doğrudan bir sıralama faktörü değildir. Google, sayfa deneyimi sinyallerinde gerçek kullanıcı verisine dayanan Core Web Vitals değerlerini dikkate alır ve alaka düzeyini her zaman önde tutar.

### Yaptığım iyileştirme neden Search Console'a hemen yansımıyor?

Saha verisi son 28 günün kayan ortalamasıdır. İyileştirmeler raporlara birkaç hafta içinde kademeli olarak yansır.

### WordPress sitemde PageSpeed skorunu nasıl yükseltirim?

Gereksiz eklentileri silin, hafif bir tema kullanın, tam sayfa önbellek kurun, görselleri WebP'ye çevirin, LCP görselini lazy-load'dan çıkarın ve üçüncü taraf scriptleri erteleyin.

### INP ile FID arasındaki fark nedir?

FID yalnızca ilk etkileşimin gecikmesini ölçüyordu; INP ise sayfa boyunca yapılan tüm etkileşimlerin yanıt süresini dikkate alır. INP, Mart 2024'te FID'in yerini aldı.

## Kaynaklar

- [Google Search Central — Core Web Vitals'ı anlama](https://developers.google.com/search/docs/appearance/core-web-vitals)
- [Google Search Central — Sayfa deneyimi](https://developers.google.com/search/docs/appearance/page-experience)
- [web.dev — Web Vitals](https://web.dev/articles/vitals)
- [web.dev — LCP'yi optimize etme](https://web.dev/articles/optimize-lcp)
- [web.dev — INP'yi optimize etme](https://web.dev/articles/optimize-inp)
- [web.dev — INP, Core Web Vitals'a dahil oldu](https://web.dev/blog/inp-cwv-launch)
- [Chrome for Developers — Lighthouse performans skoru](https://developer.chrome.com/docs/lighthouse/performance/performance-scoring)