Bulldogjob Beta - czyli nowa, zoptymalizowana odsłona portalu

Dzięki intensywnej edukacji wiemy, że ciężki i powolny front-end to problem, z którym trzeba walczyć. Może słyszeliście o tym, że każda dodatkowa sekunda odpowiada za kilka procent użytkowników, którzy porzucają stronę. To przekłada się na duże straty spowodowane spuchniętym frontem.

W ostatnich latach przybyło nam narzędzi do sprawdzania jakości fontu. Z tych, które są z nami od dawna warto wymienić https://www.webpagetest.org czy https://tools.pingdom.com/. Google w ostatnim czasie intensywnie rozwija Lighthouse, a kolejne przeglądarki implementują API do sprawdzania czasu ładowania i profilowania stron. Jednak co tak naprawdę trzeba by zrobić, żeby we wspomnianym Lighthouse dostać 100/100 punktów za Performance?

Stwierdziłem, że szkoda gadać, tu trzeba działać! Tak właśnie powstał Bulldogjob Beta. Tak, jest to żarcik na prima aprilis i już nie jest dostępny (przyp. red.)

Tak wyglądała nasza strona na prima aprilis

Na razie zawiera tylko część z artykułami, ale w końcu to jest na Bulldogu najważniejsze. Przedstawię Wam kluczowe koncepty, które pomogły mi osiągnąć tak dobry efekt.

Brak kodu = brak problemu

Nie wiem czy widzicie, ale to jest nadrzędna zasada, która miała zastosowanie przy nowej odsłonie. Znaczna część usprawnień, które teraz wprowadzają producenci przeglądarek dotyczy obchodzenia problemów z wydajnością. Często jest to tylko tuszowanie. A czemu by nie usunąć przyczyny? Jak to mówią “jak pomyślał, tak zrobił”!

Optymalizacje mogę podzielić na kilka obszarów.

JavaScript

Strony, które ładują ponad 1MB kodu w JavaScripcie to nie jest rzadkość. Niestety parsowanie i uruchomienie tego kodu liczy się już w sekundach, szczególnie na urządzeniach mobilnych. Przez takie ilości JS mimo, że strona jest już wyświetlana, to nie jest interaktywna.

Te 1MB skryptów rzadko wnosi cokolwiek do czyjegokolwiek życia. Dlatego w nowej wersji pożegnałem się z JS (ok, jest Analytics, ale poza tym czysto).

CSS

Sytuacja wygląda tak, że dopóki nie ściągnie się i nie zostanie zaaplikowany arkusz CSS strona się nie wyświetla. Tu użyłem techniki sugerowanej przez Google - zawrzyj CSS niezbędny na krytycznej ścieżce renderowania w pliku HTML. I to jest sprytne podejście, które wpisuje się w filozofię nowej odsłony. Nie ma żądania po arkusz CSS - nie ma problemu.

Wyrzuciłem też Bootstrap, który jest obecny na pełnej wersji Bulldogjob. Z tą bibilioteką jest jeden podstawowy problem - większość styli w niej zdefiniowanych jest zupełnie zbędna. W nowej wersji stawiam na prostą, tekstową komunikację. Nie są mi potrzebne biblioteki do layoutowania. Domyślny CSS, który aplikuje przeglądarka jest zupełnie uniwersalny i responsywny. Uzupełniłem go tylko o kilka styli.

Web Fonts

Z czcionkami jest odwieczny problem. To kolejny zasób, który blokuje renderowanie. Można to teoretycznie ominąć i pozwolić sobie na Flash of Unstyled Text (FOUT). Można też przed załadowaniem CSS i HTML rozkazać przeglądarce ściąganie czcionki. Do tego używa się Font Loading API, ale realnie nie robi to dużej różnicy.

Dodatkowo należy zapewnić, że czcionka jest odpowiednio zoptymalizowana - czyli zawiera tylko te znaki, których potrzebujemy. Tu rękę wyciąga do nas Google Fonts, dzięki któremu można łatwo zdefiniować font-face, który ma tylko takie cechy jakie są nam potrzebne. Mimo to zawsze jest to dodatkowy zasób. Stąd lepiej zdać się na domyślne czcionki. By to zamanifestować na nowej wersji w ogóle nie określałem parametru font-family.

Obrazki

Google mocno propaguje używanie leniwego ładowania obrazków. To dlatego, że faktycznie nie ma sensu ładować ich w momencie, gdy nikt nie ma szansy ich zobaczyć. Jednak obecnie ładowanie ich w taki sposób wymaga JS. A że JS wywaliłem, to ta opcja odpada.

Dużo lepszym rozwiązaniem w tym wypadku jest brak obrazków. No... może okazjonalnie jakiś drobny SVG jest ok.

Umieszczanie pojedynczych obrazków ładowanych odrazu nie jest katastrofą - ich ściąganie ma niski priorytet i nie blokują interakcji użytkownika ze stroną.

HTML

Tu po prostu mniej znaczy lepiej. Gołe tagi HTML mają już swoją semantykę, cała reszta z punktu widzenia super-szybkiego front-endu jest zbędna.

Największą siłą nowej strony jest to, że po jednym requeście wszystko jest gotowe do działania. Nie trzeba łączyć się z kilkoma serwerami z assetami, nie trzeba czekać aż przeprasuje się olbrzymi JS, czy kilkaset kilobajtów CSS.

Mam nadzieję, że nowa odsłona Wam się spodoba i będziecie czerpać przyjemność z szybkiego ładowania i przejrzystego layoutu.

Podziękowania

Dziękuję twórcy http://motherfuckingwebsite.com/. To on był główną inspiracją do pójścia w tym kierunku. Nie zapominam jednak o osobach, które w ciągu ostatnich lat potwierdziły, że ta droga ma sens. Przychodzi mi na myśl Addy Osmani (twórca posta https://medium.com/dev-channel/the-cost-of-javascript-84009f51e99e) czy Ilya Grigorik, który od wielu lat pracuje nad tym, by sieć była szybsza.