Taki mały wpis pokazujący co można, a czego nie można osiągnąć za pomocą statycznego blogaska. Na przykład można spróbować zmaksymalizować wynik w różnego typu narzędziach oceniających jakość i wydajność stron www. Czy to jest ważne?

Z jednej strony nie. Przynajmniej nie w przypadku wielkich korporacyjnych portali, które na starcie próbują ściągnąć pół internetu. Nawet strona startowa wyszukiwarki google ściąga około 500 kb śmieci. I to przy zastosowaniu blokowania JS! Z drugiej tak. Szczególnie dla wszystkich, którzy chcą robić dobrze technicznie rzeczy.

Blog, strona główna, na chwilę obecną „waży” około 91,5 kB. Używam niestandardowego fontu, jakim jest Lato i to „robi masę”. Bez tego mieszczę się w 50 kB!

Możesz zapytać, czy to nie jest przez przypadek próba wyścigu „kto ma większego” (mniejszego). No nie do końca. Za rok zniknie sieć 3G. Pozostaną do dyspozycji sieci 4G i nowsze oraz stareńka 2G. Te nowoczesne są dostępne niby w całym kraju, ale z jakością bywa różnie. 5G to już tylko duże miasta, a poza nimi to protezy lub brak. Pozostaje 2G, które ma pokrycie trochę większe niż 4G. Zatem jak chcesz być dostępny, to musisz być mały. Inaczej się nie da.

Statyczny blog pozwala na wdrożenie wielu optymalizacji. Pierwszą z nich jest czas renderowania po stronie serwera. Wynosi on dokładnie 0. Serwer wysyła plik, który leży sobie gdzieś tam na dysku. Zapewne można ten proces przyspieszyć, upychając całość w memcache. Pozwala to ograniczyć koszty. W najgorszym wypadku możesz cały hosting upchnąć na RPi Zero.

Po drugie użytkownik otrzymuje jedynie to, co potrzebuje. Żadnych dodatkowych treści, css-ów, js-ów czy niepotrzebnych bajerów. Im bardziej rozbudowana strona, tym więcej pracy trzeba włożyć w ograniczenie wysyłanych danych. Czy na stronie głównej potrzebne są skrypty formularza kontaktowego, skoro go tam nie ma? Czy trzeba wszędzie umieszczać kod śledzący sprzedaż, skoro nie mamy do czynienia z modułem sklepu? Ilość warunków rośnie. Wraz z nimi rośnie czas renderowania na serwerze i tym samym czas oczekiwania na odpowiedź.

Po trzecie strona będzie działać nawet wtedy, gdy twoja przeglądarka blokuje skrypty, żądania cross-origin, czy ma ograniczenia w ilości ściąganych danych. To jest ważne. Nic nie wkurza tak, jak strona, która do działania wymaga megabajtów JSa, a jej funkcjonalność ogranicza się do wyświetlenia artykułu.

Po czwarte tak skonstruowana strona nie wymaga żadnych złożonych i zagmatwanych tricków. Chyba najbardziej skomplikowanym jest preload fontów i obrazków. Nie muszę się martwić o generowanie fragmentów, które długo będą się renderować na serwerze. Nie muszę dzielić strony na segmenty i kombinować z doładowywaniem takich czy innych elementów. To po prostu działa.

I na koniec małe „chwalę się”. Bez zbędnego kombinowania. Jedynie przenosząc fonty z Google Fonts do siebie, udało mi się osiągnąć maksymalne lub prawie maksymalne wyniki w testach wydajności na Lighthouse. Mała rzecz, a cieszy. A no i oczywiście uciekłem z Wordpressa na Jekylla, bo na tym pierwszym nigdy nie wyszedłem ponad wynik 70/100.