Site Hızı ve Core Web Vitals: Ölçümden İyileştirmeye

Site hızı ve Core Web Vitals; bir sayfanın yüklenme ve etkileşim performansını ölçen metriklerin genel adıdır ve Google’ın sıralama sinyallerinden biri olarak kabul edilir. Araştırmalara göre yüklenme süresi 3 saniyeden 5 saniyeye çıktığında hemen çıkma oranı yaklaşık yüzde 38 artar; bu yüzden hız optimizasyonu hem kullanıcı deneyimini hem dönüşüm oranını doğrudan etkiler. Diyez Media’da web sitesi performans çalışmalarımızda önce PageSpeed Insights ve Search Console verisiyle ölçüm yapıyor, ardından iyileştirmeleri uygulama zorluğuna göre önceliklendiriyoruz. Bu rehberde Core Web Vitals metriklerini sade dille anlatıyor, raporları okumayı öğretiyor ve somut iyileştirme adımlarını sıralıyoruz.

Core Web Vitals nedir ve hangi metrikleri içerir?

Core Web Vitals; Google’ın kullanıcı deneyimini ölçmek için belirlediği üç temel metrikten oluşur. Bu metrikler; sayfanın yüklenme hızı, etkileşime yanıt hızı ve görsel kararlılığını ayrı ayrı ölçer. Üçü birlikte; kullanıcının sayfayı açtığı andan etkileşime geçip okumaya başladığı ana kadar geçen deneyimi temsil eder.

• LCP (En Büyük İçerik Boyama): Sayfanın ana içeriğinin yüklenme süresi. İdeal değer 2,5 saniyenin altıdır; 4 saniye üstü “zayıf” olarak değerlendirilir.
• INP (Sonraki Boyama Etkileşimi): Sayfanın kullanıcı etkileşimlerine (tıklama, dokunma, tuş basımı) yanıt verme süresi. İdeal değer 200 milisaniyenin altıdır; 500 milisaniye üstü zayıftır.
• CLS (Kümülatif Düzen Kayması): Sayfa yüklenirken görsel öğelerin beklenmedik kayma miktarı. İdeal değer 0,1’in altındadır; 0,25 üstü zayıftır.

Bu üç metrik, Google’ın sıralama sisteminde “sayfa deneyimi” sinyali olarak birleştirilir. Metriklerin iyi olması tek başına sıralama garanti etmez; ancak içerik ve diğer sinyaller eşitken, hızlı ve stabil sayfalar öne geçer.

LCP neden ölçülür ve nasıl iyileştirilir?

LCP; kullanıcının sayfada gördüğü en büyük görsel öğenin (genellikle ana görsel, başlık görseli veya büyük resim) yüklenme süresidir. Yavaş LCP’nin dört ana nedeni vardır: yavaş sunucu, yavaş görsel teslimatı, bloke eden JavaScript ve kaynak önceliklendirmesinin yanlış kurulması.

LCP iyileştirme adımları uygulama zorluğuna göre sıralanır:

1. Görselleri WebP formatına çevirin ve yeniden boyutlandırın: Mobil görünümde asla 1200 pikselden büyük görsel yüklenmemeli; bu tek adım LCP’yi yüzde 30-50 düşürebilir.
2. Görsele fetchpriority=”high” ekleyin: LCP görselinin erken yüklenmesi sağlanır; tarayıcı önceliğini bu kaynağa verir.
3. Önbellekleme ve CDN kullanın: Statik dosyalar CDN’den servis edilir; Türkiye’de yerel pop noktaları olan CDN’ler yanıt süresini belirgin düşürür.
4. Bloke eden scriptleri ertele: LCP’den önce çalışması gerekmeyen JavaScriptler ertelenir; kritik CSS satır içine alınır.
5. Sunucu yanıt süresini (TTFB) düşürün: Paylaşımlı hostingden VPS veya bulut altyapıya geçiş, sunucu kaynaklı gecikmeleri çözer.

Ölçüm tarafında LCP’nin 75. yüzdelik dilimdeki değeri esas alınır: kullanıcıların en az yüzde 75’inin LCP’si 2,5 saniyenin altındaysa metrik “iyi” sayılır. Tek bir laboratuvar testi değil, saha verisi (Gerçek Kullanıcı Ölçümleri) karar göstergesidir.

INP nedir ve etkileşim gecikmesi nasıl çözülür?

INP; kullanıcının sayfayla etkileşimine tarayıcının yanıt verme süresini ölçer. Eski metrik FID’nin yerini alan INP; yalnızca ilk tıklamayı değil, sayfa ömrü boyunca tüm etkileşimleri değerlendirir. Yüksek INP; kullanıcının tıklaması ile sayfanın tepki vermesi arasında hissedilir bir gecikme yaşanması demektir.

INP’yi yavaşlatan ana nedenler:

• Ana iş parçacığını meşgul eden uzun görevler: Büyük JavaScript dosyalarının çalışması, tıklama yanıtlarını erteler.
• Aşırı büyük JavaScript paketleri: Tüm kütüphanelerin sayfada yüklenmesi; etkileşimli öğelerin geç hazırlanmasına yol açar.
• Çalışan animasyon ve listener yoğunluğu: Gereksiz animasyonlar ve her öğeye eklenmiş dinleyiciler, tarayıcıyı yorar.

İyileştirme adımları; JavaScript boyutunu küçültme, kod bölme (code splitting), üçüncü parti scriptleri erteleme ve kritik olmayan widgetları yükleme sonrasına bırakma üzerine kurulur. Örneğin reklam ve analiz scriptleri; kullanıcı etkileşimi sonrası yüklenirse, INP belirgin iyileşir. INP hedefi 200 milisaniyenin altıdır; 500 milisaniye üstü, ziyaretçinin yarısından fazlasının gecikme hissettiği anlamına gelir.

CLS nedir ve düzen kayması nasıl önlenir?

CLS; sayfa yüklenirken öğelerin beklenmedik şekilde yer değiştirmesini ölçer. Kullanıcı bir makaleyi okurken sayfanın kayması, yanlış düğmeye tıklanmasına ve okuma akışının bozulmasına yol açar. CLS, yüzdelik oranla ölçülür; 0,1 altı iyi, 0,25 üstü zayıf kabul edilir.

Düzen kaymasının başlıca nedenleri:

• Boyut tanımlanmamış görseller ve videolar: Görsel etiketi genişlik ve yükseklik bilgisi içermezse, indirilirken sayfa kayar.
• Geç yüklenen reklamlar ve widgetlar: Reklam alanına boyut ayrılmazsa, reklam geldiğinde içerik aşağı iter.
• Dinamik eklenen içerik: Sayfa üstünde geç görünen bildirim, çerez uyarısı ve banner’lar yer kaydırır.
• Web fontları: Yazı tipi geç yüklenince metin boyutu ve satır yapısı değişir.

Çözüm; tüm görsel ve videolara sabit boyut tanımlamak, reklam alanlarına rezervasyon bırakmak, çerez banner’larını sabit konumlandırmak ve fontları font-display: swap ile yüklemektir. Bu önlemler alındığında CLS çoğu sitede 0,1 altına rahatça iner.

PageSpeed Insights raporu nasıl okunur?

PageSpeed Insights; bir URL’nin hem laboratuvar hem saha verisini tek ekranda gösteren ücretsiz Google aracıdır. Rapor okuma düzeni şöyledir:

• Saha verisi (üst bölüm): Gerçek kullanıcıların Chrome tarayıcı verisinden üretilir; 28 günlük ortalamayı yüzdelik dilimlerle gösterir. Bu bölüm, optimizasyonun gerçek etkisini yansıtır.
• Laboratuvar verisi: Lighthouse motorunun kontrollü ortamda ölçtüğü değerlerdir; hata ayıklama ve sorun tespiti için kullanılır.
• Fırsatlar (Opportunities): En büyük kazanımları sunan iyileştirmeler; tahmini saniye tasarrufuyla birlikte listelenir.
• Teşhisler (Diagnostics): Uygulandığında daha az etki eden ama takip edilmesi gereken iyileştirmeler.
• Ortaya çıkan sorunlar (Passed audits): Geçen denetimler; neyin doğru yapıldığını gösterir.

Rapor okurken en sık yapılan hata; laboratuvar puanına takılıp saha verisini görmezden gelmektir. Karar, saha verisine göre verilmelidir; laboratuvar puanı hata kaynağını bulma aracıdır. Ayrıca mobil ve masaüstü ayrımı yapılmalı; mobil değerler sıralama ve kullanıcı açısından önceliklidir.

Search Console’daki Core Web Vitals raporu ne gösterir?

Google Search Console’un Core Web Vitals raporu; sitenin tüm URL’lerini “iyi” ve “iyileştirilmesi gerekli” gruplarına ayırır ve URL örneklerini gösterir. Rapor; düşük performanslı sayfaların tespitini ölçüm araçları kurmadan yapmayı sağlar.

Rapor kullanım adımları:

1. Raporda “Mobil” sekmesiyle başlayın; “İyileştirilmesi gerekli” gruptaki URL sayısına bakın.
2. Örnek URL’lere tıklayıp PageSpeed Insights’a yönlendirin; sorunun LCP mi, INP mi, CLS mi olduğunu belirleyin.
3. Sorunlu URL’leri; şablon (tema), şablon grubu ve cihaz kırılımına göre gruplayın.
4. En çok trafik alan sorunlu şablonu önceliklendirin; iyileştirme sonrası raporun 28 günlük verisini izleyin.

Search Console verisi; 28 günlük birikmiş saha verisi olduğu için yapılan iyileştirmenin rapora yansıması 2-4 hafta alır. Bu yüzden iyileştirme sonrası “hala kötü” görünen rapor, işlemin başarısız olduğu anlamına gelmez; doğrulama için laboratuvar testi veya üçüncü parti saha izleme araçları kullanılır.

Hız iyileştirmeleri hangi sırayla uygulanmalı?

Hız optimizasyonu; önce büyük kazanım ve düşük riskli adımlardan başlanmalıdır. Ajansımızın uyguladığı öncelik sırası şöyledir:

Düşük zorluklu adımların tamamı bir hafta içinde uygulanabilir; bu adımlar çoğu sitede LCP’yi 2,5 saniyenin altına çekmek için yeterlidir. JavaScript ve sunucu iyileştirmeleri; e-ticaret gibi ağır altyapılarda ikinci fazda yapılır. Her faz sonunda ölçüm tekrarlanır ve sonuç kaydedilir; böylece hangi adımın ne kadar katkı yaptığı bilinir.

E-ticaret ve kurumsal sitelerde hız neden kritiktir?

E-ticaret sitelerinde hız; doğrudan satışa dönüşür. Araştırmalar, yüklenme süresinde 0,1 saniyelik iyileşmenin dönüşüm oranını yüzde 8’e varan oranda artırabileceğini gösterir. Sepet sayfası, ödeme sayfası ve ürün listesi gibi kritik adımlardaki gecikmeler; sepet terk oranını yükseltir.

Kurumsal sitelerde ise hız; güven ve marka algısını belirler. Yavaş açılan kurumsal siteler, ziyaretçinin ilk izleniminde profesyonellik algısını zedeler; B2B ziyaretçilerin büyük bölümü yavaş sitede bilgi aramayı bırakır. Ayrıca hız; hem organik sıralama hem de reklam kalite puanı üzerinden reklam maliyetine etki eder: yavaş açılış sayfaları, Google Ads’te daha yüksek tıklama başına maliyet demektir.

Bu yüzden hız çalışması; pazarlama bütçesinin bir parçası olarak yıllık plana alınmalı, altyapı ve tema değişikliklerinde yeniden ölçüm yapılmalıdır.

Yeni tema ve eklenti değişikliği hızı nasıl etkiler?

Tema ve eklenti seçimi; site hızının uzun vadeli kaderini belirler. Ağır temalar, sayfa yüklenmeden önce çalıştırılması gereken yüzlerce satır JavaScript ve CSS getirir; bu da LCP ve INP’yi doğrudan kötüleştirir. Eklentiler ise her biri birkaç script ve stil yükleyerek hızı kademeli eritir.

Değişiklik öncesi yapılması gereken kontroller:

• Yeni temanın demo sayfası PageSpeed Insights’ta test edilir; mobil LCP 2,5 saniyenin altında değilse tema elenir.
• Eklenti sayısı minimumda tutulur; aynı işi yapan iki eklenti yerine tek ve hafif olan seçilir.
• Her eklenti kurulumundan önce ve sonra hız testi yapılır; değer düşüşü eklentinin maliyetini ortaya koyar.
• Tema ve eklenti güncellemeleri; test ortamında denendikten sonra canlıya alınır.

Bu kontroller; hız çalışmasının kalıcılığını sağlar. Tek seferlik optimizasyon yapıp ağır bir eklenti eklemek, emeğin tamamını geri alır; bu yüzden hız disiplini sürekli bir süreç olarak yönetilmelidir.

Sık yapılan hız optimizasyonu hataları nelerdir?

Hız çalışmasında yapılan hatalar; emeğin boşa gitmesine veya kullanıcı deneyiminin kötüleşmesine yol açar:

• Yalnızca laboratuvar puanına odaklanmak: Lighthouse puanını 100 yapmak için yapılan zorlamalar; saha verisini iyileştirmez, hatta görsel kalitesini düşürür.
• Aşırı sıkıştırma: Görsellerde kalite kaybı, ziyaretçinin ürünü incelememesiyle sonuçlanır; dengeli sıkıştırma kuralı uygulanmalıdır.
• Lazy loading’i her görsele uygulamak: LCP görseli ertelenirse metrik kötüleşir; LCP görseli her zaman öncelikli yüklenir.
• Tüm scriptleri ertelemek: Analitik ve reklam ölçümleri gecikirse veri kaybı yaşanır; kritik ölçüm scriptleri öncelikli tutulmalıdır.
• Önbelleği yanlış yapılandırmak: Sık değişen içeriği uzun süre önbellekte tutmak, kullanıcıya eski veri gösterir.

Bu hataların ortak çözümü; ölçüm önceliğini saha verisine vermek ve her iyileştirmenin kullanıcı deneyimi üzerindeki etkisini izlemektir.

Sonuç

Site hızı ve Core Web Vitals; LCP, INP ve CLS metrikleriyle ölçülen, kullanıcı deneyiminin ve sıralamanın ortak sinyalidir. Önce Search Console ve PageSpeed Insights ile saha verisini okuyun, ardından düşük zorluklu adımlardan başlayarak; görsel, önbellek, CDN ve JavaScript optimizasyonunu uygulayın. Her değişikliği ölçün ve raporlayın; hız disiplinini tema ve eklenti politikasına taşıyın. Diğer teknik konular için teknik SEO rehberimizi ve mobil SEO rehberimizi inceleyebilirsiniz.

Son güncelleme: Ağustos 2026. Core Web Vitals eşikleri ve ölçüm yöntemleri Google tarafından güncellenebilir; rehberimiz yıllık revizyon takvimimiz kapsamında her yıl Ağustos ayında yenilenmektedir.

Sık Sorulan Sorular

Bu rehber 14 Ağustos 2026 tarihinde gözden geçirildi.