PORADNIK Szybkość działania Click Shopa - sugestie od Google

Skoro mówił o SSL, który być może coraz więcej osób dostrzega i bierze pod uwagę w kontekście konwersji, chciałem zwrócić uwagę i poprosić o możliwość przyspieszenia click shopa.

1. Jako firma hostingowa możecie wprowadzić opcję zmiany serwera na szybszy. W tej chwili średni czas oczekiwania na odpowiedź serwera wynosi 600-800ms. Jeżeli 40% internautów zamierza opuścić stronę, jeżeli ta wczytuje się ponad 3 sekundy, a opóźnienie strony o 1 sekundę powoduje dla strony mającej 1000 obrotu dziennego stratę roczną 25000, to odpowiedź serwera o ponad pół sekundy dłuższa niż sugerowana przez googla powoduje stratę 12500 obrotu. Jestem gotów zapłacić więcej za szybszy serwer - tylko to umożliwcie.
2. Skoro nie można ładować main.js asynchronicznie (bo sklep się sypie), to chociaż go zmniejszcie (choćby http://javascript-minifier.com/)

 

Gdzie Ty masz 600ms? sprawdziłem na 2 łączach i mam raptem max 2ms
64 bytes from xxx (xxx.xxx.xxx.xxx): icmp_seq=1 ttl=61 time=2.04 ms
64 bytes from xxx (xxx.xxx.xxx.xxx): icmp_seq=2 ttl=61 time=1.92 ms
64 bytes from xxx (xxx.xxx.xxx.xxx): icmp_seq=3 ttl=61 time=1.72 ms

Sprawdź swoje łącze

Nie ma też sensu tak drastycznie sugerować się wskazówkami odnośnie wielkości plików itd, tu trzeba do tematu podejść ostrożnie ale i bez paniki.

 

Test nr 1
https://developers.google.com/speed/pagespeed/insights/?url=http://furkidz.eu/&tab=desktop
Skróć czas odpowiedzi serwera

W naszym teście czas odpowiedzi serwera wyniósł 0,70 sekundy. Czas odpowiedzi serwera może być wydłużany przez wiele czynników. Zapoznaj się z naszymi zaleceniami i dowiedz się, jak monitorować i mierzyć działania, które zajmują serwerowi najwięcej czasu.

Test nr 2
http://www.webpagetest.org/result/150806_XC_VQM/




@Grzesiek a co poza samym analizowaniem może wyniknąć z tej usługi?

 

Mam klika sklepów homowych i każdy działa na kliknięcie, nie zauważyłem, żadnego spowolnienia na jednym z łącz mam do niego <1 ms więc chyba szybciej być nie może

 

@Grzesiek mój problem opisany w punkcie 1 dotyczy czasu odpowiedzi serwera, nie ładowania całej strony.
Poniżej przesyłam 6 testów szacunkowy czas oczekiwania na odpowiedź serwera to od ok. 0,4 sekundy do ok. 1 sekundy.






Hmm... u mnie na forum ich jakby nie widać, więc podaję linki:
ftp://furkidz.eu/1.png
ftp://furkidz.eu/2.png
ftp://furkidz.eu/3.png
ftp://furkidz.eu/4.png
ftp://furkidz.eu/5.png
ftp://furkidz.eu/6.png

PS. "raczej nie pokazują aż takich wartości jak u Ciebie. (...) przejście jest płynne." - mało precyzyjne sformułowania jak na przedstawiciela firmy hostingowej, nie sądzisz? {Być może się czepiam z gorąca }

PS2. Wiem co i dlaczego na mojej stronie się wczytuje długo - na jedne się godzę na inne nie. Opineo zwiększa konwersję bardziej niż zmniejsza ją przez czas wczytywania. Czas oczekiwania na odpowiedź serwera to czas stracony - nic na nim nie zyskuję a tylko tracę.

 

@TheL - jeżeli tak, to tym bardziej chciałbym naprawić to u siebie...

 

@Grzesiek mój problem opisany w punkcie 1 dotyczy czasu odpowiedzi serwera, nie ładowania całej strony.
Poniżej artykuł z https://developers.google.com/speed/docs/insights/Server - zwróć uwagę, że nie ma tu ani słowa o wielkości zdjęć, wielkości/ilości js czy css, etc.

Popraw czas odpowiedzi serwera
Ta reguła uruchamia się, gdy PageSpeed Insights wykryje, że czas odpowiedzi serwera przekracza 200 ms.

Omówienie
Czas odpowiedzi serwera to czas wczytywania kodu HTML niezbędnego do rozpoczęcia renderowania strony z serwera, po odjęciu czasu oczekiwania między Google a Twoim serwerem. Mogą wystąpić różnice pomiędzy poszczególnymi cyklami, ale nie powinny one być zbyt duże. W rzeczywistości duża zmienność czasu odpowiedzi serwera może sugerować problem z wydajnością.

Zalecenia
Powinieneś skrócić czas odpowiedzi serwera do mniej niż 200 ms. Spowolnienie odpowiedzi może być spowodowane przez wiele czynników: mało wydajne algorytmy aplikacji lub zapytania do bazy danych, powolny routing, architekturę, biblioteki, nadmierne wykorzystanie zasobów obliczeniowych procesora bądź pamięci. Poprawiając czas odpowiedzi serwera, musisz wziąć je wszystkie pod uwagę. Pierwszym krokiem do odkrycia przyczyny długiego czasu odpowiedzi serwera są pomiary. Następnie, mając dane pod ręką, poszukaj wskazówek, które pomogą rozwiązać problem. Po rozwiązaniu problemu kontynuuj pomiary czasu odpowiedzi serwera i na bieżąco usuwaj wąskie gardła.

 

Gdzie Ty masz te 200ms odpowiedzi serwera?

Kod:

thel@thel:~$ ping furkidz.eu
PING furkidz.eu (79.96.143.219) 56(84) bytes of data.
64 bytes from v087341.home.net.pl (79.96.143.219): icmp_seq=1 ttl=61 time=1.94 ms
64 bytes from v087341.home.net.pl (79.96.143.219): icmp_seq=2 ttl=61 time=2.30 ms
64 bytes from v087341.home.net.pl (79.96.143.219): icmp_seq=3 ttl=61 time=2.42 ms
64 bytes from v087341.home.net.pl (79.96.143.219): icmp_seq=4 ttl=61 time=2.16 ms
64 bytes from v087341.home.net.pl (79.96.143.219): icmp_seq=5 ttl=61 time=1.76 ms
64 bytes from v087341.home.net.pl (79.96.143.219): icmp_seq=6 ttl=61 time=2.02 ms
64 bytes from v087341.home.net.pl (79.96.143.219): icmp_seq=7 ttl=61 time=2.01 ms
64 bytes from v087341.home.net.pl (79.96.143.219): icmp_seq=8 ttl=61 time=2.04 ms
64 bytes from v087341.home.net.pl (79.96.143.219): icmp_seq=9 ttl=61 time=1.91 ms
64 bytes from v087341.home.net.pl (79.96.143.219): icmp_seq=10 ttl=61 time=1.66 ms
64 bytes from v087341.home.net.pl (79.96.143.219): icmp_seq=11 ttl=61 time=1.70 ms
64 bytes from v087341.home.net.pl (79.96.143.219): icmp_seq=12 ttl=61 time=1.76 ms
64 bytes from v087341.home.net.pl (79.96.143.219): icmp_seq=13 ttl=61 time=1.82 ms
64 bytes from v087341.home.net.pl (79.96.143.219): icmp_seq=14 ttl=61 time=2.07 ms
64 bytes from v087341.home.net.pl (79.96.143.219): icmp_seq=15 ttl=61 time=2.32 ms
64 bytes from v087341.home.net.pl (79.96.143.219): icmp_seq=16 ttl=61 time=2.14 ms
64 bytes from v087341.home.net.pl (79.96.143.219): icmp_seq=17 ttl=61 time=2.79 ms
64 bytes from v087341.home.net.pl (79.96.143.219): icmp_seq=18 ttl=61 time=1.99 ms
64 bytes from v087341.home.net.pl (79.96.143.219): icmp_seq=19 ttl=61 time=1.71 ms
64 bytes from v087341.home.net.pl (79.96.143.219): icmp_seq=20 ttl=61 time=1.66 ms
64 bytes from v087341.home.net.pl (79.96.143.219): icmp_seq=21 ttl=61 time=2.12 ms
64 bytes from v087341.home.net.pl (79.96.143.219): icmp_seq=22 ttl=61 time=2.81 ms
64 bytes from v087341.home.net.pl (79.96.143.219): icmp_seq=23 ttl=61 time=1.95 ms
64 bytes from v087341.home.net.pl (79.96.143.219): icmp_seq=24 ttl=61 time=2.24 ms
64 bytes from v087341.home.net.pl (79.96.143.219): icmp_seq=25 ttl=61 time=2.34 ms
64 bytes from v087341.home.net.pl (79.96.143.219): icmp_seq=26 ttl=61 time=2.17 ms
64 bytes from v087341.home.net.pl (79.96.143.219): icmp_seq=27 ttl=61 time=2.21 ms
64 bytes from v087341.home.net.pl (79.96.143.219): icmp_seq=28 ttl=61 time=3.60 ms
64 bytes from v087341.home.net.pl (79.96.143.219): icmp_seq=29 ttl=61 time=2.07 ms
64 bytes from v087341.home.net.pl (79.96.143.219): icmp_seq=30 ttl=61 time=1.81 ms

 

@TheL Twoje zapytania 64bajtowe raczej nie odwołują się do bazy danych sklepu. A w zasadzie nie raczej tylko na pewno. Po prostu przyjmują pakiet 64bajtów i go odbijają z powrotem.
Jak sobie spingujesz onet.pl przez cmd i narzędzia typu ping.pl, pingdom.com czy w googlu masz bardzo podobne wartości rzędu kilku kilkunastu ms.
Dlaczego? Bo robią wszystko co w ich mocy, żeby je zminimalizować, w tym mają serwery odpowiednio szybkie.

I dlatego @Grzesiek raz jeszcze zadaję pytanie o możliwość przejścia na szybszy serwer.

Istotna uwaga: wiem, że w tej chwili mój sklep działa akceptowalnie. Robię ze swojej strony wszystko co możliwe (w zeszłym tygodniu soptymalizowałem 2200 zdjęć na stronie i zmniejszyłem ich objętość o 2/3), żeby działał szybciej. Kompresuję dodatkowe js, rezygnuję z niepotrzebnych dodatków... Ale są dwa tematy zabierające jeszcze dość dużo czasu - nieskompresowany main.js i czas odpowiedzi serwera.

I jeszcze raz podkreślam:

 

Czas odpowiedzi serwera to właśnie odpowiedź na ping. Co innego czas generowania strony i paczka danych do przesłania. Mam kilka sklepów clickshop i zauważyłem, że działają bardzo szybko, nawet jeśli wyczyszczę cache to rozsądnie się wczytują.
Mnie najbardziej martwi, że nie mogę ustawić czasu życia zdjęć css i js w cache przeglądarki to już by maksymalnie przyśpieszyło stronę, pierwsze wczytanie normalne, potem właściwie jak z własnego komputera

 

Możesz Dodaj w htaccess
:Location *.(js|jpg|jpeg|png|gif|css|pdf|swf|ico)
Expires M31536000

 

Tutaj znajdziesz dodatkowe informacje, które potwierdzą wpis Dominika .
https://pomoc.home.pl/baza-wiedzy/j...-pliku-htaccess-na-serwerach-wspoldzielonych/

 

ja wiem, że w htaccess można, ale ja chciałem inaczej bo część plików ma być zmienna dość dynamicznie itd, a robić cała listę reguł to trochę mi się nie chcę

 

Czekam, czekam

 

Nic nie dadzą serwery dedykowane ani VPS. Google i tak "będzie wiedziało swoje"
Ani sklep ani serwery nie są wolne, sam to starałem się ostatnio ogarnąć jak zobaczyłem co różne testy pokazują i co ciekawe zróbcie sobie test i uruchomcie nawet prostą stronę z kilkoma zdjęciami większymi, ale skompresowanymi jpg na 85%, dodajcie jakikolwiek js z 5 KB i z 5 KB textu, strona będzie działała wg różnych testów wolno.
Coś to google chyba przesadza
Wiele z tych testów w necie też nie jest wiarygodne, nie wiem z czym mają ich serwery sesje, ale chyba z Polską się łączą przeskakując najpierw cały świat. Puście przykładowo tracerta do webpagetest.org te testy nie mają prawa działać dobrze