Web sitesi hızı nasıl artırılır? Core Web Vitals'ı anlamak

Önce en sık sorulan soruya cevap verelim: PageSpeed Insights'ta 100 almak bir hedef değildir. Google'ın sıralamada baktığı şey o renkli puan değil, gerçek ziyaretçilerin tarayıcısından toplanan saha verisidir. İki site aynı puanı alıp sahada tamamen farklı davranabilir.

O yüzden hız işine puandan değil, metriklerden başlayalım.

Core Web Vitals hangi üç şeyi ölçüyor?

Üçü farklı dertleri anlatıyor ve çözümleri de farklı.

LCP genelde bir fotoğraftır. Ana sayfanızdaki büyük görsel ne zaman görünüyorsa, LCP odur. Yavaşsa sebebi ya dosyanın büyüklüğü ya sunucunun geç cevap vermesidir.

INP butona bastıktan sonra sayfanın donup donmadığını ölçer. Mart 2024'te FID'nin yerini aldı ve daha zorlu bir ölçüt çünkü tek bir ilk etkileşimi değil, ziyaret boyunca yaşanan tüm etkileşimleri değerlendiriyor. Kötü INP'nin sebebi neredeyse her zaman fazla JavaScript'tir.

CLS herkesin yaşadığı ama adını bilmediği sorundur: okumaya başladığınız metin, üstünde geç yüklenen bir reklam ya da görsel yüzünden aşağı kayar ve yanlış yere basarsınız. Çözümü basittir ve çoğu sitede atlanır: görsellere ve reklam alanlarına boyut vermek.

PageSpeed skoru neden yanıltıcı olabiliyor?

Burada somut bir örnek verelim, çünkü bu konu kafa karıştırıyor.

Kendi sitemizi hazırlarken ölçüm yaptık. Gerçek ağ kısıtlamasıyla (yavaş 4G benzetimi değil, tarayıcıya dayatılmış gerçek kısıtlama) LCP 1,57 ile 1,65 saniye arasında çıktı, CLS 0,000 ölçüldü, masaüstünde LCP 0,55 saniyeye indi. Aynı sitede Lighthouse'un varsayılan yöntemi 2,6 ile 2,8 saniye gösteriyordu.

Fark nereden geliyor? Lighthouse'un varsayılan ölçümü ağı taklit ederek tahmin yürütür ve gözlenen boyama anından önce tamamlanan her isteği, o boyamanın önkoşulu kabul eder. Gerçek kısıtlamada ise LCP, ilk boyama anıyla aynı noktada gerçekleşiyordu; yani render gecikmesi sıfırdı.

Buradan çıkan pratik kural: laboratuvar testi bir teşhis aracıdır, karne değildir. Karne, Search Console'daki Core Web Vitals raporudur. Orada yeterli veri yoksa Chrome'un kullanıcı deneyimi raporuna (CrUX) bakılır.

Yavaşlığın kaynağı nasıl bulunur?

Tahminle müdahale etmek zaman kaybı. Sıra şöyle işliyor:

1. Sunucu ne kadarda cevap veriyor? Tarayıcının geliştirici araçlarındaki Ağ sekmesinde ilk belgenin yanıt süresine bakın. Bu süre yarım saniyeyi aşıyorsa sorun sayfada değil, sunucuda ya da veritabanındadır. Görsel sıkıştırmakla düzelmez.

2. En büyük öğe hangisi? Ağ sekmesini boyuta göre sıralayın. Listenin tepesinde genelde bir fotoğraf ya da bir yazı tipi dosyası durur.

3. Kaç istek yapılıyor? Dışarıdan yüklenen her betik ayrı bir bağlantı açar. Analitik, canlı destek, harita, yazı tipi sağlayıcısı, sosyal medya gömüsü, reklam pikseli. Bunların toplamı çoğu sitede kendi kodundan ağır basar.

4. JavaScript ne kadar? Performans sekmesindeki ana iş parçacığı görünümü, tarayıcı ne zaman meşgul olduğunu gösterir. INP sorunları burada teşhis edilir.

Hangi müdahale ne kadar iş görüyor?

Sırayı önem ve maliyet dengesine göre veriyoruz.

Görselleri düzeltin. Neredeyse her sitede en büyük kazanç buradan gelir. Görseli kullanılacağı boyuta küçültmek, WebP veya AVIF biçimine çevirmek ve ekranın altında kalanları geciktirmeli yüklemek. Bir uyarı: LCP öğesi olan ana görseli geciktirmeli yüklemeyin, tam tersi etki yapar.

Yazı tiplerini sadeleştirin. Beş ağırlık yerine iki ağırlık yükleyin, dosyaları kendi sunucunuzdan servis edin ve font-display ayarıyla metnin yazı tipi gelene kadar görünür kalmasını sağlayın. Yoksa metin birkaç yüz milisaniye boyunca görünmez olur.

Gereksiz eklentileri kaldırın. İçerik yönetim sistemi kullanan sitelerde en hızlı kazanç genellikle buradadır. Kullanılmayan her eklenti, her sayfada kendi CSS ve JS dosyasını yüklemeye devam eder.

Önbellek ve CDN. Sayfa önbelleği sunucu yükünü belirgin şekilde düşürür. Ziyaretçi kitleniz coğrafi olarak dağınıksa içerik dağıtım ağı ek fayda verir; tamamı Türkiye'deyse ve sunucunuz zaten yakınsa kazanç sınırlıdır.

Üçüncü taraf betiklerini gözden geçirin. Her birinin sorusu şu: bu ne kadar gelir getiriyor, sayfaya ne kadar milisaniye ekliyor? Yıllardır kimsenin bakmadığı bir ısı haritası aracı bu testi geçemez.

Boyut verin. Görsel, video ve gömülü alanlara genişlik ve yükseklik yazmak CLS'yi çoğu sitede tek hamlede çözer.

Sunucu tarafında ne yapılır?

Uygulama tarafı da hesaba katılmalı, özellikle sayfalar veritabanından besleniyorsa.

Yavaş sorgular en sık görülen sebep. Listeleme sayfalarında her satır için ayrı sorgu çalıştıran kod, on kayıtta fark ettirmez, bin kayıtta siteyi durdurur. İkinci sık sebep, üretim ortamında açık kalmış günlük kaydı ve hata ayıklama modudur.

Barındırma seçiminin bu işteki payını alan adı ve hosting yazımızda ayrıntılandırdık. Özel yazılım tarafındaki yaklaşımımızı ise web yazılım sayfasında bulabilirsiniz.

Hız sıralamayı ne kadar etkiliyor?

Dürüst cevap: doğrudan etkisi sanıldığından küçük. Core Web Vitals bir sıralama sinyalidir ama içerik kalitesiyle aynı ağırlıkta değil. Hızlı ama boş bir sayfa, yavaş ama doğru cevabı veren sayfayı geçmez.

Asıl etkisi dolaylı yoldan geliyor. Açılmayan sayfayı ziyaretçi terk eder, form doldurulmaz, reklam bütçesi boşa gider. Reklam veriyorsanız bu doğrudan paradır: aynı tıklama ücretine daha az talep toplarsınız. SEO ve Google Ads tarafındaki bütçenizin karşılığını almanın ön koşulu, sayfanın açılmasıdır.

Nereden başlamalı?

Bir hafta içinde yapılabilecek sıra şu: Search Console'daki saha verisine bakın, en kötü durumdaki sayfa grubunu seçin, o sayfadaki en büyük üç dosyayı bulun, görselleri küçültüp biçim değiştirin, görsellere boyut verin ve iki hafta sonra veriye tekrar bakın.

Bu kadarı çoğu kurumsal sitede eşiğin altına inmeye yeter. Yetmiyorsa sorun sayfada değil, sunucuda ya da uygulamadadır ve oraya ayrı bakmak gerekir.

Sitenizin mevcut ölçümlerine birlikte bakmamızı isterseniz iletişim sayfasından yazın.