Szybkość strony – poradnik dla początkujących

Co by było, gdybyśmy na szybkość witryny spojrzeli nie pod kątem punktów zdobywanych w teście PageSpeed, a pod kątem tego, co realnie dzieje się z nasza stroną od momentu umieszczenia jej w sieci aż do wyświetlenia u użytkownika?

Myślę, że wszystko stałoby się wtedy logiczniejsze, a elementy wpływające na szybkość strony przestałyby być czarną magią. I tym ma być poniższy artykuł – logicznym wyjaśnieniem poszczególnych elementów szybkości witryny z myślą o początkujących i średniozaawansowanych.

Niniejszy poradnik powstał z myślą o początkujących i posługuję się w nim jak najprostszym słownictwem. Siłą rzeczy nie rozpatruję nietypowych sytuacji i środowisk programistycznych.

Na początek: mapa

Spójrzmy na mapę najważniejszych elementów wpływających na szybkość strony…

… a następnie przeanalizujmy ją krok po kroku.

Krok 1: Przygotowanie plików

W pierwszej kolejności przyjrzyjmy się czynnościom, jakie musimy wykonać zanim w ogóle proces ładowania witryny się rozpocznie, czyli odpowiedniemu przygotowaniu plików.

Optymalizacja grafik

Pierwszy punkt jest w miarę oczywisty i przytaczam go tu tylko dla formalności.

Wiele osób uważa, że przygotowanie grafik w optymalizacji szybkości strony to po prostu odpowiednie ich skompresowanie stosownym programem graficznym.

Oczywiście jest to ważne – często możliwa jest bezstratna (czyli nie wpływająca w sposób widoczny na jakość zdjęcia) kompresja znacznie zmniejszająca rozmiar pliku.

Należy jednak pamiętać, że znaczenie ma nie tylko to, jaką wielkość będzie miał plik z obrazkiem, ale też to, w jaki sposób ów obrazek na stronie osadzimy.

Przede wszystkim należy serwować grafiki wyskalowane do potrzeb wyświetlania.

Jeśli zdjęcie z naszą twarzą o rozdzielczości 2080 x 1542 służyć ma nam jako malutki awatar, zmniejszmy je do odpowiednich rozmiarów. Jeśli nie wiemy, jakie to mają być rozmiary, bo np. w wersji mobilnej będą niewielkie, a w wersji desktopowej zajmą cały ekran, możliwe jest przygotowanie kilku ich wersji i serwowanie np. za pomocą atrybutu srcset.

Jeśli to możliwe, to warto również przy każdej grafice określić jej wymiary; dzięki temu przeglądarka jeszcze przed załadowaniem zdjęcia będzie mogła zarezerwować na nie przestrzeń i nie będzie zmuszona „przebudowywać” wyglądu strony po jego załadowaniu.

Jak optymalizacja grafik wpływa na szybkość witryny?

Jest to jedno z pierwszych i najważniejszych działań optymalizacyjnych, bo często najbardziej skraca czas ładowania i w większości wypadków jest relatywnie proste do wdrożenia.

Strony, w których niewielkich rozmiarów logo tak naprawdę jest olbrzymią, kilkumegabajtową grafiką nie należą do rzadkości.

Zmniejszenie rozmiaru kodu HTML, CSS i JS

Ten podpunkt opisałem już w artykule:
Usuń nieużywany kod – optymalizacja CSS i JS w praktyce.

Jak zmniejszenie rozmiaru kodu HTML, CSS i JS wpłynie na szybkość strony?

To oczywiście zależy od tego, ile niepotrzebnego kodu uda Ci się usunąć. Ilość usuniętego kodu będzie wprost proporcjonalna do poprawy szybkości ładowania, a dodatkowo, usunięcie nieużwanych, a często „ciężkich” skryptów JS może zaoszczędzić sporo czasu na ich zbędne wykonywanie przez przeglądarkę.

Ograniczenie ilości i rozmiaru zewnętrznych plików

Potrzeba ograniczenia do absolutnego minimum ilości i rozmiaru plików (np. skryptów JS) załączanych z zewnątrz jest oczywista. Każdy taki plik to konieczność odczytania, przetworzenia i wykonania skryptu.

Dodatkowo każdy taki plik to również konieczność łączenia się z serwerem inny niż ten na którym stoi nasza strona, co wydłuża cały proces. Jakby tego było mało, zewnętrzne pliki JS są praktycznie poza naszą kontrolą. Nie możemy ustawić okresu ich cache’owania; również ewentualna awaria na serwerze dostawcy skutkuje problemami na naszej stronie.

Jak ograniczenie ilości zewnętrznych plików wpłynie na szybkość strony?

To bardzo ważne, by ograniczyć liczbę zewnętrznych skryptów. Problem jednak w tym, że nie zawsze da się to zrobić, bo ciężko np. prowadzić stronę bez analityki od Google Analytics. Robimy więc to z głową. Jeśli np. rok temu zainstalowaliśmy Piksel Facebooka, albo skrypt tworzący heatmapy i w życiu z niego nie skorzystaliśmy, to zdecydowanie należy się go pozbyć. Im mniej dzieje się na stronie, tym lepiej.

Minify HTML, Minify CSS, Minify JavaScript

Minify czyli minifikacja kodu to właściwie dość prosty proces, polegający na usunięciu z kodu niepotrzebnych spacji, odstępów, formatowania, komentarzy, przecinków i innych zbędnych symboli.

Oczywiście nie robimy tego ręcznie, bo byłoby to praktycznie niewykonalne. Do minifikacji kodu Google zaleca kilka programów takich jak HTMLMinifier, CSSNano czy UglifyJS, których listę znajdziesz tutaj.

Jak minifikacja kodu wpływa na szybkość strony?

Choć brzmi to nierealnie, takie ucięcie zbędnych śmieci w plikach pozwala naprawdę znacznie zmniejszyć ich objętość, a co za tym idzie, przyspieszyć pobieranie witryny przez przeglądarkę.

Mamy tu jednak zasadnicze „ale”. Minifikacja nie zawsze działa na zasadzie „set it and forget it”. Niestety, ale zminifikowany kod wymaga przetestowania pod kątem poprawnego działania. Zdarza się np., że nasz niezbyt przejrzysty kod JS po minifikacji staje się też kodem niezbyt działającym.

Krok 2: Ładowanie po stronie serwera

Przeglądarka internauty wysłała do naszego serwera zapytanie, możemy więc zaczynać zabawę.

Czas odpowiedzi serwera (TTFB)

TTFB czyli Time to first byte to czas od momentu gdy przeglądarka wykona pierwsze żądanie, do momentu otrzymania pierwszych bajtów danych. Czas ten z łatwością sprawdzisz w DevTools w Chromie.

Google zaleca TTFB poniżej 200 milisekund, bardzo dobrym wynikiem jest wszystko poniżej 100 milisekund. Wyniki powyżej 600 milisekund oznaczają, że prawdopodobnie coś jest nie tak.

Ale z czego ów czas tak naprawdę wynika?

Na TTFB składają się 3 grupy czynników:

• żądanie wysłane do serwera – tutaj opóźnienia mogą wynikać z wielu powodów, między innymi powolną odpowiedzią DNS (np. gdy serwer jest fizycznie daleko od klienta), lub skomplikowanymi regułami firewalla
• procesowanie po stronie serwera – serwer musi „przepracować” zapytanie i wygenerować odpowiedź – czyli np. wykonać zapytania do bazy danych, wykonać skrypty po stronie serwera i wysłać w świat gotową odpowiedź w postaci pierwszej porcji danych
• odpowiedź do klienta – tu kluczowym elementem jest prędkość przesyłu danych przez serwer i prędkość łącza internetowego u odbiorcy; decydują one po jakim czasie pierwszy bajt danych wysłanych przez serwer dotrze do odbiorcy

W praktyce to druga grupa czynników bywa najbardziej kłopotliwa i pozwala na największe oszczędności. Wina nie zawsze (a nawet najczęściej) nie leży po stronie powolnego serwera.

Jeśli strona np. wykonuje duże ilości zapytań do bazy danych lub za każdym załadowaniem przeprowadza jakieś skomplikowane operacje, nawet najlepszy serwer nie podoła obsłużeniu ruchu i będzie pracował wyraźnie wolniej. Odpowiedzią może być cache po stronie serwera czy użycie CDNa.

Jednak zawsze najpierw upewnijmy się, że nasza strona jest po prostu dobrze napisana i nie obciąża zanadto serwera. Zmiana serwera na wydajniejszy może się bowiem wtedy okazać bezcelowa, bo przy wzroście ruchu sytuacja się powtórzy.

Jak skrócenie czasu odpowiedzi serwera wpływa na szybkość strony?

Jeśli Twój TTFB oscyluje w granicach lub poniżej 200 milisekund, daruj sobie dalszą jego optymalizację, dopóki nie będzie to konieczne. Im dalej w las, tym każde kolejne milisekundy do uszczknięcia będą wymagały już coraz bardziej złożonych i trudnych czynności.

Jeśli TTFB jest znacznie większy, to odpowiedź jak jego skrócenie wpłynie na szybkość jest oczywista. Musisz się wtedy zastanowić, jak zbudowana jest Twoja aplikacja.

Jeśli zmierzysz TTFB dla testowej, prostej strony statycznej napisanej w HTML i będzie on znacznie niższy niż na pozostałych adresach URL, problem prawie na pewno leży w budowie Twojej strony i/lub bazy danych.

Krok 3: Proces pobierania plików

Ok, serwer przygotował nam stronę do przesłania – zaczynamy pobieranie danych.

Kompresja gzip

Jeśli urodziłeś/aś się przez rokiem 90. istnieje spora szansa, że zdarzało Ci się próbować zmieścić dużą ilość danych na dyskietkę 1,44 MB. I istnieje spora szansa, że używałeś/aś wtedy jakiegoś programu kompresującego, np. WinZip lub WinRar.

Kompresja plików w tym wypadku jest czymś podobnym do „pakowania” plików WinZipem. Pliki HTML, CSS i JS automatycznie kompresowane są do formatu gzip i w takiej formie pobierane przez przeglądarkę – dzięki temu przeglądarka ma mniej danych do pobrania. Po pobraniu, przeglądarka automatycznie dekompresuje pliki i je odczytuje.

Kompresja raczej nie powinna obejmować plików graficznych – te w większości przypadków są domyślnie skompresowane.

Jak kompresja plików wpływa na szybkość strony?

Kompresja plików do formatu gzip w przypadku plików powyżej 150 bajtów (czyli niemal wszystkich) zawsze będzie miała sens. Czas potrzebny na odczytanie skompresowanych danych jest krótszy, niż czas potrzebny na pobranie plików nieskompresowanej wersji.

Krótko mówiąc – niezależnie od ilości czasu jaki zaoszczędzimy, kompresja jest rzeczą na tyle standardową i prostą we wdrożeniu, że niemal w każdym przypadku warto to zrobić.

Ciekawostką jest, że kompresja gzip może negatywnie wpłynąć na TTFB. Dzieje się tak dlatego, że serwer nie wysyła pierwszych bajtów danych gdy tylko je wygeneruje – musi poczekać na wygenerowanie całego pliku by go w całości skompresować. Jednak ogólny czas ładowania strony będzie i tak dzięki temu krótszy.

Ograniczenie przekierowań

Przekierowania 301 to sposób na automatyczne przeniesienie użytkownika z jednego adresu URL na inny. Roboty Google respektują przekierowanie, również podążając pod wskazany adres. Jeśli więc np. zmienia się adres URL Twojego na Twojej witrynie, robot Google ma dzięki przekierowaniu 301 wskazany poprawny adres, a przeglądarka użytkownika przenosi go tam niemal niezauważalnie.

No właśnie: niemal niezauważalnie. Przeglądarka wysyła żądanie pobrania zawartości adresu URL, otrzymuje wiadomość zwrotną z informacją o przekierowaniu i wtedy wysyła żądanie pod nowy adres. Krótko mówiąc ma więc więcej pracy (więcej razy łączy się z serwerem).

Problem pojawia się kiedy powstaje tzw. łańcuch przekierowań – czyli kiedy żądany adres URL przekierowuje na adres URL, który również przekierowuje na kolejny adres. Dziać się tak może np. w przypadku przekierowań typu:

domena.com -> www.domena.com -> www.domena.com/pl

Jak ograniczenie przekierowań 301 wpływa na szybkość strony?

Tu oczywiście efekt zależy od skali problemu. W skrajnych przypadkach, kiedy łańcuch przekierowań jest długi, pojawia się w obrębie wielu adresów URL, lub wręcz wpada w pętlę, usunięcie tego problemu może mieć zbawienny skutek dla szybkości witryny.

Unikanie bad requests

Bad request (nie mylić z błędem 400 Bad Request) to takie żądanie, które nie może być spełnione i zwraca kod 404 lub 410. Krótko mówiąc, jeśli np. w kodzie znajduje się odniesienie do skryptu JS: domena.pl/skrypt.js , a pod wskazanym adresem nie ma takiego skryptu – mamy do czynienia z bad request.

Jak unikanie bad requests wpływa na szybkość strony?

To proste – odnoszenie się do nieistniejących zasobów to marnowanie czasu. Przeglądarka musi bowiem wysłać żądanie na marne; nie otrzymuje w odpowiedzi żadnego pliku.

CDN – Content Delivery (Distribution) Service

CDN to w dużym skrócie sieć szybkich serwerów, które przetrzymują na swoich dyskach relatywnie „świeżą” kopię Twojej strony (lub tylko jej elementy, np. pliki graficzne) i serwują ją z najszybszego dla danego użytkownika serwera. Takie rozwiązanie dla pewnych stron może być zbawienne, dla niektórych zupełnie zbędne.

Jak CDN wpłynie na szybkość strony?

Choć odpowiedź „to zależy” pasuje niemal do każdego elementu poprawy szybkości strony, to zastosowanie CDN rodzi najwięcej wątpliwości. Dla niektórych dużych stron CDN lub podobna technologia jest niemal koniecznością. Również jeśli np. hostujemy stronę w Polsce, a użytkownicy naszej strony to np. głównie Amerykanie, CDN również może okazać się przydatny. CDN może też podnosić bezpieczeństwo, chroniąc np. przed atakami DDoS.

Jednak CDN to optymalizacja dość wymagająca, potrzebująca odpowiedniej konfiguracji, płatna, oparta na komercyjnych rozwiązaniach zewnętrznych firm. W większości przypadków jeśli już zalecam CDN, to tylko jako ostatni krok w procesie optymalizacji – warto najpierw wykonać wszystkie pozostałe zalecenia i sprawdzić ich efekt. Jeśli prowadzisz prostą stronę na WordPressie, z hostingiem i klientami w Polsce, nie streamujesz na stronie video i  nie udostępniasz grafik i plików do pobrania, a przede wszystkim: nie masz olbrzymiego ruchu – szansa że potrzebujesz CDN jest znikoma.

Krok 4: Ładowanie w przeglądarce

Mamy już – lub lada moment będziemy mieli – stronę pobraną z serwera, teraz nasza przeglądarka zajmuje się jej renderowaniem – zastanawia się jak strona ma wyglądać, co robią poszczególne skrypty i w końcu nam ją wyświetla.

Browser cache

Wykorzystanie browser cache, czyli pamięci podręcznej przeglądarki może znacząco skrócić czas ładowania strony u osób, które odwiedzają nas po raz kolejny. Dla każdego rodzaju pliku (lub dla poszczególnych pojedynczych plików) możemy bowiem ustawić nagłówek „expires” lub „max-age” (lub użyć innej metody – zależnie od konfiguracji) – czyli poinformować przeglądarkę jak często powinna pobierać z serwera najnowsza wersję pliku.

Jeśli więc przy pierwszej wizycie załaduje nam się np. duże zdjęcie, przeglądarka otrzyma informację, przez ile czasu powinna przechowywać je w swojej pamięci podręcznej. Jeśli jest to np. 30 dni, to przez najbliższy miesiąc przy kolejnych wizytach na stronie przeglądarka nie będzie tracić czasu na pobieranie kolejny raz tego samego zdjęcia i po prostu załaduje je z pamięci podręcznej.

Jeśli więc nie eksperymentujemy wciąż z designem naszej strony, pliki takie jak arkusze CSS, grafiki czy skrypt JS mogą miec nagłówek expires ustawiony nawet na dłuższe okresy jak np. rok.

Jak wykorzystanie browser caching wpływa na szybkość strony?

Wpływ wykorzystania pamięci podręcznej przeglądarki może być bardzo duży, jednak pamiętać należy, że różnica zauważalna będzie tylko u powracających użytkowników.

W pewnych przypadkach cache przeglądarki może również przyspieszyć ładowanie witryny u osób pierwszy raz odwiedzających naszą witrynę. Dzieje się tak np. w przypadku pobierania zewnętrznych skryptów i plików, które w niezmienionej formie wymagane są na innych witrynach.

Najlepszym przykładem są fonty pobierane z Google Fonts. Ten sam font używany na dwóch witrynach pobierany jest tylko raz, przy wizycie na drugiej witrynie przeglądarka korzysta już z pamięci podręcznej.

W przypadku plików ładowanych z zewnątrz nie mamy jednak wpływu na nagłówek „expires”. A o tym, czy fonty – również zważywszy na opisaną właściwość – lepiej ładować z Google Fonts czy lokalnie, przeczytacie w moim artykule sprzed roku.

Renderowanie i JavaScript

Kiedy przeglądarka pobierze kod naszej witryny, zaczyna go analizować i budować tzw. drzewko DOM. Analizując kod linijka po linijce dobudowuje do struktury witryny kolejne elementy jeszcze zanim je nam wyświetli. Jeśli w kodzie natrafi na kod JavaScript, musi przerwać analizę i wykonać napotkany skrypt, by wiedzieć jaki będzie jego wpływ na strukturę witryny.

Wpływa to bardzo negatywnie na szybkość strony, ponieważ zanim jeszcze przeglądarka cokolwiek nam wyświetli, straci mnóstwo czasu na wykonywanie skryptów, które często nie są istotne i mogłyby poczekać.

Jeszcze gorzej jest, jeśli skrypt pobierany jest z zewnętrznego serwera – dochodzi tu konieczność wykonania połączenia z innym serwerem i pobrania pliku. Tymczasem użytkownik cały czas oczekuje na wyrenderowanie treści strony.

Co więc należy zrobić? Przede wszystkim – unikać skryptów blokujących ładowanie. Jeśli musimy ich użyć, pozostają nam atrybuty defer i async.

<script async src="skrypt.js"></script>
<script defer src="skrypt.js"></script>

Atrybut async zmienia domyślny sposób budowania drzewka DOM. Skrypty nim oznaczone nie blokują renderowania witryny, i ładują się niejako w tle. Ma to też swoje minusy – nie da się kontrolować kolejności wykonywania takich skryptów, czy np. odnosić się do document.write.

Atrybut defer blokuje całkowicie wykonywanie oznaczonych nim skryptów aż do momentu kiedy ukończy się renderowanie wszystkich krytycznych elementów witryny.

Obie metody nie są idealne, bo niektóre skrypty wymagają wczesnego załadowania – np. wiele frameworków JS nie zadziała, jeśli biblioteki oznaczymy atrybutem async lub defer.

Jak ograniczenie JavaScript blokującego renderowanie witryny wpływa na jej szybkość?

Bardzo, szczególnie jeśli np. szablon naszej strony korzysta z wielu JavaScriptowych wodotrysków. Najważniejszą kwestią jest przejrzenie wszystkich skryptów, jakie ładuje nasza witryna i pozbycie się jak największej ilości tych zbędnych. Szczególnie jeśli są to skrypty ładowane z zewnątrz.

Dodatkowo odpada nam w ten sposób zagrożenie np. awarią serwera dostawcy skryptu, która może skutkować kilkudziesięciosekundowym oczekiwaniem na załadowanie skryptu.

Krok 5: Mierzenie efektów

Proces się zakończył, zmierzmy teraz jego efekty.

W internecie roi się od „magików” którzy zapewniają Ci optymalizację w celu uzyskania 100 na 100 punktów w teście PageSpeed. Świetnie, jeśli Twoja strona osiągnie taki wynik, będziesz mógł/mogła się nim pochwalić teściowej przy obiedzie, ale na niewiele Ci się to poza tym zda.

Testy takie jak np. GTMetrix należy traktować jako wskazówki. Owszem, osiągnięcie wysokiej noty na pewno pozytywnie wpłynie na szybkość strony, ale punkty te nie mogą być celem same w sobie.

Rzadko chwalę poczynania Google, ale jedna ich inicjatywa jest moim zdaniem fantastyczna i bardzo słuszna.

Są to nowe wskaźniki Core Web Vitals, które – co ważne – mają wkrótce stać się bezpośrednim czynnikiem rankingowym.

O Core Web Vitals pisałem więcej już jakiś czas temu w tym artykule. W ramach krótkiego przypomnienia – jest to lista wskaźników faktycznie i realnie wpływających na prędkość strony i odczucia użytkownika.

W dużym skrócie są to:

• First Input Delay – po jakim czasie możliwa jest interakcja ze stroną (np. kliknięcie linku)
• Cumulative Layout Shift – o jak duży dystans przesuwa się treść od pierwszego jej pokazania w trakcie doładowywania kolejnych elementów witryny
• Largest Contentful Paint – ile czasu potrzebuje strona by załadować największy contentowy element znajdujący się w oknie przeglądarki

Core Web Vitals możemy mierzyć na kilka sposobów, np. wykonując googlowski test PageSpeed lub w Search Consoli.

Czy są drogi na skróty?

Oczywiście że są. Dla WordPressa i innych popularnych CMSów są to gotowe wtyczki. Nawet jeśli chcesz takową zastosować, warto przeczytać powyższe wypociny by wiedzieć co i po co się robi. Pamiętaj, że wszystkie tego typu wtyczki wymagają konfiguracji. Nie ma dobrego rozwiązania dla wszystkich stron i dla każdej trzeba te ustawienia samemu wypracować. Bo np. 30-dniowy cache dla strony głównej serwisu newsowego to nie jest dobry pomysł.

Innym skrótem, który ostatecznie może się okazać bardzo wyboisty, jest wdrożenie AMP. O AMP również już trochę napisałem, ale najważniejsze fakty są takie: w kwestii optymalizacji szybkości strony AMP odwali za Ciebie większość roboty. Ale zwiąże Ci ręce w wielu innych kwestiach. Twoja decyzja.

---

I tak to się robi. Są jeszcze oczywiście inne kwestie, takie jak lazy load, CSS sprites i wiele innych, ale wdrożenie tych omówionych powinno przynieść najwięcej korzyści. Ważne oczywiście, niezależnie od tego, czy zlecimy optymalizację prędkości witryny specjaliście, czy też podejmiemy się tego samodzielnie, by zawsze wiedzieć co robimy i jakie może to nam przynieść korzyści.

A jeśli potrzebujesz pomocy w optymalizacji prędkości lub z jakimkolwiek innym problemem z pozycjonowaniem to przypominam, że w drobnych kwestiach pomagam nieodpłatnie, a trochę bardziej odpłatnie zajmuję się kompleksowym SEO z naciskiem na techniczny aspekt.