Materiał archiwalny, opublikowany pierwotnie przeze mnie 23 lutego 2023 w serwisie linkedin: Dlaczego tworzenie stron w javascripcie to zły pomysł?
W ostatnich dniach zderzyłem się twardo z kilkoma problemami związanymi z technologią tworzenia stron internetowych. Są to problemy trudne, albo wręcz nierozwiązywalne. Ich źródłem jest brak wiedzy, dotyczący głównie programistów, którzy uważają się za webdeveloperów i osób zarządzających projektami. Przede wszystkim do tych dwóch grup adresowany jest mój krótki wpis.
Tytułem wstępu wspomnę o sytuacji, która miała miejsce lata temu, w epoce przed upowszechnieniem się menedżerów tagów (dobrą robotę zrobił tu Google Tag Manager, IMHO najlepszy produkt firmy Google). Kiedyś wdrożenie analityki wiązało się z przygotowaniem długiej i szczegółowej instrukcji wdrożeniowej, wdrażania kodów w kilku miejscach na wszystkich stronach, weryfikowaniu ich działania i iteracyjnym wprowadzaniu poprawek przez programistów i testowaniu ich przez analityków.
W momencie upowszechnienia się managerów tagów proces ten uległ gigantycznemu uproszczeniu. Zwykle w kod strony wpinało się tylko jeden kod managera i ewentualnie wystawiało się niektóre dane za pomocą warstw danych. Prosto, szybko i mało angażująca dla programistów.
Ostatnio dostrzegam jednak niepokojące zjawisko. Programiści, nie mający żadnej wiedzy o technologiach webowych, znający zwykle jeden i tylko jeden framework oparty na javascripcie zabierają się za budowę dużych witryn internetowych. Prowadzący projekt, jeśli jest skoncentrowany na zarządzaniu i nie wnika w technologię i zatwierdza technologię wykonania projektu. Tymczasem webdeveloper i programista to dwie zupełnie różne osoby. Webdeveloper zna się na technologiach internetowych, a programista niekoniecznie.
W efekcie manager tagów staje się bezużyteczny, a zbieranie danych tak utrudnione i ograniczone, że często traci w ogóle sens.
Javascript nie przesyła danych z serwera, tak jak np. php, ale pracuje w przeglądarce, ingerując bezpośrednio w model DOM. Tak jest szybciej i można zmienić zawartość jedynie części strony, bez jej przeładowania. Pozornie same korzyści. Są jednak dwa ważne powody, dla których ta technologia nie powinna być użyta w projektach, które mają za zadanie stworzenie dużej witryny internetowej dobrze widzianej i pozycjonowanej w wynikach wyszukiwania popularnych wyszukiwarek.
O ile w aplikacji webowej, do której przekierowywany jest użytkownik z innej strony i składa się ona z kilku zaledwie ekranów, cechy javascriptu są wyłącznie zaletami, to w innych przypadkach wygląda to następująco.
Załóżmy, że chcemy, aby boty Google czytały stronę i inwestujemy w SEO, aby wyszukiwarki sprowadzały jak najwięcej użytkowników na naszą stronę. Inwestujemy w dobrze napisane teksty na stronę i optymalizujemy je dla potrzeb wyszukiwarek. Co z tego, kiedy dla bota wyszukiwarki są one zwyczajnie niedostępne.
Po pierwsze, większość javascriptowych frameworków nie zmienia adresu URL zmieniając zawartość ekranu, co oznacza, że zamiast setki naszych wypieszczonych podstron bot wyszukiwarki widzi jedną jedyną stronę. To można ominąć generując w odpowiednich miejscach kod, symulujący zmianę adresu URL, ale jest to pracochłonne, szczególnie w naprawdę dużych serwisach z dużą ilością statycznych podstron.
Po drugie, co jest znacznie ważniejsze, treści z javascriptowej witryny w żaden z prostych sposobów nie wyprowadzimy na zewnątrz, tak, aby bot wyszukiwarki ją przeczytał i zaindeksował. Jeśli nawet nam się to uda, to potężnym nakładem pracy niewspółmiernym do efektów.
Drugi ważny powód to analityka. W obecnych czasach tworząc rozbudowaną stronę chcemy wiedzieć (zbierać dane) jak użytkownik zachowuje się na stronie, po to, aby na podstawie tej wiedzy optymalizować stronę. Robimy to w celu zrobienia przyjemności użytkownikowi, tak aby użytkownik lepiej się na niej czuł, częściej na nią wracał i, przede wszystkim, konwertował!
Takimi bardzo prostymi, przykładowymi metrykami, które możemy zbierać wdrażając np. jedynie podstawową wersję Google Analytics są: liczba obejrzanych podstron, czas pobytu na stronie, czas trwania wizyty i procent przewinięci strony. To proste i niemal elementarne metryki, prawda? Strona napisana w javascripcie nie będzie umożliwiała ich mierzenia. Być może można przygotować taki silnik, który przekaże podobne (nie takie same) informacje do systemu analitycznego, ale zwykle jest to ogromna praca, wielokrotnie przewyższająca wysiłek włożony w budowę strony. Strony we frameworkach javascriptowych pisze się szybko i łatwo. Nowe, nie przewidziane frameworkiem funkcjonalności, wprowadza się trudno i żmudnie.
Powyższe uwagi odnoszą się do niemal wszystkich narzędzi analitycznych, również takich jak np. heatmapy.
Stąd mój apel: dobierajmy technologię tworzenia witryny do jej rzeczywistej funkcjonalności, nie ograniczając się jedynie do wyglądu, szybkości działania na relatywnie szybkim komputerze, szybkości stworzenia kodu i łatwości jego tworzenia.
Serdecznie zapraszam do dyskusji programistów, webdeveloperów, specjalistów SEO i PM-ów.