Site hızı testi, bir sayfanın ana içeriğini ne kadar hızlı gösterdiğini, etkileşimlere nasıl yanıt verdiğini ve yüklenirken ne kadar kararlı kaldığını incelemektir. Yalnızca 100 üzerinden bir puana bakmak, ziyaretçinin yaşadığı deneyimi açıklamaz.
Bu rehberde PageSpeed Insights, Search Console Core Web Vitals raporu ve Lighthouse ile ölçüm yapmayı, sonuçları yorumlamayı ve ilk düzeltilecek sorunu seçmeyi bulacaksınız. Önce önemli bir sayfanızı test edin; ardından aşağıdaki adımlarla raporu uygulanabilir bir çalışma listesine dönüştürün.
Kısa cevap
- Site hız testi nedir? Bir sayfanın ana içeriği ne kadar sürede gösterdiğini (LCP), tıklama ve dokunmalara ne kadar hızlı yanıt verdiğini (INP) ve yüklenirken öğelerin beklenmedik şekilde yer değiştirip değiştirmediğini (CLS) ölçmektir. Gerçek kullanıcı verisi deneyimi, laboratuvar testi ise sorunun teknik nedenini gösterir.
- Site hızı nasıl test edilir? Ücretsiz PageSpeed Insights’a URL’yi girin, mobil ve masaüstü sonuçlarını ayrı okuyun. Site genelini Search Console’daki Core Web Vitals raporundan, değişikliği yayından önce Chrome DevTools’taki Lighthouse ile kontrol edin.
- İyi değerler nedir? LCP ≤ 2,5 saniye, INP ≤ 200 milisaniye, CLS ≤ 0,1. Değerlendirme, sayfa ziyaretlerinin 75. yüzdelik dilimine göre yapılır.
- Site hızı nasıl artırılır? Önce hangi ölçümün kötü olduğunu bulun. LCP için ana görseli ve sunucu yanıtını, INP için JavaScript ve üçüncü taraf kodları, CLS için görsel boyutlarını ve sonradan yüklenen alanları inceleyin.
- PageSpeed puanı 100 olmalı mı? Hayır. Puan tek bir laboratuvar testinin sonucudur; asıl hedef gerçek kullanıcı verisinde üç ölçümün de “İyi” bandında olmasıdır.
Site hızı neden önemli?
Geç görünen bir ürün görseli, tıklamaya yanıt vermeyen bir menü veya form doldururken kayan bir alan, ziyaretçinin işini zorlaştırır. Hız çalışmasının hedefi; içeriğe ulaşmayı, karşılaştırma yapmayı ve işlemi tamamlamayı kolaylaştırmaktır.
Site hızı nedir, neyi ölçer?
Site hızı tek bir saniye değeri değildir. Google’ın Core Web Vitals ölçümleri deneyimi üç parçaya ayırır: ana içeriğin görünmesi (LCP), etkileşime yanıt (INP) ve görsel kararlılık (CLS). Bir sayfa hızlı açılıp butona dokunulduğunda geç yanıt verebilir; bu durumda “site hızlı” demek eksik kalır.
“Site açılış hızı” denildiğinde çoğu zaman sayfanın tamamen yüklenme süresi kastedilir. Bu süre analytics ve reklam kodları gibi ziyaretçinin fark etmediği kaynakları da içerir. Ziyaretçinin bekleme hissini daha iyi anlatan ölçüm, ana içeriğin göründüğü an olan LCP’dir.
Site hız testi, internet bağlantı hızı testinden de farklıdır. Speedtest türü araçlar sizin bağlantınızı ölçer; site hız testi ise belirli bir web sayfasının tarayıcıda nasıl yüklendiğini ve çalıştığını inceler.
Site açılış hızının SEO ve dönüşümlere etkisi
Google’ın sıralama sistemleri Core Web Vitals ölçümlerinden yararlanır; iyi sonuçlar tek başına üst sıraları garanti etmez. İçeriğin aramayla ilgisi ve yararı da önemlidir. Hızı, tarama ve indeksleme gibi kontrollerle birlikte değerlendirmek için teknik SEO rehberimizin performans bölümünü inceleyebilirsiniz. Google’ın sayfa deneyimi açıklaması da bu ayrımı yapar.
Reklam trafiğinde de açılış sayfası deneyimi önemlidir. Ancak site hızlanınca Google Ads tıklama maliyetinin mutlaka düşeceğini söyleyemeyiz. Kalite puanı bir teşhis aracıdır; kendi başına açık artırma girdisi değildir. Google Ads kalite puanı açıklamasına göre değerlendirme yapın; bileşenlerini kalite puanı rehberinde bulabilirsiniz. İş sonucunu ölçerken hızla birlikte form tamamlama, satış ve trafik kalitesini de izleyin.
Site hızı testi nasıl yapılır?
Yalnızca ana sayfanızı ölçmeyin. Ürün, kategori, hizmet ve blog sayfaları farklı görseller, uygulamalar ve kodlar yükleyebilir. İşiniz için önemli şablonlardan birer örnek seçin; reklam verdiğiniz açılış sayfasını da listeye alın.
- Test edeceğiniz adresi belirleyin. Gerçek ziyaretçilerin ulaştığı URL’yi kaydedin. Yönlendirme varsa başlangıç ve son adresi not edin.
- PageSpeed Insights’ı açın. URL’yi girip analizi başlatın. Mobil ve masaüstü sonuçlarını ayrı inceleyin.
- Gerçek kullanıcı verisinin kapsamını kontrol edin. Sonuç ilgili URL’ye mi, origin’e yani protokol ve alan adıyla tanımlanan site kökenine mi ait? Not alın.
- Laboratuvar bulgularını kaydedin. Ölçüm tarihi, cihaz modu, LCP öğesi ve öne çıkan sorunları yazın. Yalnızca toplam puanın ekran görüntüsünü saklamayın.
- Benzer koşullarda birkaç ölçüm yapın. Örneğin üç çalıştırmanın ortanca sonucunu karşılaştırın. Tek bir iyi sonucu seçmeyin; test sırasında sitede değişiklik yapmayın.
- Sayfayı kendiniz kullanın. Menü açın, filtre değiştirin ve form alanlarını deneyin. İlk yükleme raporu bütün etkileşimleri kapsamaz.
Kayıt için şu şablon yeterlidir: URL · tarih · araç/cihaz · veri kapsamı · temel bulgu · planlanan değişiklik · yeniden test sonucu. Farklı araçların puanlarını birbirinin yerine kullanmak yerine aynı araç ve ayarlarla karşılaştırma yapın.
Mobil sonuca öncelik verin. Google, dizine eklemede sitenizin mobil sürümünü kullanır (mobil öncelikli dizine ekleme). Ziyaretçilerinizin çoğu masaüstünden geliyorsa masaüstü sonucunu da ayrıca izleyin; iki cihaz türü ayrı değerlendirilir.
PageSpeed Insights: başlangıç noktası
PageSpeed Insights, mevcutsa gerçek kullanıcı verisini ve Lighthouse laboratuvar analizini birlikte sunar. İlk değerlendirme için buradan başlayın; aşağıdaki bölümde bu iki raporun farkını görebilirsiniz.
PageSpeed puanı nasıl hesaplanır?
Raporun üstündeki 0–100 arası performans puanı Lighthouse laboratuvar testinden gelir; gerçek kullanıcı verisinden hesaplanmaz. Puan, beş laboratuvar ölçümünün ağırlıklı ortalamasıdır. Chrome’un Lighthouse belgelerine göre Lighthouse 10’dan bu yana geçerli ağırlıklar şöyledir:
| Ölçüm | Neyi gösterir? | Ağırlık |
|---|---|---|
| Total Blocking Time (TBT) | Yükleme sırasında ana iş parçacığının engellendiği toplam süre | %30 |
| Largest Contentful Paint (LCP) | En büyük görünür içerik öğesinin belirmesi | %25 |
| Cumulative Layout Shift (CLS) | Beklenmedik yerleşim kaymaları | %25 |
| First Contentful Paint (FCP) | İlk metin veya görselin ekrana gelmesi | %10 |
| Speed Index | Görünür içeriğin ne kadar hızlı dolduğu | %10 |
Puan renkleri: 90–100 yeşil (iyi), 50–89 turuncu (iyileştirme gerekir), 0–49 kırmızı (zayıf). Laboratuvar testinde gerçek bir kullanıcı etkileşimi olmadığı için INP puana girmez; TBT, etkileşim sorunlarına işaret eden en yakın laboratuvar ölçümüdür. Bu yüzden puan yüksekken saha verisindeki INP kötü olabilir.
Search Console Core Web Vitals raporu: site genelini görmek
PageSpeed Insights tek URL’ye bakar. Sitenin geneli için Search Console’un sol menüsündeki Core Web Vitals raporunu açın. Rapor, CrUX’tan gelen gerçek kullanıcı verisini mobil ve masaüstü için ayrı gösterir. Benzer sayfaları URL grupları hâlinde toplar ve her grubu “Yavaş”, “İyileştirme gerektiriyor” veya “Hızlı” olarak etiketler. Grubun durumunu en kötü ölçüm belirler; LCP ve INP iyi, CLS yavaşsa grup “Yavaş” görünür.
- Önce mobil raporu açın ve “Yavaş” etiketli sorunlardan başlayın.
- Sorun satırına tıklayın; hangi ölçümün (LCP, INP, CLS) eşiği aştığını ve etkilenen URL gruplarını görün.
- Gruptan örnek bir URL seçin ve PageSpeed Insights ile nedenini araştırın. Gruptaki URL’ler gösterime göre sıralanır; üstteki sayfalar grubun durumunu en çok etkiler.
- Düzeltmeyi yayınladıktan sonra sorun ayrıntıları sayfasından doğrulamayı başlatın. Rapor son 28 günlük veriye dayandığı için sonuç hemen değişmez.
Yeni veya az trafik alan sitelerde rapor “Veri yok” gösterebilir; bu, sayfanın hızlı ya da yavaş olduğu anlamına gelmez. Ayrıntılar Search Console Yardım’daki Core Web Vitals raporu sayfasındadır.
Lighthouse ve Chrome DevTools: değişikliği yayından önce sınamak
Lighthouse, Chrome DevTools içinde kendi panelinde çalışır. Sayfayı Chrome’da açın, DevTools’u açıp Lighthouse paneline geçin, cihaz türünü seçin ve analizi başlatın. PageSpeed Insights sayfayı Google’ın sunucularından açtığı için herkese açık bir adres ister; Lighthouse ile test ortamındaki ya da şifreli bir önizlemedeki sayfayı da ölçebilirsiniz. Tarayıcı eklentileri sonucu etkileyebilir; gizli pencerede test etmek bu etkiyi azaltır.
INP’yi araştırmak için Performance paneli daha uygundur: sayfayı gerçekten kullanırken LCP, INP ve CLS değerlerini yerel olarak gösterir. Panelde CrUX saha verisini bağlayarak kendi ölçümünüzü ziyaretçilerinizin deneyimiyle karşılaştırabilirsiniz.
Rapor dilindeki değişiklik: 10 Ekim 2025’te yayımlanan Lighthouse 13 ile eski performans denetimlerinin çoğu, DevTools Performance paneliyle ortak “insights” (öngörüler) başlıklarına taşındı. Örneğin yönlendirmeler, sunucu yanıt süresi ve metin sıkıştırma artık “Document request latency” altında görünür. Puanlama değişmedi; yalnız puana etki etmeyen denetimlerin adı ve gruplaması değişti. Eski ekran görüntüleriyle anlatılan rehberlerde farklı başlıklar görmeniz bu yüzdendir. Lighthouse 13 duyurusu.
GTmetrix: yükleme sırasını incelemek
GTmetrix’in Performance ve Structure değerlendirmeleri, yükleme davranışını incelemeye yardımcı olur. Waterfall görünümü, hangi isteğin ne zaman başladığını ve ne kadar sürdüğünü gösterir. Konum ve bağlantı ayarları sonucu etkileyebileceğinden karşılaştırmalarda aynı koşulları koruyun. GTmetrix raporu Lighthouse tabanlıdır; bu yüzden ölçüm adları PageSpeed Insights’takilerle benzerdir.
Pingdom: düzenli takip ihtiyacı
Tek seferlik ölçümün yanında erişilebilirlik veya performans takibi gerekiyorsa Pingdom gibi izleme araçları değerlendirilebilir. Birden fazla araca abone olmadan önce hangi sorunu izleyeceğinizi belirleyin. Özellikler ve ücretler değişebildiği için güncel plan kapsamını sağlayıcısından kontrol edin.
WebPageTest ve diğer araçlar
WebPageTest; test konumu, tarayıcı ve bağlantı hızını ayrıntılı seçmenizi, yüklemeyi kare kare (filmstrip) izlemenizi ve iki testi yan yana karşılaştırmanızı sağlar. Türkiye’deki ziyaretçilerin yaşadığı gecikmeyi yurt dışındaki bir test noktasıyla ölçmek yanıltıcı olabilir; konum seçimi bu yüzden önemlidir. Ücretli izleme araçları (ör. düzenli gerçek kullanıcı ölçümü sunanlar) sürekli takip gerektiğinde değerlendirilebilir. Hangi aracı seçerseniz seçin, sonuçları aynı araç ve ayarlarla karşılaştırın.
Hangi site hız testi aracını kullanmalısınız?
| Araç | Veri türü | En uygun kullanım |
|---|---|---|
| PageSpeed Insights | Saha (CrUX, son 28 gün) + laboratuvar (Lighthouse) | Tek bir URL için ilk bakış; ücretsiz |
| Search Console Core Web Vitals | Saha (CrUX), URL grupları | Site genelinde hangi sayfa grubunun sorunlu olduğunu bulmak; ücretsiz |
| Lighthouse / Chrome DevTools | Laboratuvar; Performance panelinde yerel ölçüm | Değişikliği yayından önce sınamak, INP sorununu kaydetmek; ücretsiz |
| GTmetrix | Laboratuvar (Lighthouse tabanlı) + waterfall | İsteklerin yükleme sırasını ve süresini incelemek |
| WebPageTest | Laboratuvar; konum, tarayıcı ve bağlantı seçimi | Ayrıntılı teknik analiz, önce–sonra karşılaştırması |
| Pingdom | Laboratuvar ve izleme | Düzenli erişilebilirlik ve performans takibi |

Hız raporu nasıl okunur?
GERÇEK KULLANICI VERİSİ
Ziyaretçi ne yaşıyor?
CrUX · Son 28 günlük dönem
URL veya origin kapsamı
Deneyimi değerlendirmek için
LABORATUVAR TESTİ
Sorunu nasıl araştırırım?
Lighthouse · Tek çalıştırma
Kontrollü test koşulları
Teknik nedenleri bulmak için
CrUX, uygun Chrome kullanıcılarından toplanan deneyim verilerini kullanır; sitenizin bütün ziyaretçilerinin analitik kaydı değildir. PageSpeed’deki gerçek kullanıcı görünümü önceki 28 günlük dönemi kapsar. Shopify yönetim panelindeki hız raporu ise farklı bir veri kaynağı ve 7 günlük pencere kullanır (bkz. Shopify site hızı ve Core Web Vitals). İlgili URL için yeterli veri yoksa origin verisi gösterilebilir veya veri bulunamayabilir. Bu durum, sayfanın hızlı ya da yavaş olduğunu kanıtlamaz.
Laboratuvar puanı ise o testin sonucudur. Cihaz, ağ ve sayfada yüklenen kaynaklar nedeniyle değişebilir. Yüksek Lighthouse puanı, gerçek kullanıcı değerlendirmesinin geçtiği anlamına gelmez. İki raporu birbirinin yerine kullanmayın.
| Ölçüm | Anlamı | İyi eşik | İyileştirme gerekir | Yetersiz |
|---|---|---|---|---|
| LCP | En büyük görünür içerik öğesinin belirmesi | ≤ 2,5 saniye | 2,5–4 saniye | > 4 saniye |
| INP | Etkileşimlere yanıt verme | ≤ 200 ms | 200–500 ms | > 500 ms |
| CLS | Beklenmedik yerleşim kaymaları | ≤ 0,1 | 0,1–0,25 | > 0,25 |
Değerlendirme, ölçümlerin 75. yüzdelik dilimine bakar: ilgili ölçümlerin en az %75’inin iyi eşikte olması hedeflenir. Core Web Vitals için üç ölçüm birlikte önemlidir. LCP’nin 2,5 saniye olması, sayfadaki bütün dosyaların bu sürede yüklendiği anlamına gelmez. Ara bantlar Search Console raporundaki durumlarla aynıdır (Search Console durum tanımları).

FID yerine INP: 12 Mart 2024’ten bu yana etkileşim ölçümü INP’dir; First Input Delay (FID) Core Web Vitals’tan çıkarıldı; Chrome araçlarındaki geçiş süresi 9 Eylül 2024’te sona erdi. FID’i hâlâ üç temel ölçümden biri olarak anlatan kaynaklar bu tarihten önceki duruma göre yazılmıştır. FID yalnız ilk etkileşimin bekleme süresine bakıyordu; INP ise sayfadaki etkileşimlerin yanıt süresini bütün ziyaret boyunca değerlendirir. INP’nin Core Web Vitals’a geçişi.
Laboratuvar raporundaki TBT, yükleme sırasında ana iş parçacığının engellendiği süreleri araştırmaya yardımcı olur; INP’nin yerine geçmez. TTFB ise ilk baytın gelmesine kadar geçen süreyi anlatan tamamlayıcı bir göstergedir, Core Web Vitals ölçümü değildir. Yol gösterici değerler: FCP için 1,8 saniye veya altı, TTFB için 0,8 saniye veya altı iyi kabul edilir. TTFB eşiği kaba bir kılavuzdur; ilk yanıt LCP süresinin bir parçası olduğundan yavaş TTFB, LCP’yi de geciktirir.
Hangi hız sorununu önce çözmelisiniz?
Önceliği yalnız uyarının rengine göre belirlemeyin. Sorunun önemli sayfalarda ne kadar yaygın olduğuna, kullanıcı üzerindeki etkisine ve düzeltmenin riskine bakın. Aşağıdaki tablo kesin teşhis değil, incelemeye başlayacağınız yeri gösterir.
| Belirti | İlk kontrol | Doğrulama |
|---|---|---|
| Ana görsel geç görünüyor | Dosya boyutu, isteğin başlama zamanı, yükleme önceliği | LCP öğesi ve ağ kaydı |
| Menü veya filtre geç yanıt veriyor | Uzun JavaScript işlemleri, üçüncü taraf kodlar | Etkileşim sırasında Performance kaydı |
| İçerik yüklenirken kayıyor | Görsel boyutları, fontlar, sonradan eklenen alanlar | Kaymaya neden olan öğeler |
| İlk içerik uzun süre gelmiyor | Yönlendirmeler, sunucu yanıtı, önbellek | İlk isteğin zamanlaması |

Site hızını artırmak için uygulanabilir adımlar
Görselleri boyutlandırın ve doğru zamanda yükleyin
Mobilde küçük gösterilen bir alan için çok büyük dosya göndermeyin. Görüntü kalitesini koruyarak sıkıştırın; uygun olduğunda WebP veya AVIF kullanın ve farklı ekranlar için srcset/sizes seçeneklerini değerlendirin (ayrıntı: görsel ve video teknik SEO’su). Yalnız dosya uzantısını değiştirmek optimizasyon değildir.
İlk ekrandaki LCP görselini lazy-load ile geciktirmeyin. Tarayıcının görseli erken keşfetmesini sağlayın; yükleme önceliğini gerektiğinde ayarlayın. Her görsele yüksek öncelik vermek kaynakları yarıştırır.
Uygulamada bu, ilk ekrandaki ana görselin <img> etiketine fetchpriority="high" eklemek anlamına gelebilir; tarayıcı bu görseli diğer görsellerden önce istemeye başlar. Görsel CSS arka planı olarak veya JavaScript ile sonradan ekleniyorsa tarayıcı onu geç keşfeder; mümkünse HTML’de normal bir <img> olarak verin.
Görünür alanın altındaki uygun görsellerde loading="lazy" kullanılabilir. Görsellerin width ve height değerlerini tanımlayın; böylece yüklenmeden önce yerleri ayrılabilir.
JavaScript ve üçüncü taraf etiketleri denetleyin
Kullanılmayan eklenti, uygulama ve kodları belirleyin. Shopify mağazalarında en sık görülen nedenler için Shopify performans sorunları listesine bakın. Bir kodun dosya boyutu küçük olsa bile çalışırken tarayıcıyı uzun süre meşgul edebilir. Menü veya filtre gecikiyorsa ilgili etkileşimi kaydedin; uzun işleri parçalara ayırmayı ve gereksiz hesaplamaları azaltmayı değerlendirin.
Script’i HTML’nin en altına taşımayı tek çözüm saymayın. defer ve async farklı çalışır; seçim kodun çalışma sırasına ve bağımlılıklarına göre yapılmalıdır. Her script’e aynı niteliği eklemek işlevleri bozabilir.
Google Tag Manager kullanmak tek başına hız kazandırmaz. Yinelenen etiketleri, gereksiz tetiklemeleri ve hangi sayfalarda hangi kodlara ihtiyaç olduğunu inceleyin. Ölçüm kodlarını gelişigüzel geciktirmeyin; izin tercihlerini ve dönüşüm takibini doğrulayın. Kurulum için Google Tag Manager rehberini kullanabilirsiniz.
CSS, font ve yerleşimi birlikte değerlendirin
Kullanılmayan CSS’yi azaltın, ihtiyaç duyulmayan font ağırlıklarını kaldırın ve kritik içeriğin çizilmesini engelleyen kaynakları inceleyin. Minify işlemi dosyayı küçültür; kullanılmayan kodu veya pahalı işlemleri kendiliğinden ortadan kaldırmaz. Her kaynağı preload etmek yerine gerçekten erken gerekenleri seçin.
Banner, video ve dinamik alanlar için yer ayırın. Font değişiminin satırları ve butonları kaydırıp kaydırmadığını kontrol edin. CLS araştırmasında sadece ilk açılışa bakmayın; sayfayı kaydırırken veya sonradan içerik yüklenirken oluşan hareketleri de inceleyin.
Sunucu, önbellek ve CDN’yi bulguya göre iyileştirin
İlk yanıt gecikiyorsa gereksiz yönlendirmeleri, uygulamanın yanıt üretmesini ve önbellek davranışını araştırın. Yönlendirme zincirleri için teknik SEO rehberindeki bölüme bakın. CDN, uygun kaynakları ziyaretçiye yakın sunabilir; sunucu tarafındaki her problemi çözmez. Statik dosyaların önbellek sürelerini ve metin dosyalarında sıkıştırmayı kontrol edin.
Sepet, hesap ve kişiye özel içeriklerde genel bir önbellek ayarını kontrolsüz uygulamayın. Altyapınıza göre erişebileceğiniz ayarlar değişir. Tema veya eklenti güncellemelerini yedek alarak, mümkünse test ortamında deneyin; yalnız “hızlandırma” adlı bir eklenti kurarak sorunun çözüldüğünü varsaymayın.
Sayfalar arası geçişleri hızlandırın: bfcache ve ön yükleme
Ziyaretçi geri veya ileri düğmesine bastığında tarayıcı, sayfayı yeniden yüklemek yerine geri/ileri önbellekten (bfcache) anında gösterebilir. Bunu engelleyen en yaygın neden unload olayını kullanan kodlardır; bu olayı kullanmayın ve üçüncü taraf kodlarda kullanılıp kullanılmadığını kontrol edin. Chrome DevTools’taki Application → Back-forward Cache bölümü sayfanın bu önbelleğe alınıp alınamadığını ve nedenini gösterir.
Chrome’da Speculation Rules API ile ziyaretçinin büyük olasılıkla açacağı sonraki sayfa önceden getirilebilir veya önceden oluşturulabilir. Doğru kullanıldığında sonraki sayfa neredeyse anında açılır; yanlış kullanıldığında gereksiz sunucu yükü ve sayılmaması gereken analitik isabetleri oluşabilir. Kampanya ve analitik ölçümünü etkileyebileceği için önce sınırlı sayıda sayfada deneyin.
Altyapıya göre: WordPress, Shopify ve özel yazılım
Ölçüm ve öncelik mantığı her altyapıda aynıdır; değiştirebileceğiniz alanlar farklıdır.
- WordPress: En büyük kazanç çoğu zaman sayfa önbelleğindedir; WordPress’in kendi performans belgesi de hızlı sonuç için önbellekle başlamayı önerir. Ardından kullanılmayan eklentileri kaldırın, ağır sayfa oluşturucu ve tema seçeneklerini gözden geçirin, görselleri boyutlandırın. Her eklentiyi aynı anda kaldırmak yerine birer birer ölçün.
- Shopify: Sunucu, CDN ve önbellek Shopify tarafından yönetilir; sizin etkiniz tema, uygulamalar, görseller ve üçüncü taraf kodlar üzerindedir. Kaldırılan uygulamaların temada kod bırakıp bırakmadığını kontrol edin. Ayrıntılar: Shopify site hızı ve Core Web Vitals.
- Özel yazılım: Sunucu yanıt süresi, veritabanı sorguları, sayfa önbelleği ve CDN ayarları doğrudan sizin kontrolünüzdedir. TTFB yüksekse önce sunucu tarafını, TTFB iyi ama LCP kötüyse ön yüz kaynaklarını inceleyin.
Altyapı değişikliği planlıyorsanız taşıma sonrasında hız ve indeksleme kontrollerini birlikte yapın; adımlar için site taşıma SEO rehberine bakabilirsiniz.
Değişikliklerden sonra nasıl kontrol edilir?
- Önce–sonra kaydını karşılaştırın. Aynı URL, araç, cihaz ve bağlantı koşullarını kullanın. Önbelleğin dolu veya boş olduğu testleri birbirine karıştırmayın.
- Mümkün olduğunca tek bir değişikliği sınayın. Birkaç uygulamayı aynı anda kaldırırsanız kazanımın veya hatanın kaynağını bulmak zorlaşır.
- İşlevleri kontrol edin. Menü, filtre, form, sepet, ödeme geçişi ve çerez tercihlerini sitenizin yapısına göre deneyin. Test dönüşümlerini gerçek satışlardan ayırın.
- Ölçümün çalıştığını doğrulayın. Analitik ve reklam etiketlerinin beklenen olayları doğru koşullarda gönderdiğini kontrol edin.
- Gerçek kullanıcı eğilimini izleyin. 28 günlük kayan pencere nedeniyle yeni sonuçlarla eski deneyimler bir süre birlikte görünür. Laboratuvar kazanımının alan verisine anında yansımasını beklemeyin.
Hız ölçümleriyle dönüşüm oranını ayrı kaydedin. Kampanya, fiyat veya trafik kaynağı da değiştiyse satış farkının tamamını hız iyileştirmesine bağlamayın. Başarı ölçütünü işe başlamadan belirlemek, sonuçları daha sağlıklı yorumlamanızı sağlar.
Site hızı hakkında sık sorulan sorular
PageSpeed’de 100 puan almak gerekli mi?
100 puanı tek hedef yapmayın. Gerçek kullanıcı deneyimine, kritik işlevlere ve önemli sayfalardaki sorunlara odaklanın. Puan yükselirken form bozuluyorsa çalışma tamamlanmış değildir.
Aynı sayfanın test sonuçları neden değişir?
Ağ koşulları, sunucu yükü, önbellek ve üçüncü taraf içerikler ölçümü etkileyebilir. Aynı ayarlarda tekrarlanan testlerin genel eğilimini değerlendirin; tek çalıştırmayı kesin hüküm saymayın.
Gerçek kullanıcı verisi yoksa ne yapmalıyım?
Laboratuvar bulguları ve gerçek cihaz kontrolleriyle başlayın. Daha ayrıntılı takip gerekiyorsa gizlilik ve izin koşullarına uygun bir gerçek kullanıcı ölçümü kurulabilir. Veri yokluğunu başarılı bir Core Web Vitals sonucu olarak raporlamayın.
Site açılış hızı kaç saniye olmalı?
Google’ın “tam yüklenme süresi” için belirlediği tek bir hedef yoktur. Ölçülebilir hedef Core Web Vitals eşikleridir: ana içerik (LCP) 2,5 saniye veya altında görünmeli, etkileşimler 200 ms içinde yanıt vermeli, CLS 0,1’i geçmemelidir. Sayfanın arka planda yüklemeye devam eden kodları bu hedefi bozmadığı sürece toplam süre tek başına başarı ölçütü değildir.
En iyi site hız testi aracı hangisi?
Tek bir “en iyi” araç yoktur; amaçla seçilir. Gerçek kullanıcı verisi ve hızlı başlangıç için PageSpeed Insights, site geneli için Search Console Core Web Vitals raporu, yayın öncesi test ve INP araştırması için Chrome DevTools, yükleme sırasını incelemek için GTmetrix veya WebPageTest uygundur. Karşılaştırmayı her zaman aynı araçla yapın.
Site hız testi internet hızımı mı ölçer?
Hayır. İnternet hız testi bağlantınızın indirme ve yükleme hızını ölçer. Site hız testi belirli bir web sayfasının nasıl yüklendiğini inceler. PageSpeed Insights’taki laboratuvar testi Google’ın sunucularında sabit ayarlarla çalışır, sonuç sizin bağlantınıza bağlı değildir; saha verisi ise farklı bağlantılara sahip gerçek ziyaretçilerin deneyimini yansıtır.
Hız iyileştirmesinin sonucu ne zaman görülür?
Laboratuvar sonucu değişikliği yayınladığınız anda değişir. PageSpeed Insights ve Search Console’daki gerçek kullanıcı verisi son 28 günü kapsadığı için yeni deneyimler eski verinin yerini kademeli olarak alır; tam etkiyi görmek yaklaşık dört hafta sürebilir. Search Console’da doğrulama başlattıysanız sonucu da bu süreye göre bekleyin.
Site hızı optimizasyonunu kendim yapabilir miyim?
Ölçüm, görselleri boyutlandırma, kullanılmayan uygulama ve eklentileri kaldırma gibi adımları teknik bilgi gerektirmeden yapabilirsiniz. Tema kodu, script yükleme sırası, sunucu ve önbellek ayarları ise siteyi bozma riski taşır; bu değişiklikleri test ortamında ve yedek alarak, mümkünse bir geliştiriciyle yapın. Her değişikliği ayrı ölçerseniz hangi adımın işe yaradığını görürsünüz.
Ölçüm bulgularını uygulanabilir bir plana dönüştürmek için SEO hizmet kapsamımızı inceleyebilirsiniz. Hız çalışmasını, sitenizin teknik sağlığı ve ziyaretçinin tamamlamak istediği işlemle birlikte ele alıyoruz. Shopify mağazalarında tema ve uygulama kaynaklı hız sorunları için Shopify hizmetimize de göz atabilirsiniz.
Bu yazıdaki bilgiler en son 22 Ekim 2026’da gözden geçirildi.


