Gaming Google - idealny wynik latarni morskiej

Zawsze wahałem się, czy udostępnić mój kod. Nie chodzi o to, że uważam to za kiepskie, ani nie dręczy mnie syndrom oszusta. Po prostu udostępnianie kodu daje wgląd w szaleństwo, które jest moim umysłem, i to jest w jakiś sposób okrutne dla wszystkich innych. Pozwól, że poprowadzę cię w podróż, która prawie doprowadziła mnie na skraj zdrowia psychicznego. Wszystko zaczęło się od aktualizacji Lighthouse Google.

Dla niewtajemniczonych SEO aktualizacja Google Lighthouse stanowiła znaczną zmianę w rankingu wyszukiwania, w zależności od wydajności witryny i przestrzegania najlepszych praktyk. Jeśli chcesz przetestować swoją witrynę, po prostu otwórz ją w Chrome na pulpicie, naciśnij klawisz F12, aby otworzyć narzędzia programistyczne Chrome, a następnie kliknij kartę „Latarnia morska”. Wybierz komputer stacjonarny lub mobilny i kliknij „Analizuj”. Po około minucie otrzymasz pięć punktów, każdy od 0 do 100, za wydajność, dostępność, najlepsze praktyki, SEO i progresywną aplikację internetową (PWA).

Zanim zagłębimy się w szczegóły techniczne, pozwólcie, że się przedstawię. Nazywam się Jonathan Grantham i jestem dumnym właścicielem małej firmy B2B SaaS, Nexoid, która specjalizuje się w oprogramowaniu ERP i ITSM. Strona, którą omawiam w tym artykule, jest www.nexoid.com. Zapraszam do obejrzenia, otwórz kod źródłowy. Możesz także śledzić mnie na LinkedIn. Mój profil jest www.linkedin.com/in/jonathongrantham/

Po wydaniu aktualizacji Google Chrome Lighthouse, Zrobiłem to, co zrobiłby każdy sumienny właściciel firmy: Sprawdziłem swoją witrynę. Ku mojemu przerażeniu wyniki były dalekie od zadowalających. Z wynikami 21/100 za wydajność, 30/100 za dostępność, 45/100 za najlepszą praktykę, 11/100 dla SEO i porażką PWA, byłem zszokowany. Osobiście zbudowałem stronę internetową, dość standardową architekturę pojedynczej strony przy użyciu React.js. Wyniki były miażdżącym ciosem.

Niezrażony początkowym niepowodzeniem, Uruchomiłem MS Code i zacząłem rozwiązywać problemy jeden po drugim, a Performance jest moim pierwszym celem. Przewodniki dostarczone w narzędziu Lighthouse okazały się całkiem przydatne. Przekonwertowałem wszystkie obrazy z JPEG i PNG na nowoczesne pliki WebP i upewniłem się, że każdy znacznik img został wyposażony we właściwość width and length, aby zapobiec przesunięciom układu. Same te modyfikacje zwiększyły mój wynik z 21/100 do 60/100. To była znacząca poprawa, ale daleka od doskonałości. Jedyną sugestią pozostała była „redukcja nieużywanego JavaScript”, co nie było szczególnie pomocne. Jedynym obecnym JavaScript był framework React.js, ponieważ wszystko inne zostało wyeliminowane.

Dzięki Nexoid AM Digital był w stanie rozszerzyć korzyści płynące z ujednoliconego rozwiązania ITSM również na operacje skierowane do klientów. Portal klienta, zintegrowany z platformą Azure, oferował klientom bardziej połączoną, dynamiczną i płynną obsługę, co skutkowało zwiększoną satysfakcją i zaangażowaniem klientów. Portal umożliwił synchronizację w czasie rzeczywistym z danymi klienta, zapewniając aktualizację i dokładność wszystkich informacji, a tym samym usprawniając ich świadczenie usług i wzmacniając relacje klient-firma.

Pomimo moich uporczywych wysiłków na rzecz rozwiązania problemu, Spotykałem się z ciągłymi blokadami drogowymi. Próbowałem usunąć części React.js, zbadałem „leniwe ładowanie” i przetestowałem różne optymalizatory i uciśnięcia. Problem wynikał jednak z samego React.js, który miał rozmiar około pół megabajta.

Prawie słyszę wytrawnych programistów internetowych krzyczących: „Nie używaj Reacta na stronie internetowej! Jest przeznaczony do tworzenia aplikacji internetowych!” Teraz doskonale zdaję sobie z tego sprawę.

To, co zaczęło się jako pozornie proste zadanie konwersji kilku obrazów, przekształciło się teraz w kompletny przegląd strony internetowej przy użyciu nowej struktury. Sfrustrowany i wypowiadając pod nosem kilka wybranych słów, wyruszyłem w poszukiwaniu odpowiedniego zamiennika. Najpierw rozważałem Vue, a później Angular, prawdopodobnie największych konkurentów React.js. Obaj przedstawili jednak ten sam problem.

Próbując uprościć sprawy, Postanowiłem przyjrzeć się starszym technologiom i dałem jQuery szansę. Jednak spotkałem się z tym samym problemem. Stało się całkowicie jasne, że nie ma gotowego frameworka Single Page Architecture, który mógłby uspokoić bóstwa Google.

Wydawało się, że moją jedyną pozostałą opcją było uciekanie się do waniliowego JavaScript.

Moja seria eksperymentów rozpoczęła się od podstawowej strony HTML bez żadnego JavaScript. Następnie wypróbowałem stronę HTML z div, którego zawartość można zastąpić. Szybko zdałem sobie sprawę, że dokonywanie wielu jednoczesnych zmian na stronie za pomocą JavaScript spowodowało kary od Lighthouse. Rozwiązaniem było manipulowanie zawartością znacznika body jako łańcucha, a następnie ponowne zintegrowanie go, tworząc w ten sposób tylko jedną widoczną zmianę DOM.

Miałem teraz minimalistyczną stronę HTML z pustym tagiem body, uzupełnioną małą funkcją onload w tagu head. Ta funkcja sprawdzała adres URL i wykonała żądanie HTML GET, aby pobrać odpowiedni plik tekstowy zawierający treść HTML strony. Można by pomyśleć, że jest to odpowiednie rozwiązanie. Niestety, nie udało mi się, gdy próbowałem dynamicznie załadować funkcjonalność JavaScript.

W przeciwieństwie do innych tagów, jeśli dodasz znacznik skryptu z prostym alertem („yes this fired”) do ciągu treści treści treści, nie zostanie on uruchomiony. Chociaż nie jest to idealne rozwiązanie, jednym z obejść było przeanalizowanie łańcucha treści, zidentyfikowanie całej zawartości znacznika skryptu i umieszczenie ich w funkcji eval JavaScript. Podejście to było nieco skuteczne, ale potknęło się w przypadku przestrzeni nazw, a konsola programisty została zalana brzydkimi ostrzeżeniami. Rozwiązaniem było wyodrębnienie znaczników skryptu z HTML i dodanie ich jako elementu skryptu po renderowaniu DOM. Google z jakiegoś powodu nie ukarał tego działania.

Poczyniono postępy, i miałem podstawowe rozwiązanie architektury Single Page Architecture. Ale nie tak szybko. Podczas gdy Google jest skuteczny w indeksowaniu stron architektury pojedynczej strony (robią to, otwierając je w przeglądarce, umożliwiając uruchomienie całego JavaScript, a następnie skanowanie DOM), Bing, Yahoo i inne główne wyszukiwarki używają podobnej, prostszej metody. Jednak większość innych platform, takich jak Facebook, Reddit, LinkedIn i WhatsApp, pobiera tylko plik HTML, pobierając mały plik HTML z pustą ciałem. Moje rozwiązanie nie było opłacalne. Musiałem teraz powtórzyć tę koncepcję dla każdej strony w witrynie i dołączyć JavaScript, aby przejść do trybu architektury pojedynczej strony, gdy użytkownik kliknął link.

Potrzebowałem narzędzia zdolnego do generowania HTML dla każdej strony, w oparciu o moje rozwiązanie. Przyszło mi do głowy, że mam do dyspozycji doskonały zasób: własny system ERP, Nexoid. Stworzyłem model Nexoid obejmujący obiekty danych strony internetowej i strony internetowej. Rekord strony internetowej ułatwił utworzenie ogólnej strony szablonowej, podczas gdy rekordy strony internetowej zawierały treść dla każdej pojedynczej strony. Ostatnim elementem układanki była funkcja przepływu pracy lub skrypt, który mógł odczytać rekord strony internetowej i wszystkie powiązane rekordy stron internetowych w celu wygenerowania plików HTML. Po kilku dniach był operacyjny. Stworzyłem podstawowy system zarządzania treścią (CMS). Opracowanie CMS do tego momentu nie jest zbyt skomplikowane; prawdziwe wyzwanie pojawia się podczas integracji innych przepływów pracy CMS, zatwierdzeń, lokalizacji, podglądów itp.

Kluczowym wymogiem dla nowej strony internetowej była lokalizacja; zamierzaliśmy uruchomić ją w 11 językach. Będąc firmą informatyczną, naturalnie skłaniałem się ku rozwiązaniom technologicznym. Zamiast zatrudniać tłumacza dla każdej strony, zdecydowałem się na AWS Translate. Podczas gdy tłumacze AI są przyzwoici, nie są doskonali, a błędy są wystarczająco zauważalne, aby ujawnić pochodzenie inne niż ludzkie. Francuskojęzyczny pracownik ocenił tłumaczenie AI i nadał mu 6/10, opisując je jako „zrozumiały, ale nie właściwy francuski”.

Natknęliśmy się jednak na cenną sztuczkę. Odkryliśmy, że najpierw podawanie angielskiego tekstu przez ChatGPT, prosząc go o „uporządkowany”, a następnie wklejając go, przeredaguje tekst w sposób, który nadal jest angielski, ale jest znacznie bardziej kompatybilny z modelami językowymi. Używanie przeformułowanego przez ChatGPT-English jako podstawy do tłumaczenia znacznie poprawia jakość tłumaczenia, podnosząc je do 9 lub nawet doskonałej 10 na 10.

Po opracowaniu solidnych podstaw technologicznych do stworzenia strony internetowej robiłem postępy. Jednak nowe wyzwanie pojawiło się, gdy zaczęliśmy budować bardziej złożone strony. Zgodnie z nowymi wytycznymi Lighthouse konieczne stało się skonsolidowanie wszystkich JavaScript, CSS i HTML w jeden plik. Dotyczy to również wersji architektury pojedynczej strony.

Uciekliśmy się do wstawiania wszystkich plików JavaScript i CSS jako znaczników wbudowanych. Podobna strategia była wymagana dla wersji Single Page Architecture. Stworzyliśmy plik JSON zawierający wszystkie skrypty, style i HTML.

Lighthouse zidentyfikował kolejny problem jako rozmiar zasobów; pliki stron HTML i JSON były zbyt duże. Rozwiązałem ten problem za pomocą „minify”, biblioteki Node.js zaprojektowanej specjalnie do kompresji plików HTML, CSS i JavaScript. Rozwiązanie to spowodowało zmniejszenie rozmiaru pliku tekstowego o ponad 40%. Dodatkowo minify oferowało dodatkową zaletę zaciemniania, co utrudnia odczytanie surowego kodu, zwiększając bezpieczeństwo.

Zagłębmy się w temat hostingu. Tradycyjnie system zarządzania treścią (CMS) działa za pośrednictwem serwera aplikacji, który obsługuje żądanie HTML użytkownika. Interpretuje żądanie strony z adresu URL, lokalizuje odpowiednie zasoby w bazie danych, pobiera rekord bazy danych (ewentualnie obok innych), przetwarza informacje w celu złożenia strony i ostatecznie dostarcza je użytkownikowi końcowemu jako płaski dokument HTML. Ten opis dotyczy przede wszystkim początkowego żądania HTML, gdy użytkownik odwiedza nową stronę internetową, chociaż jestem świadomy AJAX i innych podobnych technologii.

Jednak ten konwencjonalny model ma pewne wady w kontekście nowego świata latarni morskich. Po pierwsze, komunikacja między serwerem aplikacji a serwerem bazy danych, a także kompilacja strony, wprowadza opóźnienia. Po drugie, w najprostszej formie serwer aplikacji i serwer bazy danych są fizycznie dostępne tylko w jednej lokalizacji. Ta konfiguracja jest doskonała, jeśli jesteś w tym samym budynku lub mieście, ale znacznie mniej wydajna, jeśli próbujesz uzyskać dostęp do witryny z drugiej strony świata. Na przykład średnie opóźnienie ping między Australią a Wielką Brytanią wynosi około 250 milisekund.

Nasze rozwiązanie tych wyzwań polega na wykorzystaniu AWS S3 do hostowania plików statycznych generowanych przez wspomniany wcześniej skrypt publikowania, oraz AWS CloudFront do globalnej dystrybucji treści. W chwili pisania tego tekstu AWS CloudFront dystrybuował treści do ponad 90 miast w 47 krajach. W przypadku osoby w Melbourne w Australii uzyskującej dostęp do brytyjskiej strony internetowej AWS CloudFront zmniejszył opóźnienie pingów z 250 milisekund do zaledwie 13 milisekund (jest to różnica czasu między serwerami brzegowymi Melbourne i AWS w Sydney).

Dochodzimy teraz do komponentu Progressive Web Application (PWA) testu Lighthouse, co nie było czymś, co wcześniej poświęciłem wiele uwagi. Dla tych, którzy nie są zaznajomieni, PWA obejmuje pracownika obsługi JavaScript, który zarządza witryną jako aplikacją internetową. Jeśli to trochę skomplikowane, rozważ to w ten sposób: jest to zasadniczo automatyczne narzędzie do pobierania i buforowania. Gdy użytkownik odwiedza Twoją witrynę, celem jest, aby jego kolejne żądania były tak szybkie i bezproblemowe, jak to tylko możliwe. Pracownik serwisu PWA umożliwia już pobranie kolejnych zasobów na lokalny komputer użytkownika, eliminując potrzebę kolejnego żądania GET przez Internet.

W chwili pisania tego artykułu strona Nexoid jest stosunkowo niewielka, zawiera tylko 19 stron. Jednak te 19 stron zostało przetłumaczonych na 11 różnych języków, co daje łącznie 209 stron. Początkowo próbowałem pobrać każdy zasób do pracownika serwisu, który wyniósł około 5 MB. Ten rozmiar był zbyt duży na początkowe obciążenie, a Lighthouse ukarała mnie za to. Zdecydowałem się na pobieranie tylko angielskich plików JSON strony, które zawierają wszystkie niezbędne CSS, HTML i JavaScript do wyświetlania każdej strony.

Ostateczna struktura jest następująca: Wiadro S3 zawiera skompilowane pliki HTML, nazwane bez rozszerzenia.html. Na przykład www.nexoid.com/en reprezentuje angielski HTML strony głównej, www.nexoid.com/de jest niemieckim HTML strony głównej, a www.nexoid.com/en/platform odnosi się do angielskiej platformy HTML i tak dalej. Ponadto istnieją pliki JSON, które zawierają części ciała i głowy, które zmieniają się podczas nawigacji między stronami, takie jak między innymi https://www.nexoid.com/en.json, https://www.nexoid.com/de.json i https://www.nexoid.com/en/platform.json.

Podsumowując, zrozumienie latarni morskiej stanowiło poważne wyzwanie. Jestem sceptycznie nastawiony do tego, że tradycyjne, gotowe produkty CMS mogą skutecznie sprostać temu zadaniu. Zastanawiając się nad moim doświadczeniem z platformami takimi jak WordPress i Drupal, Trudno mi uwierzyć, że można je zoptymalizować, aby osiągnąć doskonały wynik latarni morskiej. Ogólnie uważam, że wysiłek jest opłacalny, a Google jest uzasadnione, kładąc większy nacisk na wydajność. Jednak ta zmiana jest i nadal będzie poważnym punktem bólu dla projektantów stron internetowych i agencji.

Jeśli chcesz dowiedzieć się więcej o Lighthouse lub chcesz omówić produkty i usługi Nexoid, nie wahaj się skontaktować. Możesz skontaktować się z nami za pośrednictwem LinkedIn lub strony „Skontaktuj się z nami” na naszej stronie internetowej.