1. Sunucu Yanıt Süresi ve TTFB Nedir?
TTFB (Time To First Byte), tarayıcının isteği yaptıktan sonra sunucudan ilk byte’ı almasına kadar geçen süredir. Bu süre; sunucu kapasitesi, uygulama gecikmesi, veritabanı sorguları, cache hit oranı ve ağ gecikmesi gibi birçok faktörden etkilenir. Otel sitelerinde yüksek görsel yük, kampanya trafik artışı ve üçüncü taraf rezervasyon modülleri TTFB’yi dolaylı artırabilir. Bu yüzden TTFB, performans zincirinin “başlangıç düğümü”dür.
TTFB nedir, SEO’yu nasıl etkiler?
TTFB, sayfanın ilk tepki süresini gösterir. Yüksek TTFB; LCP’nin gecikmesine, kullanıcıların daha erken çıkmasına ve Google’ın sayfaları verimsiz taramasına neden olabilir. Düşük TTFB ise hem UX’i hem de teknik SEO stabilitesini destekler.
TTFB ölçümü (Lighthouse, WebPageTest)
- •Lighthouse/PSI: hızlı “lab” kontrolü
- •WebPageTest: daha detaylı waterfall ve lokasyon bazlı ölçüm
- •Varsayım: En doğru yaklaşım, lab + field (varsa RUM) birlikte okumaktır.
☑ Mini Check (TTFB teşhisi)
- •Mobilde TTFB yüksek mi, masaüstünde düşük mü?
- •Belirli saatlerde TTFB spike oluyor mu? (kampanya/yoğunluk)
- •HTML TTFB mi yüksek, yoksa statik asset’ler mi?
- •CDN var ama cache hit düşük mü?
Ne yapmalıyım? (SXO aksiyon listesi)
- • TTFB’yi tek ölçümle değil, farklı saat ve lokasyonla ölç.
- • HTML ve statik asset TTFB’yi ayrı değerlendir.
- • Spike varsa altyapı kapasitesi + cache hit oranını incele.
2. Hosting Seçiminin SEO’ya Etkisi
Hosting seçimi, TTFB’nin taban değerini belirler. Tek sunucu (monolith) yapı, maliyet olarak cazip olabilir ama kampanya dönemlerinde risk taşır. Bulut altyapı ise esneklik sağlar; doğru konfigüre edilmezse maliyet artabilir. Otel sitelerinde özellikle sezon açılışlarında ve kampanya günlerinde kapasite ihtiyacı değiştiği için “ölçeklenebilirlik” SEO ve dönüşüm için kritik hale gelir.
Sunucu lokasyonu sayfa hızını ve sıralamayı etkiler mi?
Sunucu lokasyonu, özellikle uzak pazarlarda ağ gecikmesini artırarak TTFB’yi etkileyebilir. Hedef pazarlar (ör. Türkiye + Avrupa) için doğru lokasyon ve CDN POP seçimi, mobil kullanıcıların ilk açılış süresini iyileştirebilir. Sıralamayı “tek başına” belirlemez ama hız/UX sinyallerini dolaylı etkiler.
Tek sunucu vs bulut altyapı (pratik)
- •Tek sunucu: basit, ama kapasite sınırı var
- •Bulut: ölçeklenebilir, ama cache ve ağ tasarımı şart
- •Varsayım: En iyi çözüm çoğu otelde “CDN + cache + ölçeklenebilir origin” kombinasyonudur.
☑ Mini Check (Hosting)
- •Kampanya günlerinde performans düşüyor mu?
- •CPU/RAM/disk I/O darboğazı var mı? (Varsayım: erişim varsa)
- •Hosting lokasyonu hedef pazara uygun mu?
- •TLS/HTTPS yapılandırması stabil mi?
Ne yapmalıyım? (SXO aksiyon listesi)
- • Kampanya dönemlerini “yük testi” olarak planla.
- • Ölçeklenebilirlik yoksa CDN + cache ile origin yükünü azalt.
- • Sunucu lokasyonu + CDN POP stratejisini hedef pazara göre kur.
3. Cache Katmanları (Uygulama, Sunucu, CDN)
Cache, TTFB’yi düşürmenin en etkili yollarından biridir çünkü pahalı işlemleri tekrar tekrar yapmaz. Otel sitelerinde cache üç katmanda ele alınır:
- Uygulama cache (sayfa/fragment)
- Sunucu/reverse proxy cache (örn. Nginx, Varnish)
- CDN/edge cache (kullanıcıya yakın)
Cache-control başlıkları nasıl ayarlanır?
Cache-control, hangi içeriğin ne kadar süre cache’te kalacağını tanımlar. HTML, CSS/JS ve görseller için aynı kuralı uygulamak yanlıştır; her içerik türü için ayrı strateji gerekir. Amaç, statik içerikte uzun cache, dinamik içerikte kontrollü cache ve doğru versiyonlama (fingerprint) ile hem güncellik hem hız sağlamaktır.
İçerik türüne göre cache yaklaşımı (otel)
- •Görsel/CSS/JS: uzun cache + fingerprint
- •HTML (liste/oda sayfası): kısa/orta cache + edge revalidate (kural setine bağlı)
- •Kampanya sayfaları: güncelleme dönemlerinde kontrollü cache + purge politikası
☑ Mini Check (Cache)
- •CDN cache hit oranı takip ediliyor mu?
- •HTML cache stratejisi var mı (edge/ISR/TTL)?
- •Kampanya görselleri güncellendiğinde cache kırılıyor mu?
- •Cache yanlış kurguyla “eski fiyat” gibi risk üretiyor mu?
Ne yapmalıyım? (SXO aksiyon listesi)
- • Asset’lerde uzun cache + versiyonlama standardını kilitle.
- • HTML için edge cache/ISR gibi kontrollü bir model seç.
- • Kampanya güncellemeleri için purge/versiyon prosedürü yaz.
4. HTTP/2–HTTP/3 ve Paralel Yüklemeler
HTTP/2 ve HTTP/3, bağlantı verimliliğini ve paralel yüklemeleri iyileştirerek sayfanın daha hızlı yüklenmesine katkı sağlar. Otel sitelerinde çok sayıda görsel ve asset olduğu için bağlantı verimliliği önemlidir. Ancak protokol yükseltmesi “tek başına” mucize değildir; cache ve CDN ile birlikte anlam kazanır.
☑ Mini Check (Protokoller)
- •HTTP/2 aktif mi?
- •HTTP/3 (QUIC) CDN üzerinden destekleniyor mu? (Varsayım: sağlayıcıya bağlı)
- •TLS el sıkışması gecikmeleri var mı?
- •Çok sayıda domain’e dağılan asset’ler bağlantı maliyeti yaratıyor mu?
Ne yapmalıyım? (SXO aksiyon listesi)
- • Önce cache/CDN ile TTFB’yi düşür, sonra protokol iyileştirmelerini ekle.
- • Asset domain sayısını kontrol et; gereksiz dağıtma.
- • CDN sağlayıcısında HTTP/3 desteğini planla (uyumlulukla).
5. Otel Sitelerinde Performans ve Güvenlik Dengesini Kurmak
Hız için yapılan her değişiklik güvenliği zayıflatmamalı; güvenlik katmanları da performansı gereksiz boğmamalı. CDN geçişleri, DNS değişimleri ve HTTPS sertifikaları bu dengenin merkezindedir. Özellikle ödeme/rezervasyon akışı olan sitelerde, “hızlandı ama güven uyarısı çıktı” gibi durumlar kabul edilemez.
Teknik not (sheet): DNS + HTTPS yönetimi
Sunucu değişimi veya CDN geçişlerinde DNS yönlendirmeleri, SSL sertifikaları ve HSTS gibi başlıklar doğru yönetilmelidir. Aksi halde kısa süreli erişim sorunları ve mixed content gibi problemler ortaya çıkabilir.
☑ Mini Check (Denge)
- •CDN geçişinde SSL doğru kuruldu mu?
- •DNS cutover planı var mı? (rollback dahil)
- •Güvenlik başlıkları (ör. HSTS) geçişten önce mi sonra mı?
- •Rezervasyon/ödeme akışı gerçek cihazda test edildi mi?
Ne yapmalıyım? (SXO aksiyon listesi)
- • CDN/hosting geçişini “SEO migrasyonu” gibi planla: test → cutover → izleme.
- • SSL ve DNS’i birlikte yönet; rollback planını yaz.
- • Release sonrası monitoring ile regresyonu erken yakala.
6. Fark Yaratan Mini Bölüm: Otel Projelerinde “Edge Cache + Next.js” Pratiği
Otel sitelerinde Next.js gibi modern stack’lerde hız kazanımı çoğu zaman “edge cache / ISR mantığı” ile gelir:
- •Oda sayfaları tamamen dinamik olmak zorunda değil; kontrollü yenileme ile cache’lenebilir
- •Liste sayfaları, filtre UX’ini bozmadan “cache-friendly” olabilir
- •CDN edge’de HTML cache, TTFB’yi dramatik düşürür
Bu yaklaşım, kampanya dönemlerinde origin yükünü azaltır ve mobil kullanıcı için ilk byte süresini iyileştirir.
7. İçerik Tablosu
Tablo seçimi: CDN öncesi/sonrası yanıt süreleri karşılaştırma tablosu (sheet önerisiyle uyumlu)
| Senaryo | TTFB durumu | Beklenen etki | Not |
|---|---|---|---|
| CDN yok, cache zayıf | Yüksek | Mobilde yavaş açılış | Origin yükü artar |
| CDN var, cache hit düşük | Orta/Yüksek | Dalgalı hız | Cache-control/versiyonlama eksik |
| CDN + doğru cache-control | Düşük | Stabil hız | Asset’ler uzun cache |
| Edge cache (HTML) + CDN | Daha düşük | LCP ve UX iyileşir | Kontrollü yenileme şart |
8. Sunucu Yanıt Süresi ve Cache Yapılandırma Checklist’ini İndir — SEO / TTFB
Sunucu Yanıt Süresi ve Cache Yapılandırma Checklist’ini İndir — SEO / TTFB (v1.0)
Bu asset, otel sitelerinde TTFB’yi düşürmek için hosting, cache-control ve CDN/edge katmanlarını sistematik biçimde iyileştirmeye yönelik bir checklist ve sprint planıdır. Amaç; HTML ve statik asset teslimatını hızlandırmak, kampanya dönemlerinde performansı stabil tutmak ve CWV/LCP üzerindeki altyapı etkisini azaltmaktır.
Kim Kullanır?
SEO + geliştirici/ops + ajans (altyapı ve performans optimizasyonunu birlikte yöneten ekip).
Nasıl Kullanılır?
- TTFB’yi farklı lokasyon ve saatlerde ölç; HTML ve asset’leri ayrı değerlendir.
- Cache katmanlarını (uygulama/sunucu/CDN) kontrol edip eksik kural setini tamamla.
- 14 günlük sprint planıyla uygulayıp öncesi/sonrası KPI ile doğrula; monitoring’e bağla.
Ölçüm & Önceliklendirme (Kısa sürüm)
- ▢ ✅ TTFB ölçümü alındı (Lighthouse + WebPageTest)
- ▢ ✅ Mobil/desktop ve farklı lokasyon ölçümü yapıldı
- ▢ ✅ HTML TTFB ve statik asset TTFB ayrıştırıldı
- ▢ ✅ CDN var/yok ve cache hit oranı kontrol edildi
- ▢ ✅ Cache-control başlıkları içerik türüne göre tanımlandı
- ▢ ✅ Görsel/CSS/JS fingerprint + uzun cache standardı var
- ▢ ✅ HTML için edge/TTL stratejisi belirlendi (kontrollü)
- ▢ ✅ Kampanya güncellemeleri için purge/versiyon prosedürü var
- ▢ ✅ HTTP/2 aktif, HTTP/3 planı değerlendirildi
- ▢ ✅ CDN/hosting geçişinde DNS + SSL planı hazır
- ▢ ✅ Release sonrası monitoring metrikleri tanımlandı
- ▢ ✅ 1-14 gün raporu
- ▢ ✅ TTFB ölçüm raporu (lokasyon/saat)
- ▢ ✅ Cache-control standard dokümanı
- ▢ ✅ CDN/edge cache konfig planı
- ▢ ✅ DNS+SSL cutover checklist
- ▢ ✅ Monitoring metrik seti + alarm eşikleri
PDF içinde: Problem→Kök Neden→Çözüm tablosu + 14 gün sprint planı + önce/sonra KPI tablosu
9. Kapanış: TTFB’yi Düşürmeden Hız ‘Tam’ Olmaz
Otel sitelerinde hız, sadece görsel optimizasyonu değil; sunucu yanıt süresi ve teslimat (delivery) mimarisidir. TTFB’yi ölçüp doğru hosting, cache katmanları ve CDN/edge yaklaşımıyla iyileştirirseniz; CWV metrikleri daha stabil olur, kampanya dönemlerinde performans korunur ve Google siteyi daha verimli tarar. En iyi sonuç, “ölç → optimize et → monitoring ile koru” döngüsüyle gelir.
Bir Sonraki Adım
Otel sitenizde TTFB kaynaklı yavaşlığı teşhis edip cache/CDN mimarisini iyileştirmek isteyen ekipler için.
Sık Sorulan Sorular
TTFB nedir, SEO’yu nasıl etkiler?▾
Otel sitem için CDN kullanmalı mıyım?▾
Cache-control başlıkları nasıl ayarlanır?▾
Sunucu lokasyonu sayfa hızını ve sıralamayı etkiler mi?▾
Tek sunucu mu bulut altyapı mı daha iyi?▾
CDN geçişinde en büyük risk nedir?▾
İlgili İçerikler