Jump to content

Długie wczytywanie sklepu


Recommended Posts

Witam.

Jak w temacie, sklep strasznie wolno się wczytuje. Najbardziej strona główna.

http://tnijurl.com/linkdosklepu/. W jaki sposób mogę to poprawić.

Wyłączone kompilowanie, włączone cache. A ja nadal nie mam pojęcia przez co tak się dzieje.

Obstawiam, że jak modyfikowałem wygląd home page to coś źle ustawiłem - mam na myśli plik header.tpl.

Edited by konrad1cs (see edit history)

Share this post


Link to post
Share on other sites

zmiany w header.tpl raczej nie powinny wpływać na długość ładowania się sklepu (szczególnie jeżeli są to drobne zmiany w konstrukcji bloków itp)

 

przetestowałem Twój sklep, wcale tak długo się nie włącza

czas oczekiwania na załadowanie się podstron to mnie niż 1s

 

pierwsze ładowanie strony tylko trwa długo, http://gtmetrix.com/reports/szafkinabuty.pl/kRd5EAdq

sprawdziłem Twoją stronę gmetrixem, jest tam lista rzeczy do "poprawki"

Share this post


Link to post
Share on other sites

Coś w tym chyba jednak jest.

ps_search_index - 1,5 mb

ps_product_lang - 3,5 mb

ps_pagenotfound - 3,5 mb

ps_guest - 7,5 mb

ps_connections_source - 6 mb

ps_connections - 6 mb

to te tabele które nie wiem za co odpowiadają.

Orientujecie się, które mogę usunąć bez skrupułów ?

Share this post


Link to post
Share on other sites

tabele niezbędne:

  1. ps_product_lang - tłumaczenia produktów
  2. ps_search_index - index wyszukiwarki

reszte można przeczyścić. Ps. mimo wszystko nie zapomnij o backupie bazy

 

 

statystki dostępne w back office nie będą pełne (brak danych do obrobienia - wszak zostaną one usunięte)

Share this post


Link to post
Share on other sites

Z tego co zobaczyłem przywracając tabele to guest odpowiada za klientów, connections za statystyki, connections_source za zrodło osoby przychodzącej, product_lang - łatwo się domyśleć, że za tłumaczenie produktów, pagenotfound za stronny nie wczytane, search_index od wyszukiwania. Jeśli się w czym pomyliłem to przepraszam, poprawcie mnie.

A co do Vekia to gdzie by nie był jakiś topic to Vekia wie wszystko, podziwiam i szacunek ;)

Share this post


Link to post
Share on other sites

vekia, mógłbyś gdzieś posta walnąć z wytłumaczeniem za co odpowiada jaka tabela? ;)

 

mówisz o tym przypadku, czy ogólnie o całej strukturze bazy danych? ;)

 

ps_quest jest to również baza do statystyk, raczej lądują tam śmieci, które w najgorszym przypadku spowalniają bazę i sklep, wiec z powodzeniem można ją opróżnić bez większych konsekwencji

Share this post


Link to post
Share on other sites

  • 2 weeks later...

podepne sie pod temat. sklep nowy aladym.pl, ale juz sa problemy, ktorych sam nie moge ocenic. czesc uzytkownikow pisze, ze dlugo sklep sie wczytuje, a nawet przegladarka przekracza czas odpowiedzi. czytajac od paru dni, zoptymalizowalem i w mojej ocenie wyglada to ze ladowanie z 4 sek. przyspieszylo do 2 sek., ale ponoc dalej inni maja problemy. u mnie i w miejscach gdzie moglem sprawdzac sklep b. ladnie chodzi. hostingodawca rowniez testujac nie zauwazyl problemow. testujac na http://tools.pingdom.com zauwazylem, ze klika razy przekroczyl test 60 sek., a kilkadziesiat razy bylo ponizej 4sek.

Edited by qaras (see edit history)

Share this post


Link to post
Share on other sites

podepne sie pod temat. sklep nowy aladym.pl, ale juz sa problemy, ktorych sam nie moge ocenic. czesc uzytkownikow pisze, ze dlugo sklep sie wczytuje, a nawet przegladarka przekracza czas odpowiedzi. czytajac od paru dni, zoptymalizowalem i w mojej ocenie wyglada to ze ladowanie z 4 sek. przyspieszylo do 2 sek., ale ponoc dalej inni maja problemy. u mnie i w miejscach gdzie moglem sprawdzac sklep b. ladnie chodzi. hostingodawca rowniez testujac nie zauwazyl problemow. testujac na http://tools.pingdom.com zauwazylem, ze klika razy przekroczyl test 60 sek., a kilkadziesiat razy bylo ponizej 4sek.

 

jeżeli presta ładuje się normalnie a później zwalnia na tyle, że przeglądarka przekracza czas odpowiedzi winy doszukiwałbym się raczej w dwóch miejscach:

  1. po stronie hostingu
  2. łącza z którego korzystasz (aczkolwiek to w 95% wykluczam)

 

nic innego mi do głowy nie przychodzi ;)

 

no chyba, że masz nagłe skoki odwiedzin z dajmy na to 2-3 userów online do 2000-3000 ;)

Share this post


Link to post
Share on other sites

  • 2 weeks later...

"Po stronie hostingu" hmm a co dokładnie może zawinić? Ja np. używam serwera home. A wy czego używacie do presty, aby dobrze chodziła.
Tyszek napisał wcześniej o kompresji gzip. W jaki sposób mogę to zrobic, szukałem po poradnikach, ale do niczego nie doszedłem. A ona może również mieć wpływ na czas

Share this post


Link to post
Share on other sites

"po stronie hostingu" może znaczyć naprawdę bardzo dużo, ot taki pierwszy lepszy przykład, najczęściej spotykany

  1. Serwer z ktorego korzystasz jest rowniez wykorzystywany przez inne osoby (shared hosting), Uslugodawca aby zarobic jak najwiecej dopuszcza sie tzw. oversellingu, czyli "sprzedaje" więcej niż ma, licząc po cichu na to że nie wszyscy będą wykorzystywać na maksa przydzielane im zasoby. Problem zaczyna się w momencie kiedy te osoby wykorzystują więcej zasobów niż powinny, wówczas cała maszyna może "kuleć" czego efektem są problemy z "prędkością" działania itp.

Share this post


Link to post
Share on other sites

Już wystarczająco jestem poirytowany, tym jak to chodzi.
Presta według mnie powinna tak się zachowywać przy paru tys produktów, a nie przy 200.
U Homa powiedzieli mi ze to jest spowodowane jakimś generowanym skryptem(w sumie by się zgadzało, bo mając otwartą jakąs stronę, i zaraz po zatwierdzeniu nowego adresu tj. mojej strony powinna ona zacząć się wczytywać powoli, a choćby tło mojej strony wyświetla się po dłuższym czasie niż odstęp pomiedzy tłem a treścią z grafiką, co potwierdza ich słowa. Tak jak by ładowało, ładowało i boom jest strona) Jak by się tak szybko ładowała od pokazania pierwszej rzeczy na stronie do pokazania ostatniej to był bym ucieszony.

Tylko teraz pewnie nie dojdę do tego co i jak jest źle zrobione.

Zaraz po instalacji, zmianie ustawień kontaktowych, wysyłek, kurierów etc. ustawiłem cache, pamieć podręczna, debugowanie, ccc według zaleceń.
Poza tym skompresowałem cache css i js na serwerze. Nie do końca pamiętam, ale chyba również zmieniłem coś w htaccess, ale to raczej nie powinno mieś wpływu.

 

Czy macie może jakieś propozycje?
Może wgrał bym oryginalny htaccess i zastanawiał bym się co dalej, bądź może przy optymalizacji wytryny o czym zapomniałem? Hmm?

Share this post


Link to post
Share on other sites

Na Home zawsze coś wywalało. Jak nie jedno, to później coś innego - nei wiem jak oni mają to skonfigurowane, ale lepiej zmienić hosting wcześniej niż później.

Wpisz sobie w Google "prestashop home.pl" i pewnie same posty o problemach od już kilku lat.

Share this post


Link to post
Share on other sites

U Homa powiedzieli mi ze to jest spowodowane jakimś generowanym skryptem

 

 

gdyby wskazali dokładnie o jaki skrypt (plik) chodzi (a mają taką możliwość) to by znacznie ułatwiło sprawę. Teraz jest to wróżenie z fusów.

 

w takich przypadkach trzeba mieć dostęp do konsoli serwera, a w tym przypadku może to zrobić jedynie obsługa techniczna home

Share this post


Link to post
Share on other sites

Wrzuciłem ten adres do narzędzi wujka Goooogle :(

"W naszym teście, serwer odpowiedział w 5,8 sekundy.

Kompresja nie jest włączona:  386.7KiB (72% redukcji)

Wszystkie fotki też wgrywają się na bieżąco (cache przeglądarki :( )"- a trochę ich tam jest - ze 60

 

W sumie to trudno się doszukać czegoś na plus  ^_^

Serwer pewnie też "macza w tym palce" ale to co możesz po swojej stronie - to musisz zrobić

Edited by PMaster (see edit history)

Share this post


Link to post
Share on other sites

Za koleją:
Postaram się dowiedzieć który plik jest generowany.

Odnośnie kompresji: Jak to nie jest włączona? w aplikacji jest włączona, może coś w ustawieniach serwera nie jest tak mam na mysli htaccess.
Co do zdjęć na stronie głównej to produkty wyświetlają się losowo (204 produkty)
Chyba w gtmetrix pokazało mi, abym ustawił czas wygaśniecia plików.. nie umiałem tego zrobić, jeśli to jest istotne..

Więc poza kontaktem z home co powinienem zrobić, aby włączyć te cache?

Share this post


Link to post
Share on other sites

To jest skopiowane z narzędzi - raczej nie kłamie <_<

Kompresja Gzip na serwerze nie w sklepie. Nie wiem jak to jest w Home bo nie korzystałem - czy ty możesz włączyć czy muszą oni.

Htaccess wygeneruj koniecznie (no chyba, że masz tam coś konkretnego pozmieniane - to musisz ręcznie kombinować). Fotki sklep chyba domyślnie ustawia na miesiąc, a css i javę na tydzień. Chociaż to będziesz miał z głowy... :)

Share this post


Link to post
Share on other sites

W przypadku htaccess. Wystarczy jak usunę aktualny ? Powinien się wygenerować sam, prawda?

Dzwoniłem do hostingodawcy ;) 

U nich nie ma żadych wad, wszystko chodzi pieknie i ladnie, to blad aplikacji, a konkretnie pewnie któregoś z modułu

 

Share this post


Link to post
Share on other sites

htaccess - tak jak mówisz skasuj.

Potem sprawdź jeszcze dokładnie ustawienia sklepu - wydajność, ale jak masz wszystko na zielono to nic więcej z tego nie wyciśniesz.

Jeszcze mógłbyś włączyć memcached ale wątpię aby ci to udostępnili. :(

Zobacz potem o ile zmniejszy się czas odpowiedzi serwera - jak sprawdzaliśmy to było chyba około 6 sekund.

 

Swoją drogą to ładny tekst Ci "wysmarowali w Home" - ciekawe co u nich chodzi ładnie i pięknie skoro dalej piszą, że jest błąd - to chyba jednak nie chodzi ładnie i pięknie?  :ph34r:

 

Zapomniałem - jak dzwoniłeś pytałeś o Gzip?

Edited by PMaster (see edit history)

Share this post


Link to post
Share on other sites

w katalogu głównym usunąłem htaccess, wylaczyłem offerchat i slider wiec strona zmniejszyła swoj rozmar z 1,16 kb do 786kb,  na gtmetrix czas ładowania str z C zmienił się na B, wnioski zmniejszyły się aż o 9 w dół, ale i slider i chat mi sa potrzebne wiec zostaje przy rozmiarze strony 1,16 kb.

Zastanawia mnie dlaczego jest problem z tym dźwiganiem cache, czy nie cachuje tych plików, czy chodzi, że ich jest za dużo
Zastanawia mnie również nie wiem co mogę zrobić z gzip bo powiedzieli mi, że serwer obsługuje i "trzeba włączyć w aplikacji" Ale jak ?! 

link do wyników z gtmetrix http://gtmetrix.com/reports/szafkinabuty.pl/y2iB1sov
 

Share this post


Link to post
Share on other sites

Dalej jest lipa... czas odpowiedzi 8,1 w drugim teście 6,7..

Czas wygaśnięcia plików dalej nie jest ustawiony.

Włącz przyjazne adresy i "optymalizację apache" - te dane powinny zapisać się w pliku htaccess i powinien wyglądać mniej więcej tak:

 

# ~~start~~ Do not remove this comment, Prestashop will keep automatically the code outside this comment when .htaccess will be generated again
# .htaccess automaticaly generated by PrestaShop e-commerce open-source solution
 
<IfModule mod_rewrite.c>
RewriteEngine on
RewriteCond %{HTTP_HOST} ^xdomena.pl$
RewriteRule . - [E=REWRITEBASE:/]
RewriteRule ^api/?(.*)$ %{ENV:REWRITEBASE}webservice/dispatcher.php?url=$1 [QSA,L]
 
# Images
RewriteCond %{HTTP_HOST} ^xdomena.pl$
RewriteRule ^([0-9])(\-[_a-zA-Z0-9-]*)?(-[0-9]+)?/.+\.jpg$ %{ENV:REWRITEBASE}img/p/$1/$1$2$3.jpg [L]
RewriteCond %{HTTP_HOST} ^xdomena.pl$
RewriteRule ^([0-9])([0-9])(\-[_a-zA-Z0-9-]*)?(-[0-9]+)?/.+\.jpg$ %{ENV:REWRITEBASE}img/p/$1/$2/$1$2$3$4.jpg [L]
RewriteCond %{HTTP_HOST} ^xdomena.pl$
RewriteRule ^([0-9])([0-9])([0-9])(\-[_a-zA-Z0-9-]*)?(-[0-9]+)?/.+\.jpg$ %{ENV:REWRITEBASE}img/p/$1/$2/$3/$1$2$3$4$5.jpg [L]
RewriteCond %{HTTP_HOST} ^xdomena.pl$
RewriteRule ^([0-9])([0-9])([0-9])([0-9])(\-[_a-zA-Z0-9-]*)?(-[0-9]+)?/.+\.jpg$ %{ENV:REWRITEBASE}img/p/$1/$2/$3/$4/$1$2$3$4$5$6.jpg [L]
RewriteCond %{HTTP_HOST} ^xdomena.pl$
RewriteRule ^([0-9])([0-9])([0-9])([0-9])([0-9])(\-[_a-zA-Z0-9-]*)?(-[0-9]+)?/.+\.jpg$ %{ENV:REWRITEBASE}img/p/$1/$2/$3/$4/$5/$1$2$3$4$5$6$7.jpg [L]
RewriteCond %{HTTP_HOST} ^xdomena.pl$
RewriteRule ^([0-9])([0-9])([0-9])([0-9])([0-9])([0-9])(\-[_a-zA-Z0-9-]*)?(-[0-9]+)?/.+\.jpg$ %{ENV:REWRITEBASE}img/p/$1/$2/$3/$4/$5/$6/$1$2$3$4$5$6$7$8.jpg [L]
RewriteCond %{HTTP_HOST} ^xdomena.pl$
RewriteRule ^([0-9])([0-9])([0-9])([0-9])([0-9])([0-9])([0-9])(\-[_a-zA-Z0-9-]*)?(-[0-9]+)?/.+\.jpg$ %{ENV:REWRITEBASE}img/p/$1/$2/$3/$4/$5/$6/$7/$1$2$3$4$5$6$7$8$9.jpg [L]
RewriteCond %{HTTP_HOST} ^xdomena.pl$
RewriteRule ^([0-9])([0-9])([0-9])([0-9])([0-9])([0-9])([0-9])([0-9])(\-[_a-zA-Z0-9-]*)?(-[0-9]+)?/.+\.jpg$ %{ENV:REWRITEBASE}img/p/$1/$2/$3/$4/$5/$6/$7/$8/$1$2$3$4$5$6$7$8$9$10.jpg [L]
RewriteCond %{HTTP_HOST} ^xdomena.pl$
RewriteRule ^c/([0-9]+)(\-[\.*_a-zA-Z0-9-]*)(-[0-9]+)?/.+\.jpg$ %{ENV:REWRITEBASE}img/c/$1$2$3.jpg [L]
RewriteCond %{HTTP_HOST} ^xdomena.pl$
RewriteRule ^c/([a-zA-Z_-]+)(-[0-9]+)?/.+\.jpg$ %{ENV:REWRITEBASE}img/c/$1$2.jpg [L]
# AlphaImageLoader for IE and fancybox
RewriteCond %{HTTP_HOST} ^xdomena.pl$
RewriteRule ^images_ie/?([^/]+)\.(jpe?g|png|gif)$ js/jquery/plugins/fancybox/images/$1.$2 [L]
 
# Dispatcher
RewriteCond %{REQUEST_FILENAME} -s [OR]
RewriteCond %{REQUEST_FILENAME} -l [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteCond %{HTTP_HOST} ^xdomena.pl$
RewriteRule ^.*$ - [NC,L]
RewriteCond %{HTTP_HOST} ^xdomena.pl$
RewriteRule ^.*$ %{ENV:REWRITEBASE}index.php [NC,L]
</IfModule>
 
<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType image/gif "access plus 1 month"
ExpiresByType image/jpeg "access plus 1 month"
ExpiresByType image/png "access plus 1 month"
ExpiresByType text/css "access plus 1 week"
ExpiresByType text/javascript "access plus 1 week"
ExpiresByType application/javascript "access plus 1 week"
ExpiresByType application/x-javascript "access plus 1 week"
ExpiresByType image/x-icon "access plus 1 year"
</IfModule>
 
FileETag INode MTime Size
<IfModule mod_deflate.c>
<IfModule mod_filter.c>
AddOutputFilterByType DEFLATE text/html text/css text/javascript application/javascript application/x-javascript
</IfModule>
</IfModule>
 
#If rewrite mod isn't enabled
ErrorDocument 404 /index.php?controller=404
 
# ~~end~~ Do not remove this comment, Prestashop will keep automatically the code outside this comment when .htaccess will be generated again
 
To jest plik z czystej Presty z włączonymi adresami przyjaznymi i udoskonaleniami apatche i mniej więcej tak powinien wyglądać u Ciebie. Nie ma tu tylko GZip bo to sub domena.
 
I nie ma się co bawić w zmniejszanie zdjęć (na wszystkich zdjęciach, które masz na głównej możesz zaoszczędzić 64Kb to chyba na razie nie warto) - musisz najpierw to zrobić.
Sklep ma wynik 38/100 w Google a dla urządzeń mobilnych 32/100 - mogą Cie "roboty" szybko przestać lubić :(
Z Gzip w Home, z tego co kiedyś poczytałem długo były problemy bo włączali go tylko na VPS aby zmusić ludzi do przechodzenia na wyższe abonamenty - to tylko cytuję bo z doświadczenia nie wiem - Ty powinieneś wiedzieć bo korzystasz. Ludzie robili jakieś obejścia w htccass ale ponoć mało skutecznie. 
Powiedzieli, że serwer obsługuje Gzip i nie kłamali <_<  tylko muszą Ci to włączyć (jeśli napisali, że w aplikacji to niech jeszcze dopiszą w jakiej :unsure: ), bo to chyba jakaś ich autorska... <_<
 
A to "Dźwiganie" o którym piszesz to właśnie czasy wygaśnięcia plików - to ustawi Ci sklep gdy włączysz udoskonalenia Apatche. Jak chcesz to możesz potem sam je wydłużyć w pliku. Presta ustawia jedne na miesiąc, drugie na tydzień ale spokojnie można je wydłużyć.
Edited by PMaster (see edit history)

Share this post


Link to post
Share on other sites

Plik wygląda podobnie, rożnica jest taka, że w moim jest dodane
 

# Disable Multiviews
Options -Multiviews

Tutaj kod:

 

# ~~start~~ Do not remove this comment, Prestashop will keep automatically the code outside this comment when .htaccess will be generated again

# .htaccess automaticaly generated by PrestaShop e-commerce open-source solution
 
<IfModule mod_rewrite.c>
 
# Disable Multiviews
Options -Multiviews
 
RewriteEngine on
RewriteCond %{HTTP_HOST} ^szafkinabuty.pl$
RewriteRule . - [E=REWRITEBASE:/]
RewriteRule ^api/?(.*)$ %{ENV:REWRITEBASE}webservice/dispatcher.php?url=$1 [QSA,L]
 
# Images
RewriteCond %{HTTP_HOST} ^szafkinabuty.pl$
RewriteRule ^([0-9])(\-[_a-zA-Z0-9-]*)?(-[0-9]+)?/.+\.jpg$ %{ENV:REWRITEBASE}img/p/$1/$1$2$3.jpg [L]
RewriteCond %{HTTP_HOST} ^szafkinabuty.pl$
RewriteRule ^([0-9])([0-9])(\-[_a-zA-Z0-9-]*)?(-[0-9]+)?/.+\.jpg$ %{ENV:REWRITEBASE}img/p/$1/$2/$1$2$3$4.jpg [L]
RewriteCond %{HTTP_HOST} ^szafkinabuty.pl$
RewriteRule ^([0-9])([0-9])([0-9])(\-[_a-zA-Z0-9-]*)?(-[0-9]+)?/.+\.jpg$ %{ENV:REWRITEBASE}img/p/$1/$2/$3/$1$2$3$4$5.jpg [L]
RewriteCond %{HTTP_HOST} ^szafkinabuty.pl$
RewriteRule ^([0-9])([0-9])([0-9])([0-9])(\-[_a-zA-Z0-9-]*)?(-[0-9]+)?/.+\.jpg$ %{ENV:REWRITEBASE}img/p/$1/$2/$3/$4/$1$2$3$4$5$6.jpg [L]
RewriteCond %{HTTP_HOST} ^szafkinabuty.pl$
RewriteRule ^([0-9])([0-9])([0-9])([0-9])([0-9])(\-[_a-zA-Z0-9-]*)?(-[0-9]+)?/.+\.jpg$ %{ENV:REWRITEBASE}img/p/$1/$2/$3/$4/$5/$1$2$3$4$5$6$7.jpg [L]
RewriteCond %{HTTP_HOST} ^szafkinabuty.pl$
RewriteRule ^([0-9])([0-9])([0-9])([0-9])([0-9])([0-9])(\-[_a-zA-Z0-9-]*)?(-[0-9]+)?/.+\.jpg$ %{ENV:REWRITEBASE}img/p/$1/$2/$3/$4/$5/$6/$1$2$3$4$5$6$7$8.jpg [L]
RewriteCond %{HTTP_HOST} ^szafkinabuty.pl$
RewriteRule ^([0-9])([0-9])([0-9])([0-9])([0-9])([0-9])([0-9])(\-[_a-zA-Z0-9-]*)?(-[0-9]+)?/.+\.jpg$ %{ENV:REWRITEBASE}img/p/$1/$2/$3/$4/$5/$6/$7/$1$2$3$4$5$6$7$8$9.jpg [L]
RewriteCond %{HTTP_HOST} ^szafkinabuty.pl$
RewriteRule ^([0-9])([0-9])([0-9])([0-9])([0-9])([0-9])([0-9])([0-9])(\-[_a-zA-Z0-9-]*)?(-[0-9]+)?/.+\.jpg$ %{ENV:REWRITEBASE}img/p/$1/$2/$3/$4/$5/$6/$7/$8/$1$2$3$4$5$6$7$8$9$10.jpg [L]
RewriteCond %{HTTP_HOST} ^szafkinabuty.pl$
RewriteRule ^c/([0-9]+)(\-[\.*_a-zA-Z0-9-]*)(-[0-9]+)?/.+\.jpg$ %{ENV:REWRITEBASE}img/c/$1$2$3.jpg [L]
RewriteCond %{HTTP_HOST} ^szafkinabuty.pl$
RewriteRule ^c/([a-zA-Z_-]+)(-[0-9]+)?/.+\.jpg$ %{ENV:REWRITEBASE}img/c/$1$2.jpg [L]
# AlphaImageLoader for IE and fancybox
RewriteCond %{HTTP_HOST} ^szafkinabuty.pl$
RewriteRule ^images_ie/?([^/]+)\.(jpe?g|png|gif)$ js/jquery/plugins/fancybox/images/$1.$2 [L]
 
# Dispatcher
RewriteCond %{REQUEST_FILENAME} -s [OR]
RewriteCond %{REQUEST_FILENAME} -l [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteCond %{HTTP_HOST} ^szafkinabuty.pl$
RewriteRule ^.*$ - [NC,L]
RewriteCond %{HTTP_HOST} ^szafkinabuty.pl$
RewriteRule ^.*$ %{ENV:REWRITEBASE}index.php [NC,L]
</IfModule>
 
<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType image/gif "access plus 1 month"
ExpiresByType image/jpeg "access plus 1 month"
ExpiresByType image/png "access plus 1 month"
ExpiresByType text/css "access plus 1 week"
ExpiresByType text/javascript "access plus 1 week"
ExpiresByType application/javascript "access plus 1 week"
ExpiresByType application/x-javascript "access plus 1 week"
ExpiresByType image/x-icon "access plus 1 year"
</IfModule>
 
FileETag INode MTime Size
<IfModule mod_deflate.c>
<IfModule mod_filter.c>
AddOutputFilterByType DEFLATE text/html text/css text/javascript application/javascript application/x-javascript
</IfModule>
</IfModule>
 
#If rewrite mod isn't enabled
ErrorDocument 404 /index.php?controller=404
 
# ~~end~~ Do not remove this comment, Prestashop will keep automatically the code outside this comment when .htaccess will be generated again


Odnośnie gzip, to powyzej chyba nim nie jest, nie wiem dlaczego, ale sie nie włączyło.
Dostałem od Homa właśnie informacje na temat włączenia gzip statycznego i dynamicznego, zaraz spróbuję je zastosować

Co do wyniku w google, mogę Ciebie prosić o info z czego korzystałeś, są tam jakieś zalecenia, które mógł bym zastosować, aby nie poleciało pozycjonowanie?

P.S.
Co do dźwigania cache wynik był na włączonych wszystkich zalecanych opcjach. Zachowuję się sklep, jak by nie było tej kompresji

Share this post


Link to post
Share on other sites

Link do pagespeed od Googla: http://developers.google.com/speed/pagespeed/insights/ - zalecenia też tam znajdziesz.

O GZip nie ma nic w tym pliku masz rację, bo nie włącza się tej kompresji przez sklep.

(Możesz podrzucić co Ci napisali z Home... :blink: tę instrukcję włączenia?)

Ze zdjęciami nie wiem co może być, w pliku niby wszystko jest ustawione. Chyba, że to znów jakiś patent Home :rolleyes:

Spróbuj może jeszcze zrobić test przy wyłączonej pamięci podręcznej i z wymuszoną kompilacją - sprawdź, potem wróć do poprzednich opcji i porównaj wyniki...

Share this post


Link to post
Share on other sites

O to cały tekst od nich:
 

 

 

Uprzejmie informujemy, że użycie kompresji gzip, przy wykorzystaniu platformy hostingowej home.pl, możliwe jest zarówno w przypadku treści statycznych, jak i generowanych dynamicznie.

1. Treść statyczna

W celu użycia kompresji gzip dla statycznego elementu skryptu (najczęściej są to pliki .css, lub .js) należy umieścić na serwerze uprzednio skompresowane pliki, a następnie dodać do pliku .htaccess zapis wzorowany na poniższym (dla plików .css).

:Location /*.css
Header set Content-Encoding "gzip"
:Location

Zamiennie do pliku *.css można podać dowolne rozszerzenie.

2. Treść dynamiczna

W przypadku treści dynamicznej, plik php mający serwować skompresowana treść powinien zostać utworzony w oparciu o poniższy przykład:

<?php
ob_start(); //przełącza w pozycje ON status wyjściowego bufora php
//poniższy fragment kodu html zostanie zapisany do bufora, a później skompresowany
?>

<html>
<head>
<meta http-equiv=\"Content-Type\" content=\"text/html; charset=UTF-8\" />
<title>test gzip</title>
</head>
<body>
<h1>test gzip</h1>
</body>
<html>

<?php
print_gzipped_output(); //wywołanie poniższej funkcji

function print_gzipped_output()
{
$contents = ob_get_clean(); //zapisuje zawartość bufora do zmiennej, po czym czyści bufor
header('Content-Encoding: gzip'); //ustawienie odpowiedniego nagłówka http
print("\x1f\x8b\x08\x00\x00\x00\x00\x00");
$contents = gzcompress($contents, 9); //kompresja zawartości zmiennej na poziomie 9 (gdzie 9-max, 0-brak)
print($contents); //przesłanie skompresowanej treści do przeglądarki
}
?>

W przypadku statycznego gzip do htacces w kat gł prawie na koncu dorzuciłem kod poniżej, ale to nic nie dało! nadal w testach pokazuje go:

 

 

:Location /*http://szafkinabuty.pl/themes/default/cache/636604fce43fa037fad4289fc1796bee_all.css

Header set Content-Encoding "gzip"
:Location
Header set Content-Encoding "gzip"
:Location  

 

 Wymuszona komplikacja, wył pamieć podręczna i wynik jest podobny:
http://gtmetrix.com/reports/szafkinabuty.pl/eLBB4w70
raptem o 2 sec dłużej.
Już nie wiem co robić. Wziąłem na próbę serwer biznes starter z lepszymi parametrami, aby wykorzystać kompresję w locie, ale nie zbyt umiem jej użyć. Jest napisane aby na początku oraz na koncu strony (INDEX) dodać skrypt, tylko że presta korzysta z plików .tpl  (header i footer)więc jak powinienem się zastosować do ich poleceń? HAH mam dodać pierwsza czesc w headerze i drugą na koncu footer ? (bo za </html>?
Jak się zapoznasz to napisz co myślisz, bo mi już pomysłów do kombinowania brakuje, będę wdzięczny i za dotychczasowa pomoc tez  dziekuje

Share this post


Link to post
Share on other sites

Ta instrukcja to właśnie to "niby obejście problemu", o którym pisałem dwa posty wyżej - podobno efekt żaden. :( I okazuje się, że naprawdę nie włączają tego Gzipa. Bo jeśli w ogóle da się to włączyć, w co wątpię to zobacz jaki odsetek ludzi stawiających sklep grzebie w plikach konfiguracyjnych serwera - bzdura jakaś.

Już nie wiem co Ci doradzić. Ta następna zabawa z kodem to znów nowy problem.

Oni mają chyba hosting tylko dla "zapalonych" informatyków <_< z nadmiarem wolnego czasu.

Jak coś nowego wymyślę to dam znać :)

Share this post


Link to post
Share on other sites

heh co mnie najbardziej zadziwia to fakt, że podstrony chodzą w porównaniu do indexu świetnie, a nawet jeśli już jestem wgłąb sklepu i chce powrócić do str gł to czas oczekiwania jest praktycznie ten sam, gdzie powinien być znacznie niższy.

A co do optymalizacji to czasu odpowiedzi serwera nie zmienię, kompresji nie włączę (chyba, że jakim cudem w locie, ale jutro będę się edukował w tym temacie bo nie wiem jak to ugryść skoro strona czyta i header i footer).
A co do dzwigania cache przegladarki to nadal stoję w martwym punkcie, gdyż "udoskonalenie apache" nie reaguje"

Co do zapalenia to mi nie wiele brakuje;)
A Ty jakiego serwera używasz, oraz czy Ty też masz aż takie problemy ze stroną? Być może pozostaje  mi tylko zmienić serwer?
 

Share this post


Link to post
Share on other sites

No i znalazłem przyczynę problemu!
Poirytowany zainstalowałem czystą preste na tym samym serwerze, mniej więcej te same moduły zostały włączone, chodziło pięknie.
Zabezpieczyłem sobie bazę danych, później importowałem ze starego sklepu, zmieniłem tylko adres sklepu, abym mógł go odczytać i sklep zachowywał sie jeszcze gorzej niż aktualny!

Przypuszczałem, ale nie do końca wierzyłem, że przyczyną może być baza danych.

No i teraz jak z bazy danych odzyskać same produkty z opisami i zdjęciami bo reszte jestem sobie w stanie ustawić.

Czy ktoś będzie w stanie mi pomóc?

Tutaj link do tego sklepu (ale z oryginalną bazą ) automatycznie widać różnice
http://lifeandhome.home.pl/sklepszafki/

Share this post


Link to post
Share on other sites

W sumie nie chcę Cię martwić ale w ten nowy sklep zachowuje się podobnie. Wynik w Google 62/100. Poprawił się tylko czas odpowiedzi serwera ale to nic dziwnego jeśli sklep jest czysty - nie ma za bardzo co robić :) jak wypełnisz bazę może być to samo (pusty sklep powinien mieć grubo ponad 90 nawet 96, 97, ponieważ towaru w nim nie ma, a jako czysty jest nieźle zoptymalizowany - twórcy :) o to nieźle zadbali).

Sprawdź ten czysty sklep w narzędziach Google przed kopiowaniem bazy, link wrzuciłem Ci wczoraj i sam ocenisz czy warto go wypełniać towarem.

Share this post


Link to post
Share on other sites

Domyślam się nie nie warto...

No i faktycznie zmartwiłeś mnie, a przyczyny nadal nie ma.

Co mogę w takim wypadku zrobić? Zmiana serwera, bo chyba nie sklepu - już się z nim zaprzyjaźniłem ;/

Spróbuj jeszcze ten nowy sklep sprawdzić typowo na czysto, bez żadnych dodatków (bo teraz masz tam włączonych kilka "bajerów) i tylko z przykładowym towarem. Najlepiej załóż nową sub domenę i zainstaluj na niej sklep - zrób całą optymalizację, przyjazne adresy też i wtedy przetestuj. Jeśli wynik będzie Ok to wykluczysz serwer <_<  i trzeba będzie szukać problemu po stronie sklepu.

Share this post


Link to post
Share on other sites

Zostawiłem to co mi jest potrzebne, towar przykładowy.
Utworzona subdomena i podpieta pod nia tamta aplikacja (Nie instalowałem nowej) 
Zoptymalizowałem na ile potrafiłem:
http://developers.google.com/speed/pagespeed/insights/?url=http%3A%2F%2Ftest.szafkinabuty.pl%2F#
http://gtmetrix.com/reports/test.szafkinabuty.pl/kFIacNvB 

lepiej nie potrafiłem..

Wynik jest nieco lepszy, ale nadal mnie zastanawia to gzip - ta cala ich instrukcja do statycznej kompresji (.htaccess) Co gdybym podpiął skompresowany plik (posiadam taki od homa) z folderem cache do htaccess

 

:Location /*cache_kopia.tar.gz

Header set Content-Encoding "gzip"
:Location

Tylko nie chciało mi to działać. Aby zadziałało powinienem może podpiac taki tar.gz tylko z plikiem o którym pisze google? Bo w taki sposób nic nie drgnęło.

A w jaki sposób mogę to "polepszyć" ?
"Eliminate render-blocking JavaScript and CSS in above-the-fold content" - wyeliminowanie renderowania blokowania js i css
Twoja strona posiada 1 blokujące zasoby skrypt i 1 blokujące zasoby CSS. Powoduje to opóźnienia w świadczeniu swoją stronę.

 

P.S. zle tłumaczenie bo od googla​
 

Share this post


Link to post
Share on other sites

Hey,

 

Spróbujcie usunąć poniższy kod z .htaccess

 

FileETag INode MTime Size
<IfModule mod_deflate.c>
<IfModule mod_filter.c>
AddOutputFilterByType DEFLATE text/html text/css text/javascript application/javascript application/x-javascript
</IfModule>
</IfModule>
 
U mnie na zenboxie podziałało i sklep przyspieszył

Share this post


Link to post
Share on other sites

Wydaje mi się, że to nie ma sensu - w/g mnie to ewidentna wina hostingu. :wacko:

 

Ps. Zenbos działa? Strony w ich domenie się nie otwierają - podobno mają problemy z atakiem DDos?

 

"Serwis jest atakowany od piątku, ale to w niedzielę miała miejsce kulminacja. Co ciekawe, za atakiem stoi najprawdopodobniej prawdziwy profesjonalista, który cały czas dostosowuje swoje działania i reaguje na wszystkie próby obrony Zenbox.

 

Problem jest w tym, że ten ktoś, kto atakuje, uwziął się. My stawiamy linię obrony X, a on zmienia formę ataku na Y. Poza tym używa dużego botnetu. Za każdym, jak tylko wychwycą naszą reakcję, zmieniają metodykę. Mają szeroki wachlarz możliwości zaszkodzenia. To nie jest maszynowy atak. Ktoś cały czas siedzi przy komputerze i zmienia sposób działania – mówi Tomasz Fiedoruk, szef Zenbox" - to jest informacja z przed 3 tygodni, ale na ich strony w tej chwili też nie mogę wejść :(

Share this post


Link to post
Share on other sites

3 tygodniowy DoS :P kto by to udźwignął ;)

swoją drogą miałem account na zenboxie i jestem gotów z czystym sumieniem wszystkim polecić :)

ale dziś, niestety, nie działa :|

Nie wiem co wy macie z kompami, bo mi działa, strona zenbox.pl moja strona i panel :)

Share this post


Link to post
Share on other sites

próbowałem usunąć tą część kodu z htacces, ale to nie przyniosło skutku. Hmm, ale coś w tym chyba faktycznie jest, bo strona jak by coś generowała przy każdym wejściu na stronę główną.

Napisałem do homa...
Opisałem się jak głupi, dałem załączniki z dowodami, a dostałem taką sama odpowiedz jak ostatnio.
Pozwolę sobie zamieścić treść maila:
 

 

 

Witam.
Od kilku dniu nie mogę uporać z podniesieniem atrakcyjności strony dla
google, oraz z prędkością jej wczytywania.
Treść dotyczy witryny: szafkinabuty.pl

Kilkukrotnie kontaktowałem się z Państwem, w celu poprawy jej prędkości, a
co za tym idzie, poprawy jej pozycjonowania (mam na myśli roboty
googlowskie, które pokazują wyniki raczej bardziej atrakcyjnych witryn)

Średni wynik wczytywania witryny według googole analytics to 7,84 s - to
zbyt długi czas, jak na tak małą wage aplikacji.
Poza tym według narzędzi dla developerów wśród rzeczy, które powinny zostać
poprawione jest czas odpowiedzi serwera, włączenie kompresji, oraz podanie
czasu wygaśnięcia cookie.

Każda z tych rzeczy była poddawana próbie optymalizacji za pomocą .htaccess
(dodanie formuł za to odpowiedzialnych) poza czasem odpowiedzi serwera,
gdyż tego fizycznie nie jestem w stanie zrobić, tylko hostingodawca.
Każda z prób nie przyniosła efektów, bo sklep nadal nie zachowuję sie jak
powinien.

Przy próbie ustawienia czasu wygaśnięcia plików cookie dostałem informację
od jednego z Państwa konsultantów, że to tylko i wyłącznie wina aplikacji,
ale jeśli sam sklep po włączeniu opcji optymalizacji wygenerował sobie do
pliku .htaccess polecenie,
świadczy to o tym, iż działa on prawidłowo.

Dostałem informację, że problemem mogą być zbyt małe parametry hostingu,
ale po tygodniowym testowaniu domeny na BUSINESS SERVER, wyniki nadal nie
był zbyt zadawalające, a nawet prawie w ogóle się nie zmieniły (załączniki
są wynikami już po przejściu na BUSINESS SERVER)

Zostałem również uprzedzony, że powodem może być któryś rekord w bazie
danych, ale jak na tą aplikację z około 200 produktami aplikacja powinna
chodzić płynnie.

Sklep zachowuję się, jak by przy uruchomieniu generował się jakiś skrypt.
Nie mam pojęcia czy to jest związane z nie włączoną kompresją gzip, czy z
innym plikiem, ale proszę o podanie konkretnego pliku/procesu bo to
takowych informacji Państwo mają dostęp.
Porównując wyniki świeżo zainstalowanej aplikacji, podpiętej do subdomeny
wyniki są lepsze, ale nadal nie zadowalające

P.S. Dostałem instrukcję włączenia kompresji statyczne, oraz w locie, ale
żadna z nich nie zadziałała - jak by plik .htaccess nie był czytany, a w
przypadku kompresji w locie nie byłem w stanie jej ustawić, gdyż tam są
zawarte informacje o podaniu polecenia do index'u, zaś sklep korzysta z
plików .tpl i nawet podzielenie funkcji na dwie części tj. na dwa pliki:
header.tpl i footer.tpl nie przyniosło efektów

Proszę o analizę i podanie przyczyn ww problemów, oraz o jak najszybsza
odpowiedz

a ich wspaniała odpowiedz była taka:
 

 

 

Witam,

Uprzejmie informuję, iż Państwa usługa funkcjonuje w pełni poprawnie. Nasi administratorzy zauważyli jednak, iż wyłącznie pierwsze ładowanie strony trwa dłużej co jest związane z generowanie oraz umieszczaniem treści w cache aplikacji. Sugerujemy zatem kontakt z wybranym programistą celem zoptymalizowania funkcjonowania Państwa aplikacji pod tym kątem.

W razie pojawienia się pytań lub wątpliwości pozostajemy do dyspozycji.

Czy mogę, albo czy powinienem im coś więcej napisać?

Więc w ostateczności skoro zenbox nie działa prawidłowo, czy możecie coś polecić. Przetestował bym, jeśli jest możliwość i zobaczył czy jest różnica.

Share this post


Link to post
Share on other sites

Czesc

Musisz byc jakims masochista ;) zeby tyle czasu sie z tym uzerac

Home pomimo ze duzy hostingodawca to jednak marny

Sam korzystalem swego czasu z nazwy i przesiadka byla szybsza niz zainstalowanie softu (nazwa ni daje np. Memceched) duzy hosting duzo klientow bardzo maaalo czasu na odpowiedzi o analizach nie wspominajac

Przesiadz sie np na linuxpl - support masz online do 12 w nocy

Dodatkowych funkcji i mozliwych modyfikacji od groma

A cena na poziomie 50 zl za rok

Share this post


Link to post
Share on other sites

Heh lubię jak coś jest po mojej myśli, zwłaszcza jak mi za to zapłacą, albo zapłacili i chce, żeby to funkcjonowało ;p
Jeśli rozwiąże ten problem to tu napiszę ;p No i dziękuję za dotychczasową pomoc. Jak by komuś coś wpadło do głowy to stoję otworem na propozycje ;)

Share this post


Link to post
Share on other sites

Panowie!
Znalazłem rozwiązanie problemu.
Poza hostingiem od homa (przerzuciłem się na linuxpl - wer testowa W0), to jest wina i kwestia bazy danych, a dokładniej tego co bałem sie najbardziej i nawet nie chciałem tego proponować w przyczynach, żeby przypadkiem nie okazało się prawdą, a mianowicie atrybuty ;(.
Niektóre produkty posiadają po 200 atrybutów, część po 100 w połączeniu z 17 (a że one się mnożą przez siebie to jest 1700 kombinacji), cześć po 20, ostatnia część również koło 20...

Wychodzi na to, że to one obciążały sklep. Czyta instalka sklepu, podpięta baza danych ze starego, usunięta znaczna cześć atrybutów i sklep chodzi jak marzenie - nie całe 3 sec patrząc na gtmetrix.

Najgorsze jest to, że wybrałem prestę, bo tam jest możliwość wielu atrybutów, oraz ich łączenia.
I co teraz? Pytanie do wszystkich: Czy mogę sobie jakość z tym poradzić, zoptymalizować to, bądź w jakikolwiek sposób ominąć problem? Czy warto teraz szukać rozwiązania po stronie sklepu ?

P.S. Jest jakakolwiek różnica szybkości bazy danych pomiędzy InnoDB, a MylSAM ?
Pytam, gdyż linuxpl ma możliwość instalacji presty jednym kliknięciem, ale instaluje sklep z baza innodb.
W związku z tym, ze ja miałem mylsam i żeby nie konwertowac bazy, zainstalowałem sklep z plików ściągniętych z of strony, i tam wygrałem mylsam. - na homie miałem mylsam bo nie obsluguja innodb

Share this post


Link to post
Share on other sites

  • 6 months later...

Nie zawsze należy szukać błędów po stronie naszej witryny czy kodu.

U mnie był problem natury serwera. 
Strona wczytywała się długo bo serwer był słaby i nie nadążał z zapytaniami i po prostu mulił. 

Po zmianie serwera jest dużo lepiej strona wczytuje się w jakies 1,5-1,8s przy wadze 1.6MB.

Najwięcej zajmują .js i zdjęcia w formacie PNG- nieskompresowane.


Poza tym w google developers jest fajne narzędzie które podpowiada co może być przyczyna długiego ładowania strony : 

http://developers.google.com/speed/pagespeed/insights/?url=

 

wszystko opisane jasno i dosyć prosto.

 

Share this post


Link to post
Share on other sites

 Share

×
×
  • Create New...

Important Information

Cookies ensure the smooth running of our services. Using these, you accept the use of cookies. Learn More