Core Web Vitals’ı Hosting Tarafında İyileştirmek

Core Web Vitals ve Hosting Tarafının Etkisi

Core Web Vitals artık sadece SEO uzmanlarının değil, sunucu yöneten herkesin gündeminde. Google, gerçek kullanıcı deneyimini ölçen bu metrikleri sıralama sinyali haline getirdiği için, yavaş açılan veya geç tepki veren bir site doğrudan organik trafiğini kaybedebiliyor. Üstelik sorunların önemli bir kısmı, tema veya JavaScript tarafında değil, doğrudan hosting ve sunucu ayarlarından kaynaklanıyor. DCHost tarafında yüzlerce projede gördüğümüz ortak tablo şu: TTFB, LCP ve INP değerlerini iyileştirmenin en kalıcı yolu, altyapı ve sunucu katmanını sistematik biçimde optimize etmek.

Bu yazıda geliştirici ekiple oturup kapasite planlarken, bir e-ticaret ya da içerik sitesinin Core Web Vitals hedeflerini netleştirip, bunlara ulaşmak için sunucu tarafında neleri değiştirmeniz gerektiğini adım adım anlatacağız. Önce hangi metriğin neyi ölçtüğünü özetleyeceğiz, ardından TTFB, LCP ve INP için doğrudan etkili olan hosting ayarlarını, pratik örneklerle ve uygulanabilir önerilerle detaylandıracağız. Eğer genel resmi görmek istiyorsanız, Core Web Vitals ve hosting altyapısı üzerine önceki rehberimizde kavramsal çerçeveyi anlattık; burada ise tamamen uygulamaya odaklanıyoruz.

Hangi Metrik Neyi Ölçüyor ve Sunucu Nerede Devreye Giriyor

Core Web Vitals tarafında bugün odaklanmamız gereken üç ana metrik var:

• TTFB (Time To First Byte): İlk bayta kadar geçen süre. Kullanıcının tarayıcısının sunucudan ilk cevabı alması ne kadar uzun sürerse, tüm deneyim zinciri o kadar gecikir. Resmi bir Core Web Vitals metriği değildir ama hepsinin temelini etkiler.
• LCP (Largest Contentful Paint): Ekranda görülen en büyük ana içeriğin (büyük görsel, hero metni, slider vb) ne kadar sürede yüklendiğini ölçer. Sayfa yükleme hissinin kalitesi için kritik.
• INP (Interaction to Next Paint): FID yerine gelen yeni etkileşim metriği. Kullanıcı bir butona tıkladığında, form göndermek istediğinde veya menü açtığında arayüzün tepki verip ekrandaki değişikliği göstermesine kadar geçen süreyi ölçer.

Bu üç metriğin ortak noktası, sunucunun ne kadar hızlı cevap üretip veriyi kullanıcıya ulaştırdığı. Tema, JavaScript ve görsel optimizasyonları elbette önemli; ancak TTFB yüksekse, veritabanı yavaşsa veya PHP-FPM kuyruğa boğulmuş durumdaysa, ön yüzde ne yaparsanız yapın kritik eşikleri yakalamak zorlaşıyor.

Dolayısıyla bu rehberi, geliştirici ve sistem yöneticisinin birlikte kullanacağı bir sunucu ayar kontrol listesi gibi düşünebilirsiniz: Hangi ayar TTFB’yi, hangisi LCP’yi, hangisi INP’yi etkiliyor; nereden başlamalı, neyi nasıl ölçmelisiniz, hepsini tek tek ele alalım.

TTFB’yi Düşürmek: Sunucu Cevabını Hızlandıran Ayarlar

1. Sunucu lokasyonu, ağ gecikmesi ve DNS

TTFB’nin ilk bileşeni, kullanıcının tarayıcısından veri merkezine gidiş geliş süresi. Bu da doğrudan sunucu lokasyonu, omurga kalitesi ve DNS çözümleme hızı ile ilgili. Hedef kitleniz Türkiye’deyse, sunucunun da Türkiye veya yakın bir bölgede olması milisaniye düzeyinde ciddi fark yaratır. Ayrıca iyi ayarlanmış bir DNS altyapısı, ilk çözümleme gecikmesini azaltır.

Bu konuyu daha stratejik açıdan düşünmek için, sunucu lokasyonu SEO’yu etkiler mi rehberimizde bölgesel seçimlerin performans ve arama görünürlüğüne etkilerini detaylıca ele aldık. Pratikte yapmanız gerekenler:

• Hedef ülkedeki kullanıcılar için onlara coğrafi olarak en yakın DCHost veri merkezi lokasyonunu seçmek.
• Premium bir DNS çözümü veya doğru yapılandırılmış DNS sağlayıcısıyla düşük gecikmeli çözümleme sağlamak.
• Gerekiyorsa GeoDNS ve çok bölgeli mimari ile farklı bölgelerdeki kullanıcılara en yakın sunucudan cevap vermek.

2. HTTP2, HTTP3 ve TLS el sıkışma süresini optimize etmek

TTFB’nin ikinci ayağı, HTTP ve TLS katmanındaki el sıkışmalar. Modern protokolleri kullanmak, hem bağlantı sayısını azaltır hem de eşzamanlı istekleri hızlandırır:

• HTTP2 ile tek TCP bağlantısı üzerinden çoklu istek gönderebilirsiniz.
• HTTP3 (QUIC) ile UDP tabanlı, daha hızlı kurulan ve paket kaybına dayanıklı bir bağlantı elde edersiniz.
• TLS 1.3 ile el sıkışma tur sayısı azalır; özellikle mobil ağlarda ciddi avantaj sağlar.

Altyapınızda bu protokolleri nasıl devreye alacağınızı, HTTP2 ve HTTP3 desteğinin Core Web Vitals üzerindeki etkileri başlıklı yazımızda teknik örneklerle anlattık. Özetle:

• Web sunucunuzda HTTP2’yi aktif edin, mümkünse HTTP3 desteğini de test ederek açın.
• TLS 1.2’yi minimum, TLS 1.3’ü tercih edilen protokol olarak konumlandırın.
• Gereksiz eski şifre paketlerini kapatarak el sıkışma süresini ve CPU yükünü azaltın.

3. PHP-FPM, OPcache ve uygulama katmanını hızlandırmak

Dinamik sitelerde TTFB’nin çoğu, PHP uygulamasının (WordPress, Laravel, özel yazılım vb) cevabı üretme süresinden gelir. Burada üç kritik bileşen var:

• PHP-FPM havuz ayarları (pm, pm.max_children, pm.max_requests)
• OPcache yapılandırması (bellek boyutu, validate_timestamps, revalidate_freq)
• Uygulama kodu ve sorgu optimizasyonu

WordPress, WooCommerce ve PHP tabanlı siteler için pratik örnekleri PHP OPcache ayar rehberimizde ve WordPress için sunucu tarafı optimizasyon rehberimizde detaylı paylaştık. Bu yazıda belirgin başlıkları özetleyelim:

• PHP-FPM havuzunda, eşzamanlı istek sayınızı ve RAM’inizi hesaba katarak yeterli sayıda child process tanımlayın.
• OPcache’i mutlaka aktif edin, bellek boyutunu kod tabanınızın büyüklüğüne göre ayarlayın.
• Gereksiz eklentileri temizleyin; ağır sorgular için veritabanı tarafında indeksleme yapın.

Eğer özellikle PHP tabanlı sitelerde ilk bayt süreniz ciddi derecede yüksekse, yüksek TTFB sorununu çözmek için hazırladığımız detaylı yazımız adım adım teşhis süreci sunuyor.

4. Veritabanı ve disk performansı

TTFB’nin bir diğer görünmez kahramanı, IO performansı. NVMe diskler, klasik SATA SSD ve HDD’lere göre çok daha yüksek IOPS ve düşük gecikme sunar. Özellikle sorgu yoğun e-ticaret sitelerinde, veritabanının NVMe üzerinde çalışması TTFB’yi hissedilir şekilde düşürür.

DCHost altyapısında NVMe VPS veya NVMe diskli dedicated sunucu tercih etmek, özellikle:

• WooCommerce benzeri büyük katalog sitelerinde,
• Yoğun okuma yazma yapan SaaS uygulamalarında,
• Ağır raporlama ve istatistik üreten panellerde

çok hızlı geri dönüş sağlar. Disk katmanlarının farklarını ve hangi senaryoda ne seçmeniz gerektiğini, NVMe, SATA SSD ve HDD karşılaştırması rehberimizde detaylı anlattık.

Veritabanı özelinde ise şu ayarlar TTFB’ye direkt etki eder:

• MySQL veya MariaDB’de buffer pool boyutunun RAM’e göre optimize edilmesi,
• Yavaş sorguların (slow query) tespit edilip indekslenmesi,
• Gereksiz verilerin (örneğin WordPress wp_options autoload şişmesi) temizlenmesi.

5. Önbellekleme ve sıkıştırma katmanı

TTFB’yi düşürmenin en etkili yollarından biri de, her istekte dinamik içerik üretmek yerine, önbellekten hazır cevap döndürmektir. Burada üç katmanı birlikte düşünmelisiniz:

• Sunucu tarafı tam sayfa önbellekleme (Nginx FastCGI cache, Varnish, LiteSpeed Cache vb)
• Tarayıcı önbelleği (Cache-Control, ETag, Expires başlıkları)
• CDN edge önbellekleri

Özellikle statik HTML’e yakın sayfalar için tam sayfa önbellek kullanmak, TTFB’yi milisaniyelere indirir. Bu konuda WordPress’te tam sayfa önbellekleme rehberimizde farklı web sunucularına göre örnek konfigürasyonlar paylaştık.

Önbelleğe alınan içeriklerin ağ üzerinden daha hızlı taşınması için de HTML, CSS, JS ve JSON yanıtlarında sıkıştırmayı doğru yapılandırmak gerekir. Brotli ve Gzip sıkıştırma ayarlarını doğru yapmak, hem TTFB hem de LCP açısından doğrudan kazanç sağlar.

Son olarak, tarayıcı ve CDN önbelleklemenin neden bu kadar kritik olduğuna dair rehberimizde anlattığımız gibi, cache header’larını doğru ayarlamak ve CDN ile uyumlu bir strateji kurmak, TTFB’yi tekrar eden ziyaretlerde dramatik biçimde aşağı çeker.

LCP’yi İyileştirmek: Büyük İçerik Öğesini Sunucu Tarafında Hızlandırmak

LCP, kullanıcının sayfanın gerçekten yüklendiğini hissettiği anı temsil eder. Bu genellikle hero görseli, büyük bir banner veya ana başlık bloğudur. Ön yüzde yapılacak görsel ve CSS optimizasyonlarına ek olarak, sunucu tarafında aşağıdaki ayarlar LCP’yi doğrudan etkiler.

1. Statik dosyalar için ayrı alan ve agresif önbellek

Büyük CSS, JS ve görselleri her istekte PHP üzerinden sunmak, LCP’yi doğrudan yukarı çeker. İdeal senaryo:

• CSS ve JS dosyalarının PHP’den bağımsız, doğrudan web sunucusundan veya CDN’den servis edilmesi,
• Uzun süreli Cache-Control header’ları ile bu dosyaların tarayıcı ve CDN cache’inde tutulması,
• Versiyonlama (örneğin style.css?v=123) ile içerik değiştiğinde yeniden indirilmesinin sağlanması.

Bu sayede kullanıcı sayfalar arasında gezinirken, büyük dosyaları tekrar tekrar indirmek zorunda kalmaz; LCP ciddi biçimde iyileşir.

2. Görselleri sunucu tarafında doğru format ve boyutta sunmak

LCP’yi en çok etkileyen unsurlardan biri, büyük hero görselleridir. Görsel optimizasyonu sadece tasarımcıya bırakılmamalı, hosting ve sunucu katmanında da sistematik hale getirilmelidir. Örneğin:

• Uygulama veya CDN tarafında WebP ve AVIF gibi modern formatlara otomatik dönüştürme,
• Cihaz genişliğine göre dinamik boyutlandırma (responsive images),
• Görüntülerin ayrı bir medya sunucusu veya object storage üzerinden sunulması.

Bu konuyu daha mimari düzeyde ele aldığımız görsel SEO ve hosting altyapısı rehberimizde, WebP AVIF dönüşümü ve CDN alt alan adları ile ilgili somut öneriler bulabilirsiniz. Büyük medya yükünü ana sunucudan uzaklaştırmak içinse, object storage ile medya offload stratejisi yazımız pratik bir yol haritası sunuyor.

3. CDN edge önbellekleri ve coğrafi yakınlık

LCP, sadece ilk HTML yanıtı değil, o HTML’in referans verdiği büyük görseller ve CSS’lerin de ne kadar hızlı geldiği ile ilgilidir. Bu yüzden özellikle uluslararası trafiği olan sitelerde, statik varlıkları CDN edge’lerinde önbelleğe almak büyük fark yaratır:

• Kullanıcıya en yakın edge noktasından görsel ve CSS sunulur,
• Sunucuya her seferinde tam istek gitmek zorunda kalmaz,
• Origin sunucunun yükü azalır, CPU ve disk IO başka işlemler için boş kalır.

DCHost ortamında CDN ile bütünleşik bir yapı kurguladığınızda, özellikle mobil kullanıcıların yaşadığı LCP dalgalanmaları ciddi biçimde azalır. CDN seçiminde cache politikaları, edge lokasyonları ve HTTP2/HTTP3 desteği gibi noktalar, ölçüm araçlarında göreceğiniz LCP değerlerine doğrudan yansır.

4. Sıkıştırma, önceliklendirme ve bağlantı yeniden kullanımını birleştirmek

Sunucu tarafında doğru yapılandırılmış bir Nginx, Apache veya LiteSpeed konfigürasyonu ile:

• CSS ve JS dosyalarını Brotli veya Gzip ile yüksek oranda sıkıştırabilir,
• HTTP2 ile bu dosyaları aynı bağlantı üzerinden paralel gönderebilir,
• Keep-Alive ayarları ile bağlantıyı yeniden kullanarak gecikmeyi azaltabilirsiniz.

Bu kombinasyon, LCP’yi özellikle düşük bant genişliğine sahip kullanıcılar için aşağı çeker. Eğer web sunucunuzun sıkıştırma ayarları konusunda emin değilseniz, Brotli Gzip ayar rehberimize göz atmanızı öneririz; orada paylaştığımız örnek konfigürasyonlar doğrudan LCP metriğine yansıyacak türdendir.

INP’yi Düşürmek: Etkileşim Sonrası Sunucu Tepkisini Hızlandırmak

INP, kullanıcının sayfa ile etkileşim kurduktan sonra ne kadar beklediğini ölçer. Özellikle:

• Filtreleme, arama, sepet güncelleme gibi AJAX çağrıları,
• Form gönderimleri ve ödeme adımları,
• Single Page Application yapılarında API istekleri

çoğunlukla arka planda sunucuya istek gönderir ve yanıt bekler. Bu yanıt geciktiğinde kullanıcı arayüzü takılıp kalmış hissi verir; yani INP yükselir. Sunucu tarafında INP’yi iyileştirmek için odaklanmanız gereken başlıklar:

1. API ve AJAX endpoint performansını ayrı izlemek

INP’yi düşürmek için sadece sayfa yükleme sürelerine bakmak yeterli değildir; özellikle API ve AJAX endpoint’lerinin yanıt sürelerini ayrı ayrı izlemek gerekir. Örneğin:

• /wp-admin/admin-ajax.php veya /api/* uç noktalarının ortalama ve p95 yanıt süreleri,
• Yoğun kullanılan filtreleme ve arama isteklerinin veritabanı yükü,
• Sepet ve ödeme adımlarında eşzamanlı çalışan işlemlerin sayısı.

Bu endpoint’lerde yavaşlama varsa, büyük ihtimalle:

• Veritabanı sorguları optimize edilmemiş,
• PHP-FPM havuzunuz yoğun anlarda kuyruğa düşüyor,
• Arka plan işleriniz (mail gönderimi, PDF üretimi vb) ön yüzde bloklayıcı şekilde çalışıyor

demektir. Bu tür senaryolarda PHP-FPM havuzunu ayırmak, yoğun API isteklerini farklı bir havuzda koşturmak veya Node.js tabanlı servisler için ayrı bir process yöneticisi (PM2, systemd) konfigürasyonu yapmak ciddi kazanç sağlayabilir.

2. Arka plan işleri ve kuyruk mimarisi

INP’yi iyileştirmenin en kritik yollarından biri, bloklayıcı işleri kuyruklara taşımaktır. Kullanıcının tıkladığı anda yapılması gerekmeyen işlemleri arka plana atarak ön yüzde yanıtı hızlıca döndürebilirsiniz. Örneğin:

• Onay e-postası göndermek,
• Rapor üretmek veya üçüncü parti API’lere veri göndermek,
• Ağır resim işleme veya PDF oluşturma süreçleri.

Bu tip işler için kuyruk sistemleri (Laravel Queue, RabbitMQ, Redis queue vb) kullanmak ve bunları ayrı PHP-FPM havuzları veya worker process’leri ile koşturmak, hem sunucunun CPU kullanımını daha dengeli hale getirir hem de kullanıcının bekleme süresini azaltır. Bu konuda detaylı bir mimari örneğe ihtiyaç duyuyorsanız, VPS üzerinde arka plan işleri ve kuyruk yönetimi rehberimiz iyi bir başlangıç noktasıdır.

3. Kaynak izolasyonu: PHP-FPM, veritabanı ve cache katmanı

INP tarafında sık gördüğümüz bir senaryo şöyle: Kampanya döneminde anasayfaya yüklenen trafik, aynı sunucudaki API ve admin isteklerini de boğuyor. Tüm işler aynı PHP-FPM havuzundan ve aynı veritabanı süreçlerinden geçtiği için, kullanıcı arayüzü tıklamalara geç tepki veriyor.

Bunu önlemek için:

• Ön yüz (frontend) ve API isteklerini mümkünse ayrı havuzlarda koşturmak,
• Yönetim paneli ve cron işler için ayrı bir PHP-FPM pool tanımlamak,
• Yoğun sitelerde veritabanını ayrı bir sunucuya taşıyıp, uygulama sunucusunu hafifletmek

etkili çözümler sunar. DCHost üzerinde VPS ve dedicated sunucu kombinasyonları ile bu izolasyonu kademeli olarak kurgulamak mümkün; önce tek güçlü VPS ile başlar, trafik arttıkça veritabanını ve cache katmanını ayrı sunuculara ayırabilirsiniz.

4. Cache katmanlarını akıllı kullanarak etkileşimleri hafifletmek

INP sadece ilk sayfa yüklemesi değil, sayfa içi etkileşimleri de kapsadığı için, arka plandaki OKU ağırlıklı istekleri cache ile hafifletmek çok değerlidir. Örneğin:

• Ürün filtreleme sonuçlarını kısa süreli (örneğin 30 sn) Nginx mikro önbelleğine almak,
• Yoğun okuma yapılan API cevaplarını Redis veya Memcached ile önbellekleme,
• Stok veya fiyat gibi çok sık değişmeyen verileri kısa TTL’lerle cache’lemek.

Bu yaklaşım, filtre ve arama gibi sık kullanılan etkileşimlerde veritabanı yükünü azaltır; böylece kullanıcı tıkladığında uygulama yeni bir sorgu yapmak yerine hazır cevabı döndürür. Sonuç: Daha düşük INP değerleri.

Ölçüm, Test ve Kademeli İyileştirme Süreci

TTFB, LCP ve INP’yi sadece teorik olarak konuşmak yeterli değil; ölçmeden iyileştiremezsiniz. DCHost olarak projelerde genelde şu adımlı yaklaşımı kullanıyoruz:

1. Mevcut durumu üç farklı araçla ölçmek (PageSpeed Insights, WebPageTest, Lighthouse).
2. Her metrik için en kötü sayfaları (örneğin en çok trafik alan ilk 10 URL) tespit etmek.
3. Sunucu logları ve APM araçları ile yavaş endpoint’leri ve sorguları bulmak.
4. Önce TTFB, sonra LCP, en son INP hedefleri için aksiyon planı çıkarmak.
5. Yapılan her değişiklikten sonra tekrar ölçüp farkı görmek.

Performans ölçümü tarafında nereden başlayacağınıza dair net bir yol haritasına ihtiyaç duyuyorsanız, web sitenizin hızını doğru ölçmek rehberimiz pratik bir giriş sunuyor. Ayrıca yüksek trafik beklediğiniz dönemlerden önce, load test ile kapasite ölçme rehberinde anlattığımız gibi, k6 JMeter veya Locust ile stres testi yapmak, Core Web Vitals değerlerinizin trafik arttığında nasıl davrandığını önceden görmenizi sağlar.

DCHost Altyapısında Core Web Vitals Odaklı Yapılandırma Önerileri

Şimdiye kadar anlattıklarımızı özetleyip DCHost bakış açısından pratik bir mimari öneri çıkaralım. Çoğu proje için izlediğimiz yol şu şekilde:

• Başlangıçta, yeterli vCPU ve RAM’e sahip bir NVMe VPS üzerinde uygulama, veritabanı ve cache katmanını aynı sunucuda ama mantıksal olarak izole ederek başlamak.
• PHP-FPM, OPcache ve veritabanı ayarlarını trafik ve kaynaklara göre optimize etmek; Redis veya Memcached ile nesne önbelleği kurmak.
• Nginx veya LiteSpeed üzerinde tam sayfa önbellekleme, Brotli Gzip sıkıştırma ve HTTP2/HTTP3 desteğini etkinleştirmek.
• Statik dosyalar ve görseller için CDN ve/veya object storage üzerinden offload stratejisi kurmak.
• Yoğun senaryolarda veritabanını ayrı bir DCHost VPS veya dedicated sunucuya taşıyarak uygulama sunucusunu hafifletmek.

Daha büyük ölçekli e-ticaret veya SaaS projelerinde ise ek olarak:

• Okuma ve yazma trafiğini ayıran veritabanı replikasyonu,
• GeoDNS ve çok bölgeli mimari ile farklı bölgelerdeki kullanıcılara en yakın sunucudan cevap vermek,
• Merkezi loglama ve izleme (Prometheus, Grafana, Loki vb) ile anlık metrik takibi

gibi adımlarla Core Web Vitals değerlerinin tutarlı kalmasını sağlıyoruz. DCHost’un sunduğu paylaşımlı hosting, VPS, dedicated ve colocation seçenekleri arasında doğru kombinasyonu seçmek için, mevcut trafiğiniz, büyüme planınız ve Core Web Vitals hedefleriniz üzerinden birlikte bir kapasite analizi yapmak en sağlıklı yaklaşım olacaktır.

Sonuç ve Yol Haritanızı Netleştirmek

Core Web Vitals iyileştirmesi, sadece tema değiştirmek veya bir iki eklenti kurmakla çözülen bir konu değil. TTFB, LCP ve INP metriklerini kalıcı olarak iyileştirmek istiyorsanız, hosting ve sunucu katmanını işin merkezine koymanız gerekiyor. Sunucu lokasyonundan HTTP2/HTTP3 ve TLS ayarlarına, PHP-FPM ve OPcache konfigürasyonundan veritabanı indekslerine, tam sayfa önbellekten CDN edge cache’lerine kadar her katmanda yapılacak küçük ama doğru dokunuşlar, toplamda büyük bir fark yaratıyor.

DCHost ekibi olarak, günlük operasyonlarımızda bu metriklerle birebir çalışıyoruz; bir sitenin neden yavaşladığını çoğu zaman önce sunucu loglarında ve performans grafiklerinde görüyoruz. Eğer siz de projeniz için Core Web Vitals hedefleri belirlemek, mevcut altyapınızın sınırlarını görmek veya yeni bir DCHost VPS ya da dedicated sunucu üzerinde en baştan doğru bir mimari kurmak istiyorsanız, teknik ekibimizle birlikte somut bir yol haritası çıkarabiliriz. Böylece SEO tarafında avantaj kazanırken, kullanıcılarınıza da tutarlı ve hızlı bir deneyim sunmuş olursunuz.