Yavaş Web Siteleri Neden Potansiyel Müşteri Kaybettirir?

Performans genellikle bir puan olarak konuşulur. Bir araç çalıştırılır, bir sayı çıkar, sayı yeşilse konu kapanır.

Bu yaklaşım performansın en az ilginç tarafını ölçer. Yavaş bir site yalnızca bir metrikte kötü değildir; ziyaretçinin işini bitirmesini zorlaştırır, ürünün kalitesi hakkında sessiz bir mesaj verir ve çoğu zaman kimsenin şikâyet etmediği bir yerde müşteri kaybettirir.

Kimse "siteniz yavaştı" diye e-posta yazmaz. Sadece geri dönmez.

Gerçek hız ile algılanan hız aynı şey değil

Bir sayfanın yüklenme süresi ile hızlı hissettirmesi farklı şeylerdir. İkincisi çoğu zaman daha belirleyicidir.

Ziyaretçi bir bekleme süresini değil, belirsizliği zor bulur. Boş beyaz bir ekranda geçen üç saniye, içeriğin kademeli olarak belirdiği üç saniyeden çok daha uzun hissettirir. Aynı şekilde, tıklandığında hemen tepki veren bir buton — işlem arkada devam etse bile — tepkisiz bir butondan daha hızlı algılanır.

Bu, gerçek hızın önemsiz olduğu anlamına gelmez. Daha çok şunu söyler: iyileştirme yalnızca toplam süreyi kısaltmak değil, bekleme sırasında ne olduğunu yönetmektir.

Ağırlık genellikle üç yerden gelir

Bir sayfayı yavaşlatan şeyler çoğunlukla sürpriz değildir.

Görseller en sık karşılaşılan sebeptir. Bir görselin ekranda kapladığı alan ile dosyanın gerçek boyutu ilişkili olmak zorunda değildir. Telefonda 400 piksel genişliğinde görünen bir görsel için 2000 piksellik bir dosya indiriliyor olabilir. Doğru boyutlandırma ve modern bir format, çoğu zaman tasarımdan hiçbir şey feda etmeden büyük fark yaratır.

Fontlar daha sessiz bir maliyettir. Her ek ağırlık ve her ek stil ayrı bir dosyadır. Üç aileden yedi ağırlık yüklemek, tipografiyi zenginleştirmez; yalnızca ilk görüntülemeyi geciktirir.

JavaScript ise en pahalısıdır, çünkü yalnızca indirilmez — ayrıştırılır ve çalıştırılır. Tek bir küçük etkileşim için eklenen büyük bir kütüphane, o etkileşimden çok daha fazlasına mal olur.

Herkesin cihazı sizinki gibi değil

Bir site, geliştirildiği makinede neredeyse her zaman hızlıdır. İyi bir işlemci, hızlı bir bağlantı ve sıcak bir önbellek, performans sorunlarının çoğunu görünmez kılar.

Gerçek kullanıcı koşulları bundan farklıdır: birkaç yıllık bir telefon, değişken bir mobil bağlantı, arka planda çalışan başka uygulamalar, ilk ziyaret ve boş önbellek.

JavaScript'in maliyeti bu farkı en net gösteren yerdir. Aynı script, güçlü bir makinede fark edilmezken düşük güçlü bir cihazda arayüzü gözle görülür biçimde geciktirebilir. Bu nedenle "bende hızlı açılıyor" cümlesi bir ölçüm değildir.

Kayan düzenler ve geç tepki veren arayüzler

Yükleme süresi kabul edilebilir olsa bile, sayfa hâlâ kötü hissettirebilir.

Bunun iki yaygın biçimi vardır. Birincisi, içeriğin yerleşirken kaymasıdır: kullanıcı bir bağlantıya uzanır, geç gelen bir görsel yer kaplar ve düzen aşağı kayar; tıklama yanlış yere gider. Bu, çoğunlukla görsele veya reklam alanına önceden yer ayrılmamasından kaynaklanır ve tasarım aşamasında çözülebilir.

İkincisi, arayüzün geç tepki vermesidir. Sayfa görünür durumdadır ama tıklamalar bir süre karşılıksız kalır, çünkü ana iş parçacığı hâlâ meşguldür. Kullanıcı için bu, "yüklenmedi"den daha sinir bozucudur: görünüşe göre hazır olan bir şey cevap vermiyordur.

Core Web Vitals'ı jargonsuz okumak

Google'ın kullandığı ölçütler karmaşık isimler taşır ama sordukları soru sadedir.

LCP ana içeriğin ne zaman göründüğünü sorar — yani ziyaretçi geldiği şeyi ne zaman görüyor. CLS düzenin yerleşirken ne kadar kaydığını sorar. INP ise arayüzün etkileşimlere ne kadar geç yanıt verdiğini sorar.

Bu ölçütlerin sayısal eşikleri zaman içinde değişebilir ve tanımları güncellenebilir; bu yüzden burada eşik yazmıyoruz. Bir eşik gerekiyorsa doğru kaynak, ölçümün yapıldığı gün Google'ın kendi güncel dokümantasyonudur.

Kavram olarak akılda tutulacak şey daha kalıcıdır: ne zaman göründü, yerinde durdu mu, dokununca cevap verdi mi.

Performans tasarımın rakibi değil

Performans tartışmalarının çoğu şu noktada tıkanır: "hızlandıralım" önerisi, "o zaman sade yapalım" önerisine dönüşür.

Bu gereksiz bir teslimiyettir. Bir sayfayı yavaşlatan şey genellikle tasarımın iddiası değil, uygulama biçimidir. Aynı görsel etki çoğu zaman daha ucuz bir yolla elde edilebilir: bir animasyon layout yerine transform ile çalıştırılabilir, bir efekt görsel yerine CSS ile üretilebilir, ağır bir bileşen yalnızca gerçekten görünür olduğunda yüklenebilir.

Sağlıklı yaklaşım, performansı en sonda ölçülen bir sınav değil, tasarım kararlarının bir parametresi olarak görmektir. Bunu web uygulaması çalışmalarımızda baştan böyle ele alıyoruz.

Yayın öncesi

Aşağıdaki liste, bir siteyi yayına almadan önce performans açısından gözden geçirmek için kullanılabilir.

Performans, tek seferde çözülen bir görev değildir. Her yeni bölüm, her yeni script ve her yeni görsel bütçeden bir şey alır.

En işe yarayan alışkanlık, hızı sonda ölçülen bir not olarak değil, her kararın yanında duran sessiz bir soru olarak tutmaktır: bunun bedeli ne ve kim ödüyor?