Site hız testi yapmak için bir aracın URL kutusuna adresinizi yazıp çalıştırmanız yeterlidir; asıl iş, çıkan sonucu doğru okumaktır. Tek bir 0-100 skoruna takılmak yerine LCP, INP ve CLS metriklerini, bunların laboratuvar mı yoksa gerçek kullanıcı verisi mi olduğunu ve hangi düzeltmenin en çok etki getireceğini ayırt etmeniz gerekir. Bu yazıda testi adım adım yapmayı ve sonucu yorumlamayı birlikte ele alıyoruz.
Hız testi, çoğu kişinin sandığından daha katmanlı bir konudur. Aracı çalıştırmak saniyeler sürer, ama o ekrandaki sayıların ne anlama geldiğini bilmeden yapılan optimizasyon genellikle yanlış yere harcanan emek olur. Site neden hızlı olmalı sorusunun cevabı ise basit: yavaş açılan bir sayfada ziyaretçi beklemez, geri döner. Site hızı hem kullanıcı deneyimini hem de arama görünürlüğünü doğrudan etkilediği için, ölçmeyi ve okumayı öğrenmek teknik SEO'nun temel taşlarından biridir. Aşağıda hem testi nasıl yapacağınızı hem de raporu nasıl çözeceğinizi anlatıyoruz.
Hız testi nasıl yapılır: adım adım
Temel akış her araçta benzerdir, ama doğru sonuç almak için birkaç noktaya dikkat etmek gerekir.
- Doğru sayfayı seçin. Yalnızca ana sayfayı test etmek yanıltıcıdır. Ana sayfa, ürün sayfası, blog yazısı ve kategori sayfası gibi farklı şablonları ayrı ayrı test edin, çünkü her birinin yük profili farklıdır.
- Aracı çalıştırın. Sayfanın tam adresini test kutusuna yapıştırın ve analizi başlatın. Sonucun gelmesi birkaç saniye sürer.
- Mobil ve masaüstü sekmelerini ayrı okuyun. İki sonuç birbirinden ciddi biçimde farklı olabilir.
- Testi birkaç kez tekrarlayın. Laboratuvar verisi tek seferlik bir ölçümdür ve ağ dalgalanmasından etkilenebilir; istikrarlı bir resim için aynı testi tekrarlamak iyi bir alışkanlıktır.
Bu dört adım veriyi toplamanızı sağlar. Asıl beceri, gelen rakamları yorumlamakta ortaya çıkar.
Hız testi araçları ve hangisi ne işe yarar
Piyasada onlarca araç var, ama hepsi aynı şeyi ölçmez. En sık kullanılanları ne verdiklerine göre gruplamak, kafa karışıklığını baştan engeller.
- PageSpeed Insights (PSI): Hem laboratuvar hem saha verisi gösteren tek ücretsiz Google aracı budur. Başlangıç için en kapsamlı seçenektir.
- Lighthouse / Chrome DevTools: Tamamen laboratuvar verisi üretir. Bir değişiklik yapıp anında etkisini görmek istediğinizde idealdir, çünkü kontrollü ve tekrarlanabilir.
- Search Console Core Web Vitals raporu: Yalnızca gerçek kullanıcı (saha) verisini, URL grupları halinde gösterir. Sitenin genel sağlığını izlemek için en doğru yerdir.
- WebPageTest ve GTmetrix: Detaylı laboratuvar testleri için kullanılır; farklı konum, cihaz ve bağlantı koşullarını simüle etmenize izin verirler.
Pratik yaklaşım şudur: genel resmi PSI ve Search Console'dan okuyun, tek bir değişikliğin etkisini Lighthouse ile ölçün, derin teşhis için WebPageTest'e geçin.
Lab verisi ile saha verisi farkı
Birçok Türkçe kaynağın atladığı, ama her şeyi açıklayan ayrım budur. Aynı sayfa için PSI'da iki farklı sonuç görmenizin sebebi genellikle burada gizlidir.
Google for Developers'ın PageSpeed Insights dokümantasyonuna göre laboratuvar verisi, tek bir cihazda ve sabit ağ koşullarında yapılan simüle edilmiş bir yükleme testidir. Saha verisi ise gerçek kullanıcıların tarayıcılarından toplanan geçmişe dönük bir rapordur. Yani ikisi farklı doğaya sahiptir ve aynı URL için farklı değerler vermesi tamamen normaldir.
Saha verisinin kaynağı, aynı dokümana göre Chrome User Experience Report (CrUX) veri kümesidir ve son 28 günlük toplama dönemindeki FCP, INP, LCP ve CLS deneyimlerini yansıtır. PSI'daki saha verisi günlük güncellenir; BigQuery üzerindeki CrUX veri kümesi ise aylık güncellenir ve yalnızca origin (alan adı) düzeyindedir.
Pratik kural: Laboratuvar verisi "bu sayfa teknik olarak ne kadar hızlı olabilir" sorusunu, saha verisi ise "kullanıcılarım gerçekte ne yaşıyor" sorusunu yanıtlar. Karar verirken saha verisi her zaman önceliklidir, çünkü Google'ın değerlendirmesi de ona dayanır.
Skor mu, metrik mi?
En yaygın hata, 0-100 arası Lighthouse skorunu hız metrikleriyle karıştırmaktır. Bunlar farklı şeylerdir.
Lighthouse performans skoru, birden çok laboratuvar metriğinin ağırlıklı bir özetidir. Google for Developers, skor bantlarını net biçimde tanımlar: 90 ve üzeri iyi, 50-89 arası iyileştirme gerektiriyor, 50'nin altı zayıf kabul edilir. Bu skor bir teşhis aracıdır, sıralama faktörü değildir.
Asıl önemli olan ham metriklerdir, yani saniye ve milisaniye cinsinden ölçülen gerçek değerler. Google'ın Web Vitals tanımına göre üç Core Web Vital ve "iyi" eşikleri şöyledir:
- LCP (Largest Contentful Paint): 2,5 saniye veya altı iyidir. Ana içeriğin yüklenme hızını ölçer.
- INP (Interaction to Next Paint): 200 milisaniye veya altı iyidir. Sayfanın etkileşimlere ne kadar hızlı yanıt verdiğini ölçer.
- CLS (Cumulative Layout Shift): 0,1 veya altı iyidir. Sayfa yüklenirken öğelerin ne kadar kaydığını, görsel kararlılığı ölçer.
Dikkat etmeniz gereken bir güncellik noktası var: eski INP metriği daha önce FID (First Input Delay) idi. Birçok Türkçe yazı hâlâ FID'den bahsediyor, ama Core Web Vitals üçlüsü artık LCP, INP ve CLS'tir. Eğer bir kaynak size FID'i ölçün diyorsa, o içerik güncelliğini yitirmiş demektir.
75. persentil neden önemli
Web Vitals dokümanına göre Core Web Vitals ortalama üzerinden değil, sayfa yüklemelerinin 75. persentili üzerinden değerlendirilir ve mobil ile masaüstü cihazlar ayrı segmentlenir. Yani kullanıcılarınızın en yavaş yaşayan dörtte birini dışarıda bırakıp geri kalanın değeri esas alınır. Ortalama, birkaç hızlı yüklemenin gizlediği kötü deneyimleri saklayabilir; 75. persentil bu yüzden daha dürüst bir ölçüdür.
Bunun bir yan etkisi de şudur: trafiği düşük sitelerde saha verisi hiç görünmeyebilir. CrUX yeterli örnek toplayamadığında PSI yalnızca laboratuvar verisi gösterir. Bu durumda Lighthouse sonuçlarına ve sektör tecrübenize dayanmak zorunda kalırsınız.
Darboğaz tespiti: rapordaki asıl değer
Skoru gördükten sonra iş asıl burada başlar. PSI raporunun alt kısmındaki "Diagnostics" ve "Opportunities" (Teşhis ve Fırsatlar) bölümleri, neyin yavaşlattığını söyler. Çoğu kişi yukarıdaki sayıya bakıp burayı atlar; oysa düzeltilecek işlerin listesi tam olarak buradadır.
Tipik darboğazlar şunlardır:
- Sunucu yanıt süresi (TTFB): Tarayıcı ilk baytı almak için çok bekliyorsa sorun hosting, sunucu veya backend tarafındadır. Bu yavaşsa diğer her şey de gecikir, bu yüzden genellikle ilk bakılacak yerdir.
- Render-blocking kaynaklar: Sayfa çizilmeden önce yüklenmesi zorunlu olan CSS ve JavaScript dosyaları ilk görüntülenmeyi geciktirir.
- Üçüncü taraf scriptler: Analitik, sohbet widget'ları, reklam ve takip kodları çoğu zaman fark edilmeden INP ve yükleme süresini bozar.
- Optimize edilmemiş görseller: Büyük boyutlu ve yanlış formattaki görseller LCP'nin en sık sebebidir.
Raporu okurken her satırın hangi metriği etkilediğini not edin. Bir öneri LCP'yi mi yoksa CLS'yi mi iyileştiriyor sorusu, sıradaki adımı belirler. Araçların "tahmini tasarruf" değerleri de yol göstericidir, ama bunlar laboratuvar tahminidir; gerçek etkiyi düzeltmeyi yaptıktan sonra saha verisinden teyit etmek gerekir. Kısacası teşhis bölümünü bir alışveriş listesi gibi değil, etkisine göre sıralanacak bir aday listesi gibi okuyun.
Veri-odaklı önceliklendirme
Çoğu rehber size uzun bir "yapılacaklar" listesi verip hepsini sırayla yapmanızı söyler. Bu, en az verimli yaklaşımdır. Doğrusu, etkiye göre önceliklendirmektir.
Mantık basittir: önce hangi metriğin eşiğin altında olduğunu bulun, sonra o metriği etkileyen en büyük darboğazı düzeltin. Search Console'un Core Web Vitals raporu burada kritik bir ipucu verir. Search Console Yardım dokümanına göre bu rapor gerçek kullanıcı (saha) CrUX verisine dayanır ve her URL grubuna, en kötü performans gösteren metriğine göre bir durum atar: İyi, İyileştirme gerektiriyor veya Yavaş. Yani bir grubun durumunu belirleyen şey, en zayıf metriğidir.
Bu da önceliklendirmeyi netleştirir: önce "Yavaş" işaretli grupları, sonra onların en kötü metriğini hedefleyin. LCP zayıfsa görsel ve sunucu yanıtına, INP zayıfsa JavaScript ve üçüncü taraf scriptlere, CLS zayıfsa boyutu belirtilmemiş görsellere ve geç yüklenen yazı tiplerine odaklanın. Tek bir doğru düzeltme, dağınık on küçük müdahaleden daha çok kazandırır.
Mobil ile masaüstü farkı
Neredeyse tüm rehberlerin atladığı bir nokta var: aynı site mobilde ve masaüstünde çok farklı performans gösterir. Web Vitals değerlendirmesi de zaten bu ikisini ayrı segmentler. Mobil cihazlar genellikle daha zayıf işlemciye ve daha değişken ağ koşullarına sahiptir, dolayısıyla mobil skorlar çoğu zaman masaüstünden düşüktür. Testlerinizi her iki sekmede de ayrı okuyun ve ziyaretçilerinizin büyük kısmı mobildense, önceliği mobil sonuçlara verin. Hangi cihazın daha ağırlıklı olduğunu görmek için Analytics verilerinize bakabilirsiniz; çoğu sektörde mobil trafik baskın olduğu için varsayılan olarak mobil performansa yatırım yapmak genellikle daha mantıklıdır. Masaüstünde iyi, mobilde zayıf bir sonuç gördüğünüzde, sorun büyük ihtimalle ağır JavaScript yükü ya da mobil cihazların sınırlı işlem gücüyle baş edemediği bir bileşendir.
Wix, Ikas ve özel sitelerde yorumlama
Hangi platformda olduğunuz, raporu okumayı değil, neye müdahale edebileceğinizi değiştirir.
- Wix ve Ikas gibi platformlar: Sunucu altyapısı, CDN ve temel kod platformun kontrolündedir, yani TTFB veya çekirdek script yükleme davranışına doğrudan dokunamazsınız. Buna karşılık görsel optimizasyonu, eklenti ve üçüncü taraf script sayısını azaltma, gereksiz uygulamaları kaldırma gibi alanlarda hâlâ ciddi kazanç elde edebilirsiniz.
- Özel (custom) siteler: Burada her katman sizin elinizdedir; sunucu yanıt süresinden render-blocking kaynaklara kadar her darboğazı doğrudan düzeltebilirsiniz.
Yani platform tabanlı bir sitede raporu okurken "bunu düzeltebilir miyim" filtresini de uygulamanız gerekir. Düzeltemeyeceğiniz bir TTFB sorununa saatler harcamak yerine, kontrolünüzdeki görsel ve script tarafına yüklenmek daha akılcıdır. Platform sınırları sizi rahatlatabilir de: çekirdek altyapı zaten optimize edilmiş geldiği için enerjinizi yalnızca sizin eklediğiniz içerik ve uygulamalara odaklayabilirsiniz.
Özetle
Site hız testini yapmak kolaydır, ama değer yorumlamadadır. Tek bir 0-100 skoruna saplanmayın; LCP, INP ve CLS ham metriklerine, bunların saha mı laboratuvar mı verisi olduğuna ve 75. persentil mantığına bakın. Darboğazı PSI'nin teşhis bölümünden bulun, Search Console'un saha verisiyle doğrulayın ve en kötü metrikten başlayarak etkiye göre önceliklendirin. Bu disiplin, dağınık optimizasyon listelerinden çok daha hızlı sonuç verir. Hız testini tek seferlik bir kontrol değil, düzenli tekrarlanan bir alışkanlık olarak görün; her yeni özellik, görsel ya da üçüncü taraf script eklediğinizde performans değişebilir, bu yüzden testi düzenli aralıklarla yinelemek en sağlıklı yaklaşımdır.
VixSEO, Wix, Ikas ve özel siteler için Core Web Vitals ve teknik SEO takibini tek panelden yapmanıza yardımcı olur; hangi metriğin geride olduğunu ve önce neye dokunmanız gerektiğini sizin için netleştirir. Araçları ve hizmetleri incelemek isterseniz VixSEO araçlarına ve hizmetlerimize göz atabilirsiniz.