Core Web Vitals düşüşünde hosting tarafında hangi kayıtlar incelenir?

Core Web Vitals metriklerinde ani veya kademeli bir düşüş görüldüğünde ilk şüphe çoğu zaman tema, eklenti ya da ön yüz optimizasyonları olur. Ancak LCP, INP ve CLS gibi metrikler yalnızca tarayıcı tarafındaki dosyalardan etkilenmez; sunucu yanıt süresi, kaynak tüketimi, hata oranları ve ağ gecikmeleri de doğrudan performans algısını değiştirir. Bu nedenle sağlıklı bir analizde hosting tarafındaki kayıtlar da düzenli ve kanıta dayalı biçimde incelenmelidir.

Core Web Vitals düşüşünü sunucu tarafında okumak neden önemlidir?

Core Web Vitals verileri kullanıcı deneyimini ölçer; fakat düşüşün kaynağı her zaman sayfa içeriğinde görünmeyebilir. Örneğin Largest Contentful Paint değerinin bozulması, büyük bir görselden değil, sunucunun ilk HTML yanıtını geç üretmesinden kaynaklanabilir. Benzer şekilde Interaction to Next Paint değerindeki bozulma, yoğun bot trafiği nedeniyle CPU kaynaklarının tükenmesiyle ilişkili olabilir.

Bu noktada amaç tek bir log dosyasına bakıp hızlı hüküm vermek değil, zaman çizelgesi oluşturmaktır. PageSpeed Insights, Search Console, CDN paneli, uygulama logları ve sunucu kayıtları aynı tarih aralığında karşılaştırıldığında düşüşün nedeni çok daha net görünür.

İlk kontrol: erişim kayıtları

Erişim kayıtları, web sitesine gelen isteklerin zamanını, yanıt kodunu, kullanıcı aracısını, IP adresini, istenen URL’yi ve çoğu yapılandırmada yanıt süresini gösterir. Core Web Vitals düşüşünde özellikle yoğunlaşan URL’ler, olağan dışı bot davranışları ve yavaş yanıt veren sayfalar aranmalıdır.

Access log içinde nelere bakılır?

Öncelikle düşüşün başladığı tarih aralığında trafik artışı olup olmadığı kontrol edilir. Normal ziyaretçi artışı ile agresif bot taraması aynı şey değildir. Kısa sürede binlerce kategori, arama sonucu veya filtreli URL isteği varsa sunucu kaynakları gereksiz yere tüketiliyor olabilir.

İkinci olarak 200 yanıt kodu alan ancak yüksek süreyle dönen sayfalar incelenmelidir. 500 milisaniyenin altında beklenen bir sayfanın 2-3 saniyeye çıkması, LCP üzerinde ciddi etki oluşturabilir. Ayrıca 301/302 zincirleri de gereksiz gecikme yaratır; özellikle mobil kullanıcılar için her yönlendirme ek maliyet anlamına gelir.

Hata kayıtları: görünmeyen performans problemlerini yakalar

Error log dosyaları yalnızca sitenin tamamen bozulduğu durumlarda değil, kısmi performans kayıplarında da değerlidir. PHP uyarıları, bellek limitine yaklaşan işlemler, zaman aşımına uğrayan sorgular veya eksik dosya çağrıları sayfa yüklenmesini yavaşlatabilir.

Sık tekrarlayan PHP warning kayıtları bazen göz ardı edilir; fakat her istekte oluşan uyarı, disk yazımı ve işlem yükü doğurabilir. Fatal error kayıtları ise belirli sayfa tiplerinde kullanıcıya boş ekran ya da geç yanıt olarak dönebilir. Bu nedenle hata kaydında yalnızca kritik kelimesini aramak yeterli değildir; tekrar sıklığı ve hangi URL ile ilişkili olduğu birlikte değerlendirilmelidir.

Web sunucusu kayıtları: Nginx ve Apache tarafı

Nginx veya Apache kayıtları, isteğin sunucu katmanında nasıl karşılandığını anlamak için kullanılır. Burada özellikle upstream response time, request time, keep-alive davranışı ve 4xx/5xx oranları önemlidir. Eğer PHP-FPM ya da uygulama katmanı geç yanıt veriyorsa web sunucusu bunu çoğu zaman süre alanı üzerinden gösterir.

Apache kullanan yapılarda yoğun .htaccess kuralları veya karmaşık yönlendirme mantığı gecikmeye neden olabilir. Nginx tarafında ise yanlış cache bypass kuralları, statik dosyaların her seferinde uygulamaya yönlenmesine yol açabilir. Bu tür ayrıntılar ön yüzde görünmez, ancak kayıtlar üzerinden fark edilir.

PHP-FPM ve uygulama logları

WordPress gibi PHP tabanlı yapılarda PHP-FPM kayıtları çok kritiktir. Pool kapasitesi, max children sınırı, yavaş çalışan scriptler ve timeout olayları Core Web Vitals düşüşüyle doğrudan ilişkili olabilir. Özellikle yoğun saatlerde queue oluşuyorsa kullanıcı isteği beklemeye alınır ve ilk bayt süresi uzar.

Uygulama loglarında yavaş sorgu üreten eklentiler, cron görevleri, dış API beklemeleri ve cache temizleme döngüleri araştırılmalıdır. Bir eklenti yönetim panelinde sorunsuz görünebilir; ancak her sayfa görüntülemede harici servise bağlanıyorsa gerçek kullanıcı deneyimini zayıflatır.

Veritabanı kayıtları ve yavaş sorgular

MySQL veya MariaDB slow query log, performans analizinde çoğu zaman belirleyici olur. Ana sayfa, ürün listeleme, arama veya kategori sayfalarında uzun süren sorgular LCP değerini bozabilir. Burada yalnızca tek bir sorgunun süresi değil, aynı sorgunun dakikada kaç kez çalıştığı da önemlidir.

Yanlış indeksler, şişmiş postmeta tablosu, yoğun oturum kayıtları veya temizlenmeyen geçici veriler veritabanı yanıtını yavaşlatabilir. Bu nedenle sadece cache eklentisi kurmak kalıcı çözüm olmayabilir; sorgu kökenli sorun devam ediyorsa cache dışı kullanıcılar ve botlar aynı gecikmeyi yaşar.

Kaynak kullanımı ve sistem kayıtları

CPU, RAM, disk I/O ve inode kullanımı performansın altyapı ayağını gösterir. Sistem logları ile izleme paneli birlikte okunmalıdır. CPU kısa süreli yükseliyorsa bir cron görevi veya bot dalgası tetikleyici olabilir. Disk I/O sürekli yüksekse log yazımı, yedekleme, görsel işleme veya veritabanı işlemleri site yanıtını yavaşlatabilir.

Burada sık yapılan hata, yalnızca ortalama CPU değerine bakmaktır. Core Web Vitals kullanıcı bazlı ölçüldüğü için kısa süreli zirveler de önemlidir. Özellikle mobil kullanıcıların yoğun olduğu saatlerde yaşanan 10-15 dakikalık kaynak daralması saha verilerine yansıyabilir.

CDN, güvenlik duvarı ve cache kayıtları

CDN kullanılıyorsa cache hit oranı, bypass nedenleri, WAF engellemeleri ve origin response time değerleri incelenmelidir. Cache hit oranındaki düşüş, daha fazla isteğin origin sunucuya gitmesi anlamına gelir. Bu da hosting kaynaklarını zorlayarak TTFB ve LCP metriklerini olumsuz etkileyebilir.

Yanlış yapılandırılmış güvenlik kuralları da gerçek kullanıcıların bazı kaynaklara geç erişmesine neden olabilir. Özellikle CSS, JavaScript, font ve görsel dosyalarının 403, 404 veya gecikmeli yanıt üretip üretmediği kontrol edilmelidir.

Analizi doğru sıraya koymak

Pratik bir inceleme için önce düşüşün tarih ve saat aralığı belirlenir. Ardından access log ile trafik ve yanıt kodları, error log ile uygulama hataları, PHP-FPM kayıtları ile işlem kapasitesi, veritabanı slow query log ile sorgu yükü karşılaştırılır. Son aşamada CDN ve sistem kaynakları aynı tabloya eklenir.

Karar verirken tek bir metriğe bağlı kalmamak gerekir. LCP bozulması yavaş TTFB ile, INP bozulması yoğun işlem yüküyle, CLS ise çoğu zaman ön yüz düzeniyle ilişkilidir. Ancak sunucu tarafındaki gecikmeler ön yüz optimizasyonlarının etkisini sınırlayabilir. Bu yüzden kayıtları birlikte okumak, gereksiz eklenti değişiklikleri veya plansız paket yükseltmeleri yerine doğru müdahale alanını gösterir.

Düzenli log saklama, saat dilimi tutarlılığı ve olay anına ait kaynak grafikleri bu incelemenin güvenilirliğini artırır. Kayıtlar kısa süre içinde siliniyorsa veya farklı sistemler farklı saat dilimleri kullanıyorsa kök neden analizi zorlaşır; bu nedenle performans izleme süreci yalnızca sorun çıktığında değil, site yayındayken planlı biçimde kurgulanmalıdır.