İlk Bayt Süresi (TTFB)

TTFB’nin WebPageTest’in bir sitede puan verdiği birkaç “sınıftan” biri olarak görünmesinin ve özellikle listedeki birinci sınıf olmasının bir nedeni var.

İlk bayt yavaşsa, diğer HER metrik de yavaş olacaktır. Bunu iyileştirmek, diğer tüm ölçümler üzerindeki etkisinin ne olacağını tahmin edebileceğiniz birkaç durumdan biridir. TTFB’deki her milisaniyelik iyileştirme, diğer tüm ölçümlerde doğrudan bir milisaniyelik tasarruf anlamına gelir (yani, TTFB 500 ms iyileşirse ilk boyama 500 ms daha hızlı olacaktır). Bununla birlikte, hızlı bir ttfb hızlı bir deneyimi garanti etmez, ancak yavaş bir ttfb yavaş bir deneyimi garanti eder. WebPageTest sonuçlarıyla ilgili tüm yardım taleplerinin kabaca %50’sinin yavaş bir TTFB ile mücadele eden site sahiplerinden geldiğini tahmin ediyorum.

Yönlendirmeler, DNS, bağlantı kurulumu, SSL anlaşması ve gerçek sunucu yanıt süresi dahil olmak üzere birçok şey TTFB’ye toplanabilir. Çoğu, Cloudflare gibi bir hizmet kullanılarak nispeten kolay bir şekilde çözülebilir, ancak HTML’nin kendisinin sunucu yanıt süresi genellikle en büyük sorun ve çözülmesi en zor olanıdır.

Aşağıdaki şelale şeması, sunucu yanıt süresini ilk istekte açık mavi bir çubuk olarak gösterir ve yavaş olduğunda acı verici bir şekilde açık olabilir. Optimal koşullar altında, sunucu yanıt süresi, hemen önündeki turuncu soket bağlantı çubuğundan daha uzun olmayacaktır.

Yavaş kaynak yanıt süreleri, sunucu yapılandırmasından, sistem yükünden, arka uç veritabanlarından ve konuştuğu sistemlerden uygulama kodunun kendisine kadar çok çeşitli sorunlardan kaynaklanabilir. Performans sorunlarının kökenine inmek, genellikle uygulamanın en yavaş kısımlarını izlemek ve iyileştirmek için Uygulama Performans Yönetimi araçlarıyla çalışan Dev Ops mühendislerinden oluşan ekipleri içerir.

Birlikte çalıştığım site sahiplerinin büyük bir kısmı, bu tür bir soruşturmayı yürütecek kaynaklara veya uzmanlığa sahip değil. Çoğu zaman, sitelerini oluşturmak için birine bir kerelik geliştirme ücreti ödediler veya WordPress’te kendileri oluşturdular ve bulabilecekleri en düşük maliyetli barındırmada barındırıyorlar. Barındırma, genellikle en yüksek performans için değil, mümkün olduğunca çok site çalıştırmak üzere tasarlanmıştır.

HTML Önbelleğe Alma

Mesele şu ki, çoğu HTML gerçekten dinamik değil. Site güncellendiğinde nispeten hızlı bir şekilde değişebilmesi gerekir, ancak web’in büyük bir kısmı için içerik aylar veya yıllar boyunca statiktir.

Bir kullanıcının oturum açtığı (yönetici veya başka bir şekilde) içeriğin farklı olması gerektiği ancak ziyaretlerin büyük çoğunluğunun anonim kullanıcılar olduğu gibi özel durumlar vardır. HTML önbelleğe alınabilir ve doğrudan uçtan sunulabilirse, performans kazanımları önemli olabilir (bu durumda tüm ölçümlerde 3 saniyeden daha hızlı).

İçeriği kaynağında önbelleğe almak için WordPress için düzinelerce eklenti vardır, ancak bunlar yapılandırma gerektirir (sayfaların önbelleğe alınacağı yer) ve performans yine de büyük ölçüde barındırma performansına bağlıdır. İçerik önbelleğini daha da ileriye taşımak karmaşıklığı azaltır, kaynağa geri dönmek için ek süreyi ortadan kaldırır ve barındırma performansını denklemden tamamen kaldırır. Ayrıca, tüm anonim trafiği boşaltarak barındırma sistemlerindeki yükü önemli ölçüde azaltabilir.

Cloudflare, statik HTML’yi önbelleğe almayı destekler ve ticari ve kurumsal müşteriler, “çerezlerde önbelleği atla” özelliğini etkinleştirerek oturum açmış kullanıcıların önbelleği atlamasını sağlayabilir. WordPress için Cloudflare eklentisi ile birlikte çalışır, böylece içerik her güncellendiğinde önbellek temizlenebilir. Ayrıca çeşitli CDN’lerle entegre olan birkaç başka önbelleğe alma eklentisi de vardır, ancak tüm durumlarda CDN için API anahtarlarıyla yapılandırılmaları gerekir ve uygulamalar her CDN için özeldir.

HTML’nin Sıfır Yapılandırmalı Önbelleğe Alınması

Geniş çapta benimsenmesi için, HTML’nin önbelleğe alınmasının otomatik olarak (veya mümkün olduğunca otomatik olarak gerçekleşmesine yakın) olmasını sağlamamız gerekir. Bu amaçla, açıkça temizlenebilen bir uzak önbelleği yönetmek için bir kaynak (bir WordPress sitesi gibi) ve bir uç önbellek (Cloudflare’in uç düğümleri gibi) arasında iletişim kurmanın bir yoluna ihtiyacımız var.

Origin’in şunları yapabilmesi gerekir:

• Önünde desteklenen bir uç önbellek olup olmadığını anlayın.
• Önbelleğe alınması gereken içeriği ve hangi ziyaretçiler için (yani oturum açma tanımlama bilgisi olmadan ziyaretler) belirtin.
• Önbelleğe alınmış içeriği değiştiğinde temizleyin (genel olarak tüm kenarlarda).

Değişiklikleri temizlemek için Origin’in bir API ile entegre olmasını ve neyin önbelleğe alınacağına ilişkin manuel yapılandırmayı gerektirmek yerine, kenarlar ve Origin arasında gidip gelen isteklerde HTTP başlıklarını kullanarak her şeyi başarabileceğimizde:

Mevcut bir uç önbelleğinin ve desteklediği yeteneklerin olduğunu bildirmek için uçtan kaynağa giden isteklere bir HTTP başlığı eklenir:

x-HTML-Edge-Cache: supports=cache|purgeall|bypass-cookies

Cloudflare ve TTFB (İlk Bayt Süresi)

Cloudflare, web sunucunuz ve internet arasında ters proxy gibi davranan, kötü niyetli botları engelleyen ve web sitesi hızını optimize eden popüler bir CDN hizmetidir. Hem büyük şirketler hem de bireysel web yöneticileri tarafından kullanılır ve kişisel kullanım için harika bir ücretsiz plan sunar.