Web Sitenizin Hızını Doğru Ölçmek: GTmetrix, PageSpeed Insights ve WebPageTest Rehberi

Web sitesi hızını ölçerken neden çoğu rapor kafanızı karıştırıyor?

Birçok site sahibi GTmetrix, PageSpeed Insights veya WebPageTest ile test yaptığında birbirinden oldukça farklı sonuçlar görür. Bir araçta A notu alırken, diğerinde düşük skor görmek moral bozabilir. Üstüne bir de barındırma tarafında TTFB, CPU, RAM, disk I/O gibi sunucu değerleri devreye girince, “Aslında sitem gerçekten hızlı mı, nerede sorun var?” sorusu daha da karmaşık hale gelir.

Aslında sorun genelde sitenin hızında değil, hızın nasıl ölçüldüğü ve sonuçların nasıl yorumlandığı ile ilgilidir. Farklı test araçları farklı senaryolar, farklı cihaz ve bağlantı varsayımları, hatta farklı test lokasyonları kullanır. Üstelik tarayıcı önbelleği, CDN, dinamik içerik ve oturum açmış kullanıcılar gibi faktörler de ölçümleri ciddi şekilde etkiler.

Bu rehberde, biz DCHost ekibi olarak kendi projelerimizde ve müşterilerimizin sitelerinde kullandığımız pratik yaklaşımı adım adım paylaşacağız. GTmetrix, PageSpeed Insights ve WebPageTest sonuçlarını nasıl birlikte okumalı, hangi metriklere gerçekten odaklanmalı, hangilerini ise arka plana atmalısınız; ayrıca sunucu tarafında TTFB, CPU, RAM, disk ve ağ değerlerini bu sonuçlarla nasıl ilişkilendireceğinizi konuşacağız.

Ayrıca, Core Web Vitals tarafında TTFB, LCP ve CLS gibi metriklerin hosting altyapısı ile nasıl bağlantılı olduğunu daha derinlemesine anlamak isterseniz, detayları Core Web Vitals ve hosting altyapısı rehberimizde de bulabilirsiniz. Şimdi, hız test araçlarını birer “puan oyunu” olmaktan çıkarıp, gerçek bir teşhis ve optimizasyon aracına dönüştürelim.

Hız ölçerken yapılan en yaygın hatalar

Önce fotoğrafı netleştirelim. Yanlış alışkanlıkları kırmadan doğru ölçüm yapmak çok zor.

1. Tek bir test sonucuna bakıp karar vermek

Hız testleri anlık ağ koşullarından, test bölgesinin yükünden, hatta DNS yanıt sürelerindeki küçük dalgalanmalardan bile etkilenir. Bu yüzden:

• Aynı araçta en az 3–5 test çalıştırıp ortalamaya bakın.
• Farklı saat dilimlerinde (yoğun ve sakin saatlerde) test yapın.
• Sonuçlardaki trende odaklanın; tek seferlik sıçramalara değil.

2. Sadece skor kovalamak

PageSpeed Insights’ta 100/100 almak kulağa hoş gelebilir; ancak bu skor:

• Gerçek kullanıcıların yaşadığı deneyimi birebir yansıtmaz.
• Kimi zaman ticari mantığa ters (fazla agresif) optimizasyonlara zorlayabilir.
• Her tema, eklenti ve üçüncü parti script için pratik olmayabilir.

Bizim yaklaşımımız: Skor değil kullanıcı deneyimi. Özellikle LCP, CLS, FID/INP ve TTFB gibi metriklerde makul eşiklere ulaşmak gerçek hayatta çok daha değerlidir.

3. Sadece anasayfayı test etmek

Çoğu zaman en ağır sayfa, anasayfa değil:

• E-ticaret sitelerinde kategori ve ürün filtreleme sayfaları,
• Bloglarda uzun içerik + çok görsel barındıran yazılar,
• Üyelik veya ödeme adımlarıdır.

Bu nedenle:

• En çok trafik alan ilk 3–5 sayfayı ayrı ayrı test edin.
• Sepet, ödeme ve hesap sayfaları gibi kritik adımları mutlaka ayrı test edin.

4. CDN, DNS ve lokasyon etkisini göz ardı etmek

Test lokasyonu ile kullanıcılarınızın çoğunlukla bulunduğu lokasyon aynı değilse, sonuçlar sizi yanlış yönlendirebilir. CDN ve DNS stratejiniz, özellikle farklı ülkelerden gelen kullanıcılar için büyük fark yaratır. CDN kullanımı hakkında detaylı bir karar rehberine ihtiyacınız varsa, CDN nedir, ne zaman gerekir rehberimize de göz atmanızı öneririz.

Doğru hız ölçümü için senaryo tasarımı

Bir testi doğru kurmak, sonucu doğru yorumlamak kadar kritik. Biz DCHost’ta projelere başlamadan önce mutlaka bir ölçüm senaryosu hazırlıyoruz.

1. Hedef kitlenin lokasyonunu belirleyin

Önce şu soruyu netleştirin: “Kullanıcılarım çoğunlukla nereden bağlanıyor?”

• Türkiye ağırlıklı bir kitleniz varsa, Avrupa’ya yakın test lokasyonları tercih edin.
• Global bir kitleye hitap ediyorsanız, en azından 2–3 bölgeden (Avrupa, ABD, gerekirse Asya) ayrı testler çalıştırın.

Bu aşamada aynı zamanda sunucu lokasyonunun SEO’ya ve kullanıcı deneyimine etkisini de göz önünde bulundurmak faydalı olur.

2. Cihaz ve bağlantı tipini seçin

Çoğu kullanıcı:

• Mobil cihazdan,
• Her zaman kusursuz olmayan 4G/3G bağlantılar üzerinden gelir.

Bu yüzden testleri sadece “masaüstü + sınırsız fiber” senaryosu üzerinde yapmak, gerçek resmi gizler. Ölçüm yaparken:

• Mobil cihaz profili (örneğin orta seviye Android) ile test edin.
• 3G/4G benzeri kısıtlı bağlantı profili seçin (throttling).

3. Önbellekli ve önbelleksiz senaryoyu ayırın

Önbellek (page cache, object cache, CDN cache) kullanıyorsanız, iki ayrı dünyanız var demektir:

1. İlk ziyaret (cold cache): Sayfa ilk kez isteniyor, henüz önbellek dolmamış.
2. Tekrarlayan ziyaret (warm cache): Önbellek dolu, kaynaklar tarayıcı ve CDN’den hızlı geliyor.

Bu iki senaryo için ayrı testler yapmak, özellikle WooCommerce gibi dinamik sitelerde gerçekçi bir tablo sunar. Örneğin ödeme adımı genelde önbelleksiz çalışırken, blog yazıları tam sayfa önbellekten gelir.

4. Oturum açmış / açmamış kullanıcı farkı

Birçok sistemde:

• Oturum açmamış ziyaretçiler önbellekten hızlı cevap alır.
• Oturum açmış kullanıcılar (müşteri paneli, sepet, dashboard) için dinamik sorgular devrededir.

Bu nedenle ölçüm yaparken, özellikle yönetici paneli ve üye alanları için ayrı senaryolar tanımlayın. Aksi halde sadece “anonim ziyaretçi” performansını ölçüp, asıl ağır yükü gözden kaçırmış olursunuz.

GTmetrix sonuçlarını doğru okumak

GTmetrix, özellikle waterfall (şelale) grafiği ile istek bazında detay görmenizi sağladığı için teşhis aşamasında çok değerli. Ancak burada da skorlardan çok metriklere ve şelale görünümüne odaklanmak gerekiyor.

GTmetrix’te en kritik metrikler

• Fully Loaded Time: Sayfadaki tüm isteklerin (görseller, JS, üçüncü parti script’ler) tamamlandığı süre. Kullanıcı deneyimi için önemlidir ama her zaman en kritik metrik değildir.
• Time to First Byte (TTFB): Sunucunun ilk baytı ne kadar sürede gönderdiğini gösterir. Yüksek TTFB genelde sunucu, PHP, veritabanı veya uygulama kodu kaynaklı sorunlara işaret eder.
• Total Page Size: Sayfanın toplam boyutu. Özellikle görsel ağırlıklı sitelerde 3–5 MB’ı kolayca aşabilir.
• Requests: Sayfa yüklenirken yapılan toplam HTTP isteği. Çok fazla istek (özellikle JS/CSS) performansı olumsuz etkiler.

TTFB tarafında derinleşmek isterseniz, sunucu ve PHP kaynaklı nedenleri detaylı anlattığımız yüksek TTFB sorununu çözme rehberimize mutlaka göz atın.

Waterfall grafiği nasıl okunur?

Waterfall görünümü, sayfanız yüklenirken hangi isteğin ne kadar sürede tamamlandığını görmenizi sağlar. Özellikle şu renklere dikkat edin:

• DNS Lookup süresi uzun ise: DNS sağlayıcınız, DNSSEC ayarlarınız veya ağ gecikmesi sorun yaratıyor olabilir.
• Connecting / SSL süreleri uzun ise: TLS el sıkışması, sertifika zinciri veya ağ gecikmesi incelenmelidir.
• TTFB (Waiting) uzun ise: Sunucu tarafında (PHP, veritabanı, disk, CPU) darboğaz olabilir.
• Content Download uzun ise: Dosya boyutu yüksek, sıkıştırma yok (gzip/brotli), uzak lokasyon veya yavaş bağlantı söz konusu olabilir.

Ayrıca:

• Uzun kuyruk oluşturan üçüncü parti script’leri (analytics, reklam, chat widget) tespit edin.
• Paralel yüklenebilecekken seri yüklenen büyük JS ve CSS dosyalarını belirleyin.

GTmetrix ile önceliklendirme

GTmetrix size sadece sorunları göstermiyor, aynı zamanda hangi alanda ne kadar kazanım sağlayacağınızı da yaklaşık olarak tahmin etmenize yardım ediyor. Örneğin:

• Görsel optimizasyonu ile 2 MB tasarruf,
• CSS ve JS birleştirme / küçültme ile 20–30 istek azaltma,
• Önbellekleme ile tekrar eden ziyaretlerde büyük kazanım sağlama.

Burada hedefiniz, “önce en büyük kazanımı getiren değişikliği” hayata geçirmek olmalı. Özellikle görseller ve üçüncü parti script’ler, genelde ilk bakılması gereken yerlerdir.

PageSpeed Insights ve Core Web Vitals: Skoru değil sinyali okuyun

PageSpeed Insights, Google’ın hem laboratuvar verisi (Lab Data) hem de gerçek kullanıcı verisi (Field Data – CrUX) sunduğu için SEO ve kullanıcı deneyimi açısından kritik bir araç.

Lab Data vs Field Data farkı

• Lab Data: Siteniz o anda Google’ın tanımladığı cihaz ve ağ profili üzerinde test edilir. Bu bölümde LCP, CLS, TBT gibi metrikler simüle edilmiştir.
• Field Data: Gerçek Chrome kullanıcılarından toplanan anonim metriklerin istatistiksel özeti. Eğer yeterli trafiğiniz varsa, burada LCP, FID/INP, CLS için gerçek kullanıcı deneyimini görürsünüz.

Gerçek optimizasyon kararlarını verirken Field Data’ya öncelik vermek, Lab Data’yı ise tamamlayıcı sinyal olarak kullanmak en sağlıklı yaklaşımdır.

En önemli Core Web Vitals metrikleri

• LCP (Largest Contentful Paint): Sayfadaki en büyük içerik bloğunun (genelde büyük görsel veya başlık) ne kadar sürede göründüğünü söyler. Kullanıcının “sayfa açıldı” hissini belirleyen en önemli metriklerden.
• CLS (Cumulative Layout Shift): Sayfa yüklenirken öğelerin ne kadar yer değiştirdiğini ölçer. İçerikler zıplıyor, butonlar kayıyorsa CLS yüksek çıkar.
• FID / INP: Kullanıcının bir etkileşime (tıklama, scroll, input) verdiği ilk yanıtın ne kadar hızlı olduğunu gösterir. JavaScript yoğun sitelerde önemlidir.
• TTFB: Sunucunun ilk baytı gönderme süresi. Özellikle hosting ve altyapı tarafı ile direkt bağlantılıdır.

Bu metriklerin sunucu altyapısıyla ilişkisini, ayrıntılı örneklerle Core Web Vitals ve hosting altyapısı rehberimizde anlattık. İki rehberi birlikte okursanız, ölçüm ve optimizasyon tarafında çok daha sağlam bir çerçeveye sahip olursunuz.

PageSpeed skorunu nasıl yorumlamalısınız?

Skorun arkasındaki gerçekleri şöyle düşünebilirsiniz:

• 90+ skor genelde gayet iyi bir deneyime işaret eder, ama 80–90 arası da çoğu proje için ticari açıdan yeterince iyidir.
• Mobil ve masaüstü skorlarının farklı olması doğaldır; mobil tarafı önceliklendirmeniz gerekir.
• Bazen üçüncü parti script’ler (örneğin zorunlu analitikler ve ödeme entegrasyonları) nedeniyle 100 puanı kovalamak yerine, “en mantıklı dengenin” peşinden gitmek gerekir.

WebPageTest ile ileri seviye analiz

WebPageTest, özellikle performans profesyonellerinin sık kullandığı, daha detaylı ve senaryo tabanlı testler sunan bir araçtır. Eğer sitenizde karmaşık bir performans problemi varsa, burada sunulan özellikler çok yardımcı olur.

Tekrarlı testler ve first/second view

WebPageTest’te aynı test senaryosunu birden fazla kez çalıştırıp ortalama sonuç alabilir, ayrıca:

• First View: Kullanıcı ilk kez siteyi ziyaret ederken (tarayıcı önbelleği boş),
• Repeat View: Tarayıcı önbelleği doluyken ikinci ziyarette

performansın nasıl değiştiğini görebilirsiniz. Bu, önbellek stratejinizin gerçekten işe yarayıp yaramadığını anlamak için çok değerlidir.

Filmstrip ve video kaydı

WebPageTest’in en güçlü özelliklerinden biri de sayfa yüklenmesini filmstrip (kare kare görüntü) veya video olarak izlemenize izin vermesidir. Bu sayede:

• Kullanıcı ilk 1–2 saniyede ne görüyor?
• Kritik içerik ne zaman beliriyor?
• Görsel zıplamalar veya geç yüklenen öğeler var mı?

gibi sorulara çok net cevap alabilirsiniz. Bu görsel geri bildirim, çoğu zaman sayıları okumaktan daha ikna edicidir.

İleri metrikler: Start Render, Speed Index, Time to Interactive

WebPageTest şu metrikleri de öne çıkarır:

• Start Render: Piksel bazında ilk görüntünün oluştuğu an.
• Speed Index: Sayfanın görsel olarak ne kadar hızlı dolduğunu, zaman içinde ağırlıklandırarak ölçen karma bir metrik.
• Time to Interactive: Sayfanın hem görsel olarak yüklenmiş hem de kullanıcı etkileşimine gerçekten hazır hale geldiği zaman.

JavaScript ağırlıklı modern front-end projelerinde (SPA, React, Vue, Next.js, vb.) bu metrikler, klasik yükleme süresinden daha anlamlı hale gelir.

Sunucu tarafı metrikleri hız testleriyle nasıl birleştirirsiniz?

Şimdi işin DCHost tarafına en çok dokunan yerine gelelim. Hız testleri size tarayıcıdan bakınca görünen tabloyu verir; ama asıl teşhis için sunucunun içeride neler yaşadığını da görmeniz şart.

1. TTFB ve sunucu kaynakları

TTFB, çoğu zaman şu bileşenlerin toplam gecikmesidir:

• Web sunucusu (Nginx, Apache, LiteSpeed) kuyruğu,
• PHP-FPM veya benzeri uygulama motoru kuyruğu ve işlem süresi,
• Veritabanı sorguları (MySQL/MariaDB/PostgreSQL),
• Disk erişimi (özellikle SSD vs NVMe farkı),
• Yoğun CPU kullanımı veya RAM yetersizliği nedeniyle oluşan gecikmeler.

Hız testi sırasında sunucuda izlemeniz gerekenler:

• CPU kullanımı (yüksekse işlemci gücü veya optimizasyon gerekebilir),
• RAM kullanımı (swap’e düşüyorsanız ciddi yavaşlama yaşarsınız),
• Disk I/O (yetersiz IOPS veya yoğun disk kuyruğu TTFB’yi şişirir),
• Network throughput ve gecikme (özellikle uzak lokasyona yayın yapıyorsanız).

Disk tarafındaki farkları daha derin anlamak isterseniz, NVMe VPS hosting rehberimizde NVMe’nin performansa etkisini gerçek örneklerle anlattık.

2. PHP ve veritabanı ayarları

PHP tarafında:

• max_execution_time çok düşükse bazı ağır sorgular yarıda kalabilir, çok yüksekse uzun süren script’ler CPU’yu kilitleyebilir.
• memory_limit yetersizse, yoğun sayfalarda PHP bellek hatası verebilir veya yavaşlayabilir.
• PHP-FPM havuz ayarları (pm, pm.max_children vb.) yanlışsa aynı anda gelen istekler kuyrukta bekler.

Bu ayarları doğru konumlandırmak için PHP ayarlarını doğru yapmak rehberimizi inceleyebilirsiniz.

Veritabanı tarafında ise:

• Yavaş sorgu logu (slow query log) mutlaka açık olmalı,
• Index eksikliği olan tablolar tespit edilmeli,
• Bağlantı havuzu ve cache stratejileri gözden geçirilmeli.

3. Ağ, DNS ve CDN etkisi

Sunucuya yakın kullanıcılarınız için her şey yolunda görünürken, uzak bölgedeki kullanıcılar yüksek gecikme yaşayabilir. Bu durumda:

• Sunucu lokasyonunuzu hedef kitlenize göre gözden geçirin.
• CDN kullanarak statik içerikleri kullanıcıya en yakın noktaya taşıyın.
• DNS altyapınızı (nameserver, TTL değerleri, DNSSEC vb.) sağlıklı yönetin. DNS’in performansa etkisini daha iyi anlamak için DNS kayıtları rehberimize de göz atabilirsiniz.

4. Kaynak planlama ve paket seçimi

Bazen sorun sadece optimizasyonda değil, gerçekten yetersiz kaynakta olabilir. Özellikle:

• E-ticaret siteleri,
• Yoğun içerikli blog ve haber siteleri,
• SaaS ve özel uygulamalar

için CPU, RAM, disk ve bant genişliği doğru planlanmalıdır. Bu konuda adım adım yaklaşım için yeni web sitesi için CPU, RAM ve trafik hesaplama rehberini ve WooCommerce kapasite planlama rehberini inceleyebilirsiniz.

DCHost tarafında paylaşımlı hosting, NVMe VPS, dedicated ve colocation gibi farklı seviyelerde çözümlerle, ihtiyaç arttıkça yukarı doğru sorunsuz geçiş planları kurguluyoruz.

Uçtan uca örnek: WooCommerce mağazasında hız ölçümü ve yorumlama

Şimdi tüm bu anlattıklarımızı somut bir senaryo üzerinden toplayalım. Diyelim ki Türkiye hedefli bir WooCommerce mağazanız var ve son dönemde sepet adımında yavaşlama şikayetleri alıyorsunuz.

1. Ölçüm senaryosunu kurmak

• Test lokasyonu: Avrupa’ya yakın bir nokta.
• Cihaz: Orta seviye mobil cihaz profili.
• Bağlantı: 4G kısıtlaması.
• Sayfalar: Anasayfa, yoğun kategori sayfası, ürün sayfası, sepet, ödeme.
• Durum: Hem oturum açmamış (anonim) hem de oturum açmış kullanıcı için ayrı testler.

2. GTmetrix ile ilk teşhis

Örneğin sepet ve ödeme sayfalarında:

• TTFB: 1,5–2 saniye,
• Toplam istek: 140+,
• Toplam boyut: 4–5 MB

gibi bir tablo görüyorsunuz. Waterfall grafiğinde:

• Birden fazla harici script (canlı destek, pazarlama pixel’leri) ana içeriği geciktiriyor.
• Ödeme eklentisi JS dosyaları sayfa başında yükleniyor.
• Sunucu tarafında TTFB’yi şişiren birkaç dinamik AJAX isteği var.

3. PageSpeed Insights ile Core Web Vitals kontrolü

Aynı sayfaları PageSpeed Insights’ta test ettiğinizde:

• Mobil LCP’nin 4+ saniye olduğu,
• CLS’nin ödeme adımındaki form alanları ve uyarı kutuları nedeniyle yüksek çıktığı,
• INP’nin bazı JavaScript ağır işlemler yüzünden sınırı zorladığı

ortaya çıkıyor. Field Data varsa, gerçek kullanıcıların da bu sorunları yaşadığını teyit ediyorsunuz.

4. WebPageTest ile görsel inceleme

WebPageTest üzerinde:

• First view ve repeat view sonuçlarını karşılaştırarak cache stratejinizin etkisini görüyorsunuz.
• Filmstrip’ten bakınca, ödeme formunun geç çizildiğini, üstteki banner ve kampanya görsellerinin daha önce yüklendiğini fark ediyorsunuz.

Bu görsel geri bildirim, “kritik içeriği öne çekme” ve gereksiz script’leri erteleme (defer) kararlarını güçlendiriyor.

5. Sunucu tarafını izlemek

Bu testleri yaparken DCHost sunucunuzda:

• CPU kullanımının yoğun saatte %90’lara vurduğunu,
• PHP-FPM havuzunda anlık bağlantı sayısının max_children sınırına dayandığını,
• Veritabanında birkaç ağır sorgunun 1+ saniye sürdüğünü,
• Disk I/O’nun makul, network’ün ise yeterli seviyede olduğunu

gözlemliyorsunuz. Bu tablo, asıl darboğazın CPU ve veritabanı sorguları olduğunu gösteriyor.

6. Aksiyon planı

Bu senaryoda izlenebilecek mantıklı yol şu olabilir:

1. WooCommerce üzerinde ağır sorgulara neden olan eklentileri tespit edip, gerekiyorsa alternatiflerine geçmek.
2. PHP-FPM ve veritabanı ayarlarını optimize etmek; gerekiyorsa bir üst seviye NVMe VPS veya dedicated plana geçmek.
3. Ödeme adımındaki gereksiz üçüncü parti script’leri kaldırmak veya sadece kritik olmayan adımlarda yüklemek.
4. Görsel ve CSS/JS optimizasyonları ile toplam istek sayısını ve sayfa boyutunu azaltmak.

Böyle bir çalışmada hız test araçları, sadece sorunu “var” diye işaret eden değil, nerede yoğunlaştığını gösteren detaylı göstergeler haline gelir. Sunucu tarafı metrikleri ile birleşince de çok net, ölçülebilir bir iyileştirme süreci yürütmek mümkün olur.

Sonuç: Skoru değil kullanıcıyı, tek aracı değil bütünü okuyun

Web sitesi hızını doğru ölçmek, aslında üç katmanlı bir işi aynı anda yönetmek anlamına geliyor:

• Tarayıcı tarafı: GTmetrix, PageSpeed Insights, WebPageTest ile sayfanın nasıl yüklendiğini görmek.
• Kullanıcı deneyimi: Core Web Vitals ve gerçek kullanıcı verileri (Field Data) ile insanların sitede neler hissettiğini anlamak.
• Sunucu tarafı: TTFB, CPU, RAM, disk, ağ ve uygulama logları ile altyapının perde arkasını izlemek.

Bir tek araca ya da tek skora takılıp kalmak yerine, bu üç katmanı birlikte okuduğunuzda hem daha doğru teşhis koyabilir hem de yaptığınız optimizasyonların gerçekten işe yarayıp yaramadığını net biçimde görebilirsiniz.

Biz DCHost ekibi olarak, paylaşımlı hosting, NVMe VPS, dedicated sunucu ve colocation altyapılarımızda müşterilerimizin hız testlerini sadece “rapor üretme” aracı olarak değil, somut aksiyon planı çıkarmak için kullanıyoruz. Yeni bir proje planlıyorsanız veya mevcut sitenizde hızdan emin değilseniz, bu rehberi bir kontrol listesi gibi kullanabilir; daha teknik altyapı detayları için de web hosting, domain, DNS ve SSL’in birlikte nasıl çalıştığını anlattığımız yazımıza göz atabilirsiniz.

Sonraki adımda, sitenizi seçtiğiniz araçlarla test edin, burada anlattığımız şekilde sonuçları yorumlayın ve küçük ama etkili iyileştirmelerle başlayın. İhtiyaç duyduğunuz noktada, DCHost altyapısında size en uygun hosting, VPS veya dedicated çözümünü teknik olarak birlikte planlayabilir; hem hız hem de sürdürülebilir maliyet açısından dengeli bir mimari kurabiliriz.