Szybkość polskich stron internetowych cz. 2

Opisywany w poprzednim wpisie nt. badania szybkości polskich stron internetowych system trochę okrzepł, skończył się miesiąc, więc pora na konkrety. Co prawda listę badanych serwisów było widać na zrzucie ekranu, ale nie było dostępu do danych , więc teraz to naprawiam.

Zdecydowałem, że nie będę się bawił w wyciąganie średnich miesięcznych itp.  Jeśli ktoś jest zaintersowany, to w historii są linki do danych źródłowych (CSV), można sobie wyciągnąć samodzielnie. O ile ktoś będzie potrzebował, bo to, co domyślnie daje GTmetrix, z ładną wizualizacją, jest IMO w zupełności wystarczające.

Tak więc badanie wywoływane jest dla 10 wybranych serwisów (najpopularniejsze polskie oraz ecommerce, przy czym znaczenie miała domena) co 12h. Wykonywane z Londynu, przy pomocy Chrome, bez AdBlocka i na nielimitowanym paśmie.

Oto serwisy, po kliknięciu linka dostęp do wszelkich zebranych danych:

Jest jeszcze pomysł na uruchomienie testów za pośrednictwem innego serwisu. Jednak na razie pozostaje to w sferze pomysłów, póki co bez planów na implementację.

UPDATE: Pomysł na sprawdzanie szybkości polskich stron internetowych wyglądał fajnie, ale tylko przez miesiąc. Po pierwsze, okazało się, że dostępne są dane tylko z miesiąca, mimo obiecujących wartości „1y” i „all” w historii. Po drugie, skrypt wymaga poprawki – przez parę dni dane się nie zbierały, potem samoistnie zaczęły. Pewnie do poprawy obsługa wyjątków plus dodanie wysłania powiadomienia. Przy czym założenie, że mógłbym coś zrobić i że by mi się chciało jest mocno optymistyczne. Po trzecie i najważniejsze, zmieniły się linki do raportów. Powyższe już nie działają, co oznacza, że nawet wersja miesięczna jest średnio używalna dla kogokolwiek poza mną. Pomyślę jak to wszystko rozwiązać, pewnie skończy się na powrocie do oryginalnego pomysłu i zbierania danych samodzielnie.

Pomiar szybkości polskich stron internetowych

Podczas pewnej dyskusji nt. kondycji stron internetowych powołane zostało jako argument badanie szybkości stron internetowych robione przez firmę Hostersi. Jest to ciekawe badanie, prowadzone od lat ale… ma wady.

Pomiarów niby jest dużo, ale są one przeprowadzane przy pomocy autorskiego narzędzia uruchamianego ad hoc, przez tydzień. Samo badanie publikowane raz na rok. Wszystko to powoduje, że wyniki trudno jest weryfikować samodzielnie. Dodatkowo jakaś zmiana na stronie obecna w danym tygodniu, czy chwilowe problemy wydajnościowe serwisu mogą zaburzać wyniki dla całego roku. Co widać nawet w raporcie po niektórych dziwnych danych.

Dla jasności – szanuję wykonaną pracę. Jednak gdyby to zależało ode mnie, wolałbym mieć dane zbierane z dłuższego okresu, choć z mniejszą rozdzielczością. Czyli patrzeć na trendy powiedzmy kwartalne, kosztem podatności na błąd pojedynczego pomiaru. Ale w dłuższym okresie i tak się to uśredni.

I tak narodził się pomysł, żeby zbierać i publikować w miarę na bieżąco dane dotyczące szybkości działania polskich stron internetowych samodzielnie, hobbystycznie, w sposób umożliwiający każdemu chętnemu samodzielną weryfikację wyników pomiarów.

Stawianie własnej infrastruktury oczywiście odpadło w przedbiegach. Zbyt zasobochłonne, zarówno jeśli chodzi o koszt, jak i o samą czasochłonność utrzymania. Poza tym, odpadnie możliwość peer review. Jednak serwis GTmetrix daje ciekawe możliwości badania szybkości ładowania stron i daje API. Postanowiłem z niego skorzystać, co sprowadza pracę do napisania prostych skryptów w Pythonie. Dodatkowo pozwala dzielić się zebranymi danymi przy pomocy udostępniania unikatowych URLi.

Niestety, w wersji darmowej można robić tylko 20 zapytań po API dziennie. To wymusiło ograniczenie się do jednej lokalizacji (Londyn, jako najbliższy Polsce), jednej przeglądarki (Chrome bez AdBlocka). Musiałem też zmniejszyć liczbę badanych serwisów do 10 (wybrane na podstawie raportu Hostersi z najpopularniejszych i ecommerce) i wykonywania dla każdego 2 testów dziennie. Wybrałem okolice godziny 8 rano oraz 20. Z doświadczenia o 8 jest już jakiś – choć niewielki – ruch w sieci, a 20 to szczyt. Wyniki planuję publikować co miesiąc, jako średnie wartości z danego miesiąca.

Badane strony w GTmetrix

Póki co, uruchomiłem skrypt, który przy pomocy crona robi „taktowanie”, czyli zleca uruchomienie testów. Dane zbierają się od paru dni. Pomyślę jeszcze, czy zamieszczać jakieś statystyki co miesiąc, czy po prostu ograniczyć się do zbierania. Raczej stanie na tym drugim… Stay tuned!

Jak usprawnić sieć w domu? cz. 5

Wpis, który chronologicznie powinien pojawić się jako drugi, ponieważ dotyczy stanu wyjściowego, czyli WiFi. Oczywiście sprzęt to opisywany niedawno TP-Link WR841 z OpenWrt. Banana Pi wpięte do portu LAN, czyli na 100 Mbps, ale głównym ogranicznikiem jest sieć bezprzewodowa. Jasności dodam, że są to wyniki sprzed optymalizacji, ale o poprawianiu WiFi napiszę innym razem. Warto też zaznaczyć, że wyniki jako jedyne są przeprowadzane na środowisku nieizolowanym, „produkcyjnym”, tj. z podłączonymi innymi urządzeniami. O ile nie powinny specjalnie rzutować na wynik, bo nie korzystały intensywnie, to na pewno wpływały w jakiś sposób ujemnie.

1.
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  4]   0.00-60.04  sec   125 MBytes  17.5 Mbits/sec  10.997 ms  1908/16040 (12%)  
[  4] Sent 16040 datagrams

2.
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-60.00  sec  67.7 MBytes  9.46 Mbits/sec  186             sender
[  4]   0.00-60.00  sec  67.6 MBytes  9.45 Mbits/sec                  receiver

3.
— 192.168.0.139 ping statistics —
600 packets transmitted, 598 received, 0% packet loss, time 61057ms
rtt min/avg/max/mdev = 0.766/2.303/42.995/4.036 ms

4.
— 192.168.0.139 ping statistics —
600 packets transmitted, 596 received, 0% packet loss, time 60280ms
rtt min/avg/max/mdev = 1.918/3.953/42.202/3.747 ms

5.
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  4]   0.00-3600.04 sec  6.27 GBytes  15.0 Mbits/sec  4.305 ms  71880/822270 (8.7%)
[  4] Sent 822270 datagrams
[…]
9.
Inea Orange

Jak widać stan wyjściowy nie był imponujący. Rzekłbym nawet, że zaskakująco słabe wyniki. Widać też, że brakuje części testów – przyznaję, że nie miałem ani cierpliwości, ani warunków. Ponieważ ustawienia lekko się zmieniły w międzyczasie, zostawię z brakiem, żeby nie fałszować. Zaskakuje słaby wynik transmisji w teście syntetycznym, w szczególności w porównaniu z testem do internetu.