Sık yaşanan bir sahne: geliştirici Lighthouse skorunu gösteriyor, 95. Aynı hafta müşteri hizmetlerine "siteniz çok yavaş" mesajları geliyor. İkisi de doğru olabilir, çünkü ikisi aynı şeyi ölçmüyor.
Lighthouse bir laboratuvar testi. Belirli bir cihaz profili, belirli bir bağlantı hızı, tek bir sayfa yüklemesi. Gerçek kullanıcılarınız ise farklı telefonlarda, farklı şebekelerde, tarayıcı eklentileriyle ve çoğu zaman zayıf sinyalle geziyor.
Lab ve saha
Google'ın sıralamada kullandığı veri, lab skoru değil saha verisi. Yani Chrome kullanıcılarından toplanan gerçek ölçümler. Bu veriye Search Console'daki Core Web Vitals raporundan ve PageSpeed Insights'ın üst bölümünden ulaşabiliyorsunuz.
Pratik kural: lab testi bir teşhis aracı, saha verisi ise karne. Neyin bozuk olduğunu lab gösteriyor, ne kadar önemli olduğunu saha söylüyor.
LCP gerçekte neyi ölçüyor
LCP, ekranda görünen en büyük içeriğin ne zaman boyandığını ölçüyor. Genelde bu bir kapak görseli veya büyük bir başlık oluyor.
Kötü LCP'nin dört klasik sebebi var: sunucunun geç yanıt vermesi, kritik CSS'in geç gelmesi, görselin geç keşfedilmesi ve görselin gereğinden ağır olması.
En sık gördüğümüz hata, kapak görselinin JavaScript ile sonradan yüklenmesi. Tarayıcı o görseli baştan göremiyor, dolayısıyla indirmeye geç başlıyor.
INP: yeni ve acımasız
INP, kullanıcının bir şeye dokunduktan sonra ekranın yanıt vermesine kadar geçen süreyi ölçüyor. Eski FID metriğinden daha katı, çünkü sadece ilk etkileşimi değil, sayfa boyunca yaşanan tüm etkileşimleri değerlendiriyor.
Kötü INP'nin ana sebebi ağır JavaScript. Menü açılırken, filtre uygulanırken veya sepete eklenirken tarayıcı meşgulse dokunuş boşa gidiyor, kullanıcı da ikinci kez basıyor.
E-ticarette bunun bedeli doğrudan dönüşüm oluyor: iki kez basılan buton, iki sipariş veya terk edilmiş sepet demek.
Mobilde ne değişiyor
Masaüstünde iyi olan bir site mobilde çökebiliyor, çünkü telefon işlemcisi aynı JavaScript'i çok daha yavaş çalıştırıyor. Ayrıca ekran küçük olduğu için LCP öğesi değişiyor; masaüstünde küçük kalan bir görsel mobilde ekranı kaplıyor.
Bu yüzden hız çalışmasını mobil üzerinden yürütüyoruz. Mobil düzelince masaüstü zaten düzeliyor, tersi doğru değil.
Nereden başlanır
Sıra önemli, çünkü yanlış yerden başlayan çalışma çok emek harcayıp sonucu değiştirmiyor.
- Görseller. Doğru boyut, modern format, kapak görseline öncelik. Çoğu sitede tek başına en büyük kazanç burada.
- Fontlar. Font yüklenene kadar metnin görünmez kalması LCP'yi doğrudan geciktiriyor.
- Üçüncü parti scriptler. Chat widget, ısı haritası, üç ayrı analytics. Her biri ayrı ayrı masum, toplamı sayfayı boğuyor.
- Sunucu yanıt süresi. Önbellek ve barındırma tarafı; bu adım genelde yazılım ekibinin işi.
- JavaScript miktarı. Kullanılmayan kodun ayıklanması, INP'nin asıl ilacı.
Hız ile dönüşüm arasındaki bağ
Hız çalışmasını yalnızca SEO işi olarak görmek eksik. Yavaş sayfa iki yerden vuruyor: arama tarafında sıralama sinyali olarak, kullanıcı tarafında ise doğrudan terk olarak.
Özellikle mobilde, ödeme adımında yaşanan gecikme sepetin terk edilmesiyle sonuçlanıyor. Bu yüzden hız ölçümünü dönüşüm hunisiyle birlikte okuyoruz: hangi adımda gecikme var, o adımda kaç kişi düşüyor.
Bir sayfanın hızlanması gerekiyorsa öncelik sırası ticaret mantığına göre kurulmalı: önce ürün ve sepet sayfaları, sonra kategori, en son kurumsal sayfalar.
Görsellerde pratik kurallar
Görseller çoğu sitede sorunun merkezinde olduğu için dört kural işi büyük ölçüde çözüyor:
- Görseli ekranda kaplayacağı boyutta sunun; 3000 piksel genişliğindeki dosyayı 600 piksellik alana koymayın
- Modern format kullanın, dosya boyutu belirgin biçimde düşüyor
- Kapak görseline öncelik verin, lazy loading'i ona uygulamayın
- Farklı ekran boyutları için farklı sürüm sunun
Bu dördü uygulandığında çoğu sitede LCP tek başına toparlanıyor, üstelik tek satır JavaScript değiştirmeden.
Ölçüm düzeni
Tek seferlik test yeterli değil, çünkü saha verisi 28 günlük pencerede birikiyor. Düzen şöyle kuruluyor: Search Console'daki Core Web Vitals raporu haftalık kontrol ediliyor, önemli değişikliklerden sonra lab testiyle doğrulama yapılıyor, gerçek kullanıcı ölçümü açıksa dönüşümle birlikte okunuyor.
Hız çalışmasının sonucunu tek bir skorla değil, saha verisindeki "iyi" sayfa oranıyla takip etmek daha doğru.
Üçüncü parti scriptleri budamak
Sitedeki script listesi zamanla kimsenin bakmadığı bir çöplüğe dönüşüyor. Yıllar önce denenmiş bir ısı haritası, artık kullanılmayan bir chat aracı, iki ayrı analytics kurulumu.
Budama şöyle yapılıyor: önce tüm scriptler listeleniyor, her birinin yanına o aracı kimin kullandığı yazılıyor. Sahibi olmayan script siliniyor. Kalanlardan kritik olmayanlar geciktirilerek yükleniyor, yani sayfa kullanılabilir hale geldikten sonra devreye giriyor.
Bu tek çalışma, çoğu sitede INP tarafında en hızlı kazancı veriyor ve tasarıma hiç dokunmuyor.
Sık yapılan hatalar
- Skoru yükseltmek için ölçülen sayfayı optimize edip diğer şablonları unutmak
- Lazy loading'i kapak görseline de uygulamak; o görsel hemen yüklenmeli
- Test ortamında ölçüp canlıdaki farkı görmemek
- Tek seferde her şeyi değiştirip neyin işe yaradığını bilememek
Hız bir defa yapılıp bitirilen iş değil. Yeni bir kampanya sayfası, yeni bir script veya büyük bir görsel her şeyi geri alabiliyor. Bu yüzden ölçümü düzene bağlamak, tek seferlik optimizasyondan daha değerli.