Neden "Hız Testi" Butonuna Bastınız ve Siteniz Hâlâ Yavaş?
Şu an sitenizden bir hız testi yapın. Muhtemelen 100 üzerinden 40 ile 70 arasında bir sayı görürsünüz ve rapor "görselleri sıkıştırın" veya "JavaScript'i erteleyin" der. Bu öneriler doğrudur, ancak sıralamaları yanlıştır. Zincirin hiç de darboğaz olmayan halkalarına saldırıyorsunuz.
Site hızı bir sayı değil, bir zincirdir. Kullanıcının adresi yazdığı andan sayfanın tamamen render edildiği ana kadar en az yedi halka vardır: DNS, TCP/TLS bağlantısı, HTML teslimi, CSS yükleme, JavaScript çalıştırma, görsel ve font alma ve son olarak nihai render. Her halka birkaç milisaniye sürer, ancak kullanıcı deneyimini oluşturan bunların toplamıdır.
Çoğu site yöneticisi yalnızca son iki halkayı görür ve gerisini görmezden gelir. Bu maliyetli bir hatadır.
Hız Zinciri: Her Halka Kaç Milisaniye Sürer?
Gerçek rakamlarla konuşalım. Bu değerler laboratuvar sayıları değil, pratikte gördüğüm ortalamalardır:
| Halka | Olağan Süre | Optimum Süre |
|---|---|---|
| DNS Lookup | 20–80 ms | 5–15 ms |
| TCP + TLS El Sıkışması | 50–150 ms | 30–60 ms |
| TTFB (İlk Bayta Kadar Geçen Süre) | 300–800 ms | 100–200 ms |
| CSS Yükleme | 100–400 ms | 50–100 ms |
| JavaScript Çalıştırma | 300–1500 ms | 100–300 ms |
| Görseller ve Fontlar | 500–2000 ms | 200–500 ms |
| Nihai Render | 100–300 ms | 50–100 ms |
Bu değerlerin toplamı kötü senaryoda 3,5 saniyeye ulaşır. Google, mobil ziyaretlerin %53'ünün 3 saniyeden uzun yükleme sürelerinde terk edildiğini söylüyor. Bu sayıyı ciddiye alın.
İlk Halka: DNS — Herkesin Unuttuğu Yer
Sitenizden tek bir bayt gönderilmeden önce, tarayıcı alan adını IP'ye çevirmelidir. DNS'iniz yüksek TTL (Time To Live) ve zayıf bir Nameserver ile yapılandırılmışsa, bu halka 80 milisaniye harcar.
Kontrol etmek için dig +trace example.com komutunu kullanın ve her adımın ne kadar sürdüğünü görün. Nameserver'ınızdan gelen yanıt 50 milisaniyenin üzerindeyse sorun var demektir. Çözüm: Anycast ile DNS seçin ve ana kayıtlar için TTL'yi 86400 değil, 300 saniye olarak ayarlayın.
İkinci Halka: TTFB — Barındırmanın Karar Verdiği Yer
TTFB, tarayıcı isteği ile ilk yanıt baytının alınması arasındaki süredir. Bu sayı doğrudan işlemci gücüne, disk türüne ve web sunucusu ayarlarınıza bağlıdır. TTFB'niz 300 milisaniyenin üzerindeyse sorun kodunuzda değil, altyapınızdadır.
curl -w "TTFB: %{time_starttransfer}s\n" -o /dev/null https://example.com komutuyla tam olarak ölçün. Sayı yüksekse önce PHP-FPM'yi kontrol edin: pm.max_children değerini her işlemin bellek kullanımına göre ayarlayın. Basit formül: toplam bellek bölü her PHP işleminin belleği. Her işlem 128MB kullanıyorsa ve sunucuda 4GB RAM varsa, pm.max_children = 30.
İnsanların hata yaptığı yer burası: TTFB yüksek görünce görsel sıkıştırmaya yöneliyorlar. Sonuç? Sıfır. Görseller TTFB'den sonra yüklenir ve onu hiç etkilemez. Önce altyapıyı düzeltin, sonra varlık optimizasyonuna geçin.
Maliyet-Etki Oranına Göre Önceliklendirme
Sınırlı zamanınız ve bütçeniz var. Yaptığınız her işlem en düşük maliyetle en yüksek etkiyi sağlamalıdır. Şu sıralamayı öneriyorum:
- HTTP/2 ve Brotli'yi Etkinleştirme — Web sunucusu ayarlarında tek bir değişiklik, aktarım boyutunda %20-30 azalma. Maliyet: 15 dakika.
- Cache-Control ile Tarayıcı Önbelleği — Geri dönen ziyaretçiler için yükleme süresinde %50 azalma. Maliyet: 10 dakika.
- WebP ile Görsel Optimizasyonu — Belirgin kalite kaybı olmadan görsel boyutunda %30-70 azalma. Maliyet: bir saat.
- Gereksiz JavaScript'i Kaldırma — Mümkün olan en büyük kazanç, ancak en maliyetli olanı. Kod incelemesi gerektirir.
Bu sıralama, hız iyileştirmelerinin %80'inin çabanın %20'siyle elde edildiği gerçeğine dayanır. Zor işleri sona bırakın.
Tarayıcı Önbelleği: Almadığınız En Kolay Kazanç
nginx'te önbellek başlıklarını ayarlamak yalnızca birkaç satırdır:
location ~* \.(jpg|jpeg|png|webp|svg|css|js)$ {
expires 30d;
add_header Cache-Control "public, immutable";
}Bu ayarla, kullanıcının tarayıcısı statik dosyaları 30 gün boyunca saklar ve sonraki ziyaretlerde hiç istek göndermez. Sonuç: ikinci ve üçüncü sayfa yüklemeleri neredeyse anlıktır.
Yaygın sorun: CSS veya JS değiştirdikten sonra kullanıcılar eski sürümü görür. Çözüm, dosya adına hash eklemektir: style.a3f2b9.css. Her değişiklikte ad değişir ve tarayıcı yeni sürümü almaya zorlanır.
WebP Görseller: Belirgin Kalite Kaybı Olmadan
WebP formatı ortalama olarak JPEG'den %30, PNG'den %50 daha hafiftir. Dönüştürme şu komutla yapılır:
cwebp -q 80 input.jpg -o output.webpKalite 80 genellikle görsel olarak orijinalinden ayırt edilemez. Ürün görselleri için kalite 85'i seçin. Banner ve arka planlar için 75 yeterlidir.
Siteniz WordPress ise ShortPixel veya Imagify gibi eklentiler bunu otomatik yapar. Ancak özel bir siteniz varsa, kendi CDN veya dönüştürme scriptinizi kurmanız gerekir.
JavaScript: Core Web Vitals'ın Sessiz Katili
JavaScript, özellikle LCP (Largest Contentful Paint) ve INP (Interaction to Next Paint) olmak üzere Core Web Vitals metrikleri için en büyük tehdittir. Her ekstra script çalışma süresini artırır ve her ağır kütüphane daha fazla bellek tüketir.
İlk adım ölçümdür. Chrome DevTools'da Performance sekmesini açın ve sayfa yüklemesini kaydedin. Hangi scriptin en çok zaman aldığını görün. Genellikle suçlular eski jQuery kütüphaneleri, slider'lar ve analiz scriptleridir.
Pratik çözüm: Gereksiz scriptleri defer veya async ile yükleyin. Fark önemlidir: defer çalıştırma sırasını korur, async korumaz. Bağımsız scriptler için async daha iyidir. Bağımlı scriptler için defer.
Basit bir kural: Bir script sayfanın ilk render'ı için gerekli değilse, ana HTML'de olmamalıdır. Onu defer ile yükleyin veya kullanıcı etkileşiminden sonra koşullu olarak çalıştırın.
Fontlar: Gizli 200 Milisaniye
Web fontları genellikle göz ardı edilir, ancak her font dosyası 100-300 kilobayt olabilir. Üç fontu dört farklı ağırlıkla kullanırsanız, büyük bir görsele eşdeğer bir boyut eklemiş olursunuz.
Çözüm: Metnin varsayılan fontla görüntülenmesi ve web fontunun daha sonra değiştirilmesi için font-display: swap kullanın. Ayrıca yalnızca gerekli ağırlıkları yükleyin. Yalnızca Bold ve Regular kullanıyorsanız, Italic ve Black dosyalarını kaldırın.
Doğru Ölçüm; Tedavinin Yarısı
Herhangi bir işlemden önce bir baseline kaydedin. PageSpeed Insights kullanın ve LCP, INP ve CLS değerlerini not edin. Her değişiklikten sonra tekrar ölçün. Sayı iyileşmediyse, değişikliğiniz etkisizdir.
Bir diğer ücretsiz araç, tam yükleme waterfall'unu gösteren WebPageTest'tir. Bu araç hangi isteğin darboğaz olduğunu ve ne kadar sürdüğünü tam olarak belirler.
Sürekli izleme için monitoring araçları kullanabilirsiniz. Siteniz ServerNet'in SEO hizmetleri altyapısındaysa, teknik ekip hız optimizasyonunda size doğrudan yardımcı olabilir.
İnsanların Hata Yaptığı Yer: Ölçmeden Optimizasyon
Gördüğüm en yaygın hata: Bir site yöneticisi bir hafta boyunca görsel sıkıştırmaya zaman harcıyor, ancak sitenin TTFB'si 800 milisaniye ve hızda hiçbir değişiklik hissetmiyor. Neden? Çünkü ana darboğaz altyapıydı, görseller değil.
Bu hatanın işareti: PageSpeed raporu iyileşti, ancak kullanıcılar hâlâ sitenin yavaşlığından şikayet ediyor. Bu durumu yaşıyorsanız, önce TTFB'yi ölçün. 300 milisaniyenin üzerindeyse sorun barındırma veya web sunucusu ayarlarındadır ve hiçbir miktarda frontend optimizasyonu bunu çözmez.
Çözüm: Barındırmayı yükseltin veya NVMe ve PHP 8.2+ olan bir sunucuya geçin. Paylaşımlı hosting ile özel sunucu arasındaki TTFB farkı genellikle 3 ila 5 kat arasındadır.
Sıkça Sorulan Sorular
PageSpeed Insights'ta site hızım düşük ama pratikte hızlı görünüyor. Neden?
PageSpeed Insights, 4G bağlantı ve zayıf donanıma sahip simüle edilmiş bir cihaz kullanır. Bu senaryo, en kötü durumu göstermek için kasıtlı olarak katıdır. Kullanıcılarınız çoğunlukla yüksek hızlı internet ve modern cihazlarla geliyorsa, gerçek deneyimleri rapordaki sayıdan daha iyidir. Ancak bu, raporu görmezden gelmek için bir bahane değildir; Google sıralama için aynı metriği kullanır.
TTFB ve LCP arasındaki fark nedir ve hangisi daha önemlidir?
TTFB, sunucudan ilk baytın alınmasına kadar geçen süredir; LCP ise sayfadaki en büyük öğenin görüntülenme süresidir. TTFB, LCP'nin bir alt kümesidir; TTFB yüksekse LCP de yüksek olur. Ancak TTFB düşük olsa bile ana görsel geç yüklenirse LCP yüksek olabilir. Optimizasyon için önce TTFB'yi 200 milisaniyenin altına getirin, sonra LCP'ye geçin.
İran'daki bir site için CDN kullanmak gerekli mi?
Hedef kitleniz İran içindeyse, yabancı bir CDN yalnızca yardımcı olmaz, aynı zamanda hızı düşürür. Fiziksel mesafe ve yaptırımlar gecikmeyi artırır. Yerel siteler için, İran içinde veri merkezi olan bir hosting seçmek ve önbelleği doğru ayarlamak genellikle yeterlidir. CDN yalnızca uluslararası hedef kitlesi olan siteler için anlamlıdır.
Site hızını ne sıklıkla kontrol etmeliyim?
Sitede önemli bir değişiklik yaptıktan sonra bir kez. Ve düzenli izleme olarak ayda en az bir kez. Trafiğiniz aniden düşerse, yapacağınız ilk şey hızı kontrol etmek olsun. Hız düşüşü, ani trafik düşüşünden kurtulma yazımızda ele aldığımız trafik düşüşünün yaygın nedenlerinden biridir.
Yorumlar 0
Henüz yorum yok — ilk siz olun!