Sunucu Loglarıyla Core Web Vitals İyileştirme Fırsatları

Core Web Vitals ve Sunucu Logları Neden Aynı Masaya Oturmalı?

Core Web Vitals skorlarını konuşurken çoğu ekip sadece Lighthouse raporlarına, PageSpeed Insights çıktısına veya tarayıcı tabanlı ölçümlere bakıyor. Oysa tabloyu tam görmek için bir ayağın da mutlaka sunucu tarafında, yani access log, error log, PHP-FPM ve veritabanı loglarında olması gerekiyor. Çünkü kullanıcı tarafında gördüğünüz LCP veya INP bozulmaları, çoğu zaman arkada TTFB dalgalanmaları, zaman zaman kilitlenen PHP süreçleri veya yavaşlayan veritabanı sorgularının sonucu.

DCHost tarafında özellikle yüksek trafikli WooCommerce, haber siteleri ve SaaS projelerinde şunu çok net görüyoruz: Sadece front-end optimizasyonlarıyla belli bir noktaya kadar ilerleniyor; asıl büyük sıçrama, sunucu loglarından okunan gerçek performans verilerini Core Web Vitals ile eşleştirdiğinizde geliyor. İyi tasarlanmış bir log formatı ve düzenli analizle; hangi endpoint’in LCP’yi şişirdiğini, hangi saat aralığında TTFB’nin arttığını, hangi ülke veya cihaz grubunun sürekli yavaşladığını çıplak gözle görebiliyorsunuz.

Bu yazıda tarayıcıdaki raporları tekrar etmeyeceğiz. Onların yerine, “Sunucu loglarından Core Web Vitals açısından hangi metrikleri çıkarmalıyım, hosting tarafında neleri mutlaka ölçmeliyim?” sorusuna odaklanacağız. Nginx/Apache access log’larından, PHP-FPM ve veritabanı loglarına kadar pratik örneklerle ilerleyip, sonunda elinizde uygulanabilir bir kontrol listesi olmasını hedefliyoruz.

Core Web Vitals’ın Sunucuya Dokunan Kısmı

Core Web Vitals üç ana metrikten oluşuyor: LCP (Largest Contentful Paint), INP (Interaction to Next Paint – FID’in yerini aldı) ve CLS (Cumulative Layout Shift). Bunların tamamı doğrudan sunucu loglarında görünmez; ancak özellikle ilk ikisini güçlü biçimde etkileyen sunucu tarafı sinyaller var.

• LCP: Büyük görsel veya metin bloğunun ekrana gelme süresi. Sunucu tarafında özellikle TTFB (Time To First Byte), HTML ve kritik asset (CSS, hero görseli) yanıt süreleriyle doğrudan bağlantılı.
• INP: Kullanıcının etkileşiminden sonra ilk görsel güncellenene kadar geçen süre. Back-end’deki yoğun CPU kullanımı, kilitlenen PHP süreçleri, yavaş AJAX endpoint’leri ve kuyruk işlemleri bu metriği yukarı çeker.
• CLS: Daha çok front-end/layout konusu. Ancak gecikmeli yüklenen görseller, geç gelen CSS/JS dosyaları da tetikleyici olabilir; bunların yanıt süreleri loglardan okunabilir.

Bu metriklerin hosting tarafıyla ilişkisini daha genel bir çerçevede görmek isterseniz, önce Core Web Vitals ve hosting altyapısı üzerine hazırladığımız rehbere göz atmanız faydalı olur. Burada ise konuyu daraltıp, özellikle log seviyesinde hangi alanlara bakmanız gerektiğini detaylandıracağız.

Sağlam Bir Log Altyapısı Kurmadan Core Web Vitals Okunmaz

Core Web Vitals için sunucu loglarından anlamlı veri çıkarmak istiyorsanız; önce log formatlarınızı gözden geçirmeniz gerekiyor. Varsayılan Nginx/Apache formatları çoğu zaman yeterli değil. Özellikle istek süresi, upstream süresi, cache durumu ve cevap boyutu gibi alanları kayda almazsanız, sonradan analiz kısmında eliniz bağlanır.

1. Access log mu, error log mu, yoksa uygulama log’u mu?

Önce rol dağılımını netleştirelim:

• Access log: Tüm HTTP isteklerinin “ne zaman, kimden, nereye, ne kadar sürede, kaç byte” geldiğini gösterir. Core Web Vitals’a en çok dokunan log burası.
• Error log: 4xx/5xx, time-out, backend bağlantı hataları gibi kritik sorunları yakalar. Fırlayan hatalar genellikle INP patlamaları ve bozulmuş kullanıcı deneyimi anlamına gelir.
• PHP-FPM ve uygulama log’ları: Yavaş PHP process’leri, exception’lar, uzun süren iş mantığı blokları. INP ve bazen LCP tarafında etkileri büyük.
• Veritabanı slow query log’ları: Özellikle WooCommerce, Laravel ve benzeri veri ağırlıklı uygulamalarda LCP’yi belirleyen ana bileşenlerden.

Bu yapıyı çok sunuculu ortamlara ölçeklemek, merkezi loglama ve saklama süreleri gibi konular için daha önce hazırladığımız VPS log yönetimi rehberine göz atabilirsiniz. Oradaki mimariyi Core Web Vitals bakışıyla zenginleştirmek çoğu projeye fazlasıyla yetiyor.

2. Nginx için örnek log_format (Core Web Vitals dostu)

Nginx tarafında aşağıya yakın bir log formatı ile çalışırsanız, LCP ve INP’ye etki eden kritik alanların çoğunu görebilirsiniz:

log_format cwv '
  $remote_addr - $remote_user [$time_local] "$request" '
  '$status $body_bytes_sent "$http_referer" "$http_user_agent" '
  'rt=$request_time urt=$upstream_response_time '
  'uaddr=$upstream_addr ucache=$upstream_cache_status '
  'scheme=$scheme proto=$server_protocol '
  'host=$host bytes=$body_bytes_sent';

access_log /var/log/nginx/access_cwv.log cwv;

• rt=$request_time: İstek toplam süresi (TCP handshake + TLS + bekleme + yanıtın tamamen inmesi).
• urt=$upstream_response_time: Sadece backend (PHP-FPM, Node, upstream) süresi. TTFB ve INP için altın değerinde.
• ucache=$upstream_cache_status: Önbellek – MISS/HIT/BYPASS gibi durumlar. Hem LCP hem maliyet tarafına işaret eder.
• proto=$server_protocol: HTTP/1.1 mi HTTP/2 mi; ileride HTTP/3 için de benzer alanlarla tutabilirsiniz.

3. Apache için extended log ayarları

Apache kullanıyorsanız LogFormat direktifini genişletip, özellikle %D (mikrosaniye cinsinden işlem süresi) ve %O (çıkan byte) alanlarını ekleyin. mod_status ve mod_log_config birlikte kullanıldığında, benzer analizleri Apache tarafında da yapmak mümkün.

Access ve error log’ları doğru okumaya yeni yeni başlıyorsanız, önce Apache ve Nginx sunucu loglarını okuma rehberimizi referans alıp, üzerine bu yazıdaki metrikleri eklemeniz iyi bir başlangıç olacaktır.

Core Web Vitals İçin Sunucu Tarafında Ölçmeniz Gereken 8 Kritik Metrik

1. TTFB ve Backend Süreleri (request_time & upstream_response_time)

LCP’yi doğrudan etkileyen ilk alan, HTML yanıtının TTFB dağılımı. Tarayıcı tarafında TTFB’yi görüyorsunuz; ama hangi path, hangi ülke, hangi cihaz TTFB’yi şişiriyor, onu ancak loglardan çıkarabilirsiniz.

• Yapılması gereken: Access log’larda $request_time ve $upstream_response_time alanlarını saklayın.
• Analiz: “/”, “/blog/”, “/urun/”, “/sepet” gibi path grupları için p50, p75, p90, p95 değerlerini hesaplayın.
• Yorum: HTML isteklerinde p75 seviyesinde 0.8 s üzeri TTFB görüyorsanız, LCP tarafında bozulma bekleyebilirsiniz.

Buradan çıkan tipik aksiyonlar:

• PHP-FPM havuz ayarlarını gözden geçirmek (özellikle pm.max_children ve pm.max_requests),
• Veritabanı slow query log’una inip kritik sorguları optimize etmek,
• Sık kullanılan sayfalar için tam sayfa önbellek (Nginx micro cache, LiteSpeed cache, Varnish, vb.) katmanı eklemek.

2. Ülke, IP Bloğu ve Cihaz Segmentine Göre Gecikme

Aynı sitede Türkiye içi ziyaretçiler için LCP gayet iyi seyrederken, Avrupa veya ABD trafiğinde LCP’nin patladığını çok sık görüyoruz. Bunun sebebi çoğu zaman uygulama değil, ağ gecikmesi (latency) ve rotalama.

• IP’den ülke bilgisi üreterek (GeoIP) access log’lara ekleyin.
• Mobil kullanıcıları User-Agent üzerinden ayrı segment olarak işaretleyin.
• Her segment için TTFB ve toplam istek süresi p75 değerlerini raporlayın.

Bu analiz, “aynı hosting mimarisiyle hangi lokasyonlara kadar kabul edilebilir Core Web Vitals sunabiliyorum” sorusuna çok net cevap verir. Eğer uzak bölgelerdeki kullanıcılarınızın oranı artıyorsa, GeoDNS, ek region veya agresif CDN stratejisi planlama zamanının geldiği anlamına gelir.

3. HTTP/1.1, HTTP/2 ve HTTP/3 Dağılımı

HTTP/2 ve HTTP/3, özellikle çok sayıda küçük CSS/JS/görsel isteği olan sitelerde LCP üzerinde ciddi fark yaratabiliyor. Access log’a kullanılan protokol versiyonunu ekleyerek şu soruyu cevaplayabilirsiniz:

• Kullanıcılarımın yüzde kaçı hala HTTP/1.1 üzerinden geliyor?
• HTTP/2/HTTP/3 üzerinde gelen isteklerin TTFB ve toplam süre dağılımı nasıl değişiyor?

Eğer HTTP/2 etkin olmasına rağmen loglarda hala ağırlıklı HTTP/1.1 görüyorsanız, arada bir reverse proxy, CDN veya yanlış TLS ayarı devreye girmiş olabilir. Bu durumda, protokol yükseltmelerinin Core Web Vitals tarafındaki etkilerini daha derinlemesine anlamak için Brotli ve gzip sıkıştırma ile Core Web Vitals optimizasyonu anlattığımız rehbere de göz atabilirsiniz; orada HTTP/2/3 ile birlikte değerlendirdiğimiz pratik örnekler var.

4. Önbellek (Cache) Etkinliği: HIT/MISS Oranları

Sunucu tarafında Core Web Vitals iyileştirmenin en ucuz yöntemi, doğru katmanda ve doğru TTL’lerle önbellek kullanmak. Bunun için loglara mutlaka cache durumunu eklemeniz gerekiyor:

• Nginx: $upstream_cache_status (HIT, MISS, BYPASS, EXPIRED…)
• CDN kullanıyorsanız: CF-Cache-Status, CDN-Cache-Status gibi başlıkları loglamak.

Sonra şu soruları cevaplayın:

• Statik asset’lerde (CSS, JS, görseller) MISS oranım neden yüksek?
• HTML yanıtlarında hangi path’ler için cache kullanabilirim, hangilerinde kullanamam?
• HIT istekleri ile MISS istekleri arasındaki request_time farkı ne kadar?

Çoğu projede sadece cache HIT oranını yüzde 10-20 artırmak bile, LCP tarafında göze görünür iyileşme ve aynı anda CPU/disk maliyetinde düşüş sağlıyor.

5. Cevap Boyutu ve Sıkıştırma

LCP’yi etkileyen bir diğer alan da, ilk HTML ve kritik CSS/JS dosyalarının byte boyutu. Access log’a $body_bytes_sent ekleyip; özellikle HTML, CSS ve ana JS bundle’ları için boyut dağılımına bakın.

• HTML yanıtları 200-300 KB sınırının üzerine çıkıyorsa, gereksiz inline script/HTML yorumları veya devasa JSON blokları olabilir.
• CSS/JS dosyaları sıkıştırma (gzip/Brotli) kapalı ya da yanlış ayarlı olabilir.
• Oturum açmış kullanıcılar için gönderilen HTML ile anonim kullanıcı HTML’leri arasında ciddi boyut farkları varsa, kişiselleştirme katmanını tekrar düşünmek gerekebilir.

Buradan çıkan aksiyon çoğu zaman şudur: Hem web sunucusu hem de CDN tarafında Brotli/gzip sıkıştırma ayarlarını gözden geçirmek, gereksiz başlıkları ve şişkin HTML bloklarını temizlemek. Bu konuyu adım adım ele aldığımız Brotli ve gzip rehberinde Nginx/Apache/LiteSpeed için hazır konfigürasyon örnekleri bulabilirsiniz.

6. 4xx/5xx Hataları ve Time-out Paternleri

Core Web Vitals skorlarını kötüleştiren şey sadece yavaş sayfalar değildir; tamamlanmayan veya hataya düşen istekler de kullanıcı deneyimini ve davranış metriklerini bozarak dolaylı yoldan sıralamaya yansır.

• Access log’da $status alanını izleyip, 4xx ve 5xx oranlarını path bazında raporlayın.
• Error log’da “upstream timed out”, “upstream sent too big header”, “connection reset” gibi hataların hangi endpoint’lerde yoğunlaştığını bulun.
• Bu hataların Core Web Vitals bozulması ile aynı zaman penceresinde artıp artmadığına bakın.

Özellikle e-ticaret sitelerinde, 4xx/5xx patlamaları genellikle sepet, ödeme ve filtreli kategori sayfalarında kendini gösterir. Bu alanların log analizi tarafını detaylı anlattığımız e-ticaret log analizi rehberini Core Web Vitals perspektifiyle birlikte okursanız, dönüşüm ve performansı aynı çerçevede değerlendirebilirsiniz.

7. PHP-FPM Slow Log ve Uygulama Katmanı

INP tarafında sık gördüğümüz senaryolardan biri şu: İlk sayfa yükü hızlı, ama kullanıcı tıkladığında (özellikle AJAX çağrılarında) yanıt bir anda 2-3 saniyeye fırlıyor. Tarayıcı bu etkileşim süresini INP olarak raporluyor; bizim tarafta ise bu genellikle belirli endpoint’lerin PHP-FPM veya framework seviyesinde yavaşlaması anlamına geliyor.

• PHP-FPM slowlog özelliğini aktif edin ve eşik değerini (ör. 500 ms) belirleyin.
• Slow log girişlerini, access log’tan ilgili isteklerle eşleştirin.
• Hangi fonksiyonlar, hangi veritabanı sorguları veya üçüncü parti API çağrılarının gecikmeye sebep olduğunu çıkarın.

Bu çalışma, özellikle “butona tıklayınca geç cevap veriyor” şikayetlerinin teknik karşılığını bulmanızı sağlar. INP’yi iyileştirmek çoğu zaman bu tip arka plan işlemlerini kuyruklara taşımak veya pahalı sorguları önbelleğe almakla çözülebiliyor.

8. Veritabanı Slow Query Log’u

MySQL/MariaDB/PostgreSQL tarafında slow query log’unu düzgün yapılandırmadan, Core Web Vitals bozulmalarının kaynağını bulmak zor. Çünkü pek çok sitede en büyük darboğaz CPU değil, indekslenmemiş veya kötü yazılmış sorgular.

• Threshold değerini gerçekçi ayarlayın (örneğin 200-300 ms).
• En çok çağrılan ve en çok zaman tüketen ilk 10 sorguyu çıkartın.
• Bu sorguların hit olduğu endpoint’leri access log’tan eşleştirip, ilgili sayfaların LCP/INP değerleriyle yan yana koyun.

Son adımda yapılacak indeksleme ve sorgu sadeleştirmeleri, özellikle kategori/arama sayfalarında LCP’yi saniyeler seviyesinden 1-1.5 saniyelere indirmek için çoğu zaman yeterli oluyor.

Segmentasyon: Hangi Kullanıcı Grubu Core Web Vitals’ı Batırıyor?

Log analizinde en kritik adımlardan biri, veriyi “ortalama” düzeyinden çıkarıp segmentlere bölmek. Çünkü çoğu projede sorun tüm kullanıcılarda değil; belli bir path, ülke, cihaz veya saat aralığında yoğunlaşıyor.

Segmentlemeniz gereken temel alanlar

• Path grupları: Ana sayfa, içerik sayfaları, ürün sayfaları, sepet/ödeme, arama sonuçları.
• Ülke/bölge: Türkiye, yakın coğrafya, uzak bölgeler.
• Cihaz tipi: Mobil, tablet, masaüstü (User-Agent üzerinden tespit).
• Oturum durumu: Giriş yapmış kullanıcılar vs anonim (login cookie’lerinden türetilebilir).
• Zaman dilimi: Özellikle kampanya saatleri ve yoğun trafik pencereleri.

Bu segmentler için ayrı ayrı:

• TTFB dağılımı (p50, p75, p90),
• Toplam istek süresi,
• 4xx/5xx oranı,
• Cache HIT/MISS oranı,
• Ortalama yanıt boyutu

gibi metrikleri çıkardığınızda, saha (CrUX) verilerindeki bozulmaları hangi segmentin sürüklediğini çok net görebilirsiniz. Örneğin sadece mobil, sadece /urun/ path’inde, sadece 19.00-22.00 arası bozuluyorsa; burada tarayıcı optimizasyonu değil, kaynak ölçekleme, önbellek ve veritabanı sorgu optimizasyonu konuşmak gerekir.

Gerçek Senaryolar: Loglardan Core Web Vitals Fırsatı Çıkarmak

Senaryo 1: WooCommerce’de Yüksek LCP, Suçlu Kategori Filtreleri

Bir WooCommerce mağazasında Core Web Vitals raporlarında özellikle kategori sayfalarında LCP sürekli kırmızı bölgedeydi. PageSpeed Insights raporları “render-blocking CSS/JS” gösteriyordu; fakat o taraf zaten optimize edilmişti. Access log ve veritabanı slow log’larını birleştirince şu tablo çıktı:

• /kategori/ altında çalışan filtreli sorgular, stok ve fiyat tablosuyla birlikte 1.5-2 saniyelik yavaş sorgular üretiyordu.
• Bu sorguların çalıştığı endpoint’lerin $upstream_response_time değeri p75 seviyesinde 1.8 s civarındaydı.
• İlgili sayfaların LCP p75 değeri saha verisinde 3.5-4 s aralığına çıkıyordu.

Basit birkaç indeks ekleme ve cache stratejisiyle backend süresi 400-500 ms civarına çekildi; birkaç gün sonra Core Web Vitals raporunda aynı sayfaların LCP’si 2 s civarına düştü. Burada kilit nokta, veritabanı log’u ile access log’un aynı grafikte buluşması oldu.

Senaryo 2: CDN Kullanılmasına Rağmen Yüksek TTFB

Başka bir projede CDN aktif olmasına rağmen; özellikle görsel ağırlıklı sayfalarda LCP tatmin edici değildi. Access log’a CDN cache başlıklarını ekleyip analiz yaptığımızda şunlar ortaya çıktı:

• Görsel isteklerinin önemli kısmı MISS olarak origin’e düşüyordu.
• Cache-Control ve Expires başlıkları tutarsızdı; bazı görsellerde “no-store” bile vardı.
• CDN’den gelen HIT isteklerin request_time değeri 100 ms civarında, MISS olanlar ise 600-700 ms seviyesindeydi.

Doğru cache başlıkları ve varyant stratejisiyle MISS oranı ciddi oranda aşağı indi; toplam istek süresi düşüşü doğrudan LCP grafiğine yansıdı. Tekrar vurgulamakta fayda var: Cache HIT/MISS bilgisini access log’a yazmıyorsanız, bu fırsatları görmeniz çok zor.

Senaryo 3: Sadece Kampanya Saatlerinde Bozulan INP

Bir kampanya döneminde, site normalde hızlıyken sadece akşam 20.00-23.00 arasındaki etkileşimlerde INP değerlerinin bozulduğu fark edildi. Log analizi şunu gösterdi:

• Bu saatlerde sepet ve kupon kontrolü yapan AJAX endpoint’lerine yoğun trafik yükleniyordu.
• PHP-FPM slow log’unda, kupon doğrulama fonksiyonları 1-1.5 saniyeye kadar çıkan işlem süreleriyle görüldü.
• Bu endpoint’lerin hit olduğu isteklerde $upstream_response_time p75 değeri 1.2 s civarındaydı.

Kupon kontrol mekanizması yeniden yazılıp bazı işlemler kuyruklara taşındığında; aynı kampanya bir sonraki hafta tekrarlandığında INP değerleri normal seviyelere döndü. Bu örnekte gördüğünüz gibi, INP sorunları çoğu zaman erişim değil, etkileşim loglarını okumayı gerektiriyor.

DCHost Ortamında Bu Ölçümleri Nasıl Kurabilirsiniz?

DCHost olarak sağladığımız paylaşımlı hosting, VPS, dedicated ve colocation ortamlarında müşterilerimizle en çok yaptığımız çalışmalardan biri, log ve izleme mimarisini Core Web Vitals hedefleriyle uyumlu hale getirmek. Pratikte tipik akış şöyle oluyor:

• Nginx/Apache access log formatı; request_time, upstream_response_time, cache durumu ve protokol bilgisiyle genişletiliyor.
• Loglar tek bir dosyada bırakılmak yerine, gerektiğinde Loki/ELK gibi merkezi bir sisteme veya en azından günlük bazlı rotasyona taşınıyor.
• PHP-FPM slow log ve veritabanı slow query log’ları aktif edilip, erişim loglarıyla eşleştirilebilir hale getiriliyor.
• Üzerine Prometheus/Grafana veya benzeri araçlarla basit fakat etkili dashboard’lar ekleniyor; p75/p90 grafiklerini path, ülke ve cihaz bazında görmek mümkün oluyor.

Bu mimarinin daha genel halini ve alarm kuralları, log saklama süreleri gibi ayrıntıları, VPS log yönetimi rehberimizde adım adım anlattık. Core Web Vitals açısından baktığınızda tek yapmanız gereken, oradaki genel metriği bu yazıda bahsettiğimiz TTFB, backend süresi, cache durumu, hata oranı ve boyut ölçümleriyle zenginleştirmek.

Adım Adım Yol Haritası: Sunucu Loglarından Core Web Vitals İyileştirmeye

1. Log formatlarını gözden geçir: Nginx/Apache access log’larına mutlaka süre, cache durumu, protokol ve byte bilgilerini ekleyin.
2. Segmentleri tanımla: Path grupları, ülke, cihaz tipi ve yoğun saatlere göre logları etiketleyin.
3. p75 odaklı analiz yap: Ortalama yerine p75/p90 değerlerine bakarak, Core Web Vitals raporlarıyla hizalayın.
4. Cache ve sıkıştırmayı kontrol et: HIT/MISS oranlarını, cevap boyutlarını ve sıkıştırma durumunu inceleyin.
5. Yavaş endpoint ve sorguları çıkar: PHP-FPM slow log ve veritabanı slow query log’unu access log ile eşleştirin.
6. Önceliklendirme yap: En çok trafik alan ve en kötü performans gösteren 5 endpoint’i seçip, önce bunlara odaklanın.
7. Değişiklik sonrası tekrar ölç: Yaptığınız her optimizasyondan sonra hem log metriklerini hem Core Web Vitals saha verilerini yeniden karşılaştırın.

Bu süreci rutin hale getirmek için, log analizini sadece sorun çıktığında yapılan bir “yangın söndürme” işi olmaktan çıkarıp, aylık veya çeyrek dönemlik performans gözden geçirme toplantılarının parçası haline getirmeyi öneriyoruz. Özellikle e-ticaret ve SaaS projelerinde, log bazlı bu yaklaşımı dönüşüm optimizasyonu ile birlikte ele aldığınızda, hem hız hem gelir tarafında çarpan etkisi yakalanıyor.

Sonuç: Core Web Vitals, Sadece Front-end Meselesi Değil

Core Web Vitals çoğu zaman tasarımcı ve front-end ekiplerinin omzuna bırakılıyor; ama pratikte iyi skorlar yakalamanın yolu, hosting altyapısı, sunucu konfigürasyonu ve log analizi ile yakından ilgilenmekten geçiyor. Sunucu loglarını doğru kurguladığınızda; TTFB dalgalanmalarını, cache eksikliklerini, yavaş PHP/DB işlemlerini ve belirli segmentlerde patlayan hata oranlarını çok net görebiliyor, bunları doğrudan LCP ve INP grafikleriyle ilişkilendirebiliyorsunuz.

DCHost tarafında pek çok projede gördüğümüz ortak nokta şu: Sadece birkaç güne yayılmış, odaklı bir log analizi çalışması bile; en az birkaç aylık front-end optimizasyon turuna bedel iyileştirme fırsatları çıkarabiliyor. Eğer siz de sitenizin Core Web Vitals skorlarıyla boğuşuyor ve problemin tam olarak nereden geldiğini kestiremiyorsanız, önce loglara bakmanızı tavsiye ederiz.

Yeni bir DCHost VPS, dedicated veya colocation ortamı kurarken log ve izleme mimarisini en başta doğru tasarlamak istiyorsanız, ekibimizle birlikte projenize özel bir log ve performans kontrol listesi üzerinden ilerleyebiliriz. Böylece, hem bugünkü Core Web Vitals skorlarını iyileştirir hem de büyüdükçe tekrar tekrar kullanılabilecek sağlam bir gözlemlenebilirlik (observability) temeli atmış olursunuz.