Time to First Byte metriği için nasıl optimizasyon yapacağınızı öğrenin.
Yayınlanma tarihi: 19 Ocak 2023, Son güncelleme tarihi: 28 Kasım 2025
Time to First Byte (TTFB), First 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, kendisinden sonra gelen metriklere süre 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şik dahilinde bir FCP deneyimi yaşar. Genel bir kural olarak çoğu sitenin TTFB'si 0, 8 saniye veya daha kısa olmalıdır.
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 etkilendiği için TTFB'yi gözlemlemenin birincil kaynağı olarak alan verilerini kullanmanız gerekir. Laboratuvar tabanlı araçlar ise genellikle nihai URL kullanılarak ölçülür ve bu nedenle bu ek gecikmeyi kaçırır.
PageSpeed Insights, Chrome Kullanıcı Deneyimi Raporu'nda bulunan herkese açık web siteleri için hem alan hem de laboratuvar bilgilerini almanın bir yoludur.
Gerçek kullanıcılar için TTFB, en üstteki Gerçek kullanıcılarınızın neler deneyimlediğini keşfedin bölümünde gösterilir:
Laboratuvar verileri için TTFB sorunları, Doküman isteğiyle ilgili gecikme analizinde gösterilir:
Hem sahada hem de laboratuvarda TTFB'yi ölçmenin diğer yollarını öğrenmek için TTFB metrik sayfasını inceleyin.
Saha ve laboratuvar TTFB'si arasındaki farkları anlama
Laboratuvar ve alan TTFB'si çeşitli nedenlerle farklılık gösterebilir. Farklılık gösterdiğinde, kullanıcı deneyimlerinizi iyileştirmek için laboratuvar verilerini etkili bir şekilde kullanabilmek amacıyla nedenini anlamak önemlidir.
Laboratuvar TTFB'si, alan TTFB'sinden çok daha büyük olduğunda bu, laboratuvar ortamının tipik kullanıcı deneyimlerinden daha kısıtlı olduğunu gösterir. Laboratuvar sonuçları ve öneriler hâlâ geçerli olduğundan bu durum mutlaka bir sorun teşkil etmez ancak etkiyi ve iyileştirmeyi abartabilir.
Alan TTFB'si, laboratuvar TTFB'sinden çok daha büyük olduğunda bu durum, laboratuvar çalıştırmasında belirgin olmayan sorunları (ör. sunucu tarafı önbelleğe alma, yönlendirmeler veya ağ farklılıkları) gösterir. Bu durumda, ana sorunlardan biri gözden kaçırıldığı için laboratuvar sonuçları ve öneriler daha az faydalı olabilir.
Sunucu tarafı önbelleğe almanın laboratuvar TTFB'sini etkileyip etkilemediğini görmek için daha az yaygın sayfaları test etmeyi veya önbelleğe alınmamış içerik almak için farklı URL parametreleri kullanmayı deneyerek TTFB'nin alan TTFB'si ile daha uyumlu olup olmadığını kontrol edin. Belirli bir URL parametresiyle sunucu tarafı önbelleğe almayı atlayabilmeniz de yararlı olabilir. Önbelleğe alınan içerik bölümünü inceleyin.
Yönlendirmeler ve ağ farklılıkları için trafiğin sitemize nasıl ve nereden geldiğine dair analizler, bunların olası sorunlar olup olmadığını teşhis etmek için yararlı olabilir.
Server-Timing ile sahada yüksek TTFB'de hata ayıklama
Server-Timing yanıt başlığı, yüksek gecikmeye katkıda bulunabilecek farklı arka uç işlemlerini ölçmek için uygulama arka ucunuzda kullanılabilir. Üstbilgi 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 okunabilir bir açıklama (desc aracılığıyla) bulunur.
Serving-Timing, birçok uygulama arka uç işlemini ölçmek için kullanılabilir ancak özellikle dikkat etmek isteyebileceğiniz bazı işlemler vardır:
- Veritabanı sorguları
- Varsa sunucu tarafı oluşturma süresi
- Disk aramaları
- Uç sunucu önbellek isabetleri veya 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
Üstbilgi, uygulama arka ucunuzun 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 üstbilgi ayarlandığında hem laboratuvarda hem de sahada kullanabileceğiniz bilgiler gösterilir.
Saha verilerinde, Server-Timing yanıt başlığı ayarlanmış tüm sayfalar Navigation 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ığındaki veriler Chrome Geliştirici Araçları'ndaki Ağ sekmesinin Zamanlamalar panelinde görselleştirilir:
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.
Sunucu zamanlamaları, Chrome Geliştirici Araçları'ndaki Performans panelinin Ağ kanalında da gösterilir:
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 zorlu yönü, web'in ön uç yığınının her zaman HTML, CSS ve JavaScript olmasına rağmen arka uç yığınlarının önemli ölçüde değişiklik gösterebilmesidir. Her birinin kendi optimizasyon teknikleri olan çok sayıda arka uç yığını ve veritabanı ürünü vardır. Bu nedenle, bu kılavuzda yalnızca yığına özel rehberlik yerine çoğu mimari için geçerli olan konulara odaklanılmıştır.
Platforma özgü 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 kalitesinden veya kullanılan temalardan etkilenir. Platform özelleştirildiğinde diğer platformlar da benzer şekilde etkilenir. Bu yayındaki daha genel performans önerilerini tamamlayacak tedarikçiye özel öneriler için platformunuzun dokümanlarına bakmanız gerekir. Lighthouse analizi, yığına özel bazı sınırlı kılavuzlar da içerir.
Barındırma, barındırma, barındırma
Diğer optimizasyon yaklaşımlarını düşünmeden önce barındırma hizmetini değerlendirmeniz gerekir. Bu konuda sunulabilecek özel bir kılavuz yoktur ancak genel bir kural olarak web sitenizin barındırıcısının, gönderdiğiniz trafiği işleyebildiğinden emin olmanız gerekir.
Paylaşımlı barındırma genellikle daha yavaştır. Çoğunlukla statik dosyalar sunan küçük bir kişisel web siteniz varsa bu muhtemelen sorun teşkil etmez. TTFB'nizi mümkün olduğunca azaltmak için aşağıdaki optimizasyon tekniklerinden bazılarını kullanın.
Ancak kişiselleştirme, veritabanı sorgulama ve diğer yoğun sunucu tarafı işlemlerini içeren, çok sayıda kullanıcısı olan daha büyük bir uygulama çalıştırıyorsanız barındırma seçiminiz, alandaki TTFB'yi düşürmek için kritik hale gelir.
Barındırma sağlayıcısı seçerken dikkat etmeniz gereken bazı noktalar şunlardır:
- Uygulama örneğinize ne kadar bellek ayrıldı? Uygulamanızda yeterli bellek yoksa sayfaları olabildiğince hızlı sunmak için çabalar ve 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ının ve veritabanı yazılımlarının yeni sürümleri yayınlandıkça bu yazılımların performansı zaman içinde artar. Bu tür önemli bakım işlemlerine öncelik veren bir barındırma sağlayıcısıyla çalışmak çok ö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ı sorun.
Bu konularla sizin yerinize ilgilenen 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, 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 gerektiğinin bir işareti olabilir.
İçerik yayınlama ağı (CDN) kullanma
CDN kullanımı konusu çok sık ele alınır ancak bunun iyi bir nedeni vardır: Uygulama arka ucunuz çok iyi optimize edilmiş olsa bile kaynak sunucunuzdan uzakta bulunan kullanıcılar sahada yüksek TTFB ile karşılaşabilir.
CDN'ler, kaynak sunucunuzun kullanıcılara olan uzaklığı sorununu, kaynakları kullanıcılarınıza fiziksel olarak daha yakın olan sunucularda önbelleğe alan dağıtılmış bir sunucu ağı kullanarak çözer. Bu sunuculara uç sunucular denir.
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, içeriğinizi HTTP/2 veya HTTP/3 gibi modern protokolleri kullanan uç sunuculardan sunar.
- Özellikle HTTP/3, UDP protokolünü kullanarak TCP'de (HTTP/2'nin kullandığı) mevcut olan satır başı engelleme sorununu çözer.
- CDN'ler genellikle TLS'nin modern sürümlerini sunar. Bu da TLS anlaşma süresindeki gecikmeyi azaltır. Özellikle TLS 1.3, TLS anlaşmasını mümkün olduğunca kısa tutacak şekilde tasarlanmıştır.
- Bazı CDN sağlayıcıları, istekleri yakalamak, uç önbelleklerdeki yanıtları programatik olarak yönetmek veya yanıtları tamamen yeniden yazmak için Service Worker API'ye benzer bir API kullanan ve genellikle "uç çalışan" olarak adlandırılan bir özellik sunar.
- CDN sağlayıcıları, sıkıştırma için optimizasyon konusunda çok başarılıdır. Sıkıştırma işlemini kendi başınıza doğru şekilde yapmak zordur ve dinamik olarak oluşturulan işaretlemelerin anında sıkıştırılması gereken bazı durumlarda yanıt sürelerinin uzamasına neden olabilir.
- Ayrıca CDN sağlayıcılar, statik kaynaklar için sıkıştırılmış yanıtları otomatik olarak önbelleğe alır. Bu da sıkıştırma oranı ile yanıt süresinin en iyi şekilde birleştirilmesini sağlar.
CDN kullanmaya başlamak için gereken çaba önemsizden önemliye kadar değişebilir. Ancak web siteniz henüz CDN kullanmıyorsa TTFB'nizi optimize etmek için CDN kullanmaya başlamak yüksek öncelikli olmalıdır.
Mümkün olduğunda önbelleğe alınmış içerikleri kullanma
CDN'ler, içeriğin uygun Cache-Control HTTP üstbilgileriyle yapılandırılması koşuluyla, 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ğa kadar geri gitmeyi gerektirmesi, CDN'nin değerinin büyük bir kısmını ortadan kaldırabilir.
İçeriklerini sık sık güncelleyen sitelerde, kısa bir önbelleğe alma süresi bile yoğun siteler için fark edilir performans artışları sağlayabilir. Bunun nedeni, yalnızca bu süre zarfındaki ilk ziyaretçinin kaynak sunucuya kadar olan gecikmeyi tam olarak yaşaması, diğer tüm ziyaretçilerin ise uç sunucudaki önbelleğe alınmış kaynağı yeniden kullanabilmesidir. Bazı CDN'ler, site sürümlerinde önbellek geçersiz kılmaya izin vererek her iki dünyanın da en iyi özelliklerini sunar: uzun önbellek süreleri ve gerektiğinde anında güncellemeler.
Önbelleğe alma doğru şekilde yapılandırılmış olsa bile analiz ölçümü için benzersiz sorgu dizesi parametreleri kullanılarak bu durum göz ardı edilebilir. Bunlar, aynı olmalarına rağmen CDN'ye farklı içerik gibi görünebilir ve bu nedenle önbelleğe alınmış sürüm kullanılmaz.
Eski veya daha az ziyaret edilen içerikler de önbelleğe alınmayabilir. Bu durum, bazı sayfalarda diğerlerine kıyasla daha yüksek TTFB değerlerine neden olabilir. Önbelleğe alma sürelerini artırmak bu sorunun etkisini azaltabilir ancak önbelleğe alma süreleri arttıkça eski içerik sunma olasılığının da artacağını unutmayın.
Önbelleğe alınan içeriğin etkisi yalnızca CDN kullananları etkilemez. Önbelleğe alınmış 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 TTFB'nin yaygın nedenlerinden 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. Tek bir yönlendirme, gezinme isteğine kesinlikle istenmeyen gecikme ekleyebilir ancak bu yönlendirme başka bir yönlendirmeyle sonuçlanan başka bir kaynağa işaret ederse durum daha da kötüleşebilir. Bu durum, özellikle reklamlar veya bültenler aracılığıyla yüksek hacimli ziyaretçi alan siteleri etkileyebilir. Çünkü bu siteler genellikle ölçüm amacıyla analiz hizmetleri üzerinden yönlendirme yapar. 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ı kaynak yönlendirmeleri: Yönlendirmenin tamamen web sitenizde gerçekleştiği durumlardır.
- Yönlendirmenin web sitenize ulaşmadan önce başka bir kaynakta (ör. sosyal medya URL kısaltma hizmeti) gerçekleştiği çapraz kaynak yönlendirmeleri.
Doğrudan kontrolünüzde olan bir konu olduğu için aynı kaynağa yönlendirmeleri ortadan kaldırmaya odaklanın. Bu, web sitenizdeki bağlantıları kontrol ederek 302 veya 301 yanıt kodu döndürüp döndürmediklerini görmeyi içerir. Bu durum genellikle https:// şemasının dahil edilmemesinden (bu nedenle tarayıcılar varsayılan olarak http:// şemasına geçer ve ardından yönlendirme yapar) veya URL'ye sağa eğik çizgilerin uygun şekilde dahil edilmemesinden ya da hariç tutulmamasından kaynaklanabilir.
Çapraz kaynak yönlendirmeleri genellikle kontrolünüz dışında olduğundan daha zordur 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ı kullanın. Reklamverenlere veya bültenlere sağlanan URL'nin doğru nihai URL olduğundan emin olun. Böylece, bu hizmetler tarafından kullanılan yönlendirmelere başka bir yönlendirme eklenmez.
Yönlendirme süresinin bir diğer önemli kaynağı da HTTP'den HTTPS'ye yönlendirmeler olabilir. Bu sorunu aşmanın bir yolu, bir kaynağa ilk ziyarette HTTPS'yi zorunlu kılan ve ardından tarayıcıya gelecekteki ziyaretlerde kaynağa HTTPS şeması üzerinden hemen erişmesini söyleyen Strict-Transport-Security üst bilgisini (HSTS) kullanmaktır.
İyi bir HSTS politikanız olduğunda, sitenizi HSTS önceden yükleme listesine ekleyerek bir kaynağa ilk ziyarette işleri hızlandırabilirsiniz.
Tarayıcıya işaretleme akışı yapma
Tarayıcılar, işaretlemeyi akış sırasında verimli bir şekilde işleyecek şekilde optimize edilmiştir. Yani işaretleme, sunucudan geldiği gibi parçalar halinde işlenir. Bu, büyük işaretleme yükleri söz konusu olduğunda çok önemlidir. Çünkü tarayıcı, ayrıştırma işleminin başlayabilmesi için tüm yanıtın gelmesini beklemek yerine işaretleme parçalarını kademeli olarak ayrıştırabilir.
Tarayıcılar, akış işaretlemelerini işleme konusunda başarılı olsa da akışın devam etmesini sağlamak için elinizden geleni yapmanız çok önemlidir. Böylece, ilk işaretleme parçaları mümkün olan en kısa sürede gönderilir. Arka uç, işlemleri geciktiriyorsa bu bir sorundur. Arka uç yığınları çok sayıda olduğundan, her bir yığını ve her birinde ortaya çıkabilecek sorunları ele almak bu kılavuzun kapsamı dışında kalır.
Örneğin, React 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şım kullanmıştır. Ancak React'in daha yeni sürümlerinde, oluşturulurken işaretlemeyi akışla aktarmak için sunucu yöntemleri uygulanmıştır. Bu sayede, bir React sunucu API'si yönteminin tüm yanıtı oluşturmasını beklemeniz gerekmez.
İş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şturma yöntemini kullanmaktır. Dosyanın tamamı hemen kullanılabilir olduğundan web sunucuları dosyayı hemen göndermeye başlayabilir ve HTTP'nin doğası gereği işaretleme akışı gerçekleşir. Bu yaklaşım, her web sitesindeki her sayfa için (ör. kullanıcı deneyiminin bir parçası olarak dinamik yanıt gerektiren sayfalar) uygun olmasa da işaretlemenin belirli bir kullanıcıya göre kişiselleştirilmesini gerektirmeyen sayfalar için faydalı olabilir.
Hizmet çalışanı kullanma
Service Worker API, hem belgeler hem de yükledikleri kaynaklar için TTFB üzerinde büyük bir etkiye sahip olabilir. Bunun nedeni, hizmet çalışanının tarayıcı ile sunucu arasında proxy görevi görmesidir. Ancak web sitenizin TTFB'si üzerinde bir etki olup olmayacağı, hizmet çalışanınızı nasıl ayarladığınıza ve bu ayarın uygulama gereksinimlerinize uygun olup olmadığına bağlıdır.
- Öğeler için stale-while-revalidate stratejisi kullanın. Bir öğe (doküman veya dokümanın gerektirdiği bir kaynak) hizmet çalışanı önbelleğindeyse stale-while-revalidate stratejisi, bu kaynağı önce önbellekten sunar, ardından arka planda indirir ve gelecekteki etkileşimler için önbellekten sunar.
- Çok sık değişmeyen belge kaynaklarınız varsa stale-while-revalidate stratejisi kullanmak, bir sayfanın TTFB'sini neredeyse anında yapabilir. Ancak web siteniz, kullanıcının kimliğinin doğrulanıp doğrulanmadığına göre değişen işaretleme gibi dinamik olarak oluşturulan işaretlemeler gönderiyorsa bu yöntem pek işe yaramaz. Bu gibi durumlarda, belgenin mümkün olduğunca güncel olması için her zaman önce ağa erişmek istersiniz.
- Dokümanınız, 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ın TTFB'si, stale-while-revalidate 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" 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 tek sayfalık uygulamalar için en uygun modeldir.
Oluşturma için kritik kaynaklarda 103 Early Hints kullanın
Uygulamanızın arka ucu ne kadar iyi optimize edilmiş olursa olsun, sunucunun yanıt hazırlamak için yapması gereken önemli miktarda iş olabilir. Bu işler arasında, gezinme yanıtının mümkün olduğunca hızlı gelmesini geciktiren pahalı (ancak gerekli) veritabanı işlemleri de yer alır. Bunun olası etkisi, oluşturma açısından kritik olan bazı kaynakların (ör. CSS veya bazı durumlarda istemcide işaretleme oluşturan JavaScript) gecikebilmesidir.
103 Early Hints başlığı, arka uç işaretlemeyi hazırlamakla meşgulken sunucunun tarayıcıya gönderebileceği erken bir yanıt kodudur. Bu başlık, işaretleme hazırlanırken sayfanın indirmeye başlaması gereken, oluşturma açısından kritik kaynaklar olduğunu tarayıcıya bildirmek için kullanılabilir. Destekleyen tarayıcılarda, doküman oluşturma (CSS) ve sayfa yükleme daha hızlı olabilir.
103 Erken İpuçları'nın bir dezavantajı, önbelleğe alma gibi bir sitenin "gerçek" TTFB'sini maskeleyebilmesidir. Sunucu altyapısı yavaşsa (yetersiz olduğu veya kodun optimize edilmesi gerektiği için) 103 Erken İpuçları kullanıldığında TTFB hızlı göründüğü için bu durum daha az belirgin olabilir. 103 Early Hints kullanan siteler, gerçek sunucu süresini ölçmeyi düşünmelidir (PerformanceNavigationTiming API'nin Server-Timing veya finalResponseHeadersStart aracılığıyla).
Sonuç
Çok sayıda arka uç uygulama yığını 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şleri biraz daha hızlandırmak için deneyebileceğiniz bazı seçenekler vardır.
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. Bazı teknikler sizin durumunuz için uygun olmasa da bazıları muhtemelen uygundur. Her zaman olduğu gibi, saha verilerinizi yakından takip etmeniz ve mümkün olan en hızlı kullanıcı deneyimini sağlamak için gereken ayarlamaları yapmanız gerekir.