Core Web Vitals ve hosting: LCP, CLS, INP’yi hızlandırma

Core Web Vitals (LCP, CLS, INP), kullanıcı deneyimini sayısallaştıran üç temel metriktir. Hosting tarafında yapılan hatalar doğrudan bu metrikleri düşürür: kaynakların geç gelmesi LCP’yi uzatır, görsel/slot kaymaları CLS’i bozar, yoğun istekler veya kötü önbellekleme INP’yi kötüleştirir. Bu rehberde her metriğin hosting ile ilişkisini netleştirip, ölçümden ayara kadar uygulanabilir bir kontrol akışı veriyorum.

Core Web Vitals nedir ve hosting nereye dokunur?

Core Web Vitals; bir sitenin yükleme hızı ve etkileşim kalitesini tarayıcı ölçümleriyle değerlendirir. “Hosting önemli” demek yerine, her metriğin hangi sunucu/dağıtım davranışından beslendiğini net şekilde ayırmak gerekir.

LCP (Largest Contentful Paint) ve hosting kaynakları

LCP, sayfadaki en büyük içerik bloğunun (çoğunlukla hero görseli veya başlık alanı) ekranda görünmesine kadar geçen süreyi ölçer.

Hosting etkisi genellikle şunlardan gelir: - Terapötik olmayan yanıtlar: HTML veya büyük görselin ilk byte’ı geç gelirse LCP uzar. - Yetersiz sıkıştırma (compression): Gzip/Brotli aktif değilse HTML/CSS/JS daha geç iner. - Cache katmanı eksikliği: CDN olmadan, büyük görseller ve statik dosyalar her istekle origin’den geç gelirse LCP uzar. - TLS/handshake gecikmesi: HTTP/2/HTTP/3 ve sertifika kurulumu doğru değilse ilk yükleme kötüleşir.

CLS (Cumulative Layout Shift) ve hosting kaynaklı kaymalar

CLS, sayfa içinde beklenmedik “yer değiştirmelerin” toplam etkisini ölçer. Hosting tek başına “CSS/JS yazımı” hatası üretmez; ancak içerik gecikmesi ve farklı boyutlarda teslimat CLS’i tetikleyebilir.

Hosting etkisi genellikle: - Görseller için boyutların tanımlanmaması: Görsel geç geldiğinde yer kaplaması sonradan değişir. - Stil/Font geç yükleme: Font swap veya geç yüklenen CSS, layout kaymasına neden olabilir. - Önbellekleme davranışı: “İlk yüklemede A boyutu, sonraki yüklemede B boyutu” gibi tutarsız içerik dağıtımı CLS’i yükseltir.

INP (Interaction to Next Paint) ve sunucu/CPU gecikmesi

INP, kullanıcının etkileşimini (tıklama, tuş, seçim) takiben bir sonraki güncellenmiş ekrana kadar geçen süreyi ölçer. INP kötüleşiyorsa genellikle tarayıcı tarafında uzun ana iş parçacığı (main thread) veya arka uç gecikmesi vardır.

Hosting etkisi şunlara dayanır: - Yanıt süresi artışı (TTFB ve özellikle istekten yanıt bekleme): Örneğin “filtre uygula” gibi istekler yavaş dönerse etkileşim gecikir. - Kaynak rekabeti: CPU limitleri, Node.js/uygulama süreçlerinin sıraya girmesi, bazen tek çekirdekli iş yükünde INP’yi düşürür. - Yanıtların önbellekten gelmemesi: Her etkileşim origin’e gidiyorsa INP ve genel gecikme artar. - Yetersiz süreç ayarları: Keep-Alive, HTTP keep-alive yönetimi, socket tükenmesi gibi durumlar istekleri geciktirir.

Hangi metrik hangi katmandan etkilenir? (Somut eşleştirme)

Aşağıdaki eşleştirme, hangi problemi hangi katmanda arayacağınızı hızlandırır.

Ölçüm: Core Web Vitals’i doğru görmeden hosting ayarı boşa gider

Önce veriyi toplayın. Hosting değiştirseniz bile “ölçüm yöntemi yanlış” ise sonuç çıkaramazsınız.

Hangi araçlarla bakılmalı?

• Google PageSpeed Insights: Hem alan (field) hem laboratuvar (lab) görünümü verir.
• Chrome DevTools: Network ve Performance üzerinden büyük içerik ve gecikme noktaları görünür.
• web-vitals (tarayıcı tarafı): Kendi metrik toplamanız için olay bazlı izleme kurabilirsiniz.

Ne aramalısınız? (LCP/CLS/INP için net odak)

• LCP: LCP öğesi ne? Kaynağı (img mi, video mu, h1 mi)? Response size ve timing (TTFB, download süresi) nedir?
• CLS: En büyük shift hangi elementte? “Layout Shift row”/snapshot’ta hangi kayma var?
• INP: En yavaş etkileşim hangisi? O etkileşime giden isteklerin (fetch/xhr) süresi kaç ms?

Hosting tarafında uygulanabilir kontrol listesi (LCP/CLS/INP odaklı)

Aşağıdaki maddeler, NetKıyas’ta VDS/VPS/Web hosting kıyaslarında da sık gördüğüm “gerçek performans” farklarını hedefler.

[ 1 ] Statik içerik teslimini CDN ile hızlandırın

LCP’nin en büyük nedeni çoğu sitede “büyük görsel ve statik dosyaların” geç gelmesidir. Origin performansı tek başına yeterli olmaz.

Uygulama: - Görselleri ve JS/CSS’i önbellek başlıkları (Cache-Control) ile doğru sürelerde servis edin. - Mümkünse CDN katmanı ekleyin; özellikle Türkiye kullanıcıları için uç konumlarda önbellek kritik olur.

Kontrol: - LCP görselinin yanıtı CDN’den geliyor mu? - CDN’den gelmiyorsa “cache miss” oranı yüksek mi?

[ 2 ] Sıkıştırmayı (Brotli/Gzip) ve HTTP sürümünü doğrulayın

• Brotli (Brotli, compression) destekliyse metin tabanlı içeriklerde indirme süresi düşer.
• HTTP/2 veya HTTP/3 doğru çalışmıyorsa ilk yükleme hızlanmaz.

Kontrol: - Response headers içinde content-encoding var mı? - HTTP/3/QUIC aktif mi değil mi (destekleyen istemcilerde) test edin.

[ 3 ] LCP öğesinin boyutunu ve ön yüklemeyi netleştirin

Hosting ayarı kadar HTML içeriği de önemlidir; fakat burada hostingin etkilediği kısmı hedefleyelim.

Uygulama: - LCP görseline width ve height verin (CLS’i doğrudan azaltır). - Kritik görsel veya font için preload kullanın. - Görsel formatını modernleştirin (ör. WebP/AVIF) ve doğru kalite ayarını uygulayın.

Not: “Sadece CDN koymak” her zaman CLS’i tek başına çözmez; boyutlandırma ve preload hâlâ gereklidir.

[ 4 ] Önbellek stratejisini Varyantlara göre kurun

CLS ve INP bazen “tutarsız içerik dağıtımı” yüzünden yükselir. Örneğin kullanıcı agent veya dil varyantları doğru ayrıştırılmıyorsa aynı URL farklı içerik döndürebilir.

Uygulama: - Vary: Accept-Encoding gibi varyantları doğru yönetin. - Dil (lang) ve cihaz (mobile/desktop) farklılıklarını deterministik yapın. - Cache sürelerini sadece “uzun olsun” diye değil, içerik güncelleme sıklığına göre belirleyin.

[ 5 ] INP için origin/API performansını ölçün ve kuyruklanmayı azaltın

INP’de yavaşlık çoğunlukla arka uç endpoint’lerinde olur. Hosting seçimi burada belirleyicidir.

Uygulama: - VDS/VPS’te uygulamayı ayağa kaldırdığınız süreçte CPU limit/timeout ayarlarını netleştirin. - Uygulama düzeyinde istek başına süreyi (p95/p99) takip edin. - Önbelleğe alınabilir endpoint’leri response caching ile hızlandırın.

Kontrol: - INP’i kötüleştiren etkileşime giden request’lerin p95/p99 değerleri kaç ms? - İşlem bekleme (queue) oluşuyor mu? (Node.js worker sayısı, PHP-FPM max children gibi)

[ 6 ] Yeterli kaynak planı yapın: “CPU/RAM sınırı” INP’yi bozar

Core Web Vitals laboratuvarda iyileşiyor gibi görünse bile gerçek trafik geldiğinde kaynak limitleri devreye girer.

Somut kural seti: - CPU’nun sürekli %80+ kullanımına çıktığı senaryolarda INP genellikle hızla kötüleşir. - Çok düşük RAM, GC (garbage collection) ve swap kaynaklı gecikmeleri artırır. - Disk I/O darboğazı log ve oturum işlemlerini uzatır; bu da etkileşimlerde gecikme üretir.

[ 7 ] Uygulama güncelleme ve cache temizliği davranışını tasarlayın

Yanlış cache temizliği (purge) CLS ve INP’de ani sıçramalar yaratabilir.

Uygulama: - Yeni sürüm devreye alınırken statik dosyaları versiyonlu (hashed filename) servis edin. - CDN/edge cache temizliğini hedefli yapın; tümünü her seferinde temizlemek genelde LCP’yi geçici olarak düşürür.

[ 8 ] TLS/HTTP keep-alive ve bağlantı limitlerini kontrol edin

Bağlantı yeniden kurulumu (handshake) arttıkça ilk yükleme ve bazen etkileşim gecikir.

Kontrol: - Keep-Alive açık mı? - Çok sayıda kısa bağlantı (connection churn) var mı? - Reverse proxy (Nginx/Apache) zaman aşımı ayarları makul mi?

Sonuç: Core Web Vitals’i hosting ile iyileştirmek için sırayı bozmadan ilerleyin

Aksiyon önerisi: Önce PageSpeed Insights ve DevTools ile LCP/CLS/INP’nin “hangi öğe” ve “hangi istek” kaynaklı olduğunu bulun. Ardından LCP için CDN + sıkıştırma + doğru ön yükleme; CLS için boyut/yerleşim deterministikliği; INP için p95/p99 endpoint süreleri ve CPU/RAM kuyruklanmasını düzeltin. En hızlı sonuç genellikle statik içerik teslimi ve istek yanıt süresinin birlikte iyileştirilmesiyle gelir—ölçüm-ayar-sınama döngüsünü her değişiklikte tekrarlayın.