Dlaczego wyłączyłem reklamy AdSense?

Z niewiadomych dla mnie powodów sporą popularność zyskał ten artykuł nt. wyłączenia reklam AdSense. Sprawdziłem fakty i niemal dwa lata temu pisałem o odchudzaniu bloga, w tym o wyłączeniu reklam Google. Przeczytałem jeszcze raz, skonfrontowałem z ww. artykułem i stwierdziłem, że warto dodać parę słów.

We wpisie poruszyłem tylko jeden aspekt – niskie zarobki. Tak niskie, że trudno tu mówić o zarobkach – tu polecam artykuł, bo ja zupełnie niekomercyjnie i amatorsko podchodziłem do tematu. Ale powodów było tak naprawdę więcej i uważam Google AdSense za bardzo słaby produkt. Po pierwsze, notoryczne problemy z pojawianiem się reklam w językach innych, niż polski i ew. angielski. Jeśli nawet nie robią detekcji języka, to deklaracja języka jest jasna czy to w samym HTML, czy w Google webmaster tools. O ile „międzynarodowy” angielski jeszcze bym od czasu do czasu zrozumiał, to notorycznie pojawiały się języki takie jak niemiecki, turecki czy jakieś skandynawskie. Nie pomagało ani blokowanie reklam, ani dostawców. Czyli z mojego widzenia wyświetlane były śmieci.

Druga sprawa, to niedostosowane tematycznie reklamy połączone z brakiem jakiegokolwiek uczenia się, których kategorii nie chcę widzieć na blogu. Oczywiście można wybrać kategorie wrażliwe. Jednak nawet przy wyłączeniu wszystkich notorycznie pojawiały się na blogu preparaty na łysienie itp. paramedyczne atrakcje. Jawnie zablokować tego nie sposób, przy blokowaniu pojedynczych żadna korelacja nie jest stosowana. Czyli znowu śmieci.

Kolejna sprawa to reklamy wprowadzające w błąd. Przede wszystkim chodzi o reklamy krzyczące na urządzeniach mobilnych o tym, że na urządzeniu są wirusy. Raczej nie widziałem tego u siebie, ale widać to zwykle na urządzeniach mobilnych, a tak raczej nie zdarzało mi się oglądać bloga. Natomiast temat znam zarówno z innych stron, jak i aplikacji ze sklepu Play. Zupełnie nie wiem, czemu nie jest to blokowane na wejściu globalnie. Żeby było weselej, chyba korzystał z tego któryś bardziej znany producent antywirusa. Albo po prostu domena była podobna… Problem jest taki, że ktoś to w końcu kliknie (mi się zdarzyło) i zainstaluje jakiś syf na telefonie. Czy to świadomie, czy nieświadomie…

Z punktu widzenia Google, na krótką metę, nie ma znaczenia, czy reklamy wyświetlają z sensem, czy bez sensu. Bardziej opłaca im się wyświetlić reklamę zupełnie niedopasowaną, niż nic nie wyświetlić. Jeśli nikt nie kliknie, to nie płacą, jeśli ktoś kliknie, nawet przez pomyłkę to zarabiają. A że Internet wygląda coraz bardziej jak zawalone bez ładu i składu reklamami polskie miasta? Nie ich problem…

Guetzli – lepsza kompresja JPEG

Przedwczoraj Google ogłosiło na blogu nowe narzędzie do kompresji JPEG o nazwie Guetzli, wydawane na wolnej licencji (Apache License). Ma dawać lepsze optycznie rezultaty przy mniejszym rozmiarze wynikowym (mowa nawet o 35% mniejszych plikach). Cena? Oczywiście czas kompresji.

Postanowiłem przetestować na szybko, co mogło by się zmienić, gdybym wykorzystał grafiki skompresowane przy pomocy Guetzli na blogu. W tym celu sięgnąłem po obrazki z backupu bloga i uruchomiłem program (domyślne opcje kompilacji, domyślne ustawienia jakości, czyli 90%) na moim laptopie (CPU: Intel(R) Core(TM) i3 CPU M 380 @ 2.53GHz). Zdziwiło mnie to, że aż przy 12 plikach nie udało się ukończyć działania – program zgłosił błąd:

Invalid input JPEG fileGuetzli processing failed

Udało się przetworzyć 66 plików, całość trwała prawie 17 minut (sic!). Czyli jest bardzo wolno. Kompresor wykorzystywał tylko jeden rdzeń CPU. Efekty są obiecujące, zarówno wizualne, jaki i objętościowe. Mimo, że algorytm jest zaprojektowany z myślą o działaniu na możliwie nieprzetworzonych obrazach wejściowych, a te na blogu raczej są już zoptymalizowane, to łączny rozmiar udało się zmniejszyć o 14% (z ok. 3,3 MB do ok. 2,8 MB).

Jeśli wezmą się za wykorzystanie i optymalizację duże firmy, a jest na to szansa po uwolnieniu programu, może to oznaczać mniej przesyłanych danych po sieci, czyli szybsze ładowanie się stron, widoczne zwłaszcza na komórkach. Chwilowo główną barierą jest czas działania, który wygląda na zależny bezpośrednio od wielkości pliku wejściowego.

Zrobiłem jeszcze jeden test – plik JPG bezpośrednio z aparatu, rozmiar 2560×1440, rozmiar wejściowy 1,2 MB. Po kompresji (trwającej kilka minut) brak zauważalnych zmian jakości, natomiast rozmiar zmniejszony aż o 50% (614 kB).

Jak zenbox.pl z domen klientów korzystał

Niedawno na blogu sprawnymarketing.pl pojawił się wpis o tym, jak rzekomo Zenbox stosował black hat SEO. Sprawa okazała się znacznie głębsza, szersza i ciekawa, niż na pierwszy rzut oka wyglądał. W różnych wymiarach, od technicznych, po prawne.

Przede wszystkim, niezaprzeczalnym faktem jest, że niektóre strony (raczej: większość) hostowane na zenbox.pl, pokazywały co innego przy wejściu przez HTTP, a co innego przez HTTPS. Jak pokazują zamieszczone w ww. wpisie zrzuty ekranu, narzędzia do badania SEO zauważały te linki. Raczej słusznie, bo wbrew temu, co twierdzi zenbox.pl, strony te nie zostały zignorowane przez Google, lecz normalnie zaindeksowane, co pokazuje poniższy zrzut ekranu:

Zenbox.pl SEO HTTPS

Szybko okazało się, że zenbox.pl nie jest jedynym hostingiem, który działa w ten sposób, a winny jest prawdopodobnie panel DirectAdmin, którego domyślna konfiguracja powoduje pokazywanie „zaślepki” przy braku podpiętego certyfikatu SSL. Potem było już tylko weselej, bo w dyskusji na Wykopie niektórzy sugerowali, że w zaślepkach powinien być w linkach atrybut nofollow. Uważam, że akurat brak nofollow świadczy w tym przypadku na korzyść zenbox.pl i braku celowego działania – gdyby ktoś zawracał sobie głowę atrybutami czy anchor text (a są i tacy), to znaczy, że pomyślał o pozycjonowaniu.

Jeszcze bardziej dziwi mnie skupienie się na SEO i ominięcie sedna sprawy: nie chodzi o – celowe lub nie – wprowadzenie w błąd Google. Przede wszystkim mamy do czynienia z podmianą treści na stronie zamieszczonej w określonej domenie. Wątpię, by właściciele domen mieli wiedzę, że taka podmiana miała miejsce. Jeszcze bardziej wątpię w ich zgodę na takie działanie.

HTTPS zamiast HTTP niewiele tu zmienia – oczywiście jest możliwość serwowania różnych treści w zależności od protokołu, podobnie jak strona z przedrostkiem www (de facto subdomena) z technicznego punktu widzenia może kierować zupełnie gdzie indziej, niż domena bez takiego przedrostka, ale przyjęte jest, że kierują w to samo miejsca. W przypadku HTTPS jest to IMO wręcz oczywiste.

Pamiętajmy też, że strony WWW, zwłaszcza popularniejsze blogi, potrafią po prostu sprzedawać miejsce na reklamę na stronie. Wydaje mi się, że w przypadku takich blogów wykazanie szkody w sądzie byłoby trywialne. Dlatego podejście zenbox.pl do sprawy mnie dziwi. Jak widać w komentarzach na blogu, mamy kolejno:

  1. straszenie „na takie działania godzić się nie można i zrobimy wszystko aby takie akcje miały konsekwencje”
  2. negacja, najpierw problemu w ogóle (screenshot w ww. wpisie), potem wpływu „działania nie mają wpływu na pozycję stron klientów ani wpływu na pozycję witryny zenbox.pl”
  3. przyznanie istnienia problemu „wspomnianego problemu nie doświadczyli” i w końcu podjęcie działań (zmiana konfiguracji, mailingi)

Wydaje mi się, że znacznie bardziej na miejscu byłaby analiza sytuacji, podziękowanie za zwrócenie uwagi, naprawienie problemu (poprawa konfiguracji) i przeproszenie klientów.

Cała sprawa ma jeszcze jeden ciekawy aspekt. Wydaje mi się, że największy błąd popełniło… Google, które podmienioną treść na stronie jak widać łyka jak pelikan. Mimo ewidentnych błędów HTTPS (certyfikat nie pasuje do domeny), które m.in. przed taką podmianą miały chronić. W czasach, gdy każda domena może mieć rozpoznawany przez przeglądarki certyfikat SSL za darmo (oczywiście chodzi o projekt Let’s Encrypt) strony za niepasującymi, wygasłymi i self signed certyfikatami powinny po prostu być ignorowane.

Prawidłowa konfiguracja to IMHO ta sama treść dostępna po HTTP i HTTPS. Czy to za sprawą odpowiedniego przekierowania (to sensownie uda się tylko z HTTP na HTTPS…), czy też – zwł. na shared hostingu – pod certyfikatem hostingodawcy, jeśli domena nie ma własnego.