Sonsuz Kaydırma: Ne Zaman Çalışır, Bedeli Ne Olur
Sonsuz kaydırma, tıklamayı ortadan kaldırdığı için bedava görünür. Bedeli sonra çıkar: geri dönen kullanıcı listenin başına düşer, footer erişilemez hale gelir, telefon ısınır. Sorulacak soru desenin iyi mi kötü mü olduğu değil, kullanıcının o ekranda göz mü attığı yoksa bir şey mi aradığı.
Kaydırma nerede gerçekten kazandırıyor
Akış tipi içerikte kazanç net. Kullanıcı belirli bir hedefe gitmiyor, homojen bir yığının içinden geçiyor. Instagram akışında "3. sayfa" diye bir şey yok, çünkü ikinci gönderiyle yirmincisi arasında kullanıcı açısından bir hiyerarşi yok. Nike'ın ürün listelerinde de aynı mantık işliyor, göz atma davranışı baskın olduğu sürece.
Peki ya kullanıcı gerçekten arıyorsa? 42 beden siyah koşu ayakkabısı arayan biri için kaydırma bir kolaylık değil, filtrelenmiş listeye ulaşana kadar geçmek zorunda kaldığı bir engel. Aynı sayfa, iki niyet, iki farklı doğru cevap. Ürün listeleme sayfası için tek bir desen seçmek zorunda da değilsin: filtre uygulandığı anda sayfalamaya geçmek de bir tasarım kararı.
Geri tuşu, desenin gerçek maliyeti
Sonsuz kaydırmanın en pahalı parçası kaydırma değil, geri dönüş. Kullanıcı on ikinci partideki ürünü açıp geri geldiğinde iki şeyin birlikte gelmesi gerekiyor: yüklenmiş bütün partiler ve kaydırma konumu. Bunu ancak yüklü aralığı URL'ye ya da geçmiş durumuna yazarsan yapabilirsin. Yazmazsan kullanıcı listenin başına düşer ve az önce yaptığı işi baştan yapar. Bir e-ticaret projesinde sonsuz kaydırmayı tam bu yüzden söküp sayfalamaya dönmüştük.
Arama motoru tarafında da aynı sorun var, farklı kılıkta. Bot kaydırmaz. İçeriğe yalnızca gerçek URL'ler üzerinden erişilebiliyorsa taranır; yani sonsuz kaydırma, sayfalanmış URL'lerin üstüne kurulan bir iyileştirme katmanı olmalı, tersi değil. Kaydırmanın altında /liste?sayfa=3 gibi kendi başına çalışan bağlantılar yoksa arşivin büyük kısmı görünmez kalır.
DOM büyümesi ilk yüklemede neden fark edilmez
İlk açılış hızlıdır, çünkü yalnızca ilk parti gelir. Bir ürün kartı yaklaşık kırk DOM düğümü tutuyorsa ve her partide yirmi kart yüklüyorsan, on beşinci partide sayfada on iki bin düğüm birikmiş olur. Yerleşim ve boyama maliyeti düğüm sayısıyla büyüdüğü için takılma tam da kullanıcı akışa girmişken başlar, ölçüm yaptığın ilk saniyede değil.
İki çıkış var: pencereleme, yani yalnızca görünür aralığı DOM'da tutmak; ya da parti sayısını sınırlayıp devamını bir düğmeye bağlamak. Pencereleme ucuz gelmesin, tarayıcının kendi sayfa içi aramasını ve odak sırasını da beraberinde bozar.
Klavye ve ekran okuyucu tarafı
Kaydırmayla büyüyen liste, sıralı gezinen kullanıcı için sonu olmayan bir tünel. Footer'daki iletişim bağlantısına klavyeyle ulaşmak imkânsız hale geliyorsa bu bir konfor meselesi değil, erişim engeli. ARIA'nın feed rolü tam bunun için: akışa ve öğelere sıra bilgisi verir, ekran okuyucuya burada büyüyen bir liste olduğunu söyler. Rol tek başına yetmiyor ama; kritik bağlantıları akışın altına değil üstüne ya da kenara koymak gerekiyor.
Hangi listede hangisi
Göz atma baskınsa, içerik homojense ve kullanıcının aynı öğeye geri dönmesi beklenmiyorsa kaydırma doğru karar. Kullanıcı arıyorsa, listeye dönüş sıksa ve içeriğin taranması gerekiyorsa sayfalama. Arada kalan geniş orta alan "daha fazla göster" düğmesinin: veri tüketimi kullanıcının kontrolünde kalır, footer erişilebilir olur, geri dönüş davranışı basitleşir.
Kaydırma sürerken sayfa göstergesi de gösteren hibrit yaklaşım merak ediliyor. Tekrar bulunabilirlik sorununu gerçekten çözüyor, fakat URL ve geçmiş yönetimini zorunlu kıldığı için üç seçenek arasında en pahalısı. Kataloğun büyükse ve trafiğin aramadan geliyorsa bu maliyeti ödemeye değer, küçük bir listede değmez.