İlk Bayta Erişim Süresi metriği için nasıl optimizasyon yapacağınızı öğrenin.
İlk Bayta Kadar Geçen Süre (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, bunu izleyen metriklere zaman eklediği anlamına gelir.
Sunucunuzun gezinme isteklerine yeterince hızlı yanıt vermesi önerilir. Böylece, kullanıcıların %75'i "iyi" eşiğinin altında bir FCP deneyimleyebilir. Kabaca bir kılavuz olarak, çoğu sitenin TTFB'sinin 0,8 saniye veya daha az olması gerekir.
TTFB'yi Ölçme
TTFB'yi optimize etmeden önce, bunun web sitenizin kullanıcılarını nasıl etkilediğini gözlemlemeniz gerekir. TTFB, yönlendirmelerden etkilendiği için birincil gözlem kaynağı olarak sahada toplanan verileri kullanmanız gerekir. Laboratuvar tabanlı araçlar genellikle nihai URL kullanılarak ölçüldüğünden bu ek gecikmeyi atlar.
PageSpeed Insights, herkese açık web siteleri için hem saha hem de laboratuvar bilgilerini Chrome Kullanıcı Deneyimi Raporu'nda bulabileceğiniz bir yöntemdir.
Gerçek kullanıcılar için TTFB, en üstteki Gerçek kullanıcılarınızın nelerle karşılaştığını görün bölümünde gösterilir:
Sunucu yanıt süresi denetiminde TTFB'nin bir alt kümesi gösterilir:
Hem sahada hem de laboratuvarda TTFB'yi ölçmenin diğer yollarını öğrenmek için TTFB metrik sayfasına göz atın.
Server-Timing ile sahada yüksek TTFB'de hata ayıklama
Server-Timing yanıt başlığı, yüksek gecikmeye neden olabilecek farklı arka uç işlemlerini ölçmek için uygulamanızın arka ucunda 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 aracılığıyla) ve isteğe bağlı olarak kullanıcı tarafından okunabilen bir açıklama (desc aracılığıyla) bulunur.
Serving-Timing, birçok uygulama arka uç sürecini ölçmek için kullanılabilir ancak özellikle dikkat etmeniz gereken bazı süreçler vardır:
- Veritabanı sorguları
- Varsa sunucu tarafı oluşturma süresi
- Disk aramaları
- Edge sunucusu önbelleği isabetleri/isabetleri (CDN kullanılıyorsa)
Server-Timing girişinin tüm bölümleri iki nokta işaretiyle ayrılır ve birden fazla giriş 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 ettiği dil kullanılarak ayarlanabilir. Örneğin, PHP'de üstbilgiyi ş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 - $dbReadStartTime) / 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 sahada kullanabileceğiniz bilgiler gösterilir.
Alanda, Server-Timing yanıt üstbilgisi ayarlanmış tüm sayfalar Gezinme Zamanlama API'sindeki serverTiming mülkünü 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 üst bilgisindeki veriler Chrome Geliştirici Araçları'ndaki Ağ sekmesinin zamanlama panelinde görselleştirilir:
Chrome Geliştirici Araçları'nın ağ sekmesinde görselleştirilen Server-Timing yanıt üstbilgileri. Burada Server-Timing, bir kaynak isteği için CDN önbelleğe ulaşılıp ulaşılmadığını ve isteğin CDN'nin uç sunucusuna ve ardından kaynağa ulaşmasının ne kadar sürdüğünü ölçmek için kullanılır.
Mevcut verileri analiz ederek TTFB'nizin sorunlu olduğunu belirledikten sonra sorunu düzeltmeye geçebilirsiniz.
TTFB'yi optimize etme yöntemleri
TTFB'yi optimize etmenin en zor yönü, web'in ön uç yığınının her zaman HTML, CSS ve JavaScript olması, arka uç yığınlarının ise önemli ölçüde değişiklik gösterebilmesidir. Her biri kendi optimizasyon tekniklerine sahip çok sayıda arka uç paketi ve veritabanı ürünü vardır. Bu nedenle bu kılavuzda, yalnızca yığına özgü yönergelere odaklanmak yerine çoğu mimari için geçerli olan konulara odaklanılmıştır.
Platforma özel rehberlik
Web siteniz için kullandığınız platform, TTFB'yi büyük ölçüde etkileyebilir. Örneğin, WordPress performansı; eklentilerin sayısı ve kalitesi ya da kullanılan temalardan etkilenir. Platform özelleştirildiğinde diğer platformlar da benzer şekilde etkilenir. Bu yayındaki daha genel performans önerilerine ek olarak tedarikçiye özel öneriler için platformunuzun dokümanlarına bakmanız gerekir. Sunucu yanıt sürelerini azaltmaya yönelik Lighthouse denetimi, stack'e özel sınırlı sayıda kılavuz da içerir.
Barındırma, barındırma, barındırma
Diğer optimizasyon yaklaşımlarını düşünmeden önce ilk dikkate almanız gereken konu barındırma olmalıdır. Burada verilecek belirli bir rehberlik yoktur ancak genel bir kural olarak, web sitenizin barındırma sağlayıcısının kendisine gönderdiğiniz trafiği işleyebileceğinden emin olmanız gerekir.
Paylaşılan barındırma genellikle daha yavaştır. Çoğunlukla statik dosyalar sunan küçük bir kişisel web siteniz varsa bu durum muhtemelen sorun oluşturmaz. Aşağıdaki optimizasyon tekniklerinden bazıları, TTFB'yi mümkün olduğunca düşürmenize yardımcı olacaktır.
Ancak kişiselleştirme, veritabanı sorgulama ve sunucu tarafında yoğun işlemler içeren, çok sayıda kullanıcısı olan daha büyük bir uygulamayı çalıştırıyorsanız alandaki TTFB'yi düşürmek için barındırma seçiminiz kritik öneme sahip olur.
Barındırma sağlayıcı seçerken dikkat etmeniz gereken bazı noktalar:
- Uygulama örneğinize ne kadar bellek ayrıldı? Uygulamanızda yeterli bellek yoksa sayfaları mümkün olduğunca hızlı yayınlamak için çabalar ve bu işlem çok yavaş gerçekleşir.
- Barındırma sağlayıcınız arka uç paketinizi güncel tutuyor mu? Uygulama arka uç dillerinin, HTTP uygulamalarının ve veritabanı yazılımlarının yeni sürümleri kullanıma sunulduğunda, bu yazılımlardaki performans zaman içinde iyileşir. Bu tür önemli bakım işlemlerine öncelik veren bir barındırma sağlayıcıyla iş ortaklığı yapmanız önemlidir.
- Çok özel uygulama gereksinimleriniz varsa ve sunucu yapılandırma dosyalarına en düşük düzeyde erişim istiyorsanız kendi uygulama örneğinizin arka ucunu özelleştirmenin mantıklı olup olmadığını öğrenin.
Bu tür konularda size yardımcı olacak birçok barındırma sağlayıcı vardır. Ancak özel barındırma sağlayıcılarda bile uzun TTFB değerleri görmeye başlarsanız 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 gerekebilir.
İçerik yayınlama ağı (CDN) kullanma
CDN kullanımı konusu, iyi bir nedenden dolayı çok sık ele alınan bir konudur: Uygulamanızın arka ucu çok iyi optimize edilmiş olsa bile kaynak sunucunuzdan uzakta bulunan kullanıcılar, alanda yüksek TTFB deneyimleyebilir.
CDN'ler, kaynakları kullanıcılarınıza fiziksel olarak daha yakın 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 adı verilir.
CDN sağlayıcılar, uç sunucuların ötesinde avantajlar da sunabilir:
- CDN sağlayıcılar genellikle son derece hızlı DNS çözümleme süreleri sunar.
- CDN'ler, içeriğinizi HTTP/2 veya HTTP/3 gibi modern protokoller kullanarak uç sunuculardan yayınlar.
- Özellikle HTTP/3, UDP protokolünü kullanarak TCP'de (HTTP/2'nin kullandığı) bulunan sıranın başında engelleme sorununu çözer.
- CDN'ler, TLS'nin modern sürümlerini de sunar. Bu sürümler, TLS iletişim süresinde yaşanan gecikmeyi azaltır. Özellikle TLS 1.3, TLS iletişimini mümkün olduğunca kısa tutmak için tasarlanmıştır.
- Bazı CDN sağlayıcıları, genellikle "uç çalışan" olarak adlandırılan bir özellik sunar. Bu özellik, istekleri durdurmak, uç önbelleğe alınan yanıtları programatik olarak yönetmek veya yanıtları tamamen yeniden yazmak için Service Worker API'ye benzer bir API kullanır.
- CDN sağlayıcılar, sıkıştırma için optimizasyon konusunda çok iyidir. Sıkıştırma işlemini doğru şekilde gerçekleştirmek zordur ve dinamik olarak oluşturulan işaretlemede anında sıkıştırılması gereken belirli durumlarda yanıt sürelerinin uzamasına neden olabilir.
- CDN sağlayıcılar, 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 açısından en iyi kombinasyonu sağlar.
CDN'yi kullanmaya başlamak, önem derecesi önemsizden önemliye değişen miktarda çaba gerektirse de web siteniz henüz CDN kullanmıyorsa TTFB'nizi optimize etmek için bu konuya öncelik vermelisiniz.
Mümkün olduğunda önbelleğe alınmış içerikleri kullanın.
CDN'ler, içeriğin uygun Cache-Control HTTP başlıklarıyla yapılandırılması koşuluyla içeriğin ziyaretçilere fiziksel olarak daha yakın olan uç sunucularda önbelleğe alınmasına olanak tanır. Bu, kişiselleştirilmiş içerikler için uygun olmasa da kaynağın başına kadar geri dönmeyi gerektirmesi, CDN'nin değerinin büyük bir kısmını ortadan kaldırabilir.
İçeriklerini sık sık güncelleyen siteler için kısa bir önbelleğe alma süresi bile yoğun sitelerde belirgin performans kazanımları sağlayabilir. Bunun nedeni, bu süre zarfında yalnızca ilk ziyaretçinin kaynak sunucuya geri dönen tam gecikmeyi deneyimlemesi, diğer tüm ziyaretçilerin ise önbelleğe alınmış kaynağı uç sunucuda yeniden kullanabilmesidir. Bazı CDN'ler, site sürümlerinde önbelleğin geçersiz kılınmasına izin verir. Böylece, hem uzun önbellek süreleri hem de gerektiğinde anında güncellemeler elde edebilirsiniz.
Önbelleğe alma doğru şekilde 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ı olmasına rağmen CDN'ye farklı içerik gibi görünebilir. Bu nedenle, önbelleğe alınmış sürüm kullanılmaz.
Eski veya daha az ziyaret edilen içerikler de önbelleğe alınamayabilir. Bu da bazı sayfalarda diğer sayfalara kıyasla daha yüksek TTFB değerlerine neden olabilir. Önbelleğe alma sürelerini artırmak bu durumun etkisini azaltabilir ancak önbelleğe alma süreleri arttıkça eski içeriklerin sunulma olasılığının da arttığını unutmayın.
Önbelleğe alınmış içeriğin etkisi yalnızca CDN kullananları etkilemez. Önbelleğe alınan içerik yeniden kullanılamadığında sunucu altyapısının, pahalı veritabanı aramalarından içerik oluşturması gerekebilir. Sık erişilen veriler veya önceden önbelleğe alınan sayfalar genellikle daha iyi performans gösterebilir.
Çoklu sayfa yönlendirmelerinden kaçının
Yüksek TTFB'ye neden olan yaygın faktörlerden biri yönlendirmelerdir. Yönlendirmeler, bir doküman için gezinme isteği, tarayıcıya kaynağın başka bir konumda olduğunu bildiren bir yanıt aldığında gerçekleşir. Bir yönlendirme, gezinme isteğine kesinlikle istenmeyen bir gecikme süresi ekleyebilir ancak bu yönlendirme başka bir kaynağı işaret ederse ve bu da başka bir yönlendirmeye neden olursa durum daha da kötüye gidebilir. Bu durum, genellikle ölçüm amacıyla analiz hizmetleri üzerinden yönlendirme yaptığından, reklamlardan veya bültenlerden çok sayıda ziyaretçi alan siteleri özellikle 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ı kaynaktan yönlendirmeler.
- Çapraz kaynak yönlendirmeleri: Yönlendirmenin, web sitenize ulaşmadan önce başlangıçta başka bir kaynakta (ör. sosyal medya URL kısaltma hizmeti) gerçekleştiği durumlar.
Doğrudan kontrol sahibi olacağınız için aynı kaynaktan yönlendirmeleri ortadan kaldırmaya odaklanmalısınız. Bu, web sitenizdeki bağlantıları kontrol ederek bunlardan herhangi birinin 302 veya 301 yanıt koduyla sonuçlanıp sonuçlanmadığını kontrol etmeyi içerir. Bu durum genellikle https:// şemasının dahil edilmemesinden (tarayıcılar varsayılan olarak http://'e yönlendirildiğinden) veya sağa eğik çizgilerin URL'ye uygun şekilde dahil edilmemesinden ya da hariç tutulmamasından kaynaklanabilir.
Kaynaklar arası yönlendirmeler genellikle sizin kontrolünüz dışında olduğundan daha zordur ancak mümkün olduğunda birden fazla yönlendirmeden kaçının (ör. bağlantıları paylaşırken birden fazla bağlantı kısaltıcı kullanarak). Reklamverenlere veya bültenlere sağlanan URL'nin, bu hizmetler tarafından kullanılanlara başka bir yönlendirme eklenmemesi için doğru nihai URL olduğundan emin olun.
Yönlendirme süresinin önemli bir kaynağı da HTTP'den HTTPS'ye yönlendirmeler olabilir. Bu sorunun üstesinden gelmenin bir yolu, Strict-Transport-Security üst bilgisini (HSTS) kullanmaktır. Bu üst bilgi, bir kaynağa yapılan ilk ziyarette HTTPS'yi zorunlu kılar ve ardından tarayıcıya gelecekteki ziyaretlerde kaynağa HTTPS şeması üzerinden hemen erişmesini söyler.
İyi bir HSTS politikası uyguladıktan sonra, sitenizi HSTS ön yükleme listesine ekleyerek bir kaynağa yapılan ilk ziyarette süreci hızlandırabilirsiniz.
İşaretleri tarayıcıya aktarma
Tarayıcılar, işaretleme akış halindeyken verimli bir şekilde işlenecek şekilde optimize edilmiştir. Bu, işaretlemenin sunucudan geldikçe parçalara ayrılarak işlendiği anlamına gelir. Bu, büyük işaretleme yükü söz konusu olduğunda çok önemlidir. Çünkü tarayıcı, ayrıştırma işlemine başlamadan önce yanıtın tamamının gelmesini beklemek yerine işaretleme parçalarını kademeli olarak ayrıştırabilir.
Tarayıcılar, akış biçimindeki işaretlemeyi işlemede mükemmel olsa da bu akışların devam etmesini sağlamak için elinizden geleni yapmanız önemlidir. Böylece, ilk işaretleme parçaları en kısa sürede gönderilir. Arka uç işlemleri yavaşlatıyorsa bu bir sorundur. Arka uç yığınları çok sayıda olduğundan her yığının ve her yığınta ortaya çıkabilecek sorunların ele alınması bu kılavuzun kapsamı dışındadır.
Örneğin React ve sunucu üzerinde isteğe bağlı olarak işaretlemeyi oluşturabilen diğer çerçeveler, sunucu tarafı oluşturma için senkronize bir yaklaşım kullanmıştır. Ancak React'in daha yeni sürümlerinde, oluşturulurken yazım işaretlerini yayınlamak için sunucu yöntemleri uygulanmıştır. Bu, bir React sunucu API yönteminin yanıtın tamamını gönderilmeden önce oluşturmasını beklemeniz gerekmediği anlamına gelir.
İşaretin tarayıcıya hızlı bir şekilde aktarılmasını sağlamanın bir başka yolu da derleme sırasında HTML dosyaları oluşturan statik oluşturma özelliğini kullanmaktır. Dosyanın tamamı hemen kullanılabilir olduğunda web sunucuları dosyayı hemen göndermeye başlayabilir ve HTTP'nin doğası gereği işaretleme akışına neden olur. Bu yaklaşım, her web sitesindeki her sayfa için uygun değildir (ör. kullanıcı deneyiminin bir parçası olarak dinamik yanıt gerektirenler). Ancak işaretlemenin belirli bir kullanıcıya göre kişiselleştirilmesini gerektirmeyen sayfalar için yararlı olabilir.
Hizmet çalışanı kullanma
Service Worker API, hem dokümanlar hem de yükledikleri kaynaklar için TTFB üzerinde büyük bir etkiye sahip olabilir. Bunun nedeni, hizmet çalışanlarının tarayıcı ile sunucu arasında proxy görevi görmesidir. Ancak web sitenizin TTFB'si üzerinde bir etkisi olup olmadığı, hizmet çalışanınızı nasıl ayarladığınıza ve bu ayarın uygulama gereksinimlerinizle uyumlu olup olmadığına bağlıdır.
- Öğeler için yeniden doğrulama sırasında eski strateji kullanın. Bir öğe (doküman veya dokümanın gerektirdiği bir kaynak olabilir) hizmet çalışanı önbelleğindeyse yeniden doğrulama sırasında eski strateji, 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 yeniden doğrulama sırasında eski stratejiyi kullanmak, sayfanın TTFB'sini neredeyse anında hale getirebilir. Ancak web siteniz dinamik olarak oluşturulmuş işaretleme gönderiyorsa (ör. kullanıcının kimliğinin doğrulanıp doğrulanmadığına göre değişen işaretleme) bu yöntem pek işe yaramaz. Böyle durumlarda, dokümanın mümkün olduğunca güncel olması için her zaman ağı önce kullanmak istersiniz.
- Belgeniz, belirli bir sıklıkta değişen kritik olmayan kaynaklar yüklüyorsa ancak eski kaynağın getirilmesi kullanıcı deneyimini önemli ölçüde etkilemiyorsa (ör. belirli resimler veya kritik olmayan diğer kaynaklar) bu kaynaklar için TTFB, eski kaynak yeniden doğrulanırken stratejisi kullanılarak önemli ölçüde azaltılabilir.
- İstemci tarafından oluşturulan uygulamalar için uygulama kabuğu modelini kullanın. Bu model, sayfanın "kabuk"unun hizmet çalışanı önbelleğinden anında yayınlanabildiğ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 modeldir.
Oluşturma işlemi için kritik kaynaklarda 103 Early Hints kullanın
Uygulamanızın arka ucu ne kadar iyi optimize edilmiş olursa olsun, sunucunun bir yanıt hazırlamak için yapması gereken önemli miktarda iş olabilir. Bu işlemler arasında, gezinme yanıtının olabildiğince hızlı gelmesini geciktiren pahalı (ancak gerekli) veritabanı işlemleri de yer alır. Bunun olası bir etkisi, CSS veya bazı durumlarda istemcide işaretlemeyi oluşturan JavaScript gibi, oluşturma işlemi için kritik olan bazı sonraki kaynakların gecikmesi olabilir.
103 Early Hints üst bilgisi, arka uç işaretlemeyi hazırlamakla meşgulken sunucunun tarayıcıya gönderebileceği erken bir yanıt kodudur. Bu üstbilgi, işaretleme hazırlanırken sayfanın indirmeye başlaması gereken, oluşturma için kritik öneme sahip kaynaklar olduğunu tarayıcıya bildirmek için kullanılabilir. Desteklenen tarayıcılarda bu özellik, doküman oluşturmanın daha hızlı olması (CSS) ve temel sayfa işlevlerinin daha hızlı kullanılabilir olması (JavaScript) şeklinde sonuçlanabilir.
Sonuç
Arka uç uygulama yığınlarının çok fazla kombinasyonu olduğundan, web sitenizin TTFB'sini düşürmek için yapabileceğiniz her şeyi kapsayan tek bir makale yoktur. Ancak sunucu tarafında işlemleri biraz daha hızlı hale getirmek için deneyebilirsiniz.
Her metriği optimize ederken 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 ardından mümkün olduğunda optimizasyonları uygulayın. Buradaki tekniklerin her biri sizin durumunuz için uygun olmayabilir ancak bazı teknikler 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 izlemeniz ve gerektiğinde düzenlemeler yapmanız gerekir.
Unsplash'tan alınan Taylor Vick tarafından oluşturulan lokomotif resim.