Hugo, dwa tygodnie później

Po 39 wersjach (commits) na GitHub i 30 minutach budowania strony (build) na Netlify, tak minęły dwa tygodnie, odkąd przesiadłem się z WordPress na Hugo i nie żałuje!

I, mimo że straciłem trochę odwiedzin wg Google Analytics (w większości osób próbujących włamać się na moją stronę), to nadal wszystko działa i nie mogę uwierzyć, że odeszło z mojej głowy podstawowe zadanie sprawdzania, czy moja strona cały czas działa prawidłowo.

Przy przenoszeniu zadbałem o odpowiednie przekierowywania, aby zminimalizować błędy 404 oraz upewniłem się, aby zaktualizować narzędzia webmastera Google, Bing i Yandex. Mimo utraty odwiedzin nie zaobserwowałem zmiany w wysokości przychodów z reklam AdSense, co jednocześnie świadczy, że stracony ruch nie był tym, który wprowadzał interakcję treści z użytkownikiem – czyli nie był tym najbardziej wartościowym.

Przy użyciu narzędzi takich jak Atom (do edycji kodu) oraz GitHub Desktop, pozostało mi patrzenie jak Netlify (z automatycznym budowaniem strony), robi wszystko za mnie.

Czas, który zyskałem, przez pierwsze dwa tygodnie spędziłem na optymalizacji kodu oraz nauczenia się nowych, przydatnych technik związanych z Hugo, HTML, CSS, JavaScriptem oraz JSON.

Udało mi się między innymi:

• zachować moje przekierowania (redirects) i stworzyć nowe;
• dodać ciemny motyw (Dark Mode), o którym wspomniałem w moim pierwszym wpisie;
• ustawić zaawansowane okruszki (breadcrumbs) wraz z generowaniem odpowiedzi w JSON dla postów oraz specyficzny dla przepisów. Pozwoliło mi to nauczyć się, ja w prosty sposób w przyszłości wprowadzić niestandardowy schema dla nowych typów wpisów, które mogę stworzyć;
• dodać instantpage w celu przyśpieszenia ładowania odnośników, na które użytkownik najedzie, a które będzie chciał odwiedzić. Dzięki czemu strona ładować się będzie wręcz natychmiastowo.
• nauczyć poprawnych metod implementacji skryptów, zdjęć, jak również popracować nad optymalizacją SEO.
• ograniczyć ładowanie niepotrzebnych skryptów do czasu, gdy są one potrzebne – takich jak komentarze Discus.
• dodać własne ikony udostępnienia treści w sieciach społecznościowych oraz ikony, prowadzące do moich profili w tych sieciach;
• zastosować fingerprinting dla stylów CSS. Dzięki temu, gdy dokonam zmiany w stylu CSS strony, po odświeżeniu mam pewność, że załadowana zostanie zawsze najnowszy plik, a nie ten, który domyślnie przesiaduje w pamięci podręcznej przeglądarki użytkownika końcowego.

…oraz wiele więcej.

Po dwóch tygodniach od uruchomienia, na mojej liście zostało tylko:

• zadbanie o zdjęcia w różnych rozmiarach, automatycznie generowanych przez Hugo Images Processing przy generowaniu strony;
• dodanie obrazów w formatach nowej generacji (WebP), które, na razie nie są natywnie generowane przez Hugo. Podczas używania przeze mnie WordPress i wtyczki EWWW do generowania WebP nauczyłem się, w jaki sposób rozwiązać to z myślą o przyszłym zastosowaniu (generowaniu WebP rezydującego na stałe obok standardowego obrazu). Na razie będę rozważał sposób na jego wprowadzenie, ale myślę, że poczekam z tym do aktualizacji Safari 14, która w końcu wprowadzi ich obsługę do przeglądarek w systemach operacyjnych z nadgryzionym jabłkiem.

Oczywiście, na każdym kroku przeglądając internet, natrafiam na rozwiązania, które inni zaimplementowali na swoich stronach, a które w prosty sposób teraz mogę wprowadzić (zapożyczyć) do siebie bez znaczącej zmiany w kodzie. Coś, czego wprowadzenie (w tym sprawdzenie, aby działało prawidłowo) z wykorzystaniem WordPress zajęłoby mi znacznie więcej czasu, szczególnie gdy nie używałem własnego motywu, tylko gotowy Twenty Twenty, na którego bazie stworzyłem Child Theme.

Nim skończyłem niniejszy wpis, już miałem sposób na wprowadzenie czegoś nowego 😉.

Po całych tych pracach dostosowawczych, choć wydawać się one mogą czasochłonne (więcej czasu – przeszło dwa tygodnie – zajęło mi przeniesienie z WordPress do Hugo) mam większą frajdę o obserwowaniu efektu końcowego.

Efekt końcowy, do którego zmierzam, o którym wspominam, jest osiągnięcie szybkiej i dostosowanej strony z treścią, którą odwiedzający będą czytać z zainteresowaniem.

I tak web.dev pokazał już sporę cześć na zielono (SEO 100, Best Practices 100 oraz Accessibility 91) to jednak Wydajność (Performance) kuleje na poziomie 20, głównie ze względu na obrazy serwowane w postaci pełnowymiarowej.

Aktualizacja 29/08/2020

Wg powyższego wyniku web.dev widać poważny problem z wydajnością, który jednakże nie jest do końca prawdziwy. Po każdym odświeżeniu strony opróżniany jest cache po stronie Netlify, jak i w moim przypadku po stronie Cloudflare. Gdy cache jest odbudowany, wydajność wraca do poziomu 80.

Mimo że korzystam z Netlify do serwowania mojej strony, to nie chętny jestem do wprowadzenia zależności wielkości moich zdjęć od ich rozwiązania (Large Media) i wolałbym to rozwiązać bezpośrednio z Hugo.

W związku z tym jeszcze trochę przede mną. Mimo tego już czuję, że wróciłem ponownie do treści a niżeli bawienie się w utrzymanie przy życiu strony internetowej.