Speedtest od Google

Jak to jest z tym speedtestem?
https://developers.google.com/speed/pagespeed/insights/?hl=pl

Pracuje dla klienta, który chce zoptymalizować swoją stronę właśnie pod kątem tego testu. Jednak wyniki bardzo się tam wahają w jeden dzień jest 50/100, w drugi 30/100. Natomiast jeśli uruchomie test w przeglądarce Chrome (w narzędziach developera) to wynik jest stały (75/100). I mówimy tutaj o teście na urządzenia mobilne w obu przypadkach.

Tak z ciekawości wpisalem 4programmers i wyskoczyło 20/100. Stąd moje pytanie - czy ma to jakiś wpływ na indeksowanie strony pzez Google?

O kant pupy ten test tłuc - na nim nawet google.com na chromie nie ma stówki.

W Chrome audit zwykle wszystko pokazuje, na stronie obecnie pewnie mają jakiś błąd z tego co widzę.

Tak, szybkość strony ma duży wpływ na indeksowanie oraz na pozycje SEO. Bardziej wiarygodny jest webpagetest.org. Wskaźnik speed index dla stron mobilnych (na sieci 3G) powinien optymalnie wynosić ok. 3000, dla desktop na połączeniu kablowym ok. 1500. Oczywiście im mniejszy tym lepiej, wachania zawsze będą ale raczej w granicach 10-20%, tak wynika z mojego doświadczenia.

Rzeczywiście :D Nawet google.com nie ma 100 tylko 70 coś. To już moje portfolio ma 80. Czyli najlepiej sugerować się testami w Chrome?

Samym audytem w chrome czemu nie, czasami daje tam dobre podpowiedzi odnośnie wielkości obrazków, czy skryptów.

axelbest napisał(a):

O kant pupy ten test tłuc - na nim nawet google.com na chromie nie ma stówki.

Nie test potłuc o kant pupy, tylko strony, które ładują setki kilobajtów zbędnych skryptów i CSS oraz niezoptymalizowane obrazki :p

Z tego co widzę, to nawet poluzowali oceny, bo mój blog aktualnie wyciąga: 99 na komórki i 100 na komputery, a wcześniej plasował się gdzież w 80/95.

Natomiast czepić się tam mogę dwóch rzeczy:

• czytelność wyników i wygoda przeglądania tego jest przyzerowa, naprawdę inne testy robią to lepiej:
  https://www.uptrends.com/tools/website-speed-test
  https://tools.pingdom.com
  https://gtmetrix.com
  https://www.webpagetest.org/https://www.webpagetest.org
  https://webspeed.intensys.pl

• druga rzecz to fakt, że ten test jest (a w każdym razie bywał) trochę bezmyślny i jak miałeś dwie grafiki po 1KB, które się dało odchudzić do 500 bajtów, to już krzyczał i płakał, a jak nawaliłeś 10 (dobrze zoptymalizowanych) ale bezsensownie wielkich grafik po 100KB, to nie widział problemu.

MasterOf napisał(a):

Pracuje dla klienta, który chce zoptymalizować swoją stronę właśnie pod kątem tego testu. Jednak wyniki bardzo się tam wahają w jeden dzień jest 50/100, w drugi 30/100.

Czy strona zmienia swoją zawartość?

Tak z ciekawości wpisalem 4programmers i wyskoczyło 20/100. Stąd moje pytanie - czy ma to jakiś wpływ na indeksowanie strony pzez Google?

Tak, obecnie to jeden z czynników:
https://www.ecommerce2day.pl/wolno-ladujace-sie-strony-wypadna-z-google
https://mensis.pl/google-bedzie-karac-zbyt-wolno-ladujace-sie-strony

Czyli ogólnie porządny content na WordPressie przegra z kancerogennymi gniotami, które zaladuja się szybciej? No ciekawie się zapowiada.

axelbest napisał(a):

Czyli ogólnie porządny content na WordPressie przegra z kancerogennymi gniotami, które zaladuja się szybciej? No ciekawie się zapowiada.

To tylko jeden z czynników, więc sensowny i sensownie podlinkowany kontent wygra z bezsensownym ale odpalonym na rakiecie. No chyba, że to faktycznie będą jakieś czasy ładowania rzędu nastu sekund, bo dochodzimy ostatnio i do takiej patologii.

Jednak czasami zmiana o 1s powoduje wzrost z 30pkt do 70. Przecież to jest nielogiczne. Ogólnie na jakiej zasadzie ten test działa?

Na jakość strony według google najważniejsze są:
Progressive Web App - ładowanie strony przy słabym połączeniu, dostęp do strony w każdej sytuacji
Performance - optymalizacja skryptów (np. async/defer), css, images, mobile images, kompresja-gzip, cache, szybkość renderowania strony
Accessibility - dostęp i jasność elementów na stronie, dokładny opis, język, rwd, mobile
Best Practices - HTTPS, brak błędów itp.
SEO - tu wiadomo poprawna składnia html, alt itp.

MasterOf napisał(a):

Jednak czasami zmiana o 1s powoduje wzrost z 30pkt do 70. Przecież to jest nielogiczne. Ogólnie na jakiej zasadzie ten test działa?

Dlaczego nielogiczne? Jeśli urwiesz jedną sekundę z ogólnych trzech to tak by właśnie wychodziło :)

Szczegółów nie znam, ale z tego co widzę, to patrzą tu nawet nie tyle na czas, co na to na ile strona jest zoptymalizowana pod kątem szybkości. Dostajesz pełną listę możliwych poprawek oraz listę poprawnie zaliczonych testów.

o ****

odpaliłem stronę na webassembly, które ładuje 4MB dllek i dostałem scora 94 :D!

edit

Ta część ma sens ponieważ tylko bada prędkość renderowania strony, czyli to co odbiorca otrzymuje w najkrótszym czasie oczekiwania, aczkolwiek pełnego audytu byś nie przeszedł na zielono więc nie wiem w czym problem.
U mnie np. wykrył, że nie mam przekierowania z http->https i już zacząłem się pienić, bo przecież to wykonałem, a okazało się, że zrobiłem w literówkę w przekierowaniu htaccess czyli czasami się przydaje ;)

Ja tak tylko ogólnie powiem odnośnie Google PageSpeed Insights. Google ma u nas ponad 95% runku, dlatego moim zdaniem jest mieć lepsze wyniki niż mieć gorsze, nawet gdyby google w tej chwili na to nie zwraca kompletnie uwagi. Przyjdzie czas, że google zacznie brać pod uwagę wyniki, a wtedy będą mieli lepiej Ci co mają lepsze ;)

Test nie jest zły. Różne wyniki tej samej strony mogą wynikać z obciążenia samego serwera, które się zmienia w czasie. Ale nie ma co się nastawiać na 100%, bo niektóre zalecenia, które się pojawiają w audycie spowodują spowolnienie ładowania. Np. przekierowania w .htaccess, ssl, sugestie związane z dostępnością (np. dopisanie aria-label). Lepiej wykonać audyt w Chrome, bo tam oceniane są dodatkowe czynniki. To, co możesz zrobić to zrezygnowanie z ładowania niepotrzebnych bibliotek (css i js) i zastąpienie ich własnymi dostoswanymi wersjami (np. w SASS) + usunięcie zbędnego kodu css i minifikacja z zastosowaniem np. uncss i js z zastosowaniem uglify, ładowanie niektórych zasobów asynchronicznie, stosowanie lazy-loading, optymalizacja obrazów + stosowanie formatu webp + ładowanie mniejszych wersji obrazów dla urządzeń mniejszych (ja np. stosuję po 3 różne wersje), ładowanie niepotrzebnych od razu treści dynamicznie z użyciem js (np. galerii zdjęć) itd.

Odnośnie obrazów, to "Panda" jest bardzo pouczająca:
https://tinypng.com/
Oczywiście nawet ona nie pomoże komuś, kto wrzuca obrazek 1000x1000, żeby go później wyświetlić jako ikonkę 50x50.

Tego typu stron jest wiele. Do samego skalowania i kadrowania najlepiej użyć https://www.birme.net bo nie ma ograniczeń na ilość zdjęć w jednym wczytaniu. Ale później i tak trzeba użyć kompresji, a tutaj większość stron w wersji bezpłatnej ma ograniczenie do max. 30 obrazów po zalogowaniu (np. iloveimg.com). Jeśli się używa node.js to lepiej jest użyć narzędzi w stylu sharp, compress-images czy webp lub inne (w zależności od operacji, którą się chce wykonać). Wtedy można bardzo szybko przetworzyć bardzo dużą ilość obrazów.

Jestem tylko ciekaw czy nie obcina za bardzo jakości, bo zjazd z 24bitów na 8 musi się gdzieś odbić, szczególnie na cieniowaniu itp.

Zmniejszenie 80 procentowe (czyli redukcja do 20%) praktycznie jest nie do zauważenia (wiadomo, że jakby się porównało rysunki w dużym powiększeniu to się człowiek czegoś doszuka), ale jakość jest naprawdę dobra. Ponadto nie dochodzi do redukcji do 8 bitów, tylko uśredniania bardzo podobnych kolorów, co tylko nieznacznie zmniejsza ilość możliwych do wystąpienia kolorów (na rzeczywistym obrazie nigdy nie występują wszystkie możliwe kolory).

Zresztą najlepiej jest sprawdzić, bo większość tego typu stron nie wymaga logowania (po zalogowaniu zwiększają się tylko możliwości).

https://gtmetrix.com/ - to narzędzie polecam do mierzenia prędkości.

backlinks sie napisał(a):

https://gtmetrix.com/ - to narzędzie polecam do mierzenia prędkości.

Też czasami potrafi ci zaniżyć ocenę za obrazki, które mogły być skompresowane o 1kb więcej ;)