Mobil sayfa yüklenme süresi 1 saniyeden 3 saniyeye çıktığında bounce rate %32 artıyor, Google'ın kendi verisi bu. 5 saniyeye çıkınca? %90. Rakamlar acımasız. Yavaş site ziyaretçi kaybettirir, nokta. Google Core Web Vitals metriklerini doğrudan sıralama sinyali olarak kullandığı için mesele sadece kullanıcı deneyimiyle sınırlı kalmıyor; organik görünürlüğünüz de tehlikede.
Site hızı analizi tam da bu yüzden SEO denetiminin ayrılmaz parçası.
Hangi sayfalar yavaş, neden yavaş, nasıl hızlandırılır: bu soruların cevabı somut teknik müdahaleler gerektiriyor. Güzel tarafı şu: hız sorunlarının büyük kısmı birkaç temel optimizasyonla çözülebilir. Karmaşık altyapı değişikliklerine gerek kalmadan, doğru yerlere dokunarak ciddi iyileşmeler elde edebilirsiniz.
Site hızını ölçmek için hangi araçlar kullanılır?
PageSpeed Insights en yaygın başlangıç noktası. Google'ın kendi aracı olması önemli çünkü hem laboratuvar verisi hem de gerçek kullanıcı verisi (Chrome UX Report) sunuyor. Laboratuvar verisi kontrollü ortamda yapılan simülasyondur; her seferinde aynı koşullarda test eder. Saha verisi ise gerçek ziyaretçilerin deneyimini yansıtır. İkisi arasında fark olması normal, saha verisi daha güvenilir, yeni sayfalar için yeterli veri olmayabilir ama zamanla birikir.
Daha derine inmek isteyenler için Chrome DevTools'un Performance sekmesi var. Sayfa yüklenme sürecini milisaniye milisaniye gösterir: hangi kaynak ne zaman indirilmiş, hangi script ne kadar süre çalışmış, render ne zaman başlamış. Teknik bilgi gerektirir. Karşılığında sorunun tam kaynağını bulursunuz.
WebPageTest ise farklı lokasyonlardan ve farklı bağlantı hızlarıyla test yapmanıza olanak tanır. Türkiye'deki bir kullanıcının deneyimini görmek mi istiyorsunuz? İstanbul sunucusunu seçin. Waterfall grafiği her kaynağın yüklenme süresini görsel olarak gösterir, darboğazları tespit etmek kolaylaşır.
Lighthouse da Chrome'un içinde gelen bir denetim aracı. Performance, Accessibility, Best Practices ve SEO kategorilerinde puan verir. PageSpeed Insights zaten Lighthouse motorunu kullanıyor; DevTools üzerinden çalıştırdığınızda daha fazla detay ve özelleştirme seçeneği elde edersiniz. Hangisini kullanacağınız biraz da ne kadar derine inmek istediğinize bağlı.
Görseller: en yaygın yavaşlık nedeni
Çoğu sitede sayfa ağırlığının yarısından fazlasını görseller oluşturur. Optimize edilmemiş tek bir hero görseli 2-3 MB olabilir. Mobil bağlantıda bu birkaç saniye demek, ve o birkaç saniye ziyaretçiyi kaybetmenize yeter.
Format seçimi kritik. JPEG fotoğraflar için hâlâ geçerli bir seçenek; WebP ise aynı kalitede %25-35 daha küçük dosya boyutu sunuyor. AVIF daha da küçük boyutlar vaat ediyor, tarayıcı desteği henüz WebP kadar geniş değil. Pratik yaklaşım: WebP'yi birincil format olarak kullanın, AVIF'i destekleyen tarayıcılar için <picture> elementi ile alternatif sunun.
Boyutlandırma meselesi de var.
1920x1080 piksellik bir görseli 400 piksel genişliğindeki bir alana koyuyorsanız tarayıcı gereksiz yere büyük dosya indiriyor. srcset ve sizes özelliklerini kullanarak farklı ekran boyutları için farklı görsel versiyonları sunabilirsiniz. Sadece bu adım bile sayfa ağırlığını ciddi ölçüde azaltır, üstelik kullanıcı hiçbir kalite farkı hissetmez.
Lazy loading standart pratik olmalı. Ekranın altında kalan görsellerin sayfa yüklenirken hemen indirilmesine gerek yok; HTML'de loading="lazy" özelliği bunu tarayıcıya bırakır. Dikkat edilmesi gereken nokta: above the fold, yani sayfa açıldığında görünen alandaki görsellere lazy loading uygulamayın. LCP metriğini olumsuz etkiler çünkü tarayıcı o görseli geç yüklemeye başlar. Burada yapılan hata şaşırtıcı derecede yaygın.
Sıkıştırma kalitesi ile dosya boyutu arasında denge kurmak gerekiyor. JPEG'de %80-85 kalite çoğu durumda gözle görülür fark yaratmadan dosya boyutunu yarıya indirir, WebP'de benzer sonuçlar %75-80 kalitede elde edilir. Farkı ancak görseli %200 zoom yapıp yan yana koyduğunuzda görebilirsiniz.
Render engelleyen kaynaklar
Tarayıcı bir sayfayı render etmeden önce HTML'i parse eder, CSS dosyalarını indirir ve uygular. Bu süreçte karşılaştığı her harici CSS ve JavaScript dosyası render'ı durdurabilir. Buna "render-blocking resources" deniyor, site hızı analizlerinde sık karşılaşılan bir uyarı ve genellikle ilk bakışta göründüğünden daha kolay çözülür.
CSS tarafında ne yapılır? Kritik CSS'i inline olarak <head> içine koyun, geri kalanını asenkron yükleyin. Kritik CSS, sayfanın above the fold kısmını render etmek için gereken minimum stil kuralları. İlk boyamayı (First Contentful Paint) hızlandırır. Her sayfa için farklı kritik CSS çıkarmak karmaşık olabilir; küçük sitelerde tüm CSS'i tek dosyada tutup minimize etmek daha pratik bir yol.
JavaScript daha büyük sorun.
Büyük JS dosyaları hem indirme hem parse süresi açısından maliyetli. async ve defer özelliklerini kullanın. defer script'i HTML parse edildikten sonra çalıştırır, çoğu durumda en güvenli seçenektir. async ise script'i indirildikten hemen sonra çalıştırır, sıralama garantisi vermez. Analytics gibi bağımsız script'ler için async, DOM'a bağımlı script'ler için defer tercih edin. İkisini karıştırmak yaygın bir hata ve debug etmesi sinir bozucu olabiliyor.
Kullanılmayan CSS ve JavaScript'i temizlemek de göz ardı edilmemeli. WordPress gibi CMS'lerde eklentiler kendi CSS ve JS dosyalarını her sayfaya yükler, o sayfada kullanılmasa bile. Chrome DevTools'un Coverage sekmesi hangi kodun kullanıldığını, hangisinin kullanılmadığını gösterir. Kullanılmayan kod oranı yüksekse code splitting veya koşullu yükleme düşünülmeli. Bazen tek bir eklentiyi kaldırmak sayfa hızını 1-2 saniye iyileştirebilir; bu tür sürprizler nadir değil.
Sunucu tarafı optimizasyon
İstemci tarafındaki tüm optimizasyonlar sunucu yavaşsa etkisini kaybeder. Time to First Byte (TTFB), yani sunucunun ilk yanıtı gönderme süresi, 200 milisaniyenin altında olmalı. Yüksekse sorun genellikle sunucu yapılandırması, veritabanı sorguları veya backend kodunda gizlidir. Bazen sadece bir yavaş SQL sorgusu tüm sayfayı 2 saniye geciktirebilir.
Sıkıştırma aktif mi? Gzip veya Brotli mutlaka açık olmalı. HTML, CSS ve JavaScript dosyaları metin tabanlıdır; sıkıştırma ile boyutları %60-80 oranında küçülür. Brotli, Gzip'ten daha iyi sıkıştırma oranı sunar ve modern tarayıcıların tamamı destekliyor. Sunucu yapılandırmasında birkaç satırlık değişiklikle aktif edilir, etkisine kıyasla inanılmaz düşük efor.
Protokol tarafında HTTP/2 veya HTTP/3 kullanın. HTTP/1.1'de tarayıcı aynı anda sınırlı sayıda bağlantı açabilir, kaynaklar sırayla indirilir. HTTP/2 multiplexing ile birden fazla kaynağı aynı bağlantı üzerinden paralel indirir. HTTP/3 QUIC protokolü üzerinde çalışır, özellikle yüksek gecikmeli bağlantılarda belirgin fark yaratır.
CDN (Content Delivery Network) coğrafi gecikmeyi azaltır. Sunucunuz Almanya'daysa Türkiye'deki kullanıcı her istekte yüzlerce milisaniye gecikme yaşar, bu kaçınılmaz fizik. CDN statik dosyalarınızı dünya genelindeki sunuculara dağıtır ve kullanıcıya en yakın noktadan sunar. Cloudflare, Bunny CDN gibi servisler kurulumu kolay, ücretsiz planları bile ciddi fark yaratır.
Tarayıcı önbellekleme (browser caching) de sunucu tarafında ayarlanır. Statik dosyalar için uzun cache süreleri belirleyin: CSS, JS ve görseller için en az bir yıl. Dosya değiştiğinde URL'ye versiyon parametresi ekleyerek (style.css?v=2) önbelleği geçersiz kılabilirsiniz. Basit, etkili, bir kere ayarlayıp unutacağınız bir şey.
Core Web Vitals ve hız ilişkisi
Core Web Vitals üç metrikten oluşur. Hepsi doğrudan site hızıyla bağlantılı ve Google'ın sıralama algoritmasında ağırlığı giderek artıyor.
LCP (Largest Contentful Paint) sayfadaki en büyük içerik öğesinin render süresini ölçer, genellikle hero görseli veya büyük bir metin bloğu. 2,5 saniyenin altında olmalı. İyileştirmek için görselleri optimize edin, sunucu yanıt süresini düşürün, render engelleyen kaynakları azaltın ve kritik kaynaklar için preload kullanın. Çoğu sitede LCP sorununun kaynağı optimize edilmemiş tek bir görsel oluyor.
INP (Interaction to Next Paint) kullanıcı etkileşimlerine sayfanın ne kadar hızlı yanıt verdiğini ölçer. Bir butona tıkladığınızda veya bir form alanına yazdığınızda sayfa ne kadar sürede görsel geri bildirim veriyor? 200 milisaniyenin altında olmalı. Ağır JavaScript işlemleri, uzun main thread görevleri ve aşırı DOM boyutu INP'yi kötüleştirir. Özellikle SPA (Single Page Application) mimarilerinde INP sorunları daha sık ortaya çıkıyor.
CLS (Cumulative Layout Shift) ise sayfa yüklenirken içeriğin beklenmedik şekilde kaymasını ölçer. Bir yazı okurken aniden reklam yüklenir, metin aşağı kayar, herkesin sinirini bozan o durum. 0,1'in altında olmalı. Görsellere ve iframe'lere genişlik/yükseklik belirtin, dinamik içerikleri sayfanın üstüne enjekte etmeyin, web fontları için font-display: swap kullanın.
SEO skorunuzu değerlendirirken Core Web Vitals metriklerini mutlaka kontrol edin. Search Console'daki Core Web Vitals raporu site genelindeki durumu özetler: hangi sayfalar "iyi", hangileri "iyileştirme gerekli", hangileri "kötü" kategorisinde. Bu raporu ayda bir kontrol etmek bile çoğu sorunu erken yakalamanızı sağlar.
Hız optimizasyonunda önceliklendirme
Her şeyi aynı anda yapmaya çalışmak verimsiz.
En büyük etkiyi yaratacak değişikliklerden başlayın. Görseller genellikle ilk hedef: sıkıştırılmamış görselleri WebP'ye çevirmek ve boyutlandırmak çoğu sitede sayfa ağırlığını %40-60 azaltır. Teknik bilgi gerektirmez, etkisi hemen görülür. Bir görseli optimize etmek beş dakika sürer, LCP üzerindeki etkisi saniyeler mertebesinde olabilir.
Render engelleyen kaynaklar ikinci sırada. Kullanılmayan CSS ve JavaScript'i kaldırmak veya ertelemek First Contentful Paint süresini belirgin şekilde düşürür. Üçüncü parti script'ler (analytics, chat widget'ları, reklam kodları) sayfa hızını beklenenden çok etkiler. Bir e-ticaret sitesinde sadece kullanılmayan üç eklentiyi kaldırmak FCP'yi 1,8 saniye iyileştirebilir; bu tür kazanımlar nadir değil.
Sunucu tarafı üçüncü sırada geliyor. Sıkıştırma aktif değilse aktif edin, CDN kullanmıyorsanız ekleyin, cache başlıkları doğru ayarlanmamışsa düzeltin. Bu değişiklikler bir kere yapılır, tüm sayfaları etkiler.
Her değişiklikten sonra ölçüm yapın. PageSpeed Insights'ta önceki ve sonraki skorları karşılaştırın. Düzenli SEO denetimi kapsamında hız metriklerini aylık takip edin; yeni eklenen bir script veya optimize edilmemiş bir görsel fark etmeden hızı düşürebilir. Site hızı bir kere düzeltilip bırakılacak bir konu değil, yeni içerik eklendikçe, yeni özellikler geliştirildikçe hız tekrar bozulabilir. Sürekli izleme ve periyodik optimizasyon şart. Bunu ihmal eden siteler altı ay sonra başladıkları noktaya geri dönüyor.