Web sitesi hızı SEO'yu etkiler; ancak hızlı bir web sitesi tek başına yüksek Google sıralaması garantisi vermez. Google'ın sıralama sistemleri gerçek kullanıcı deneyimini ölçen Core Web Vitals verilerini kullanır. Bunun yanında içerik kalitesi, arama niyetine uygunluk, teknik erişilebilirlik, bağlantılar ve genel sayfa deneyimi gibi birçok sinyal birlikte değerlendirilir.
Bu nedenle site hızını “Google'dan birkaç sıra kazanmak için alınacak bir PageSpeed puanı” olarak değerlendirmek yerine SEO, kullanıcı deneyimi ve web performansının ortak bir parçası olarak görmek gerekir.
Özellikle rekabetin yüksek olduğu sorgularda benzer kalitede iki sayfadan daha iyi kullanıcı deneyimi sağlayan sayfanın önemli bir avantajı olabilir. Google da çok sayıda faydalı sonucun bulunduğu sorgularda iyi sayfa deneyiminin arama başarısına katkıda bulunabileceğini açıkça belirtiyor.
Site hızının SEO üzerindeki etkisini yalnızca “sayfa kaç saniyede açılıyor?” sorusuyla açıklamak yeterli değildir.
Performans aslında birkaç farklı alana etki eder:
Google'ın kendi dokümantasyonunda Core Web Vitals'ın sıralama sistemlerinde kullanıldığı açıkça belirtiliyor. Bununla birlikte Google, tek bir “page experience ranking signal” bulunmadığının ve Core Web Vitals değerlerinin mükemmel olmasının otomatik olarak üst sıralama sağlamayacağının da altını çiziyor.
Evet. Core Web Vitals, Google'ın sıralama sistemlerinin kullandığı sinyaller arasındadır. Ancak sayfa hızı tek başına bir sayfanın sıralamasını belirlemez.
Örneğin:
Google yalnızca hız nedeniyle A sitesini B sitesinin üzerinde göstermek zorunda değildir. Arama motorunun temel amacı hâlâ kullanıcı için en alakalı ve faydalı sonucu sunmaktır.
Bu ayrım modern SEO açısından oldukça önemlidir.
Core Web Vitals, Google tarafından gerçek kullanıcı deneyiminin belirli bölümlerini değerlendirmek amacıyla kullanılan performans metrikleridir.
Güncel Core Web Vitals seti üç temel metriğe odaklanır:
| Metrik | Neyi Ölçer? | İyi Değer |
|---|---|---|
| LCP – Largest Contentful Paint | Ana içeriğin yüklenme süresi | ≤ 2,5 saniye |
| INP – Interaction to Next Paint | Kullanıcı etkileşimlerine verilen tepki | ≤ 200 ms |
| CLS – Cumulative Layout Shift | Görsel kararlılık | ≤ 0,1 |
Google ve web.dev, bu eşiklerin kullanıcı ziyaretlerinin 75. yüzdelik diliminde, mobil ve masaüstü ayrı değerlendirilerek karşılanmasını öneriyor.
Buradaki ayrıntı önemlidir:
Tek bir hızlı test sonucu sitenizin Core Web Vitals açısından başarılı olduğu anlamına gelmez.
Gerçek kullanıcıların farklı cihaz, internet bağlantısı, lokasyon ve kullanım koşullarındaki deneyimleri dikkate alınır.
Largest Contentful Paint (LCP) kullanıcının ekranında görünen ana içeriğin ne kadar sürede görüntülendiğini ölçer.
Bu genellikle:
olabilir.
İyi kullanıcı deneyimi için LCP'nin 2,5 saniye veya altında olması önerilir.
En sık karşılaşılan nedenler şunlardır:
Örneğin sitenin ana banner görseli 3 MB boyutundaysa yalnızca sunucuyu değiştirmek problemi tamamen çözmeyebilir. Görselin WebP veya AVIF formatına dönüştürülmesi, uygun ölçülerde servis edilmesi ve kritik kaynakların doğru önceliklendirilmesi gerekir.
Interaction to Next Paint (INP) kullanıcının sayfadaki bir etkileşimine tarayıcının ne kadar hızlı görsel yanıt verdiğini ölçer.
Örneğin kullanıcı:
Butona basıldıktan sonra sayfa uzun süre tepki vermiyorsa kullanıcı açısından site “yüklenmiş” olsa bile hızlı değildir.
İyi INP değeri 200 milisaniye veya daha düşük kabul edilir.
Genellikle şu noktalara bakılır:
Özellikle modern web sitelerinde sadece görselleri sıkıştırmak yeterli değildir. JavaScript performansı çoğu zaman kullanıcı etkileşimlerini doğrudan etkiler.
Cumulative Layout Shift (CLS) sayfanın yüklenirken beklenmedik şekilde hareket edip etmediğini ölçer.
Örneğin kullanıcı bir butona basacakken:
Bu kötü bir kullanıcı deneyimidir.
İyi CLS değeri 0,1 veya altında olmalıdır.
CLS optimizasyonunun amacı her şeyi hızlı yüklemek değil, sayfanın kullanıcı karşısında görsel olarak kararlı kalmasını sağlamaktır.
SEO çalışmalarında en sık gördüğümüz yanlışlardan biri şudur:
“Rakibin PageSpeed puanı 80, benimki 95. O zaman benim onun üzerinde çıkmam gerekir.”
Hayır.
PageSpeed Insights performans skoru doğrudan Google sıralama puanı değildir.
Google PageSpeed Insights içerisinde hem gerçek kullanıcı verileri hem de Lighthouse tarafından simüle edilen laboratuvar verileri kullanılabilir.
Google'ın dokümantasyonuna göre Lighthouse performans skorunda:
olarak değerlendirilir.
Fakat bu değerler:
“90'ın üzerindeyseniz SEO açısından başarılısınız.”
anlamına gelmez.
Öncelik sırası kabaca şöyle olmalıdır:
PageSpeed puanının amacı size optimizasyon yapılabilecek alanları göstermektir.
100 puan almak uğruna işlevsel özellikleri kaldırmak veya kullanıcı deneyimini bozmak doğru bir SEO stratejisi değildir.
Google da sırf SEO amacıyla mükemmel bir skor peşinde koşmanın zamanın en verimli kullanımı olmayabileceğini özellikle belirtiyor.
PageSpeed Insights incelenirken bu ayrım mutlaka bilinmelidir.
Gerçek Chrome kullanıcılarından elde edilen performans verileridir.
Google'ın Chrome User Experience Report (CrUX) verilerine dayanır.
PageSpeed Insights'taki gerçek kullanıcı verileri geriye dönük 28 günlük bir dönemi temsil eder ve PSI tarafındaki field data günlük olarak güncellenir.
Dolayısıyla bugün yaptığınız optimizasyonun gerçek kullanıcı Core Web Vitals verilerine anında tamamen yansımasını beklememelisiniz.
Lighthouse tarafından kontrollü bir ortamda yapılan testtir.
Avantajı, teknik problemlerin teşhisinde son derece kullanışlı olmasıdır.
Ancak gerçek kullanıcının:
birebir temsil etmez.
Bu nedenle SEO analizi yaparken yalnızca Lighthouse ekranındaki tek bir rakama bakmak yanlış sonuçlara yol açabilir.
“Web sitesi 2 saniyede açılmalı” gibi kesin bir SEO kuralı yoktur.
Daha doğru yaklaşım Core Web Vitals üzerinden değerlendirmektir.
Ana içeriğin görünür hâle gelmesini ölçen LCP için hedef 2,5 saniye veya altıdır.
Ancak aynı anda şunlara da bakılmalıdır:
Bir sitenin ekranda hızlı görünmesine rağmen birkaç saniye boyunca etkileşime cevap vermemesi de kötü performanstır.
Bu nedenle modern web performansı artık sadece “loading time” üzerinden değerlendirilmez.
Hosting altyapısı özellikle sunucu yanıt sürelerinde önemli rol oynar.
Sunucu tarafında problem varsa tarayıcı daha HTML belgesini almadan beklemeye başlar.
Bu da sonrasında:
TTFB → içerik yükleme → LCP
zincirinin tamamını etkileyebilir.
Örneğin yüksek TTFB şu nedenlerden kaynaklanabilir:
Ancak burada önemli bir SEO ayrımı vardır:
Her yavaş site problemi hosting kaynaklı değildir.
3 MB banner görseli, yüzlerce kilobyte kullanılmayan JavaScript ve onlarca üçüncü taraf script bulunan bir web sitesini yalnızca daha güçlü bir sunucuya taşıyarak tamamen optimize edemezsiniz.
İyi performans için uygulama ve altyapının birlikte değerlendirilmesi gerekir.
Web9 gibi hosting altyapısı sağlayıcılarını değerlendirirken de yalnızca disk kapasitesine değil; sunucu kaynakları, web sunucusu teknolojisi, cache imkânları, PHP performansı, lokasyon ve ölçeklenebilirlik gibi kriterlere bakmak daha doğru olacaktır.
Time to First Byte (TTFB) tarayıcının isteği göndermesi ile sunucudan ilk byte'ın gelmesi arasında geçen süreyi ifade eder.
TTFB Core Web Vitals metriklerinden biri değildir.
Ancak LCP gibi önemli yükleme metriklerinin başlangıç noktasında bulunduğu için performans üzerinde büyük etkisi olabilir.
Örneğin sunucu ilk HTML belgesini 1,8 saniyede gönderiyorsa LCP'nin 2,5 saniye hedefini yakalaması doğal olarak zorlaşır. web.dev de yüksek TTFB'nin LCP hedefinin yakalanmasını zorlaştırabileceğine dikkat çekiyor.
CDN kullanmanız doğrudan:
“+5 SEO puanı”
kazandırmaz.
Ancak doğru yapılandırılmış CDN:
sağlayabilir.
Bunlar da web performansı ve kullanıcı deneyimi üzerinden dolaylı fayda oluşturabilir.
Özellikle Türkiye dışından ziyaretçi alan uluslararası projelerde CDN'in etkisi daha belirgin hâle gelebilir.
Birçok web sitesinde sayfa ağırlığının önemli bölümü görsellerden oluşur.
Özellikle:
LCP performansını ciddi biçimde etkileyebilir.
WebP veya AVIF kullanın.
Modern formatlar uygun içeriklerde dosya boyutunu önemli ölçüde azaltabilir.
Görüntüyü kullanılacağı boyutta servis edin.
400×300 px gösterilecek bir görseli 4000×3000 px indirtmeyin.
Responsive images kullanın.srcset ve sizes ile farklı ekranlara uygun kaynak sağlayın.
Lazy loading uygulayın.
Ekranın aşağısındaki görselleri gerektiğinde yükleyin.
Ancak önemli bir ayrıntı:
Sayfanın ana LCP görselini agresif lazy-load etmek ters etki yaratabilir.
Tarayıcının en önemli görseli geç keşfetmesine neden olarak LCP'yi kötüleştirebilirsiniz.
Modern web sitelerinde performans problemlerinin büyük bölümü yalnızca görsellerden değil JavaScript ve CSS katmanından kaynaklanabilir.
Özellikle:
sayfayı ağırlaştırabilir.
Above-the-fold alanının görüntülenmesi için gereken CSS'in hızlı erişilebilir olması önemlidir.
Bir sayfanın ihtiyacı olmayan yüzlerce kilobyte CSS dosyasını yüklemek gereksiz ağ ve işleme maliyeti yaratır.
Büyük JavaScript görevleri tarayıcının ana thread'ini meşgul ederek INP performansını kötüleştirebilir.
Bu nedenle optimizasyon sadece:
“Dosyaları minify ettik, tamamdır.”
şeklinde ele alınmamalıdır.
Ne kadar kod yüklendiği kadar ne zaman ve neden yüklendiği de önemlidir.
WordPress sitelerde performans problemi çoğu zaman tek bir nedenden kaynaklanmaz.
İyi bir optimizasyon sırası şu şekilde olabilir:
Öncelikle TTFB incelenmelidir.
Backend zaten yavaşsa frontend optimizasyonlarının etkisi sınırlı kalabilir.
Dinamik olarak her ziyarette yeniden PHP ve veritabanı işlemleri çalıştırmak yerine uygun sayfalarda cache mekanizması kullanılabilir.
WebP/AVIF, responsive images ve doğru lazy-loading politikası uygulanmalıdır.
“Pasif eklentileri silmek” kadar aktif fakat gereksiz yük oluşturan eklentileri tespit etmek de önemlidir.
Kullanılmayan kaynakları kaldırın veya yalnızca ihtiyaç duyulan sayfalarda yükleyin.
Gereksiz font ailesi ve ağırlıklarının tamamını indirtmeyin.
Özellikle uluslararası trafik ve yoğun statik içerikte faydalı olabilir.
WooCommerce gibi dinamik sistemlerde yavaş sorgular frontend optimizasyonlarının önüne geçebilir.
Google, çoğu site için içeriğin mobil sürümünü indeksleme ve sıralama amacıyla kullanır. Googlebot isteklerinin çoğunluğu da mobil crawler üzerinden gerçekleştirilir.
Ayrıca gerçek kullanıcıların mobil koşulları masaüstünden çok daha değişkendir.
Bir ziyaretçi:
ile sitenize erişebilir.
Geliştiricinin güçlü bilgisayarında 0,8 saniyede açılan bir site gerçek kullanıcıda aynı performansı göstermeyebilir.
Bu nedenle performans çalışmalarında yalnızca masaüstü PageSpeed skorunu takip etmek ciddi bir hata olabilir.
Burada da gereksiz genellemelerden kaçınmak gerekir.
Googlebot hangi sitenin ne sıklıkta ve kaç sayfa taranacağını algoritmik olarak belirler. Google ayrıca sunucu kullanılabilirliği sorunlarının taramayı sınırlayabileceğini belirtiyor.
Ancak küçük bir kurumsal web sitesinde:
“Siteyi 300 ms hızlandırırsam crawl budget iki katına çıkar.”
gibi bir hesap yapmak doğru değildir.
Crawl budget konusu özellikle:
için daha anlamlıdır.
SEO açısından öncelik çoğu sitede sunucunun Googlebot'a stabil şekilde cevap verebilmesi ve gereksiz URL üretiminin engellenmesi olmalıdır.
Bu sorunun cevabı:
İkisini rakip faktörler gibi düşünmemek gerekir.
Google açık biçimde en alakalı içeriği sunmayı amaçladığını ve düşük sayfa deneyimine sahip bir içeriğin sırf bu nedenle her zaman geriye atılmayacağını belirtiyor.
Dolayısıyla:
mükemmel performans + kötü içerik = güçlü SEO değildir.
Aynı şekilde:
mükemmel içerik + ciddi teknik problemler = potansiyelin altında performans
anlamına gelebilir.
En güçlü yaklaşım:
Arama niyeti + kaliteli içerik + taranabilirlik + performans + iyi kullanıcı deneyimi
kombinasyonudur.
Google'ın generative AI arama deneyimleri için yayımladığı güncel rehbere göre mevcut temel SEO uygulamaları AI özellikleri açısından da geçerliliğini koruyor. Google, AI Overviews ve AI Mode gibi özelliklerin temel Search sıralama ve kalite sistemlerine dayandığını belirtiyor.
Yani AI sonuçlarında görünmek için ayrı bir “gizli hız optimizasyonu” bulunmuyor.
Önemli olan hâlâ:
Google ayrıca AI Search görünürlüğü için özel llms.txt dosyaları veya benzeri taktiklere gereğinden fazla odaklanmak yerine temel SEO stratejilerine öncelik verilmesini öneriyor.
Bu nedenle site performansı da yeni bir “GEO hilesi” olarak değil, kaliteli web deneyiminin parçası olarak ele alınmalıdır.
SEO çalışmasında tek bir araç yerine farklı veri kaynaklarını birlikte kullanmak daha sağlıklıdır.
Tekil sayfaların:
incelemek için kullanılabilir.
Site genelindeki URL gruplarında Core Web Vitals problemlerini takip etmek için uygundur. Google da site sahiplerine Search Console Core Web Vitals raporunu kullanmalarını öneriyor.
Geliştirici seviyesinde:
incelenebilir.
Daha gelişmiş projelerde gerçek kullanıcılardan doğrudan performans metriği toplanarak cihaz, ülke, sayfa tipi ve kullanıcı segmenti bazında analiz yapılabilir.
Özellikle yüksek trafikli e-ticaret ve SaaS projelerinde yalnızca sentetik testlere bağımlı kalmamak için güçlü bir yöntemdir.
Bir performans projesinde her PageSpeed uyarısını aynı önemde görmek yerine en büyük kullanıcı etkisini oluşturan sorunlardan başlanmalıdır.
1. Önce gerçek Core Web Vitals problemini belirleyin.
LCP mi?
INP mi?
CLS mi?
Hepsi mi?
2. Problemin kaynağını bulun.
LCP kötüyse doğrudan “görselleri sıkıştırın” demek yerine:
zincirini inceleyin.
3. Sayfa şablonuna göre analiz edin.
Ana sayfa hızlı olsa bile:
yavaş olabilir.
4. Mobil gerçek kullanıcı verisine bakın.
Güçlü masaüstü bilgisayarda alınan skor tek başına yeterli değildir.
5. Optimizasyonu tekrar ölçün.
Performans optimizasyonu bir defalık işlem değildir.
Yeni:
Core Web Vitals performansını yeniden bozabilir.
Teknik SEO çalışmalarında en verimli yaklaşım, PageSpeed Insights ekranındaki her kırmızı uyarıyı mekanik biçimde düzeltmeye çalışmak değildir.
Örneğin LCP problemi bulunan bir sayfada:
Durum A
TTFB: 1,7 saniye
LCP: 4,1 saniye
Burada yalnızca görsel sıkıştırmaya odaklanmak büyük resmi kaçırabilir.
Durum B
TTFB: 250 ms
LCP görseli: 2,5 MB
LCP: 4 saniye
Bu senaryoda sunucuyu değiştirmek yerine görsel pipeline'ına müdahale etmek çok daha mantıklı olabilir.
Durum C
LCP: 1,8 saniye
INP: 450 ms
Sayfa hızlı görünmesine rağmen JavaScript yoğunluğu nedeniyle kullanımı ağır olabilir.
Bu yüzden iyi web performansı optimizasyonu:
ölç → darboğazı belirle → düzelt → tekrar ölç
döngüsüyle gerçekleştirilmelidir.
Web sitesi hızı modern SEO'nun önemli teknik bileşenlerinden biridir.
Google'ın güncel yaklaşımında Core Web Vitals sıralama sistemlerinde kullanılmaktadır, fakat Google aynı zamanda tek bir sayfa deneyimi sinyalinin bulunmadığını ve mükemmel performans değerlerinin üst sıralamayı garanti etmediğini açıkça belirtmektedir.
Bu nedenle hedefiniz:
“PageSpeed'de 100 puan almak”
değil;
“gerçek kullanıcıların hızlı, kararlı ve tepkisel bir web deneyimi yaşamasını sağlamak”
olmalıdır.
Bunun için içerik, frontend, backend ve hosting altyapısı birlikte değerlendirilmelidir.
Doğru yapılandırılmış hızlı bir web sitesi yalnızca SEO için değil; kullanıcı deneyimi, dönüşüm, marka güveni ve sitenin genel teknik kalitesi açısından da uzun vadeli avantaj sağlar.
Evet. Google, Core Web Vitals verilerinin sıralama sistemlerinde kullanıldığını belirtmektedir. Ancak hız tek başına sıralama belirleyen bir faktör değildir; içerik kalitesi ve alaka düzeyi gibi başka birçok sinyal de değerlendirilir.
Hız optimizasyonu sıralama başarısına katkıda bulunabilir ancak “siteyi iki saniye hızlandırınca üç sıra yükselirsiniz” şeklinde doğrusal bir ilişki bulunmaz.
Lighthouse performans skorunda 90 ve üzeri iyi kabul edilir. Ancak bu bir Google sıralama puanı değildir. Core Web Vitals ve gerçek kullanıcı deneyimine ayrıca bakılmalıdır.
Hayır. Google, sırf SEO amacıyla mükemmel skor peşinde koşmanın zamanın en doğru kullanımı olmayabileceğini açıkça ifade ediyor.
İyi kullanıcı deneyimi için LCP'nin 2,5 saniye veya altında olması önerilir.
İyi INP değeri 200 milisaniye veya daha düşük olmalıdır.
İyi kullanıcı deneyimi için CLS değerinin 0,1 veya altında olması önerilir.
Hosting tek başına SEO sıralaması sağlamaz; ancak sunucu yanıt süresi, kullanılabilirlik ve sayfa performansı üzerinden web deneyimini etkileyebilir. Özellikle yüksek TTFB değerlerinde hosting ve backend altyapısı incelenmelidir.
CDN doğrudan SEO puanı sağlamaz. Ancak içeriğin daha hızlı dağıtılmasına ve sunucu yükünün azaltılmasına yardımcı olduğunda kullanıcı deneyimi ve performans üzerinde olumlu etki yaratabilir.
İkisi de önemlidir. Bununla birlikte Google çoğu web sitesi için mobil içerik sürümünü indeksleme ve sıralamada kullanmaktadır. Bu nedenle mobil performansın ihmal edilmemesi gerekir.
Optimize edilmemiş büyük görseller sayfa yükleme süresini ve özellikle LCP'yi kötüleştirebilir. Görseller doğru boyut, format ve yükleme stratejisiyle sunulmalıdır.
Hayır. Ekranın altında bulunan görseller için faydalı olabilir; ancak ana LCP görselini gereksiz yere lazy-load etmek içeriğin geç yüklenmesine neden olabilir.
Core Web Vitals, gerçek kullanıcı deneyimindeki yükleme performansı, etkileşim hızı ve görsel kararlılığı ölçen LCP, INP ve CLS metriklerinden oluşur.
Her zaman değil. Core Web Vitals gerçek kullanıcı verileri belirli bir dönem üzerinden değerlendirildiği için iyileştirmelerin saha verilerine tamamen yansıması zaman alabilir. PageSpeed Insights'taki CrUX tabanlı saha verileri geriye dönük 28 günlük dönemi temsil eder.
Bazı eklentiler ek JavaScript, CSS, veritabanı sorguları veya üçüncü taraf bağlantıları oluşturabilir. Sorun eklenti sayısından çok, kullanılan eklentilerin sayfaya getirdiği toplam yük ve çalışma biçimidir.
Sadece hız sayesinde güçlü ve alakalı içeriklerin önüne geçmek beklenmemelidir. Google, en alakalı içeriği göstermeyi amaçlar ve sayfa deneyimi bu değerlendirmenin yalnızca bir bölümüdür.