Setki realizacji, tysiące rozwiązanych problemów
Skontaktuj się już teraz!
Optymalizacja PrestaShop – Zaktualizowana oferta!
Zauważyliśmy, że artykuł o optymalizacji sklepów PrestaShop 1.7 – SEO oraz przyspieszenie wciąż przyciąga uwagę. Chociaż ten wpis ma już swoje lata, chcemy Was zapewnić, że nasza wiedza i umiejętności są na bieżąco aktualizowane!
Obecnie specjalizujemy się w optymalizacji najnowszych wersji PrestaShop, w tym 8.1.7 i wszelkich przyszłych aktualizacjach. Jeśli szukasz fachowej pomocy w zakresie SEO, przyspieszania działania Twojego sklepu lub jakiejkolwiek innej optymalizacji, jesteśmy tutaj, aby pomóc!
Nie ważne, czy Twój sklep działa na starszej wersji czy najnowszej, nasze doświadczenie pozwala nam dostarczać skuteczne rozwiązania, które przyczynią się do lepszej widoczności i wydajności Twojego sklepu.
Zachęcamy do kontaktu! Nasz zespół jest gotowy, aby odpowiedzieć na wszelkie pytania i dostosować nasze usługi do Twoich potrzeb. Skontaktuj się z nami już dziś, a wspólnie sprawimy, że Twój sklep będzie działał lepiej niż kiedykolwiek!
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.
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:
- innodb_buffer_pool_size: minimum 512GB (im więcej tym lepiej)
- innodb_thread_concurrency: 2 * [ilość rdzeni CPU] + 2
- query_cache_size: minimum 64MB (im więcej tym lepiej)
- 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/