Sayfa hızını iyileştirme kontrol listesi

Sayfa hızı çalışmalarında en çok zaman kaybettiren şey, yanlış sayıya bakmaktır.

Bu rehber önce hangi sayıya bakılacağını netleştiriyor, sonra yedi adımda ne yapılacağını veriyor. Her adımın sonunda ne yapılacağı, kimin sorumlu olduğu ve elinizde ne kalacağı yazıyor.

Başlamadan önce bir ayrımı oturtmak gerekiyor, çünkü bu rehberdeki her karar ona dayanıyor.

Sayfa hızı iki farklı yolla ölçülür ve ikisi aynı şeyi söylemez.

Saha verisi. Sitenizi gerçekten ziyaret eden kullanıcılardan toplanan ölçümdür. Gerçek cihazlarda, gerçek bağlantılarda, gerçek koşullarda ne olduğunu gösterir. Search Console'daki Core Web Vitals raporu ve kendi kurduğunuz gerçek kullanıcı ölçümü bu gruba girer.

Laboratuvar verisi. Kontrollü bir ortamda, simüle edilmiş cihaz ve yapay olarak kısıtlanmış bağlantıyla üretilen çıktıdır. Lighthouse ve benzeri araçların verdiği değerler buradan gelir.

Kritik nokta şu: laboratuvar aracının verdiği LCP değeri, çoğu durumda ölçülmüş bir boyama süresi değil, uygulanan kısıtlama altında hesaplanmış bir tahmindir. Aynı sayfada aracın söylediği süre ile gerçek ölçümün söylediği süre arasında birkaç katlık fark çıkabilir.

Bu yüzden iki cümleyi asla birbirinin yerine kullanmayın:

• "Araç bu sayfa için şu değeri veriyor." — bir araç çıktısıdır.
• "Bu sayfa kullanıcıda şu sürede boyanıyor." — bir ölçüm iddiasıdır.

Raporlarınızda hangisini yazdığınız belli olsun. Karışan bu iki cümle yüzünden ekipler aylarca gerçekte var olmayan bir sorunu çözmeye çalışıyor.

Karar saha verisiyle verilir. Bakılacak üç gösterge ve iyi kabul edilen eşikleri şunlar:

• LCP — sayfanın en büyük içerik parçasının görünür olma süresi: 2,5 saniyenin altında.
• INP — kullanıcının etkileşimine sayfanın verdiği yanıt süresi: 200 milisaniyenin altında.
• CLS — sayfa yüklenirken öğelerin yer değiştirme miktarı: 0,1'in altında.

Bu eşikler tek bir ziyaret için değil, 28 günlük dönemde ziyaretlerin yüzde 75'i için sağlanmalıdır. Yani ortalamaya değil, kullanıcıların dörtte üçünün yaşadığı deneyime bakılır.

İyi ile kötü arasında bir orta bant da var; oradaki değerler "iyileştirme gerekiyor" sayılır. Bu rehberde orta bandın üst sınırlarını yazmıyorum, çünkü karar için gereken şey iyi eşiğidir.

Çıktı: Üç gösterge için sitenizin bugünkü saha değerleri.

Ne yapılır: Önce elinizde saha verisi olduğundan emin olun. Search Console'daki Core Web Vitals raporu başlangıç için yeterlidir ve ek kurulum gerektirmez.

Raporu okurken iki şeye dikkat edin. Birincisi: değerler sayfa bazında değil, benzer sayfaların gruplandığı kümeler halinde gelir. İkincisi: yeni yayınlanmış bir sayfa için veri birikmesi zaman alır; sıfır satır görmek başarısızlık değil, yeterli trafik olmaması olabilir.

Trafiği düşük siteler için saha verisi hiç birikmeyebilir. Bu durumda laboratuvar aracı tek elinizdeki şey olur — ama o zaman da çıktıyı "ölçülmüş süre" diye raporlamayın.

Kim sorumlu: Teknik muhatap.

Çıktı: Üç göstergenin sayfa grubu bazında bugünkü durumu.

Kurumsal sitelerde en sık karşılaşılan LCP suçlusu, sayfanın en üstündeki büyük görseldir.

Ne yapılır:

• Ana görselin boyutunu gerçekten görüntülendiği ölçüye indirin. Ekranda 800 piksel genişliğinde görünen bir görselin 4000 piksel olarak yüklenmesi yaygın bir durumdur.
• Modern görsel biçimlerini kullanın; aynı görsel kalitesi belirgin biçimde daha küçük dosyayla sağlanabiliyor.
• Ekranın altında kalan görselleri geciktirerek yükleyin — ama ilk ekrandaki görseli geciktirmeyin, o LCP'nin kendisidir.
• Görsel için yer ayırın; boyutu belirtilmemiş görsel yüklendiğinde altındaki içeriği aşağı iter ve bu doğrudan CLS üretir.

Kim sorumlu: Tasarım ve geliştirme birlikte.

Çıktı: İlk ekrandaki görsellerin boyut ve biçim denetimi.

Web fontları küçük dosyalardır ama yanlış yüklendiklerinde metnin görünmesini geciktirirler.

Ne yapılır: Font yüklenene kadar metnin görünmez kalması yerine, yedek bir yazı tipiyle hemen görünmesini sağlayın. Font geldiğinde değişim olur; bu değişim de düzen kaymasına yol açmasın diye yedek font, asıl fontla benzer ölçülerde seçilir.

Kullanılmayan font ağırlıklarını da çıkarın. Tasarımda üç ağırlık kullanılıyorsa yedi ağırlık yüklemenin karşılığı yoktur.

Kim sorumlu: Geliştirme; ağırlık kararı tasarımda.

Çıktı: Yüklenen font dosyalarının listesi ve her birinin gerekçesi.

Yıllar içinde biriken analitik, sohbet, ısı haritası, reklam ve test araçları çoğu kurumsal sitede en büyük ikinci yüktür.

Ne yapılır: Sayfada çalışan tüm üçüncü taraf betiklerini listeleyin ve her biri için tek bir soru sorun: bunu kim, en son ne zaman kullandı?

Cevabı olmayanları kaldırın. Cevabı olanları geciktirerek yükleyin; çoğu araç sayfanın çizilmesini beklemek zorunda değildir.

Bu adım genellikle en hızlı kazancı verir çünkü kod değişikliği değil, silme işidir.

Kim sorumlu: Pazarlama ve teknik muhatap birlikte — liste pazarlamada, uygulama teknikte.

Çıktı: Üçüncü taraf envanteri, kaldırılanlar ve geciktirilenler.

CLS, kullanıcının okuduğu ya da tıklamaya hazırlandığı şeyin ayağının altından kaymasıdır. Ölçüsü teknik ama sonucu tamamen deneyimseldir.

Ne yapılır: Yaygın dört kaynağı tek tek kontrol edin:

• Boyutu belirtilmemiş görsel ve videolar
• Sonradan enjekte edilen reklam, banner ya da duyuru çubukları
• Geç gelen font nedeniyle metin ölçüsünün değişmesi
• İçerik yüklendikçe genişleyen bileşenler

Çözüm hepsinde aynı: gelecek olan şey için yeri baştan ayırın.

Kim sorumlu: Geliştirme.

Çıktı: Kayma üreten bileşenlerin listesi ve ayrılan alanların doğrulanması.

INP, kullanıcı bir şeye dokunduğunda sayfanın ne kadar sürede karşılık verdiğini ölçer. Yavaşlığın sebebi genellikle ağ değil, tarayıcının o anda başka bir işle meşgul olmasıdır.

Ne yapılır: Sayfa açılışında çalışan işleri azaltın. Kullanıcı henüz aşağı inmemişken hesaplanan şeyleri, ihtiyaç duyulduğunda hesaplayın. Uzun süren işlemleri parçalara bölün ki tarayıcı arada kullanıcıya cevap verebilsin.

Bu adım diğerlerinden daha teknik ve genellikle geliştirme ekibiyle birlikte çalışmayı gerektirir. İyi haber şu: Adım 4'te betikleri temizlemek bu göstergeyi de doğrudan iyileştirir.

Kim sorumlu: Geliştirme.

Çıktı: Açılışta çalışan işlerin envanteri.

Ne yapılır: Sunucunun ilk yanıt süresine bakın; her şey ondan sonra başlıyor. Yanıt yavaşsa üstteki hiçbir iyileştirme görünür fark yaratmaz.

Statik dosyalar için içerik dağıtım ağı kullanmak, kullanıcıya coğrafi olarak yakın teslim sağlar. Sıkıştırma ve önbellek başlıkları da bu adımda kontrol edilir; ikisi de bir kez doğru kurulduğunda sürekli kazanç verir.

Kim sorumlu: Teknik muhatap ya da barındırma sağlayıcısı.

Çıktı: İlk yanıt süresi ölçümü ve önbellek yapılandırmasının denetimi.

Buraya kadar saha verisinin kararı verdiğini söyledik. Laboratuvar aracı ise değersiz değil — sadece işi başka.

İyi olduğu şey: neden yavaş olduğunu göstermek. Hangi dosya ne zaman yükleniyor, hangi işlem ne kadar sürüyor, hangi görsel ne kadar büyük. Bir değişikliğin etkisini yayına almadan önce karşılaştırmak için de kullanışlıdır.

İyi olmadığı şey: ne kadar yavaş olduğunu söylemek. O sayı sizin kullanıcılarınızın deneyimi değildir.

Pratik kullanım şu: saha verisi hangi sayfa grubunun sorunlu olduğunu söyler, laboratuvar aracı o sayfada neyin yavaşlattığını gösterir. Sıra bu; tersi değil.

Puan kovalamak. Bileşik puan neyi düzelttiğinizi gizler. Tek tek göstergelere bakın; puan zaten onların sonucudur.

Tek bir ölçümle karar vermek. Laboratuvar aracı aynı sayfada arka arkaya farklı sonuçlar verebilir. Tek koşunun sonucunu rapora yazmayın.

Ana sayfaya bakıp bitirmek. Ana sayfa genellikle en çok optimize edilmiş sayfadır. Sorun çoğunlukla ürün, kategori ve blog şablonlarındadır; oralarda bir düzeltme yüzlerce sayfayı birden etkiler.

Sırayla üç şey:

1. Saha verisini açın. Search Console'daki rapordan üç göstergenin bugünkü durumunu alın ve kaydedin. Bu başlangıç çizginiz olacak.
2. Üçüncü taraf betiklerini listeleyin. Genellikle en hızlı kazanç burada ve kod değişikliği gerektirmiyor.
3. En çok trafik alan şablonu seçin. Tek sayfa değil şablon — düzeltme tüm sayfalara yayılsın.

Hızın kullanılabilirlikle ilişkisini kullanılabilirlik yazımızda, arama görünürlüğüyle ilişkisini Google'da sıralama yazımızda, stil katmanının hıza etkisini ise CSS yazımızda ele aldık. Projenin hangi aşamasında ne yapılacağı kurumsal web sitesi rehberimizde duruyor.