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.

Ventura

Trochę późno, bo dopiero wczoraj zaktualizowałem system do wersji Ventura. Biorąc pod uwagę mój stosunek do aktualizacji macOS, ta była wyjątkowo sprawna. Szczególnie biorąc pod uwagę rozmiar. Jednak w sumie nie widzę zmian godnych uwagi – trochę inne kolory, ot co.

Skoro jednak jest już pretekst, do wpisu, to przetestowałem nową wersję hashcata (v6.2.6-320-g9acfc26d8) na nowej wersji systemu. W stosunku do poprzedniej wersji, jest szybciej. Istotnie szybciej, nawet o 50% w niektórych przypadkach:

METAL API (Metal 306.3.5)
=========================
* Device #1: Apple M1 Pro, skipped

OpenCL API (OpenCL 1.2 (Dec 16 2022 20:37:40)) - Platform #1 [Apple]
====================================================================
* Device #2: Apple M1 Pro, GPU, 960/21845 MB (2048 MB allocatable), 16MCU

Benchmark relevant options:
===========================
* --optimized-kernel-enable

-------------------
* Hash-Mode 0 (MD5)
-------------------

Speed.#2.........:  6542.3 MH/s (0.97ms) @ Accel:64 Loops:1024 Thr:256 Vec:1

----------------------
* Hash-Mode 100 (SHA1)
----------------------

Speed.#2.........:  2718.3 MH/s (2.35ms) @ Accel:128 Loops:1024 Thr:128 Vec:1

---------------------------
* Hash-Mode 1400 (SHA2-256)
---------------------------

Speed.#2.........:   983.4 MH/s (6.52ms) @ Accel:64 Loops:1024 Thr:256 Vec:1

No i jeszcze md5crypt:

------------------------------------------------------------------------------
* Hash-Mode 500 (md5crypt, MD5 (Unix), Cisco-IOS $1$ (MD5)) [Iterations: 1000]
------------------------------------------------------------------------------

Speed.#2.........:  2516.6 kH/s (1.13ms) @ Accel:128 Loops:1000 Thr:64 Vec:1

Hashcat na M1

Jakiś czas temu pisałem o przesiadce na M1. Musiałem użyć hashcata i… przypomniało mi się, że nowe M1 ma poważną zaletę, w postaci szybkości. Żeby zobaczyć faktyczną różnicę, pozwoliłem sobie na nanobenchmark.

Nawiązując do starego wpisu o przyspieszaniu hashcata, sprawdziłem md5crypt:

* Hash-Mode 500 (md5crypt, MD5 (Unix), Cisco-IOS $1$ (MD5)) [Iterations: 1000]
Speed.#1.........:  1902.0 kH/s (53.57ms) @ Accel:512 Loops:500 Thr:32 Vec:1

Drobne cztery razy szybciej w stosunku do starego laptopa. Nie powala, ale wzrost przyjemny. Sprawdźmy więc inne typy hashy:

METAL API (Metal 263.8)
=======================
* Device #1: Apple M1 Pro, 10880/21845 MB, 16MCU

OpenCL API (OpenCL 1.2 (Apr 19 2022 18:44:44)) - Platform #1 [Apple]
====================================================================
* Device #2: Apple M1 Pro, skipped

Benchmark relevant options:
===========================
* --optimized-kernel-enable

-------------------
* Hash-Mode 0 (MD5)
-------------------

Speed.#1.........:  5713.7 MH/s (92.80ms) @ Accel:1024 Loops:1024 Thr:32 Vec:1

----------------------
* Hash-Mode 100 (SHA1)
----------------------

Speed.#1.........:  2031.9 MH/s (64.99ms) @ Accel:256 Loops:1024 Thr:32 Vec:1

---------------------------
* Hash-Mode 1400 (SHA2-256)
---------------------------

Speed.#1.........:   598.6 MH/s (54.90ms) @ Accel:64 Loops:512 Thr:64 Vec:1

Jakieś dwanaście razy szybciej w przypadku MD5 w stosunku do poprzedniego laptopa. Albo połowa wydajności Tesla 4. Miło. Jako podręczna maszynka w zupełności wystarczające.

Wszystkie powyższe wyniki benchmarków robione dla M1 z 10 core CPU i hashcata w wersji v6.2.5-516-g372d3a127.

Tym, którzy nie mają dostępu do M1, zostają inne sposoby, np. poproszenie Google o użyczenie mocy obliczeniowej.