Site Hızı Neden Önemlidir? Nasıl Yükseltilir?

Bir sayfanın açılma süresi, kullanıcının o sayfayla kuracağı ilişkinin ilk cümlesidir. Yavaş açılan bir site, içeriği ne kadar iyi olursa olsun ziyaretçinin sabrını daha ilk saniyede harcar. Site hızı, bu yüzden yalnızca teknik bir konu değil; doğrudan gelir tarafına bakan bir iş metriğidir.

Hız neden bu kadar önemli?

Üç somut sebep var:

1. Dönüşüm. Açılma süresindeki her ek saniye, sepete ekleme ve satın alma oranlarını ölçülebilir biçimde düşürür. Etki en çok mobilde ve ilk kez gelen ziyaretçilerde görülür.
2. Sıralama. Google, sayfa deneyimi sinyallerini sıralama hesabına katıyor. Hız tek başına sizi üst sıraya taşımaz; ancak içerik kalitesi benzer olan iki sayfa arasında ayrıştırıcı olur.
3. Reklam verimliliği. Tıklama başına ödeme yaptığınız trafiğin bir kısmı sayfa açılmadan geri dönüyorsa, o para tamamen kayıptır. Yavaş açılış, reklam bütçenizi görünmez biçimde eritir.

Core Web Vitals: hızın ölçülebilir hâli

Google, kullanıcı deneyimini üç ölçütle sayısallaştırıyor:

1. LCP (Largest Contentful Paint): Sayfadaki en büyük görsel veya metin bloğunun ne zaman göründüğü. Hedef: 2,5 saniyenin altı.
2. INP (Interaction to Next Paint): Kullanıcının tıklamasından sonra arayüzün cevap verme süresi. Hedef: 200 milisaniyenin altı. Bu ölçüt, eskiden kullanılan FID’in yerini aldı ve etkileşimin tamamını ölçtüğü için çok daha gerçekçi sonuç veriyor.
3. CLS (Cumulative Layout Shift): Sayfa yüklenirken içeriğin kayma miktarı. Hedef: 0,1’in altı.

Bu üç ölçütün ne anlama geldiğini ve nasıl iyileştirildiğini Core Web Vitals rehberimizde ayrıntılı olarak ele aldık. Burada önemli olan şu ayrım: laboratuvar testleri (Lighthouse) bir simülasyondur; Google’ın sıralamada kullandığı veri ise gerçek kullanıcılardan toplanan alan verisidir. Lighthouse skoru 95 olan bir sitenin alan verisinde kırmızı görünmesi son derece olağandır.

Siteyi yavaşlatan gerçek sebepler

Optimize edilmemiş görseller

Uygulamada karşılaştığımız en yaygın sebep budur. 2500 piksel genişliğindeki bir fotoğrafın 400 piksellik alanda gösterilmesi, boşa indirilen megabaytlar demektir. Çözüm üç adımlıdır: görselleri gösterildikleri boyuta göre yeniden üretmek, WebP veya AVIF gibi modern biçimlere geçmek ve ekranda görünmeyen görselleri geciktirmeli (lazy) yüklemek.

Sunucu yanıt süresi

Tarayıcı isteği gönderdikten sonra sunucunun ilk baytı göndermesi uzun sürüyorsa, sonrasında yapacağınız hiçbir optimizasyon bu gecikmeyi telafi etmez. Paylaşımlı hostingden kaynaklanan yavaşlık, optimize edilmemiş veritabanı sorguları ve önbelleğin devre dışı olması en sık görülen sebeplerdir. Hedef, ilk bayt süresini 600 milisaniyenin altında tutmaktır.

Üçüncü taraf betikleri

Analitik, sohbet balonu, ısı haritası, A/B test aracı, pazarlama otomasyonu, sosyal medya pikselleri… Her biri tek başına masum görünür; toplamda sayfayı kilitleyen ana sebep olurlar. Etiket yöneticisi üzerinden yüklenen ve kimsenin artık bakmadığı eski etiketler, birçok sitede sessizce çalışmaya devam eder. Yılda bir kez etiket envanteri çıkarmak, çoğu zaman en hızlı kazancı verir.

Render’ı bloke eden CSS ve JavaScript

Sayfanın ilk görünümü için gerekmeyen stil ve betik dosyaları, tarayıcının çizim işlemini geciktirir. Kritik CSS’i ayırmak, geri kalanını ertelemek ve kullanılmayan kodu temizlemek LCP üzerinde doğrudan etkilidir.

Yazı tipleri

Özel yazı tipleri yüklenene kadar metnin görünmemesi, hem LCP’yi hem de algılanan hızı bozar. font-display: swap kullanmak ve yalnızca gerçekten kullanılan ağırlıkları yüklemek sorunu büyük ölçüde çözer.

Beklenmeyen kaymalar

Boyutu belirtilmemiş görseller, sonradan yüklenen reklam alanları ve sayfa açıldıktan sonra beliren çerez bildirimleri CLS’i bozar. Çözüm basittir: her medya öğesine genişlik ve yükseklik vermek, dinamik alanlara önceden yer ayırmak.

Nereden başlamalı? Öncelik sırası

Hız çalışmasında en sık yapılan hata, listenin başından sonuna kadar her şeyi aynı anda yapmaya çalışmaktır. Verimli sıra şudur:

1. Alan verisini okuyun: Search Console’daki Core Web Vitals raporu hangi sayfa gruplarının sorunlu olduğunu söyler.
2. En çok trafik alan üç şablonu seçin (ana sayfa, kategori, ürün/yazı). Sitenin tamamını değil, bu şablonları düzeltin.
3. Görselleri ve sunucu yanıt süresini halledin. Vakaların çoğunda kazancın büyük kısmı buradan gelir.
4. Üçüncü taraf betiklerini envantere alın ve gereksizleri kaldırın.
5. Kritik CSS, yazı tipi ve kayma düzeltmeleriyle ince ayar yapın.

WordPress kullanıyorsanız bu adımların platforma özgü karşılıklarını WordPress site hızlandırma yazımızda adım adım anlattık.

Hız ile hemen çıkma oranı ilişkisi

Yavaş sayfalarda hemen çıkma oranı yükselir, ancak her yüksek çıkma oranı hız sorunu değildir. İçerik beklentiyi karşılamıyorsa kullanıcı hızlı açılan bir sayfadan da çıkar. Bu ayrımı doğru yapmak için hız iyileştirmesinden önce ve sonra aynı sayfa grubunu karşılaştırmak gerekir. Konunun davranış tarafını hemen çıkma oranını düşürme yazımızda ele aldık.

Ölçüm araçları ve doğru okuma

PageSpeed Insights hem laboratuvar hem alan verisini bir arada gösterdiği için başlangıç noktası olarak en pratik araçtır. Tarayıcının geliştirici araçlarındaki performans sekmesi, hangi kaynağın kaç milisaniye bloke ettiğini görmenizi sağlar. Sonuçları okurken iki kuralı unutmayın: mobil sekmesine bakın (kullanıcıların çoğunluğu oradadır) ve tek sayfaya değil, şablon bazında birden fazla sayfaya bakın.

Hızın SEO içindeki ağırlığını abartmamak da önemli. Google’ın doğruladığı sıralama faktörleri arasında sayfa deneyimi vardır, ancak içerik kalitesi ve alaka düzeyi hâlâ çok daha belirleyicidir. Hız, iyi içeriğin önündeki engeli kaldırır; kötü içeriği kurtarmaz.

Mobil ve masaüstü neden bu kadar farklı sonuç verir?

Aynı sayfa masaüstünde 1,8 saniyede, mobilde 6 saniyede açılabilir. Sebep yalnızca bağlantı hızı değildir. Mobil cihazların işlemci gücü daha düşüktür ve JavaScript işleme yükü orantısız biçimde artar. Masaüstünde fark edilmeyen bir betik, orta seviye bir telefonda ana iş parçacığını saniyelerce meşgul edebilir.

Bu yüzden ölçümü her zaman mobil sekmesinden yapmak gerekir. Türkiye’de çoğu e-ticaret sitesinde trafiğin dörtte üçünden fazlası mobilden gelir; masaüstü skoruna bakarak alınan kararlar bu kitleyi görmez.

Hız iyileştirmesinin iş sonucuna etkisini nasıl kanıtlarsınız?

Teknik ekipten kaynak isterken “site yavaş” demek genellikle yetmez. Etkiyi göstermenin pratik yolu şudur: iyileştirme öncesi dört hafta ile sonrası dört haftayı aynı sayfa grubu, aynı trafik kaynağı ve aynı cihaz türü için karşılaştırın. Bakılacak üç metrik dönüşüm oranı, sayfa başına oturum süresi ve organik tıklama oranıdır.

Karşılaştırmayı bozabilecek etkenleri de not etmek gerekir: kampanya dönemleri, fiyat değişiklikleri ve Google güncellemeleri sonucu tek başına etkileyebilir. Bu yüzden mümkünse iyileştirmeyi tüm siteye aynı anda değil, önce tek bir şablona uygulamak en temiz ölçümü verir.

Yayına alma sürecine hız kontrolü eklemek

Hız çalışmalarının en büyük sorunu kalıcı olmamasıdır. Üç ayda toparlanan bir site, yeni eklenen bir sohbet balonu ve birkaç yeni pikselle altı ay içinde eski hâline döner. Bunu önlemenin yolu hızı sürekli bir kontrol maddesine çevirmektir:

1. Her yeni üçüncü taraf betiği için “bu ne kadar yavaşlatıyor?” sorusunun cevaplanması
2. Yayına alınan her görselin boyut ve format kuralından geçmesi
3. Ayda bir kez alan verisinin raporlanması ve eşik aşıldığında uyarı üretilmesi
4. Etiket yöneticisindeki pasif etiketlerin çeyrekte bir temizlenmesi

Bu dört madde, tek seferlik bir hız projesinden çok daha kalıcı sonuç verir; çünkü sorunu oluşmadan önce yakalar.

Metrikleri ayrıntılı ele aldığımız rehberler

Bu yazıda genel çerçeveyi çizdik. Her metriği derinlemesine ele aldığımız rehberler:

1. LCP nedir? LCP'nin dört alt aşaması ve her aşama için iyileştirme yöntemleri
2. CLS nedir? Kayma puanı hesabı, oturum pencereleri ve kaymaların gerçek sebepleri
3. FCP nedir? İlk içerik çizimi ve render engelleyici kaynaklar
4. TTFB nedir? Sunucu yanıt süresinin alt aşamaları ve düşürme yöntemleri
5. RTT nedir? Ağ gecikmesinin sayfa hızına görünmeyen etkisi

Özetle

Site hızı, dönüşüm ve sıralamanın ortak paydasıdır. Alan verisinden başlayıp en çok trafik alan şablonlara odaklanmak, görsel ve sunucu tarafını düzelttikten sonra üçüncü taraf betiklerini temizlemek; çoğu sitede birkaç hafta içinde ölçülebilir kazanç verir. Kalıcı sonuç için hızı tek seferlik bir proje değil, yayına alma sürecinin bir kontrol maddesi haline getirmek gerekir.