Time to First Bayte metriği için nasıl optimizasyon yapacağınızı öğrenin.
İlk Bayt Süresi (TTFB), İlk Zengin İçerikli Boyama (FCP) ve Largest Contentful Paint (LCP) gibi diğer tüm anlamlı kullanıcı deneyimi metriklerinden önce gelen temel bir web performansı metriğidir. Bu, yüksek TTFB değerlerinin kendisini takip eden metriklere zaman katacağı anlamına gelir.
Kullanıcıların 75. yüzdelik diliminin "iyi" eşiği dahilinde bir FCP deneyimi yaşaması için sunucunuzun gezinme isteklerine yeterince hızlı yanıt vermesi önerilir. Kaba bir kılavuz olarak, çoğu sitenin 0,8 saniye veya daha kısa bir TTFB'ye sahip olması gerekir.
TTFB Nasıl Ölçülür?
TTFB'yi optimize etmeden önce, web sitenizin kullanıcılarını nasıl etkilediğini gözlemlemeniz gerekir. Yönlendirmelerden etkilenen TTFB'yi gözlemlemek için birincil kaynak olarak alan verilerine bel bağlamalısınız. Laboratuvar tabanlı araçlar ise genellikle nihai URL kullanılarak ölçülür. Bu nedenle, bu ekstra gecikme yaşanmaz.
PageSpeed Insights, Chrome Kullanıcı Deneyimi Raporu'nda bulunan herkese açık web siteleri için hem alan hem de laboratuvar bilgilerini almanın basit bir yoludur.
Gerçek kullanıcılar için TTFB, üstteki Gerçek kullanıcılarınızın neyle karşılaştığını keşfedin bölümünde gösterilir:
TTFB'nin bir alt kümesi, sunucu yanıt süresi denetiminde gösterilmektedir:
TTFB'yi hem alanda hem de laboratuvarda ölçmenin daha fazla yolunu öğrenmek için TTFB metrik sayfasına bakın.
Server-Timing ile yüksek TTFB'yi anlama
Yüksek gecikmeye neden olabilecek farklı arka uç işlemlerini ölçmek için uygulamanızın arka ucunda Server-Timing yanıt başlığı kullanılabilir. Başlık değerinin yapısı esnektir ve en azından tanımladığınız bir herkese açık kullanıcı adını kabul eder. İsteğe bağlı değerler arasında bir süre değeri (dur üzerinden) ve isteğe bağlı olarak kullanıcılar tarafından okunabilir bir açıklama (desc üzerinden) bulunur.
Serving-Timing, birçok uygulama arka uç işlemini ölçmek için kullanılabilir, ancak özellikle dikkat etmeniz gereken bazı noktalar vardır:
- Veritabanı sorguları
- Sunucu tarafı oluşturma süresi (varsa)
- Diskte arama
- Uç sunucu önbellek isabetleri/eksikliği (CDN kullanılıyorsa)
Server-Timing girişinin tüm bölümleri iki nokta üst üste işaretiyle ayrılır. Birden çok giriş ise virgülle ayrılabilir:
// Two metrics with descriptions and values
Server-Timing: db;desc="Database";dur=121.3, ssr;desc="Server-side Rendering";dur=212.2
Üstbilgi, uygulamanızın arka ucunun tercih edilen dili kullanılarak ayarlanabilir. Örneğin, PHP'de başlığı şu şekilde ayarlayabilirsiniz:
<?php
// Get a high-resolution timestamp before
// the database query is performed:
$dbReadStartTime = hrtime(true);
// Perform a database query and get results...
// ...
// Get a high-resolution timestamp after
// the database query is performed:
$dbReadEndTime = hrtime(true);
// Get the total time, converting nanoseconds to
// milliseconds (or whatever granularity you need):
$dbReadTotalTime = ($dbReadEndTime - $dbReadStarTime) / 1e+6;
// Set the Server-Timing header:
header('Server-Timing: db;desc="Database";dur=' . $dbReadTotalTime);
?>
Bu başlık ayarlandığında, hem laboratuvarda hem de alanda kullanabileceğiniz bilgiler gösterilir.
Alanda, Server-Timing yanıt başlığı ayarlanmış herhangi bir sayfa Gezinme Zamanlaması API'sindeki serverTiming özelliğini doldurur:
// Get the serverTiming entry for the first navigation request:
performance.getEntries("navigation")[0].serverTiming.forEach(entry => {
// Log the server timing data:
console.log(entry.name, entry.description, entry.duration);
});
Laboratuvarda, Server-Timing yanıt başlığından gelen veriler Chrome Geliştirici Araçları'ndaki Ağ sekmesinin zamanlamalar panelinde görselleştirilecektir:
Chrome Geliştirici Araçları'nın ağ sekmesinde görselleştirilmiş Server-Timing yanıt başlığı. Burada Server-Timing, bir kaynak isteğinin CDN önbelleğine ulaşıp ulaşmadığını ve isteğin CDN'nin uç sunucusuna ve ardından kaynağa ne kadar sürede ulaştığını ölçmek için kullanılır.
Mevcut verileri analiz ederek sorunlu bir TTFB'nizin olduğunu belirledikten sonra, sorunu düzeltmeye geçebilirsiniz.
TTFB'yi optimize etme yolları
TTFB'yi optimize etmenin en zor yanı, web'in ön uç yığını her zaman HTML, CSS ve JavaScript olsa da, arka uç yığınlarının önemli ölçüde farklılık gösterebilmesidir. Her biri kendi optimizasyon tekniklerine sahip çok sayıda arka uç yığını ve veritabanı ürünü bulunur. Bu nedenle, bu kılavuz yalnızca yığına özgü rehberliğe odaklanmak yerine çoğu mimari için geçerli olan öğelere odaklanacaktır.
Platforma özel rehberlik
Web siteniz için kullandığınız platform TTFB'yi önemli ölçüde etkileyebilir. Örneğin, WordPress'in performansı eklentilerin sayısından ve kalitesinden ya da kullanılan temalardan etkilenir. Platform özelleştirildiğinde diğer platformlar da aynı şekilde etkilenir. Bu yayındaki daha genel performans tavsiyelerine ek olarak tedarikçiye özel öneriler almak için platformunuzun dokümanlarına bakmanız gerekir. Sunucu yanıt sürelerini azaltmaya yönelik Lighthouse denetiminde yığmaya özel sınırlı bazı yönergeler de yer alır.
Barındırma, barındırma
Diğer optimizasyon yaklaşımlarını düşünmeden önce, ilk düşünmeniz gereken barındırma hizmeti olmalıdır. Burada belirli bir konuda yardımcı olmanın pek bir yolu yoktur. Ancak genel kural, web sitenizin barındırıcısının, gönderdiğiniz trafiği yönetebildiğinden emin olmaktır.
Paylaşılan barındırma genellikle daha yavaştır. Çoğunlukla statik dosyalar sunan küçük, kişisel bir web sitesi çalıştırıyorsanız, bu muhtemelen sorun değildir ve aşağıdaki optimizasyon tekniklerinden bazıları TTFB'yi mümkün olduğunca azaltmanıza yardımcı olacaktır.
Bununla birlikte, kişiselleştirme, veritabanı sorgulama ve diğer yoğun sunucu tarafı işlemleri içeren çok sayıda kullanıcıya sahip daha büyük bir uygulama çalıştırıyorsanız, barındırma seçiminiz alanda TTFB'yi azaltmak için kritik hale gelir.
Barındırma sağlayıcısı seçerken şunlara dikkat edin:
- Uygulama örneğinize ne kadar bellek tahsis edildi? Uygulamanız yeterli bellek alanına sahip değilse, aksamaya ve sayfaları mümkün olduğunca hızlı bir şekilde sunmakta zorlanır.
- Barındırma sağlayıcınız arka uç yığınınızı güncel tutuyor mu? Uygulama arka uç dillerinin, HTTP uygulamaları ve veritabanı yazılımlarının yeni sürümleri yayınlandıkça, bu yazılımın performansı zaman içinde artar. Bu tür önemli bakımlara öncelik veren bir barındırma sağlayıcısıyla iş ortaklığı yapmak çok önemlidir.
- Çok spesifik uygulama gereksinimleriniz varsa ve sunucu yapılandırma dosyalarına en düşük düzeyde erişimi istiyorsanız kendi uygulama örneğinizin arka ucunu özelleştirmenin mantıklı olup olmadığını sorun.
Sizin için bu işleri halledecek birçok barındırma sağlayıcısı vardır. Ancak özel barındırma sağlayıcılarında bile uzun TTFB değerleri görmeye başlarsanız bu, mümkün olan en iyi kullanıcı deneyimini sunabilmek için mevcut barındırma sağlayıcınızın özelliklerini yeniden değerlendirmeniz gerekebileceğine işaret edebilir.
İçerik Yayınlama Ağı (CDN) kullanın
CDN kullanımı konusu sık kullanılan bir konudur, ancak bunun iyi bir nedeni vardır: Çok iyi optimize edilmiş bir uygulama arka ucunuz olabilir, ancak kaynak sunucunuzdan uzakta bulunan kullanıcılar yine de sahada yüksek TTFB yaşayabilir.
CDN'ler, kaynakları kullanıcılarınıza fiziksel olarak daha yakın olan sunucularda önbelleğe alan dağıtılmış bir sunucu ağı kullanarak kullanıcıların kaynak sunucunuza yakınlığı sorununu çözer. Bu sunuculara uç sunucuları denir.
CDN sağlayıcıları, uç sunucuların ötesinde de avantajlar sunabilir:
- CDN sağlayıcıları genellikle son derece hızlı DNS çözümleme süreleri sunar.
- CDN, içeriğinizi muhtemelen HTTP/2 veya HTTP/3 gibi modern protokolleri kullanarak uç sunuculardan sunar.
- HTTP/3, özellikle TCP'de mevcut olan (HTTP/2'nin kullandığı) satır başı engelleme sorununu UDP protokolünü kullanarak çözer.
- Bir CDN, muhtemelen TLS'nin modern sürümlerini de sağlar ve bu da TLS iletişim süresinde yer alan gecikmeyi azaltır. Özellikle TLS 1.3, TLS iletişimini mümkün olduğunca kısa tutacak şekilde tasarlanmıştır.
- Bazı CDN sağlayıcıları genellikle "uç çalışan" olarak adlandırılan bir özellik sağlar. Bu özellik, isteklere müdahale etmek, uç önbelleklerdeki yanıtları programatik olarak yönetmek veya yanıtları tümüyle yeniden yazmak için Service Worker API'sininkine benzer bir API kullanır.
- CDN sağlayıcıları, sıkıştırma için optimize etmede çok iyidir. Sıkıştırma işlemini kendi başınıza yapmak zor olabilir ve dinamik olarak oluşturulmuş işaretlemenin, anında sıkıştırılması gereken bazı durumlarda yanıt sürelerinin yavaşlamasına neden olabilir.
- CDN sağlayıcıları ayrıca statik kaynaklar için sıkıştırılmış yanıtları otomatik olarak önbelleğe alarak sıkıştırma oranı ve yanıt süresi arasında en iyi dengeyi sağlar.
CDN'yi benimsemek önemsizden önemliye kadar çeşitli çabalar gerektirse de, web sitenizde zaten TTFB kullanılmıyorsa, TTFB'nizi optimize etmek için yüksek bir öncelik olmalıdır.
Mümkün olduğunda önbelleğe alınmış içerik kullanıldı
CDN'ler, içeriğin uygun Cache-Control HTTP üst bilgileri ile yapılandırılması koşuluyla, fiziksel olarak ziyaretçilere daha yakın olan uç sunucularda içeriğin önbelleğe alınmasına olanak tanır. Bu, kişiselleştirilmiş içerikler için uygun olmamakla birlikte, kaynağa tamamen geri dönmek, CDN'nin değerini önemli ölçüde azaltabilir.
İçeriği sık sık güncelleyen sitelerde kısa bir önbelleğe alma süresi bile yoğun sitelerde gözle görülür performans artışlarına neden olabilir. Çünkü bu süre zarfında yalnızca ilk ziyaretçi kaynak sunucuya geri dönerken tamamen gecikme yaşarken diğer tüm ziyaretçiler uç sunucudaki önbelleğe alınmış kaynağı yeniden kullanabilir. Bazı CDN'ler, site sürümlerinde önbelleği geçersiz kılmaya izin vererek hem uzun önbellek süreleri, hem de gerektiğinde anında güncelleme olanağı sunar.
Önbelleğe almanın doğru yapılandırılmış olsa bile bu durum, analiz ölçümü için benzersiz sorgu dizesi parametreleri kullanılarak göz ardı edilebilir. Bunlar, aynı olmalarına rağmen CDN'den farklı içerikler gibi görünebilir. Bu nedenle, önbelleğe alınan sürüm kullanılmaz.
Daha eski veya daha az ziyaret edilen içerik de önbelleğe alınmayabilir, bu da bazı sayfalarda diğerlerine göre daha yüksek TTFB değerlerine neden olabilir. Önbelleğe alma sürelerinin uzatılması, bu durumun etkisini azaltabilir. Ancak önbelleğe alma sürelerinin uzaması, eski olabilecek içeriklerin sunulması olasılığını da artırır.
Önbelleğe alınan içeriğin etkisi, yalnızca CDN kullananları etkilemez. Önbelleğe alınan içerik yeniden kullanılamadığında sunucu altyapısının maliyetli veritabanı aramalarından içerik oluşturması gerekebilir. Daha sık erişilen veriler veya önceden önbelleğe alınmış sayfalar genellikle daha iyi performans gösterebilir.
Çoklu sayfa yönlendirmelerinden kaçının
Yüksek bir TTFB'ye katkıda bulunan en yaygın faktörlerden biri yönlendirmelerdir. Bir dokümana yönelik gezinme isteği, tarayıcıya kaynağın başka bir konumda bulunduğunu bildiren bir yanıt aldığında yönlendirmeler gerçekleşir. Bir yönlendirme kesinlikle gezinme isteğine istenmeyen gecikme ekleyebilir. Ancak yönlendirme, başka bir yönlendirmeyle (ve bu şekilde devam eden başka bir kaynağa) işaret ederse kesinlikle daha kötü hale gelebilir. Bu siteler, ölçüm amacıyla analiz hizmetleri aracılığıyla yönlendirme yaptığından, bu siteler özellikle reklamlarınızdan veya bültenlerden çok sayıda ziyaretçi alan siteleri etkileyebilir. Doğrudan kontrolünüz altındaki yönlendirmeleri ortadan kaldırmak, iyi bir TTFB elde etmenize yardımcı olabilir.
İki tür yönlendirme vardır:
- Yönlendirmenin tamamen web sitenizde gerçekleştiği aynı kaynaklı yönlendirmeler.
- Kaynaklar arası yönlendirmeler: Yönlendirme, web sitenize ulaşmadan önce başlangıçta başka bir kaynakta (ör. bir sosyal medya URL'si kısaltma hizmetinden) gerçekleşir.
Doğrudan kontrolünüz olacağı için, aynı kaynaktan gelen yönlendirmeleri ortadan kaldırmaya odaklanmak istersiniz. Bunun için web sitenizdeki bağlantılardan herhangi birinin 302 veya 301 yanıt koduyla sonuçlanıp sonuçlanmadığını kontrol etmeniz gerekir. Genellikle bu, https:// şemasının dahil edilmemesinden (böylece tarayıcılar varsayılan olarak http:// değerine ayarlanır) veya sondaki eğik çizgilerin URL'ye uygun şekilde dahil edilmediği ya da hariç tutulmamasından kaynaklanabilir.
Kaynaklar arası yönlendirmeler genellikle sizin kontrolünüzün dışında olduğundan daha karmaşıktır. Ancak mümkün olduğunda birden fazla yönlendirmeden kaçınmaya çalışın (örneğin, bağlantı paylaşırken birden fazla bağlantı kısaltıcı kullanmak). Söz konusu hizmetler tarafından kullanılanlara başka bir yönlendirme eklememek için, reklamverenlere veya bültenlere sağlanan URL'nin doğru nihai URL olduğundan emin olun.
Yönlendirme süresinin başka bir önemli kaynağı da HTTP-HTTPS yönlendirmelerinden gelebilir. Bu sorunu aşmanın yollarından biri, Strict-Transport-Security üst bilgisini (HSTS) kullanmaktır. Bu üstbilgi, bir kaynağa yapılan ilk ziyarette HTTPS'yi zorunlu kılar, ardından tarayıcıya sonraki ziyaretlerde HTTPS şeması aracılığıyla kaynağa hemen erişmesini sağlar.
İyi bir HSTS politikası oluşturduktan sonra, sitenizi HSTS ön yükleme listesine ekleyerek bir kaynağa ilk ziyaretinizde süreci hızlandırabilirsiniz.
İşaretlemeyi tarayıcıda akış şeklinde göster
Tarayıcılar işaretlemeyi akış sırasında verimli bir şekilde işlemek için optimize edilmiştir. Diğer bir deyişle, işaretleme sunucudan geldikçe parçalar halinde işlenir. Bu, büyük işaretleme yüklerinin söz konusu olduğu durumlarda çok önemlidir. Çünkü bu, ayrıştırma işlemi başlamadan önce yanıtın tamamının ulaşmasını beklemek yerine, tarayıcının işaretleme parçalarını kademeli olarak ayrıştırabileceği anlamına gelir.
Tarayıcılar akış işaretlemesini işlemede harikadır, ancak bu akışın akışını sağlamak için elinizden gelen her şeyi yapmanız çok önemlidir. Böylece, bu başlangıç işaretleme parçaları bir an önce kullanılabilir hale gelir. Arka uç bir şeyleri bekletiyorsa sorun vardır. Arka uç yığınları çok sayıda olduğundan, her bir yığını ve her bir grupta ortaya çıkabilecek sorunları ele almak bu kılavuzun kapsamı dışındadır.
Örneğin tepki verenler ve sunucuda isteğe bağlı olarak işaretleme oluşturabilen diğer çerçeveler, sunucu tarafı oluşturma için eşzamanlı bir yaklaşımdan yararlanmıştır. Bununla birlikte, React'ın yeni sürümlerinde, oluşturma işlemleri sırasında akış işaretlemesi için sunucu yöntemleri uygulanmaktadır. Bu, React sunucu API yönteminin, yanıt gönderilmeden önce tüm yanıtı oluşturmasını beklemenize gerek olmadığı anlamına gelir.
İşaretlemenin tarayıcıya hızlı bir şekilde aktarılmasını sağlamanın bir başka yolu, derleme süresi sırasında HTML dosyaları oluşturan statik oluşturmaya güvenmektir. Tam dosya anında kullanılabilir olduğunda, web sunucuları dosyayı hemen göndermeye başlayabilir ve HTTP'nin doğası gereği akış işaretlemesi oluşturulur. Bu yaklaşım, her web sitesindeki her sayfaya (kullanıcı deneyiminin bir parçası olarak dinamik yanıt gerektirenler gibi) uygun olmasa da, işaretlemenin belirli bir kullanıcıya göre kişiselleştirilmesini gerektirmeyen sayfalar için faydalı olabilir.
Service Worker kullanın
Service Worker API'nin hem dokümanlar hem de yükledikleri kaynaklar için TTFB'yi önemli ölçüde etkileyebilir. Bunun nedeni, Service Worker'ın tarayıcı ile sunucu arasında bir proxy görevi görmesidir. Ancak web sitenizin TTFB'si üzerinde bir etkinin olup olmaması, hizmet çalışanınızı nasıl ayarladığınıza ve bu kurulumun uygulama gereksinimlerinize uygun olup olmadığına bağlıdır.
- Öğeler için eski bir yeniden doğrulama stratejisi kullanın. Bir öğe hizmet çalışanı önbelleğindeyse (doküman veya dokümanın gerektirdiği bir kaynak olabilir) eski yeniden doğrulama stratejisi bu kaynağı önce önbellekten sunar, ardından öğeyi arka planda indirir ve gelecekteki etkileşimler için önbellekten sunar.
- Çok sık değişmeyen belge kaynaklarınız varsa eski "yeniden doğrulama" stratejisi kullanmak, sayfanın TTFB'sini neredeyse anında sağlayabilir. Ancak web siteniz, kullanıcının kimliğinin doğrulanıp doğrulanmadığına bağlı olarak değişen işaretleme gibi dinamik olarak oluşturulmuş işaretleme gönderiyorsa bu yöntem pek işe yaramaz. Bu gibi durumlarda, doküman mümkün olduğunca güncel olduğundan, her zaman için önce ağı kullanmanız gerekir.
- Belgeniz belirli bir sıklıkta değişen kritik olmayan kaynakları yüklüyor ancak eski kaynağın getirilmesi, kullanıcı deneyimini büyük ölçüde etkilemez (seçili resimler veya kritik olmayan diğer kaynaklar gibi). Bu kaynakların TTFB, eski bir yeniden doğrulama stratejisi kullanılarak büyük ölçüde azaltılabilir.
- Mümkünse akış hizmet çalışanı mimarisi kullanın. Bu Service Worker mimarisi, bir belge kaynağının parçalarının Service Worker önbelleğinde depolandığı ve gezinme isteği sırasında içerik bölümleriyle birleştirildiği bir yaklaşım kullanır. Bu hizmet çalışanı modelini kullanmanın sonucunda, gezinmeniz oldukça hızlı olurken ağdan daha küçük HTML yükü indirilir. Bu hizmet çalışanı kalıbı her web sitesinde çalışmasa da doküman kaynaklarına ilişkin TTFB süreleri, onu kullanabilen siteler için neredeyse anında olabilir.
- İstemci tarafından oluşturulan uygulamalar için uygulama kabuğu modelini kullanın. Bu model, sayfa "kabuğunun" Service Worker önbelleğinden anında iletilebileceği ve sayfanın dinamik içeriğinin sayfa yaşam döngüsünün ilerleyen aşamalarında doldurulup oluşturulduğu SPA'lar için en uygun seçenektir.
Oluşturma açısından kritik kaynaklar için 103 Early Hints kullanın
Uygulama arka ucunuz ne kadar iyi optimize edilmiş olursa olsun, bir yanıt hazırlamak için sunucunun yapması gereken önemli miktarda iş olabilir. Bunlar arasında navigasyon yanıtının olabildiğince hızlı ulaşmasını geciktiren pahalı (ancak gerekli) veritabanı çalışmaları da olabilir. Bunun olası etkisi, CSS veya bazı durumlarda istemcide işaretleme oluşturan JavaScript gibi sonraki oluşturma açısından kritik bazı kaynakların gecikmeli olabilmesidir.
103 Early Hints üst bilgisi, arka uç işaretlemeyi hazırlamakla meşgulken sunucunun tarayıcıya gönderebileceği erken yanıt kodudur. Bu üstbilgi, işaretleme hazırlanırken sayfanın indirilmeye başlaması gereken oluşturma açısından kritik kaynakların bulunduğunu tarayıcıya belirtmek için kullanılabilir. Tarayıcıları destekleme açısından, doküman oluşturma (CSS) ve temel sayfa işlevleri daha hızlı kullanılabilir (JavaScript).
Sonuç
Arka uç uygulama yığınlarının çok sayıda kombinasyonu olduğundan, web sitenizin TTFB'sini azaltmak için yapabileceğiniz her şeyi kapsayan tek bir makale yoktur. Ancak bunlar sunucu tarafında işleri biraz daha hızlı hale getirmek için deneyebileceğiniz bazı seçeneklerdir.
Her metriğin optimizasyonunda olduğu gibi yaklaşım büyük ölçüde benzerdir: TTFB'nizi sahada ölçün, nedenleri ayrıntılı olarak incelemek için laboratuvar araçlarını kullanın ve mümkün olduğunda optimizasyonları uygulayın. Buradaki her teknik sizin durumunuz için uygun olmayabilir, ancak bazı teknikler sizin durumunuz için uygun olabilir. Her zaman olduğu gibi, mümkün olan en hızlı kullanıcı deneyimini sağlamak için alan verilerinizi yakından takip etmeniz ve gerekli düzenlemeleri yapmanız gerekir.
Unsplash'in kaynağı olarak Taylor Vick'in lokomotif resmi.