Co to jest infinite scrolling i kiedy warto stosować nieskończone przewijanie?

Infinite scrolling, czyli nieskończone przewijanie, to sposób prezentowania treści, w którym kolejne elementy są automatycznie doładowywane, gdy użytkownik zbliża się do końca aktualnie widocznej listy.

Zamiast przechodzić z pierwszej strony wyników na drugą, trzecią i kolejną, użytkownik po prostu przewija.

Nowe produkty, wpisy, zdjęcia albo inne elementy pojawiają się bez klasycznego przeładowania całej strony.

Mechanizm jest dobrze znany z serwisów społecznościowych, gdzie strumień treści może teoretycznie ciągnąć się niemal bez końca.

Na pierwszy rzut oka rozwiązanie wydaje się idealne.

Nie trzeba klikać „Następna strona”.

Nie przerywamy przeglądania.

Treść cały czas pojawia się przed użytkownikiem.

Problem polega na tym, że infinite scrolling nie jest automatycznie lepszy od tradycyjnej paginacji.

W jednych projektach potrafi znacznie poprawić doświadczenie użytkownika.

W innych może utrudnić powrót do wcześniej oglądanej treści, zwiększyć obciążenie przeglądarki, utrudnić korzystanie ze stopki, stworzyć problemy z dostępnością i skomplikować indeksowanie kolejnych elementów przez wyszukiwarki.

Dlatego pytanie nie powinno brzmieć:

Czy infinite scroll jest nowocześniejszy?

Lepiej zapytać:

Czy ten sposób nawigacji odpowiada temu, co użytkownik próbuje zrobić?

Jak działa infinite scrolling?

Klasyczna strona z listą produktów lub artykułów pobiera określoną liczbę elementów podczas pierwszego wejścia.

Przykładowo może pokazać 24 produkty.

W tradycyjnej paginacji kolejne produkty znajdują się pod osobnymi adresami lub na kolejnych logicznych stronach listy.

Użytkownik klika:

2 → 3 → 4 → 5

i przechodzi pomiędzy kolejnymi zestawami wyników.

Infinite scrolling działa inaczej.

Skrypt obserwuje pozycję użytkownika na stronie.

Kiedy zbliża się on do końca aktualnej listy, aplikacja wysyła w tle żądanie pobrania następnej partii danych.

Serwer zwraca kolejne elementy, a JavaScript dokłada je do już istniejącej listy.

Dla użytkownika wygląda to tak, jakby strona nie miała końca.

Infinite scrolling a AJAX

Nieskończone przewijanie bardzo często wykorzystuje AJAX lub podobny mechanizm komunikacji asynchronicznej.

Nie trzeba wtedy przeładowywać całej strony.

Pobierane są jedynie kolejne dane potrzebne do rozbudowania listy.

Może to być:

• HTML kolejnych kart produktów,
• dane JSON przekształcane później w elementy interfejsu,
• kolejne wpisy blogowe,
• zdjęcia,
• wyniki wyszukiwania.

Samo użycie AJAX nie oznacza jednak infinite scrollingu.

Można przecież pobierać kolejne elementy dopiero po kliknięciu przycisku „Pokaż więcej”.

Różnica dotyczy przede wszystkim sposobu wywołania kolejnej operacji.

Infinite scroll, paginacja i „Pokaż więcej” – trzy różne rozwiązania

W praktyce przy projektowaniu długiej listy mamy zazwyczaj trzy podstawowe możliwości.

Klasyczna paginacja

Lista zostaje podzielona na kolejne strony.

Użytkownik sam decyduje, kiedy przejść dalej.

Przycisk „Pokaż więcej”

Kolejna partia wyników jest doładowywana bez przeładowania strony, ale dopiero po świadomym działaniu użytkownika.

Infinite scrolling

Kolejna partia jest pobierana automatycznie podczas przewijania.

Technicznie dwa ostatnie rozwiązania mogą być bardzo podobne.

UX jest jednak zupełnie inny.

Dlaczego infinite scrolling stał się tak popularny?

Infinite scroll świetnie pasuje do zachowania polegającego na swobodnym przeglądaniu dużej liczby elementów.

Jeżeli użytkownik nie szuka konkretnej pozycji, tylko chce odkrywać kolejne treści, każde dodatkowe kliknięcie może być niepotrzebną przerwą.

Przykładowo podczas oglądania:

• zdjęć,
• inspiracji,
• krótkich filmów,
• aktualności,
• postów społecznościowych

użytkownik często nie interesuje się tym, czy znajduje się na stronie numer 4 czy 17.

Interesuje go kolejny element.

Właśnie w takim scenariuszu nieskończone przewijanie może być bardzo naturalne.

Kiedy infinite scrolling działa dobrze?

Najlepiej sprawdza się wtedy, kiedy:

• użytkownik przegląda treści eksploracyjnie,
• kolejność elementów nie ma dużego znaczenia nawigacyjnego,
• nie musi zapamiętywać konkretnej strony wyników,
• lista może być długa,
• kolejne elementy są stosunkowo lekkie,
• powrót do określonego miejsca można technicznie poprawnie obsłużyć.

Dobrym przykładem może być galeria inspiracji.

Użytkownik nie myśli:

Chcę zobaczyć stronę numer siedem.

Po prostu ogląda kolejne realizacje.

Kiedy infinite scrolling może być złym pomysłem?

Sytuacja zmienia się, kiedy użytkownik wykonuje zadanie wymagające orientacji w zbiorze.

Wyobraźmy sobie sklep z kilkoma tysiącami produktów.

Klient przewija listę przez kilka minut.

Znajduje interesujący produkt.

Wchodzi na jego kartę.

Po chwili wraca.

Jeżeli system odsyła go na początek kategorii, doświadczenie jest fatalne.

Użytkownik nie wie:

• jak daleko wcześniej dotarł,
• które produkty już oglądał,
• gdzie znajdował się interesujący fragment listy.

Przy paginacji miałby przynajmniej punkt odniesienia:

Byłem na stronie 6.

Infinite scrolling w sklepie internetowym

Sklepy są jednym z najciekawszych przypadków, ponieważ infinite scrolling może w nich zarówno pomagać, jak i przeszkadzać.

W kategorii posiadającej wiele podobnych produktów płynne doładowywanie może być wygodne.

Klient szybko ogląda kolejne:

• kolory,
• wzory,
• modele,
• zdjęcia.

Nie musi za każdym razem przechodzić na kolejną stronę.

Jednocześnie e-commerce wymaga znacznie większej kontroli nad stanem interfejsu niż prosty feed społecznościowy.

Klient filtruje.

Sortuje.

Otwiera produkty.

Wraca.

Porównuje.

Zmienia kryteria.

Dlatego samo „doładowujmy wszystko automatycznie” jest zwykle zbyt prostym podejściem.

Infinite scrolling a filtry produktów

Filtry dodatkowo komplikują sytuację.

Załóżmy, że użytkownik wybiera:

• markę,
• rozmiar,
• kolor,
• zakres ceny.

Otrzymuje 300 produktów.

Przewija do około setnego produktu, otwiera kartę i wraca.

Dobrze zaprojektowany system powinien odtworzyć:

• wybrane filtry,
• sortowanie,
• załadowaną liczbę produktów,
• pozycję przewinięcia.

Jeżeli choć jeden z tych elementów zostanie utracony, użytkownik może być zmuszony do powtarzania całej pracy.

Infinite scrolling a przycisk „Wstecz”

Obsługa przycisku „Wstecz” jest jednym z najważniejszych elementów dobrego wdrożenia.

Przeglądarka posiada własną historię.

Użytkownik ma utrwalone oczekiwanie, że po wejściu do produktu i powrocie znajdzie się mniej więcej tam, gdzie był.

Jeżeli aplikacja dynamicznie przebudowuje listę, ale nie zachowuje jej stanu, naturalny mechanizm przeglądarki może nie wystarczyć.

Trzeba więc świadomie zaprojektować:

• odtwarzanie listy,
• pozycję scrolla,
• historię,
• parametry URL.

Dlaczego adres URL nadal ma znaczenie?

Infinite scrolling może sprawiać wrażenie, że strony przestały istnieć.

Z technicznego punktu widzenia bardzo często nadal warto zachować logiczny podział zbioru.

Przykładowo użytkownik przewija kategorię i aplikacja kolejno pobiera zestawy odpowiadające:

stronie 1, 2, 3, 4…

Nie musi widzieć tradycyjnej paginacji.

System nadal może jednak posiadać adresy pozwalające dostać się bezpośrednio do kolejnych części listy.

Ma to znaczenie dla:

• nawigacji,
• udostępniania adresu,
• historii przeglądarki,
• SEO,
• obsługi sytuacji bez JavaScript.

Infinite scrolling a SEO

To właśnie SEO jest jednym z powodów, dla których wdrożenia infinite scrollingu trzeba projektować technicznie, a nie wyłącznie wizualnie.

Użytkownik może przewijać stronę i uruchamiać kolejne żądania JavaScript.

Robot wyszukiwarki nie powinien być jednak jedynym sposobem dotarcia do kolejnych elementów uzależniony od wykonywania dokładnie takiej samej interakcji jak człowiek.

Jeżeli produkty lub wpisy pojawiają się wyłącznie po wykonaniu określonego skryptu i nie istnieje żadna normalna ścieżka prowadząca do kolejnych części listy, możemy utrudnić ich odkrywanie.

Dlatego przy SEO technicznym infinite scrolling powinien być analizowany również jako element architektury nawigacyjnej strony.

Najbezpieczniejsze podejście: progressive enhancement

Dobrym sposobem myślenia o infinite scrollingu jest progressive enhancement.

Podstawowa wersja strony posiada normalną, działającą strukturę.

JavaScript poprawia później doświadczenie użytkownika.

Przykładowo bazowa wersja kategorii może posiadać:

strona 1 → strona 2 → strona 3

Po uruchomieniu JavaScript użytkownik nie musi klikać tych odnośników, ponieważ kolejne części są doładowywane automatycznie.

Fundamentalna struktura nadal jednak istnieje.

To znacznie solidniejsze rozwiązanie niż stworzenie całej listy wyłącznie jako efektu działania skryptu.

Czy infinite scrolling blokuje indeksowanie?

Nie sam w sobie.

Problemem nie jest efekt przewijania.

Problemem może być sposób technicznego udostępniania kolejnych treści.

Jeżeli każdy produkt posiada własny indeksowalny adres, a robot może znaleźć go również przez poprawnie zbudowane linkowanie i strukturę kategorii, sytuacja wygląda zupełnie inaczej niż wtedy, gdy dostęp do większości katalogu istnieje wyłącznie poprzez serię dynamicznych wywołań.

Nie należy więc sprowadzać problemu do zasady:

Infinite scroll jest zły dla SEO.

Poprawniejsze jest:

źle zaprojektowany infinite scroll może być zły dla SEO.

Infinite scrolling a linkowanie wewnętrzne

Struktura kategorii pomaga wyszukiwarkom odnajdywać produkty i rozumieć relacje pomiędzy stronami.

Jeżeli tradycyjne linki do kolejnych części listy zostaną całkowicie usunięte i zastąpione mechanizmem JavaScript, warto sprawdzić, czy nie osłabiono przy okazji zwykłej ścieżki crawl.

Dotyczy to szczególnie dużych serwisów posiadających:

• tysiące produktów,
• wiele kategorii,
• głęboką strukturę katalogu.

W takich projektach wygląd listingu jest tylko jednym elementem większej architektury.

Infinite scrolling a WooCommerce

WooCommerce standardowo dobrze współpracuje z klasycznym modelem archiwum produktów i paginacji.

Infinite scroll można do niego dołożyć, ale warto traktować go jako zmianę sposobu obsługi listy, a nie tylko efekt wizualny.

Przy tworzeniu i rozwijaniu sklepów WooCommerce zwracam uwagę między innymi na to, czy po zmianie listingu nadal poprawnie działają:

• filtry,
• sortowanie,
• licznik wyników,
• powrót z produktu,
• historia przeglądarki,
• linkowanie,
• analityka e-commerce.

Samo doładowanie kolejnych produktów jest zwykle najprostszą częścią całego rozwiązania.

Infinite scrolling a Core Web Vitals

Nieskończone przewijanie może mieć wpływ również na wydajność.

Każda kolejna partia produktów może oznaczać:

• nowe elementy DOM,
• kolejne obrazy,
• dodatkowe skrypty inicjalizujące komponenty,
• obserwatory zdarzeń,
• kolejne dane przechowywane w pamięci.

Przy krótkiej liście nie ma to większego znaczenia.

Po załadowaniu kilkuset lub kilku tysięcy kart sytuacja może wyglądać inaczej.

DOM może rosnąć praktycznie bez końca

Każdy produkt na liście to pewna liczba elementów HTML.

Jeżeli jedna karta zawiera:

• zdjęcie,
• nazwę,
• cenę,
• promocję,
• przyciski,
• warianty,
• ikonki,

to kilkaset produktów może stworzyć tysiące elementów DOM.

Przeglądarka musi nimi zarządzać.

Może to zwiększyć:

• zużycie pamięci,
• czas wykonywania JavaScript,
• koszt przeliczania layoutu,
• czas renderowania.

Dlatego prawdziwie „nieskończona” lista nie zawsze powinna rzeczywiście trzymać wszystko, co kiedykolwiek zostało załadowane.

Wirtualizacja długich list

W bardzo rozbudowanych aplikacjach stosuje się czasami wirtualizację.

Zamiast utrzymywać wszystkie elementy w DOM, system renderuje tylko te znajdujące się w aktualnym lub pobliskim obszarze widoku.

Pozostałe mogą być usuwane i odtwarzane w razie potrzeby.

To pozwala obsługiwać ogromne zbiory danych.

Rozwiązanie jest jednak znacznie bardziej skomplikowane.

Trzeba zachować:

• poprawną wysokość listy,
• pozycję użytkownika,
• focus,
• stan elementów.

Nie każdy sklep potrzebuje więc pełnej wirtualizacji tylko dlatego, że posiada infinite scrolling.

Obrazy są jednym z największych kosztów

Listing produktów lub realizacji może zawierać setki grafik.

Jeżeli infinite scroll bez kontroli zaczyna pobierać kolejne obrazy, transfer może szybko rosnąć.

Dlatego bardzo ważne są:

• lazy loading,
• odpowiednie rozmiary plików,
• responsywne obrazy,
• nowoczesne formaty,
• rozsądne preloadowanie.

Nie ma sensu ładować od razu dziesięciu kolejnych ekranów treści tylko dlatego, że technicznie można.

Prefetch i doładowywanie z wyprzedzeniem

Infinite scroll powinien sprawiać wrażenie płynnego.

Jeżeli użytkownik dochodzi do końca listy, widzi spinner i czeka kilka sekund, cała zaleta rozwiązania zaczyna znikać.

Można temu przeciwdziałać, uruchamiając pobieranie kolejnej partii nieco wcześniej.

Nie wtedy, kiedy użytkownik już dotarł do ostatniego produktu, lecz kiedy zbliża się do końca aktualnie dostępnej treści.

Trzeba jednak znaleźć równowagę.

Zbyt agresywne pobieranie może generować transfer danych dla elementów, których użytkownik nigdy nie zobaczy.

Intersection Observer zamiast ciągłego nasłuchiwania scrolla

Technicznie infinite scroll można zbudować poprzez ciągłe analizowanie pozycji przewijania.

W nowoczesnych implementacjach często wygodniejszym rozwiązaniem jest obserwowanie specjalnego elementu umieszczonego w pobliżu końca listy.

Gdy pojawi się on w obszarze obserwowanym przez przeglądarkę, można rozpocząć pobieranie kolejnego zestawu.

Architektura jest wtedy bardziej związana z faktyczną widocznością elementu niż z ręcznym liczeniem pozycji strony.

Co powinno się wydarzyć podczas ładowania?

Użytkownik powinien wiedzieć, że system wykonuje operację.

Może pojawić się:

• spinner,
• skeleton loader,
• krótki komunikat,
• placeholder kolejnych kart.

Nie powinno jednak dochodzić do sytuacji, w której layout nagle skacze albo użytkownik nie wie, czy lista już się skończyła, czy tylko coś się nie załadowało.

Infinite scrolling a błędy sieci

Każda kolejna partia treści to kolejne żądanie do serwera.

Może się nie udać.

Przyczyną może być:

• chwilowy brak internetu,
• timeout,
• błąd serwera,
• problem API.

Dobre wdrożenie powinno obsługiwać taki przypadek.

Zamiast nieskończonego spinnera warto pokazać użytkownikowi informację oraz możliwość ponowienia operacji.

Co powinno się wydarzyć po dojściu do końca?

Infinite scroll nie zawsze jest rzeczywiście nieskończony.

Kategoria może mieć 238 produktów.

Po ich załadowaniu użytkownik powinien dostać czytelną informację, że zobaczył już wszystkie wyniki.

Brak kolejnych elementów nie powinien wyglądać jak awaria.

Problem stopki w infinite scrollingu

To jeden z klasycznych problemów.

Użytkownik próbuje dotrzeć do stopki.

Zbliża się do końca strony.

System ładuje kolejne elementy.

Stopka ucieka.

Użytkownik przewija ponownie.

System znowu dokłada kolejną partię.

Jeżeli lista jest bardzo długa, dostęp do stopki staje się absurdalnie trudny.

To kolejny argument za tym, że pełny infinite scroll nie jest zawsze najlepszym rozwiązaniem.

Przycisk „Pokaż więcej” często rozwiązuje większość problemów

W wielu projektach najlepszym kompromisem jest przycisk:

Pokaż więcej

Technicznie nadal możemy:

• korzystać z AJAX,
• doładować kolejne elementy bez przeładowania,
• zachować już widoczne produkty,
• zapewnić płynne doświadczenie.

Jednocześnie użytkownik kontroluje moment doładowania.

Może zatrzymać się.

Może dotrzeć do stopki.

Wie również, że świadomie otworzył kolejną partię wyników.

Infinite scroll czy „Pokaż więcej” w e-commerce?

W sklepach bardzo często preferuję wariant kontrolowany.

Nie oznacza to, że infinite scroll jest zły.

Przycisk „Pokaż więcej” ma jednak kilka praktycznych zalet:

• ogranicza niekontrolowane pobieranie danych,
• użytkownik zachowuje kontrolę,
• łatwiej dotrzeć do stopki,
• prościej zrozumieć kolejne porcje wyników,
• łatwiej zbudować dostępny mechanizm.

Infinite scrolling a dostępność

Dostępność to obszar, o którym łatwo zapomnieć, ponieważ infinite scroll projektuje się przede wszystkim z myślą o wizualnym przewijaniu myszką lub palcem.

Nie każdy użytkownik korzysta jednak ze strony w taki sposób.

Trzeba uwzględnić osoby:

• korzystające z klawiatury,
• używające czytników ekranowych,
• poruszające się pomiędzy elementami przez focus,
• korzystające z technologii wspomagających.

Nowa treść musi być komunikowana

Jeżeli kolejne elementy pojawiają się dynamicznie, użytkownik czytnika ekranowego powinien móc zrozumieć, że lista została rozszerzona.

Nie można zakładać, że wizualne pojawienie się kolejnych kart jest wystarczającą informacją.

Jednocześnie nie należy zasypywać użytkownika komunikatami przy każdej drobnej zmianie.

Mechanizm powinien być spokojny i przewidywalny.

Focus nie powinien skakać

Podczas doładowywania nowych elementów nie powinno dochodzić do przypadkowego przejmowania focusa.

Jeżeli użytkownik korzysta z klawiatury i nagle znajduje się w innym miejscu interfejsu, orientacja w stronie może zostać utracona.

Przy przycisku „Pokaż więcej” sprawa jest prostsza, ponieważ użytkownik świadomie wywołuje działanie.

Można wtedy odpowiednio zaprojektować zachowanie focusa po rozszerzeniu listy.

Infinite scrolling na urządzeniach mobilnych

Na telefonach przewijanie jest bardzo naturalną interakcją.

Dlatego infinite scrolling może wydawać się szczególnie dobrym rozwiązaniem właśnie na mobile.

Ma to sporo sensu.

Trzeba jednak uwzględnić:

• transfer danych,
• słabsze urządzenia,
• niestabilne połączenie,
• zużycie pamięci,
• powrót do listy po otwarciu produktu.

Interfejs, który działa idealnie na mocnym komputerze z szybkim łączem, może zachowywać się zupełnie inaczej na kilkuletnim telefonie korzystającym z mobilnego internetu.

Infinite scroll a zużycie danych

Automatyczne doładowywanie ma jeszcze jedną cechę.

Użytkownik nie musi świadomie prosić o kolejną partię treści.

System robi to za niego.

Dlatego łatwiej pobrać zasoby, których człowiek wcale nie potrzebował.

Przycisk „Pokaż więcej” ogranicza to ryzyko, ponieważ pobranie kolejnej porcji wynika z wyraźnej decyzji użytkownika.

Infinite scrolling a analityka

Klasyczna paginacja tworzy naturalne zdarzenia.

Użytkownik przeszedł na stronę 2.

Później na 3.

W infinite scrollingu trzeba samodzielnie zdecydować, co chcemy mierzyć.

Można śledzić na przykład:

• załadowanie kolejnej partii wyników,
• liczbę wyświetlonych produktów,
• głębokość przeglądania kategorii,
• kliknięcie produktu po określonej liczbie wyników,
• korzystanie z filtrów.

Nie oznacza to jednak, że należy wysyłać zdarzenie dla każdego pojedynczego ruchu scrolla.

Pomiar powinien odpowiadać na pytania biznesowe.

Co warto mierzyć w sklepie?

Interesujące może być na przykład to, czy użytkownicy:

• rzadko przekraczają pierwsze 24 produkty,
• regularnie przeglądają ponad 100 wyników,
• częściej korzystają z filtrów niż przewijają,
• klikają produkty głównie z początku listy.

Takie dane mogą pokazać, czy większym problemem jest sposób paginacji, czy może jakość filtrowania i sortowania.

Infinite scrolling nie naprawi słabej nawigacji

Jeżeli klient musi przeglądać 800 produktów, aby znaleźć właściwy, problem może wcale nie polegać na tym, że paginacja jest niewygodna.

Problemem może być:

• brak dobrych filtrów,
• słaba kategoryzacja,
• nieczytelne nazwy produktów,
• niewłaściwe sortowanie.

Infinite scroll może wręcz ukryć ten problem, pozwalając użytkownikowi szybciej przewijać źle zorganizowany katalog.

Nowoczesny interfejs nie powinien pomagać człowiekowi szybciej wykonywać niepotrzebnej pracy.

Search jest czasami ważniejszy od infinite scrolla

Jeżeli użytkownik wie, czego szuka, dobry system wyszukiwania może być znacznie bardziej wartościowy niż możliwość przeglądania kolejnych setek elementów.

W dużych katalogach warto więc patrzeć na cały zestaw narzędzi:

• wyszukiwarkę,
• filtry,
• sortowanie,
• kategorie,
• paginację lub doładowywanie.

Infinite scrolling jest tylko jednym elementem tego systemu.

Infinite scrolling a sortowanie

Zmiana sortowania powinna zwykle rozpocząć listę od początku.

Jeżeli użytkownik załadował wcześniej 200 produktów, a następnie zmienia:

Popularne

na:

Cena od najniższej

system powinien jasno zresetować poprzedni stan.

Nie może mieszać produktów z dwóch różnych kolejności.

Infinite scrolling a dynamiczne dane

Problem staje się jeszcze ciekawszy, kiedy kolejność wyników zmienia się w czasie.

Dotyczy to na przykład feedów aktualności.

Pomiędzy pobraniem pierwszej i drugiej partii mogą pojawić się nowe elementy.

Jeżeli backend używa prostego offsetu, może dojść do:

• duplikowania elementów,
• pomijania elementów.

W takich przypadkach lepiej sprawdzają się mechanizmy oparte na stabilnym kursorze lub identyfikatorze kolejnej części zbioru.

Offset pagination i cursor pagination

To techniczny szczegół, ale ważny przy dużych dynamicznych zbiorach.

Klasyczny model może działać tak:

daj elementy 1–20, później 21–40, później 41–60.

To paginacja oparta na offsecie.

Jeżeli jednak pomiędzy żądaniami lista się zmieni, granice mogą się przesunąć.

Cursor pagination mówi raczej:

daj kolejne elementy znajdujące się po tym konkretnym rekordzie.

Przy dynamicznych feedach może to dawać bardziej stabilne rezultaty.

Infinite scroll w aplikacji a infinite scroll na stronie SEO

To ważne rozróżnienie.

W aplikacji dostępnej dopiero po zalogowaniu SEO może praktycznie nie mieć znaczenia.

Możemy wtedy skoncentrować się na:

• wydajności,
• UX,
• zarządzaniu stanem.

Na publicznej stronie kategorii sklepu sytuacja jest inna.

Tam trzeba dodatkowo uwzględnić:

• indeksowanie,
• linkowanie,
• adresy URL,
• strukturę katalogu.

Dlatego identyczny komponent nie zawsze powinien być stosowany wszędzie.

Czy należy aktualizować URL podczas przewijania?

Może to być bardzo dobre rozwiązanie, jeżeli jest zrobione przewidywalnie.

Gdy użytkownik dochodzi do fragmentu odpowiadającego stronie numer 4, aplikacja może zaktualizować bieżący adres bez pełnego przeładowania.

Dzięki temu historia przeglądarki lepiej odzwierciedla aktualne miejsce.

Trzeba jednak uważać, żeby nie generować dziesiątek wpisów historii podczas jednego przewijania.

Mechanizm powinien pomagać użytkownikowi, a nie walczyć z przyciskiem „Wstecz”.

Stan listy można zapisać również w URL

Parametry mogą opisywać:

• stronę,
• filtry,
• sortowanie.

Dzięki temu użytkownik może:

• odświeżyć stronę,
• skopiować adres,
• otworzyć go później

i nadal otrzymać podobny stan wyników.

Nie każdy detal interfejsu musi znaleźć się w URL, ale kluczowe elementy nawigacji często warto tam zachować.

Czy użytkownik powinien wiedzieć, ile wyników pozostało?

W sklepie zwykle tak.

Informacja:

Wyświetlono 48 z 327 produktów

daje użytkownikowi orientację.

Wie, czy przejrzał niewielką część katalogu, czy zbliża się już do końca.

To drobny element, który może znacząco poprawić poczucie kontroli.

Automatyczne ładowanie nie zawsze powinno trwać bez końca

Możliwy jest również model hybrydowy.

Przykładowo system automatycznie ładuje trzy kolejne partie.

Później pojawia się przycisk:

Pokaż więcej

Dzięki temu pierwsze przeglądanie jest płynne, ale użytkownik nadal może łatwo dotrzeć do innych elementów strony.

Nie trzeba wybierać wyłącznie pomiędzy pełną paginacją a nieskończonym feedem.

Infinite scroll może być różny na desktopie i mobile

Nie ma obowiązku stosowania dokładnie tego samego modelu interakcji na każdym urządzeniu.

Na mobile przewijanie jest bardzo naturalne.

Na desktopie użytkownik może częściej:

• otwierać produkty w nowych kartach,
• korzystać z rozbudowanych filtrów,
• porównywać wiele elementów.

Jeżeli dane i testy pokazują istotną różnicę, sposób obsługi listingu można dostosować.

Infinite scrolling a crawl budget

W bardzo dużych serwisach znaczenie ma również sposób, w jaki roboty odkrywają kolejne adresy.

Nie chodzi o to, aby każda możliwa kombinacja listingu tworzyła osobną indeksowalną stronę.

Wręcz przeciwnie.

Trzeba rozdzielić:

• adresy potrzebne do nawigacji,
• adresy wartościowe dla indeksowania,
• kombinacje filtrów, których nie chcemy traktować jako osobnych stron SEO.

Infinite scrolling nie rozwiązuje tego problemu.

Architekturę trzeba zaplanować niezależnie od sposobu wizualnej prezentacji wyników.

Najczęstszy błąd: gotowa wtyczka i koniec analizy

W WordPressie i WooCommerce można znaleźć rozwiązania pozwalające uruchomić infinite scrolling bardzo szybko.

Technicznie może wystarczyć kilka ustawień.

To nie oznacza jednak, że temat został rozwiązany.

Po wdrożeniu warto sprawdzić:

• co dzieje się po wejściu do produktu i powrocie,
• czy filtry zachowują stan,
• czy URL ma sens,
• czy nowe elementy są wykrywalne,
• jak wygląda wydajność po załadowaniu wielu produktów,
• czy rozwiązanie można obsługiwać klawiaturą.

Drugi błąd: automatyczne ładowanie za wcześnie

Jeżeli system pobiera kolejną partię już chwilę po wejściu na stronę, użytkownik może pobierać dziesiątki produktów, których nigdy nie zobaczy.

Ładowanie z wyprzedzeniem powinno poprawiać płynność, a nie generować niepotrzebny transfer.

Trzeci błąd: brak obsługi powrotu

W e-commerce to prawdopodobnie jeden z najbardziej irytujących problemów.

Użytkownik przewija 150 produktów.

Wchodzi na jeden.

Wraca.

I znajduje się na początku listy.

Jedno takie doświadczenie potrafi całkowicie zepsuć ocenę wygody mechanizmu.

Czwarty błąd: brak końca i brak orientacji

Jeżeli użytkownik nie wie:

• ile wyników istnieje,
• ile już zobaczył,
• czy lista nadal się ładuje,

może mieć poczucie utraty kontroli.

Infinite scroll nie powinien oznaczać braku informacji o strukturze zbioru.

Piąty błąd: projektowanie tylko myszką

Mechanizm trzeba przetestować również:

• klawiaturą,
• na telefonie,
• przy dużym powiększeniu,
• z wolniejszym połączeniem.

Dopiero wtedy widać część problemów niewidocznych podczas szybkiego testu na komputerze projektanta.

Szósty błąd: traktowanie scrolla jako celu

Duża głębokość przewijania nie musi oznaczać sukcesu.

Jeżeli klient musi przewinąć 300 produktów, ponieważ nie potrafi znaleźć właściwego, wysoki scroll depth może być oznaką problemu, a nie zaangażowania.

Metryki trzeba interpretować w kontekście zadania.

Siódmy błąd: brak planu na SEO

Projekt jest wizualnie świetny, ale po wdrożeniu okazuje się, że duża część katalogu jest dostępna wyłącznie przez mechanizm JavaScript.

Takie rzeczy powinny zostać przemyślane wcześniej.

UX i SEO nie powinny być osobnymi projektami wykonywanymi jeden po drugim.

Kiedy wybrałbym klasyczną paginację?

Paginację wybrałbym szczególnie wtedy, gdy:

• użytkownik potrzebuje orientacji w zbiorze,
• często wraca do wcześniej oglądanych wyników,
• lista ma wyraźną strukturę,
• ważne jest łatwe udostępnianie określonego fragmentu wyników,
• prostota techniczna ma dużą wartość.

Stara technologia nie oznacza złego UX.

Czasami klasyczna paginacja jest po prostu najbardziej przewidywalna.

Kiedy wybrałbym przycisk „Pokaż więcej”?

To rozwiązanie bardzo dobrze pasuje do:

• sklepów,
• portfolio,
• list wpisów,
• wyników wyszukiwania.

Użytkownik zachowuje kontrolę, ale nie musi przeładowywać strony.

Dodatkowo łatwiej pogodzić je z dostępem do stopki i czytelnym końcem listy.

Kiedy wybrałbym pełny infinite scrolling?

Gdy dominującym zachowaniem jest odkrywanie kolejnych elementów, a nie poruszanie się po uporządkowanym zbiorze.

Dobrymi kandydatami są:

• feedy,
• strumienie aktualności,
• galerie inspiracji,
• niektóre katalogi wizualne.

Nadal trzeba jednak rozwiązać kwestie wydajności, stanu, dostępności i nawigacji.

Jak wybrać właściwy model?

Zadałbym kilka pytań.

1. Czy użytkownik czegoś konkretnego szuka, czy raczej odkrywa?
2. Czy ważne jest zapamiętanie miejsca w liście?
3. Czy często otwiera element i wraca?
4. Czy lista może zawierać setki lub tysiące pozycji?
5. Czy użytkownik powinien móc dotrzeć do stopki?
6. Czy kolejne części listy muszą być łatwo dostępne dla wyszukiwarek?
7. Czy mamy dobre filtry i wyszukiwarkę?
8. Czy mechanizm zachowa stan po odświeżeniu lub powrocie?
9. Czy rozwiązanie będzie dostępne z klawiatury?
10. Jak zachowa się po załadowaniu kilkuset elementów?

Odpowiedzi zwykle szybko pokazują, czy pełny infinite scroll rzeczywiście jest najlepszym wyborem.

Infinite scrolling nie jest funkcją. Jest częścią nawigacji

To najważniejsza rzecz, o której warto pamiętać.

Łatwo traktować infinite scroll jak niewielki efekt:

Zamiast paginacji doładujemy produkty podczas przewijania.

W rzeczywistości zmieniamy jeden z podstawowych sposobów poruszania się użytkownika po dużym zbiorze danych.

Ta decyzja wpływa na:

• URL,
• historię przeglądarki,
• wydajność,
• SEO,
• dostępność,
• analitykę,
• UX.

Dlatego powinna być projektowana tak samo świadomie jak wyszukiwarka, menu czy system filtrów.

Jak podchodzę do infinite scrollingu w projektach?

Nie zakładam z góry, że infinite scrolling jest lepszy dlatego, że wygląda bardziej nowocześnie.

Najpierw patrzę na zachowanie użytkownika.

Jeżeli głównym zadaniem jest swobodne odkrywanie kolejnych elementów, automatyczne doładowywanie może być bardzo dobrym rozwiązaniem.

Jeżeli jednak klient porównuje, filtruje, wraca do wcześniejszych produktów i potrzebuje orientacji, często lepiej sprawdzi się model hybrydowy albo przycisk „Pokaż więcej”.

Przy wdrożeniu sprawdzam również to, co znajduje się pod powierzchnią interfejsu:

• jak zachowuje się historia,
• czy można odtworzyć stan,
• jak rośnie DOM,
• co dzieje się z obrazami,
• czy istnieje poprawna struktura URL,
• czy mechanizm nie utrudnia indeksowania,
• czy użytkownik klawiatury może z niego korzystać.

Dobry infinite scrolling powinien być niemal niewidoczny. Użytkownik po prostu przegląda kolejne treści i nic nie zmusza go do zastanawiania się, jak działa lista.

Jeżeli natomiast zaczyna walczyć z przyciskiem „Wstecz”, traci filtry, szuka stopki albo po powrocie musi przewijać wszystko od początku, problemem nie jest już infinite scrolling.

Problemem jest jego implementacja.