Optymalizacja strony

Kolejny wpis, który przeleżał wiele czasu jako szkic. Nie znalazłem na niego czasu, a teraz sprawdziłem i dobrze się zestarzał, więc opublikuję to, co mam, choć nie pociągnąłem do końca tematu, którym jest optymalizacja stron WWW, tym razem bardziej od strony serwera, niż WordPressa, o którym wtedy napisałem.

Na początek polecam wpis Yzoji o optymalizacji bloga. I komentarze do niego. Tak, wpis jest sprzed trzech lat. Tak, jest aktualny, a wszystko co tu znajdziesz powstało właśnie wtedy. Raczej postaram się napisać uzupełnienie, niż powtarzać rady z tamtego wpisu.

Efekty

Nie mam niestety porównania sprzed wprowadzania zmian, ale żeby było wiadomo o czym rozmawiamy. Efekty optymalizacji strony bloga, wg PageSpeed Insights, przedstawiają się następująco:

Wynik optymalizacji strony wg PageSpeed dla desktop - performance 100%
Wynik dla desktop
Wynik optymalizacji strony wg PageSpeed wynik dla mobile - performance 9%
Wynik dla mobile

Kompresja

Na przyspieszenie działania bloga pomogło zmniejszenie poziomu kompresji w nginx. Tak, dobrze czytacie, zmniejszenie, nie zwiększenie. Dlaczego? Otóż tekst kompresuje się dobrze tak czy inaczej. A różnice w szybkości działania kompresji gzip są znaczne. Czyli mamy mininalnie większą ilość przesyłanych danych, ale odpowiedź jest wysyłana znacznie szybciej! Być może to kwestia relatywnie słabego VPSa, ale skoro nie widać różnicy, po co przepłacać? W każdym razie w konfiguracji nginx mam:

gzip_comp_level 1;

Lazy loading

Kolejną rzeczą, która przyspieszyła działanie tego bloga było wyłączenie lazy loading. Było o tym u Yzoji, ale warto powtórzyć, bo znowu, jest to nieintuicyjne. W dodatku wszyscy mantrują, że włączenie lazy loadingu jest dobre dla szybkości ładowania. No i teoretycznie mają rację. Ale nie jest to prawdą na stronach, gdzie ilość załączanych grafik jest niewielka. Więc jak mam jedną czy w porywach dwie skromne grafiki na wpis, to lazy loading tylko spowolni ładowanie. Gdyby grafik było więcej lub były większe – pewnie włączenie lazy loadingu mógłoby pomagać.

Google

Wyłączenie zabawek Google. Firma ta prezentuje pewną dwumyślność. Z jednej strony chce, by strona działała szybko. Z drugiej strony, sama dostarcza rozwiązania, które fatalnie wpływają na wydajność strony i stwarzają problemy w ich własnym scoringu! Google Analytics – wydajnościowe zło. Fonty Google – kolejne wydajnościowe zło. Google AdSense też drastycznie pogorszy szybkość działania strony.

Rozwiązanie, jeśli nie chcemy całkiem pozbywać się Google? W przypadku AdSense można zrezygnować z wyświetlania reklam wszędzie i ograniczyć ich obecność do wpisów, na których jest największy ruch. Taki kompromis – strony z reklamami będą ładować się dłużej, ale większość stron będzie działać szybko. Oczywiście wiąże się to z rezygnacją z reklam na głównej. Nieco upierdliwe, bo oznacza to ręczne zarządzanie kodem JS odpowiedzialnym za wyświetlanie reklam na poziomie konkretnych wpisów, ale dla mnie OK. Zamiast Google Analytics polecam Matomo. Z fontów Google zrezygnowałem, zamiast tego pewnie można serwować je lokalnie.

Klucz RSA

Kolejna nieoczywista sprawa – rozmiar klucza wykorzystywanego przy SSL/TLS. Miałem podejście security is our priority i klucz RSA o długości 4096 bitów. Tyle tylko, że póki co 2048 bity są także uznawane za bezpieczne. No i na tym blogu nie ma nic wrażliwego. Najbardziej wrażliwe jest hasło, które przesyłam przy logowaniu, więc zmniejszyłem rozmiar klucza i… Pomogło to skrócić czas nawiązywania połączenia z serwerem. Znowu, może kwestia stosunkowo słabego VPSa. Przy tej okazji polecę jeszcze wpis o tym jak zrobić sobie certyfikat SSL/TLS z oceną A+ na nginx.

Jak widać, optymalizacja stron WWW nie jest oczywista i warto do tematu podejść kompleksowo.

Googlowe rozdwojenie jaźni

Zawsze, gdy sprawdzam szybkość działania strony, zastanawiam się, czy Google cierpi na rozdwojenie jaźni. Z jednej strony bowiem promuje szybkie strony i dostarcza narzędzia do badania szybkości stron WWW. Z drugiej strony największym spowalniaczem stron są… reklamy AdSense od Google.

Nic nie generuje tylu ostrzeżeń o spowolnieniu strony, co umieszczenie reklam AdSense. Także w samych narzędziach Google. Spójrzmy na wyniki z GTmetrix (dla porządku: to nie narzędzie Google) dla strony na tym blogu z reklamami oraz strony bez reklam:

Wynik GTmetrix dla strony z AdSense
Wynik GTmetrix dla strony bez AdSense

Różnica powyżej nie jest może powalająca, ale jeśli spojrzymy na wyniki waterfall, robi się ciekawiej:

OK, trafiło się pechowo, bo jakieś video było w reklamie. Niemniej, trend jest jasno widoczny.

Narzędzie od Google pokazuje, że cierpią głównie użytkownicy mobilni. Dla powyższych URLi wyniki PageSpeed Insights wyglądają następująco:

PageSpeed Insights z AdSense
PageSpeed Insights bez AdSense

Widać, że cierpi głównie wydajność, ale nie tylko. Dostępność też się pogorszyła.

Czyli mamy sprzeczność. Z jednej strony szybsze strony lepiej się indeksują i są odwiedzane przez większą ilość użytkowników. Czyli lepiej nadają się do wyświetlania reklam. Z drugiej strony włączenie reklam AdSense spowolni je, co w dłuższym okresie może spowodować pogorszenie pozycji w wyszukiwarce i mniej odwiedzin. Albo rezygnację użytkowników z oczekiwania na załadowanie strony.

Jak żyć? Oczywiście jeśli chodzi o szybkość działania strony, to oczywiście najlepszy efekt da całkowite usunięcie reklam. Jeśli jednak z jakiegoś powodu nie chcemy całkiem rezygnować z wyświetlania reklam AdSense, a chcemy, by witryna działała szybko, to można ograniczyć ich wyświetlanie tylko do wybranych stron. Na przykład takich z największym ruchem z wyszukiwarki. Jest to oczywiście jakiś kompromis, w dodatku niezbyt wygodny utrzymaniu. Jednak dzięki temu co do zasady jest szybko, a zachowujemy większość dochodu z reklam. To oczywiście jakieś grosze. No i człowiek nie traci kontaktu z tym ekosystemem.

Google, he knows me

Dostałem maila od Google. Na stronie wykryto błędy, kod błędu 403. Sprawa mnie zaintrygowała. Co prawda chodziło tylko o jeden URL, ale czemu 403? Błędy 5xx czy 404 bym zrozumiał jeszcze, zwłaszcza na blogu, ale 403? Coś się tu zdecydowanie nie zgadza.

Rozpocząłem dochodzenie i zrobiło się dziwniej. Bowiem chodziło o zupełnie egzotyczny URL ( hxxps://zakr.es/tststs/ ). Na oko poprawny, ale ewidentnie tymczasowy i testowy. I zdecydowanie nie należący do bloga. W ogóle byłem zdziwiony, że Google o nim wie.

And he knows I’m right

Pierwsze co przyszło mi do głowy to robots.txt. Może dlatego, że sugerują sprawdzenie, czy dostęp nie jest tam blokowany? W każdym razie pudło. Zresztą nawet gdyby tam URL był, to raczej jako wykluczenie dla botów. A wtedy zgłaszanie braku dostępu byłoby sporą bezczelnością.

Zajrzałem do katalogu na serwerze i przypomniało mi się, że testowałem pewną rzecz. Powiedzmy, że okolice bug bounty. Tak, robienie tego na podstawowej domenie to zwykle kiepski pomysł, ale tym razem kluczowa miała być obecność naturalnego ruchu. Tak czy inaczej nic z tego nie wyszło, tj. nie udało mi się wykorzystać w planowany sposób. A katalog pozostał, choć już niewykorzystany. I nielinkowany.

Analiza

Google webmaster tools[1] pokazuje, skąd jest linkowana dana strona. W tym przypadku podał dwie strony na blogu. Jedną z konkretnym wpisem, drugą zbiorczą.

Strona odsyłająca
https://zakr.es/blog/author/rozie/page/6/
https://zakr.es/blog/2015/10/spis-wyborcow-a-rejestr-wyborcow/

Tyle, że w podglądzie źródła tego ostatniego wpisu to ja tego URLa w żaden sposób nie widzę.

Jak to wygląda czasowo? Kolejna ciekawostka to kolejne dwie daty w Google webmaster tools:

Data pierwszego wykrycia: 31.08.2022

Zapewne wtedy się bawiłem. Daty utworzenia plików potwierdzają – wszystkie pliki mają 03.08.2022. Ma to jakiś sens, tylko musiałbym zostawić pliki podlinkowane na miesiąc? Raczej niemożliwe, bo wtedy zostałyby na stałe. A nie ma. No i skąd by się wzięły w tak starym wpisie?

Ostatnie skanowanie 5 maj 2023, 11:47:16

To oczywiście możliwe, tym bardziej, że Google zauważyło błąd 403 dokładnie 3 maja 2023. Po ponad pół roku?

I’ve been talking to Google all my life

Jeśli chodzi o Google, to mamy love hate relationship. Z jednej strony doceniam firmę za GCTF, czy zabezpieczenia poczty i kont. Z drugiej strony to, co robią z prywatnością userów, nachalność reklam, tragiczny, scamerski content części reklam bąbelkowanie w wyszukiwarce i wreszcie samo bycie globalną korporacją mocno mnie odstręczają.

Ostatecznie jest tak, że umiarkowanie korzystam z ich usług. Trochę, bo wygodne, trochę, bo wypada znać. Mam webmaster tools, mam reklamy AdSense, ale tylko w wybranych miejscach. Pozwalam indeksować blog. Raczej nie korzystam z ich wyszukiwarki, tj. sięgam do niej tylko, jeśli nie znajdę wyników w podstawowej, czyli rzadko. Inne usługi Google, czyli np. Maps, Waze, translate, calendar, drive, docs – różnie, raczej korzystam, choć w ograniczonym stopniu.

Częściowe wyjaśnienie

Spojrzenie w logi serwera mówi nieco więcej:

66.249.65.223 - - [28/Aug/2022:20:35:53 +0200] "GET /tststs/ HTTP/1.1" 403 187 "-" "Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/104.0.5112.79 Mobile Safari/537.36 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
66.249.70.63 - - [30/Aug/2022:20:53:52 +0200] "GET /tststs/ HTTP/1.1" 403 187 "-" "Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/104.0.5112.79 Mobile Safari/537.36 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
66.249.64.227 - - [30/Apr/2023:22:32:01 +0200] "GET /tststs/ HTTP/1.1" 403 187 "-" "Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/112.0.5615.142 Mobile Safari/537.36 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
66.249.64.231 - - [03/May/2023:10:44:18 +0200] "GET /tststs/ HTTP/1.1" 403 187 "-" "Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/112.0.5615.142 Mobile Safari/537.36 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
66.249.64.229 - - [05/May/2023:11:47:16 +0200] "GET /tststs/ HTTP/1.1" 403 187 "-" "Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/112.0.5615.142 Mobile Safari/537.36 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"

Część rzeczy się zgadza, np. wizyty kiedy Google zauważyło i zaindeksowało URL, po miesiącu od zamieszczenia plików. Widać też wizyty 03.05, kiedy sobie o nim ni stąd ni zowąd przypomniało. Mogło się też zdarzyć, że do testów wziąłem jakiś stary wpis z 2015.

Nadal nie zgadza się – albo nie mogę sobie przypomnieć – jak to się stało, że URL został na miesiąc, a nie został na stałe. I słodką tajemnicą Google pozostanie, czemu zapomniało o tym URLu na bite osiem miesięcy.

Usunąłem katalog z serwera. Może teraz Google, gdy dostanie 404, zapomni o nim na dobre?

[1] Obecnie Google Search Console, ale przywykłem do starej nazwy, więc przy niej zostanę, przynajmniej w tym wpisie.