TTFB Nedir? Önbellek, CDN ve Sunucu Yanıt Süresi SEO Etkisi

TTFB (Time to First Byte), bir sayfaya gitmeye başladığınız an ile sunucudan gelen yanıtın ilk baytının tarayıcıya ulaşması arasında geçen süredir. Sayfanın hiçbir görseli ya da yazısı bu ilk bayt gelmeden ekrana çıkamaz; bu yüzden sunucu yanıt süresi, sayfa hızının en baştaki halkasıdır. Peki bu süre SEO'yu gerçekten etkiler mi, etkiliyorsa hangi yoldan ve onu önbellek ile CDN ile nasıl kısaltırsınız?

Bu yazı yayıncılar ve geliştiriciler için yazıldı. TTFB'nin tanımını ve eşiklerini, nasıl ölçüleceğini, sunucu yanıtını oluşturan katmanları, Cache-Control yönergelerinin ne yaptığını, CDN'in neyi çözüp neyi çözmediğini, kişisel sayfaların neden paylaşılan önbelleğe girmemesi gerektiğini ve Google'ın tarayıcılarının önbelleğe nasıl baktığını sırayla ele alıyor. Görsel, JavaScript ve diğer Core Web Vitals ayrıntıları ayrı bir konudur ve ilgili bölümde yönlendirilir.

TTFB Nedir?

Tanım ve bileşenler

web.dev'in TTFB makalesi (yeni sekmede açılır), ölçümü gezinmenin başlamasıyla yanıtın ilk baytının gelmeye başlaması arasındaki süre olarak tanımlar. Bu süre tek bir sunucu işi değildir. Makaleye göre TTFB şu adımların toplamıdır: yönlendirme süresi, varsa service worker başlatma süresi, DNS çözümleme, bağlantı kurma ve TLS pazarlığı, ilk bayt gelene kadar istek.

Bu ayrım pratikte önemlidir. "Sunucum yavaş" şikayetinin ardında çoğu zaman bir zincir vardır: eski bir adrese giden gereksiz yönlendirme, uzak bir sunucuya kurulan bağlantı ya da uygulamanın veritabanı sorgularını beklemesi. Hangi halkanın uzadığını bilmeden yapılan "daha güçlü sunucu" kararı, sorunun başka yerde olduğu durumlarda sonuç vermez.

Eşikler: iyi, geliştirilmeli, zayıf

web.dev aynı makalede TTFB için yaklaşık bir rehber eşik verir: 0,8 saniye (800 ms) veya altı iyi, 1,8 saniyenin (1.800 ms) üzeri zayıf, ikisinin arası ise geliştirilmesi gereken aralıktır. Makale bu değerleri kesin bir kural değil, çoğu site için kaba bir kılavuz olarak sunar ve kullanıcıların 75. yüzdelik diliminin hedefe uyması gerektiğini belirtir. Yani tek bir ölçümde 700 ms görmek sorunun olmadığını göstermez; farklı konumlardaki gerçek kullanıcıların dağılımı belirleyicidir.

TTFB bir Core Web Vitals metriği değildir

Aynı makale TTFB'nin Core Web Vitals metriklerinden biri olmadığını açıkça söyler. Sitelerin iyi eşiği tutturmak zorunda olmadığını, yeter ki bu değer iyi puan almayı engellemesin, diye ekler. Ayrıca sunucuda üretilen (server-rendered) bir sitenin TTFB'sinin biraz yüksek olmasına rağmen FCP ve LCP değerlerinin daha iyi çıkabileceğini, düşük TTFB'nin en çok istemci tarafında oluşturulan uygulamalarda önem taşıdığını belirtir. Bu cümleler, TTFB'yi tek başına bir "puan" olarak kovalamanın yanlış olduğunu gösterir: TTFB bir tanı metriğidir, hedef değil.

TTFB SEO'yu Nasıl Etkiler?

Dolaylı yol 1: LCP ve diğer yükleme metrikleri

web.dev, TTFB'nin FCP ve LCP'den önce geldiğini söyler: sunucu yanıtı geciktiğinde, sayfayı gösterme sürecinin geri kalanı da bu gecikmenin üzerine biner. Bu nedenle yavaş bir sunucu yanıtı, LCP'yi iyileştirme çabalarının önüne geçebilir. Core Web Vitals, kullanıcı deneyiminin ölçüm çerçevesidir ve bu konuyu bütünüyle sayfa hızı ve Core Web Vitals rehberinde ele aldık; bu yazı o rehberin yalnız sunucu tarafı halkasına odaklanır.

Dolaylı yol 2: tarama kapasitesi

Google Search Central'ın büyük sitelerde tarama bütçesi yönetimi rehberi (yeni sekmede açılır), Google tarayıcılarının bir "tarama kapasitesi sınırı" kullandığını anlatır. Bu sınır, sunucunuzun Google için bağlantıları açık tutarak harcadığı toplam süreyi sınırlar. Her site aynı temkinli varsayılanla başlar; site tutarlı ve hızlı yanıt verdikçe sınır yükselir, yanıtlar yavaşladığında ya da sunucu hataları ve hız sınırlama sinyalleri (5xx ve 429 gibi) görüldüğünde düşer. Sayfa, taramayı hızlandırmak için sunucu yanıt sürelerini ve kaynakları optimize etmeyi önerir.

Aynı rehber, kapsadığı durumları da tarif eder: bir milyon veya daha fazla benzersiz sayfası olan ve haftalık değişen siteler ile on binden fazla sayfası olan ve günlük değişen siteler gibi örnekler verir; bu rakamları kaba tahmin olarak sunar. Yani çoğu küçük ve orta ölçekli site için tarama bütçesi birincil bir sorun olmayabilir. Konuyu geniş çerçevede tarama bütçesi optimizasyonu yazısında bulabilirsiniz.

TTFB ile sıralama ilişkisinin sınırı

Google ve web.dev belgeleri TTFB'yi doğrudan bir sıralama sinyali olarak tanımlamaz. İlişki iki dolaylı yoldan kurulur: yavaş sunucu yanıtı kullanıcıya görünen yükleme süresini uzatabilir ve Google'ın tarama kapasitesini sınırlayabilir. Aksi yöndeki yaygın inanışları Google belgeleriyle karşılaştırmak isterseniz SEO mitleri ve Google belgelerindeki gerçekler yazısı bu bakışla hazırlandı.

TTFB Nasıl Ölçülür?

Saha verisi ve laboratuvar verisi

web.dev, saha ölçümü için Chrome Kullanıcı Deneyimi Raporu'nu (CrUX) ve web-vitals JavaScript kitaplığını, laboratuvar ölçümü için Chrome DevTools'taki Network panelini ve WebPageTest'i sayar. Fark önemlidir. Laboratuvar ölçümü kontrollü bir ortamda tek bir istektir; saha ölçümü farklı ağlardaki, farklı konumlardaki gerçek ziyaretçileri yansıtır. Sunucu yakınındaki bir geliştirici bilgisayarında düşük görünen TTFB, uzaktaki ziyaretçiler için yüksek olabilir.

Tarayıcıda ölçüm

Makaleye göre sayfa gezintisinin TTFB'si, Navigation Timing API'sinde navigation girdisinin responseStart değerinden okunabilir. web-vitals kitaplığı bu değeri onTTFB işleviyle verir. Alt kaynakların TTFB'sini Resource Timing API'siyle ölçerken, farklı bir kaynaktan (cross-origin) gelen kaynaklarda saha ölçümü için sunucunun Timing-Allow-Origin başlığını göndermesi gerekir. Bu ayrıntı özellikle üçüncü taraf betikleri ve CDN üzerinden sunulan kaynakları izleyen geliştiriciler için önemlidir.

Ölçüm tuzakları

Üç tuzağı bilmek işinizi kolaylaştırır:

• 103 Early Hints yanıtı ilk bayt sayılır. Dolayısıyla erken ipuçları gönderen bir sunucuda TTFB düşük görünürken asıl HTML yanıtı geç gelebilir. web.dev, erken ipuçlarının yavaş bir arka ucu maskeleyebileceğini, bu yüzden gerçek sunucu süresinin de ölçülmesi gerektiğini söyler.
• Önbellekli ve önbelleksiz yanıtlar farklı sonuç verir. web.dev, teşhis için CDN'i ve diğer önbellek katmanlarını atlamanın bir yolunu bulundurmayı önerir; aksi hâlde sorunlu arka ucu görmeden yalnız önbelleğin hızını ölçersiniz.
• Tarayıcılar arasında ayrıntı farkı olabilir. web.dev, Chrome'un responseStart değerini bir dönem değiştirip sonra eski haline getirdiğini not eder; sürüm farkları ölçümleri etkileyebilir.

Sunucu zamanını görünür kılmak: Server-Timing

web.dev'in TTFB optimizasyonu makalesi (yeni sekmede açılır), arka uç adımlarını (veritabanı sorguları, sunucu tarafı oluşturma, disk erişimi, CDN önbellek isabeti ya da kaçırması) ölçmek için Server-Timing başlığını önerir. Bu başlıktaki bilgi tarayıcıdaki Navigation Timing API'siyle, Chrome DevTools'la ve Lighthouse'un belge isteği gecikmesi bulgusuyla okunabilir. Başlıkta hangi iç adımların açıklandığına dikkat edin: herkese açık yanıtlarda iç sistem ayrıntılarını gereksiz yere ifşa etmek yerine, yalnız ölçüm için gereken kısa adları kullanın.

Sunucu Yanıt Süresini Oluşturan Katmanlar

Hangi katman neyi etkiler?

Bir isteğin ilk bayta kadar geçtiği yolu katmanlara ayırmak, sorunu doğru yerde aramanızı sağlar. Aşağıdaki tablo, web.dev makalelerindeki bileşenlerden yola çıkarak katmanları ve her biri için ilk kontrolü özetler.

Hosting kararından önce sormanız gerekenler

web.dev, barındırıcının trafiğinizi kaldırıp kaldırmadığını kontrol etmeyi, ayrılan belleği gözden geçirmeyi, arka uç yığınını güncel tutmayı ve uzun TTFB sürerse barındırmayı yeniden değerlendirmeyi öneren genel bir çerçeve çizer. Bu yazıda belirli bir barındırma sağlayıcısı ya da fiyat önerisi yoktur; böyle bir seçimi kendi ölçümlerinize göre yapmanız gerekir. Önce önbellek ve yönlendirmeler gibi düşük maliyetli adımları tüketmek, çoğu durumda donanım kararını daha net hâle getirir.

Önbellek Katmanları ve Cache-Control

Özel önbellek, paylaşılan önbellek

MDN'in Cache-Control belgesi (yeni sekmede açılır) iki önbellek türünü ayırır. Özel (private) önbellek istemcide durur; tarayıcı önbelleği buna örnektir ve tek bir kullanıcıya ait kişiselleştirilmiş içeriği saklayabilir. Paylaşılan (shared) önbellek ise kaynak sunucu ile istemciler arasında durur (bir vekil sunucu ya da CDN gibi); tek bir yanıtı saklayıp birçok kullanıcıya yeniden sunar. Bu nedenle kişiselleştirilmiş içeriğin paylaşılan önbelleğe girmemesi gerekir. TTFB'yi düşürmeye çalışırken yapılan en pahalı hata, bu ayrımı atlayıp kişisel bir sayfayı herkese açık hâle getirmektir.

Başlıca yönergeler

MDN belgesinden, sunucu yanıtlarında sık kullanılan yönergelerin anlamları şöyledir:

• max-age=N: Yanıtın, kaynak sunucuda üretildikten sonra N saniye boyunca taze kalacağını söyler. Süre, yanıtın alınmasından değil üretilmesinden başlar; yanıt başka önbelleklerde geçirdiği süre Age başlığıyla düşülür.
• s-maxage=N: Yalnız paylaşılan önbellekler için tazelik süresini belirler; özel önbellekler bunu yok sayar. Paylaşılan önbellekte max-age ve Expires değerlerinin yerine geçer.
• no-cache: "Önbelleğe alma" anlamına gelmez. Yanıt saklanabilir ancak her yeniden kullanımdan önce kaynak sunucuyla doğrulanmalıdır.
• no-store: Hiçbir önbelleğin (özel ya da paylaşılan) yanıtı saklamamasını ister.
• public: Yanıtın paylaşılan önbellekte saklanabileceğini belirtir.
• private: Yanıtın yalnız özel önbellekte, örneğin tarayıcıda saklanabileceğini belirtir.
• must-revalidate: Yanıt tazeyken yeniden kullanılabilir; bayatladıktan sonra yeniden kullanılmadan önce kaynak sunucuyla doğrulanmalıdır. Genellikle max-age ile birlikte kullanılır.
• stale-while-revalidate=N: Bayat bir yanıtın, önbellek arka planda doğrularken N saniye boyunca yeniden kullanılmasına izin verir.
• immutable: Yanıtın tazeyken güncellenmeyeceğini söyler; sürümlü ya da özetli (hash) statik dosyalar için tasarlanmıştır.

Başlık değerlerini kendi sunucu yapılandırmanızda MDN belgesindeki yazım biçimiyle doğrulayın.

Sürümlü statik dosyalar: uzun süre güvenle önbelleğe alınır

web.dev'in HTTP önbellek makalesi (son güncelleme tarihi 2018-11-05, yani eski bir kaynak), içeriği asla değişmeyecek adresler için uzun ömürlü önbellek kullanmayı, içerik değiştiğinde ise dosya adını (ya da adresi) değiştirmeyi önerir. Makalenin örneğinde dosya adına bir parmak izi eklenir ve yanıt başlığında bir yıl civarı süre verilir. Bu yöntemin gücü şudur: dosya değiştiğinde adres de değiştiği için kullanıcı yeni dosyayı hemen alır, değişmediğinde ise hiç ağ isteği yapılmaz. Bu yaklaşım CSS, JavaScript ve görsel dosyaları için geçerlidir; HTML'de aynı mantığı uygulamak çoğu zaman mümkün değildir.

HTML ve sürümsüz adresler: doğrulama ile önbellek

Aynı makale, adresleri sabit kalan kaynaklarda yalnız HTTP önbelleğinin ağdan tamamen kaçınmaya yetmediğini söyler ve bu kaynaklar için her kullanımdan önce sunucuyla doğrulama yapan bir yaklaşım önerir. Doğrulama için sunucu bir ETag (çoğunlukla içeriğin özeti) döner; tarayıcı bir sonraki istekte bu değeri geri gönderir, içerik aynıysa sunucu 304 Not Modified yanıtı verir ve gövdeyi yeniden göndermez. Makale, ETag'i Last-Modified'a tercih eder ve nedenini daha doğru olması olarak açıklar. Bu davranış TTFB'yi sıfırlamaz: doğrulama isteği yine sunucuya gider, fakat yanıt gövdesi küçülür. Gerçek TTFB kazancı çoğu zaman sunucu ya da uç önbelleğinin hazır HTML'i kendi başına, uygulamayı çalıştırmadan döndürebilmesinden gelir.

CDN SEO İçin Ne Yapar, Ne Yapmaz?

Uç önbellek ve mesafe

web.dev'in CDN makalesine (son güncelleme 2023-12-05) göre CDN, içeriği kullanıcıya kaynak sunucudan daha yakın noktalardan sunan dağıtık bir sunucu ağıdır ve bu sayede gidiş geliş gecikmesini azaltır. Kullanıcıya yakın bu noktalara uç önbellek denir. Kaynak çekme (origin pull) modelinde bir kaynağa gelen ilk istek önbellekte bulunmaz; CDN kaynağı kaynak sunucudan alır, saklar ve sonraki isteklere oradan yanıt verir. Önbelleğe alınamayan içerikte bile CDN'in kullanıcıya yakın bağlantı sonlandırması ve kaynak sunucuyla hazır bağlantılar kullanması mümkündür.

Önbellek isabet oranı

Makale, önbellek isabet oranını (isabet sayısının toplam isteğe bölümü) bir ölçü olarak tanıtır ve çoğu site için yüzde 90'ı iyi bir hedef olarak adlandırır. Bu bir garanti ya da evrensel eşik değildir; kendi sitenizin isabet oranını önce ölçmeniz gerekir. Düşük oranın başlıca nedenleri genellikle kolay bulunur: aynı kaynağın sorgu parametreleriyle çok sayıda adrese bölünmesi, Vary başlığıyla önbellek girdilerinin çoğaltılması ve Set-Cookie içeren yanıtların genelde önbelleğe alınmaması.

Önbellek anahtarı, Vary ve çerezler

Makalede önbellek anahtarının temelinin adres olduğu, sorgu parametrelerinin bir kaynağı birden çok girdiye bölebileceği ve gereksiz parametrelerin yok sayılmasının ya da sıralanmasının yardımcı olduğu belirtilir. Vary başlığı, istek başlığı değerine göre ayrı önbellek girdileri oluşturur; Accept-Language gibi başlıkları normalleştirmek isabet oranını korur. Çok dilli bir sitede dil seçimini adres yolunda (ör. /tr/ ve /en/) tutmak, bu tür başlık tabanlı çoğaltmayı azaltır. Set-Cookie içeren yanıtların genelde önbelleğe alınmadığı da makalede geçer; bu yüzden herkese açık sayfalarda gereksiz çerez ayarlamaktan kaçının.

Süre (TTL) ve temizleme

Makale statik içerik (görseller, videolar, sürümlü kitaplıklar) için uzun bir TTL'i (altı ay ya da bir yıl gibi) örnekler. Dinamik içerikte ise yoğun trafikte birkaç saniyelik kısa bir önbelleğin taze kalma maliyetini az artırıp kaynak sunucu yükünü azaltabileceğini söyler. Uzun süre sakla, içerik değişince temizle yaklaşımını da (hold-till-told) tarif eder. Bu yaklaşımı kullanacaksanız yayın sürecinize bir temizleme adımı eklemelisiniz; aksi hâlde güncellediğiniz içerik eski haliyle sunulmaya devam eder.

CDN'in çözmediği şeyler

CDN, yavaş bir uygulamayı hızlandırmaz; yalnız aynı yanıtın tekrar tekrar üretilmesini engeller. Önbelleğe alınamayan, her kullanıcıya özel sayfalar için TTFB büyük ölçüde kaynak sunucunun hızına bağlı kalır. Ayrıca CDN'in kendisi bir yönlendirme zinciri, yanlış başlık ya da bozuk bir sertifika yaratabilir; bu da TTFB'yi iyileştirmek yerine bozabilir. Belirli bir CDN markasını bu yazıda önermiyoruz: seçim kriteri sizin trafik dağılımınız, bütçeniz ve bakım kapasitenizdir.

Kişisel Sayfaları Herkese Açık Önbelleğe Sokmamak

Neden kritik?

MDN belgesi, oturum açıldıktan sonra alınan ya da çerezle yönetilen oturumlara ait yanıtlarda private eklenmesini önerir ve uyarır: kişiselleştirilmiş bir yanıta private eklemeyi unutursanız o yanıt paylaşılan önbellekte saklanıp birden çok kullanıcıya yeniden sunulabilir; bu da kişisel bilginin sızmasına yol açabilir. Bu bir hız meselesinden öte güvenlik ve gizlilik meselesidir. web.dev'in CDN makalesi de kullanıcıya özel yanıtların private ile işaretlenmesi durumunda CDN tarafından önbelleğe alınmaması gerektiğini, no-store içeren yanıtların da dışarıda kaldığını belirtir.

Hızlı bir ayrım listesi

• Herkese aynı olan sayfalar: yayımlanmış makaleler, kategori sayfaları, herkese açık ürün ya da ilan sayfaları. Bunlar uç önbellek için adaydır.
• Kullanıcıya özel sayfalar: hesap, panel, sepet, sipariş, mesajlar, ödeme ve oturumla ilişkili her şey. Bunlar herkese açık önbelleğe girmemeli; kullanıcıya özel yanıtlara private, hiç saklanmaması gerekenlere no-store düşünülmelidir.
• Karma sayfalar: herkese açık sayfa gövdesi ve içinde kullanıcıya özel bir parça (ör. oturum açmış kullanıcı adı) bulunan sayfalar. Bu durumda kişisel parçayı ayrı bir istekle yüklemek ya da sayfayı tümüyle önbelleğe almamak gerekir.

Önbellek kuralını yayın öncesinde sınayın: oturum açıp oturumu kapattıktan sonra aynı adresin yanıt başlıklarını ve gövdesini inceleyin, başka bir tarayıcıdan farklı kullanıcı olarak da kontrol edin. Önbellek sorunu çoğu zaman yalnız yoğun trafikte ortaya çıkar; bu nedenle üretimde izlenebilir bir uyarı düzeni de kurun. Bir sayfa herkese açık önbelleğe girmemelidir ama arama motorlarının indekslemesi de gerekmiyorsa, bu ayrı bir konudur ve noindex ile erişim denetimi gibi başka mekanizmalarla çözülür.

Yönlendirmeler, HSTS ve Sunucu Tarafı İşler

Aynı kaynak yönlendirmeleri

web.dev, doğrudan kontrolünüzde olan aynı kaynak (same-origin) yönlendirmelerini ortadan kaldırmaya odaklanmayı önerir. Eksik https:// ya da tutarsız eğik çizgi gibi nedenlerle oluşan yönlendirmeleri düzeltmeyi, HSTS kullanmayı ve HTTP'den HTTPS'ye yönlendirmeyi kaldırmak için HSTS ön yüklemesini düşünmeyi ekler. Adres tutarlılığı hem kullanıcıya hem arama motoruna aynı yolu gösterdiği için hem TTFB hem de standartlaştırma açısından işe yarar.

Akış, erken ipuçları ve statik üretim

web.dev, sunucu tarafı oluşturmada yanıt akışını mümkün olduğunca erken başlatmayı, çalışma ortamınız destekliyorsa akışlı oluşturmayı kullanmayı ve kişiselleştirilmiş içerik bulunmayan sayfalarda statik oluşturmanın yardımcı olabileceğini söyler. 103 Early Hints ise tarayıcıya render için kritik kaynakları hemen indirmeye başlamasını bildirir ve sunucu tam yanıtı hazırlarken zaman kazandırır; yukarıda anlatıldığı gibi bu yöntem yavaş bir arka ucu maskeleyebileceği için gerçek sunucu süresi ayrıca ölçülmelidir.

JavaScript tabanlı sitelerde dikkat

İstemci tarafında oluşturulan sayfalarda sunucunun ilk yanıtı çoğu zaman boş bir kabuktur ve içerik sonradan yüklenir. web.dev, düşük TTFB'nin en çok bu tür uygulamalarda önem taşıdığını belirtir. Arama motoru açısından oluşturma ve indekslemenin bu yapıda nasıl işlediğini JavaScript SEO, oluşturma ve indeksleme yazısından okuyabilirsiniz.

Google'ın Tarayıcıları ve HTTP Önbelleği

Hangi başlıkları destekler?

Google'ın tarayıcılara genel bakış sayfası (yeni sekmede açılır) (son güncelleme 2026-06-12), Google'ın tarama altyapısının HTTP önbellek standardında tanımlandığı biçimiyle sezgisel (heuristic) HTTP önbelleğini desteklediğini söyler. Sayfa, ETag ile If-None-Match ve Last-Modified ile If-Modified-Since çiftlerini belirtir ve isteğe bağlı olarak max-age'in ayarlanabileceğini önerir. Aynı sayfada Google tarayıcıları için ETag'in Last-Modified yerine önerildiği, her ikisi de varsa ETag'in kullanıldığı ve tarih biçimi sorunlarını önlemek için ETag'in tercih edildiği anlatılır.

304 ve tarama verimi

Tarama bütçesi rehberi, değişmemiş sayfalar için 304 Not Modified yanıtlarını desteklemenizi, böylece Google'ın bu sayfaları kendi önbelleğinden kullanabilmesini ve bant genişliğinden tasarruf etmesini önerir. Rehber ETag ve If-Modified-Since'i adıyla anmaz; bu ayrıntı yukarıda anılan tarayıcılara genel bakış sayfasındadır. Yani önbellek hem kullanıcıya hem de tarayıcıya aynı yönde yardımcı olur: tekrar eden yanıtların gövdesi küçülür, sunucu iş yükü azalır.

Hataları izleyin

Sunucu hataları ve hız sınırlama yanıtları tarama kapasitesini düşürdüğüne göre, TTFB iyileştirmesinin yanında 5xx ve 429 yanıtlarını da izlemeniz gerekir. Bunun için sunucu kayıtlarından bot isteklerini inceleyebilirsiniz; yöntemi SEO için sunucu log analizi yazısında anlattık. Kayıtlar, hangi URL'lerin yavaş döndüğünü ve hangi saatlerde hata arttığını gösterdiği için ölçüm ve önbellek kararlarını somut veriye bağlamanıza yardım eder.

Adım Adım Sunucu Yanıt Süresi Denetimi

Sırayla yapılacaklar

Bir denetimi aşağıdaki sırayla yürütmek, rastgele ayar değiştirmekten daha az risklidir:

1. Önce temel çizgiyi çıkarın: CrUX ya da web-vitals ile saha TTFB değerini, DevTools ya da WebPageTest ile laboratuvar değerini kaydedin.
2. Önemli sayfa türlerini (ana sayfa, kategori, makale, ilan) ayrı ayrı ölçün; tek bir ortalama farklı sorunları gizler.
3. Yönlendirme zincirlerini bulun ve aynı kaynak yönlendirmelerini kısaltın.
4. Server-Timing ya da uygulama günlükleriyle sunucu işini adımlara bölün; veritabanı, oluşturma ve dış servis çağrılarını ayrı görün.
5. Statik dosyalar için sürümlü adres ve uzun ömürlü önbellek uygulayın.
6. Herkese açık HTML için uygun bir önbellek stratejisi belirleyin; kullanıcıya özel yanıtları kapsam dışı bırakın.
7. CDN kullanıyorsanız isabet oranını, önbellek anahtarını, Vary ve çerez davranışını denetleyin.
8. Önbelleği atlayarak çıplak kaynak sunucu süresini ölçün; sorun burada ise önbellek yalnız örtü işlevi görüyordur.
9. Değişikliklerden sonra aynı sayfaları aynı yöntemle yeniden ölçün ve karşılaştırın.

Değişiklikten sonra doğrulama

Saha verisi birkaç günde ve haftada oluştuğu için hemen sonuç beklemeyin. Hemen kontrol edebileceğiniz şeyler şunlardır: yanıt başlıkları beklediğiniz Cache-Control değerlerini taşıyor mu, oturum açmış bir kullanıcının sayfası başka bir tarayıcıda görünmüyor mu, yönlendirme zincirleri kısaldı mı ve 5xx oranı değişti mi? Bunlar, sonuç beklenirken yapılabilecek güvenli kontrollerdir.

Yayıncılar ve Geliştiriciler İçin Öncelik Rehberi

Kime hangi adım?

Reklam kullanan sayfalarda ek dikkat

Reklam içeren sayfalarda yavaşlığın kaynağı yalnız sunucu olmayabilir; reklam betikleri ve düzen kayması da hız ve kullanıcı deneyimini etkiler. Bu dengeyi reklam ve Core Web Vitals dengesi yazısında inceledik. Sunucu yanıtını sağlıklı tutmak bu dengenin yalnız ilk adımıdır; reklam alanının yerleşimi ve yükleme biçimi ayrıca değerlendirilmelidir.

Sık Yapılan Hatalar

Ölçüm hataları

İlk hata, yalnız tek bir laboratuvar ölçümüne bakmaktır; bu, dağılımı ve uzak konumlardaki kullanıcıları gizler. İkinci hata, önbellek açıkken ölçüp kaynak sunucunun gerçek hızını hiç görmemektir. Üçüncü hata, TTFB'yi tek başına bir hedef olarak ele almaktır; web.dev, TTFB'nin Core Web Vitals olmadığını ve önemli olan metrikleri engellemediği sürece sıkı bir eşik gerekmediğini belirtir.

Yapılandırma hataları

Sık görülen yapılandırma hataları şunlardır: kullanıcıya özel yanıtlarda private ya da no-store belirtmemek, HTML'i çok uzun süreyle önbellekte tutup temizleme düzeni kurmamak, sürümsüz dosya adlarına uzun ömür vermek (kullanıcılar eski dosyayı kullanmaya devam eder), her sayfada gereksiz çerez ayarlamak ve yönlendirme zincirlerini bırakmak. Bunların çoğu tek bir kontrol listesiyle yakalanabilir.

Beklenti hataları

"CDN kurdum, SEO sorunum çözülür" yaklaşımı yanlış bir beklentidir. CDN yalnız bir halkayı iyileştirir; içerik kalitesi, taranabilirlik ve ilgili bağlantılar ayrı işlerdir. Ayrıca hız iyileştirmesi karşılığında hızlı sıralama artışı vaat eden hizmetlere temkinli yaklaşın; Google ve web.dev belgeleri hız çalışmasının sıralama artışı getireceğini taahhüt etmez.

Sıkça Sorulan Sorular

TTFB nedir?

TTFB, bir sayfaya gitmeye başladığınız an ile sunucudan gelen yanıtın ilk baytının ulaştığı an arasındaki süredir. Yönlendirmeleri, DNS çözümlemeyi, bağlantı ve TLS kurulumunu ve sunucunun ilk bayt için harcadığı süreyi kapsar. Bir Core Web Vitals metriği değil, tanı amaçlı bir yükleme metriğidir.

İyi bir TTFB değeri kaç saniyedir?

web.dev'e göre 0,8 saniye veya altı iyi, 1,8 saniyenin üzeri zayıf kabul edilir; ikisinin arası geliştirilmesi gereken aralıktır. Bu değerler kaba bir kılavuzdur ve kullanıcıların 75. yüzdelik dilimi için aranır. Tek bir ölçüm yerine saha verisini izlemek gerekir.

TTFB Google sıralamasını etkiler mi?

Google ve web.dev belgeleri TTFB'yi doğrudan bir sıralama sinyali olarak tanımlamaz. Etki dolaylı yollardan beklenir: yavaş sunucu yanıtı LCP gibi yükleme metriklerini geciktirebilir ve Google'ın tarama kapasitesi sınırını düşürebilir. Sıralama garantisi verilemez.

CDN SEO'ya yardımcı olur mu?

CDN, içeriği kullanıcıya yakın noktalardan sunarak gecikmeyi ve kaynak sunucu yükünü azaltabilir; bu da TTFB ve yükleme sürelerine dolaylı olarak yardımcı olabilir. Ancak yavaş bir uygulamayı tek başına düzeltmez, kullanıcıya özel sayfaları önbelleğe almamalıdır ve sıralama sonucu vaat etmez.

no-cache ile no-store arasındaki fark nedir?

no-cache yanıtın saklanmasına izin verir ancak her yeniden kullanımdan önce kaynak sunucuyla doğrulanmasını ister. no-store ise hiçbir önbelleğin yanıtı saklamamasını ister. Kullanıcıya özel yanıtlarda private ya da no-store gerekip gerekmediğini yanıtın içeriğine göre değerlendirin.

Kullanıcıya özel sayfalar CDN'de önbelleğe alınabilir mi?

Alınmamalıdır. Kişiselleştirilmiş bir yanıt paylaşılan önbellekte saklanırsa başka kullanıcılara sunulabilir ve kişisel bilgi sızabilir. Bu tür yanıtlara private ya da gerektiğinde no-store verin, yayın öncesinde oturumlu ve oturumsuz isteklerle sınayın.

Google tarayıcıları HTTP önbelleğini kullanır mı?

Evet. Google belgelerine göre tarama altyapısı sezgisel HTTP önbelleğini destekler; ETag ile If-None-Match ve Last-Modified ile If-Modified-Since çiftleri desteklenir ve Google tarayıcıları için ETag önerilir. Değişmeyen sayfalar için 304 yanıtı vermek taramayı verimli kılar.

Sonuç ve Sonraki Adım

TTFB, sunucu yanıt süresinin ölçüsüdür ve bir Core Web Vitals metriği değildir; SEO'ya etkisi, yükleme metriklerini geciktirmesi ve tarama kapasitesini sınırlaması gibi dolaylı yollarla gelir. En sağlıklı sıra şudur: önce ölçün, sonra yönlendirmeleri ve sunucu işini inceleyin, ardından herkese açık içerik için önbellek ve gerekiyorsa CDN kurun, kullanıcıya özel yanıtları kesinlikle dışarıda bırakın ve her değişiklikten sonra yeniden ölçün.

Sayfalarınızda reklam gösteriyorsanız, "Reklam kullanan sayfalarda ek dikkat" bölümünde anlatıldığı gibi sunucu yanıtı dengenin yalnız ilk adımıdır; hızlı yanıt, reklamın gösterildiği ortamın da parçasıdır. Reklam alanı sunmayı düşünüyorsanız Akua Adforce'ta reklam alanları ilanlarını inceleyebilirsiniz. Her ilanın kapsamı ve koşulları ilgili ürün ve politika sayfalarında yazılıdır; Akua bir TTFB, önbellek ya da CDN düzenlemesinin sıralama veya trafik artışı sağlayacağını vaat etmez.