Core Web Vitals ve Hosting Altyapısı: TTFB, LCP ve CLS’yi Sunucu Tarafında İyileştirme Rehberi

Core Web Vitals artık sadece SEO tarafında bir puanlama metriği değil, doğrudan iş sonuçlarını etkileyen bir performans çerçevesi. Özellikle e-ticaret, SaaS veya içerik sitelerinde milisaniyelerin dönüşüm oranına nasıl yansıdığını her gün sahada görüyoruz. Planlama toplantılarında “Sunucuyu büyütsek mi, kodu mu optimize etsek, CDN’i mi agresifleştirsek?” soruları tam da bu yüzden masaya geliyor.

Bu yazıda konuyu sadece “ön yüzde birkaç optimize edelim” seviyesinde bırakmayacağız. Doğrudan hosting altyapısının ve sunucu tarafı ayarların, TTFB (Time to First Byte), LCP (Largest Contentful Paint) ve CLS (Cumulative Layout Shift) skorlarınıza nasıl yansıdığını adım adım konuşacağız. Hem teorik sınırlar (Google’ın eşikleri) hem de DCHost tarafında gerçek projelerde işe yarayan pratik ayarlardan bahsedeceğim.

Özellikle WordPress, WooCommerce, Laravel ve benzeri PHP tabanlı uygulamalar kullanıyorsanız; doğru yapılandırılmış bir web sunucusu, PHP-FPM, veritabanı ve önbellek katmanı ile Core Web Vitals skorlarınızı ciddi oranda yukarı çekebilirsiniz. Sunucu tarafında neleri değiştirmeniz gerektiğini, hangi metrikte hangi bileşenin rol oynadığını ve hangi sırayla ilerlemenin mantıklı olduğunu birlikte netleştirelim.

Core Web Vitals ve Hosting Altyapısı Arasındaki Doğrudan İlişki

Core Web Vitals üç ana metrikten oluşuyor:

• TTFB – İlk bayta kadar geçen süre (HTTP yanıtının başlatılması)
• LCP – Sayfadaki en büyük ana içeriğin yüklenme zamanı (genelde hero görseli, büyük başlık veya bölüm)
• CLS – Sayfa yüklenirken oluşan beklenmedik tasarım kaymalarının toplam skoru

Google’ın önerdiği sınırlar özetle şöyle:

• TTFB: Mümkünse < 0.8 sn (özellikle ana sayfa ve kritik landing sayfalarında)
• LCP: < 2.5 sn (iyi), 4 sn üzeri problemli
• CLS: < 0.1 (iyi), 0.25 üzeri kötü deneyim

Bu metriklerin bir kısmı doğrudan frontend ile ilgili (CSS/JS boyutu, görsel optimizasyonu vb.) görünse de, arka planda hosting altyapısının kalitesi ve konfigürasyonu belirleyici rol oynuyor. Örneğin:

• Zayıf CPU veya I/O yüzünden yavaş çalışan PHP/FPM, TTFB’yi yükselterek hem LCP’yi doğrudan, hem de dolaylı olarak CLS’yi etkiler.
• Yanlış yapılandırılmış önbellek, büyük hero görsellerini ve CSS dosyalarını her istekte diskten/uygulamadan okutur; bu da LCP’yi yukarı iter.
• Sunucu tarafında dinamik olarak üretilen HTML’in her sayfada farklı boyutlarda görsel yerleştirmesi, CLS puanının artmasına neden olabilir.

DCHost tarafında performans analizlerinde gördüğümüz ortak nokta şu: Sunucu tarafını düzeltmeden sadece frontendi optimize etmek çoğu zaman tavan yapmış skorları yeterince aşağı çekmiyor. O yüzden gelin önce TTFB’yi masaya yatıralım.

TTFB Nedir ve Sunucu Katmanında Nelerden Etkilenir?

TTFB, kullanıcının tarayıcısında adres çubuğuna yazılan URL’nin ilk byte’ının gelmesine kadar geçen süre. Yani:

1. DNS çözümü
2. TCP bağlantısı + TLS el sıkışması
3. Web sunucusunun isteği karşılaması (Nginx/Apache/LiteSpeed)
4. Uygulama motorunun çalışması (PHP-FPM, Node.js vb.)
5. Veritabanı veya cache sorguları
6. Cevabın oluşturulup ilk byte’ın gönderilmesi

Bu zincirin her halkası hosting altyapınız ile ilgilidir. TTFB yüksekse, LCP’nin iyi olması neredeyse imkansız hale gelir. Çünkü LCP, TTFB sonrasında yüklenmeye başlayan büyük içeriğe bakar.

DNS ve Ağ Gecikmesi

İyi yapılandırılmamış DNS, TTFB’nin ilk kısmını zaten zayıf başlatır. Çok bölgeli kullanıcılarda tek lokasyonda çalışan bir DNS sağlayıcısı veya yanlış TTL stratejisi fark edilir gecikmeye yol açabilir. Zero-downtime taşıma ve gecikme optimizasyonu için TTL stratejileri ve DNS yayılımını hızlandırma üzerine yazdığımız rehber bu noktada güzel bir tamamlayıcı.

Buna ek olarak, veri merkezinizin kullanıcılara fiziksel yakınlığı, omurga bağlantıları ve peering kalitesi de ham ağ gecikmesini belirler. Aynı uygulama kodu ve aynı veritabanı ile farklı veri merkezlerinde 40-50 ms’lik farklar görebiliyoruz.

Web Sunucusu (Nginx/Apache) ve PHP-FPM

PHP tabanlı sitelerde TTFB’nin belki de en kritik kısmı, web sunucusu ile PHP-FPM arasındaki iletişim ve FPM havuz ayarlarıdır. Yanlış yapılandırılmış FPM:

• Peak trafiklerde queue oluşturur, istekler bekler.
• Aşırı büyük havuz ayarları ile RAM’i tüketir, swap’e düşerek her isteği yavaşlatır.
• OPcache yanlış ayarlıysa aynı kodu tekrar tekrar yükler.

Bu konuyu detaylı ele aldığımız WordPress için sunucu tarafı optimizasyon rehberinde PHP-FPM, OPcache ve Redis ayarlarının gerçek dünya örnekleriyle TTFB’yi nasıl düşürdüğünü adım adım anlattık. Oradaki prensipler sadece WordPress için değil, çoğu PHP uygulaması için geçerli.

Veritabanı ve Nesne Önbelleği

TTFB’nin büyük kısmı çoğu zaman veritabanı sorgularında kaybolur. Özellikle WooCommerce gibi ağır sorgular üreten sistemlerde:

• Optimize edilmemiş indeksler
• Slow query’ler
• Yetersiz buffer pool ayarları
• Hiç olmayan veya yanlış yapılandırılmış Redis/Memcached

gibi etkenler, HTML’in oluşturulmasını saniyeler seviyesinde geciktirebilir. Bu noktada nesne önbelleği ile HTML’i değil ama sorgu sonuçlarını cache’lemek, TTFB üzerinde dramatik iyileşmeler sağlar.

MySQL/MariaDB tuning ve Redis konularını ayrı ayrı ele aldığımız rehberlerde, özellikle yüksek trafikli uygulamalarda nasıl yol izlediğimizi detaylandırdık. Örneğin WooCommerce için MySQL/InnoDB tuning kontrol listesi pratiğe çok hızlı dönebileceğiniz ayarlarla dolu.

HTTP/2, HTTP/3, TLS 1.3 ve Sıkıştırma

TTFB’yi yalnızca uygulama katmanı değil, protokol tarafı da etkiler. Modern bir hosting altyapısında:

• HTTP/2 veya HTTP/3 (QUIC) aktif olmalı
• TLS 1.3 desteklenmeli (daha hızlı handshake)
• Gzip/Brotli sıkıştırma doğru yapılandırılmalı

Nginx üzerinde TLS 1.3, OCSP Stapling ve Brotli yapılandırmasını adım adım gösterdiğimiz hızlı ve güvenli HTTPS rehberi, uygulama katmanına dokunmadan TTFB ve genel yanıt sürelerini düşürmede güzel bir başlangıç noktası.

TTFB’yi Sunucu Tarafında İyileştirmek İçin Somut Adımlar

TTFB’yi gerçekten aşağı çekmek istiyorsanız, sadece “RAM’i artırdık, bitti” yaklaşımı yetmez. Aşağıdaki yolu izlemek çok daha sağlıklı:

1. Profil Çıkarın: Nerede Zaman Kaybediyorsunuz?

Önce ölçüm:

• Chrome DevTools veya WebPageTest ile TTFB’yi ölçün.
• Sunucu tarafında access log’larda $request_time ve $upstream_response_time gibi alanları loglayın.
• Uygulama katmanında veritabanı sorgu sürelerini ve PHP yürütme süresini (örneğin Laravel Telescope veya WordPress query monitor eklentisi ile) analiz edin.

Böylece gecikmenin hangi katmanda (ağ, web sunucusu, PHP, veritabanı) yoğunlaştığını net görürsünüz.

2. Mikro Önbellekleme (Microcaching) Kullanın

Özellikle PHP tabanlı sitelerde Nginx ile 1–5 saniyelik tam sayfa önbellek, TTFB’yi milisaniyelere indirebilir. Bu kadar kısa süreli cache bile ani trafik dalgalanmalarında hem CPU’yu hem de gecikmeyi ciddi oranda azaltır.

Nginx ile microcache kurulumunu adım adım anlattığımız Nginx mikro önbellekleme rehberinde WordPress/Laravel gibi uygulamalarda hangi URL’lerin cache edilip hangilerinin bypass edilmesi gerektiğini detaylandırdık. Aynı prensip LCP ve CLS’yi de pozitif etkiliyor, çünkü HTML çok daha erken geliyor.

3. Nesne Önbelleğini Zorunlu Gibi Düşünün

WordPress, WooCommerce ve benzeri uygulamalarda Redis veya Memcached ile kalıcı nesne önbelleği kullanmak artık bir lüks değil, zorunluluk. Bu katman:

• Veritabanına giden sorgu sayısını ciddi oranda azaltır.
• TTFB’yi düşürürken, aynı zamanda yüksek trafik anlarında stabilite sağlar.

Bu konuyu WordPress ve WooCommerce için Redis mi Memcached mi? yazımızda karşılaştırmalı olarak anlattık. DCHost üzerindeki projelerde genellikle Redis + doğru TTL/eviction ayarları ile TTFB tarafında %30–60 arası kazanım görebiliyoruz.

4. NVMe Depolama ve I/O

Veritabanı veya dosya sistemi yoğun çalışan projelerde klasik SSD ile NVMe arasındaki fark, yalnızca sentetik benchmark’larda değil, gerçek TTFB değerlerinde de net hissediliyor. Özellikle:

• Yoğun log yazan uygulamalar
• Büyük ürün kataloglarına sahip e-ticaret siteleri
• Medya ağırlıklı içerik siteleri

NVMe I/O sayesinde sorgu yanıt sürelerini ve dosya okuma gecikmelerini ciddi şekilde azaltabiliyor. Bu farkı detaylı incelediğimiz NVMe VPS hosting rehberinde gerçek dünyadan örneklerle karşılaştırmalar bulabilirsiniz.

5. HTTP/2, HTTP/3 ve TLS Ayarlarını Güncelleyin

Sunucunuz hala sadece HTTP/1.1 ve eski TLS sürümleriyle hizmet veriyorsa, TTFB tarafında gereksiz bir başlangıç gecikmesi ekliyorsunuz demektir. Yapılması gerekenler:

• HTTP/2’yi (ve mümkünse HTTP/3’ü) aktif edin.
• TLS 1.3’ü destekleyin, zayıf şifre paketlerini kapatın.
• OCSP Stapling ile sertifika doğrulama gecikmelerini azaltın.

Bu ayarların hem hız hem güvenlik tarafında neler getirdiğini TLS 1.3 ve modern şifreler rehberinde detaylı olarak paylaştık.

LCP’yi (Largest Contentful Paint) Sunucu Tarafında Hızlandırmak

LCP genellikle “frontend meselesi” olarak görülse de, işin büyük kısmı yine sunucu tarafında başlıyor. Çünkü LCP’nin hesaplandığı an:

• HTML’in gelmiş ve parse edilmiş olması
• Gerekli CSS’in yüklenmiş olması
• Büyük görsel veya blok içeriğin isteklerinin yapılmış olması

gerekiyor. Bu zincirin her halkasında sunucunun rolü var.

HTML Teslim Süresi = LCP’nin Temeli

TTFB’yi düşürmek, LCP’yi iyileştirmenin zorunlu ilk adımı. Ancak sadece HTML’i hızlı teslim etmek yetmez. Sunucu tarafında şu başlıklara da dikkat etmek gerekiyor:

• Critical CSS’i inline veya erken yüklemek
• Özellikle hero görseli ve büyük bileşenleri barındıran CSS/JS dosyalarının HTTP/2 push veya preload ile erken çağrılması
• Görsellerin optimize edilmiş formatlarda (WebP/AVIF) ve doğru boyutta sunulması

Görsel Optimizasyonu ve CDN ile LCP’yi Düşürmek

LCP’nin çoğu zaman en kritik parçası büyük görsellerdir. Sunucu tarafında doğru yapılandırılmış bir görsel optimizasyon boru hattı ile:

• Yüksek çözünürlüklü kaynak görselleri orijinal formatında saklayıp
• İstemci cihazına ve tarayıcısına göre WebP/AVIF gibi modern formatlarda
• Doğru boyutta ve cache dostu şekilde

sunabilirsiniz. Bu mimariyi adım adım anlattığımız görüntü optimizasyonu boru hattı rehberi, LCP’yi aşağı çekmek isteyen projeler için birebir.

Ayrıca, WebP/AVIF sunarken SEO ve uyumluluk tarafında kırılma yaşamamak için WebP/AVIF’i kırmadan sunmak yazımızdaki Nginx/Apache kural örneklerine mutlaka göz atmanızı öneririz.

CDN Kullanımı ve Edge Önbellekleme

Özellikle küresel trafiği olan sitelerde LCP’yi düşük tutmanın en etkili yolundan biri, statik içerikleri CDN üzerinden sunmak. İyi yapılandırılmış bir CDN:

• CSS, JS ve görselleri kullanıcıya en yakın edge noktasından teslim eder.
• Hem TTFB’yi hem de LCP’yi ciddi oranda düşürür.

CDN’in temel çalışma mantığı ve avantajlarını CDN nedir ve avantajları nelerdir? yazımızda detaylandırdık. LCP odaklı bir kurulum yapmak için, özellikle cache-control başlıkları, varyantlar ve cache key tasarımı konularına dikkat etmek gerekiyor.

HTTP/2 Multiplexing ve Bağlantı Sayısı

HTTP/2 ve HTTP/3’ün sunduğu multiplexing sayesinde, aynı bağlantı üzerinden birden fazla isteği eşzamanlı yürütebiliyoruz. Bu da:

• CSS/JS/görsellerin daha hızlı ve verimli indirilmesini
• LCP’ye konu olan büyük bileşenin daha erken çizilmesini

sağlıyor. Sunucu tarafında yapılması gerekenler:

• HTTP/2 önceliklendirmesini (priority) doğru yapılandırmak
• Gereksiz sayıda alt domain ve bağlantı sayısını azaltmak
• Önemli kaynakları <link rel="preload"> ile işaretleyip tarayıcıya ipucu vermek

CLS (Cumulative Layout Shift) ve Sunucu Tarafının Rolü

CLS çoğunlukla frontend tarafına yazılan bir problem gibi görünür: yanlış img boyutları, sonradan yüklenen reklam alanları, font değişimleri vb. Ancak sunucu tarafı doğru kurgulanmadığında CLS’nin de arka planda bozulduğunu görüyoruz.

Dinamik İçerik ve Boyut Bilgisi

Özellikle CMS tabanlı sitelerde (WordPress, özel CMS’ler):

• Görsellerin width/height atributeleri sunucu tarafında HTML’e yazılmıyorsa
• Responsive img (srcset, sizes) mantığı sunucu tarafında yanlış uygulanıyorsa
• Reklam / widget alanlarının yüksekliği dinamik geliyor ama rezerv alan bırakılmıyorsa

CLS skoru hızla artar. Bunun çözümü:

• Görseller için sunucu tarafında sabit oranlı (aspect ratio) placeholder’lar üretmek
• Temada kullanılan bileşenler için minimum yükseklikleri HTML/CSS seviyesinde garanti altına almak
• SSR (server-side rendering) yapılan uygulamalarda, dinamik bileşenlerin boyut bilgisini backend’ten sağlamak

Önbellek Katmanları ve Tutarlı HTML

CLS bazen de tutarsız HTML’den kaynaklanır. Örneğin:

• Cache ısınmamışken gelen ilk ziyaretçiler farklı bir HTML yapısı görüyor
• Cache dolduktan sonra gelenler farklı varyasyonu görüyor
• Lazy-load veya A/B test script’leri her istekte farklı düzen üretiyor

Bu tür durumlarda, hem TTFB hem de CLS bozulur. Sunucu tarafında:

• Önbellek varyasyonlarını (cihaz, dil, kullanıcı oturumu) iyi tanımlamak
• A/B test veya deney script’lerini cache katmanlarıyla uyumlu kurgulamak
• İlk yüklemede mümkün olduğunca statik ve tutarlı bir HTML üretmek

CLS skorunu iyileştirmeye yardımcı olur.

Ölçüm, İzleme ve Sürekli İyileştirme

Core Web Vitals bir kere düzeltip bırakacağınız bir liste değil; trafik arttıkça, kod tabanı büyüdükçe, içerik ekipleri yeni görseller ekledikçe yeniden bozulabilen canlı metrikler. Bu yüzden hem frontend hem backend için sürekli ölçüm ve izleme kurmak şart.

Alan Verisi (Field Data) ve Laboratuvar Verisi (Lab Data)

Google Search Console ve CrUX ile gelen field data, gerçek kullanıcıların yaşadığı deneyimi özetler. Ancak değişikliği yaptıktan sonra etkisini görmek zaman alabilir. Bu yüzden:

• Field data ile uzun vadeli trendleri
• Lighthouse, WebPageTest ve tarayıcı DevTools ile lab datayı

beraber takip etmek en sağlıklısı. Sunucu tarafında yaptığınız bir FPM ayar değişikliğinin TTFB’ye etkisini anında görmek için access log’larınızı, uygulama log’larınızı ve sistem metriklerinizi birlikte izlemelisiniz.

Sunucu İzleme ve Alarm Mekanizmaları

CPU, RAM, I/O, network, disk doluluk ve process sayıları, Core Web Vitals skorlarınız için dolaylı ama çok belirleyici sinyaller. Örneğin:

• CPU saturasyonuna giren bir VPS, TTFB’yi fırlatır.
• Disk I/O kuyruğa girdiğinde, veritabanı sorguları uzar; LCP ve hatta CLS bozulur.

Bu yüzden VPS izleme ve alarm kurulumuna giriş veya daha ileri senaryolar için Prometheus, Grafana ve Node Exporter ile izleme rehberlerimizde anlattığımız gibi merkezi bir gözlemlenebilirlik sistemi kurmak çok değerli.

Deploy Süreçleri ve Performans Regresyonları

Yeni kod dağıtımlarında performans regresyonlarını erken fark etmek için:

• Staging ortamında Lighthouse ve WebPageTest ile otomatik raporlar üretin.
• Canlıya çıktıktan sonra ilk saatlerde TTFB ve LCP grafikleri için alarm eşikleri belirleyin.
• CI/CD pipeline’ınıza temel performans testlerini entegre edin.

DCHost üzerinde çalışan projelerde, özellikle yüksek trafikli sitelerde, Core Web Vitals regresyonları için ayrı alarm panelleri kurmayı alışkanlık haline getiriyoruz. Böylece sadece kesintiye değil, “yavaşlamaya” da proaktif tepki verebiliyoruz.

DCHost Altyapısında Core Web Vitals’e Yaklaşım

DCHost ekibi olarak, yeni bir proje migrate ederken veya mevcut müşterilerimizin altyapısını büyütürken, klasik CPU/RAM hesabı yapmaktan öteye geçiyoruz. Genelde şu soruları birlikte masaya yatırıyoruz:

• Mevcut TTFB, LCP ve CLS skorlarınız ne durumda?
• Bu skorların ne kadarı kod/tema kaynaklı, ne kadarı altyapı kaynaklı?
• Önbellek katmanınız (tam sayfa cache, nesne cache, CDN) ne kadar olgun?
• DNS, TLS, HTTP/2/3, NVMe gibi altyapı bileşenleri güncel mi?

Ardından sırayla:

1. TTFB odaklı PHP-FPM, OPcache, veritabanı ve microcache ayarlarını optimize ediyoruz.
2. LCP odaklı görsel optimizasyon, CDN ve HTTP/2/3 yapılandırmalarını gözden geçiriyoruz.
3. CLS için tema/mimari ekipleriyle birlikte sunucu tarafının sağlayabileceği boyut ve layout bilgilerini netleştiriyoruz.

Bu yaklaşım sayesinde, sadece “daha fazla kaynak verelim” yerine, aynı veya daha düşük maliyetle çok daha iyi Core Web Vitals skorları elde etmek mümkün oluyor.

Sonuç ve Yol Haritası: TTFB, LCP, CLS için Pratik Adım Planı

Core Web Vitals bugün hem SEO hem de kullanıcı deneyimi tarafında kritik bir çıpa. TTFB, LCP ve CLS’yi iyileştirmek istiyorsanız, işi sadece tema değiştirip birkaç eklenti kurmakla sınırlamamak gerekiyor. Hosting altyapınız, web sunucunuz, PHP-FPM ayarlarınız, veritabanınız, önbellek katmanlarınız ve CDN stratejiniz bu skorların ayrılmaz parçası.

Özet bir yol haritası çıkarmak gerekirse:

1. Mevcut CWV skorlarınızı ve TTFB/LCP/CLS kırılımlarını ölçün.
2. Access log, uygulama log ve veritabanı metrikleriyle nerede zaman kaybettiğinizi tespit edin.
3. Önce TTFB’yi hedef alın: PHP-FPM, veritabanı, microcache ve NVMe odaklı iyileştirmeleri uygulayın.
4. Sonra LCP için görsel optimizasyon, CDN ve HTTP/2/3 yapılandırmalarını elden geçirin.
5. CLS için HTML yapınızda ve sunucu tarafı üretilen layout bilgilerinde tutarlılık sağlayın.
6. Tüm bunları izleme, alarm ve düzenli gözden geçirme döngüsüyle sürekli hale getirin.

Eğer altyapınızı DCHost üzerinde çalıştırıyor veya taşımayı düşünüyorsanız, yukarıda anlattığımız ayarların büyük bölümü zaten günlük operasyonlarımızın parçası. Projenizin Core Web Vitals hedeflerine birlikte bakmak, darboğazları tespit etmek ve aşamalı bir iyileştirme planı çıkarmak için bizimle her zaman iletişime geçebilirsiniz. Doğru kurgulanmış bir hosting altyapısı ile milisaniyelerin bile nasıl dönüşüme dönüştüğünü görmek, işin en keyifli kısmı.