Hızın arama görünürlüğündeki gerçek ağırlığı, Core Web Vitals metriklerinin sade tanımları, saha verisi ile laboratuvar verisi ayrımı, ölçüm araçları ve iyileştirmede en çok kazandıran işi öne alan bir öncelik sırası.
Bir sayfanın ne kadar çabuk açıldığı, arama sonuçlarındaki yerini tek başına belirlemez; ama birbirine yakın iki aday arasında fark yaratabilir. Site hızı bu yüzden hem fazla abartılan hem de sık küçümsenen bir başlıktır. Bu yazıda site hızı SEO açısından gerçekte neyi değiştirir, hangi metriklerle ölçülür ve iyileştirmeye nereden başlanır sorularını ele alıyoruz.
Amaç eşik tabloları ezberletmek değil, mekanizmayı anlatmak. Arama motorunun hangi veriyi nereden aldığını ve hangi işin ne kadar kazandırdığını bilirseniz, site hızı çalışması tahmin olmaktan çıkıp planlanabilir bir işe dönüşür.
Site hızı sıralamada ne kadar ağırlık taşır?
Arama motorları sayfa deneyimini değerlendirirken site hızını hesaba katar, ancak bu sinyal içeriğin alaka düzeyinin önüne geçmez. Aradığı yanıtı veren yavaş bir sayfa, konuyla ilgisiz ama çok hızlı bir sayfanın gerisinde kalmaz. Site hızının belirleyici hale geldiği yer, kalite ve niyet uyumu bakımından birbirine yakın adayların yarıştığı rekabetçi sonuç kümeleridir.
Bu ayrımı net kurmak gerekir, çünkü performans çalışmasına giren birçok işletme yanlış beklentiyle başlar. Skor yükseldiğinde sıralamanın kendiliğinden yukarı taşınacağı varsayılır; oysa sinyal, aday havuzu oluştuktan sonra devreye giren bir ayrıştırıcıdır.
Mekanizmayı şöyle düşünebilirsiniz: arama motoru önce sorguya karşılık verebilecek sayfaları belirler, sonra bunları çok sayıda ölçüte göre karşılaştırır. Deneyim ölçütleri bu karşılaştırmanın bir parçasıdır. Dolayısıyla hız, zayıf içeriği kurtarmaz ama iyi içeriğin önündeki engeli kaldırır.
Site hızı ayrıca dolaylı yollardan da etki eder. Yavaş açılan bir sayfada kullanıcı beklemeden geri döner, bu davranış zamanla sayfanın sorguya verdiği tatmini zayıflatır. Konunun teknik altyapı tarafını bütünsel görmek isterseniz teknik SEO çalışmasının kapsamı iyi bir başlangıç noktasıdır.
Core Web Vitals: üç metrik neyi ölçer?
Core Web Vitals, sayfa deneyimini üç ölçülebilir başlığa indirger. LCP yüklenme hissini, INP etkileşime verilen yanıtı, CLS ise görsel kararlılığı temsil eder. Üçü birlikte bir kullanıcının sayfayı ne kadar akıcı deneyimlediğini tarif eder. Her metriğin ayrı nedenleri ve ayrı çözümleri vardır; tek bir müdahaleyle hepsi birden düzelmez.
| Metrik | Ne ölçer | Tipik neden |
|---|---|---|
| LCP | Ekrandaki en büyük içerik ögesinin görünür olma süresi | Ağır kapak görseli, yavaş sunucu yanıtı, geciken kaynak yüklemesi |
| INP | Kullanıcı etkileşimlerine sayfanın verdiği görsel yanıt süresi | Uzun süren JavaScript görevleri, ağır olay dinleyicileri, üçüncü taraf betikler |
| CLS | Sayfa yüklenirken ögelerin beklenmedik biçimde kayması | Boyutu belirtilmemiş görsel, sonradan yerleşen reklam, geç yüklenen font |
Metriklerin iyi kabul edilen aralıkları Google tarafından yayımlanır ve zaman içinde güncellenebilir. Güncel değerler için kesin rakamı ezberlemek yerine web.dev üzerindeki Core Web Vitals dokümantasyonuna bakmak daha güvenlidir.
LCP: yüklenme hissi
LCP, ziyaretçinin ekranında görünen en büyük içerik ögesinin ne zaman belirdiğini ölçer. Bu öge çoğu sayfada kapak görseli, ürün fotoğrafı veya büyük bir başlık bloğudur. Kullanıcı sayfanın açıldığını bu ögeyi gördüğü anda hisseder.
Kötü LCP'nin arkasında genellikle üç şey vardır: sıkıştırılmamış büyük görseller, sunucunun ilk baytı geç göndermesi ve kritik kaynakların geç keşfedilmesi. Bu üçü çözüldüğünde site hızı algısı çoğu projede belirgin biçimde iyileşir.
INP: etkileşime verilen yanıt
INP, kullanıcının bir düğmeye dokunması veya menüyü açması gibi etkileşimlerden sonra sayfanın görsel olarak yanıt vermesinin ne kadar sürdüğünü ölçer. Daha önce kullanılan FID metriği yalnızca ilk etkileşimin gecikmesine bakıyordu; INP ise ziyaret boyunca yaşanan etkileşimleri bütün olarak değerlendirir ve FID'in yerini almıştır.
INP sorunlarının kaynağı neredeyse her zaman JavaScript'tir. Uzun süren betik görevleri ana iş parçacığını meşgul eder ve tarayıcı kullanıcının dokunuşuna yanıt veremez. Sayfa görünürde yüklenmiş olsa bile tepkisiz hissettiriyorsa, bakılacak metrik budur.
CLS: görsel kararlılık
CLS, sayfa yüklenirken içeriğin yerinden oynamasını ölçer. Okumaya başladığınız metnin aşağı kayması veya tam dokunacakken düğmenin yer değiştirmesi bu metriğin konusudur. Ölçtüğü şey süre değil, kararsızlıktır.
En yaygın nedenler görsel ve reklam alanlarına önceden yer ayrılmaması ile fontların geç yüklenip metin boyutunu değiştirmesidir. CLS, çözümü görece ucuz ama etkisi kullanıcı tarafında hemen hissedilen bir metriktir.
Saha verisi mi, laboratuvar verisi mi?
Laboratuvar verisi, sabit koşullarda çalıştırılan bir simülasyonun sonucudur ve hata ayıklamak için idealdir. Saha verisi ise sitenizi gerçekten ziyaret eden kullanıcıların cihazlarından toplanan ölçümlerdir. Değerlendirmede ağırlık taşıyan taraf saha verisidir, çünkü kullanıcıların yaşadığı gerçek deneyimi yansıtır. Laboratuvar skoru yüksek bir sayfanın saha verisi zayıf olabilir.
Bu iki verinin ayrışmasının sebebi basittir: test aracı belirli bir cihaz ve bağlantı profili varsayar, gerçek ziyaretçiler ise eski telefonlarla, zayıf mobil bağlantılarla ve reklam engelleyicilerle gelir. Aradaki fark bazen çok büyük olur.
- Laboratuvar verisi: tekrar edilebilir, anında sonuç verir, geliştirme sırasında değişikliği doğrulamak için kullanılır.
- Saha verisi: gerçek kullanıcılardan toplanır, birikmesi zaman alır, değerlendirmede belirleyici olan taraftır.
- Saha verisi yeterli trafiği olmayan sayfalarda toplanamayabilir; bu durumda benzer sayfa grupları üzerinden bakılır.
- Bir düzeltmenin saha verisine yansıması genellikle haftalar sürer; hemen sonuç beklemeyin.
Pratik sonuç şu: laboratuvar aracıyla neyin bozuk olduğunu bulun, saha verisiyle gerçekten düzelip düzelmediğini doğrulayın. Yalnız birine bakmak, site hızı çalışmasını ya yanlış yere odaklar ya da sahte bir başarı hissi yaratır.
Ölçüm: hangi araç neye yarar?
İki ana araç yeterlidir. PageSpeed Insights tek bir adresi hem laboratuvar hem saha verisiyle inceler ve sorunun kaynağını gösterir. Search Console içindeki Core Web Vitals raporu ise site genelini sayfa grupları halinde özetler, hangi şablonun sorunlu olduğunu ortaya çıkarır. Biri teşhis, diğeri kapsam görme aracıdır.
Doğru sıra genellikle şudur: önce Search Console raporundan hangi sayfa grubunun sorunlu olduğunu görürsünüz, sonra o gruptan temsili bir adresi PageSpeed Insights üzerinde tek tek incelersiniz. Tek sayfayla başlamak, sorunun ne kadar yaygın olduğunu gizler.
- Sorunlu sayfa grubu şablon düzeyinde mi belirlendi, yoksa tek sayfaya mı bakıldı?
- Mobil ve masaüstü sonuçları ayrı ayrı okundu mu?
- Saha verisi mevcut mu, yoksa yalnız laboratuvar skoruna mı bakılıyor?
- En çok etkilenen metrik hangisi: LCP, INP yoksa CLS?
- Düzeltme sonrası ölçüm için bir tarih belirlendi mi?
- Değişiklik canlıya alınmadan önce mevcut değerler kayıt altına alındı mı?
Ölçüm alışkanlığı olmayan sitelerde performans çalışması genellikle tek seferlik bir müdahaleye dönüşür ve birkaç ay içinde eski haline döner. Mevcut durumun bütün olarak çıkarılması için SEO analizi çalışmasının nasıl yürüdüğüne bakabilirsiniz.
Siteyi yavaşlatan tipik nedenler
Site hızını düşüren etkenler çoğu projede beş başlıkta toplanır: optimize edilmemiş görseller, işlemeyi bloklayan betikler ve stiller, geç yanıt veren sunucu, kontrolsüz eklenen üçüncü taraf kodlar ve yanlış yüklenen fontlar. Bu beş başlık birbirini büyütür; hepsi aynı anda varsa sayfanın hangi nedenle yavaş olduğunu ayırmak zorlaşır.
- Ağır görseller: gereğinden büyük boyutta yüklenen, modern formata dönüştürülmemiş ve ekran boyutuna göre ölçeklenmeyen dosyalar.
- Bloklayan betikler ve stiller: sayfanın çizilmesini bekleten, kritik olmayan ama başta yüklenen kaynaklar.
- Sunucu yanıt süresi: ilk baytın geç gelmesi; önbellekleme, sorgu maliyeti veya barındırma kaynaklı olabilir.
- Üçüncü taraf kodlar: analiz, sohbet, reklam ve pazarlama etiketleri; her biri ayrı bir ağ isteği ve ayrı bir betik yürütmesi demektir.
- Font yükleme: özel fontların geç gelmesi metnin görünmesini geciktirir veya sonradan boyut değişimine yol açar.
Bu nedenlerin ağırlığı site tipine göre değişir. Ürün listeleme sayfalarında görsel yükü ve filtre betikleri öne çıkar; bu yüzden site hızı sorunları e-ticaret SEO çalışmasında neredeyse her zaman ilk gündem maddelerinden biridir.
Üçüncü taraf kodlar özel bir başlık hak eder, çünkü çoğu zaman pazarlama tarafından tek tek eklenir ve kimse kaldırmaz. Yılda bir kez etiket envanteri çıkarmak, tek bir teknik optimizasyondan daha fazla kazandırabilir.
İyileştirme sırası: önce hangi işi yapmalı?
Sıralama ilkesi nettir: en çok kullanıcıyı etkileyen sorunu, en düşük uygulama maliyetiyle çözen iş öne alınır. Bu genellikle sunucu yanıtı ve görsel optimizasyonuyla başlar, betik yönetimiyle devam eder, mimari değişiklikle biter. Tersine sıralama, aylar süren bir yeniden yazımın sonunda küçük bir kazanç bırakır.
- En çok trafik alan şablonu belirleyin: ana sayfa, kategori ve en çok ziyaret edilen içerik şablonu genellikle ilk üçtedir.
- Sunucu yanıt süresini düşürün: önbellekleme ve barındırma tarafındaki kazanç tüm sayfalara aynı anda yansır.
- Kapak ve ürün görsellerini düzenleyin: doğru boyut, modern format ve ekran genişliğine göre sunum LCP üzerinde en hızlı etkiyi verir.
- Görsel ve reklam alanlarına yer ayırın: boyut tanımlamak CLS sorunlarının büyük kısmını ortadan kaldırır.
- Üçüncü taraf kod envanterini çıkarın: kullanılmayan etiketleri kaldırın, kalanları gecikmeli yükleyin.
- JavaScript yükünü azaltın: kullanılmayan kodu ayıklayın, uzun görevleri bölün; INP iyileşmesi çoğunlukla buradan gelir.
- Font stratejisini düzeltin: font sayısını sınırlayın ve metnin font gelene kadar görünür kalmasını sağlayın.
- Ölçün ve tekrarlayın: her adımdan sonra saha verisinin oturmasını bekleyip yeniden bakın.
Bu sıra her projede birebir aynı olmaz, ancak mantığı değişmez. Ölçümün gösterdiği en zayıf metrik hangisiyse, o metriğin en ucuz çözümü listenin başına taşınır.
Tarama bütçesi ve mobil öncelikli değerlendirme
Yavaş yanıt veren bir sunucu, arama motoru robotunun aynı sürede daha az sayfa gezmesine yol açar. Bu, doğrudan bir sıralama sinyali değil, indeksleme hızını etkileyen dolaylı bir sonuçtur. Değerlendirmenin mobil sürüm üzerinden yapılması ise masaüstünde sorunsuz görünen bir sitenin gerçekte zayıf durumda olabileceği anlamına gelir.
Tarama bütçesine dolaylı etki
Tarama bütçesi, arama motorunun sitenizde belirli bir sürede gezmeye ayırdığı kaynaktır. Sunucu her istekte geç yanıt veriyorsa aynı sürede daha az adres taranır; yeni ve güncellenen sayfaların indekslenmesi gecikir.
Bu etki küçük sitelerde çoğu zaman fark edilmez. Ancak on binlerce adresi olan kataloglarda, sunucu yanıt süresini iyileştirmek doğrudan indeksleme kapsamına yansıyabilir. Konuyu ayrıntılı ele alan Google Search Central dokümantasyonu tarama davranışını açıklar.
Mobil öncelikli bakış
Değerlendirme mobil deneyim üzerinden yapıldığı için ölçümü de mobil tarafta okumak gerekir. Masaüstünde iyi görünen skorlar, orta seviye bir telefonda ve mobil bağlantıda tamamen farklı çıkabilir.
Pratik bir alışkanlık: raporlarda önce mobil sekmesine bakın, masaüstünü ikinci sırada değerlendirin. Site hızı tartışması masaüstü ekran görüntüsü üzerinden yürütüldüğünde, gerçek sorun görünmeden kalır.
Site hızı tek başına sıralama getirir mi?
Getirmez. Bir sayfa, sorgunun arkasındaki niyete karşılık vermiyorsa ne kadar hızlı açılırsa açılsın üst sıralara çıkmaz. Site hızı çalışması, içeriği yerinde olan bir sayfanın önündeki engeli kaldırır; olmayan içeriği yaratmaz. Bu yüzden performans çalışması içerik ve yapı çalışmasının yerine değil, yanına konumlandırılmalıdır.
Sahada en sık görülen hata, aylarca süren bir performans projesinin ardından sıralamanın değişmemesine şaşırmaktır. İncelendiğinde genellikle sayfanın hedeflediği sorguya yüzeysel bir yanıt verdiği, rakiplerin ise konuyu çok daha kapsamlı ele aldığı görülür.
Bunun tersi de doğrudur: içeriği güçlü ama teknik olarak yorucu bir sayfa, hak ettiği görünürlüğün altında kalabilir. Site hızının kullanıcı davranışı ve satış tarafındaki karşılığını merak ediyorsanız Core Web Vitals ile dönüşüm ilişkisini anlatan yazı konuyu o açıdan ele alıyor.
Sıkça Sorulan Sorular
Site hızı gerçekten bir sıralama faktörü mü?
Evet, site hızı sayfa deneyimi değerlendirmesinin bir parçası olarak hesaba katılır. Ancak ağırlığı sınırlıdır ve içeriğin sorguya uygunluğunun önüne geçmez. Etkisi en çok, kalite bakımından birbirine yakın sayfaların yarıştığı rekabetçi sorgularda görülür. Zayıf bir içeriği hızlandırmak tek başına sıralama kazandırmaz; kazandırdığı şey, güçlü içeriğin önündeki engelin kalkmasıdır.
PageSpeed skorunu 100'e çıkarmam gerekir mi?
Gerekmez. Skor, laboratuvar koşullarında hesaplanan özet bir puandır ve doğrudan bir sıralama girdisi değildir. Asıl bakılması gereken, gerçek kullanıcılardan toplanan saha verisindeki metriklerin iyi kabul edilen aralıkta olup olmadığıdır. Puanı son birkaç basamak yükseltmek için harcanan emek, çoğu projede içerik tarafında daha fazla kazandırır.
FID metriği neden artık raporlarda görünmüyor?
FID kullanımdan kaldırıldı ve yerini INP aldı. FID yalnızca sayfadaki ilk etkileşimin gecikmesini ölçüyordu; bu da ziyaret boyunca yaşanan yavaşlıkları çoğu zaman gizliyordu. INP ise tüm etkileşimleri değerlendirerek sayfanın genel tepkiselliğini gösterir. Eski raporlarda FID görürseniz, güncel karşılığı INP'dir.
Değişiklik yaptım, sonuç ne zaman görünür?
Laboratuvar testinde etkiyi hemen görebilirsiniz, ancak saha verisi belirli bir zaman aralığındaki gerçek ziyaretlerden derlendiği için güncellenmesi haftalar alır. Bu nedenle düzeltmeden hemen sonra rapora bakıp sonuç çıkarmayın. Doğru yaklaşım, değişiklik öncesi değerleri kaydedip birkaç hafta sonra karşılaştırmaktır.
Saha verim yok, ne yapmalıyım?
Saha verisi yeterli ziyaret olmayan adreslerde toplanamaz. Bu durumda benzer şablonu paylaşan sayfa grubunun verisine bakılır; grup düzeyinde de veri yoksa laboratuvar ölçümüyle ilerlenir. Laboratuvar sonucu mükemmel olmasa bile bariz sorunları, örneğin ağır görselleri ve bloklayan betikleri güvenle gösterir.
Hangi metrikle işe başlamalıyım?
Ölçümde en zayıf çıkan metrikle başlayın. Çoğu sitede bu LCP olur ve nedeni ağır kapak görseli ile yavaş sunucu yanıtıdır. Bu iki başlık düzeltildiğinde kullanıcı tarafındaki iyileşme en hızlı hissedilen kazanımdır. INP genellikle daha derin bir betik çalışması gerektirir, bu yüzden sonraya bırakılır.
Eklenti kurarak site hızı sorunu çözülür mü?
Kısmen. Önbellekleme ve görsel sıkıştırma eklentileri belirgin kazanç sağlayabilir, ancak sunucu kaynaklı gecikmeleri, ağır tema kodunu ve üçüncü taraf etiket yükünü çözmez. Ayrıca birden fazla optimizasyon eklentisini aynı anda çalıştırmak çakışma yaratabilir. Eklenti bir başlangıçtır; kalıcı çözüm altyapı ve kod tarafındadır.
Mobil ve masaüstü sonuçları neden bu kadar farklı?
Mobil ölçüm daha kısıtlı bir işlemci ve daha yavaş bir bağlantı varsayar. Masaüstünde saniyenin altında tamamlanan bir betik yürütmesi, orta seviye bir telefonda kat kat uzayabilir. Değerlendirme mobil sürüm üzerinden yapıldığı için raporları okurken önce mobil sekmesine bakmak doğru alışkanlıktır.
Sonuç
Site hızı, arama görünürlüğünde belirleyici değil ama gerçek bir etkendir. Rolünü doğru konumlandırdığınızda beklenti de yerine oturur: hız, hak edilmiş bir sıralamanın önündeki sürtünmeyi azaltır; hak edilmemiş bir sıralamayı satın almaz.
Bu nedenle çalışmayı ölçümle başlatmak, en zayıf metriği bulmak ve en çok kazandıran işi öne almak en sağlıklı yol. Saha verisine bakmayı alışkanlık haline getiren ekipler, hangi düzeltmenin gerçekten işe yaradığını zamanla net biçimde görmeye başlar.
Özetle site hızı SEO çalışmasının tamamlayıcı bir parçasıdır; içerik ve niyet uyumuyla birlikte ele alındığında değer üretir. Sitenizin mevcut performans durumunu ve öncelik sırasını konuşmak isterseniz iletişim sayfası üzerinden bir ön görüşme planlayabilirsiniz.
