Proud Media

Optymalizacja sklepów Prestashop

To nie jest kolejny artykuł opisujący podstronę konfiguracji PrestaShop. tutaj skupiliśmy się na technicznym aspekcie w głębinach Presty!

Setki realizacji, tysiące rozwiązanych problemów

Skontaktuj się już teraz!

Kontakt

Optymalizacja sklepów Prestashop 1.7 – SEO oraz przyspieszenie

2013 – to rok, w którym rozpoczęliśmy realizację projektów opartych o niebiański silnik sklepów internetowych PrestaShop. Już wtedy okazało się że coś nie do końca jest okej. Problemem okazał się czas ładowania strony internetowej. A niesie to za sobą kilka poważnych konsekwencji. Po pierwsze – długi czas ładowania (kręcącego się kółeczka u góry przeglądarki od momentu wpisania np. www.sklep-kocham-preste.pl do czasu wyświetlenia sklepu) powoduje zwiększenie współczynnika odrzuceń (z ang. Bounce rate). Po prostu chcąc kupić np. wielkiego różowego słonika czekając 5s na załadowanie się sklepu – potencjalny klient przejdzie do konkurencji.

Kolejnym aspektem jest Google i jego miłość do turbo stron. Oczywiście nie przesadzając z AMP i PageSpeed, lecz im dłuższy i „cięższy” load time tym gorzej w serpach czyli wynikach wyszukiwania. Efekt zadowalający oznacza że pierwsza odpowiedź serwera z HTML strony zostanie dostarczona do przeglądarki w czasie mniejszym niż 0.5 – 1s. Wynik powyżej oznacza że coś należy zmienić.

Optymalizację sklepu internetowego możemy podzielić na kilka segmentów:

Optymalizacja SEO – meta treści, opisów – Nie zajmujemy się tym aspektem!
Optymalizacja zdjęć
Optymalizacja wtyczek i konfiguracji Presty
Optymalizacja PHP, TMPFS, Bazy danych
Optymalizacja infrastruktury serwerowej

Bez owijania w bawełnę – poniżej przedstawiona treść techniczna jest skomplikowana i wymaga doświadczenia. Oczywiście nie odkryliśmy tutaj wszystkich tajników i metod naszej pracy.

Więc jeżeli poszukujesz eksperta ds. przyspieszenia sklepu opartego o PrestaShop – skontaktuj się!

Wspieramy wiele dużych projektów o zasięgu krajowym opartych o PS 1.7. Niestety nie możemy pochwalić się od tak markami gdyż zawieramy z klientami Umowy NDA o zachowaniu poufności.

Jesteśmy zgodni z RODO więc przed przystąpieniem do prac przekazujemy poniższe dokumenty:

Umowa o wykonanie Audytu, a następnie ewentualną usługę optymalizacji
Umowa powierzenia danych osobowych
Umowa zachowania poufności

Jak wygląda proces optymalizacji czasu ładowania się sklepu?

Zawarcie stosownych umów
Wykonanie audytu i przygotowanie wyceny
Po akceptacji wyceny, przygotowanie projektu zmian
Wdrożenie projektu zmian
Testy sklepu internetowego
Deploy „na produkcję”

Tak więc przechodzimy do konkretów 😊 Życzę miłej lektury i optymalizacji czasów ładowania w Twoim sklepie.

Wymagania PrestaShop w wersji 1.7.x

Na początku kilka banałów – ale i one są ważne. Poniżej przedstawiamy podstawowe wymagania techniczne sklepu na PrestaShop by Filipczyk.net.

Paczki PHP: php-intl, php-mcrypt, php-openssl, php-zip, php-xml, php-curl, php-gd, php-pdo, php-opcache, php-fileinfo

Konfiguracja php.ini:

max_input_vars = 20000
upload_max_filesize = 256M
memory_limit = 512M
zend_extension = /$sciezka_do_katalogu$/ioncube_loader_lin_$wersja_php$.so
allow_url_fopen = On
max_execution_time = 40s (dla klientów) 600s (dla backend i wtyczek cron) [Można to zrobić edytując php_vars używając pliku jakiegoś pliku .php który będzie załadowany przez sklep]
realpath_cache_size=1M
realpath_cache_ttl=86400
zlib.output_compression = On
opcache.enable=1
opcache.memory_consumption=1024
opcache.interned_strings_buffer=64
opcache.max_accelerated_files=20000
opcache.revalidate_freq=10

Wersja PHP: najlepiej 7.2 – fcgi lub fpm (w przypadku zastosowania PHP-FPM należy odpowiednio skonfigurować dostosowując do możliwości technicznych serwera)
Serwer www: Apache 2.2+, nginx
System operacyjny: Linux najlepiej Debian/CentOS/Ubuntu Server

W aspekcie konfiguracji polecam połączenie PHP-FPM z NGINX.
Uważam, że nie ma sensu przepisywać doskonałego w tym aspekcie poradnika dostępnego pod tym adresem: https://www.if-not-true-then-false.com/2011/nginx-and-php-fpm-configuration-and-optimizing-tips-and-tricks/

LiteSpeed web server Enterprise wraz z wtyczką LSCache – świetne rozwiązanie pozwalające zrealizować pamięć statyczną z podstronami w formie HTML – jeżeli chcesz dowiedzieć się więcej – skontaktuj się z nami.

Instancja single server / muli server / cloud

Bardzo ważną kwestią jest wybór infrastruktury serwerowej w ramach której będzie pracować nasz sklep internetowy. Rozwiązań jest kilka i każde ma swoje minusy oraz plusy.

Nazwa rozwiązania	Średni koszt miesięczny	Maksymalna ilość klientów w 1 momencie	Awaryjność 1-min 10-max	Zastosowanie
Hosting klasyczny SSD	30zł	5	7	Bardzo małe sklepy. Można wykorzystać w czasie budowy projektu.
Hosting dedykowany PS	80zł	15	3	Małe sklepy internetowe.
Serwer VPS low cost	40zł	10	5	Małe sklepy internetowe.
Serwer VPS premium	150zł	30	3	Małe/średnie sklepy.
Serwer dedykowany	350zł	100-500	2	Dopiero takie rozwiązanie pozwoli oprzeć się naporowi np. porządnej kampanii sms/email.
Rozwiązanie public cloud wielo-instancyjne	800zł+	Brak ograniczeń	1	Rozwiązanie topowe dla dużych graczy gdzie czas ładowania i dostępność to priorytet.

Rozwiązania zaprezentowane na powyższej tabeli można podzielić ze względu na 2 podstawowe czynniki (pomijamy shared hosting):

1 serwer = [baza, php, apache w jednym] – Warto wykorzystać WAF po kroju Cloud Flare
Klaster = Najlepiej opisze to poniższy artykuł https://zaufanatrzeciastrona.pl/post/budujemy-klaster-serwerow-www-z-load-balancerem-w-chmurze/

Jeżeli Twój sklep rośnie to i Twoje zaplecze techniczne musi rosnąć. Nie można w tym aspekcie oszczędzać pieniędzy.

Zawsze na czasie

Nie stoimy w miejscu. Ciągle wdrażamy nowe technologie i poszerzamy swoje horyzonty

Obsługa klienta

Z sukcesami tworzymy całościowe strategie dla marketingu w internecie

Jakość i precyzja

Do każdego klienta podchodzimy indywidualnie. Działamy w imię zasady jakość ponad ilość

Profilowanie oraz debugowanie PrestaShop (sprawdzanie wydajności) – Czyli cholerne wtyczki

Bardzo często klienci zgłaszający się do nas mają już jakąś firmę/agencję, która wykonuje dla nich sklep i potrzebują naszej pomocy. Dlaczego? Ponieważ świeży sklep ładuje się długo. Serwer mieli, mieli i mieli bardzo długo.

Co w takim wypadu? Co robić? Jak żyć?

Programiści projektu PrestaShop https://github.com/PrestaShop zadbali o możliwość badania „co w trawie piszczy”. Wystarczy zmodyfikować kilka linijek kodu w pliku: /home/sklep/public_html/config/defines.inc.php. Interesuje nas:

define('_PS_MODE_DEV_', true);
define('_PS_DEBUG_PROFILING_', true);
Możemy też użyć prostego instrukcji warunkowej if - w taki sposób tylko my będziemy mieć podgląd do trybu profilowania.
define('_PS_MODE_DEV_', $_SERVER['REMOTE_ADDR'] == '127.0.0.1');
define('_PS_DEBUG_PROFILING_', $_SERVER['REMOTE_ADDR'] == '127.0.0.1');

Czego możemy się dowiedzieć używając trybu profilowanie?

Czas ładowania strony przez interpreter PHP
Czas zapytań do bazy danych SQL
Ilość zapytań do bazy danych
Ilość załadowanych plików do wykonania strony wraz z ich objętością
Informacje o podstawowej konfiguracji serwera
Tabelka z podziałem na poszczególne sekcje ładowania presty – co ile i jak długo obciąża ładowanie – tutaj łatwo zauważyć że kluczowym aspektem jest initContent oraz display
Analiza dokładnie wszystkich zapytań SQL oraz składowych, z których powstaje widok

Największą uwagę należy jednak poświęcić elementowi nr 7 i dostosować go w taki sposób zaprezentowany poniżej.

W poniższym przykładzie widać że wtyczka POS Mega Menu (składowa zakupionego szablonu) powoduje najdłuższe czasowe obciążanie dla serwera realizując zapytanie SQL:

Nie będę komentował kunsztu programistycznego „POS” – przemilczę tą kwestię. Dzięki temu narzędziu można łatwo odkryć co powoduje długi czas ładowania i prawdopodobnie w Twoim sklepie powoduje to jakaś wtyczka integracji z Allegro albo moduł nawigacji fasetowej (oj to jest zmora PS). Często zajmujemy się przepisywaniem oraz optymalizowaniem wtyczek tworzonych przez agencje/firmy. Nie tylko w aspekcie poprawienia prędkości ładowania. Zdarzyło się również że odkryliśmy błąd w pewnej polskiej oficjalnej wtyczce integrującej z systemem mikropłatności. Do dnia dzisiejszego większość naszych klientów działa właśnie na starej wersji która została załatana przez nas w taki sposób aby nie dało się wykonać oszukanej płatności. Dostawca oficjalnego modułu dopiero po kilku tygodniach załatał dziurę.

(Eksperymentalne rozwiązanie) Dla optymalizacji zdjęć warto wykorzystać mod_pagespeed

Zdjęcia i ich optymalizacja są bardzo ważną kwestią. Im mniej KB zajmują tym lepiej. Natomiast nie wolno przesadzić gdyż „pixeloza” wygląda dla potencjalnego klienta po prostu źle. Aspekt pierwszy – Zweryfikuj czy rozdzielczości wyświetlanych zdjęć na sklepie są zbieżne z:

Nie jest mądre aby pokazywać miniaturkę 300x300px z pliku 1920x1080px. Jeżeli będzie potrzebne to zmodyfikuj pliki .tpl w taki sposób aby wyświetlać poprawne wersje.

Aspekt drugi – Ustaw optymalną dla Google kompresję JPEG oraz PNG np.

Ciekawym pomysłem jest wykorzystanie CDN (zobacz niżej) albo mod_pagespeed zainstalowany w „silnik” serwera Apache2 lub NGINX.

Skrócona instrukcja mod_pagespeed

Instalacja: https://developers.google.com/speed/pagespeed/module/download?hl=pl
Przykładowy plik konfiguracyjny: https://pastebin.com/3eiNcQUb
Przykładowa dodatkowa konfiguracja do .htaccess dla Presty do głównego katalogu: https://pastebin.com/HNSZr6Jj
Pamiętaj aby w .htaccess dla katalogu admina zablokować usługę: https://pastebin.com/vcfSZxeh

Ustawienia bazy danych są niewątpliwie kluczowe w kooperacji z sklepem PS np. w wersji 1.7. Dlatego też należy:

Pilnować aby wszystkie tabele sklepu były oparte o InnoDB (czasem po migracjach może coś pozostać jako MyISAM)
Zmodyfikować plik konfiguracyjny MySQL:
1. innodb_buffer_pool_size: minimum 512GB (im więcej tym lepiej)
2. innodb_thread_concurrency: 2 * [ilość rdzeni CPU] + 2
3. query_cache_size: minimum 64MB (im więcej tym lepiej)
4. query_cache_limit: 2MB (im więcej tym lepiej)
Cyklicznie wykorzystać dobrodziejstwo wtyczki Ps Cleaner https://github.com/PrestaShop/pscleaner i usuwać nadmiarowe niepotrzebne śmieciowe dane https://screen.proudmedia.eu/v3randbase873ye4rfhgjfitre4837wyerdfgh/chrome_2019-07-04_14-40-38.jpg
Ciekawym rozwiązaniem jest wyłączenie modułu – kopalnia danych dla statystyk – https://screen.proudmedia.eu/v3randbase873ye4rfhgjfitre4837wyerdfgh/chrome_2019-07-04_14-41-12.jpg może to dać kilka cennych ms czasu ładowania sklepu
Zapoznać się z Preferencje/Ruch i metodą zapisywania danych https://screen.proudmedia.eu/v3randbase873ye4rfhgjfitre4837wyerdfgh/chrome_2019-07-04_14-41-52.jpg
Zastanowić się na wdrożeniem rozwiązań pokroju REDIS’a.

Jeżeli nasz serwer pracuje z wykorzystaniem protokołu NVMe – nie wydaje mi się aby ten krok był potrzebny. Natomiast w innych wypadkach warto sprawdzić czy to rozwiązanie przyniesie satysfakcjonujące efekty. Jeżeli tak należy je pozostawić – kontrolując przez kilka dni czy wszystko działa poprawnie.

Zadanie TMPFS jest proste, chodzi o to aby w łatwy i szybki sposób przechowywać kluczowe dane bezpośrednio w pamięci RAM serwera. Wystarczy wykorzystać odpowiednio polecenie mount (uwaga działa to tylko do restartu serwera! Dlatego należy to skryptową albo dodać do cron’a lub init.d lub innego daemona startu):

mkdir $PS_DIR$/cache2
mv $PS_DIR$/cache $PS_DIR$/cache2
mount -t tmpfs -o size=$wielkość cache np. 5GB$ tmpfs $PS_DIR$/cache 
chown -R $użytkownik z grupą serwera np. www-data:www-data$ $PS_DIR$/cache
chmod -R 644 $PS_DIR$/cache
cp $PS_DIR$/cache2/* $PS_DIR$/cache/
rm -rf $PS_DIR$/cache

2To nie wszystko podobną procedurę należy odpowiednio edytując powyższy kod zastosować do katalogu $PS_DIR$/var/cache co będzie wyglądać tak:

mkdir $PS_DIR$/var/cache2
mv $PS_DIR$/var/cache $PS_DIR$/var/cache2
mount -t tmpfs -o size=$wielkość cache np. 5GB$ tmpfs $PS_DIR$/var/cache
chown -R $użytkownik z grupą serwera np. www-data:www-data$ $PS_DIR$/var/cache
chmod -R 644 $PS_DIR$/var/cache
cp $PS_DIR$/var/cache2/* $PS_DIR$/var/cache/
rm -rf $PS_DIR$/var/cache2

Oczywiście $PS_DIR$ zastępujemy ścieżką do naszej Presta Shop.

Od tego momentu cała struktura cache będzie znajdować się w pamięci RAM a nie bezpośrednio w systemie plików.

Kilka lat temu napisałem skrypt zarządzający TMPFS – nie mniej wymaga on dopracowania – udostępniam, być może komuś się przyda: https://pastebin.com/EAVucrHy

Skontaktuj się już teraz!

Wystarczy, że wypełnisz poniższy formularz, a z przyjemnością Ci pomożemy!

Dodatkowe aspekty optymalizacji

Szybki SSL

Ustanowienie bezpiecznego połączenia SSL również tworzy miejsce potencjalnego tracenia czasu na połączenie miedzy serwerem a komputerem. Jeżeli korzystasz z CloudFlare ten aspekt w zasadzie Cię nie dotyczy – można poeksperymentować nad przyspieszeniem CF a serwer lecz w takim przypadku ustawienia podstawowe są wystarczające. Problemem jest optymalizacja i bezpieczeństwo. Im mocniejsza metoda szyfrowania tym lepiej, ale też i wolniej. Poniżej przedstawiam sprawne ustawienie SSLCipher dla Apache2 – ustawiamy to w plikach konfiguracyjnych serwera www Apache2:

SSLCipherSuite EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:ECDHE-RSA-AES128-SHA:DHE-RSA-AES128-GCM-SHA256:AES256+EDH:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4

Więcej ciekawych informacji na temat ustanawiania SSL dla Apache2 znajdziesz tutaj: https://bobcares.com/blog/apache-sslciphersuite-recommended/

HTTP/2

Jest to znacznie unowocześniony standard transmisji danych. Ma swoje wady jak i zalety. Natomiast może znacząco przyspieszyć ładowanie strony.
Wystarczy jedna linijka kodu: Protocols h2 http/1.1 w ustawieniach <VirtualHost *:443> naszego serwera – oczywiście w przypadku Apache2.

CDN – Content Delivery Network

Koncepcja użycia CDN zakłada że przeglądarka internetowa klienta pobiera symultanicznie z różnych URL wszystkie js, css oraz obrazki – dzięki czemu strony ładują się znacznie szybciej.

Najlepiej użyć jako CDN dedykowanej usługi pokroju Amazon.

CloudFlare

CF to coś więcej niż CDN. To między innymi proxy pozwalające zabezpieczyć stronę przed atakami, przyspieszyć czas ładowania a nawet zoptymalizować niejako „w locie” obrazki. W szczególności CloudFlare jest przez nas ceniony gdyż porządnie zanonimizuje adres lub adresy IP serwera/serwerów.

Według nas jest to rozwiązanie typu „must have” w optymalizacji sklepu PrestaShop.

Klasyczne CCC

Skrót CCC pochodzi od słów combine, compress and cache. Czyli łącz, kompresuj i keszuj (zapisuj w pamięci podręcznej). Opcja ta ma za zadanie zredukować rozmiar strony, a co za tym idzie skrócić czas jej ładowania i wyświetlania poszczególnych podstron. Dzięki temu sklep działa szybciej.
Nie jest to jakieś wybitne narzędzie ale warto go uruchomić.

Tak jak już wyżej napisaliśmy – stricte optymalizacją SEO czyli meta tekstami się nie zajmujemy. Działania takie dla sklepów wymagają ogromnej ilości pracy w integracji z Semstorm oraz Ahrefs.

W zasadzie wszystkie działania podchodzą pod SEO tak samo jak optymalizacji dla sklepu PrestaShop pliku htaccess. Oczywiście w NGINX będzie nieco inaczej. Chodzi tutaj o koncepcje pamięci podręcznej w przeglądarce już raz pobranych plików jak np. logo. Po co za każdym razem ma zostać pobrany obrazek logo od nowa? Rozwiązaniem tego problemu jest ten przykład kodu: https://pastebin.com/XZaiqVEX

Oferujemy również usługę profesjonalnej aktualizacji Presty od starych do nowych wersji z zachowaniem bazy danych klientów, produktów oraz kategorii. Jako, iż Presta jest ciągle rozbudowywana – z każdą kolejną wersją szablony oraz niektóre wtyczki tracą kompatybilność. Wielokrotnie przyprowadzaliśmy procedurę aktualizacji całości dla klienta, zawsze z sukcesami.

Jak do tego procesu najlepiej podejść?

Trzeba zacząć od zrobienia od zera sklepu na jakieś tymczasowej domenie. Z kilkoma testowymi kategoriami, produktami oraz klientami. Zaprojektować fajny, responsywny i zgodny z zasadami UX/UI szablon, a następnie wyposażyć sklep wtyczkami. Tak przygotowany workspace należy odpowiednio zoptymalizować, a następnie przetransferować ze starej instancji sklepu to co będzie nam potrzebne. Kolejnym krokiem są testy, weryfikacja stabilności, ew. poprawki wydajności, a następnie pełnoprawne uruchomienie tzw. „deploy”.

A co z linkami SEO – jest to dla nas Świętość! Struktura URL’i musi pozostać taka jak była – lub nieznacznie inna po poprawkach wynikających z Google Search Console.

Cały proces optymalizacji sklepu internetowego opartego o PrestaShop jest bardzo zaawansowany i złożony. W tym artykule ujawniliśmy tylko mały fragment wiedzy którą możemy tchnąć w Twój sklep internetowy. Zaufały nam duże krajowe marki. I chodź zabrzmi to dość dziwnie to ja jako autor tego tekstu nienawiedzę PrestaShop. Dlaczego? Ponieważ straciłem na to zbyt dużo nerwów. Często debugowałem grzebiąc bezpośrednio w silniku drzemiący jeszcze głębiej czyli Symfonii. Często walcząc do długich godzin nocnych, aż wszystko stało się jasne i sprawne.

Podsumowując – nie marnuj czasu na własnoręczne próby zoptymalizowania Presty. My zrobimy to bardzo dobrze.

Dodatkowe źródła:

http://www.prestamodulemarket.com/en/module/stblog/3_how-to-speed-prestashop-up-guide.html
http://www.gxjansen.com/101-ways-to-speed-up-your-magento-e-commerce-website/
http://php.net/manual/en/book.opcache.php
http://www.prestashop.com/blog/en/your-prestashop-store-is-twice-as-fast-with-zend-opcache/