Web Sitesi Tasarımı ve Yazılımı
Web sitesi hızı: Core Web Vitals nereden başlanmalı?
Web sitesi hızını LCP, INP ve CLS ölçümleriyle inceleyin; saha verisi, laboratuvar testi ve öncelikli düzeltmeler için uygulanabilir bir çalışma planı kurun.

Bir hız raporu iyi görünüyor, fakat telefonda menüye dokunduğunuzda açılmasını bekliyorsunuz. Başka bir sayfada metin hemen geliyor; kapak görseli yüklenince okumakta olduğunuz bölüm aşağı kayıyor. İki durumda da “site yavaş” demek mümkün, ancak çözülmesi gereken teknik sorun aynı değil. Core Web Vitals bu deneyimleri ayırarak incelemeyi kolaylaştırır. Yükleme, etkileşime yanıt ve görsel kararlılık için farklı göstergeler bulunur. Raporu işe yarar bir çalışma planına çevirmek de bu ayrımdan başlar: Hangi sayfada, hangi cihaz grubunda, hangi hareket sırasında sorun görülüyor? Ekibin araştıracağı neden ve düzeltmeyi doğrulayacağı senaryo bu sorularla belirlenebilir.
Sağlıklı başlangıç, hangi sayfada hangi kullanıcı deneyiminin bozulduğunu belirlemektir. Sonrasında ölçümün kaynağı, örneklemi ve koşulları incelenir; teknik neden araştırılır ve düzeltme aynı senaryoda yeniden sınanır. Bu rehber, kurumsal web sitesi veya içerik sitesi yöneten ekiplerin performans çalışmasını anlaşılır bir iş planına dönüştürmesine yardımcı olur. Buradaki örnekler varsayımsaldır ve herhangi bir iyileştirme oranı vaat etmez.
Core Web Vitals hangi deneyimleri ölçer?
26 Ekim 2026 tarihinde kontrol edilen web.dev rehberinde temel göstergeler LCP, INP ve CLS olarak açıklanır. LCP yükleme deneyimiyle, INP etkileşimlere yanıtla, CLS ise beklenmedik görsel yer değiştirmelerle ilgilidir. İyi eşikler sırasıyla en fazla 2,5 saniye, 200 milisaniye ve 0,1 olarak verilir. Değerlendirmede mobil ve masaüstü ayrımıyla yüzde 75'lik dilim dikkate alınır.
Bu sayıları bütün sitenin tek bir kullanıcıda aldığı süre gibi okumamak gerekir. Farklı ziyaretçiler farklı cihazlar, ağlar ve içerik durumlarıyla karşılaşır. Bir bilgisayarda sayfanın hızlı açılması bütün kullanıcıların aynı deneyimi yaşadığını kanıtlamaz. Ölçütlerin amacı her ziyaretin bire bir aynı olmasını sağlamak değil, kullanıcı deneyiminin önemli boyutlarını izlenebilir bir çerçevede değerlendirmektir. Raporu okurken hangi sayfa ve cihaz grubunu anlattığını belirleyin.
Laboratuvar testi ve saha verisini ayırın
Laboratuvar ölçümü kontrollü veya benzetilmiş koşullarda çalıştırılan bir testtir. Geliştirme sırasında sorunu tekrar üretmek, bir değişikliği karşılaştırmak ve olası darboğazı incelemek için faydalıdır. Saha verisi ise gerçek ziyaretlerin deneyiminden oluşur. Birbirleriyle ilişkili olsalar da aynı soruya aynı örneklem üzerinden cevap vermezler. Bu nedenle iki raporun farklı görünmesi otomatik olarak araçlardan birinin bozuk olduğu anlamına gelmez.
PageSpeed Insights açıklaması, gerçek kullanıcı verisinin bulunması için yeterli örnek gerektiğini belirtir. Sayfa verisi yetersizse kaynak düzeyindeki veri gösterilebilir; onun da bulunmadığı durumlar vardır. Yeni yayımlanan bir sayfada saha verisinin görünmemesi hızın iyi veya kötü olduğunu tek başına söylemez. Rapor başlığında değerlendirmenin tek adresi mi yoksa daha geniş kaynak grubunu mu kapsadığını kontrol edin.
Önce temsil edici sayfa gruplarını seçin
Sadece ana sayfayı test etmek, bütün sitenin durumunu açıklamayabilir. Hizmet sayfası, blog ayrıntısı, proje listesi ve iletişim formu farklı kaynaklar kullanabilir. Ortak şablonları belirleyerek her gruptan örnek seçin. Özellikle büyük görseli, ek betikleri veya farklı form işlevleri olan sayfalar ayrı incelenmelidir. Böylece bir düzeltmenin kaç sayfayı etkileyebileceği de daha net anlaşılır.
Her örnek için adres, şablon, cihaz sınıfı ve kullanılan test koşullarını kaydedin. Giriş yapılmış yönetici görünümü ile normal ziyaretçinin gördüğü sayfa aynı davranmayabilir. Önbellek durumu veya bir bildirim katmanının açık olması da sonucu etkileyebilir. Karşılaştırmanın anlamlı olması için bu farkları bilmek gerekir. Ölçümleri yalnızca en iyi sonucu seçerek raporlamak yerine değişkenliği ve gözlem sınırlarını açıkça belirtin.
LCP sorununda ana içeriğin neden geç göründüğünü araştırın
LCP yüksekse ilk akla gelen çözüm bütün görselleri küçültmek olabilir. Fakat ana içerik öğesinin ne olduğu ve hangi aşamada beklediği incelenmeden yapılan değişiklik hedefi kaçırabilir. Sunucunun yanıt vermesi, kaynağın keşfedilmesi, indirilmesi ve ekrana çizilmesi farklı gecikme noktaları oluşturabilir. Teknik inceleme bunları ayırmalıdır. Ana görselin dosya boyutu yalnızca olası nedenlerden biridir.
Görsel ve yükleme kararını birlikte değerlendirin
Varsayımsal bir hizmet sayfasında büyük kapak görseli geç görünüyorsa uygun çözünürlük, dosya biçimi ve kaynak seçimi incelenebilir. Ancak görselin yalnızca geç çalışan bir bileşen oluşturulduktan sonra bulunması söz konusuysa dosyayı sıkıştırmak tek başına yeterli olmayabilir. Üst bölümde hemen gerekli içerikle aşağıda ihtiyaç duyulan içerik aynı yükleme stratejisine zorlanmamalıdır. Çözüm, ölçülen gecikmenin bulunduğu aşamaya göre seçilmelidir.
INP incelemesinde gerçek etkileşimleri kaydedin
Ziyaretçinin menüyü açması, filtreyi değiştirmesi veya form alanıyla etkileşmesi sırasında arayüzün yanıtı önemlidir. Sayfanın açılmış görünmesi, bütün bu işlemlerin akıcı olduğu anlamına gelmez. Uzun süren işler veya gereksiz tekrar hesaplamalar etkileşim anında sorun yaratabilir. Hangi kontrolün hangi koşulda geciktiğini gösteren kayıt, genel bir “site yavaş” bildiriminden daha kullanışlıdır.
Yükleme odaklı otomatik bir test gerçek etkileşim örnekleminin yerini tutmaz. web.dev, kullanıcı girdisi olmadan çalışan Lighthouse testinde INP'nin doğrudan ölçülmediğini; TBT'nin laboratuvar incelemesinde yardımcı gösterge olduğunu açıklar. Bu iki metriği aynı isimle raporlamayın. Menü ve form gibi kritik görevleri deneyerek teknik kaydı kullanıcı davranışıyla ilişkilendirin. Bir düğmenin bekleme sırasında ikinci kez basılması da gözlenebilecek yararlı bir işarettir.
CLS sorununda beklenmedik hareketin kaynağını bulun
Bir sayfanın metni okunurken yeni görselin gelmesiyle içerik aşağı kayıyorsa ziyaretçinin konumu bozulur. Özellikle seçmek üzere olduğu düğme hareket ediyorsa yanlış etkileşim oluşabilir. Boyutları önceden ayrılmamış görsel veya sonradan eklenen bir bölüm incelenmesi gereken olası nedenlerdendir. Ancak her hareket otomatik olarak aynı ölçüm koşuluna girmez; teknik kayıtta gerçekten hangi kaymaların değerlendirildiği görülmelidir.
Görsel alanlarının oranını baştan belirlemek, sonradan gelen bileşenler için yer planlamak ve yazı tipi davranışını incelemek uygun çözümler arasında değerlendirilebilir. Burada amaç içeriği sabitlemek uğruna kesmek değildir. Uzun başlıklar, farklı dil sürümleri ve yeni görsellerle düzenin nasıl değiştiğini de kontrol edin. Bir kartın boşluklarını düzeltirken başka içerikleri görünmez hale getiren sert yükseklikler oluşturmak yeni kullanılabilirlik sorunları yaratabilir.
Üçüncü taraf araçları amaç ve maliyetle inceleyin
Sohbet araçları, video oynatıcıları, analiz etiketleri ve reklam bileşenleri iş ihtiyacını karşılayabilir; buna rağmen teknik maliyetleri vardır. Hangilerinin hangi sayfada neden çalıştığını listeleyin. Aynı amaca hizmet eden birden fazla aracın yanlışlıkla birlikte yüklenmesi gereksiz olabilir. Önce işlevin gerçekten kullanılıp kullanılmadığını netleştirin, sonra yükleme ve kapsam seçeneklerini değerlendirin.
Her üçüncü tarafı kaldırmak doğru bir genel kural değildir. İletişimi veya ölçümü destekleyen araç, uygun uygulamayla korunabilir. İşlev devre dışı bırakılarak yapılan karşılaştırma, etkisini araştırmak için bir deney olabilir; kalıcı karar ayrıca verilir. Bu sırada izin ve bilgilendirme süreçleri de ilgili sorumlularla değerlendirilmelidir. Performans iyileştirmesi, gerekli iş işlevlerinin habersizce ortadan kaldırılması anlamına gelmemelidir.
Sunucu, önbellek ve dosya dağıtımını bağlamıyla ele alın
Sunucu yanıtı veya önbellek politikası araştırma gerektirebilir. Ancak her siteye aynı ayarı kopyalamak doğru değildir. Değişmeyen bir görsel ile kullanıcıya özel içerik aynı koşullarda önbelleğe alınamaz. Teknik ekip hangi kaynağın ne kadar süre saklanabileceğini ve güncellemede nasıl yenileneceğini belirlemelidir. Yanlış yapılandırma eski içeriğin görünmesine veya kişiye özel bilginin uygunsuz paylaşılmasına yol açabilir.
İçerik dağıtım ağı veya farklı hosting planı da yalnızca isim üzerinden çözüm kabul edilmemelidir. Darboğazın nerede olduğu ve beklenen trafik modeli değerlendirilir. Sunucu hızlı yanıt verirken tarayıcıda ağır çalışan bir bileşen varsa sadece sunucu değiştirmek sınırlı fayda sağlayabilir. Önce mevcut durumu ölçmek, önerilen değişikliğin hangi sorunu çözeceğini açıkça yazmak ve sonrasında aynı koşullarda doğrulamak gerekir.
İyileştirmeleri etki ve güvenle sıralayın
Bulunan her uyarıyı aynı öncelikle düzeltmek verimli olmayabilir. Çok sayıda sayfada görülen, önemli görevi etkileyen ve nedeni anlaşılmış sorunlar öncelikli olabilir. Belirsiz bir öneri için önce küçük bir araştırma adımı planlanır. Her işlemde beklenen etki, sorumlu kişi, test yöntemi ve geri alma seçeneği bulunması çalışmayı denetlenebilir hale getirir.
Varsayımsal olarak kapak görseli kaynaklı gecikme bütün hizmet şablonlarında görülüyorsa ortak bileşen düzeltmesi birçok adresi etkileyebilir. Ancak önce birkaç temsil edici sayfada doğrulama yapılmalıdır. Aynı değişiklik bir sayfayı iyileştirirken diğerindeki kırpmayı bozabilir. Web tasarım ve yazılım çalışmasında teknik kazanım ile içerik görünümünü birlikte değerlendirmek bu tür yan etkileri fark etmeyi kolaylaştırır.
Başarıyı yalnızca yeşil puanla tanımlamayın
İyi performans göstergeleri önemli olsa da doğru hizmet açıklaması, anlaşılır menü ve çalışan formun yerini tutmaz. Google'ın Core Web Vitals rehberi bu ölçütleri sayfa deneyimiyle ilişkilendirir. Buradan belirli bir anahtar kelimede ilk sıraya çıkma sözü çıkarılamaz. Performans çalışması bir sıralama garantisi olarak değil kullanıcı deneyimi ve teknik kalite yatırımı olarak ele alınmalıdır.
Yayın sonrasında görsel eklenmesi, yeni etiket kurulması veya tasarım bileşeni değişikliği önceki sonucu etkileyebilir. Bu nedenle içerik ekibi için görsel kuralları, teknik ekip için yeniden ölçüm noktaları belirleyin. Web sitesi geliştirme kapsamına teslim sonrası kontrol sorumluluğu eklemek, hızın yalnızca lansman gününe ait bir özellik gibi görülmesini önler. Ölçüm tarihi ve uygulanan değişiklikler düzenli kaydedildiğinde sonraki kararlar da daha güçlü kanıta dayanır.
Kontrol kaydına ilgili içerik sürümünü de ekleyin. Aynı adres üzerinde kapak görseli veya etkileşimli bölüm değişmişse eski ölçümle doğrudan karşılaştırma yanıltıcı olabilir. Tarihli notlar, sorunun altyapıdan mı yeni içerikten mi kaynaklandığını araştırmayı kolaylaştırır ve ekipler arasındaki sorumluluk tartışmasını somut gözleme taşır.
Sık Sorulan Sorular
PageSpeed puanım düşükse ilk ne yapmalıyım?
Önce raporun hangi adresi, cihazı ve veri türünü anlattığını kontrol edin. Ardından sorunlu göstergeyi belirleyin ve ilgili kaynağı araştırın. Rastgele eklenti kurmak veya bütün görselleri kaldırmak yerine ölçümle bağlantılı bir değişiklik planlayın.
Saha verisi görünmüyorsa sitem yavaş mı?
Bu sonuç tek başına çıkarılamaz. Yeterli gerçek kullanıcı örneği bulunmaması olası nedenlerden biridir. Laboratuvar testleriyle inceleme yapılabilir; ancak rapordaki veri yokluğunu iyi ya da kötü performans kanıtı olarak sunmayın. Ölçümün kapsamını açıkça belirtin.
LCP, INP ve CLS aynı sorunu mu anlatır?
Hayır. Yükleme, etkileşime yanıt ve görsel kararlılık farklı deneyimleri değerlendirir. Bir sayfada birden fazlası sorunlu olabilir. Her gösterge için ilgili davranışın ve teknik nedenin ayrıca incelenmesi gerekir; tek düzeltmenin hepsini çözeceği varsayılmamalıdır.
Bütün görselleri silmek siteyi iyileştirir mi?
Dosya aktarımı azalabilir ama içerik anlamı ve hizmet sunumu zarar görebilir. Görselin amacı, boyutu ve yüklenme biçimi değerlendirilmelidir. Yararlı görseli uygun biçimde sunmak, bütün görsel içeriği kaldırmaktan daha dengeli bir karar olabilir.
İyi Core Web Vitals sonuçları Google'da ilk sırayı getirir mi?
Hayır. Bu göstergeler tek başına belirli sıralama garantisi vermez. Arama ihtiyacına uygun içerik, teknik erişilebilirlik ve diğer değerlendirmeler de önemlidir. Teknik iyileştirmeyi kesin trafik veya satış artışı sözüyle birleştirmek doğru değildir.
İyileştirmeden sonra neden tekrar kontrol gerekir?
Bir değişiklik farklı şablonları, cihazları ve etkileşimleri farklı etkileyebilir. Ayrıca saha verisi yeni deneyimleri zamanla yansıtır. Aynı test koşullarında yeniden ölçüm ve gerçek görev kontrolü yapmak, kazanımın yanında olası yan etkileri de ortaya çıkarır.