Site Hızı Neden Satışı Etkiler? Yavaşlığın Görünmeyen Maliyeti

Bekleme süresi kararı değiştirir

Bir sayfayı açıp beklerken insanın aklından geçen şey teknik bir değerlendirme değildir. Önce sabırsızlık, ardından şüphe gelir: acaba bağlantım mı kötü, yoksa bu site mi bozuk? Şüphe oluştuğu anda kullanıcı geri tuşuna basar ve bir sonraki sonuca geçer. Burada kaybedilen şey yalnızca bir ziyaret değil, o kişiye anlatabileceğiniz her şeydir. En iyi hizmet anlatımı, en güçlü örnek iş, en doğru fiyat kurgusu; hiçbiri okunmadan kaybolur. Yavaşlığın maliyeti bu yüzden görünmez, çünkü kaybedilen müşteri hiçbir raporda iz bırakmaz. Kimse size sitenizin yavaş olduğu için vazgeçtiğini söylemez. Bu yüzden hız problemi genellikle şikayetle değil, sessiz bir düşüşle kendini gösterir.

Etki sadece ilk açılışla da sınırlı değildir. Sayfa açıldıktan sonra tıklanan bir menü hemen tepki vermiyorsa kullanıcı butonun çalışmadığını düşünüp tekrar tıklar. Form gönder butonuna basıldığında ekran bir süre kıpırdamıyorsa kişi ikinci kez basar ve bazen aynı talep iki kez düşer, bazen de kullanıcı sayfayı tamamen kapatır. Sepete ekleme, filtre değiştirme, tarih seçme gibi işlemlerde de aynı şey yaşanır. Bunların hepsi güven kaybı üretir. Hızlı bir site sadece kısa sürede açılan site değil, dokunulduğunda tepki veren sitedir. İkisi farklı problemlerdir, farklı sebeplerden kaynaklanır ve farklı çözümleri vardır. Bir sayfa hızlı açılıp yavaş tepki verebilir; tersi de mümkündür ve ikisini ayrı ayrı ölçmek gerekir.

Bir de arama tarafı var. Sayfa deneyimiyle ilgili ölçütler sıralamada tek başına belirleyici değildir; içerik kalitesi ve konuya uygunluk çok daha ağır basar. Ancak birbirine yakın iki sayfa arasında fark yaratabilir ve bu fark özellikle mobil sonuçlarda hissedilir. Daha önemlisi, yavaş sayfalar reklamla getirilen ziyaretçide doğrudan para kaybettirir; tıklama başına ödeme yaptığınız bir ziyaretçinin sayfa açılmadan gitmesi, harcamanın karşılıksız kalması demektir. Yani hız, arama motoru için değil önce bütçe için önemlidir. Reklam veren bir işletmede yapılacak ilk iş, açılış sayfasının gerçek bir telefonda ne kadar sürede açıldığını ölçmektir. Reklam bütçesini artırmadan önce bu ölçümü yapmak, çoğu zaman aynı parayla daha fazla sonuç almayı sağlar.

LCP: en büyük parça ne zaman görünüyor

LCP, sayfadaki en büyük görünür parçanın ekrana gelme süresini ölçer. Bu parça genellikle üstteki büyük görsel, bir video kapak resmi ya da başlık bloğudur. Kullanıcı açısından anlamı basittir: sayfa ne zaman gerçekten bir şey göstermeye başladı? Bir sayfanın teknik olarak yüklenmiş olması, kullanıcının bir şey görmesi anlamına gelmez; ekran boş dururken arka planda ne yapıldığı kimseyi ilgilendirmez. Yaygın olarak kabul edilen ölçüt, bu sürenin iki buçuk saniyenin altında kalmasıdır. Dört saniyeyi aşan değerler ise belirgin biçimde kötü sayılır ve bu aralıkta sayfayı terk etme davranışı hızla artar. Bu ölçütü iyileştirmenin en doğrudan yolu, üstteki büyük parçayı hafifletmek ve yükleme sırasında ona öncelik vermektir.

LCP değerini bozan şeyler genellikle tahmin edilebilir. Sayfanın en üstündeki görselin çok büyük bir dosya olması en yaygın sebeptir. İkinci sebep, o görselin geç yüklenecek şekilde işaretlenmesidir; ekranın altındaki görseller için doğru olan bu ayar, en üstteki görsel için tam tersi sonuç verir ve sayfayı bekletir. Üçüncü sebep, sayfanın çizilmesini bekleten bir yazı tipi ya da stil dosyasıdır. Dördüncüsü ise sunucunun ilk cevabı geç vermesidir; içerik daha yola çıkmadan zaman kaybedilmiştir. Bu dört başlık sırayla incelendiğinde çoğu sitede sorunun kaynağı ilk denemede bulunur. Çözüm genellikle saatler değil dakikalar sürer; asıl zaman teşhis aşamasında harcanır.

INP: tıklayınca ne kadar sürede cevap veriyor

INP, kullanıcının yaptığı etkileşimlere sayfanın ne kadar sürede görünür bir cevap verdiğini ölçer. Menüye tıklamak, bir açılır listeyi genişletmek, formda bir kutuya yazmak, sekme değiştirmek gibi işlemler buna dahildir. Ölçülen şey işlemin tamamlanma süresi değil, ekranda bir değişikliğin görünmeye başlama süresidir; kullanıcı bir şeyin olduğunu görmek ister, bitmesini beklemeye razıdır. Genel kabul gören eşik iki yüz milisaniyenin altıdır. Beş yüz milisaniyeyi aşan değerlerde kullanıcı gecikmeyi açıkça hisseder, arayüzü bozuk sanmaya başlar ve aynı yere tekrar tekrar basar. Bu tekrar eden dokunuşlar çoğu zaman yeni işlemler başlattığı için sayfa daha da yavaşlar ve durum kartopu gibi büyür.

Bu ölçüt neredeyse tamamen tarayıcıda çalışan kodla ilgilidir. Sayfa açıldığında arka planda çalışan çok sayıda betik ana iş parçacığını meşgul eder ve kullanıcının dokunuşuna cevap verilecek an gecikir. Sohbet kutuları, ısı haritası araçları, birden fazla ölçüm kodu, sosyal medya gömüleri ve büyük arayüz kütüphaneleri bu yükün en sık kaynaklarıdır. Çözüm genellikle hepsini silmek değil, önceliklendirmektir: kritik olmayan kodları sayfa yerleştikten sonra yüklemek, gerçekten kullanılmayan araçları tamamen kaldırmak, büyük dosyaları parçalara bölmek ve uzun süren işlemleri küçük adımlara ayırmak. Bu düzenlemeler görünmez ama hissedilir. Bir butona basıldığında hemen küçük bir tepki göstermek, işlem arkada devam etse bile beklemeyi katlanılır hale getirir.

CLS: sayfa okurken neden zıplıyor

CLS, sayfa yüklenirken içeriğin ne kadar kaydığını ölçer. Herkesin başına gelmiştir: bir yazıyı okumaya başlarsınız, üstte bir görsel yüklenir ve metin aşağı kayar; ya da tam butona basacakken sayfa oynar ve yanlış yere tıklarsınız. Bu, teknik bir hatadan çok bir nezaket meselesidir ve kullanıcıda sitenin özensiz olduğu izlenimini bırakır. Kabul edilen ölçüt sıfır virgül birin altındadır. Değerin yüksek olması, sinir bozucu olmasının yanında yanlış tıklamalar üzerinden gerçek kayıplar da doğurur; özellikle mobilde yanlışlıkla açılan bir bağlantı kullanıcıyı sayfadan tamamen çıkarabilir. Alışverişin ya da form doldurmanın ortasında yaşanan böyle bir kayma, çoğu zaman işlemin hiç tamamlanmamasıyla sonuçlanır.

Kayma genellikle boyutu önceden belirtilmemiş öğelerden kaynaklanır. Görselin genişlik ve yükseklik bilgisi verilmemişse tarayıcı ona yer ayıramaz ve dosya geldiğinde alanı zorla açar. Aynı durum reklam alanları, gömülü haritalar, sonradan görünen bildirim çubukları ve çerez uyarıları için de geçerlidir. Yazı tipinin geç yüklenip harflerin birden değişmesi ve satırların kayması da aynı sonucu doğurur. Çözüm aslında basittir: her öğe için baştan yer ayırmak, sabit yükseklik tanımlamak ve sonradan görünecek unsurları içeriği aşağı itmeyecek biçimde yerleştirmek. Bu, sonradan yapılan optimizasyonlardan çok daha ucuz bir önlemdir. Tasarım aşamasında her bileşen için sabit bir alan düşünmek, sonradan yapılacak bütün bu düzeltmeleri gereksiz kılar.

Yavaşlığın birinci sebebi: görseller

Bir sayfanın toplam ağırlığının büyük kısmı çoğu zaman görsellerden gelir. Fotoğraf makinesinden ya da telefondan çıkan bir dosya, ekranda gösterilecek boyutun kat kat üstünde olabilir. Tarayıcı bu dosyayı önce baştan sona indirir, sonra küçültüp gösterir; yani kullanıcı hiç görmediği piksellerin bedelini öder ve bunun için bekler. Çözümün ilk adımı, görseli kullanılacağı en büyük boyuta göre yeniden boyutlandırmaktır. Bu tek işlem bile çoğu sitede hissedilir bir fark yaratır, hiçbir teknik altyapı değişikliği gerektirmez ve içeriği yöneten kişi tarafından da yapılabilir. Yükleme alışkanlığını değiştirmek burada kalıcı çözümdür. İçerik yükleyen kişiye tek bir üst sınır vermek, aylar sonra ortaya çıkacak sorunları baştan önler.

İkinci adım biçim seçimidir. Modern görüntü biçimleri, aynı görsel kaliteyi belirgin biçimde daha küçük dosyayla verir. Fotoğraflar için bu biçimler tercih edilmeli, çizim, logo ve simge gibi öğeler içinse vektör biçimi kullanılmalıdır; vektör dosyalar boyuttan bağımsız olarak keskin kalır ve genellikle çok küçüktür. Üçüncü adım, ekranın altında kalan görselleri gecikmeli yüklemektir; kullanıcı aşağı inmezse o dosyalar hiç indirilmez ve boşuna veri harcanmaz. Ancak bu ayarı ekranın üst kısmındaki ana görsele uygulamamak gerekir, çünkü orada tam tersi etki doğar ve ilk görüntü gecikir. Kural basittir: ilk ekranda görünen her şey öncelikli, altta kalan her şey ertelenebilir.

Son olarak farklı ekranlara farklı boyut sunmak gerekir. Telefonda açılan bir sayfaya masaüstü için hazırlanmış geniş bir görseli göndermek, mobil bağlantıda ciddi bir yük demektir ve aradaki kalite farkı çoğu zaman fark bile edilmez. Aynı görselin birkaç farklı boyutta hazırlanıp tarayıcıya seçenek olarak sunulması bugün standart bir uygulamadır. Bu düzenlemelerin hiçbiri kullanıcıya görünmez; sadece sayfa daha erken açılır. Görsel tarafını düzeltmeden diğer iyileştirmelere geçmek, genellikle küçük kazançlar için çok emek harcamak anlamına gelir. Bu yüzden hız çalışmasına her zaman buradan başlamak gerekir. Görsel düzeni oturduktan sonra yapılan diğer iyileştirmelerin etkisi de çok daha net ölçülebilir hale gelir.

Eklentiler, betikler ve üçüncü taraf kodlar

Zamanla siteye eklenen her araç bir bedelle gelir. Sohbet penceresi, ziyaretçi kaydı, birden fazla ölçüm kodu, kayan galeri, çerez bildirimi, sosyal paylaşım kutusu, harita gömüsü. Bunların her biri tek başına küçük görünür ama toplamı sayfayı taşınamaz hale getirir. Üstelik bu kodlar genellikle başka sunuculardan gelir; o sunucu yavaşladığında sizin siteniz de yavaşlar ve kontrol tamamen dışınızdadır. Yılda bir kez kullanılan araçların listesini çıkarıp gerçekten işe yarayanları ayıklamak, en az emekle en çok kazanç sağlayan işlerden biridir. Kimsenin bakmadığı bir ölçüm aracını taşımanın hiçbir anlamı yoktur. Aynı şekilde deneme amacıyla eklenip unutulmuş kodlar, yıllarca her sayfada sessizce çalışmaya devam eder.

Hazır sistemlerde eklenti yığılması ayrı bir problemdir. Tek bir küçük özellik için kurulan eklenti, sitenin her sayfasına kendi kod ve stil dosyalarını ekleyebilir. On eklenti kurulu bir sitede, ana sayfada hiç kullanılmayan onlarca dosya yükleniyor olabilir ve çoğu zaman kimse bunun farkında değildir. Burada yapılacak iş, eklentileri yalnızca gerektikleri sayfada çalıştırmak, aynı işi yapan araçları teke indirmek ve artık kullanılmayanları pasif bırakmak yerine tamamen kaldırmaktır. Bazen tek bir eklentiyi kaldırmak, haftalarca uğraşılacak diğer iyileştirmelerin toplamından daha çok fayda sağlar. Eklenti kurmadan önce aynı işin birkaç satır kodla yapılıp yapılamayacağını sormak, zamanla biriken bu yükü baştan engeller.

Sunucu, barındırma ve önbellek

Sayfanın hızı, tarayıcıya ilk baytın ne zaman ulaştığıyla başlar. Bu süre uzunsa yapılan diğer bütün iyileştirmeler bir tavanla sınırlanır, çünkü içerik henüz yola bile çıkmamıştır. Paylaşımlı ve aşırı yüklü barındırma paketleri, veritabanına gereğinden fazla sorgu atan sayfalar ve her istekte baştan üretilen içerikler bu gecikmenin başlıca sebepleridir. Ziyaretçiye her seferinde aynı içerik gösteriliyorsa, o içeriği bir kez üretip saklamak en doğrudan çözümdür. Barındırma değiştirmeden önce bu tarafı incelemek gerekir; çoğu zaman sorun sunucunun gücünde değil, gereksiz yere tekrarlanan işlerdedir. Aynı sorgunun her sayfa açılışında defalarca çalıştığı durumlar tek bir düzeltmeyle ortadan kalkabilir ve fark hemen görülür.

Önbellek birkaç katmanda çalışır: sunucu tarafında üretilmiş sayfanın saklanması, tarayıcı tarafında değişmeyen dosyaların tekrar indirilmemesi ve dağıtık sunucular üzerinden dosyaların kullanıcıya coğrafi olarak yakın noktadan verilmesi. Üçü birlikte kurulduğunda etkisi büyüktür. Ancak önbellek kurulan yerde bir noktaya dikkat etmek gerekir: dosya güncellendiğinde eski sürümün kullanıcıda kalmaması için dosya adının ya da sürüm işaretinin değişmesi şarttır. Aksi halde yaptığınız değişiklik günlerce görünmeyebilir ve siz sorunun kodda olduğunu sanarak boşuna uğraşırsınız. Bu, hız çalışmalarında en sık karşılaşılan yanıltıcı durumlardan biridir. Değişiklik sonrası kontrolü her zaman gizli pencerede ya da önbelleği temizlenmiş bir tarayıcıda yapmak bu karışıklığı önler.

Bağlantı ve sıkıştırma ayarları da bu başlığa girer. Metin dosyalarının sıkıştırılarak gönderilmesi, güvenli bağlantının doğru yapılandırılması ve gereksiz yönlendirme zincirlerinin temizlenmesi ölçülebilir kazanç sağlar. Özellikle yönlendirme zincirleri sık gözden kaçar; adres yazılırken önce bir sürüme, oradan başka bir sürüme, oradan asıl sayfaya gidiliyorsa her adım ek bekleme demektir ve mobilde bu bekleme katlanarak artar. Zinciri tek adıma indirmek küçük ama kalıcı bir iyileştirmedir. Aynı şekilde artık var olmayan sayfalara giden bağlantıları temizlemek de hem hız hem kullanıcı açısından fayda sağlar. Bu tür bakım işleri yılda bir iki kez yapıldığında toplam süreleri birkaç saati geçmez ama etkileri kalıcı olur.

Yazı tipleri sessiz bir yavaşlatıcıdır

Yazı tipleri genellikle küçük dosyalar olduğu için gözden kaçar, ama etkileri boyutlarıyla orantılı değildir. Çünkü metin, yazı tipi gelene kadar ya hiç görünmez ya da başka bir yazı tipiyle görünüp sonra değişir. Birincisi sayfanın boş kalmasına, ikincisi ise okuma sırasında harflerin ve satırların zıplamasına yol açar. Doğru davranış, sistemdeki bir yedek yazı tipiyle metni hemen göstermek ve asıl dosya geldiğinde geçiş yapmaktır. Bu tek satırlık bir düzenlemedir ama görünür etkisi büyüktür. Yedek yazı tipini asıl yazı tipine yakın genişlikte seçmek, geçiş anındaki kaymayı da en aza indirir. Sistemde hazır bulunan yazı tipleriyle yetinmek de tamamen geçerli bir tercihtir ve hiçbir dosya indirilmediği için bedelsizdir.

İkinci konu, yazı tipini nereden yüklediğinizdir. Dış bir sunucudan çekilen yazı tipleri ek bir bağlantı kurulması demektir ve bu bağlantı bazen beklenenden uzun sürer. Dosyaları kendi sunucunuza koymak hem bu gecikmeyi ortadan kaldırır hem de veri paylaşımı açısından daha temiz bir yapı sunar. Üçüncü konu ise ağırlık sayısıdır; bir sitede üç dört farklı kalınlık genellikle yeterlidir ve her kalınlık ayrı bir dosya olduğu için fazlası doğrudan yük demektir. Kullanılmayan alfabelerin dosyadan çıkarılması da boyutu belirgin biçimde düşürür ve bu işlem yalnızca bir kez yapılır. Türkçe karakterlerin dosyada eksiksiz bulunduğundan emin olmak ise atlanmaması gereken küçük bir kontroldür.

Ölçüm: saha verisi mi laboratuvar verisi mi

Hız ölçümünde iki farklı veri türü vardır ve bunları karıştırmak yanlış kararlara yol açar. Laboratuvar verisi, sayfanın kontrollü bir ortamda, belirlenmiş bir cihaz ve bağlantı hızıyla test edilmesiyle üretilir; tekrarlanabilir olduğu için yapılan değişikliklerin etkisini ölçmeye çok uygundur. Saha verisi ise siteyi gerçekten ziyaret eden kullanıcıların cihazlarından toplanır. Gerçeği yansıtır ama bir değişikliğin etkisini görmek için beklemek gerekir, çünkü veri belirli bir zaman aralığına yayılarak birikir. İkisi aynı sayfayı ölçtüğünde farklı sonuç verebilir; bu bir çelişki değil, tamamen doğal bir durumdur. Kullanıcı cihazlarının gücü, bağlantı kalitesi ve ziyaret edilen sayfalar birbirinden çok farklı olduğu için sonuçlar da farklılaşır.

Doğru kullanım şudur: saha verisi problemi haber verir, laboratuvar verisi sebebini bulmanızı sağlar. Saha verisinde belirli bir ölçüt kötü görünüyorsa, laboratuvar testiyle o sayfayı inceleyip hangi öğenin gecikmeye yol açtığını çıkarırsınız. Değişikliği yaptıktan sonra laboratuvar tarafında etkiyi hemen görürsünüz, ancak saha tarafında sonucun oturması haftalar alır. Bu gecikmeyi bilmemek, yapılan iyileştirmenin işe yaramadığı sanılmasına ve doğru bir düzenlemenin gereksiz yere geri alınmasına yol açar. Bu yüzden hız çalışmalarında sabır, kullanılan araçtan daha önemli bir gereçtir. Yapılan her değişikliği tarihiyle birlikte not almak, haftalar sonra gelen saha verisini doğru yorumlamayı çok kolaylaştırır ve gereksiz geri adımları önler.

Bir de test edilen sayfanın seçimi önemlidir. Yalnızca ana sayfayı ölçmek yanıltıcıdır, çünkü ziyaretçilerin çoğu iç sayfalara gelir. Hizmet sayfaları, blog yazıları, ürün sayfaları ve iletişim sayfası ayrı ayrı ölçülmelidir. Ayrıca test her zaman mobil ayarıyla yapılmalıdır; ofisteki hızlı ağda masaüstü tarayıcıyla yapılan test, gerçek kullanıcının şehir dışında zayıf çeken telefonunda yaşadığını göstermez. Mümkünse gerçek bir telefonla, mobil veriyle ve önbellek temizlenerek denemek en öğretici yöntemdir. Kötü senaryoyu ölçmek, iyi senaryoyu ölçmekten her zaman daha çok şey öğretir. Ölçümü mümkün olduğunca aynı saatte ve benzer koşullarda tekrarlamak da sonuçların birbiriyle karşılaştırılabilir olmasını sağlar.

Düzeltme sırası ve tasarımla denge

İyileştirmeye nereden başlanacağı sorusunun cevabı bellidir: en çok yükü en az emekle azaltan işten. Sıra genellikle şöyle işler. Önce görseller boyutlandırılır ve uygun biçime dönüştürülür. Sonra kullanılmayan araçlar ve eklentiler kaldırılır. Ardından önbellek ve sıkıştırma ayarları yapılır. Daha sonra yazı tipi davranışı düzeltilir ve öğelere baştan yer ayrılarak kaymalar giderilir. En son, tarayıcıda çalışan kodun bölünmesi ve ertelenmesi gibi daha teknik işler gelir. Bu sıra bozulduğunda en zor işle başlayıp en kolay kazancı kaçırma riski doğar ve çalışma çoğu zaman yarıda kalır. Her adımdan sonra ölçüm alıp not etmek, hangi müdahalenin ne kadar fayda sağladığını görmenizi ve bir sonraki projede daha isabetli davranmanızı sağlar.

Ölçüm puanını bir hedef haline getirmek de yaygın bir hatadır. Amaç yüksek bir puan almak değil, kullanıcının bekleme hissini azaltmaktır. Bazen puanı birkaç basamak yükselten bir müdahale kullanıcı için hiçbir fark yaratmaz; bazen puanı hiç değiştirmeyen bir düzenleme deneyimi belirgin biçimde iyileştirir. Bu yüzden karar verirken sayının kendisine değil, o sayının hangi davranışı temsil ettiğine bakmak gerekir. Puan bir gösterge tablosudur, varış noktası değil. Mükemmel puanın peşinde koşmak yerine, gerçek bir telefonda sayfanın rahat açılıp rahat kullanıldığından emin olmak daha sağlıklı bir ölçüttür. Puanı iyi olup kullanımı kötü olan sayfalar da vardır ve bunları yalnızca gerçek bir deneme ortaya çıkarır.

Son olarak hız ile tasarım arasında gerçek bir gerilim vardır ve bunu inkâr etmek işe yaramaz. Büyük görseller, hareketli geçişler ve zengin görsel anlatım sayfayı ağırlaştırır. Buradaki çözüm hepsinden vazgeçmek değil, her ağır öğenin bir işi olduğundan emin olmaktır. Dikkat çeken bir açılış görseli anlatıma katkı yapıyorsa yerinde durur; sadece boşluk doldurduğu için konmuşsa çıkarılır. Aynı soru animasyonlar, gömülü videolar ve kayan bölümler için de sorulmalıdır. Biz projelerde bu kararı tasarım aşamasında veriyoruz, çünkü hız sonradan eklenen bir düzeltme değil, baştan alınan kararların toplamıdır. Tasarım aşamasında sorulan tek bir soru, yayın sonrasında haftalarca sürecek bir iyileştirme çalışmasının yerini tutar.