Core Web Vitals’ı iyileştirmek için önce gerçek kullanıcı verisiyle hangi metriğin kötü olduğunu bulur, sonra o metriğin nedenine göre müdahale edersiniz. Google’ın hedefleri sayfa yüklemelerinin %75’inde ana içeriğin 2,5 saniye içinde görünmesi (LCP), tıklamalara 200 milisaniye içinde tepki verilmesi (INP) ve sayfanın 0,1’den fazla kaymamasıdır (CLS). Pratikte LCP için ilk ekrandaki görseli önden ve küçük yüklemek, INP için ana iş parçacığını uzun görevlerden kurtarmak, CLS için de görsellere ve sonradan yüklenen alanlara önceden yer ayırmak sonuçların çoğunu getirir.
Aşağıdaki rehber Google’ın web.dev ve Search Central belgelerine dayanıyor. Ekim 2026’da antargetech.com’u yeniden kurarken yaptıklarımızı da örnek olarak ekledik.
Core Web Vitals nedir ve neden önemli?
Core Web Vitals, bir sayfanın kullanıcıya nasıl hissettirdiğini ölçen üç metriktir: yüklenme hızı, etkileşime tepki ve görsel kararlılık. Her biri sayfa yüklemelerinin 75. yüzdelik dilimine göre, mobil ve masaüstü için ayrı değerlendirilir. Yani ziyaretlerinizin dörtte üçü eşiğin altında kalıyorsa o metrik “iyi” sayılır.
| Metrik | Ne ölçer? | İyi | İyileştirilmeli | Zayıf |
|---|---|---|---|---|
| LCP | Ana içeriğin görünme süresi | 2,5 sn ve altı | 2,5–4 sn | 4 sn üstü |
| INP | Tıklama, dokunma ve tuşlara tepki süresi | 200 ms ve altı | 200–500 ms | 500 ms üstü |
| CLS | Sayfadaki beklenmedik kaymalar | 0,1 ve altı | 0,1–0,25 | 0,25 üstü |
INP, Mart 2024’te First Input Delay’in (FID) yerini aldı. FID yalnızca ilk etkileşimi ölçüyordu; INP sayfadaki tüm tıklama, dokunma ve tuş basışlarını izler.
Google, iyi Core Web Vitals değerlerini Arama’da başarı için açıkça öneriyor ve bunların ana sıralama sistemlerinin ödüllendirmek istediği sayfa deneyimiyle örtüştüğünü söylüyor. Ancak bu metrikleri sıralamayı tek başına belirleyen bir puan olarak tanımlamıyor. İyi bir içerik yavaş bir sayfada da sıralanabilir; ama aynı soruyu cevaplayan iki sayfadan hızlı olanı kullanıcıyı daha az kaybeder.
Önce ölçün: saha verisi ve laboratuvar verisi
İki tür veri var ve farklı şeyler söylüyorlar. PageSpeed Insights ikisini aynı ekranda gösterir:
- Saha verisi: Chrome kullanıcılarından toplanan gerçek ölçümler (Chrome User Experience Report, CrUX). Son 28 günü kapsar. Google’ın değerlendirmesi bu veriye dayanır.
- Laboratuvar verisi: Lighthouse’un orta seviye bir telefonu ve mobil ağı taklit ederek yaptığı tek bir yükleme. Sorunun nedenini bulmak için iyidir ama gerçek kullanıcıların cihaz ve bağlantı çeşitliliğini yansıtmaz.
Search Console’daki Core Web Vitals raporu da CrUX verisini kullanır. Benzer sayfaları gruplar ve bir grubun durumunu en kötü metriğine göre belirler: LCP ve INP iyi, CLS zayıfsa grup “zayıf” görünür.
Trafiği az olan sitelerde bu raporlar boş kalabilir. Gizlilik nedeniyle CrUX’in yeterli sayıda ziyaret toplaması gerekiyor. Ekim 2026’da kendi sitemizde Search Console mobil ve masaüstü için “son 90 güne ait yeterli kullanım verisi yok” diyordu. Bu durumda Lighthouse sonuçlarına ve kendi topladığınız ölçümlere bakarsınız. Google’ın web-vitals kütüphanesi, aynı üç metriği kendi ziyaretçilerinizden toplayıp analitik aracınıza göndermenizi sağlar.
LCP’yi hızlandırmak
LCP genellikle ilk ekrandaki büyük görsel ya da ana başlıktır. Google, LCP süresini dört parçaya ayırarak incelemeyi öneriyor; hangi parçanın uzun olduğunu bulmadan yapılan iyileştirme bir parçadan kazandığını diğerine kaydırabilir.
- İlk bayt süresi (TTFB): Sunucunun ilk cevabı. Yönlendirme zincirlerini azaltın, sayfaları önbelleğe alın ve ziyaretçiye yakın bir CDN kullanın.
- Kaynak yükleme gecikmesi: Tarayıcının LCP görselini fark edip indirmeye başlaması. Görseli HTML içinde doğrudan verin,
fetchpriority="high"ekleyin ve yalnızca CSS ya da JavaScript içinden çağrılıyorsapreloadkullanın. Google’ın uyarısı açık: LCP görseli asla tembel yüklenmemeli (loading="lazy"). - Kaynak yükleme süresi: Görselin inmesi. Ekran boyutuna uygun ölçüde, WebP ya da AVIF biçiminde ve sıkıştırılmış görsel sunun.
- Öğe çizim gecikmesi: Görsel indikten sonra ekrana çizilmesi. Kullanılmayan CSS’i atın, küçük stilleri sayfaya gömün,
<head>içindeki eşzamanlı betikleri erteleyin. Sayfayı sunucuda ya da derleme sırasında hazır HTML olarak üretmek, JavaScript’in çalışmasını beklemeden içeriği gösterir.
INP’yi iyileştirmek
INP, kullanıcının bir düğmeye bastığı andan ekranda sonucun göründüğü ana kadar geçen süredir. Bu süre üç aşamadan oluşur: girdi gecikmesi (tarayıcı başka bir işle meşgul), işleme süresi (olay kodunuzun çalışması) ve sunum gecikmesi (yeni karenin çizilmesi).
En sık neden, ana iş parçacığını uzun süre meşgul eden JavaScript’tir. Şunlar çoğu durumda işe yarar:
- Uzun görevleri bölün: Bir tıklamada yapılacak işi parçalara ayırın; ekranı güncelleyen kısmı önce çalıştırın, geri kalanını
setTimeoutgibi yöntemlerle sonraki göreve bırakın. - Sayfa yüklenirken ana iş parçacığını boğmayın: Büyük betikleri ve gereksiz kütüphaneleri ilk yüklemeden çıkarın.
- DOM’u küçük tutun: Binlerce öğeli sayfalar her etkileşimde daha yavaş çizilir. Ekran dışındaki bölümler için
content-visibilitykullanılabilir. - Yerleşimi zorlamayın: Aynı görevde stili değiştirip hemen ardından öğe ölçülerini okumak tarayıcıyı yerleşimi baştan hesaplamaya zorlar.
Mobil uygulama kullanır gibi çalışan web panellerinde, filtre ve arama kutuları gibi her tuşta çalışan kodlar INP’nin en çok bozulduğu yerlerdir.
CLS’yi düşürmek
CLS, siz okurken içeriğin aşağı ya da yana kaymasını ölçer. Kullanıcı bir yere tıkladıktan sonraki 500 milisaniye içindeki kaymalar sayılmaz; sorun, kullanıcının beklemediği kaymalardır. Google’ın listelediği başlıca nedenler ve çözümleri:
| Neden | Çözüm |
|---|---|
| Boyutu belirtilmemiş görsel ve videolar | width ve height niteliklerini ya da CSS aspect-ratio değerini verin |
| Reklam, harita ve gömülü içerikler | Kutunun en küçük beklenen boyutu kadar yer ayırın; içerik gelmese de alanı koruyun |
| Sonradan eklenen bantlar ve bildirimler | İçeriği itmek yerine üstüne bindirin ya da yerini baştan ayırın |
| Web yazı tipleri | Önemli yazı tiplerini önden yükleyin, ölçüleri yakın bir yedek yazı tipi kullanın |
| Animasyonlar | top ya da left yerine transform ile hareket ettirin |
Ayrıca sayfanın tarayıcının geri/ileri önbelleğine (bfcache) uygun olması, geri dönüldüğünde sayfanın baştan yüklenip yeniden kaymasını önler.
Bu sitede neler yaptık?
antargetech.com’u Ekim 2026’da yeniden kurarken ana sayfanın mobil Lighthouse sonucu Performans 97; Erişilebilirlik, En İyi Uygulamalar ve SEO 100 oldu. En büyük kazanç üç yerden geldi:
- İlk ekrandaki görseli önden yüklemek: Tarayıcı LCP görselini HTML’i okur okumaz istemeye başlıyor.
- Görselleri küçültmek: Görseller derleme sırasında ekran boyutlarına göre WebP olarak üretiliyor ve her birinin genişliği ile yüksekliği HTML’de yazılı. Bu, CLS’yi de sıfıra yakın tutuyor.
- Kullanılmayan CSS’i atmak: Sayfa başına CSS 727 kB’den 134 kB’ye indi ve sayfaya gömüldü; ayrı bir stil dosyasının inmesini beklemeye gerek kalmadı.
Sayfalar derleme sırasında hazır HTML olarak üretiliyor ve Cloudflare üzerinden sunuluyor; bu da ilk bayt süresini kısa tutuyor. Bir de ters örnek: blog yazılarında ilk ekrandaki en büyük öğe görsel değil başlık metni. Kapak görselini önden yüklemeyi denediğimizde LCP iyileşmedi, kötüleşti; görsel, başlığı çizmek için gereken kaynaklarla bant genişliği için yarıştı. Bu yüzden kapaklar tembel yükleniyor. Kural basit: önden yüklenecek olan, gerçekten LCP olan öğedir.
Taşıma sırasında hızın yanında yönlendirmeleri ve dizine eklemeyi de nasıl yönettiğimizi site taşıma rehberimizde, sitenin ChatGPT ve Google’ın yapay zeka özetlerinde kaynak gösterilmesi için yaptıklarımızı da GEO nedir yazımızda anlattık.
Sık sorulan sorular
Lighthouse puanım yüksek ama Search Console “zayıf” diyor. Neden?
Lighthouse tek bir yüklemeyi taklit eder; Search Console son 28 günün gerçek ziyaretlerine bakar. Kullanıcılarınız daha yavaş telefonlardan ya da zayıf bağlantılardan geliyorsa saha verisi laboratuvar sonucundan kötü olur. Google’ın değerlendirmesi saha verisine dayanır.
Düzelttikten sonra ne zaman yansır?
Saha verisi 28 günlük bir dönemi kapsadığı için iyileşme kademeli görünür. Sorunu tüm sayfalarda düzelttikten sonra Search Console’da sorunun ayrıntı sayfasından doğrulamayı başlatabilirsiniz. Google 28 gün boyunca saha verisini izler; sorun bu sürede hiçbir adreste görünmezse düzeltilmiş sayılır. Doğrulama sayfaları yeniden taratmaz, yalnızca izleme dönemini başlatır.
Core Web Vitals sıralamayı ne kadar etkiler?
Google bunları sayfa deneyiminin bir parçası olarak değerlendiriyor ve iyi değerler öneriyor, ancak tek başına belirleyici bir sıralama puanı olarak tanımlamıyor. İçeriğin soruyu iyi cevaplaması hâlâ önce gelir; hız, aynı kalitede iki sayfa arasındaki farkı belirler ve ziyaretçiyi sayfada tutar.
Sonuç
Core Web Vitals’ı iyileştirmenin sırası hep aynı: saha verisiyle sorunlu metriği bulun, laboratuvar araçlarıyla nedenini teşhis edin, sonra o nedene yönelik düzeltin. Çoğu sitede kazancın büyük kısmı ilk ekrandaki görseli doğru yüklemekten, gereksiz JavaScript ve CSS’i atmaktan ve sayfadaki öğelere önceden yer ayırmaktan gelir.
Sitenizin hızını ve teknik SEO durumunu birlikte değerlendirmek isterseniz SEO ve dijital görünürlük hizmetimize göz atabilir ya da yeni bir proje için web ve mobil uygulama geliştirme sayfamızdan bize ulaşabilirsiniz.
