Gecikme (Latency) Nedir? Siteniz Neden Yavaş Açılıyor?

Gecikme (latency), bir isteğin ziyaretçinin cihazından sunucuya gidip cevabın geri gelmesi için geçen süredir ve milisaniye (ms) ile ölçülür. Gecikme nedir sorusunun işletme açısından cevabı şu: Ziyaretçinizin interneti ne kadar hızlı olursa olsun, her istek bir yol kat eder ve bu yolun süresi sitenizin "ilk açılış" hissini belirler. Bu yazıda gecikmenin nereden geldiğini, bant genişliğinden farkını ve sitenizde neleri iyileştirebileceğinizi anlatıyoruz.

Gecikme nedir?

MDN'nin tanımına göre gecikme, bir veri paketinin kaynaktan hedefe ulaşması için geçen süredir. Web'de genellikle gidiş-dönüş süresi (round-trip time, RTT) olarak ölçülür: Tarayıcı bir istek gönderir, sunucu cevap verir ve bu cevabın ilk parçası tarayıcıya ulaşır.

Bilgisayarınızda ping alanadi.com komutunu çalıştırdığınızda gördüğünüz "time=… ms" değeri bu gidiş-dönüş süresinin basit bir ölçümüdür. Yani düşük değer, isteklerin hızlı gidip geldiği anlamına gelir.

Gecikmenin bir de "kardeş" kavramı vardır: jitter. Kısaca jitter, gecikme süresindeki dalgalanmadır. Paketler bazen 20 ms'de, bazen çok daha geç geliyorsa bağlantı düzensizdir. Web sayfalarında jitter'ın etkisi sınırlıdır; görüntülü görüşme ve canlı yayında ise takılma olarak hissedilir.

Gecikme ile bant genişliği arasındaki fark

Bu iki kavram çoğunlukla birbirine karışır. Basit bir benzetmeyle:

• Bant genişliği, yolun kaç şeritli olduğudur: Aynı anda ne kadar veri taşınabileceğini belirler (Mbps).
• Gecikme, bir aracın A noktasından B noktasına ne kadar sürede gittiğidir.

Yolu on şeride çıkarmak, aracın İstanbul'dan Londra'ya varış süresini kısaltmaz. İnternette de durum aynıdır. Ilya Grigorik'in High Performance Browser Networking kitabında vurguladığı gibi, çoğu web sitesi için performansı sınırlayan şey bant genişliği değil, gecikmedir. Çünkü bir web sayfası tek büyük bir dosya değil, çok sayıda küçük istekten oluşur: HTML, CSS, JavaScript, fontlar, görseller. Dolayısıyla her istekte gidiş-dönüş süresini tekrar ödersiniz.

Gecikme nereden gelir?

Bir isteğin süresi tek bir kaynaktan değil, birkaç parçanın toplamından oluşur.

1. Fiziksel mesafe

Veri, fiber optik kablolarda ışık hızına yakın ama ondan daha yavaş ilerler: yaklaşık saniyede 200.000 km. High Performance Browser Networking kitabındaki hesaplara göre New York ile Londra arasındaki gidiş-dönüş, en ideal fiber hatta bile yaklaşık 56 ms sürer. Gerçek hayatta kablolar düz bir çizgi izlemediği ve paketler birçok ara cihazdan geçtiği için süre bunun üzerine çıkar. Bu nedenle ziyaretçileriniz Türkiye'deyken sunucunuzun başka bir kıtada olması, her istekte fark edilir bir süre ekler.

2. Ara cihazlar ve "son kilometre"

Paketler yol boyunca yönlendiricilerden geçer. Üstelik her cihaz paketi işler, gerekirse kuyrukta bekletir. Ev ya da ofis internetinin operatör ağına bağlandığı ilk bölüm ("son kilometre") da tek başına onlarca milisaniye ekleyebilir. Mobil bağlantılarda bu pay genellikle daha yüksektir.

3. Bağlantı kurma adımları

Bir siteye ilk kez bağlanırken tarayıcı veri istemeden önce bazı hazırlıklar yapar:

1. DNS sorgusu: Alan adının IP adresini bulur (bkz. DNS nedir?).
2. TCP bağlantısı: Sunucuyla "el sıkışır".
3. TLS el sıkışması: HTTPS için şifreli bağlantıyı kurar (bkz. HTTP ve HTTPS farkı).

MDN'nin belirttiği gibi ilk istekte gecikme daha uzundur; çünkü DNS sorgusu, TCP el sıkışması ve TLS anlaşması bu süreye dahildir. Buna karşılık bağlantı kurulduktan sonraki istekler daha hızlı gelir. Bu yüzden sayfanızın kaç farklı alan adından (fontlar, analiz araçları, sohbet eklentileri, harici scriptler) kaynak çektiği önemlidir: Her yeni alan adı ayrı bir DNS sorgusu ve ayrı bir bağlantı demektir.

TLS 1.3 sürümü bağlantı kurulumunu önceki sürüme göre kısaltmak için tasarlanmıştır. Sunucunuzun güncel TLS sürümünü desteklemesi bu yüzden yalnız güvenlik değil, hız konusudur.

4. Sunucunun cevap hazırlama süresi

İstek sunucuya ulaştıktan sonra sunucu sayfayı hazırlar: WordPress gibi bir sistemde PHP çalışır, veritabanı sorgulanır, HTML üretilir. Bu süre ağ gecikmesi değildir ama kullanıcı açısından aynı bekleme olarak hissedilir. Bu nedenle yavaş bir sunucu, yakın bir veri merkezinin avantajını yok edebilir.

5. Yönlendirmeler

http:// adresinden https://'e, oradan www'li adrese, oradan da dil klasörüne giden bir zincir, her adımda yeni bir gidiş-dönüş demektir. web.dev'in TTFB rehberi yönlendirmeleri ilk bayt süresini uzatan yaygın nedenlerden biri olarak sayar.

Gecikme web sitenizi ve işinizi nasıl etkiler?

Gecikmenin en doğrudan ölçüsü TTFB'dir (Time to First Byte, ilk bayta kadar geçen süre). TTFB; yönlendirmeleri, DNS sorgusunu, bağlantı ve TLS kurulumunu ve sunucunun ilk cevabı göndermesine kadar geçen süreyi kapsar. web.dev, kaba bir hedef olarak çoğu sitenin TTFB değerini 0,8 saniye veya altında tutmaya çalışması gerektiğini belirtir.

TTFB tek başına bir Core Web Vitals metriği değildir. Ama sayfanın ana içeriğinin görünme süresi olan LCP'nin önünde durur: İlk bayt geç gelirse, geri kalan her şey de geç başlar. Core Web Vitals'ı ayrıntılı anlattığımız yazıya buradan ulaşabilirsiniz.

İşletme açısından sonucu basittir: Ziyaretçi, sayfa açılırken boş ekrana ne kadar uzun bakarsa sitenizden o kadar kolay ayrılır. Özellikle mobil bağlantıyla, sahada ya da yolda sitenize giren müşteriler gecikmeyi daha çok hisseder.

Gecikmeyi nasıl azaltabilirsiniz?

Mesafeyi ve ışık hızını değiştiremezsiniz, ama gecikmenin etkisini azaltabilirsiniz.

• Sunucu konumunu ziyaretçinize göre seçin. Müşterilerinizin çoğu Türkiye'deyse, hosting ya da sunucu seçerken veri merkezinin konumunu sorun. Hosting türlerini Hosting nedir? yazımızda anlattık.
• İçerik dağıtım ağı (CDN) kullanmayı değerlendirin. CDN, sitenizin statik dosyalarının kopyalarını ziyaretçiye yakın sunucularda tutar. Özellikle ziyaretçileriniz farklı ülkelere dağılmışsa etkisi belirgindir. web.dev, uzaktaki kullanıcıların yüksek TTFB yaşayabileceğini ve CDN kullanmayan siteler için bunun öncelikli bir iyileştirme olduğunu belirtir.
• Sayfa önbelleği kullanın. Sunucunun her ziyarette sayfayı yeniden üretmesi yerine hazır kopyayı göndermesi, sunucu tarafındaki bekleme süresini kısaltır.
• Yönlendirme zincirlerini kısaltın. Site içi bağlantılarınız doğrudan son adrese (ör. https://www…) gitsin.
• Harici alan adlarını azaltın. Kullanmadığınız takip kodlarını, eklentileri ve harici fontları temizleyin; gerekli olanları mümkünse kendi sunucunuzdan servis edin.
• İstek sayısını azaltın. Gereksiz scriptler ve büyük ama kullanılmayan dosyalar, her biri için ayrı bekleme demektir.

Sık yapılan hatalar

• "İnternet paketimiz hızlı, sorun bizde değil" demek. Hız testi bant genişliğini ölçer. Siteniz başka bir kıtadaki sunucudaysa hızlı bağlantı gecikmeyi ortadan kaldırmaz.
• Yalnız kendi bilgisayarından test etmek. Siz sitenizi önbellekten, ofisin kablolu ağından görüyor olabilirsiniz. Oysa mobil ağdaki bir ziyaretçinin deneyimi farklıdır.
• Önbelleğin yavaş sunucuyu gizlemesini fark etmemek. web.dev'in uyardığı gibi önbellek, yavaş bir arka ucu maskeleyebilir. Önbelleğe alınmayan sayfalar (sepet, form sonrası sayfalar, giriş yapmış kullanıcılar) yavaş kalabilir.
• Her yeni eklentiyi "küçük bir kod" diye eklemek. Her harici script, yeni bir alan adı ve yeni bir bağlantı anlamına gelebilir.

Bizim deneyimimiz

Kendi sitemiz artsution.com.tr, LiteSpeed sunucu üzerinde LiteSpeed Cache eklentisiyle çalışıyor. Mobil PageSpeed sonuçlarını iyileştirirken CSS dosyalarını birleştirdik, fontları harici bir servisten çekmek yerine yerel olarak sunduk ve Türkçe karakterler için küçük font alt kümeleri hazırladık. Böylece sayfanın ihtiyaç duyduğu harici bağlantı ve istek sayısını azalttık.

Bir de ders çıkardık: LiteSpeed Cache'teki "Konuk İyileştirme" (guest optimization) seçeneği JavaScript'i ilk etkileşime kadar geciktirebiliyor. Bu, ölçüm araçlarında iyi görünse de menü ve formların ilk dokunuşta çalışmamasına yol açabiliyor. Bu yüzden bu seçeneği kapalı tutuyoruz. Gecikmeyi azaltırken ziyaretçinin gerçek deneyimini bozmamak gerekiyor.

Sık sorulan sorular

Sonuç

Gecikme, sitenizin "hızlı internete rağmen neden geç açıldığı" sorusunun çoğu zaman cevabıdır. Mesafeyi, bağlantı adımlarını ve sunucunun cevap süresini birlikte ele aldığınızda iyileştirme yapılacak noktalar netleşir: doğru sunucu konumu, önbellek, kısa yönlendirme zincirleri ve az sayıda harici kaynak.

Sitenizin neden yavaş açıldığını birlikte incelemek isterseniz web tasarım ve WordPress geliştirme hizmetlerimize göz atabilir ya da bize ulaşabilirsiniz.