Audyt modułów PrestaShop: sprawdzanie, co każdy moduł ładuje na każdej stronie

Dlaczego rozrost modułów jest cichym zabójcą wydajności PrestaShop

Każdy sklep PrestaShop zaczyna szybko. Potem instalujesz pięć modułów, dziesięć modułów, trzydzieści modułów i nagle Twoja strona główna ładuje się cztery sekundy. Winowajcą rzadko jest jeden ogromny moduł. Zamiast tego są to dziesiątki małych modułów, z których każdy dodaje swój własny plik CSS, swój własny plik JavaScript i swoje własne zapytania do bazy danych przy każdym załadowaniu strony. Ten skumulowany ciężar to właśnie rozrost modułów, i jest to główny powód, dla którego sklepy PrestaShop z czasem stają się wolne.

Problem polega na tym, że większość właścicieli sklepów nigdy nie przeprowadza audytu tego, co ich moduły faktycznie ładują. Instalują moduł na etykiety produktów, kolejny na przyciski udostępniania w mediach społecznościowych, kolejny na popup z newsletterem, kolejny na analitykę, i każdy z nich cicho rejestruje się na hookach takich jak displayHeader i actionFrontControllerSetMedia. Nawet jeśli moduł wyświetla treść tylko na stronach produktów, może nadal ładować swoje pliki CSS i JavaScript na stronie głównej, stronach kategorii, w koszyku i w kasie. Oznacza to, że Twoi klienci pobierają zasoby, których nigdy nie wykorzystają na danej stronie.

Prawidłowy audyt modułów ujawnia dokładnie, co każdy moduł wnosi do wagi Twojej strony. Pokazuje, które moduły są największymi winowajcami, które ładują zasoby niepotrzebnie i które możesz zoptymalizować lub całkowicie usunąć. Ten artykuł przeprowadza Cię przez kompletny proces audytu modułów PrestaShop pod kątem wydajności, wykorzystując DevTools przeglądarki, tryb debugowania PrestaShop i systematyczną analizę.

Krok 1: Włączenie trybu debugowania PrestaShop i profilowania wydajności

Zanim otworzysz narzędzia przeglądarki, musisz włączyć wbudowane funkcje profilowania PrestaShop. PrestaShop posiada tryb debugowania, który ujawnia szczegółowe informacje o wykonywaniu hooków, czasach ładowania modułów i zapytaniach do bazy danych. Aby go włączyć, musisz zmodyfikować dwa ustawienia.

Najpierw przejdź do Zaawansowane parametry, następnie Wydajność w panelu administracyjnym. Ustaw Tryb debugowania na Tak. To włącza raportowanie błędów i dodatkowe logowanie, które pomaga identyfikować problematyczne moduły. Jednak prawdziwa moc tkwi w funkcji profilowania.

Aby włączyć pełne profilowanie, musisz edytować plik defines.inc.php znajdujący się w katalogu config PrestaShop. Znajdź linię definiującą _PS_DEBUG_PROFILING_ i ustaw ją na true. W PrestaShop 1.7 i 8.x ta stała kontroluje, czy pasek profilowania pojawia się na dole każdej strony front office. Po włączeniu przeładuj dowolną stronę sklepu, a zobaczysz szczegółowy panel profilowania pokazujący czasy wykonania dla każdego hooka, każdego modułu i każdego zapytania SQL.

Panel profilowania jest podzielony na kilka sekcji. Sekcja hooków pokazuje każdy hook wykonany na bieżącej stronie, które moduły są podpięte do każdego hooka i jak długo każdy moduł wykonywał się. Sekcja SQL pokazuje każde zapytanie do bazy danych, jego czas wykonania oraz który moduł lub funkcja rdzenia je wywołała. Sekcja modułów daje podsumowanie całkowitego czasu wykonania na moduł we wszystkich hookach.

Zwróć szczególną uwagę na kolumnę całkowitego czasu wykonania. Dobrze zoptymalizowany moduł powinien dodawać mniej niż 10 milisekund do ładowania strony. Jeśli widzisz moduł zajmujący 50, 100 czy nawet 500 milisekund, to poważny problem wydajnościowy wymagający zbadania.

Krok 2: Używanie DevTools przeglądarki do mapowania zasobów modułów

Wbudowane profilowanie PrestaShop informuje o wydajności po stronie serwera, ale nie pokazuje pełnego obrazu tego, co dzieje się w przeglądarce. Do tego potrzebujesz narzędzi deweloperskich przeglądarki. Otwórz Chrome lub Firefox, naciśnij F12 i przejdź do zakładki Sieć (Network).

Przeładuj stronę główną z otwartą zakładką Sieć. Zobaczysz każde żądanie wykonywane przez przeglądarkę: HTML, pliki CSS, pliki JavaScript, obrazy, czcionki i wywołania AJAX. Celem jest identyfikacja, które z tych żądań pochodzą z modułów.

W PrestaShop zasoby modułów podążają za przewidywalnym wzorcem URL. Pliki CSS z modułów są zazwyczaj serwowane ze ścieżek takich jak /modules/nazwamodulu/views/css/nazwapliku.css lub /modules/nazwamodulu/css/nazwapliku.css. Pliki JavaScript podążają za tym samym wzorcem z js zamiast css. Użyj paska filtrów w zakładce Sieć, aby filtrować po „modules/" i natychmiast zobaczysz każdy zasób ładowany z zainstalowanych modułów.

Dla każdego znalezionego zasobu modułu zanotuj następujące informacje: nazwę pliku, jego rozmiar (zarówno przesłany, jak i nieskompresowany) oraz czy ładuje się na bieżącym typie strony. Chcesz zbudować arkusz kalkulacyjny lub prostą listę, która mapuje każdy moduł na jego zasoby. Typowy audyt może ujawnić coś takiego: moduł A ładuje dwa pliki CSS o łącznej wielkości 45 KB i jeden plik JavaScript o 120 KB na każdej stronie, ale wyświetla treść tylko na stronach produktów. Oznacza to, że strony kategorii, strona główna i koszyk ładują 165 KB niepotrzebnych zasobów.

Zakładka Sieć pokazuje również widok kaskadowy (waterfall), który ujawnia, kiedy każdy zasób zaczyna się ładować i jak długo to trwa. Zasoby blokujące renderowanie (CSS blokujący renderowanie i synchroniczny JavaScript) są szczególnie szkodliwe, ponieważ uniemożliwiają przeglądarce wyświetlenie jakiejkolwiek treści do czasu ich załadowania. Szukaj plików JavaScript modułów, które ładują się w sekcji head bez atrybutów async lub defer, ponieważ to one najbardziej wpływają na postrzegany czas ładowania.

Krok 3: Analiza kaskady sieciowej per moduł

Widok kaskadowy w DevTools zasługuje na osobną sekcję, ponieważ ujawnia problemy wydajnościowe, których same rozmiary plików nie pokazują. Gdy patrzysz na kaskadę, chcesz zidentyfikować trzy typy problemów.

Po pierwsze, szukaj zasobów blokujących renderowanie pochodzących z modułów. Pojawiają się one jako paski rozpoczynające się wcześnie w kaskadzie i opóźniające zdarzenie pierwszego malowania (pionowa zielona lub niebieska linia). W PrestaShop pliki CSS dodane przez hook displayHeader lub przez addCSS w setMedia zazwyczaj blokują renderowanie. Jeśli moduł dodaje duży plik CSS, który jest potrzebny tylko na konkretnych stronach, blokuje renderowanie na każdej stronie bez powodu.

Po drugie, szukaj łańcuchów sekwencyjnego ładowania. Niektóre moduły ładują plik JavaScript, który następnie wyzwala ładowanie dodatkowych zasobów: kolejnych plików JavaScript, plików CSS, czcionek webowych lub wywołań zewnętrznych API. Każde ogniwo w tym łańcuchu dodaje opóźnienie. Moduł ładujący jQuery UI, następnie motyw CSS jQuery UI, potem niestandardowy skrypt widgetu, a potem CSS widgetu tworzy łańcuch czterech sekwencyjnych żądań, który może zająć od 200 do 400 milisekund nawet przy szybkim łączu.

Po trzecie, szukaj żądań zewnętrznych. Niektóre moduły wykonują wywołania do zewnętrznych serwerów w celu analityki, śledzenia, ładowania czcionek, widgetów mediów społecznościowych lub danych API. Te żądania są szczególnie niebezpieczne, ponieważ nie masz kontroli nad czasem odpowiedzi zewnętrznego serwera. Moduł udostępniania społecznościowego wywołujący API Facebooka, Twittera i Pinteresta przy każdym załadowaniu strony może dodać 500 milisekund lub więcej opóźnienia, a jeśli którykolwiek z tych serwerów jest wolny lub niedostępny, może zablokować całą stronę przed zakończeniem ładowania.

Aby zmierzyć wpływ per moduł, użyj funkcji blokowania w Chrome DevTools. Kliknij prawym przyciskiem myszy na żądanie z konkretnego modułu i wybierz „Block request domain" lub „Block request URL". Następnie przeładuj stronę i porównaj czas ładowania. Daje to bezpośredni pomiar tego, ile zasoby danego modułu wnoszą do całkowitego czasu ładowania strony. Powtórz to dla każdego modułu, aby zbudować ranking od najcięższych do najlżejszych.

Krok 4: Analiza wykonywania hooków

Zrozumienie, których hooków używa każdy moduł, jest kluczowe dla identyfikacji niepotrzebnego ładowania. System hooków PrestaShop to mechanizm, za pomocą którego moduły wstrzykują swoją treść, zasoby i logikę na strony. Najważniejsze hooki pod kątem wydajności dla stron front office to displayHeader, actionFrontControllerSetMedia, displayTop, displayHome, displayFooter, displayProductAdditionalInfo i displayProductListFunctionalButtons.

Hook displayHeader jest najczęściej nadużywanym hookiem w ekosystemie PrestaShop. Moduły rejestrują się na tym hooku, aby dodać swoje pliki CSS i JavaScript do sekcji head strony. Problem polega na tym, że displayHeader uruchamia się na każdej stronie front office. Jeśli moduł rejestruje się na displayHeader bez sprawdzania, którą stronę klient aktualnie przegląda, ładuje swoje zasoby wszędzie.

Aby zobaczyć, które moduły są zarejestrowane na poszczególnych hookach, przejdź do Wygląd, następnie Pozycje w panelu administracyjnym. Ta strona pokazuje każdy hook i każdy moduł do niego podpięty. Sprawdź szczególnie displayHeader i actionFrontControllerSetMedia. Policz, ile modułów jest tam zarejestrowanych. W typowym sklepie z 30 lub więcej zainstalowanymi modułami możesz znaleźć od 15 do 20 modułów na samym displayHeader. Każdy z nich dodaje co najmniej jeden plik CSS lub JavaScript do każdej strony.

Teraz skrzyżuj te dane z wynikami z DevTools. Dla każdego modułu na displayHeader sprawdź, czy ten moduł rzeczywiście musi ładować się na bieżącej stronie. Moduł recenzji produktów potrzebuje swoich zasobów tylko na stronach produktów. Moduł listy życzeń potrzebuje swoich zasobów tylko na stronach produktów i konta. Moduł tabeli rozmiarów potrzebuje swoich zasobów tylko na stronach produktów. A mimo to wszystkie ładują się na stronie głównej, stronach kategorii, stronach CMS i w procesie składania zamówienia.

Dane profilowania z kroku 1 dodają kolejny wymiar do tej analizy. Niektóre moduły nie tylko ładują niepotrzebne zasoby, ale także wykonują kosztowny kod PHP przy każdym wywołaniu hooka. Moduł, który uruchamia zapytania do bazy danych w swojej metodzie hookDisplayHeader, aby sprawdzić wartości konfiguracyjne lub pobrać dane, marnuje zasoby serwera na każdej stronie, nawet gdy jego wynik nie jest potrzebny.

Krok 5: Identyfikacja najcięższych modułów

Mając dane z profilowania, DevTools i analizy hooków, możesz teraz uszeregować moduły według ich wpływu na wydajność. Utwórz listę z następującymi kolumnami: nazwa modułu, liczba ładowanych plików CSS, łączny rozmiar CSS, liczba ładowanych plików JavaScript, łączny rozmiar JavaScript, czas wykonania serwera z profilowania, liczba zapytań do bazy danych oraz strony, na których moduł faktycznie wyświetla treść.

Moduły, które uzyskują najwyższe wyniki w tych metrykach, są Twoimi największymi winowajcami. Z naszego doświadczenia w audytowaniu setek sklepów PrestaShop wynika, że następujące kategorie modułów są konsekwentnie najgorszymi pod względem wydajności.

Moduły budowania stron (page builder) są często najcięższe. Ładują duże frameworki CSS, wiele bibliotek JavaScript dla swojego edytora wizualnego, a czasem nawet ładują zasoby edytora na front office. Page builder ładujący 300 KB CSS i 500 KB JavaScript na każdej stronie nie jest niczym niezwykłym.

Moduły mediów społecznościowych osadzające widgety z Facebooka, Instagrama czy Twittera ładują zewnętrzne skrypty, które są zarówno duże, jak i nieprzewidywalne pod względem czasu ładowania. Pojedynczy widget kanału Instagram może dodać 1 MB lub więcej JavaScript do Twojej strony.

Moduły analityki i śledzenia korzystające z wielu pikseli śledzących ładują skrypty z zewnętrznych domen. Każdy piksel śledzący zazwyczaj dodaje od 20 do 50 KB JavaScript plus dodatkowe żądania sieciowe dla obrazów pikseli i wywołań API.

Moduły sliderów i karuzel ładują duże biblioteki JavaScript, takie jak Slick, Owl Carousel czy Swiper, wraz z ich CSS. Nawet jeśli slider pojawia się tylko na stronie głównej, zasoby często ładują się na każdej stronie.

Moduły czatu na żywo ładują znaczące paczki JavaScript dla interfejsu widgetu czatu, zazwyczaj od 100 do 300 KB, plus nawiązują połączenia WebSocket, które zużywają zasoby przez całą sesję przeglądania.

Krok 6: Pomiar wydajności przed i po zmianach

Zanim zaczniesz wyłączać hooki lub usuwać moduły, ustal bazowy pomiar. Użyj wielu narzędzi, aby uzyskać pełny obraz.

W Chrome DevTools przejdź do zakładki Lighthouse i uruchom audyt wydajności. Zapisz Wynik Wydajności, First Contentful Paint (FCP), Largest Contentful Paint (LCP), Total Blocking Time (TBT) i Cumulative Layout Shift (CLS). Uruchom audyt trzy razy i uśrednij wyniki, aby uwzględnić zmienność.

Użyj zakładki Wydajność (Performance) w DevTools, aby nagrać ślad ładowania strony. Daje to wykres płomieni pokazujący dokładnie, co przeglądarka robi w każdej milisekundzie. Szukaj długich zadań (bloków dłuższych niż 50 milisekund) i identyfikuj, które skrypty modułów je powodują.

Zmierz również wagę strony. W zakładce Sieć sprawdź łączną liczbę żądań i łączny przesłany rozmiar na dole panelu. Filtruj po CSS i JS osobno, aby uzyskać sumy specyficzne dla modułów.

Zapisz wszystkie te liczby przed wprowadzeniem jakichkolwiek zmian. Następnie, w miarę optymalizowania modułów przez odpinanie ich od niepotrzebnych hooków lub całkowite wyłączanie, ponownie uruchom te same pomiary. Różnica powie Ci dokładnie, ile wydajności zyskałeś z każdej zmiany.

Dobrze przeprowadzony audyt modułów zazwyczaj redukuje wagę strony o 30 do 50 procent i poprawia czasy ładowania o jedną do dwóch sekund. W sklepach z wieloma słabo zoptymalizowanymi modułami poprawa może być jeszcze bardziej dramatyczna.

Krok 7: Wyłączanie niepotrzebnych hooków

Gdy już zidentyfikujesz, które moduły ładują zasoby na stronach, gdzie nie są potrzebne, masz kilka opcji optymalizacji. Najprostszym podejściem jest odpięcie modułów od hooków, na których nie muszą być obecne.

Przejdź do Wygląd, następnie Pozycje w panelu administracyjnym. Znajdź moduł na hooku, z którego chcesz go usunąć. Kliknij ikonę kosza lub przycisk odpięcia, aby usunąć moduł z tego konkretnego hooka. To zapobiega wykonywaniu modułu na tym hooku całkowicie.

Jednak zachowaj ostrożność z tym podejściem. Niektóre moduły używają displayHeader nie tylko do ładowania CSS i JavaScript, ale także do wykonywania niezbędnych zadań inicjalizacyjnych. Odpięcie takiego modułu od displayHeader może zepsuć jego funkcjonalność na stronach, gdzie jest rzeczywiście potrzebny. Zawsze testuj w środowisku stagingowym lub co najmniej przetestuj konkretne strony, na których moduł powinien nadal działać po odpięciu.

Lepszym długoterminowym podejściem jest skontaktowanie się z deweloperem modułu i poproszenie o warunkowe ładowanie zasobów. Dobrze zakodowany moduł powinien sprawdzać bieżący kontroler lub typ strony przed załadowaniem swoich zasobów. Na przykład moduł recenzji produktów powinien ładować swoje CSS i JavaScript tylko wtedy, gdy bieżący kontroler to ProductController. W ten sposób moduł pozostaje podpięty do displayHeader dla kompatybilności, ale ładuje zasoby tylko wtedy, gdy są faktycznie potrzebne.

Jeśli czujesz się komfortowo edytując kod modułu, możesz samodzielnie dodać warunkowe sprawdzenia. W metodzie hookDisplayHeader lub hookActionFrontControllerSetMedia modułu dodaj sprawdzenie nazwy bieżącego kontrolera. Jeśli kontroler nie jest tym, na którym moduł wyświetla treść, zakończ funkcję wcześniej bez dodawania jakichkolwiek zasobów. To najbardziej celowa i efektywna optymalizacja, jaką możesz wykonać.

Praktyczna lista kontrolna audytu modułów

Podsumowując cały proces audytu, oto praktyczna lista kontrolna, którą możesz stosować. Zacznij od włączenia profilowania debugowania PrestaShop. Otwórz zakładkę Sieć w DevTools i przeładuj stronę główną. Filtruj żądania po ścieżce modules i wylistuj każdy zasób modułu. Zanotuj rozmiar i typ każdego zasobu. Sprawdź Wygląd, następnie Pozycje pod kątem modułów na displayHeader. Skrzyżuj rejestracje hooków z miejscami, gdzie moduły faktycznie wyświetlają treść. Użyj blokowania żądań w DevTools, aby zmierzyć wpływ per moduł. Zapisz bazowe wyniki Lighthouse. Odpnij moduły od hooków, na których nie są potrzebne. Dodaj warunkowe ładowanie do modułów ładujących się globalnie. Ponownie zmierz wyniki Lighthouse po każdej zmianie. Udokumentuj swoje ustalenia i zmiany na przyszłość.

To systematyczne podejście zapewnia, że nie przegapisz żadnych możliwości optymalizacji i daje konkretne dane uzasadniające każdą wprowadzoną zmianę. Rozrost modułów nie jest tajemnicą. To mierzalny, rozwiązywalny problem, a każdy sklep PrestaShop korzysta z dokładnego audytu modułów przynajmniej raz w roku.