GTmetrix ile WordPress Hiz Testi Nasil Yapilir

WordPress sitenizin "yavaş" olduğunu hissetmek başka şey, bunu ölçülebilir sayılara dökmek başka şeydir. "Site geç açılıyor" cümlesiyle bir sorunu çözemezsiniz; ama "ana sayfa 3.8 saniyede yükleniyor, bunun 1.9 saniyesi sunucunun ilk yanıt vermesinde harcanıyor ve tek başına 1.2 MB'lık bir slider görseli var" dediğinizde elinizde üzerine gidilecek somut bir hedef vardır. GTmetrix tam olarak bu dönüşümü yapan araçtır: soyut bir yavaşlık hissini, üzerinde çalışabileceğiniz bir teşhis raporuna çevirir.

Bu rehberde GTmetrix arayüzünü baştan sona gezeceğiz. Test konumu ve tarayıcı seçiminin sonucu nasıl değiştirdiğini, Grade ile Performance ve Structure skorlarının ne anlama geldiğini, Waterfall (şelale) grafiğinde yavaş istekleri nasıl ayıklayacağınızı, TTFB ile toplam sayfa boyutunu nasıl yorumlayacağınızı adım adım göreceğiz. En önemlisi de şunu vurgulayacağım: amaç yeşil bir "A" harfi toplamak değil, gerçek ziyaretçinizin sayfayı ne kadar hızlı kullanabildiğini iyileştirmektir. Skor, aracın değil sizin hedeflerinize hizmet etmelidir.

GTmetrix Neyi Ölçer ve Neden PageSpeed'den Farklıdır#

GTmetrix, bir sayfayı gerçek bir tarayıcıyla açıp yükleme sürecini kaydeden bir laboratuvar (lab) test aracıdır. Girdiğiniz URL'yi kendi sunucularındaki bir tarayıcıda çalıştırır, her isteği zaman damgasıyla kaydeder ve size bir performans raporu üretir. 2020 sonrası GTmetrix, ölçüm motoru olarak Google'ın Lighthouse'unu kullanır; yani gördüğünüz metrikler (LCP, TBT, CLS) büyük ölçüde Google'ın PageSpeed Insights ile aynı kaynaktan gelir. Fark, GTmetrix'in bu verileri çok daha okunabilir bir arayüzde, özellikle de güçlü bir Waterfall grafiğiyle sunmasıdır.

Burada kritik bir ayrımı baştan netleştirelim. GTmetrix "lab veri" üretir: kontrollü, tekrarlanabilir, tek bir sanal ziyaretçinin sonucu. Google Search Console'daki Core Web Vitals raporu ise "saha verisi" (field data, CrUX) gösterir: gerçek kullanıcılarınızın gerçek cihaz ve bağlantılarından toplanan ortalamalar. İkisi çoğu zaman uyuşmaz ve bu normaldir. GTmetrix'te "A" almanız, Search Console'da Core Web Vitals'ın yeşil olacağını garanti etmez. Doğru yaklaşım şudur: hızlı, tekrarlanabilir teşhis için GTmetrix'i kullanın; nihai başarı ölçütü olarak gerçek kullanıcı verisini baz alın. Bu ikisi arasındaki köprüyü kurmak, bu rehberin ana amacıdır.

Şunu da unutmayın: GTmetrix her testte sayfayı önbelleksiz (cold) ya da tek seferlik açar. Sitenizde bir sayfa önbellekleme (page cache) eklentisi varsa, ilk test önbelleği "ısıtır", ikinci test çok daha hızlı çıkar. Bu yüzden bir sayfayı hep aynı koşulda, tercihen 2-3 kez test edip sonuçların oturduğu değeri baz almak gerekir.

Test Konumu ve Tarayıcı Seçimi Neden Belirleyici#

GTmetrix'in en çok yanlış yorumlanan ayarı test konumudur. Ücretsiz hesapta test varsayılan olarak Kanada, Vancouver sunucusundan yapılır. Sunucunuz Türkiye'de veya Almanya'daysa, Vancouver'dan yapılan test, ziyaretçinizin gerçekte yaşadığı gecikmeyi değil, okyanus aşırı bir bağlantının gecikmesini ölçer. Bu durumda TTFB olduğundan çok daha yüksek görünür ve siz aslında var olmayan bir sunucu sorununu kovalamaya başlarsınız.

Kural basittir: test konumunu, hedef kitlenizin coğrafi olarak en yoğun olduğu yere en yakın seçin. Türkiye'ye hitap eden bir site için Londra veya Frankfurt, Vancouver'dan çok daha anlamlıdır; ücretli hesaplarda İstanbul dahil daha fazla konum açılır. Aynı sayfayı iki farklı konumdan test edip aradaki TTFB farkını görmek, sorunun sunucu işlem süresinde mi yoksa ağ mesafesinde mi olduğunu anlamanın en pratik yoludur.

Aşağıdaki tablo, konum seçiminin aynı site için sonuçları nasıl değiştirdiğine dair tipik bir örneği gösterir.

Tarayıcı ve cihaz seçimi de aynı derecede önemlidir. GTmetrix, Chrome üzerinde masaüstü veya çeşitli mobil profillerle test yapmanıza izin verir; ücretli planlarda bağlantı hızını (örneğin "Broadband Fast" yerine yavaş bir 4G) sınırlandırabilirsiniz. Trafiğinizin büyük kısmı mobildeyse, masaüstü hızlı bağlantıyla test edip "her şey yolunda" demek kendinizi kandırmaktır. Analytics'inizden cihaz dağılımını kontrol edin ve testi ona göre kurgulayın. Mobil ve yavaş bağlantı, Total Blocking Time gibi JavaScript kaynaklı metrikleri acımasızca ortaya çıkarır.

Rapor Özeti Grade, Performance ve Structure#

Test bittiğinde karşınıza çıkan ilk ekran özet karnesidir. En üstte büyük bir harf notu (Grade, A'dan F'ye) ve onun hemen altında iki yüzde vardır: Performance ve Structure. Bu üç değeri karıştırmamak, raporu doğru okumanın temelidir.

Performance skoru, sayfanın gerçekten ne kadar hızlı yüklendiğini ölçen Lighthouse metriklerinin ağırlıklı ortalamasıdır. Bu bölümdeki değerler ziyaretçinin deneyimiyle doğrudan ilişkilidir. Öne çıkan metrikler şunlardır:

• LCP (Largest Contentful Paint): Sayfadaki en büyük görünür öğenin (genellikle hero görseli veya başlık) ne zaman boyandığı. Kullanıcının "sayfa yüklendi" hissettiği andır. 2.5 saniyenin altı iyidir.
• TBT (Total Blocking Time): Ana iş parçacığının JavaScript yüzünden ne kadar süre kilitli kaldığı. Yüksek TBT, tıklamalara geç yanıt veren bir site demektir.
• CLS (Cumulative Layout Shift): Yükleme sırasında öğelerin ne kadar zıpladığı. Reklam veya geç yüklenen görseller yüzünden sayfanın "oynaması" burada cezalanır.

Structure skoru ise farklı bir şey ölçer: sayfanın optimizasyon açısından "kitaba uygunluğu". Görseller sıkıştırılmış mı, önbellek başlıkları doğru mu, kullanılmayan CSS var mı gibi kontrollerin sonucudur. Structure yüksek ama Performance düşük olabilir; bu, "her şeyi doğru yapmışsınız ama sunucu yavaş" anlamına gelir. Tersi de mümkündür. Bu yüzden tek bir harfe bakıp karar vermeyin; asıl teşhis, Performance metrikleri ile birazdan gireceğimiz Waterfall'da saklıdır.

Waterfall Grafiğini Okumak İşin Kalbi#

GTmetrix'in gerçek gücü Waterfall (şelale) sekmesindedir. Bu grafik, sayfanın yüklenirken yaptığı her tek isteği (HTML, CSS, JS, görsel, font, üçüncü taraf script) soldan sağa zaman ekseninde, alt alta çubuklar halinde gösterir. Her çubuğun uzunluğu o isteğin ne kadar sürdüğüdür; renkler ise sürenin nerede harcandığını (DNS, bağlantı, sunucu bekleme, indirme) ayırır. Darboğazları burada gözle görürsünüz.

Waterfall'a bakarken şu üç kalıbı arayın. Birincisi, en üstteki ilk isteğin (belgenin kendisi) sarı "Waiting/TTFB" kısmının uzunluğudur; burası uzunsa sorun sunucu tarafındadır. İkincisi, tek başına çok uzun ve kalın bir çubuk; bu genellikle sıkıştırılmamış dev bir görsel ya da yavaş bir üçüncü taraf script'idir. Üçüncüsü, birbirini bekleyen uzun bir "merdiven" görüntüsü; bu, dosyaların paralel değil sıralı yüklendiğini, yani render'ı bloklayan (render-blocking) CSS/JS olduğunu gösterir.

Waterfall'da renklerin ne anlama geldiğini akılda tutmak yorumu kolaylaştırır:

Pratik bir örnek: Waterfall'da wp-content/uploads/2026/slider-hero.jpg isteğinin 1.4 saniye sürdüğünü ve yeşil (indirme) kısmının kocaman olduğunu görüyorsanız, teşhis nettir: bu görsel çok büyük. Çözüm de bellidir: görseli WebP'ye çevirip boyutunu küçültmek, gerekiyorsa srcset ile responsive sunmak. Benzer şekilde, googletagmanager.com veya bir sohbet widget'ının script'i 900 ms bloklama yapıyorsa, o üçüncü taraf aracı geciktirerek (defer) veya kullanıcı etkileşiminden sonra yüklemeyi düşünürsünüz. Bu tür görsel ve script optimizasyonlarının WordPress tarafındaki uygulamasını WordPress hız optimizasyonu rehberimizde adım adım ele alıyoruz.

TTFB Toplam Boyut ve İstek Sayısını Yorumlamak#

Waterfall'da gözle gördüğünüzü sayılarla doğrulamak için üç metrik yeterlidir: TTFB, toplam sayfa boyutu ve toplam istek sayısı. Bu üçlüyü doğru okumak, "sorun sunucumda mı yoksa sayfamın ağırlığında mı" sorusunu çoğu zaman tek başına yanıtlar.

TTFB (Time To First Byte), tarayıcının isteği yolladığı andan sunucunun ilk baytı gönderdiği ana kadar geçen süredir. Bu, saf sunucu tepki süresidir: DNS, TLS, PHP işleme ve veritabanı sorgularının toplamı. WordPress'te yüksek TTFB'nin en yaygın sebebi sayfa önbelleğinin olmaması ya da yetersiz sunucu kaynağıdır. Terminalden hızlıca ölçmek isterseniz curl yeterlidir:

# TTFB'yi saniye cinsinden ölç (birkaç kez çalıştırıp ortalamayı al)
curl -o /dev/null -s -w "TTFB: %{time_starttransfer}s | Toplam: %{time_total}s\n" \
  https://siteadresiniz.com/

Kabaca bir yorum ölçeği verelim: 200 ms altı mükemmel, 200-500 ms iyi, 500-800 ms iyileştirilebilir, 800 ms üstü ise ziyaretçinin fark ettiği bir gecikmedir ve öncelikli sorununuz büyük olasılıkla sunucu/önbellek tarafındadır. TTFB'yi düşürmenin en etkili yolu, WordPress önünde bir sayfa önbelleği çalıştırmaktır. Nginx tarafında basit bir FastCGI cache tanımı şuna benzer:

# Nginx FastCGI önbellek bölgesi tanımı (http bloğunda)
fastcgi_cache_path /var/run/nginx-cache levels=1:2
    keys_zone=WORDPRESS:100m inactive=60m max_size=500m;

server {
    set $skip_cache 0;
    # Giriş yapmış / sepeti olan kullanıcıyı önbelleğe alma
    if ($http_cookie ~* "wordpress_logged_in|woocommerce_cart_hash") {
        set $skip_cache 1;
    }

    location ~ \.php$ {
        fastcgi_cache WORDPRESS;
        fastcgi_cache_valid 200 60m;
        fastcgi_cache_bypass $skip_cache;
        fastcgi_no_cache $skip_cache;
        add_header X-Cache $upstream_cache_status;
    }
}

Toplam sayfa boyutu, tüm kaynakların (HTML, CSS, JS, görsel, font) indirilen toplam ağırlığıdır. Modern bir içerik sayfası için 1-2 MB makul, 3 MB üstü ağır, 5 MB ve ötesi ise mobil kullanıcı için ciddi bir yüktür. GTmetrix bu boyutu içerik türüne göre de ayırır; neredeyse her zaman en büyük dilim görsellerdir. Toplam istek sayısı ise ayrı bir sinyaldir: 100 isteğin altı sağlıklı, 150 üstü genellikle "çok fazla eklenti, çok fazla üçüncü taraf script" demektir. Her istek ek bir bağlantı ve gecikme maliyeti taşır; bu yüzden CSS/JS dosyalarını birleştirmek ve gereksiz eklentileri kapatmak istek sayısını hızla düşürür.

Bu üç metriği birlikte okumanın pratik bir çerçevesi:

• TTFB yüksek, boyut düşük ise sorun sunucu/önbellektedir; barındırma ve cache'e odaklanın.
• TTFB düşük, boyut yüksek ise sorun sayfanın ağırlığındadır; görsel ve script optimizasyonuna gidin.
• İkisi de yüksek ise önce TTFB'yi (önbellek), sonra boyutu ele alın.

Skora Takılmadan Gerçek Kullanıcı Hızına Odaklanmak#

Şimdi bu rehberin en önemli mesajına geldik. GTmetrix'te "A" görmek tatmin edicidir ama tek başına bir amaç değildir. Skoru maksimize etmek uğruna gerçekte kimsenin fark etmediği mikro optimizasyonlara saatler harcarken, ziyaretçinin ilk gördüğü hero görselini ya da yavaş sunucu yanıtını görmezden gelmek çok yaygın bir hatadır. Aracın notu, kullanıcının sabrının yerine geçmez.

Doğru pusula şudur: LCP, TTFB ve etkileşime hazır olma süresi (TBT/TTI) gibi kullanıcının doğrudan hissettiği metrikleri iyileştirin. "Kullanılmayan CSS'i kaldır" gibi Structure uyarıları, birkaç saniyelik LCP sorununuz varken önceliğiniz olmamalıdır. Bir başka deyişle, önce ziyaretçinin bekleme süresini kısaltan büyük kazanımları toplayın; kırıntı niyetine kalan skor puanları en sona kalsın.

Lab verisiyle saha verisi arasındaki farkı da hep aklınızda tutun. GTmetrix size mükemmel bir sonuç verirken Search Console'daki Core Web Vitals kırmızı olabilir; çünkü gerçek kullanıcılarınız daha yavaş cihazlarda, daha zayıf bağlantılarda ve önbelleği ısıtmadan siteye giriyordur. Bu yüzden GTmetrix'i "değişikliğim işe yaradı mı?" sorusunu hızlı yanıtlamak için kullanın, ama nihai kararı gerçek kullanıcı verisiyle verin. Hız çalışmasının SEO tarafındaki karşılığını ve arama motorlarının bu metrikleri nasıl değerlendirdiğini WordPress SEO başlangıç rehberimizde bulabilirsiniz.

Son olarak, ölçümü bir alışkanlık haline getirin. Her büyük değişiklikten (yeni eklenti, tema güncellemesi, CDN devreye alma) önce ve sonra aynı sayfayı, aynı konumdan test edip sonuçları kaydedin. Böylece "sitenin yavaşlaması"nı tahmin etmek yerine hangi değişikliğin neye yol açtığını sayıyla görürsünüz. Performans, tek seferlik bir görev değil, düzenli bakımı olan bir süreçtir.

Sıkça Sorulan Sorular#

GTmetrix'te neden her testte farklı sonuç alıyorum#

Sonuçların testten teste bir miktar oynaması tamamen normaldir çünkü ölçüm anlık ağ koşullarına, sunucu yüküne ve önbellek durumuna duyarlıdır. İlk test sayfa önbelleğini "soğuk" bulup ısıtabilir, ikincisi ısınmış önbellekten çok daha hızlı çıkabilir. Doğru yaklaşım, aynı sayfayı aynı test konumundan 2-3 kez çalıştırıp sonuçların oturduğu tutarlı değeri baz almaktır; tek bir testin uç sonucuna bakıp panik yapmamak gerekir.

GTmetrix skorumun düşük çıkması Google sıralamamı doğrudan bozar mı#

Hayır, GTmetrix'in verdiği harf notu Google'ın kullandığı bir sıralama sinyali değildir; Google kendi saha verisini (Core Web Vitals, CrUX) kullanır. GTmetrix bir teşhis aracıdır ve genellikle Google'ın da baktığı Lighthouse metriklerini ölçtüğü için yol gösterir, ama nihai referansınız Search Console'daki Core Web Vitals raporu olmalıdır. Yani düşük GTmetrix skoru bir uyarıdır; gerçek etkiyi görmek için gerçek kullanıcı verisine bakın.

Test konumunu değiştirince TTFB neden bu kadar oynuyor#

TTFB'nin içinde sunucunun işlem süresi kadar ağ mesafesinden kaynaklanan gecikme de vardır. Sunucunuz Almanya'daysa ve testi Kanada'dan yaparsanız, kıtalar arası mesafe TTFB'yi yapay olarak şişirir ve olmayan bir sorunu kovalarsınız. Bu yüzden test konumunu hedef kitlenize coğrafi olarak en yakın seçmelisiniz; aynı sayfayı yakın ve uzak konumdan test edip farkı görmek, sorunun sunucuda mı yoksa mesafede mi olduğunu anlamanın en pratik yoludur.

Waterfall grafiğinde neye öncelik vermeliyim#

Önce en üstteki ilk isteğin sarı Waiting/TTFB kısmına bakın; burası uzunsa sorun sunucu tarafındadır ve önbellekle başlamalısınız. Ardından tek başına en uzun ve en kalın çubukları arayın; bunlar genellikle sıkıştırılmamış dev görseller veya yavaş üçüncü taraf script'lerdir ve en büyük kazanımı bunları düzelterek elde edersiniz. Yüzlerce küçük isteği tek tek kovalamak yerine, birkaç büyük darboğazı çözmek toplam süreyi çok daha fazla kısaltır.

Sayfa boyutunu düşürmek için ilk olarak neye bakmalıyım#

Neredeyse her zaman ilk suçlu görsellerdir; GTmetrix'in içerik türü dökümünde toplam boyutun büyük kısmının resimlerden geldiğini göreceksiniz. Görselleri WebP veya AVIF formatına çevirip gerçek görüntülenme boyutuna göre ölçeklendirmek ve ekran dışındaki resimleri geç yüklemek (lazy load) çoğu sitede sayfa boyutunu yarıya indirir. Görselleri hallettikten sonra sıra render'ı bloklayan CSS/JS dosyalarını ve gereksiz üçüncü taraf script'lerini azaltmaya gelir.

Mobil mi masaüstü mü test etmeliyim#

İkisini de test etmek en doğrusudur, ancak trafiğinizin ağırlığı hangi cihazdaysa asıl kararı ona göre vermelisiniz. Analytics'inizde ziyaretçilerin çoğu mobilse, masaüstü ve hızlı bağlantıyla iyi sonuç almak sizi yanıltır; mobil profil ve sınırlandırılmış bağlantı, JavaScript'in yol açtığı Total Blocking Time gibi sorunları çok daha net ortaya çıkarır. Gerçek kullanıcı deneyiminizi temsil eden koşulda test etmek, olduğundan iyi görünen bir rapora bakmaktan her zaman daha değerlidir.

Kapanış#

GTmetrix, WordPress sitenizin performansını tahminden çıkarıp ölçülebilir bir zemine oturtur. Doğru test konumunu seçmek, Grade ile Performance ve Structure'ı ayırmak, Waterfall'da gerçek darboğazları görmek ve TTFB, toplam boyut, istek sayısını birlikte okumak; bu dört alışkanlık, çoğu yavaşlık sorununu birkaç dakikada teşhis etmenizi sağlar. Ama unutmayın: harf notu araç için, hız ise ziyaretçiniz içindir. Skora değil, gerçek kullanıcının bekleme süresine odaklanın.

Teşhis kolaydır; asıl fark, altyapıyla açığa çıkar. Yüksek TTFB'nin en yaygın çözümü hızlı bir barındırma ve doğru önbellektir. WordPress projeleriniz için optimize edilmiş WordPress hosting ve genel hosting paketlerimiz düşük TTFB için NVMe ve sunucu düzeyi önbellekle gelir; daha fazla kaynak isteyen projeler için VDS sunucularımızı inceleyebilir, kurulum ve bakımı bize bırakmak isterseniz sunucu yönetimi ve WordPress bakım hizmetlerimizden yararlanabilirsiniz. Hız çalışmanızı bir CDN ve WAF katmanıyla güçlendirmek isterseniz ekibimiz size en uygun kurulumu birlikte tasarlar.