Web site hızı neden yalnızca “kaç saniyede açılıyor?” değildir?
Bir sayfanın performansı tek bir süreyle açıklanamaz. Kullanıcının isteğinin sunucuya ulaşması, sunucunun ilk byteı üretmesi, HTML içinden kaynakların keşfedilmesi, CSS ve JavaScriptin işlenmesi, ana içeriğin görünmesi ve sayfanın görsel olarak kararlı hale gelmesi farklı aşamalardır. Bu yüzden performans optimizasyonunda TTFB ve Core Web Vitals gibi farklı sinyalleri birlikte değerlendirmek gerekir.
TTFB nedir?
TTFB, bir HTTP isteğinden sonra ilk byteın istemciye ulaşmasına kadar geçen süreyi ifade eder. Sunucu işlem süresi, veritabanı sorguları, cache durumu, ağ gecikmesi ve proxy/CDN katmanları bu süreyi etkileyebilir. Yüksek TTFB çoğu zaman HTML içeriğinin kullanıcıya geç ulaşmasına ve sonraki render aşamalarının da gecikmesine neden olur.
TTFB Checker ile farklı URLleri karşılaştırabilir, ardından sunucu cache ve CDN davranışını inceleyebilirsiniz.
Core Web Vitals: LCP, INP ve CLS
- LCP: Sayfadaki ana içeriğin görünür hale gelme performansını anlamaya yardımcı olur. Büyük hero görseli, yavaş HTML, render-blocking kaynaklar ve sunucu gecikmesi etkili olabilir.
- INP: Kullanıcı etkileşimlerine verilen yanıtın ne kadar hızlı olduğunu ölçer. Ağır JavaScript, uzun görevler ve gereksiz üçüncü taraf scriptleri önemli nedenler arasındadır.
- CLS: Sayfanın yüklenirken beklenmedik şekilde yer değiştirmesini ölçer. Boyutu belirtilmemiş görseller, reklam alanları ve sonradan eklenen bileşenler sık görülen sebeplerdir.
Görselleri optimize etmek
Web sitelerindeki yüksek dosya boyutunun önemli bir bölümü görsellerden gelir. Gereksiz büyük JPEG/PNG dosyaları yerine kullanım senaryosuna uygun modern formatlar, doğru çözünürlük, responsive image kullanımı ve lazy loading tercih edilebilir. Ancak kritik ilk ekran görsellerini düşünmeden lazy-load etmek LCP performansını kötüleştirebilir; optimizasyon her kaynak için aynı şekilde uygulanmamalıdır.
Cache ve CDN performansı nasıl etkiler?
Tekrar ziyaretlerde statik dosyaların tarayıcı veya CDN cacheinden sunulması origin sunucusuna gelen istekleri azaltabilir. Cache-Control, ETag, Last-Modified ve CDN cache davranışı bu sistemin temel parçalarıdır. HTML için kısa veya kontrollü cache, fingerprint edilmiş CSS/JS dosyaları için uzun cache politikaları birçok projede iyi bir başlangıçtır.
Cache Checker ve CDN Checker ile HTTP yanıtlarını ve CDN kullanımını inceleyebilirsiniz.
JavaScript neden siteyi yavaşlatabilir?
JavaScript dosyalarının sayısı kadar çalışma maliyeti de önemlidir. Büyük bundlelar, senkron scriptler, gereksiz kütüphaneler ve uzun ana thread görevleri etkileşim performansını düşürebilir. Sadece dosyayı küçültmek yeterli değildir; kullanılmayan kodu kaldırmak, code splitting yapmak ve kritik olmayan scriptleri geciktirmek daha etkili olabilir.
Sunucu tarafında yapılabilecek optimizasyonlar
- Dinamik sayfalar için uygulama ve veritabanı sorgularını profilleyin.
- Object cache veya uygun uygulama cache mekanizmalarını değerlendirin.
- HTTP/2 veya HTTP/3 desteğinin CDN/origin mimarinizle uyumlu olduğunu kontrol edin.
- Sık kullanılan statik içerikleri CDN üzerinden sunun.
- Gzip veya Brotli sıkıştırmasını doğru MIME türleri için etkinleştirin.
- TLS, DNS ve ağ gecikmesini de performans zincirinin parçası olarak değerlendirin.
Performans testi nasıl yapılmalı?
Tek bir test sonucuna bakıp “site hızlı” veya “site yavaş” demek yanıltıcı olabilir. Aynı URLyi farklı zamanlarda, farklı ağlarda ve mümkünse hem cacheli hem cachesiz senaryoda test edin. TTFB, toplam kaynak sayısı, sayfa boyutu, render aşamaları ve kullanıcı etkileşimi birlikte değerlendirilmelidir.
Başlangıç için Speed Test, Page Size, Compression Test ve Core Web Vitals araçlarını bir kontrol zinciri olarak kullanabilirsiniz.
Sonuç
Web site hızlandırma bir “tek ayar” işi değildir. Sunucu yanıtı, DNS, CDN, cache, görseller, CSS, JavaScript ve kullanıcı etkileşimleri birbirini etkiler. En iyi sonuç, önce ölçüp sonra en büyük darboğazı hedefleyen küçük ve doğrulanabilir değişikliklerle alınır.
Üçüncü taraf scriptler performansı nasıl etkiler?
Analytics, chat widgetları, reklam scriptleri, heatmap araçları ve sosyal medya bileşenleri tek tek küçük görünse de toplamda ana thread ve network üzerinde önemli yük oluşturabilir. Kullanılmayan scriptleri kaldırmak, kritik olmayanları geciktirmek ve gerçekten iş değeri üretmeyen üçüncü tarafları azaltmak çoğu projede ücretsiz bir performans kazanımıdır.
Mobil performans neden ayrı ele alınmalı?
Güçlü masaüstü donanımıyla yapılan testler gerçek mobil deneyimi temsil etmeyebilir. Mobil cihazlarda CPU, ağ ve ekran koşulları farklıdır. Bu yüzden performans optimizasyonunda yalnızca hızlı masaüstü bağlantısına göre karar vermek yerine gerçek kullanıcı verileri ve mobil senaryolar da değerlendirilmelidir.
Performans optimizasyonunda doğru öncelik
Her küçük optimizasyon aynı değerde değildir. Önce TTFBsi yüksek sayfaları, büyük görselleri, renderı engelleyen kaynakları ve uzun JavaScript görevlerini belirleyin. Sonra değişiklik yapıp yeniden ölçün. Ölçmeden yapılan optimizasyonlar zaman kaybettirebilir ve bazen performansı daha da karmaşık hale getirebilir.
Sayfa boyutu ile hız aynı şey değildir
İki sayfanın aynı toplam byte miktarına sahip olması aynı kullanıcı deneyimini garanti etmez. Bir sayfa çok büyük bir görseli geç yüklerken diğeri daha küçük ama bloklayıcı JavaScript çalıştırabilir. Bu nedenle kaynak boyutlarını waterfall sırası, öncelik ve kullanıcı etkileşimiyle birlikte değerlendirmek gerekir.
Performans bütçesi oluşturun
Projeye toplam JavaScript, CSS, görsel ve üçüncü taraf kaynakları için basit bütçeler koymak regresyonları erken yakalar. Yeni bir özellik bu bütçeyi aşıyorsa ekip, özelliğin gerçekten gerekli olup olmadığını veya başka bir kaynağın kaldırılıp kaldırılamayacağını tartışabilir.