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, ale pozostaje to w sferze pomysłów, póki co bez planów na implementację.

UPDATE: Pomysł 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, choć 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 wysyłać powiadomienia o nowych wpisach na blogu do blabler.pl

Z serwisu blabler.pl, będącego następcą Blip.pl, aktywnie nie korzystam od dłuższego czasu, a nawet bardzo rzadko czytam. Jedyne co tam trafiało, to powiadomienia o nowych wpisach na blogu, realizowane skryptem w Perlu – zawsze to dotarcie do paru czytelników.

Skrypt był dostosowany do RSS z Blox, z paroma naleciałościami, więc po migracji na WordPressa przestał działać. Stwierdziłem, że to świetna okazja by zapoznać się – bardzo pobieżnie – z mechanize (odpowiednik genialnego WWW::Mechanize z Perla) w Pythonie.

Tak powstał skrypt umożliwiający śledzenie wordpressowego RSS i wysyłający informację o nowym wpisie na blogu do serwisu blabler.pl. Do użycia z crona. Raczej nie planuję rozwoju, pomijając naprawę ew. błędów, a takie mogą się zdarzyć, zwł. dotyczące kodowania pl-znaków, bo zupełnie tego nie testowałem, ale może się komuś przyda.

Feedburner wymaga IPv6

Od jakiegoś czasu w zadaniach do zrobienia miałem następujące zadanie związane z migracją bloga w nowe miejsce: poprawić RSS Feedburner. Teoretycznie to są trzy kliknięcia, ale przy próbie zmiany źródła feeda dostawałem niewiele mówiący komunikat:

An error occurred connecting to the URL: unknown error

W logach serwera brak jakiejkolwiek informacji połączenia, komunikat enigmatyczny, myślałem, że coś po stronie Google, jakiś cache, DNS, coś takiego. Chciałem nawet napisać do supportu, ale Feedburner nie posiada takowego – jak widać Google niezbyt dba o ten serwis. Są nawet głosy, żeby przenieść się z Feedburnera – może niebawem, póki co zostaje jak jest.

Sprawa była niezbyt pilna – tam gdzie mi zależało najbardziej, podałem bezpośredni URL do feedu RSS. Część ludzi ma jednak podany stary feed, tak też kieruje stary blog i zapowiadałem, że będzie on aktualny, więc wypadało naprawić.

Dziś zrobiłem test SSL i w oczy rzuciło mi się, że serwer WWW słucha tylko na IPv4. Zamierzona zaszłość. Teoretycznie przy braku łączności po IPv6 w większości popularnych implementacji powinno nastąpić połączenie po IPv4 (mechanizm Happy Eyeballs i podobne), ale jak widać Feedburner tego nie robi i wymaga serwera słuchającego na adresie IPv6, jeśli tylko domena bloga posiada rekord AAAA.

Błędu nie zgłoszę, skoro Google nie chce. Poprawiłem konfigurację serwera, by słuchał także na IPv6 i feed działa. W sumie mój błąd, że nie odpaliłem sniffera od razu przy diagnostyce, ale odrobinę lepszy komunikat błędu, np. connection to ADRES_IP failed wyjaśniał by wszystko.

W każdym razie do zapamiętania: jeśli chcemy, by Feedburner działał dla domeny rozwiązującej się na IPv4 i IPv6, to serwer musi słuchać na IPv6.

Uciec, ale dokąd?

Chwytliwy tytuł nie jest związany z filmem. Pod koniec zeszłego roku w komentarzu u Boniego wyraziłem przypuszczenie, że roku 2018 nie skończę na Blox i… stało się. Równia pochyła była widoczna od dłuższego czasu, najpierw wyłączane były funkcjonalności (API), potem doszły problemy ze stabilnością naprawiane… długo i nie do końca, bo błąd 503 się pojawia – relatywnie niski wynik Blox na mojej stronie ze statystykami nie jest przypadkiem. Zapowiadanych nowych funkcjonalności nie ma – nowy panel nie został nigdy ukończony, nowe szablony są nadal trzy na krzyż, mimo zapowiedzi. O HTTPS można zapomnieć, co oznacza, że wkrótce blogi na Blox będą oznaczone jako niezaufane w przeglądarkach, pewnie za jakiś czas polecą w dół w indeksach Google. Nawet blog o Blox nie jest już od dłuższego czasu aktualizowany. Znaczy, że przyszłość rysuje się niewesoło, było wiadomo od dłuższego czasu.

Zamknięcie serwisów blog.pl oraz bloog.pl na początku roku (Onet i WP, odpowiednio) pewnie dodało Agorze odwagi w wyciskaniu zysków z upadającej platformy i postanowiono dołożyć reklamy. O tym, że mogą zamieszczać reklamy, było wiadomo od dawna, bo jest to napisane w regulaminie odkąd pamiętam. I reklamy były serwowane na nieaktualizowanych blogach.

Jednak tym, co przelało czarę goryczy nie jest fakt zamieszczenia reklam, tylko forma. Zarówno forma reklamy, totalnie nieestetycznej, rozwalającej wygląd szablonu, wklejonej na samej górze (wiadomo, co jest najważniejsze… żeby żaden user nie zapomniał przypadkiem kliknąć, a blog to taka przylepka do reklamy), w dodatku dynamicznej (animacja), zasłaniającej jakieś 75% ekranu na moim smartfonie, jak i forma komunikacji zmian użytkownikom.

Otóż komunikacji nie było żadnej. A jak już użytkownicy zauważyli reklamę i zapytali na forum co jest grane, to usłyszeli:

Jednak koszty utrzymania platformy Blox.pl wzrosły i wprowadziliśmy zmianę – nieinwazyjne reklamy są wyświetlane teraz na wszystkich blogach.

Wolne żarty. Nie lubię zaglądać komuś do kieszeni, ale koszty hostingu, łącz i sprzętu komputerowego regularnie spadają. W tym ostatnim przypadku rośnie wydajność sprzętu/pojemność dysków, przy zachowaniu cen. Oczywiście Agora może sobie dowolnie księgować koszty i zapewne na papierze koszt utrzymania platformy wzrósł, niemniej można to ująć po prostu chcemy więcej zarabiać na Blox (i mamy w głębokim poważaniu, co sądzą o tym użytkownicy, albowiem silna nasza pozycja[1]). O „nieinwazyjności” reklamy było wyżej.

W każdym razie będę stąd znikał. Nie wiem jeszcze dokąd pójdę i kiedy dokładnie, ale znikam na pewno. Jestem w tej komfortowej sytuacji[1], że mam i backup bloga, i narzędzie do migracji z Blox do WordPressa (gdyby ktoś był zainteresowany, polecam kontakt jak w dziale kontakt; TANSTAAFL). Choć nie wiem, czy akurat na WordPressa chciałbym się przenieść. Z jednej strony de facto standard i wygodny, z drugiej statyczne generatory bloga (tu: Pelican) nadal kuszą… Tylko jest problem z komentarzami. Z drugiej strony chyba połowa komentarzy to spam lub krytpospam i usuwam, więc… Tak czy inaczej, dojrzałem do self hosted bloga, tym razem.

W każdym razie nie należy spodziewać się tu wielu nowych wpisów – energia idzie w migrację. Na pierwszy ogień idzie blog BKS, przy okazji pewnie nieco zaktualizuję treść. Można spodziewać się zmian związanych z przekierowaniem użytkowników w nowe miejsce i stopniowego(?) znikania treści. Jeśli korzystasz z kanału RSS innego, niż ten, to polecam aktualizację w czytniku RSS – dołożę starań, by zachować ciągłość. Dla tych, co bez RSS w – razie czego będzie mnie można znaleźć przez Planetę Joggera. Wpis na ostateczne pożegnanie też jest planowany, ale to jeszcze nie teraz.

[1] Trzeba przyznać, że wyłączenie API, plus właścicielstwo domeny, plus niezłe pozycjonowanie, plus brak kontroli nad nagłówkami przez użytkowników stawiają Agorę na mocnej pozycji, bo migracja dla przeciętnego użytkownika jest IMO niewykonalna, chyba, że ktoś będzie ręcznie wpisy przenosił… No ale o tym, że prawdziwe własność daje własna domena wiadomo nie od dziś.