Hızlı Cevap
Sayfa yükleme hızını doğru ölçmek için PageSpeed Insights veya Lighthouse ile lab testini, CrUX ve Search Console ile gerçek kullanıcı verisini, WebPageTest ya da GTmetrix ile waterfall analizini birlikte okuyun. Sonuçlar çelişirse SEO önceliği için field data’yı, hata ayıklama için lab verisini öne alın.
Önemli Noktalar
- Tek skor değil, veri tipi ve test bağlamı belirleyicidir.
- SEO kararlarında p75 field data, hata ayıklamada lab test öne çıkar.
- Mobil skor farkı çoğu kez cihaz, ağ ve script yükünden gelir.
- WebPageTest waterfall, sorunun kaynağını en görünür biçimde ayırır.
Sayfa yükleme hızını ölçmek için hangi araçlar öne çıkar?
Sayfa yükleme hızını ölçmek için tek bir araca bakmak çoğu zaman yanıltır. 2026’da sağlıklı bir okuma için en az üç katmanı birlikte görmek gerekir: lab verisi, gerçek kullanıcı verisi ve istek zinciri. Bu yüzden web sitesi hız testi yaparken PageSpeed Insights, Lighthouse, WebPageTest, CrUX, Search Console ve GTmetrix aynı işin farklı parçalarını tamamlar. Biri hızlı teşhis verir, biri hatayı izole eder, diğeri de sahadaki gerçek deneyimi doğrular.
Tek araç yerine ölçüm katmanları
- PageSpeed Insights, hızlı başlangıç noktasıdır; aynı raporda hem mobil ve masaüstü lab ölçümü hem de varsa field data gösterir.
- Lighthouse, geliştirme sürecinde kod değişikliği sonrası tekrarlanabilir laboratuvar testi için kullanışlıdır.
- WebPageTest, test lokasyonu, ağ kısıtı ve waterfall görünürlüğü sayesinde darboğazı ayırmada öne çıkar.
- CrUX ve Search Console, 28 günlük gerçek kullanıcı davranışını görerek SEO açısından neyin gerçekten sorun olduğunu gösterir.
- GTmetrix, paylaşılabilir rapor ve görsel zaman çizelgesiyle özellikle ekip içi iletişimde pratik bir katman sunar.
Aynı metriğin araçtan araca farklı görünmesi normaldir. Çünkü test cihazı, CPU gücü, ağ kısıtı, lokasyon, tarayıcı motoru ve örneklem penceresi değişir. Örneğin PageSpeed Insights mobil testi emüle edilmiş bir cihaz profiliyle çalışırken, CrUX gerçek Chrome kullanıcılarının anonimleştirilmiş saha verisini toplar. WebPageTest ise seçtiğiniz lokasyona ve bağlantı profiline göre bambaşka bir perspektif sunabilir. Bu nedenle hangi araç daha doğru sorusundan önce hangi veri tipine bakıyorum sorusu gelmelidir.
Pratik kullanımda çerçeve basittir: hızlı kontrol için PageSpeed Insights, ayrıntılı kök neden analizi için WebPageTest veya GTmetrix, canlı kullanıcı deneyimini doğrulamak için CrUX ve Search Console. Site hızı ölçme araçları arasındaki farkı böyle kurduğunuzda, çelişkili skorlar moral bozan bir karmaşa olmaktan çıkar ve karar verdiren bir haritaya dönüşür.
PageSpeed Insights, CrUX ve Search Console verisi neden farklı çıkar?
Google for Developers’ın PageSpeed Insights dokümanında açıkça belirtildiği gibi, bu rapor tek başına bir skor ekranı değildir; aynı URL’de Lighthouse tabanlı lab verisi ile CrUX tabanlı field data yan yana gösterilir. Bu yüzden PageSpeed Insights içinde yüksek performans skoru görüp hemen üst bölümde Core Web Vitals durumunun zayıf kalması teknik olarak çelişki değil, iki farklı ölçüm katmanının aynı sayfada buluşmasıdır.
Search Console tarafındaki farkın ana nedeni ise URL gruplamadır. Google Search Console Help sayfasına göre Core Web Vitals raporu tek bir URL’yi izole etmekten çok benzer sayfaları bir grup olarak değerlendirir ve durumu genelde en kötü metriğe göre sınıflandırır. Yani ürün sayfalarınızdan biri ağırsa, aynı şablondaki diğer URL’lerin raporu da etkilenebilir. Bu nedenle Search Console’da sorun görüp PageSpeed Insights’ta tekil URL testinde daha iyi tablo çıkması oldukça sık rastlanan bir durumdur.
2026 itibarıyla bir diğer kritik nokta, geçmiş ekran görüntülerini bugünkü sonuçlarla bire bir kıyaslamamaktır. 2025 sonundaki Lighthouse 13 geçişi sonrası bazı ağırlıklar, teşhis alanları ve rapor sunumu değiştiği için eski raporda 90 görünen bir sayfanın bugünkü karşılığını sadece skora bakarak okumak hatalı olur. Özellikle pagespeed insights nasıl yorumlanır sorusunda, aynı aracın farklı sürümleri ile aynı URL’nin farklı veri tipleri birbirine karıştırıldığında yanlış önceliklendirme yapılır.
Özet kural şudur: PageSpeed Insights’ta field data varsa önce onu okuyun; yoksa lab verisini başlangıç ipucu olarak değerlendirin. Search Console’a ise URL bazlı değil, şablon ve cihaz kırılımı bazlı bakın. CrUX, gerçek kullanıcı deneyiminin yönünü gösterir; Lighthouse ise mühendislik tarafında hangi değişikliğin etkili olacağını anlamanızı kolaylaştırır.
LCP, INP, CLS, TTFB, TBT ve Speed Index sonuçları nasıl yorumlanır?
Google Search Central, Core Web Vitals değerlendirmesinde p75 düzeyinde LCP için 2.5 saniye altını, INP için 200 ms altını ve CLS için 0.1 altını iyi aralık olarak tanımlar. Bu eşikler, tek bir test koşusunun değil kullanıcıların önemli bir bölümünün deneyimine bakar. Bu nedenle tek seferde çıkan çok iyi bir lab sonucu, zayıf field data’yı otomatik olarak geçersiz kılmaz.
- LCP: Ana içeriğin görünür hale gelme hızıdır. Yüksek çıkıyorsa sunucu yanıtı, görsel boyutu, render-blocking CSS veya hero alanındaki ağır medya ilk bakılacak yerlerdir.
- INP: Kullanıcının tıklama ya da dokunma sonrası arayüzün tepki verme kalitesidir. Yüksek INP çoğu kez ağır JavaScript, uzun ana iş parçacığı görevleri ve üçüncü parti etiketlerden beslenir.
- CLS: Görsel düzen kaymasını gösterir. Reklam alanı, boyutu tanımsız görseller, geç yüklenen font veya dinamik bileşenler sık fail nedenidir.
- TTFB: İlk bayt süresidir. CDN yapılandırması, sunucu yanıt süresi ve önbellek stratejisi burada belirleyicidir.
- TBT: Özellikle lab testlerinde ana iş parçacığının ne kadar bloke olduğunu anlamanızı sağlar; yüksek TBT, düşük etkileşim kalitesinin erken işaretidir.
- Speed Index: Sayfanın görsel olarak ne kadar hızlı dolduğunu hissiyat düzeyinde okutur; tek başına karar vermek için değil, diğer metriklerle birlikte kullanmak için faydalıdır.
Mobil skorun masaüstünden düşük çıkması da çoğu zaman normaldir. Mobil testte daha zayıf CPU, daha kısıtlı ağ ve daha sert darboğaz varsayılır. Üçüncü parti script yükü, ağır görseller ve istemci tarafında yoğun çalışan bileşenler mobilde daha görünür hale gelir. Terimlere takılıyorsanız performans terimleri sözlüğü üzerinden LCP, INP, TTFB ve benzeri kavramları tek tek açmak işinizi kolaylaştırır.
Buradaki en sık hata, performans skorunu hedefleyip metrik niyetini kaçırmaktır. LCP bozuksa önce sunucu, görsel ve kritik kaynak zincirine gidin; INP bozuksa JavaScript ve etkileşim maliyetine odaklanın; CLS bozuksa düzen kararlılığını düzeltin. Web sitesi performans analizi araçları size aynı anda birçok sayı gösterir, ama öncelik her zaman kullanıcı deneyimini bozan metriğin kök nedeni olmalıdır.
| Özellik | PageSpeed Insights | Lighthouse | WebPageTest | CrUX / Search Console | GTmetrix |
|---|---|---|---|---|---|
| Lab verisi sunma | Evet | Evet | Evet | Hayır | Evet |
| Field verisi sunma | Varsa CrUX üzerinden | Hayır | Hayır | Evet | Sınırlı, ana odak değil |
| Test lokasyonu seçimi | Sınırlı | Yerel çalıştırmaya bağlı | Gelişmiş | Yok | Var |
| Waterfall görünürlüğü | Düşük | Düşük | Çok güçlü | Yok | İyi |
| Mobil ve masaüstü ayrımı | Evet | Evet | Profil seçimine bağlı | Evet | Profil seçimine bağlı |
| Core Web Vitals odak seviyesi | Yüksek | Orta | Orta | Çok yüksek | Yüksek |
| Paylaşılabilir rapor yapısı | Kolay | Orta | İyi | Rapor mantığıyla sınırlı | Kolay |
| En uygun kullanım senaryosu | İlk kontrol | Geliştirme testi | Kök neden analizi | Gerçek kullanıcı doğrulaması | Ekip içi raporlama |
Aynı URL’yi dört araçta test ettiğimizde neden farklı sonuç gördük?
Pratikte en sık gördüğümüz iki çelişki var. Birincisi, PageSpeed Insights mobil lab tarafı zayıf görünürken CrUX veya Search Console tarafında sayfanın kabul edilebilir durumda kalmasıdır. Bu genelde tekil testin sert cihaz ve ağ simülasyonundan, ama gerçek kullanıcı kitlesinin daha güçlü cihazlardan gelmesinden kaynaklanır. İkincisi ise tersidir: lab skoru iyi görünür, fakat sahada p75 LCP ya da INP bozulur. Bu durumda sorun çoğu kez test edilmeyen gerçek koşullarda, yani yoğun trafik, üçüncü parti scriptler, kişiselleştirme katmanları veya belirli URL gruplarında ortaya çıkar.
Çelişki gördüğünüzde önce neye bakmalı?
Chrome for Developers’ın CrUX dokümanında anlatıldığı üzere CrUX, gerçek Chrome kullanıcılarının anonimleştirilmiş saha verisinden beslenir; bu nedenle SEO etkisini anlamada güçlü sinyaldir. WebPageTest dokümantasyonu ise test lokasyonu, bağlantı profili ve waterfall görünürlüğünün hata ayıklamada neden kritik olduğunu net gösterir. Aynı URL’yi dört araçta yan yana açtığınızda, PSI size uyarıyı, CrUX sorunun gerçekliğini, WebPageTest kaynağı ve GTmetrix iletişim kolaylığını verir.
Waterfall raporunda özellikle şu zincire bakın: yüksek TTFB ile başlayan sunucu gecikmesi mi var, yoksa HTML hızlı gelip asıl gecikme büyük görseller, font dosyaları veya uzun çalışan scriptlerden mi oluşuyor? Lokasyonu İstanbul’a yakın bir bölgeye aldığınız test ile uzak bir lokasyondaki testin farklı çıkması şaşırtıcı değildir. Benzer şekilde SPA veya JavaScript ağırlıklı sayfalarda ilk yükleme kabul edilebilir olsa bile iç gezinmeler yavaş hissedilebilir. 2026’da soft navigation ölçümü daha çok konuşulmasının nedeni de budur: tek sayfalık uygulamalarda kullanıcı deneyimi sadece ilk açılışla bitmez.
Bu başlıkta asıl karar kuralı şudur: çelişen sonuçlar arasında kazanan skor değil bağlamdır. SEO için gerçek kullanıcı verisini önceleyin; mühendislik sırası belirlemek için lab ve waterfall katmanını kullanın. Böyle yaptığınızda aynı URL’nin neden farklı sonuç verdiğini açıklamak kolaylaşır ve gereksiz optimizasyon işlerinden kaçınırsınız.
Hangi aracı ne zaman kullanmalı ve SEOYEN ile nasıl rutine bağlamalı?
Araç seçimini kullanım amacına göre ayırmak en verimli yoldur. Hızlı bir URL kontrolü mü yapacaksınız, önce PageSpeed Insights açın. Kod değişikliği sonrası tekrar edilebilir test mi istiyorsunuz, Lighthouse uygundur. Sorunun sunucu mu, görsel mi, script mi olduğunu ayırmanız gerekiyorsa WebPageTest veya GTmetrix daha net görünürlük verir. Canlı kullanıcı deneyiminin SEO açısından gerçekten bozulup bozulmadığını görmek içinse CrUX ve Search Console ana referans olmalıdır.
- Hızlı teşhis: PageSpeed Insights ile mobil ve masaüstü farkını görün.
- Geliştirme testi: Lighthouse ile değişiklik öncesi ve sonrası karşılaştırın.
- Kök neden analizi: WebPageTest waterfall ya da GTmetrix zaman çizelgesini açın.
- Düzenli izleme: Search Console ve CrUX ile sorun tek URL mi şablon mu anlayın.
Bu ölçüm döngüsü tek seferlik rapor olarak kalmamalı. Teknik bulguları bir site audit akışı içinde topladığınızda, hangi sayfanın hangi metriği bozduğunu izlemek kolaylaşır. Ardından değişikliklerin görünürlüğe etkisini sıralama takibi ile bağladığınızda, performans işinin yalnızca geliştirici tarafında değil SEO çıktısında da izlenebilir hale geldiğini görürsünüz. SEOYEN’in farkı tam burada belirginleşir: tek platformda tüm SEO araçları, Türkçe arayüz ve yerel Türkçe destek sayesinde teknik bulgular operasyonel karara daha hızlı dönüşür.
Ahrefs veya SEMrush gibi geniş platformlardan gelen ekipler genelde hız verisini ayrı, sıralama verisini ayrı yerde toplar. SEOYEN bunu Türkiye pazarına uyarlanmış bir iş akışıyla sadeleştirir; ayrıca güncel paket detayları sayfası üzerinden TL bazlı plan yapısını takip etmek de karar sürecini kolaylaştırır. Burada amaç tek bir aracı yüceltmek değil, sayfa hızını düzenli ve sürdürülebilir bir SEO pratiğine bağlamaktır.
Adım Adım Aynı URL’yi dört araçla test edip sonuçları doğru yorumlama
Tek bir ekran görüntüsüne göre karar vermek yerine aşağıdaki sıralamayı uygularsanız hem gereksiz panikten kaçınır hem de hangi sorunu önce çözmeniz gerektiğini daha net görürsünüz. Bu akış özellikle site hızı testi sonuçları nasıl okunur sorusuna pratik bir cevap verir.
- Test edilecek URL ve cihaz senaryosunu seç: Ana sayfa yerine trafik, dönüşüm veya SEO değeri taşıyan kritik bir URL belirleyin. Mobil ve masaüstünü ayrı iş olarak görün; çünkü aynı sayfa iki ortamda aynı darboğazı vermez. Kategori, ürün, blog ve landing page gibi farklı şablonları karıştırmadan ilerlemek sonraki yorumları netleştirir.
- PageSpeed Insights ile ilk lab ve field kontrolünü yap: Önce Core Web Vitals alanında field data var mı bakın. Ardından performans skoru, fırsatlar ve teşhisler bölümünü okuyun. Skor düşük diye doğrudan panik yapmayın; LCP, INP, CLS ve TTFB tarafında hangi uyarının tekrarlandığını not almak daha değerlidir.
- WebPageTest veya GTmetrix ile ayrıntılı waterfall incele: Burada amaç yeni bir skor görmek değil, gecikmenin kaynağını ayırmaktır. Sunucu yanıtı mı yavaş, kritik CSS mi bloke ediyor, büyük görseller mi geç geliyor, yoksa üçüncü parti scriptler mi ana iş parçacığını kilitliyor? Aynı URL’yi en az bir uygun lokasyon ve makul mobil profil ile test etmek yorumu sağlamlaştırır.
- CrUX ve Search Console ile gerçek kullanıcı verisini doğrula: Search Console’da sorun tek URL’de mi, benzer URL grubunda mı kontrol edin. CrUX veya Core Web Vitals raporu kötüyse, bunu SEO önceliği olarak ciddiye alın. Tek bir laboratuvar testinin iyi görünmesi, 28 günlük saha verisindeki bozulmayı otomatik olarak önemsiz hale getirmez.
- Metrikleri öncelik sırasına koyup izleme rutinine bağla: LCP, INP, CLS ve TTFB etkisine göre iş listesini sıraya koyun. Önce kullanıcı deneyimini ve indekslenebilir performansı en fazla bozan metriği hedefleyin. Sonrasında değişiklikleri düzenli takip ederek teknik iyileştirmeyi görünürlük ve sıralama etkisiyle aynı çizgide izleyin.
Kaynaklar
Sıkça Sorulan Sorular
Site hızı doğru biçimde tek araçla değil, üç katman birlikte okunarak ölçülür: lab testi, gerçek kullanıcı verisi ve kaynak zinciri analizi. İlk adımda PageSpeed Insights veya Lighthouse ile sayfanın laboratuvar koşullarındaki davranışına bakılır. Ardından CrUX veya Search Console üzerinden 28 günlük gerçek kullanıcı verisi kontrol edilir. Son olarak WebPageTest ya da GTmetrix ile waterfall açılarak gecikmenin sunucu, görsel, font ya da JavaScript kaynaklı olup olmadığı anlaşılır. En sağlıklı yorum, bu üç katman aynı çerçevede değerlendirildiğinde çıkar.
PageSpeed Insights, Google'ın bir URL için hem Lighthouse tabanlı lab verisini hem de varsa CrUX tabanlı field data'yı aynı raporda gösteren ölçüm aracıdır. Yani sadece skor veren bir test ekranı değildir. Core Web Vitals durumu, fırsatlar, teşhisler ve mobil-masaüstü kırılımını aynı yerde toplar. Bu yüzden hızlı bir başlangıç aracı olarak çok kullanışlıdır. Ancak verdiği skorun tek başına nihai karar olmadığını unutmamak gerekir. rapordaki veri tipini ve hangi metriğin gerçekten bozulduğunu birlikte okumak gerekir.
Önce test etmek istediğiniz URL'yi girin ve mobil sonucu temel referans olarak inceleyin. İlk bakmanız gereken alan, field data bölümünde Core Web Vitals durumunun geçip geçmediğidir. Sonra LCP, INP ve CLS metriklerine bakın. ardından performans skorunu yalnızca özet sinyal olarak değerlendirin. Alt taraftaki fırsatlar ve teşhisler bölümünü okurken özellikle tekrar eden darboğazları not alın: render-blocking kaynaklar, büyük görseller, uzun çalışan scriptler veya yüksek TTFB gibi. Masaüstü sonucunu da ayrıca açıp mobil ile neden ayrıştığını cihaz ve ağ bağlamında yorumlayın.
PageSpeed Insights skoru tek başına iyi ya da kötü kararı verdirmez. esas değer, skorun arkasındaki metriklerde ve veri tipindedir. Eğer field data alanında Core Web Vitals geçmiyorsa, yüksek bir lab skoru bile SEO açısından rahatlatıcı değildir. Tersi durumda, skor orta seviyede olsa bile gerçek kullanıcı verisi sağlıklı olabilir. Bu nedenle önce field data var mı bakın, sonra LCP, INP ve CLS eşiklerini yorumlayın, en son skorun hangi teşhislerden etkilendiğini okuyun. Skor özet ekranıdır. aksiyon planı ise metrik ve kök neden düzeyinde çıkar.
GTmetrix, sayfa performansını özellikle Lighthouse ve Web Vitals mantığında raporlayan, görsel zaman çizelgesi ve paylaşılabilir rapor yapısıyla öne çıkan bir ölçüm aracıdır. Analiz yaparken önce doğru lokasyonu ve mümkünse gerçek kullanım senaryosuna yakın bir profil seçmek gerekir. Ardından performans özeti, LCP ve TBT gibi temel metrikler, yükleme zaman çizelgesi ve kaynak listesi birlikte incelenir. GTmetrix'i en verimli kullanan yaklaşım, onu tek doğruluk kaynağı değil, PageSpeed Insights ve WebPageTest ile birlikte açıklayıcı bir katman olarak kullanmaktır.
Core Web Vitals, sayfanın kullanıcı tarafından nasıl deneyimlendiğini ölçen üç temel performans metriğinin ortak adıdır: LCP, INP ve CLS. LCP ana içeriğin ne kadar hızlı göründüğünü, INP etkileşim sonrası arayüzün ne kadar hızlı tepki verdiğini, CLS ise sayfadaki beklenmedik düzen kaymalarını ölçer. Bu metrikler SEO tarafında önemlidir çünkü yalnızca teknik hız değil, gerçek kullanım kalitesini temsil eder. Yorumlama yapılırken tek test yerine p75 düzeyi, cihaz türü ve gerçek kullanıcı verisi bağlamı dikkate alınmalıdır.
Tek bir sihirli saniye hedefi yoktur. çünkü sayfanın türü, cihaz profili ve kullanıcı ağı sonucu değiştirir. Pratikte daha güvenilir yaklaşım Core Web Vitals eşiklerine odaklanmaktır: p75 düzeyinde LCP 2.5 saniye altı, INP 200 ms altı ve CLS 0.1 altı hedeflenmelidir. Ayrıca TTFB'nin kontrol altında olması, kritik içeriğin hızla görünmesi ve etkileşimlerin gecikmemesi gerekir. Yani doğru soru sadece kaç saniye olduğu değil, kullanıcının sayfayı ne kadar hızlı gördüğü ve ne kadar sorunsuz kullandığıdır.