Sayfa hızı; SEO görünürlüğü, dönüşüm oranı ve kullanıcı memnuniyeti üzerinde doğrudan etkili stratejik bir metriktir. Özellikle Core Web Vitals (LCP, INP, CLS) güncellemeleri sonrasında, barındırma (hosting) katmanındaki doğru ayarlar, uygulama/tema optimizasyonları kadar belirleyici hale gelmiştir. Aşağıdaki başlıklarda; sunucu, ağ ve yazılım konfigürasyonlarına odaklanan, ölçülebilir iyileştirmeler sağlayan kurumsal düzeyde öneriler bulacaksınız. Hedefimiz, TTFB’yi düşürmek, 95. persentil yanıt süresini iyileştirmek ve gerçek kullanıcı ölçümlerinde (RUM) kalıcı kazanımlar elde etmek.
Dinamik PHP tabanlı sitelerde (WordPress, WooCommerce vb.) TTFB’yi belirleyen ilk halka, PHP-FPM’in süreç yönetim stratejisidir. Varsayılan ayarlar genellikle genel kullanım içindir; oysa üretim (production) ortamında iş yükünüze uygun pm modu ve sınırlar seçilmelidir. pm = dynamic çoğu senaryoda güvenli ve esnektir; ancak yoğun trafiğin öngörülebilir olduğu kurumsal yapılarda pm = static ile sabit süreç sayısı belirlemek, soğuk başlatma gecikmelerini azaltır ve CPU bağlam değiştirme (context switch) maliyetlerini düşürür. pm.max_children, pm.start_servers, pm.min_spare_servers, pm.max_spare_servers değerleri, eşzamanlı istek ve bellek kullanımına göre test edilmelidir. Her FPM havuzu (pool) için request_terminate_timeout ile “asılı kalan” işlemler sınırlandırılmalı, rlimit_files ve rlimit_core gibi kaynak limitleri tanımlanmalıdır.
OPcache etkinleştirmek kritik bir kazançtır: opcache.enable=1, opcache.memory_consumption uygulama boyutunu kapsayacak şekilde artırılmalı, opcache.validate_timestamps üretimde düşük tutulmalı (CI/CD ile sürüm anında reset), opcache.max_accelerated_files dosya sayısına göre ayarlanmalıdır. realpath_cache_size ve realpath_cache_ttl değerlerinin yükseltilmesi, dosya sistemi aramalarını azaltır. PHP uzantıları gereksizse kapatılmalı, disable_functions ile saldırı yüzeyi daraltılmalıdır.
Yük dengeleme arkasında birden fazla PHP-FPM havuzu kullanılıyorsa, slowlog ile yavaş talepler izlenmeli; pm.status_path ve metrik toplayıcılarla (Prometheus/Agent) 95p/99p gecikmeleri dashboard’a taşınmalıdır. Ayrıca max_input_vars, memory_limit ve post_max_size gibi limitlerin iş akışına uygun, ancak abartısız düzeyde tutulması, aşırı bellek tüketimini engeller. Sonuç: Doğru yapılandırılmış bir PHP-FPM + OPcache kombinasyonu, tek başına TTFB’de yüzlerce milisaniye kazanç sağlayabilir ve yoğun saatlerde tutarlılığı korur—SEO için kritik olan “öngörülebilir hız” böyle yakalanır.
Ağ yığını, çoğu zaman uygulama kadar kazanç potansiyeli taşır. HTTP/2 ile çoklu istekler tek TCP bağlantısından akabilir; HTTP/3 (QUIC) ise UDP tabanlı yapısıyla paket kaybında daha dayanıklıdır. Her iki protokolün de etkin olması, tarayıcıların en iyi yolu kendiliğinden seçmesini sağlar. TLS 1.3, el sıkışma (handshake) tur sayısını azaltır ve modern şifre takımlarıyla daha hızlıdır; bu, özellikle ilk ziyaretçi temasında belirgin bir kazanımdır. OCSP stapling aktifleştirilmeli, sertifika zinciri (chain) düzgün kısaltılmalı ve HSTS ilkesi ile tutarlı HTTPS zorlaması yapılmalıdır.
Keep-Alive ayarları; NGINX/Apache/LiteSpeed üzerinde bağlantı başına taşıma maliyetini düşürür. keepalive_timeout çok uzun tutulmamalı; ama eşzamanlılık düzeyinize göre yeterli bir süre tanınmalıdır. Aşırı uzun timeout ve yüksek keepalive_requests değerleri, beklenmedik kaynak tüketimi doğurabilir—AB testi ile “tatlı nokta” saptanmalıdır. Brotli (özellikle metin tabanlı varlıklar için) Gzip’e göre daha iyi sıkıştırma sunar; brotli_static ile önceden sıkıştırılmış artefaktları sunmak CPU yükünü daha da azaltır.
Özel durumlarda 0-RTT (TLS early data) avantajlı olabilir; ancak idempotent olmayan isteklerde güvenlik açısından dikkat gerektirir. Sunucu tarafında TCP Fast Open (HTTP/2/3 ile farklılaşabilir) ve modern çekirdek ağ parametreleri (sndbuf, rcvbuf, wmem/rmem) testlerle ayarlanmalıdır. CDN veya WAF katmanı kullanıyorsanız, HTTP/2 push yerine tarayıcı yönetişimine (Preload, Early Hints 103) ağırlık verin; yanlış push politikaları bant genişliğini boşa harcar. Sonuç olarak; protokol modernizasyonu, doğru TLS ve Keep-Alive ayarlarıyla birleştiğinde, özellikle mobil ağlarda ve yüksek RTT’li coğrafyalarda hissedilir bir hızlanma sağlar.
CDN (Content Delivery Network), statik ve yarı dinamik içerikleri kullanıcıya yakın kenar noktalarından (POP) sunarak gecikmeyi düşürür. Ancak fayda, yalnızca “CDN açmakla” sınırlı değildir; cache key tasarımı, vary kuralları ve TTL stratejisi belirleyicidir. Örneğin cihaz tipine (mobil/desktop), dil parametresine veya ülkeye göre varyant üretmek gerekiyorsa, cache key bu sinyalleri kapsamalıdır. Aksi halde yanlış varyantlar, CLS ve LCP üzerinde olumsuz etki yaratır. Full-page cache (HTML) mümkün olduğunda, “anonim ziyaretçi” trafiğinde sunucu yükünü dramatik biçimde azaltır; dinamik kullanıcı oturumları için ise ESI (Edge Side Includes) veya hole-punching taktikleri değerlidir.
Stale-while-revalidate ve stale-if-error gibi direktifler, anlık arka uç sorunlarında dahi kullanıcıya hız ve süreklilik sağlar. Sürümleme (asset versioning) ile CSS/JS dosyaları için uzun TTL verip, dağıtım sonrası önbelleği kolayca geçersiz kılabilirsiniz. Görsellerde AVIF/WebP formatları ve responsive boyutlar, CDN’in image resizing yetenekleriyle birleştirildiğinde, ortalama sayfa ağırlığını büyük ölçüde küçültür.
Coğrafi hedeflemede, coğrafi yönlendirmeyi (geo-routing) abartmadan, en yakın POP’tan içerik sunumunu otomatikleştirmek gerekir; overly agresif yönlendirmeler SEO’da karışıklık yaratabilir. Origin shield kullanarak CDN → Origin isteklerini tek noktada kümelendirmek, arka uçtaki nakavt riskini düşürür. Son olarak CDN metriklerini (HIT oranı, 95p kenar gecikmesi, köken istek sayısı) düzenli izleyin; başarı, “HIT oranını kademeli yükseltmek” ve origin’i yalnızca zorunlu durumlarda çalıştırmakla gelir. Böylece LCP süreleri düşer, TTFB istikrarlı hale gelir ve tarama bütçesi (crawl budget) verimli kullanılır.
Dinamik uygulamalarda hızın en etkili kaldıraçlarından biri çok katmanlı önbelleklemedir. Object cache olarak Redis (çoğu durumda tercih) veya Memcached kullanmak, tekrarlayan veritabanı sorgularını RAM üzerinden milisaniye seviyesine indirir. Redis’te maxmemory-policy (ör. allkeys-lfu) ile akıllı tahliye politikaları uygulanmalı, persistence seçenekleri (AOF/RDB) iş yüküne göre değerlendirilmelidir. Connection pooling (PHP-FPM, Node.js vb.) ve reconnect stratejisi, yoğun saatlerde bağlantı fırtınalarını önler.
Tam sayfa önbellek (FPC), anonim trafikte HTML’i dahi cache’leyerek backend yükünü ciddi oranda düşürür. WooCommerce gibi sepet/oturum ağırlıklı yapılarda, kullanıcıya özel kısımlar ESI ile dinamik tutulurken geri kalan iskelet önbellekten sunulabilir. Sorgu tarafında, yavaş sorgu günlüğü (slow query log) aktif edilmeli; sıklıkla tetiklenen, tablo taraması yapan veya indeks kullanmayan sorgular optimize edilmelidir. EXPLAIN çıktılarıyla indeks stratejisi (BTREE/Hash), covering index ve composite index düzenleri gözden geçirilmelidir.
TTL değerlerini körlemesine uzatmak yerine, içerik değişim frekanslarına göre ayarlayın; gereksiz invalidation fırtınaları, gerçek hız kazanımlarını gölgeler. Önbellek ısınması (warm-up), dağıtım sonrasında kritik sayfaların otomatik taranmasıyla sağlanmalıdır. Ayrıca cache stampede (eşzamanlı miss) riskine karşı locking veya request coalescing mekanizmaları uygulayın. Doğru tasarlanmış bir önbellek mimarisi; aynı donanımda 2–10 kat daha fazla talebi düşük gecikmeyle karşılar, 95p yanıt süresini stabil tutar ve SEO’da sıralama dalgalanmalarını azaltır.
Sayfa ağırlığının büyük kısmı görsellerden gelir. AVIF ve WebP, geleneksel JPEG/PNG’ye göre kıyas kabul etmeyecek kadar daha iyi sıkıştırma sunar; kalite kaybı olmadan boyutları %30–70 oranında küçültmek mümkündür. Responsive görseller (srcset/sizes) ile tarayıcıya cihaz genişliğine uygun dosya seçimi yaptırmak kritik önemdedir. Lazy-loading (loading="lazy") üstte görünmeyen görseller için gecikmeli yükleme sağlar; ancak LCP öğesini yanlışlıkla ertelerseniz ters etki yaratabilirsiniz. Bu yüzden “kahraman görsel”i (hero) priority/preload ile erken getirip boyutlarını CSS’te sabitlemek (CLS önleme) doğru yaklaşımdır.
CSS/JS tarafında minify ve bundle işlemleri temel hijyendir; modern tarayıcıların HTTP/2 çoklu istek kabiliyetini düşünerek “tek dev dosya” yerine makul parçalara bölmek bazen daha verimlidir. Defer/async ile kritik olmayan JS’i ertelerken, critical CSS’i sayfaya gömmek ilk boyamayı hızlandırır. Yazı tiplerinde subset oluşturmak, font-display: swap kullanmak ve gerekirse preload ile ilk dokuyu öne almak, algılanan hızı artırır. İkon setleri için tek, optimize edilmiş bir font veya SVG sprite tercih edilmelidir.
CDN’in görsel dönüştürme olanakları (on-the-fly resize/crop) ve ETag/Last-Modified doğrulaması; istemci önbelleğini etkin kullanarak tekrar ziyarette trafiği düşürür. Ölçüm tarafında, LCP ve INP’ye odaklanın; görsel optimizasyonu yalnızca ağırlığı değil, boyutsal istikrarı (CLS) da hedeflemelidir. Doğru görsel stratejisi, hem mobil veri kullanımını düşürür hem de arama motorlarının hız sinyallerine olumlu katkı sağlar.
Arka uçtaki en büyük darboğazlar genellikle veritabanı ve disk I/O katmanında ortaya çıkar. Donanım düzeyinde NVMe SSD’ler, SATA SSD’lere kıyasla çok daha yüksek IOPS ve düşük gecikme sunar; RAID10 ile birlikte tutarlılık artar. MySQL/MariaDB tarafında InnoDB parametreleri kritiktir: innodb_buffer_pool_size aktif veri setinizin önemli kısmını kapsayacak şekilde ayarlanmalı, innodb_log_file_size ve innodb_flush_log_at_trx_commit değerleri iş yüküne göre optimize edilmelidir. Yazma ağırlıklı senaryolarda flush stratejileri büyük fark yaratır.
Connection pooling (örn. ProxySQL, pgbouncer benzeri yaklaşım), kısa ömürlü bağlantı fırtınalarını engeller ve CPU maliyetini düşürür. query_cache modern sürümlerde önerilmez; bunun yerine uygulama katmanı önbelleği ve doğru indeksleme tercih edilmelidir. Slow query log ve performance_schema ile en çok zaman alan sorguları izleyin; EXPLAIN ve ANALYZE çıktılarıyla tablo tasarımını gözden geçirin. Büyük tabloları partisyonlamak, sıcak/soğuk veri ayrımı yapmak ve uzun süreli kilitleri (lock) tespit etmek, 95p yanıt sürelerini istikrarlı hale getirir.
Dosya sistemi ve çekirdek katmanında, noatime gibi mount seçenekleri ve yeterli I/O scheduler seçimi (modern NVMe’lerde genellikle none) fayda sağlar. Yedekleme sırasında I/O dar boğazı yaratmamak için anlık görüntüler (snapshot) ve throttling uygulamak gerekir. Sonuç: Veritabanını ve I/O’yu bilinçli ayarlamak, “CPU ekleyerek hızlanma” yanılgısını kırar; aynı kaynakla çok daha fazla talebi düşük gecikmeyle karşılayabilirsiniz.
Brotli ve Gzip sıkıştırması; HTML, CSS, JS ve SVG gibi metin tabanlı varlıklarda dramatik kazanımlar sağlar. Brotli seviyesini körlemesine 11’e çekmek yerine, CPU bütçenize göre dengeli bir seviye seçin (çoğu üretimde 4–6 arası iyi bir başlangıçtır). Cache-Control, ETag, Last-Modified ve Vary başlıkları; istemci ve CDN tarafında önbelleğin verimli çalışmasının anahtarıdır. Sürümlenmiş varlıklar için immutable ve uzun max-age kullanabilir, HTML için daha kısa TTL + revalidate tercih edebilirsiniz.
Preload, Prefetch ve Preconnect ipuçları doğru kullanıldığında kritik kaynakların erken getirtilmesini sağlar; ancak aşırı preload, tarayıcı sıra yönetimini bozabilir. Service Worker ile akıllı çevrimdışı önbellek (offline cache) stratejileri, tekrar ziyaretlerde hissedilir hızlanma yaratır—özellikle içerik sitelerinde sayfa geçişleri neredeyse anlıkmış gibi algılanır.
Yanıt olarak 204/304 kodlarının doğru döndüğünden emin olun; gereksiz 200 OK tam yanıtları bant genişliği israfıdır. Görseller haricindeki medya (video) için adaptif bitrate ve modern kapsayıcılar (HLS/DASH) değerlendirilmelidir. Son olarak, sıkıştırma ve cache başlıkları değişimlerini A/B testine tabi tutun; bazı kullanıcı popülasyonlarında (eski tarayıcılar, kurumsal proxy’ler) farklı davranışlar gözlenebilir. Metriklere yansıyan kalıcı kazanımlar, SEO’daki istikrarı da beraberinde getirir.
Kalıcı hız, yalnızca “bir kerelik” optimizasyonla gelmez; izleme kültürü ister. Sunucu tarafında CPU steal, iowait, run queue, disk latency; uygulama tarafında 95p/99p yanıt süreleri, hata oranları; CDN tarafında HIT oranı ve kenar gecikmesi; tarayıcı tarafında RUM metrikleri (LCP, INP, CLS)—hepsi aynı pano üzerinde görünür olmalıdır. Uyarı eşikleri gerçekçi belirlenmeli; örneğin LCP 2.5 s sınırını aşan sayfa/cihaz/ülke kombinasyonları için otomatik iş emri açılmalıdır.
Sürüm yönetimi (CI/CD) ile performans gerilemelerini (regression) yakalamak, her dağıtımdan sonra canary trafiğiyle yeni sürümü küçük bir kitleye yönlendirmek ve RUM farklarını kıyaslamak, hızın “her zaman aynı” kalmasını sağlar. Load test (kademeli ve pik), synthetic monitoring (çok lokasyonlu) ve real-browser testleri birlikte kullanılmalıdır. Hız hedefleri OKR’lara bağlanmalı; örneğin “TTFB < 200 ms (TR), LCP < 1.8 s (mobil), 95p yanıt < 400 ms (kampanya)” gibi somut eşiikler konulmalıdır.
Gelişim döngüsünde, en büyük kazancı getiren düşük maliyetli işlerden başlayın (ör. cache HIT oranını %10 artırmak, kahraman görseli optimize etmek) ve etkiyi ölçün. Sonuçları pazarlama ve ürün ekipleriyle paylaşarak hızın gelir ve SEO’ya katkısını görünür kılın. Bu disiplin, arama sıralamalarındaki dalgalanmaları azaltır, reklam harcamalarının verimini artırır ve kullanıcı memnuniyetini kalıcı biçimde yükseltir.
Doğru hosting ayarları; protokol, önbellek, I/O, veritabanı ve görsel stratejilerinin birlikte ele alındığı bir bütünlük gerektirir. “Tek mucize ayar” yok; ancak yukarıdaki sekiz başlık, çoğu projede kısa sürede ölçülebilir hız kazanımları sağlar. TTFB ve LCP’nin düşmesi, SEO ve dönüşüm metriklerine doğrudan yansır. Kurumsal ölçekte başarı için bu ayarları izleme kültürüyle desteklemek ve her dağıtımda performansı doğrulamak şarttır.
Worldwide (English) 
