Skrypty, style i czcionki: co blokuje wyświetlenie sklepu

Optymalizacja skryptów PrestaShop zaczyna się od rozpoznania, że przeglądarka nie wyświetla strony, dopóki nie pobierze i nie przetworzy zasobów uznanych za blokujące. Style i część skryptów należą do tej kategorii z definicji. Sklep może mieć szybki serwer i lekkie zdjęcia, a klient i tak patrzy na biały ekran, bo trwa pobieranie arkusza stylów z obcego serwera albo kroju pisma, którego nikt już nie używa.

Ten obszar różni się od pozostałych jedną rzeczą: większość zbędnych zasobów nie została dołożona przez wykonawcę technicznego, tylko narosła przez lata z decyzji marketingowych. Dlatego jego uporządkowanie zaczyna się od rozmowy, a nie od kodu.

Co blokuje wyświetlenie strony

Trzy rodzaje zasobów zatrzymują renderowanie i każdy wymaga innego podejścia.

Do tego dochodzi kategoria czwarta, która nie blokuje wyświetlenia, ale psuje reakcję strony na dotyk: skrypty wykonujące długie operacje po załadowaniu. Klient widzi gotową stronę, dotyka przycisku i nic się nie dzieje, bo przeglądarka jest zajęta. Mierzy to wskaźnik INP, którego próg wynosi 200 ms, a definicję opisuje dokumentacja Google na web.dev.

Optymalizacja skryptów PrestaShop zaczyna się od inwentaryzacji

Zanim cokolwiek zmienisz, zrób listę. Otwórz kartę produktu w narzędziach deweloperskich, w zakładce z zasobami, i odfiltruj skrypty oraz style. Zapisz trzy rzeczy przy każdej pozycji: skąd pochodzi, ile waży i czy jest potrzebna na tej stronie.

Wynik dzieli się zwykle na cztery grupy.

• Rdzeń sklepu i motyw. Potrzebne, zostają. Warto sprawdzić, czy nie ładują się w kilku kopiach, co zdarza się po zmianie motywu.
• Moduły. Tu zaczyna się praca. Moduł obsługujący wyłącznie checkout dokładający swoje pliki do strony głównej to przypadek podręcznikowy.
• Narzędzia zewnętrzne. Analityka, piksele, czat, mapy ciepła, narzędzia do testów. Każde dokłada połączenie do obcego serwera.
• Pozostałości. Skrypt kampanii sprzed dwóch lat, biblioteka po module, który już nie istnieje, krój pisma z poprzedniego projektu graficznego.

Przy każdym narzędziu zewnętrznym zadaj dwa pytania: kto po stronie firmy jest jego właścicielem i na jakie pytanie ono odpowiada. Pozycje bez właściciela wychodzą. To najprostszy sposób, żeby rozmowa o usuwaniu skryptów nie zamieniła się w spór o to, czy dane są ważne.

Łączenie i kompresja w ustawieniach PrestaShop

PrestaShop ma wbudowane opcje łączenia oraz kompresji plików stylów i skryptów. To pierwsza rzecz do włączenia, bo zmniejsza liczbę żądań i wagę transferu bez ingerencji w kod. Bywa wyłączona, bo ktoś kiedyś diagnozował problem i nie wrócił do ustawień.

Włączenie tych opcji ma jednak konsekwencję, o której trzeba wiedzieć zawczasu: łączenie plików potrafi rozłożyć funkcje zależne od kolejności wykonania skryptów. Najczęściej cierpią konfigurator produktu, wybór punktu odbioru w checkoucie i widżety zewnętrzne.

Procedura, która oszczędza cofanie zmian: włącz opcje na środowisku testowym, przejdź pełną ścieżkę zakupową od wyszukania produktu po płatność testową, sprawdź konsolę błędów przeglądarki na każdym kroku. Dopiero potem produkcja. Sprawdzanie samej strony głównej niczego nie dowodzi, bo najbardziej złożone skrypty żyją w checkoucie.

Jeśli łączenie psuje konkretną funkcję, nie rezygnuj z całej opcji. PrestaShop pozwala wykluczyć pojedyncze pliki z łączenia, więc problematyczny skrypt zostaje osobno, a reszta korzysta z optymalizacji.

Czcionki, o których nikt nie pamięta

Czcionki firmowe są traktowane jak element identyfikacji wizualnej, a zachowują się jak zasób blokujący. Domyślnie przeglądarka wstrzymuje wyświetlenie tekstu do momentu pobrania pliku kroju, więc klient patrzy na stronę bez treści, mimo że treść jest już gotowa.

Cztery zmiany, każda niezależna od pozostałych:

• Zastępcza czcionka systemowa na czas pobierania. Tekst wyświetla się od razu krojem systemowym i podmienia po pobraniu pliku. Krótkie mrugnięcie jest lepsze niż pusty ekran.
• Ograniczenie liczby odmian. Sklepy potrafią ładować sześć grubości jednego kroju, używając dwóch. Każda odmiana to osobny plik.
• Zawężenie zestawu znaków. Krój obsługujący wszystkie alfabety świata jest wielokrotnie cięższy niż wersja z alfabetem łacińskim i polskimi znakami.
• Serwowanie z własnego serwera. Skraca ścieżkę o połączenie z obcym hostem i upraszcza kwestie zgód, bo przeglądarka nie odpytuje wtedy serwera spoza sklepu.

Ostatni punkt bywa niedoceniany. Połączenie z zewnętrznym dostawcą czcionek wymaga rozwiązania nazwy, nawiązania połączenia i negocjacji szyfrowania, zanim w ogóle zacznie się pobieranie pliku. Przy pierwszym wejściu na stronę to zauważalny koszt.

Skrypty zewnętrzne i ich prawdziwy koszt

Kody analityczne, piksele reklamowe, czat, narzędzia do testów i mapy ciepła narastają latami. Każdy z osobna wydaje się lekki, a razem potrafią przewyższyć wagę całego motywu.

Koszt ma trzy składniki, z których widoczny jest tylko pierwszy:

• Waga pliku. To, co widać w narzędziach deweloperskich.
• Połączenie z obcym serwerem. Każdy dodatkowy host to osobne rozwiązanie nazwy i osobne nawiązanie połączenia, płacone przy pierwszym wejściu.
• Czas wykonania. Skrypt śledzący ruch myszy albo nagrywający sesję pracuje przez cały czas wizyty i konkuruje o procesor z interfejsem sklepu. To najczęstsza przyczyna złego wyniku INP.

Praktyczne rozstrzygnięcia. Skrypty analityczne wczytuj asynchronicznie, żeby nie wstrzymywały renderowania. Narzędzia nagrywające sesje włączaj na czas badania i wyłączaj po nim, zamiast trzymać na stałe. Czat rozważ jako element doładowywany po interakcji, a nie razem ze stroną: klient, który chce napisać, kliknie w ikonę i poczeka sekundę, a pozostali nie zapłacą za bibliotekę, której nie użyli.

Osobno warto sprawdzić menedżer tagów, jeśli sklep go używa. Bywa workiem, do którego przez lata wrzucano wszystko, i potrafi ładować kody kampanii zakończonych dawno temu. Przegląd jego zawartości należy do tej samej pracy.

Jak wycenić koszt pojedynczego skryptu

Dyskusja „ten piksel jest nam potrzebny” nie ma rozstrzygnięcia, dopóki nikt nie zna jego ceny. Pomiar jest prosty i nie wymaga specjalistycznych narzędzi.

1. Zmierz czas wyświetlenia i wskaźnik reakcji na karcie produktu, ze spowolnionym procesorem w narzędziach deweloperskich.
2. Zablokuj wybrany skrypt w narzędziach deweloperskich i powtórz pomiar w tych samych warunkach.
3. Różnica jest ceną tego skryptu.

Powtórzone dla wszystkich narzędzi zewnętrznych daje ranking, który zamienia dyskusję o przekonaniach w rozmowę o liczbach. Zdarza się, że jedno narzędzie odpowiada za większość kosztu, a pozostałe pięć jest w granicach błędu pomiaru. Wtedy decyzja jest łatwa.

Do rankingu warto dołożyć drugą kolumnę: kto z tego korzysta i jak często. Narzędzie kosztowne, ale używane codziennie przez dział marketingu, zostaje. Narzędzie tanie, do którego nikt nie zaglądał od pół roku, wychodzi mimo niskiego kosztu, bo każdy zbędny zasób to jedno połączenie więcej i jedna rzecz więcej do utrzymania.

Długie zadania i reakcja na dotyk

Wskaźnik INP mierzy coś, czego nie widać w wadze plików: czas od dotknięcia elementu przez klienta do zobaczenia efektu. Strona może być w pełni wyświetlona i nadal nie reagować, bo przeglądarka wykonuje długie zadanie w tle.

Przeglądarka wykonuje kod w jednym wątku. Skrypt pracujący nieprzerwanie blokuje obsługę dotknięć na cały ten czas. Na komputerze bywa to niezauważalne, na telefonie z wolniejszym procesorem ta sama operacja trwa wielokrotnie dłużej i zamienia się w wrażenie zawieszonego sklepu.

Typowe źródła długich zadań w sklepie:

• Narzędzia nagrywające sesje i mapy ciepła. Śledzą ruch wskaźnika i przewijanie przez cały czas wizyty.
• Karuzele i suwaki. Zwłaszcza uruchamiane automatycznie i przeliczające układ przy każdej zmianie slajdu.
• Filtry przeliczane w przeglądarce. Rozwiązanie kuszące, bo szybkie w odbiorze, ale przy dużym katalogu przenoszące koszt na urządzenie klienta.
• Skrypty reklamowe. Często wykonują pracę niezwiązaną z niczym, co klient robi w sklepie.

Diagnoza: w narzędziach deweloperskich nagraj profil wydajności podczas wchodzenia na kartę produktu i przewijania. Długie zadania są tam zaznaczone i pokazują, który skrypt je wywołał. To jedyny sposób, żeby odróżnić winowajcę od zbiegu okoliczności.

Co ładować warunkowo

Zasada porządkująca cały ten obszar brzmi: zasób potrzebny na jednej stronie nie powinien ładować się na wszystkich. W PrestaShop moduły deklarują swoje pliki przez mechanizm rejestracji zasobów i mogą robić to warunkowo, w zależności od aktualnego kontrolera. Wiele modułów tego nie robi, bo autorowi łatwiej dołożyć pliki globalnie.

Typowe przypadki do rozdzielenia:

• skrypty checkoutu ładowane na całym sklepie
• biblioteka galerii obecna na stronach informacyjnych, gdzie nie ma żadnej galerii
• obsługa konfiguratora produktu wczytywana na listingach
• style panelu klienta serwowane niezalogowanym odwiedzającym

Zmiany w tej warstwie dotykają kodu modułów, więc wymagają środowiska testowego i kontroli wersji. Zasady rejestrowania zasobów przez moduły opisuje dokumentacja deweloperska PrestaShop. Sposób oceny, czy dany moduł zarabia na swój koszt, rozkładamy w tekście o optymalizacji modułów PrestaShop.

Baner zgód a wydajność

Mechanizm zbierania zgód jest w sklepach obowiązkowy i jednocześnie bywa jednym z cięższych elementów strony, bo ładuje się na każdym wejściu, przed treścią i z priorytetem. Warto go przejrzeć przy tej samej okazji co resztę zasobów.

Trzy rzeczy, które robią różnicę. Po pierwsze, sam baner powinien być lekki i wyświetlać się bez pobierania zewnętrznej biblioteki, jeśli to możliwe. Po drugie, skrypty warunkowane zgodą mają uruchamiać się dopiero po jej udzieleniu, a nie ładować się z góry i czekać. Po trzecie, baner nie może przesuwać treści po wyświetleniu, bo wtedy psuje wskaźnik stabilności układu na każdym pierwszym wejściu.

Ta ostatnia rzecz jest częsta i łatwa do przeoczenia, bo zespół widzi baner tylko raz, zanim przeglądarka zapamięta wybór. Sprawdzaj go w oknie prywatnym, tak jak widzi go nowy klient.

Kod motywu i pozostałości po przebudowach

Osobna warstwa, o której rzadko się mówi, bo nie ma właściciela po stronie marketingu. Motyw sklepu przechodzi przez lata kilka przebudów i po każdej zostaje osad: reguły stylów dla elementów, których już nie ma, biblioteka dołożona pod jedną funkcję i nieusunięta po jej wycofaniu, drugi zestaw ikon obok pierwszego.

Objaw jest mierzalny: arkusz stylów o rozmiarze wyraźnie większym, niż wynikałoby ze złożoności sklepu, i skrypty, których nazw nikt w firmie nie rozpoznaje. Diagnoza polega na sprawdzeniu, jaki procent reguł stylów jest w ogóle używany na kluczowych szablonach. Narzędzia deweloperskie przeglądarki mają do tego osobną zakładkę pokazującą pokrycie kodu.

Uprzątanie tej warstwy wymaga wykonawcy technicznego i środowiska testowego, bo usunięcie reguły, która wygląda na nieużywaną, potrafi rozłożyć widok, na który nikt nie zajrzał podczas testów. Dlatego pracuje się tu partiami, z pełnym przejściem ścieżki zakupowej po każdej z nich, a nie jednym dużym porządkiem.

Warto tę pracę zaplanować przy okazji zmiany motywu albo większej przebudowy, bo wtedy i tak dotykasz tych plików. Robiona osobno, bez innego powodu, rzadko wygrywa z pilniejszymi zadaniami.

Jedna zasada, która porządkuje cały obszar

Wszystkie powyższe działania sprowadzają się do jednego pytania zadawanego przy każdym zasobie: czy klient potrzebuje tego, żeby zobaczyć i kupić produkt na tej konkretnej stronie. Odpowiedź „tak” oznacza ładowanie normalne i priorytetowe. „Tak, ale później” oznacza wczytywanie asynchroniczne albo po interakcji. „Nie” oznacza usunięcie albo warunkowe ładowanie tylko tam, gdzie zasób jest potrzebny.

Test jest brutalnie prosty i działa też na spotkaniach: jeśli nikt nie potrafi powiedzieć, co dany skrypt robi i kto z niego korzysta, to jest odpowiedź „nie”. Zasób bez właściciela nie ma obrońcy, a każdy taki element kosztuje przy każdym wyświetleniu strony przez każdego klienta.

Kolejność prac i weryfikacja

Od najtańszego do najdroższego, z zaznaczeniem, co wymaga wykonawcy technicznego.

Po każdym kroku sprawdź trzy rzeczy: czy strona nadal wygląda tak samo, czy konsola przeglądarki nie zgłasza błędów i czy pełna ścieżka zakupowa przechodzi bez zacięć. Wskaźniki porównuj z realnego ruchu po kilku dniach, nie z pojedynczego testu bezpośrednio po zmianie.

Jeśli po uporządkowaniu zasobów strona nadal wyświetla się z opóźnieniem, przyczyna leży wcześniej. Wtedy patrzysz na czas odpowiedzi serwera PrestaShop albo na wagę zdjęć, czyli na optymalizację obrazów PrestaShop. Całość, wraz z kolejnością obszarów, porządkuje przewodnik o optymalizacji PrestaShop, a usługowo ten zakres zamyka optymalizacja wydajności PrestaShop.