Web'in Büyüme Sancıları: 1996'nın Darboğazı Nereye Taşındı?
Doksanların ortasında web'in en görünür sorunu sunucu kapasitesiydi: kullanıcı sayısı katlanarak artıyor, donanım yetişemiyordu. O dönemin teşhisi doğruydu, çözümü de büyük ölçüde bulundu. Ama aynı dönemin iki varsayımı bugüne olduğu gibi taşınıyor ve ikisi de artık geçerli değil.
Kapasite sorunu çözüldü, darboğaz taşındı
Esnek altyapı, yatay ölçekleme ve dağıtık önbellek, sunucu tarafındaki sıkışmayı çoğu site için tarihe gömdü. Ortalama bir kurumsal sitenin bugün karşılaştığı yavaşlık, sunucunun isteği karşılayamamasından kaynaklanmıyor. Sunucu yanıtı milisaniyeler içinde dönüyor, ardından tarayıcı megabaytlarca betiği ayrıştırıp çalıştırmakla uğraşıyor.
Bu, ölçüm alışkanlıklarını da değiştirmesi gereken bir kayma. Sunucu yanıt süresine bakan bir izleme paneli, kullanıcının gerçekten beklediği sürenin küçük bir dilimini görür. Tarayıcı tarafındaki işlem süresi ve ana iş parçacığının bloke olduğu aralık ölçülmeden, hız iyileştirmesi büyük ölçüde tahmine dayanır.
Önbellek ile kişiselleştirme çelişkisi hiç çözülmedi
Doksanlardaki ayna sunucu ve önbellek çözümlerinin, içerik kullanıcıya göre değiştikçe etkisini kaybettiği o zaman da fark edilmişti. Bu gözlem bugün de aynen geçerli. Her isteğe kullanıcı adı, sepet özeti veya kişiye özel öneri iliştirdiğiniz anda sayfa CDN'de paylaşılabilir olmaktan çıkar.
Kişiselleştirilmiş parçayı ayrı bir istekle çek, sayfanın geri kalanı yeniden paylaşılabilir önbelleğe girsin. Sağ üst köşedeki isim yüzünden bütün HTML'i dinamik üretmeye değmez; kazanılan tutarlılık, kaybedilen önbellek isabetinin yanında küçük kalır.
"Kullanıcıların yarısı acemi" varsayımı artık tutmuyor
O dönemin kullanılabilirlik önerilerinin çoğu tek bir aritmetiğe dayanıyordu: kullanıcı sayısı her yıl ikiye katlanıyorsa, bugünkü kitlenin yaklaşık yarısı web'i bir yıldan kısa süredir kullanıyor demektir. Bu doğruysa, arayüzü sürekli ilk kez gelen kişiye göre kurmak mantıklıdır.
Büyüme düzleşince aynı hesap tersine döner. Yıllık artış yüzde birkaç seviyesindeyse, tamamen acemi kullanıcıların oranı da o mertebeye iner. Bugün bir arayüzün karşısındaki kişi büyük olasılıkla on yıldır form dolduruyor, kaydırma jestini biliyor, çarpı işaretini arıyor. Tanıdık kalıpları açıklamak için harcanan ekran alanı, çoğu üründe deneyimli kullanıcıyı yavaşlatmaktan başka işe yaramıyor.
Bu, karşılama akışlarını tamamen atın demek değil. Ürüne özgü olan ile web'e özgü olanı ayırmak gerekiyor: kendi alan modelinizi anlatın, kaydırmayı anlatmayın.
Ölçmeden iyileştirme yapılmıyor
Hız çalışmasının sırası, tahmini en aza indirecek biçimde kurulmalı.
- PageSpeed Insights ile saha verisine bakın; laboratuvar skoru tek başına yanıltıcıdır.
- WebPageTest veya GTmetrix ile şelale grafiğini çıkarın, hangi kaynağın hangisini beklettiğini görün.
- En ağır üç kaynağı isimlendirin. Çoğu sitede bunlar üçüncü taraf betikleri ve boyutlandırılmamış görsellerdir.
- Değişikliği yaptıktan sonra aynı ölçümü tekrarlayın; iyileşme sayıyla gösterilemiyorsa yapılmamış sayılır.
Erişilebilirlik tarafı bu listeden ayrı düşünülmemeli. Ana iş parçacığını dakikalarca meşgul eden bir sayfa, ekran okuyucu kullanan bir ziyaretçi için sadece yavaş değil, kullanılamaz hale gelir. Performans bütçesi, erişilebilirlik bütçesinin de bir parçası.