İlk Bayt Zamanı Optimizasyonu

İlk Bayt Zamanı metriği için nasıl optimizasyon yapacağınızı öğrenin.

Jeremy Wagner

Barry Pollard

İlk Bayta Kadar Geçen Süre (TTFB), İlk Contentful Paint (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 takip eden metriklere zaman kattığı anlamına gelir.

Kullanıcıların 75. yüzdelik diliminin FCP'yi "iyi" eşiğinde deneyimlemesi için sunucunuzun, gezinme isteklerine yeterince hızlı yanıt vermesi önerilir. Yaklaşık 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, bunun web sitenizin kullanıcılarını nasıl etkilediğini gözlemlemeniz gerekir. TTFB'yi gözlemlemek için birincil kaynak olarak alan verilerini kullanmalısınız. Laboratuvar tabanlı araçlar ise genellikle nihai URL kullanılarak ölçülür, dolayısıyla bu ekstra gecikmeyi içermez.

PageSpeed Insights, Chrome Kullanıcı Deneyimi Raporu'nda bulunan, herkese açık web siteleriyle ilgili hem alan hem de laboratuvar bilgilerini almanın bir yoludur.

Gerçek kullanıcılar için TTFB, üst Gerçek kullanıcılarınızın neler yaşadığını keşfedin bölümünde gösterilir:

TTFB'nin bir alt kümesi, sunucu yanıt süresi denetiminde gösterilir:

TTFB'yi hem sahada hem de laboratuvarda nasıl ölçeceğinizi öğrenmek için TTFB metrik sayfasına bakın.

Server-Timing ile sahada yüksek TTFB hatalarını ayıkla

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 sizin tanımladığınız bir herkese açık kullanıcı adını kabul eder. İsteğe bağlı değerler arasında süre değeri (dur üzerinden) ve isteğe bağlı olarak kullanıcılar tarafından okunabilir bir açıklama (desc üzerinden) yer alır.

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ı
• Geçerliyse sunucu tarafı oluşturma süresi
• Disk araması
• Uç sunucu önbellek isabetleri/eksikleri (CDN kullanılıyorsa)

Server-Timing girişinin tüm bölümleri iki nokta üst üste ile 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

Başlık, uygulamanızın arka ucunun seçilen dili 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 - $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.

Bu alanda, Server-Timing yanıt başlığı ayarlanmış tüm sayfalar Gezinme Timing API'deki 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 alınan veriler, Chrome Geliştirici Araçları'ndaki Ağ sekmesinin zamanlamalar panelinde görselleştirilecek:

Chrome Geliştirici Araçları'nın ağ sekmesinde gösterilen Server-Timing yanıt başlıkları. 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 ulaşmasının ne kadar sürdüğünü ölçmek için kullanılır.

Mevcut verileri analiz ederek sorunlu bir TTFB'niz olduğunu belirledikten sonra, sorunu düzeltmeye geçebilirsiniz.

TTFB'yi optimize etme yolları

TTFB'yi optimize etmenin en zorlu yanı, web'in ön uç yığını her zaman HTML, CSS ve JavaScript olacakken, 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ığınları ve veritabanı ürünleri vardır. Bu nedenle bu kılavuz, yalnızca yığına özel rehberlikten ziyade çoğu mimari için geçerli olan özelliklere odaklanacaktır.

Platforma özel yönergeler

Web siteniz için kullandığınız platform TTFB'yi büyük ölçüde etkileyebilir. Örneğin, WordPress performansı, eklentilerin sayısından ve kalitesinden ya da kullanılan temalardan etkilenir. Platform özelleştirildiğinde diğer platformlar da benzer şekilde etkilenir. Bu gönderideki daha genel performans tavsiyesinin yanı sıra satıcıya özel tavsiyeler için platformunuzun belgelerine bakmanız gerekir. Sunucu yanıt sürelerini azaltmayla ilgili Lighthouse denetiminde yığa özel sınırlı bazı yönergeler de bulunur.

Barındırma, barındırma, barındırma

Diğer optimizasyon yaklaşımlarını değerlendirmeden önce, üzerinde düşüneceğiniz ilk iş barındırma olmalıdır. Burada sunabileceğiniz belirli bir yönlendirmenin çok fazla bir yolu yoktur, ancak genel kural, web sitenizin barındırıcısının ona gönderdiğiniz trafiği işleyebildiğinden emin olmaktır.

Paylaşılan barındırma hizmeti genellikle daha yavaş olur. Çoğunlukla statik dosyalar sunan küçük bir kişisel web sitesi çalıştırıyorsanız, bu muhtemelen iyi bir durumdur ve aşağıdaki optimizasyon tekniklerinden bazıları TTFB'yi mümkün olduğunca azaltmanıza yardımcı olur.

Bununla birlikte, kişiselleştirme, veritabanı sorgulaması 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 bu alanda TTFB'yi azaltmak için kritik önem taşır.

Barındırma sağlayıcısı seçerken aşağıdakilere dikkat etmeniz gerekir:

• Uygulama örneğinize ne kadar bellek ayrıldı? Uygulamanızda yeterli belleğe sahip olmayan uygulamalar varsa aşırı yüklenmeye neden olur 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 kullanıma sunuldukça bu yazılımın performansı zamanla iyileşecektir. Bu tür kritik bakımlara öncelik veren bir barındırma sağlayıcıyla iş ortaklığı yapmak çok önemlidir.
• Çok spesifik uygulama gereksinimleriniz varsa ve sunucu yapılandırma dosyalarına en düşük düzeyde erişim elde etmek istiyorsanız kendi uygulama örneğinizin arka ucunu özelleştirmenin mantıklı olup olmadığını sorun.

Bu işlemleri sizin yerinize yapacak 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özlemlemeye başlarsanız bu durum, 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 dair bir işaret olabilir.

İçerik Yayınlama Ağı (CDN) Kullanma

CDN kullanımı yaygın 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 deneyimi yaşayabilir.

CDN'ler, kullanıcılarınıza fiziksel olarak daha yakın olan sunucularda kaynakları ö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 de avantajlar sunabilir:

• CDN sağlayıcıları genellikle son derece hızlı DNS çözümleme süreleri sunar.
• CDN, büyük olasılıkla içeriğinizi HTTP/2 veya HTTP/3 gibi modern protokolleri kullanan uç sunuculardan yayınlar.
• HTTP/3 özellikle TCP'de bulunan satır içi engelleme sorununu (HTTP/2'nin temel aldığı) UDP protokolünü kullanarak çözer.
• Bir CDN, muhtemelen TLS'nin modern sürümlerini de sağlar, bu da TLS iletişim süresindeki 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ı, Service Worker API'ninkine benzer bir API kullanarak isteklere müdahale etmek, uç önbelleklerdeki yanıtları programatik olarak yönetmek veya yanıtları tamamen yeniden yazmak için genellikle "uç çalışan" adı verilen bir özellik sunar.
• CDN sağlayıcıları, sıkıştırma için optimizasyon yapma konusunda oldukça başarılıdır. Sıkıştırma işleminin kendi başınıza yapılması zordur ve dinamik olarak oluşturulan işaretlemeler nedeniyle belirli durumlarda yanıt sürelerinin uzayabilir. Bu işaretlemenin çalışma sırasında sıkıştırılması gerekir.
• CDN sağlayıcıları ayrıca, statik kaynaklar için sıkıştırılmış yanıtları otomatik olarak önbelleğe alır. Böylece, en iyi sıkıştırma oranı ve yanıt süresi karması elde edilir.

Bir CDN'nin benimsenmesi basitten önemliye doğru farklılık gösterse de, web sitenizde zaten böyle bir araç kullanılmıyorsa TTFB'nizi optimize ederken öncelikli olarak dikkate alınmalıdır.

Mümkün olduğunda önbelleğe alınmış içerik kullanıldı

CDN'ler, içeriğin uygun Cache-Control HTTP başlıklarıyla yapılandırılması koşuluyla, fiziksel olarak ziyaretçilere fiziksel olarak daha yakın olan uç sunucularda içeriğin önbelleğe alınmasına olanak tanır. Bu, kişiselleştirilmiş içerik için uygun olmasa da kaynağa tamamen geri gitmeyi gerektirmek CDN değerinin büyük bir kısmını olumsuz etkileyebilir.

İçeriğini sık sık güncelleyen sitelerde, kısa bir önbelleğe alma süresi bile yoğun siteler için kayda değer performans kazanımları sağlayabilir. Bunun nedeni, bu süre zarfında yalnızca ilk ziyaretçi kaynak sunucuya tam gecikmeyle karşılaşırken diğer tüm ziyaretçiler uç sunucuda önbelleğe alınmış kaynağı yeniden kullanabilir. Bazı CDN'ler, site sürümlerinde önbelleği geçersiz kılmaya izin verir. Bu sayede, uzun önbellek süreleri, gerektiğinde anında güncelleme yapılması gibi iki olanak da en iyi şekilde kullanılabilir.

Önbelleğe alma doğru şekilde yapılandırıldığında bile analiz ölçümü için benzersiz sorgu dizesi parametreleri kullanılarak bu durum yoksayılabilir. Bunlar, aynı olmalarına rağmen CDN'de farklı içerik gibi görünebilir ve bu nedenle, önbelleğe alınan sürüm kullanılmaz.

Daha eski veya daha az ziyaret edilen içerikler de önbelleğe alınamayabilir. Bu durum, bazı sayfalarda diğerlerine göre daha yüksek TTFB değerlerine neden olabilir. Önbelleğe alma sürelerini uzatmak bu durumun etkisini azaltabilir. Ancak, önbelleğe alma sürelerinin artması, eski olabilecek içerik sunma olasılığının da yükseldiğini unutmayın.

Ö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 yaygın nedenlerden biri yönlendirmelerdir. 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, yönlendirmeler gerçekleşir. Bir yönlendirme kesinlikle gezinme isteğine istenmeyen gecikme ekleyebilir. Ancak bu yönlendirme, başka bir yönlendirmeyle sonuçlanan başka bir kaynağa yönlendiriyorsa kesinlikle daha kötü hale gelebilir. Bu durum özellikle, reklamlar veya bültenlerden çok sayıda ziyaretçi alan siteleri etkileyebilir. Bunun nedeni, söz konusu siteler genellikle ölçüm amacıyla analiz hizmetleri üzerinden yönlendirmektedir. 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:

• Aynı kaynaklı yönlendirmeler: Yönlendirme tamamen web sitenizde gerçekleşir.
• Kaynaklar arası yönlendirmeler: Yönlendirmenin ilk olarak web sitenize ulaşmadan önce başka bir kaynakta (ör. bir sosyal medya URL'si kısaltma hizmetinden) gerçekleştiği.

Doğrudan denetime sahip olacağınız bir şey olduğu için, aynı kaynaktan gelen yönlendirmeleri kaldırmaya odaklanmak istersiniz. Herhangi birinin 302 veya 301 yanıt koduyla sonuçlanıp sonuçlanmadığını görmek için web sitenizdeki bağlantıları kontrol etmek de buna dahildir. Bu durum genellikle https:// şemasının eklenmemesinden (yani tarayıcılar varsayılan olarak http:// değerine ayarlanır ve ardından yönlendirme yapar) veya sondaki eğik çizgilerin URL'ye uygun şekilde dahil edilmediğinden ya da hariç tutulamamasından kaynaklanabilir.

Kaynaklar arası yönlendirmeler genellikle sizin kontrolünüzün dışında olduğu için daha karmaşıktır. Ancak mümkün olduğunda birden çok yönlendirmeden kaçınmaya çalışın. Örneğin, bağlantıları paylaşırken birden çok bağlantı kısaltma aracı kullanarak. Reklamverenlere veya bültenlere sağlanan URL'nin doğru nihai URL olduğundan emin olun. Böylece, bu hizmetler tarafından kullanılan adreslere başka bir yönlendirme eklenmemelidir.

Yönlendirme süresinin diğer önemli bir kaynağı da HTTP-HTTPS yönlendirmelerinden gelebilir. Bu sorunu aşmanın bir yolu, Strict-Transport-Security üst bilgisini (HSTS) kullanmaktır. HSTS, bir kaynağa yapılan ilk ziyarette HTTPS'yi zorunlu kılar ve sonraki ziyaretlerde tarayıcının, 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 yaptığınız ilk ziyarette işleri hızlandırabilirsiniz.

İşaretlemeyi tarayıcıya akışla gönder

Tarayıcılar, işaretleme akışı gerçekleştirildiğinde işaretlemeyi verimli bir şekilde işlemek için optimize edilmiştir, yani işaretleme, sunucudan geldikçe parçalar halinde işlenir. Bu, büyük işaretleme yüklerinin söz konusu olduğu durumlarda son derece önemlidir. Çünkü bu, ayrıştırma işlemi başlamadan önce tüm yanıtın gelmesini beklemek yerine, tarayıcının işaretleme parçalarını artımlı olarak ayrıştırabileceği anlamına gelir.

Tarayıcılar akış işaretlemesini işleme konusunda mükemmel olsalar da, bu ilk işaretleme parçalarının mümkün olan en kısa sürede yola çıkmalarını sağlamak amacıyla akışın akışta kalmasını sağlamak için elinizden geleni yapmak çok önemlidir. Arka uçta sorunlar ortaya çıkıyorsa bu bir sorundur. Arka uç yığınları çok sayıda olduğundan, her bir yığını ve her bir yığında ortaya çıkabilecek sorunları ele almak bu kılavuzun kapsamı dışındadır.

Örneğin React ve sunucuda istek üzerine işaretleme oluşturabilen diğer çerçeveler sunucu tarafı oluşturmaya eşzamanlı bir yaklaşım kullanmıştır. Bununla birlikte, React'in yeni sürümleri oluşturulurken akış işaretlemesi için sunucu yöntemleri uygulanmaktadır. Bu, gönderilmeden önce yanıtın tamamını oluşturmak için React sunucu API yönteminin kullanılması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 da, derleme sırasında HTML dosyaları oluşturan statik oluşturmayı kullanmaktır. Tam dosya anında kullanılabilir hale geldiğinde, web sunucuları dosyayı hemen göndermeye başlayabilir ve HTTP'nin doğası gereği akış işaretlemesi alınır. Bu yaklaşım, her web sitesindeki her sayfa için uygun olmasa da (kullanıcı deneyiminin bir parçası olarak dinamik yanıt gerektirenler gibi), işaretlemenin belirli bir kullanıcı için kişiselleştirilmesini gerektirmeyen sayfalar için faydalı olabilir.

Hizmet çalışanı kullanma

Service Worker API'nin, hem dokümanlar hem de yükledikleri kaynaklar için TTFB üzerinde büyük bir etkisi olabilir. Bunun nedeni, Service Worker'ın tarayıcı ile sunucu arasında bir proxy görevi üstlenmesidir. Ancak web sitenizin TTFB'si üzerinde bir etki olup olmadığı, 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 durum yeniden doğrulama stratejisi kullanın. Bir öğe, hizmet çalışanı önbelleğinde bulunuyorsa (belge veya belgenin gerektirdiği kaynak gibi) 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, yeniden doğrulama sırasında eski bir strateji kullanmak, bir sayfanın TTFB'sini neredeyse anında yapabilir. Bununla birlikte, web siteniz dinamik olarak oluşturulmuş işaretlemeler (ör. bir kullanıcının kimliğinin doğrulanıp doğrulanmadığına göre değişen işaretleme) gönderdiğinde bu yaklaşım pek işe yaramaz. Bu tür durumlarda, belgenin olabildiğince güncel olması için daima önce ağ üzerinden ilerlemeniz gerekir.
  • Dokümanınız belirli bir sıklıkta değişen kritik olmayan kaynaklar yüklüyor ancak eski kaynağı getirmek, örneğin belirli resimler veya kritik olmayan diğer kaynaklar gibi kullanıcı deneyimini büyük ölçüde etkilemeyecekse bu kaynaklara yönelik TTFB, eski bir yeniden doğrulama 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 "kabuğunun" Service Worker ö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 daha uygundur.

Oluşturma açısından kritik kaynaklar için 103 Early Hints kullanın

Uygulama arka ucunuz ne kadar iyi optimize edilmiş olursa olsun yine de sunucunun bir yanıt hazırlamak için yapması gereken önemli miktarda iş olabilir. Bu da gezinme yanıtının olabildiğince hızlı ulaşmasını geciktiren pahalı (ama gerekli) veritabanı işleri de olabilir. Bunun olası etkisi, sonraki oluşturma açısından kritik kaynakların (CSS veya bazı durumlarda, istemcide işaretlemeyi oluşturan JavaScript gibi) gecikebilmesidir.

103 Early Hints başlığı, arka uç işaretlemeyi hazırlamakla meşgulken sunucunun tarayıcıya gönderebileceği bir erken yanıt kodudur. Bu başlık, işaretleme hazırlanırken sayfanın indirilmeye başlaması gereken oluşturma açısından önemli kaynaklar olduğu konusunda tarayıcıya ipucu vermek için kullanılabilir. Tarayıcıları desteklemek için bunun etkisi, daha hızlı doküman oluşturma (CSS) ve temel sayfa işlevlerinin (JavaScript) daha hızlı kullanılabilir hale gelmesi olabilir.

Sonuç

Arka uç uygulama yığınlarının çok sayıda kombinasyonu olduğundan, web sitenizin TTFB'sini düşürmek için yapabileceğiniz her şeyi özetleyebilecek tek bir makale yoktur. Bununla birlikte, bu seçenekleri inceleyerek sunucu tarafında işleri biraz daha hızlandırabilirsiniz.

Her metriğin optimize edilmesinde 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 daha sonra mümkün olduğunda optimizasyonları uygulayın. Buradaki her teknik sizin durumunuz için uygun olmayabilir, ancak bazıları işe yarayacaktır. 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 ayarlamaları yapmanız gerekir.

Taylor Vick'in hero görseli. Unsplash'ten alındı.