E-commerce: Postrzeganie szybkości witryny robi różnicę

Wszyscy wiemy, że szybkość witryny może mieć ogromny wpływ na współczynnik konwersji i lepkość witryny e-commerce.

W jednym studium przypadku SOASTA stwierdzono, że poprawa szybkości ładowania strony mobilnej zwiększyła współczynnik konwersji o ponad 25%. W swoim nieustannym dążeniu do postawienia użytkownika na pierwszym miejscu, Jeff Bezos, założyciel i dyrektor generalny Amazon, ma słynną obsesję na punkcie szybkości ładowania strony i nieustannie zachęca swoich pracowników do zmniejszania szybkości strony w witrynie Amazon.

Wzrost dominacji urządzeń mobilnych zwiększył potrzebę szybszego ładowania strony, ponieważ użytkownicy często przeglądają witryny na wolniejszych połączeniach.

Istnieje wiele narzędzi, które pomogą Ci poprawić szybkość stron internetowych, takich jak Yslow lub Google Pagespeed Insights, i istnieją różne sprawdzone metody, takie jak minifikacja i łączenie css i js, użycie sprite'ów css i minimalizacja żądań sieciowych, które programista front-end powinien postępować, aby zapewnić maksymalizację szybkości strony.

Problem, który mamy, polega na tym, że gdy zastosujesz się do standardowych najlepszych praktyk i zdasz sobie sprawę z wielkich wygranych, wkrótce zaczniesz zauważać malejące zwroty z wysiłków na rzecz poprawy ogólnej szybkości strony.

Możesz poświęcić dużo czasu na coraz mniejsze, przyrostowe ulepszenia, a będzie to kosztowny i czasochłonny proces. Programiści front-end posiadający niezbędne umiejętności i doświadczenie do pracy na tym poziomie są zaskakująco nieliczni i drodzy.

Niektórych rzeczy nie można kontrolować, takich jak opóźnienie sieci lub szybkość połączenia mobilnego, dlatego istnieje ograniczenie tego, co można osiągnąć przy surowej szybkości strony. W przypadku połączenia 3G w dowolnym miejscu między 600 ms a 1 s są zużywane przez obowiązkowe koszty ogólne sieci, na które nic nie można poradzić. W oparciu o pożądany czas ładowania strony wynoszący 2 sekundy, daje nam to tylko 1 sekundy do zabawy. To niewiele.

Nie można zaprzeczyć, że surowa szybkość strony jest bardzo ważna i wszyscy programiści powinni przestrzegać co najmniej standardowych najlepszych praktyk.

W tym artykule nie będziemy jednak omawiać, jak przyspieszyć ładowanie strony. Istnieje wiele artykułów na ten temat i wszystko jest trochę techniczne.

Ten artykuł skupi się na postrzeganiu szybkości strony.
Co jest ważniejsze: jak szybko ładuje się strona lub jak szybko postrzega ją użytkownik?

Z pewnością najważniejsza dla użytkownika jest percepcja.

Szybkość witryny: pierwsze wrażenia

Skupmy się na stronie głównej Twojej witryny. Prawdopodobnie zawiera górną nawigację, pasek wyszukiwania, baner bohatera, może linki do kluczowych kategorii, karuzelę i trochę treści. Strony domowe są zwykle dość treściwe, a szybkie ładowanie wszystkich tych treści na połączeniu mobilnym będzie dużym wyzwaniem.

Kluczem jest tutaj nadanie priorytetu ładowaniu treści krytycznych, przed innymi treściami – daj użytkownikowi coś ważnego do zobaczenia tak szybko, jak to możliwe.

Podczas przetwarzania tych krytycznych informacji możesz rozpocząć ładowanie następnej warstwy treści.

Na urządzeniu mobilnym większość treści zaczyna się w części strony widocznej na ekranie i dlatego powinna być wczytywana za treścią w części strony widocznej na ekranie. Powszechną praktyką jest scalanie i minimalizowanie kodu JavaScript. Jest to zwykle postrzegane jako najlepsza praktyka, ale może uniemożliwić priorytetowe ładowanie krytycznego kodu JavaScript przed mniej krytycznym kodem. Zamiast tego możesz rozważyć podzielenie zminifikowanego i scalonego kodu JavaScript i ładowanie go stopniowo, gdy jest to potrzebne. Nie ma potrzeby ładowania kodu JavaScript wymaganego do przeprowadzenia wyszukiwania przed załadowaniem pola wyszukiwania. Użytkownicy nie będą wpisywać znaków w polu wyszukiwania przez co najmniej kilka sekund podczas ładowania strony.

Przyjrzyjmy się witrynie, która robi to bardzo dobrze. Amazon podzielił dostarczanie zasobów i treści, aby zapewnić użytkownikowi jak najszybsze dostarczenie krytycznej zawartości, a następnie stopniowo ładuje zasoby w kolejności priorytetów.

Ten test został przeprowadzony na symulatorze iPhone'a 6 z dobrym połączeniem 3G i wyłączonym buforowaniem. Po wstępnym załadowaniu strony zainicjowałem twarde odświeżenie.

W nieco ponad 600ms coś zaczyna się ładować z moim imieniem w nagłówku. Zauważysz również, że wykonano tylko 6 połączeń sieciowych i załadowano 5 zasobów (3 pliki css i 2 obrazy).

Zaledwie 50 ms później widzę teraz kluczowe elementy nagłówka, a także baner głównego bohatera. Mam już wrażenie szybkości, ponieważ kluczowa treść jest do mnie dostarczana bardzo szybko, a moje oczy i mózg mają coś do przetworzenia podczas ładowania dodatkowych treści.

Po zaledwie 1 sekundzie ładowana jest nawigacja główna. Zauważysz, że na tym etapie nie jest widoczny pasek przewijania. Oznacza to, że w części strony widocznej na ekranie nie ma obecnie żadnej treści. Nie zmarnowano cennego czasu na ładowanie treści, których użytkownik nie może zobaczyć. Zauważysz również, że do tej pory złożono tylko 13 próśb.

W niecałe 2 sekundy mam teraz nową sekcję z ważnymi treściami.

W mniej niż 3 sekundy widzę teraz, że strona została całkowicie załadowana, podczas gdy strona załadowała się w całości w niecałe 5 sekund. Sugeruje to, że postrzegam witrynę jako całkowicie załadowaną, podczas gdy w rzeczywistości jest załadowana tylko w 60%.

Rzeczywisty czas dostarczania treści będzie się różnić w zależności od osoby, ale to bardzo wyraźnie ilustruje, w jaki sposób Amazon priorytetowo traktuje ładowanie treści mobilnych, aby zapewnić, że krytyczne treści są ładowane tak szybko, jak to możliwe, a użytkownicy postrzegają witrynę jako zaczynającą się bardzo szybko ładować.

Teraz spójrzmy na stronę, która nie radzi sobie z tym tak dobrze. Ten test został przeprowadzony przy użyciu dokładnie tych samych narzędzi i szybkości sieci, co poprzedni test Amazon. Chociaż witryna Charlesa Tyrwhitta nadaje priorytet niektórym treściom, można zrobić o wiele więcej, aby zbliżyć się do optymalizacji Amazon.

Nie widzę żadnej treści przez prawie 7,5 sekundy. Od razu wydaje mi się, że ta witryna działa wolno na moim urządzeniu mobilnym. Chociaż witryna traktuje priorytetowo treść nagłówka, a także baner bohatera, można zauważyć, że do tego momentu wysłano ponad 90 żądań i, jak widzę na pasku przewijania, jasne jest, że treść musiała zostać załadowana w części po przewinięciu.

Po 8,5 sekundy widzę, że karuzela zaczyna się ładować. Liczba żądań nie uległa zmianie, co sugeruje, że większość żądań związanych z treścią jest wysyłana już na samym początku ładowania strony.

Dopiero po prawie 22 sekundach zauważam, że strona jest już w pełni załadowana. Całkowite załadowanie strony zajęło w sumie 28,4 sekundy. Sugeruje to, że dostrzegam, iż strona była całkowicie załadowana, podczas gdy w rzeczywistości była załadowana w 77%.

Łatwo zauważyć wyraźną różnicę między tymi dwoma doświadczeniami. Chociaż mobilna strona główna Amazon ładuje się znacznie szybciej niż strona główna Charlesa Tyrwhitta, dołożono starań, aby użytkownicy zauważyli, że jest jeszcze szybsza. Użytkownik zaczyna widzieć, że coś się ładuje w ciągu 12,5% całkowitego czasu ładowania strony, podczas gdy użytkownicy witryny Charles Tyrwhitt widzą, że coś się dzieje tylko w ciągu 26% całkowitego czasu ładowania strony. Strona główna Amazon wykonała 6 żądań sieciowych, zanim użytkownik zobaczy postęp, podczas gdy strona główna Charlesa Tyrwhitta wysłała 90 żądań.

Nie oznacza to zbytniej krytyki Charlesa Tyrwhitta, ponieważ w żadnym wypadku nie są wyjątkowi pod względem sposobu, w jaki zbudowali swoją witrynę internetową. Przyjęta najlepsza praktyka została zastosowana w wielu obszarach, ale wydaje się, że można zrobić znacznie więcej, aby poprawić postrzeganie prędkości, a także prędkości rzeczywistej.

Popraw szybkość witryny, nadając priorytet CSS

Często zdarza się, że programiści front-end umieszczają większość CSS witryny w kilku plikach i zawsze używają zewnętrznego, a nie wbudowanego CSS. Problem, który to powoduje, polega na tym, że przed wyświetleniem użytkownikowi treści należy załadować duży plik css.

Rozwiązaniem tego problemu jest podzielenie plików css i załadowanie ich w kolejności z krytyczną zawartością. Jeśli spojrzymy na przykład Amazona, jako jedno z pierwszych 6 żądań ładują plik css o rozmiarze zaledwie 6,5 tys. Ten plik zawiera css, który jest wymagany do nadania stylu krytycznej treści na ich stronie głównej. W rzeczywistości łączny rozmiar wszystkich plików css, które są wymagane, zanim użytkownik zobaczy treści na mobilnej stronie głównej Amazon, wynosi poniżej 40 tys., podczas gdy na stronie głównej Charlesa Tyrwhitta przekracza 500 tys.

Ta praktyka pozwala na bardzo szybkie dostarczanie krytycznych treści do użytkownika i pomaga wymusić postrzeganie szybkości.

Zrób to samo z JavaScript

Oprócz nadawania priorytetów css, powinieneś rozważyć, jak zrobić to również z JavaScript. Prawie wszystkie witryny e-commerce będą w dużym stopniu polegać na JavaScript, aby funkcjonować. Jest to w porządku, o ile JavaScript nie blokuje ładowania krytycznej zawartości. Jeśli ponownie wezmę przykład ze strony Charlesa Tyrwhitta i wyłączę JavaScript w mojej przeglądarce, widzę teraz ładowanie treści w ciągu 4,5 sekundy. Jest to ogromna zmiana w moim postrzeganiu szybkości tej witryny, a JavaScript, który został załadowany przed treścią krytyczną, nie miał wpływu na tę treść i dlatego nie ma powodu, dla którego JavaScript nie mógł zostać załadowany po tej treści.

Twórcy stron internetowych mogą się wiele nauczyć ze sposobu, w jaki witryny takie jak Amazon skupiają się na postrzeganiu szybkości swojej witryny, a także rzeczywistej szybkości. Chociaż ich strona internetowa jest wyraźnie bardzo szybka, użytkownicy postrzegają ją jako jeszcze szybszą ze względu na sposób, w jaki kładą nacisk na pokazywanie użytkownikom najważniejszych treści przed wszystkim innym.

Wiele wpłynęło na wpływ, jaki prędkość może mieć na współczynnik konwersji, a sprzedawcy powinni rozważyć zainwestowanie w optymalizację postrzeganej wydajności witryny wraz z rzeczywistą prędkością witryny.