Site hızını ölçme ve sonuçları okuma

Site Hız Testiniz Sizi Neden Yanıltıyor?

Site hız testi sonucunuzu PageSpeed Insights veya GTmetrix gibi araçlarda gördüyseniz, muhtemelen şu senaryoyla karşılaşmışsınızdır: Laboratuvarda mükemmel bir puan, ancak gerçek kullanıcılar hâlâ sitenin yavaşlığından şikayetçi. Ya da tam tersi, test aracında düşük bir puan, ancak site tarayıcınızda hızlı görünüyor. Bu çelişki, Laboratuvar Verisi (Lab Data) ile Saha Verisi (Field Data) arasındaki temel farktan kaynaklanır.

Bu makalede, site hız testi sonucunu nasıl okuyacağınızı, hangi sayıların gerçekten önemli olduğunu ve en önemlisi, iyileştirmeleri tahminlere değil gerçek verilere dayanarak nasıl önceliklendireceğinizi öğreneceksiniz. Bu rehber; anlamsız puanların peşinden koşmak yerine gerçek hızı iyileştirmek isteyen geliştiriciler, teknik yöneticiler ve site sahipleri için yazılmıştır.

Laboratuvar Verisi ve Saha Verisi: İki Farklı Dünya

Site hız testi araçları genellikle iki tür çıktı sunar. Bu ikisi arasındaki farkı anlamak, sonucu doğru yorumlamanın yolunun yarısıdır.

Laboratuvar Verisi (Lab Data) Nedir?

Laboratuvar verisi, kontrollü bir ortamda test yapılmasının sonucudur. Lighthouse gibi araçlar (PageSpeed Insights'ta kullanılır) sitenizi belirli bir sunucudan, belirli bir tarayıcıyla (genellikle başsız Chrome) ve simüle edilmiş bir ağ bağlantısıyla (örneğin Slow 4G) yükler. Bu testler:

• Sabit bir coğrafi konumdan çalıştırılır (genellikle Amerika veya Avrupa).
• Tarayıcı önbelleğini (Cache) temizler ve çerezleri yok sayar.
• Sonucu 0-100 arası bir puan ve belirli metrikler (LCP ve TBT gibi) olarak raporlar.

Bu yöntemin avantajı, tekrarlanabilir ve karşılaştırılabilir olmasıdır. Ancak en büyük dezavantajı, gerçek kullanıcı deneyiminizle göreceli olarak ilgisiz olmasıdır; Tahran'da, Android telefonuyla ve Turkcell operatörünün 4G bağlantısıyla sitenizi açan bir kullanıcı, laboratuvar koşullarını asla deneyimlemez.

Saha Verisi (Field Data) veya CrUX Nedir?

Saha verisi, gerçek kullanıcıların tarayıcılarından toplanır. Google, bu verileri yeterli trafiğe sahip siteler için (ayda yaklaşık birkaç bin ziyaret) Chrome Kullanıcı Deneyimi Raporu (CrUX) aracılığıyla yayınlar. Bu veriler, kullanıcılarınızın sitenizle gerçek etkileşiminden elde edilen LCP, INP (FID'nin halefi) ve CLS gibi gerçek metrikleri içerir.

Önemli not: CrUX, son 28 günün verilerini gösterir ve yüzdelik dilim (P75) olarak raporlanır. Yani sitenizin CrUX'taki LCP'si 3,2 saniyeyse, gerçek kullanıcılarınızın %75'inin LCP'si 3,2 saniyeden kısadır.

Hızlı Karşılaştırma

Site Hız Testi Sonucundaki Temel Metrikler

Site hız testi sonucunu açtığınızda birçok sayıyla karşılaşırsınız. Ancak gerçekten odaklanmanız gereken yalnızca birkaç metrik vardır. Bu metrikler, Google'ın kullanıcı deneyiminin ana ölçütü olarak kabul ettiği Core Web Vitals'lardır.

LCP (Largest Contentful Paint - En Büyük İçerikli Boyama)

Görünüm alanındaki (viewport) en büyük içerik öğesinin (genellikle ana görsel, video veya büyük metin) yüklenme süresi. Bu metrik, kullanıcının sayfanın "en kullanışlı" bölümünü görmek için ne kadar beklemesi gerektiğini gösterir. İstenen sınır: 2,5 saniyeden az.

INP (Interaction to Next Paint - Sonraki Boyamaya Etkileşim)

Bu metrik FID'nin yerini almıştır ve sayfanın kullanıcı etkileşimlerine (tıklama, dokunma, yazma) verdiği yanıtı ölçer. INP, ilk etkileşimden sonraki karenin görüntülenmesine kadar geçen süreyi hesaplar. İstenen sınır: 200 milisaniyeden az.

CLS (Cumulative Layout Shift - Kümülatif Düzen Kayması)

Yükleme sırasında sayfa öğelerinin beklenmedik hareket miktarı. Görseller yüklenirken metin aşağı itilirse CLS yükselir. İstenen sınır: 0,1'den az.

TBT (Total Blocking Time - Toplam Engelleme Süresi) — Yalnızca Laboratuvar

Ana iş parçacığının (Main Thread) yükleme sırasında engellendiği ve kullanıcı girdisine yanıt veremediği toplam süre. Bu metrik yalnızca laboratuvar verilerinde bulunur ve INP'yi tahmin etmeye yardımcı olur. İstenen sınır: 200 milisaniyeden az.

Yaygın Senaryo: İyi Laboratuvar Puanı, Kötü Gerçek Deneyim

Diyelim ki siteniz PageSpeed Insights'ta mobil için 95 puan alıyor. Laboratuvar LCP'si 1,8 saniye. Ancak CrUX, gerçek LCP'nin 4,5 saniye olduğunu gösteriyor. Bu büyük fark neden?

Bu farkın ana nedenleri şunlardır:

1. Test sunucusunun coğrafi konumu: Google aracı Amerika'dan test yapar. Sitenizin sunucusu İran'daysa, fiziksel mesafe ve uluslararası internet yolu, gidiş-dönüş süresini (RTT) artırır. İran sunucusuna bağlanan İranlı kullanıcı, laboratuvar testinden daha iyi bir LCP'ye sahip olacaktır.
2. Gerçek ağ koşulları: Laboratuvar testi simüle edilmiş 4G bağlantısı kullanır, ancak gerçek kullanıcılar 3G veya yoğun dalgalanmalı bir ağda olabilir.
3. Cihaz donanımı: İranlı kullanıcıların büyük bir kısmını oluşturan orta ve alt segment telefonlar daha az işlem gücüne sahiptir ve JavaScript çalıştırmak daha yavaştır.
4. Önbellek ve CDN: Gerçek kullanıcılar, laboratuvar testinde simüle edilmeyen tarayıcı önbelleğini veya CDN'yi etkinleştirmiş olabilir.

Sonuç Yorumlamadan Gerçek Bir Örnek

Diyelim ki site hız testi sonucunuz şu sayıları gösteriyor:

LCP (Laboratuvar): 2.1s
LCP (CrUX - P75): 4.8s
INP (CrUX - P75): 350ms
CLS (CrUX - P75): 0.05

Doğru yorumlama, ana sorununuzun ağ ve içerik dağıtımında olduğudur, ön uç kodlarında değil. Çünkü CLS mükemmel ve INP nispeten kabul edilebilir, ancak gerçek LCP izin verilen sınırın iki katı. İlk öncelik, JavaScript optimizasyonu değil, kritik kaynakların indirme süresini azaltmak olmalıdır.

İyileştirmeleri Gerçek Verilere Dayanarak Önceliklendirme

Site hız testi sonucunu yorumladıktan sonra sıra harekete geçmeye gelir. Ancak tüm sorunları aynı anda çözmeye çalışmamalısınız. Önceliklendirme, saha verisi üzerindeki etkiye göre yapılır.

Adım 1: CrUX'u İnceleyin ve Kritik Metriği Belirleyin

PageSpeed Insights'a gidin ve "Field Data" bölümünü inceleyin. CrUX verisi yoksa (düşük trafikli site), Search Console (Core Web Vitals raporu) gibi araçları kullanın. "Poor" durumunda olan metrik sizin ilk önceliğinizdir.

Adım 2: Ağ ve İçerik Dağıtım Sorunlarını Giderin

LCP ana sorunsa, şu adımları sırasıyla uygulayın:

• CDN Etkinleştirme: Sitenizin dağınık kullanıcıları varsa, CDN statik kaynakların teslim süresini büyük ölçüde azaltabilir. Cloudflare veya İran içi CDN hizmetlerini inceleyin.
• Görsel Optimizasyonu: WebP veya AVIF formatı, Squoosh gibi araçlarla sıkıştırma ve farklı boyutlar için srcset kullanımı.
• Kritik Kaynakları Önceden Yükleme (Preload): <link rel="preload"> komutuyla tarayıcıya yazı tipini veya ana görseli daha erken indirmesini söyleyin.
• Sunucu ve Barındırmayı Kontrol Edin: Sunucunuz İran'daysa ve yabancı kullanıcılarınız varsa (veya tam tersi), sunucu konumunu değiştirmeniz veya daha optimize bir altyapıya sahip bir barındırma hizmeti kullanmanız gerekebilir. ServerNet, web barındırma ve bulut altyapı hizmetleri sağlayıcısı olarak sunucu yanıt süresini iyileştirmek için seçenekler sunar.

Adım 3: JavaScript ve CSS Optimizasyonu

INP veya TBT ana sorunsa, şu adımları uygulayın:

• Gereksiz JavaScript'i Kaldırma: DevTools'taki Coverage aracını kullanarak kullanılmayan kodları bulun.
• Defer ve Async: Kritik olmayan scriptleri defer ile yükleyin, böylece HTML ayrıştırıldıktan sonra çalıştırılır.
• Code Splitting: JavaScript'te dynamic import kullanarak her sayfa için yalnızca gereken kodu yükleyin.
• Ana İş Parçacığı İş Yükünü Azaltma: Ağır işlemleri Web Worker'a taşıyın.

Adım 4: CLS Sorunlarını Giderin

CLS yüksekse, sorun genellikle şunlardan kaynaklanır:

• Belirgin boyutları olmayan görseller ve videolar (width ve height).
• İlk yüklemeden sonra dinamik içerik eklenmesi (reklamlar gibi).
• Gecikmeli yüklenen ve metnin kaymasına neden olan yazı tipleri (font-display: swap kullanın).

Site Hız Testi Sonucunu Yorumlamada Sık Yapılan Hatalar

Bu bölümde, site hız testi sonucunu analiz ederken en sık karşılaşılan hataları gözden geçiriyoruz.

Hata 1: PageSpeed Insights'ta 100 Puanın Peşinden Koşmak

Lighthouse'ta 100 puan "mümkün olan en hızlı site" anlamına gelmez. Bu puan yalnızca sitenizin belirli laboratuvar koşullarında optimize olduğunu gösterir. Çok hızlı birçok site 80 puana sahiptir çünkü bazı optimizasyonlar (belirli kitaplıkları kaldırmak gibi) ticari ihtiyaçlarla çelişir. 90'ın üzerinde bir puanı hedeflemeyin; CrUX metriklerine odaklanın.

Hata 2: Coğrafi Farkı Görmezden Gelmek

Sitenizin hedef kitlesi İranlıysa, Amerika sunucusundan yapılan test sonucu neredeyse ilgisizdir. Her zaman test sunucusu konumu seçeneği sunan araçları kullanın (GTmetrix'te Tahran veya Dubai konumu seçmek gibi). Ayrıca, İranlı kullanıcıların gerçek verilerini gösteren CrUX'u da ihmal etmeyin.

Hata 3: Bir Metriği İyileştirirken Diğerini Bozmak

Klasik örnek: JavaScript'i tamamen kaldırmak LCP'yi iyileştirebilir ancak kullanıcı etkileşimlerini (INP) bozabilir. Veya aşırı görsel sıkıştırma, boyutları belirtmezseniz CLS'yi kötüleştirebilir. Her değişiklikten sonra tüm Core Web Vitals setini yeniden kontrol edin.

Hata 4: Yalnızca Bir Kez Test Etmek

Site hız testi sonucu büyük ölçüde dalgalanır. Tek bir test, ağ trafiğinden, sunucu durumundan veya günün saatinden etkilenebilir. Testi en az 5 kez tekrarlayın ve sonuçların medyanını (Median) temel alın. Saha verisi için her zaman CrUX'un 28 günlük aralığını inceleyin, belirli bir günü değil.

Test ve İzleme İçin Önerilen Araçlar

Site hız testi sonucunuzun yorumlanmasının doğru olması için aşağıdaki araçların bir kombinasyonunu kullanın:

• PageSpeed Insights: Laboratuvar ve saha verilerini aynı anda görmek için (CrUX mevcutsa).
• GTmetrix: Farklı coğrafi konumlardan test etmek ve isteklerin su basması (Waterfall) analizi için.
• WebPageTest: Belirli cihazları ve farklı bağlantıları simüle eden gelişmiş testler için.
• Search Console: Alan adı düzeyinde Core Web Vitals'ı sürekli izlemek için.
• RUM (Gerçek Kullanıcı İzleme) Araçları: Cloudflare Web Analytics veya gerçek kullanıcı verilerini toplayan özel bir script gibi.

Özet: Sayıdan Eyleme

Site hız testi bir başlangıç noktasıdır, hedef değil. Bu testin sonucunu bir "teşhis" olarak görün, "kesin yargı" olarak değil. Siteniz CrUX için yeterli trafiğe sahip değilse (bu durumda RUM araçlarını kullanın), her zaman saha verisini (CrUX) laboratuvar verisinden üstün tutun.

İyileştirme önceliğini kritik durumdaki metriğe göre belirleyin. LCP kötüyse ağ ve görsellere bakın. INP kötüyse JavaScript'i optimize edin. CLS kötüyse öğelerin boyutlarını belirtin. Her değişiklikten sonra yeni saha verisinin toplanması için en az bir hafta bekleyin ve yeniden yorumlayın.

Unutmayın: Hız tek seferlik bir proje değil, sürekli bir süreçtir. Düzenli izleme ve doğru yorumlama ile laboratuvar araçlarının ne puan verdiğinden bağımsız olarak kullanıcılarınız için hızlı ve keyifli bir deneyim oluşturabilirsiniz.