Spis treści
Ponad 3 lata temu szybkość ładowania strony dołączyła do oficjalnych czynników rankingowych Google. Był to dobry krok, ponieważ mało kto zwracał uwagę na to, aby jego strona ładowała się w sposób jak najbardziej zoptymalizowany, zapominając, że tworząc strony w pierwszej kolejności mamy myśleć o osobach, które ją odwiedzają, a nie o robotach Google.
Po wdrożeniu updatu Google okazało się jednak, że strony świetnie dopieszczone pod kątem prędkości wczytywania wcale nie wskoczyły niejako z automatu na pierwsze strony w wyszukiwarce. Sceptycy zaczęli mówić, że Google nie jest konsekwentne w swoich działaniach – zapominając, że ów czynnik rankingowy to tylko jeden z wielu, który Google bierze pod uwagę tworząc wyniki wyszukiwania.
Mało kto jednak zagłębił się w temat, aby sprawdzić, czy warto dążyć za wszelką cenę do osiągnięcia celu, jakim jest 4×100. Ten, kto to zrobił, zauważył, że narzędzie swoje, a życie swoje
4×100 jest do osiągnięcia, ale …
Po latach postanowiłem doszlifować swoją stronę firmową – prace zaowocowały takim oto wynikiem
Jednak szybko okazało się, że wyniku nie uda się zachować…
Dylemat 1 – Pixel Facebooka
Po sprawdzeniu poprawności wdrożenia, celem upewnienia się, że o niczym nie zapomniano, okazało się, że nie przeniesiony został kod Google Tag Managera. Umieszczono go zatem na nowo w witrynie i od razu Performance strony spadło o 16%:
Problemem okazał się Pixel Facebooka
No i co tutaj zrobić? 🙂 – można go usunąć, w sytuacji, jak nie jest potrzebny; jednak prawdopodobieństwo, że z „czystem GTM” osiągniemy 4×100 jest bliskie zera
Dylemat 2 – Google reCaptcha
Kolejnym problemem, na drodze ku 4×100, jest Google reCaptcha Google, która na logikę nie powinna negatywnie wpływać na stronę – w końcu to produkt Google – a tymczasem jest inaczej; zobaczmy, co się dzieje na stronie, na której jest ona wczytywana
Spadek Performace jest o 50%, a ogólny wynik mamy na poziomie zaledwie 46%; wchodząc w szczegóły widzimy, kto odpowiada za jakość strony
Rozwiązaniem jest uruchamianie jest tylko na odpowiednich stronach (tylko kto dzisiaj, w dobie popularności WordPressa, instaluje w ten sposób reCaptchę? Domyślnie odpala się ona na każdej stronie).
Dylemat 3 – grafiki WebP
Poświęciłem temu tematowi osobny wpis, krótko napiszę zatem krótko, że ich użycie, mimo zachęcania przez web.dev do wdrożenia, nie jest zalecane, ponieważ Safari w dalszym ciągu, notabene jako JEDYNA przeglądarka, nie obsługuje w pełni tego formatu. Ewidentnie Google nie potrafi porozumieć się z Apple, jak nie wiadomo dlaczego trwa to już ponad 10 lat, to musi chodzić o naprawdę wielkie pieniądze (tak myślę).
Osoby, które korzystają z produktów Apple, to osoby warte szczególnej uwagi, zwłąszcza w branży e-commerce; jeżeli wdrożylibyśmy na swojej stronie grafiki WebP ryzykujemy zmniejszenie konwersji w wartościowej grupie docelowej.
Konkluzja
Wielu właścicieli firm, zwłaszcza tych mniej doświadczonych w kwestiach optymalizacji stron, jest zbyt zapatrzonych w „zielone cyferki” i dąży do wyniku 4×100 na siłę. Jest to jednak w wielu przypadkach niemożliwe – o ile można zrezygnować z Google Tag Managera w sytuacji, gdy do śledzenia ruchu w witrynie korzystamy z logów serwera, to jednak w przypadku działań reklamowych same logi nam nie wystarczą, zwłaszcza, jak nasze kampanie reklamowe pracują w inteligentnym trybie.
Optymalizując naszą stronę nie popadajmy w przesadę i nie gońmy „za króliczkiem”, szukając na siłę „Świętego Graala”. Pamiętajmy, że to ludzie, a nie roboty Google, są naszymi odbiorcami – i to na nich powinniśmy się koncentrować, w niektórych przypadkach świadomie „psując jakość strony”.
Pixel Facebooka, reCaptacha, Google Tag Manager – to wszystko można bez żadnej straty optymalizować pod performance 🙂
Pewnie tak – jednak „zwykła implementacja” np. Pixela w GTM czy wymuszenie reCaptcha na wybranej stronie nie powinna prowadzić do takich sytuacji, skoro używamy Narzędzi Google 🙂
To częsty „zarzut” zaraz obok tego, że strony Google nie mają 100 punktów w PSI :). Nikt nie rusza kodu, który jest wygenerowany w kreatorze bo w domyśle zakłada, że nie można go edytować. Są to zwykłe instrukcje, a także linki do innych skryptów, które muszą być odpalone i tyle. To że coś jest od Google nie musi być domyślnie dopieszczone pod performance. Nadmierna optymalizacja takich kodów bez wiedzy na jakiej stronie zostaną użyte mogłoby powodować potencjalne problemy. Ta „zwykła implementacja” to najczęściej ta najprostsza metoda dodania kodu (dodanie kodu do sekcji head albo przed tagiem zamykającym body). I choć dzisiaj nikt tak nie programuje stron, jest ona opracowana tak aby każdy, nawet poczatkujący user CMSa nie miał z nią problemów na swojej stornie stworzonej według różnych technologii. Programista wie, że takie coś trzeba dodać w odpowiednim miejscu i on sobie poradzi z optymalizacją. Rozszerzenia do CMSów, które automatyzują integrację z tymi narzędziami opracowuje się zaś pod to aby działały w każdym możliwym środowisku i przypadku – tam też jest prostota, bo nadmierna optymalizacja też nie jest wówczas zalecana. Natomiast każdy kto zna w JS takie konstrukcje jak (async, promise lub callback) wie jak dodać konkretny kawałek kodu aby nie blokować ścieżki krytycznej. Kody analityczne typu Pixel FB czy Analytics nie mają instrukcji zależnych i można je z powodzeniem opóźniać. To, że do Analytics dojdzie sygnał o odświeżeniu strony kilka milisekund później (np. 50ms) to żaden problem z perspektywy funkcjonalności – wszystko działa i konwersje się zliczają a w analizatorach mamy zielone wyniki.
Jasne, przy czym od Google oczekiwałbym konsekwencji – skoro wrzucam kod GTM „ręcznie” w kod strony, to nie powinienem się zajmować takimi „szczegółami” jak „konstrukcje jak (async, promise lub callback) wie jak dodać konkretny kawałek kodu aby nie blokować ścieżki krytycznej”.
Lubię logikę i konsekwencję – no ale za długo siedzę w SEO, aby powiedzieć, że tu wszystko zawsze jest logiczne 🙂 – stąd ten wpis.
PS
Pewnie później z ciekawości zajmę się tym, co piszesz – jednak to nie powinno tak działać, jeszcze raz napiszę.
Pełna zgoda. Ja też jestem w pewien sposób zawiedziony kiedy jedynym problemem na stronie klienta są właśnie te skrypty analityczne – a to na prawdę częsty problem. Google mogłoby zamieścić gdzieś podpowiedź, że można te skrypty optymalizować, bo nie każdy kto zajmuje się stronami i SEO jest domyślnie pasjonatem web-performance. Pamiętajmy też, że brak pełnego wyniku nie oznacza od razu, że nasza strona nie spełni podstawowych wskaźników internetowych na zielono. Jeżeli strona nie jest przeładowana czym innym to ten :analytics” nie jest taki zły 🙂
Otóż to, otóż to – nie można gonić „na siłę” za „zielonymi wynikami” – umiar przede wszystkim. 🙂
Do tego jednak też pasuje mieć wiedzę, jak piszesz w wątku, ponieważ nierzadko wyniki są złe nie z powodu np. wolnego serwera, co sugeruje Google, a chociażby page buildera, w którym postawiony jest WP. Widzę to ostatnio bardzo często – liczę, że po ostatnich zmianach w WP ludzie zaczną w końcu mniej używać tych kreatorów…