Web Sitesi Hızını Ölçme ve Test Sonuçlarını Yorumlama

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.

Raporlar arasındaki fark, tek başına sitenin hızlı ya da yavaş olduğunu göstermez; hızın nasıl ölçüldüğü ve sonuçların nasıl yorumlandığı da önemlidir. 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, hız ölçümü ve sonuçların yorumlanması için pratik bir 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 metriklerinden LCP ve CLS’nin, ayrıca teşhis metriği TTFB’nin 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, aynı URL ve test ayarlarıyla en az 3–5 test çalıştırıp ortalamaya ve sonuçların dağılımına bakın.
• Günün farklı saatlerinde (yoğun ve sakin saatlerde) test yapın.
• Karşılaştırılabilir ölçümlerde metriklerin eğilimine 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, INP ve TTFB gibi metriklerde makul eşiklere ulaşmak gerçek hayatta çok daha değerlidir.

3. Sadece anasayfayı test etmek

Anasayfadan daha ağır olabilecek sayfalara örnekler:

• 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ı.

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. Testlere başlamadan önce bir ölçüm senaryosu hazırlayın.

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, varsa Türkiye’deki bir test lokasyonunu tercih edin; yoksa Türkiye’ye yakın bir lokasyon seçip bunun yaklaşık bir temsil olduğunu not 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

Kullanıcılarınızın bir bölümü:

• 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:

• Aracın sunduğu seçenekler içinde hedef kitlenize uygun bir mobil cihaz profili (örneğin orta seviye Android) kullanın.
• Ayarlanabiliyorsa 3G/4G benzeri kısıtlı bağlantı profili seçin (throttling). Sabit profil kullanan testlerde cihaz ve ağ varsayımlarını kaydedin; farklı araçlarda bunların aynı olduğunu varsaymayın.

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

Tarayıcı önbelleğini, sunucudaki sayfa/nesne önbelleğini ve CDN önbelleğini ayrı değerlendirin. İlk ziyaret, tüm bu katmanların boş olduğu anlamına gelmez. Her katman için iki durumu ayırın:

1. Soğuk önbellek (cold cache): İncelenen katmanda istenen içerik için kullanılabilir bir önbellek kaydı yoktur.
2. Sıcak önbellek (warm cache): İncelenen katmanda yeniden kullanılabilir bir kayıt vardır. Tekrarlayan ziyaret bunu garanti etmez; kayıt süresi dolmuş veya istek önbellek dışında bırakılmış olabilir.

Bu iki senaryo için ayrı testler yapmak, özellikle WooCommerce gibi dinamik sitelerde gerçekçi bir tablo sunar. Örneğin WooCommerce’de sepet, ödeme ve hesap sayfalarının kişiye özel yanıtları paylaşılan tam sayfa önbelleğinden sunulmamalıdır; uygun yapılandırılmış blog yazıları ise tam sayfa önbelleğinden sunulabilir.

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

Birçok sistemde:

• Oturum açmamış ziyaretçilerin kişiselleştirilmemiş sayfa istekleri, uygun yapılandırmada önbellekten yanıt alabilir.
• Oturum açmış kullanıcıların üye alanlarında dinamik sorgular devrededir. Ancak sepet gibi oturuma özel içerikler, kullanıcı giriş yapmamış olsa da paylaşılan sayfa önbelleğinden hariç tutulmalıdır.

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: Güncel raporlarda testin tamamlanması için FCP ve onload’un gerçekleşmesi, ardından ağ ve CPU’nun 5,25 saniye hareketsiz kalması beklenir; onload sonrasında 30 saniyelik üst sınır uygulanır. Gösterilen süre, testte yakalanan ilgili zamanlamaların en geç olanıdır; tamamlanmayı saptamak için kullanılan bekleme süresini ifade etmez. Sonradan oluşabilecek tüm isteklerin bittiğini veya sayfanın kullanıcı açısından hazır olduğunu tek başına göstermez.
• Time to First Byte (TTFB): İlk yanıt baytının istemciye ulaşmasına kadar geçen süreyi gösterir. Yüksek TTFB, sunucu, PHP, veritabanı veya uygulama kodunun yanı sıra ağ gecikmesiyle de ilişkili olabilir; tek başına sunucu darboğazını kanıtlamaz.
• 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 etkileyebilir; istek sayısını dosya boyutları ve yükleme sıralamasıyla birlikte değerlendirin.

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 aşamalara 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.
• Waiting süresi uzun ise: İstek gönderildikten sonra ilk yanıt baytı beklenirken geçen bu aşamada sunucu işlemleri (PHP, veritabanı, disk, CPU) ve ağ gecikmesi etkili olabilir. Bunu DNS ve bağlantı aşamalarını da içerebilen toplam TTFB ölçümüyle aynı kapsamda değerlendirmeyin; raporun zamanlama tanımını kontrol edin.
• 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 optimizasyonuyla aktarılacak veri miktarını azaltma,
• CSS ve JS küçültmeyle dosya boyutunu azaltma; birleştirmeyle istek sayısını azaltmanın etkisini ayrıca ölçme,
• Uygun kaynakları önbelleğe alarak tekrar eden ziyaretlerde gereksiz aktarımları azaltma.

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 test koşullarındaki performansı gösterir.
• Field Data: Gerçek Chrome kullanıcılarından toplanan anonim metriklerin istatistiksel özeti. Yeterli CrUX verisi varsa, burada LCP, INP ve 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.

Core Web Vitals metrikleri ve yardımcı TTFB ölçümü

• LCP (Largest Contentful Paint): Sayfanın görünür alanındaki en büyük uygun görsel veya metin öğesinin (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): Sayfanın görsel kararlılığını ölçer. Beklenmedik yerleşim kaymaları CLS değerini yükseltebilir; değerlendirme yalnızca ilk yüklemeyle sınırlı değildir.
• INP (Interaction to Next Paint): Sayfanın kullanıcı etkileşimlerine yanıt verebilirliğini ölçer. JavaScript yoğun sitelerde önemlidir.
• TTFB: Core Web Vitals arasında değildir; sunucu tarafındaki darboğazları araştırırken yardımcı bir sinyaldir. Ağ gecikmesini de dikkate alarak yorumlanmalı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 olumlu bir laboratuvar sinyalidir; ancak ne bu skor ne de 80–90 aralığı tek başına iyi kullanıcı deneyimini veya ticari yeterliliği kanıtlar.
• Mobil ve masaüstü skorlarının farklı olması doğaldır; önceliği hedef kitlenizin cihaz dağılımına ve yaşadığı sorunlara göre belirleyin.
• 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, detaylı ve senaryo tabanlı testlerle performans sorunlarını incelemek için kullanılabilir. Karmaşık bir sorunu araştırırken test koşullarını ve sayfanın yüklenme aşamalarını ayrı ayrı değerlendirin.

Tekrarlı testler ve First View / Repeat View

WebPageTest’te aynı test senaryosunu birden fazla kez çalıştırıp sonuçların dağılımını karşılaştırabilir, ayrıca:

• First View: Tarayıcı önbelleği boşken yapılan ilk yükleme,
• Repeat View: İlk yüklemeden kalan tarayıcı durumuyla yapılan tekrar yükleme

arasındaki performans farkını görebilirsiniz. Repeat View’da kaynakların yeniden kullanılması, önbellek kurallarına ve kayıtların geçerliliğine bağlıdır; her kaynağın önbellekten geleceğini varsaymayın. Bu karşılaştırma sunucu veya CDN önbelleğinin sıcak ya da soğuk olduğunu da tek başına kanıtlamaz. Hangi kaynakların yeniden kullanıldığını istek ayrıntılarından inceleyin.

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. Filmstrip ve Speed Index için video yakalamanın test yapılandırmasında desteklenmesi ve etkin olması gerekir. 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

Seçtiğiniz WebPageTest raporunda yer alıyorsa, şu metrikleri de değerlendirin:

• 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 (TTI): Laboratuvar koşullarında etkileşime hazırlığı tahmin eden bir metriktir. FCP’den başlayarak ana iş parçacığında 50 ms’yi aşan görevlerin olmadığı en az beş saniyelik bir etkileşim penceresi aranır. Bu pencerenin içinde, aynı anda en fazla iki başarılı GET isteğinin sürdüğü kesintisiz beş saniyelik bir aralık bulunmalıdır; POST ve başarısız istekler bu sayımın dışındadır. Zaman damgası, bulunan etkileşim penceresinin başlangıcı, First Contentful Paint (FCP) ve DOMContentLoaded (DCL) zamanlarının en geç olanıdır. Tüm görsellerin yüklendiğini veya her kullanıcı etkileşiminin sorunsuz çalışacağını kanıtlamaz.

JavaScript ağırlıklı front-end projelerinde (SPA, React, Vue, Next.js, vb.) bu metrikleri yükleme zamanlamalarıyla birlikte kullanın. Görsel ilerleme ile etkileşime yanıt farklı konulardır; TTI’yi gerçek kullanıcı INP verisinin veya ilgili akışta yapılan etkileşim incelemesinin yerine koymayın.

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

Hız testleri tarayıcıdan görünen tabloyu verir; sunucu kaynaklı bir darboğazdan şüpheleniyorsanız, aynı zaman aralığındaki sunucu metrikleriyle birlikte değerlendirin.

1. TTFB ve sunucu kaynakları

TTFB’yi yorumlarken ağ gecikmesini de hesaba katın. Sunucu tarafında aşağıdaki etkenler süreyi artırabilir; bunlar birbirinden bağımsız, doğrudan toplanacak süreler değildir:

• 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 (örneğin SATA SSD ve NVMe SSD performansı),
• 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ı (yoğun swap giriş/çıkışı ciddi yavaşlamaya yol açabilir),
• 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 ele aldık.

2. PHP ve veritabanı ayarları

PHP tarafında:

• max_execution_time, PHP yürütme süresini sınırlar; süre hesabı platforma ve PHP derlemesine bağlıdır. Veritabanı beklemeleri her ortamda aynı şekilde hesaba katılmaz; bu ayarı sorguyu kesin olarak durduran bir sınır gibi yorumlamayın. Yüksek değer tek başına CPU’yu kilitlemez. Kullanılan PHP yapılandırmasını ve ayrı web sunucusu zaman aşımlarını kontrol edin; script, sorgu ve işçi bekleme sürelerini ayrı inceleyin.
• memory_limit, bir PHP script’inin ayırabileceği belleği sınırlar. İzin verilen bellek tahsisi aşıldığında ölümcül bellek hatası oluşabilir; düşük limit doğrudan bir yavaşlatma mekanizması değildir. Hata kayıtlarını ve script’in bellek ihtiyacını inceleyerek limiti sunucunun kapasitesine uygun belirleyin.
• 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), teşhis ihtiyacına uygun eşik ve kayıt saklama süresiyle kullanılmalı,
• 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.

Paylaşımlı hosting, VPS, dedicated sunucu ve colocation seçeneklerini kaynak, yönetim ve taşıma ihtiyaçlarına göre karşılaştırın. NVMe depolama gereksinimini ve büyüme sırasında veri taşıma, kesinti ve geri dönüş adımlarını seçilecek plan için ayrıca değerlendirin.

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: Türkiye’deki hedef kitleyi temsil eden bir nokta; bu yoksa yakın bir Avrupa noktası kullanın ve lokasyon farkını sonuçlara not edin.
• 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. Sepet ve ödeme testlerinde aynı test ürünlerini sepete ekleyin ve ilgili oturumu koruyun; yalnızca boş sepet URL’sini açmakla yetinmeyin. Test hesabı ve örnek veriler kullanın; ödeme akışını test modunda tutun.

2. GTmetrix ile ilk teşhis

GTmetrix’te önce herkese açık kategori ve ürün URL’lerini ölçün. Sepet ve ödeme akışı için kullandığınız plan ve test ortamının gerekli oturum/çerez aktarımını veya akışı yeniden kuracak senaryo desteğini sunup sunmadığını kontrol edin; kendi tarayıcınızdaki oturumun otomatik aktarılacağını varsaymayın. Desteklenen yöntemle yalnızca test hesabının oturumunu hazırlayın ve testin ürün eklenmiş sepeti, ardından doğru ödeme sayfasını açtığını doğrulayın. Bunu sağlayamıyorsanız bu adımı anonim URL teşhisiyle sınırlayın; boş sepet veya giriş sayfası sonucunu oturumlu ödeme ölçümü diye sunmayın.

Bu varsayımsal örnekte, oturumlu akışın yeniden oluşturulup doğrulandığı bir test ortamında sepet ve ödeme sayfaları için aşağıdaki değerleri ve bulguları elde ettiğinizi varsayalım:

• 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 olabilir; etkilerini karşılaştırmalı testlerle inceleyin.
• Ödeme eklentisi JS dosyaları sayfa başında yükleniyor.
• Birkaç dinamik AJAX isteğinde uzun yanıt bekleme süreleri var; bunları ana HTML isteğinin TTFB’sinden ayrı inceleyin ve sunucu kayıtlarıyla ilişkilendirin.

3. PageSpeed Insights ile Core Web Vitals kontrolü

Standart PageSpeed Insights URL testi, kendi tarayıcınızdaki giriş veya sepet oturumunu devralmaz; yalnızca sepet ya da ödeme URL’sini girmek, ürün eklenmiş akışı yeniden oluşturmaz. Bu adımda herkese açık ürün veya kategori URL’sini ölçün ve laboratuvar sonucunu oturumlu ödeme testiyle eşitlemeyin. Laboratuvar sonuçlarıyla gerçek kullanıcı verilerini de ayrı değerlendirin. Bu varsayımsal örnekte:

• Test edilen herkese açık URL’nin mobil laboratuvar ölçümünde LCP’nin 4+ saniye çıktığını,
• Aynı laboratuvar ölçümünde CLS’nin yüksek olduğunu,
• Yeterli veri bulunan gerçek kullanıcı bölümünde INP’nin yanıt verme sorunu gösterdiğini

varsayalım. Field Data’nın test ettiğiniz URL’ye mi yoksa origin geneline mi ait olduğunu kontrol edin; genel veriyi ödeme adımındaki sorunun kanıtı saymayın. Bu sonuçlar herkese açık sayfadaki inceleme alanlarını gösterir. Ödeme formu alanları ve uyarı kutularındaki olası kaymaları, ayrıca ağır JavaScript işlemlerini ise oturumlu akışı yeniden oluşturabilen ayrı bir testte inceleyerek doğrulayın.

4. WebPageTest ile görsel inceleme

WebPageTest’te oturumlu ödeme incelemesine geçmeden önce, kullandığınız test ortamında gerekli senaryo betiği veya çerez ayarlarının desteklendiğini doğrulayın. Desteklenen yöntemle test ürününü sepete ekleyip oturumu koruyarak ödeme sayfasına ilerleyin; giriş gerekiyorsa test hesabını kullanın. Bu akışı kuramıyorsanız herkese açık URL’lerle sınırlı kalın. Aşağıdaki varsayımsal gözlemler, ürün eklenmiş sepet ve doğru ödeme sayfasının açıldığı doğrulanmış bir akış içindir:

• First View ve Repeat View’da aynı test hesabı ve sepet içeriğiyle doğru ödeme sayfasının açıldığını kontrol ediyor, ardından kaynakların yeniden kullanımını ve yükleme sürelerini karşılaştırıyorsunuz. Tekrar yüklemenin tüm önbellek katmanlarının sıcak olduğunu kanıtlamadığını, kişiye özel sepet ve ödeme yanıtlarının paylaşılan tam sayfa önbelleğinden sunulmaması gerektiğini dikkate alıyorsunuz.
• Filmstrip’ten bakınca, ödeme formunun geç çizildiğini, üstteki banner ve kampanya görsellerinin daha önce göründüğünü fark ediyorsunuz.

Bu görsel geri bildirim, kritik içeriğin neden geç göründüğünü araştırmanıza yardımcı olur. Waterfall ve JavaScript incelemesiyle birlikte, kritik içeriği öne çekme ve uygun script’leri erteleme (defer) seçeneklerini değerlendirin; değişikliklerden sonra ödeme işlevlerinin bozulmadığını test modunda kontrol edin.

5. Sunucu tarafını izlemek

Bu testlerle aynı zaman aralığında, sunucu metriklerine erişiminiz varsa örneği şu varsayımsal gözlemlerle tamamlayabilirsiniz:

• CPU kullanımının yoğun saatte %90’lara vurduğunu,
• PHP-FPM havuzunda meşgul işçi süreç 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özlemlediğinizi varsayalım. Bu tablo, CPU kapasitesi ve veritabanı sorgularını öncelikli inceleme alanları yapar; asıl darboğazı belirlemek için bulguları yavaş isteklerin zamanları ve uygulama kayıtlarıyla eşleştirin.

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; kapasite yetersizliği doğrulanırsa CPU/RAM ihtiyacını karşılayan bir VPS veya dedicated planı değerlendirmek. Disk I/O yeterliyse, yalnızca NVMe depolamaya geçişi CPU darboğazının çözümü saymamak.
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.

Her değişiklikten sonra aynı URL, cihaz, bağlantı, lokasyon, oturum ve önbellek koşullarıyla tekrarlı ölçüm yapın; sonuçları başlangıç ölçümleriyle karşılaştırın. Böylece 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 ve kritik işlev kontrolleriyle birlikte, iyileşmeyi ölçebilir ve olası gerilemeleri fark edebilirsiniz.

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 yükleme, etkileşime yanıt ve görsel kararlılık performansını değerlendirmek.
• 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.

Paylaşımlı hosting, VPS, dedicated sunucu veya colocation seçeneğini değerlendirirken hız testlerini yalnızca “rapor üretme” aracı olarak değil, somut aksiyon planı çıkarmak için kullanabilirsiniz. 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. Kapasite ihtiyacı doğrulanırsa hosting, VPS veya dedicated seçeneklerini ölçülen kaynak gereksinimleri ve toplam maliyet üzerinden karşılaştırın.