Czas ładowania strony internetowej to jeden z najważniejszych czynników wpływających na doświadczenie użytkownika. Już czas ładowania powyżej 3 sekund negatywnie oddziałuje na tworzenie się naszej subiektywnej oceny względem danego serwisu, sklepu czy strony firmy.

Czas ładowania strony to w gruncie rzeczy aspekt przede wszystkim techniczny. Pełne ładowanie strony może trwać nawet kilka(naście) sekund, ale z punktu widzenia użytkownika najważniejsze jest, aby część widoczna przez niego tuż po przejściu pod konkretny adres URL pokazywała się od razu. Dobrym przykładem jest strona główna Wikipedii, która ładuje się błyskawicznie, według narzędzia GTmetrix dzieje się to w czasie 800ms, to jest mniej niż jednej sekundy. Jest to tak krótki czas, że praktycznie możemy nie zauważyć załadowania CSS jeżeli w tym momencie akurat mrugniemy. Co wpłynęło na tak krótki czas ładowania się zawartości Wikipedii.org? Przede wszystkim jej bardzo mała waga. W dniu testu (tj. 29.01.2018) ważyła zaledwie 58,3KB.

Wikipedia

Jak widzimy, strona wysyła zaledwie 7 żądań, są to:

Wikipedia request

Ilość żądań (Requests) wpływa na tempo ładowania się stron. Im więcej żądań, tym więcej „rozmów” pomiędzy komputerem użytkownika (czy urządzeniem z dostępem do sieci) a serwerem. Serwer zwraca odpowiedzi na nasze zapytania – jeżeli odpowiedzi znajdują się w plikach hostowanych w obrębie własnego hostingu, czas ładowania jest szybszy.

W waterfallu Wikipedii łatwo zauważyć ile dokładnie i jakie dokładnie elementy ładują się do strony. Jest to sam dokument HTML, pliki PNG, pliki SVG oraz pliki JS. Widzimy również czas ładowania, która potwierdza dane analityczne z GTmetrix:

Waterfall Wikipedii

Łatwo tym samym zauważyć, że Wikipedia nie korzysta z zewnętrznych skryptów co realnie spowalnia stronę. Wynik z GTmetrix oraz dane z Developer Tools mają swoje potwierdzenie także w PageSpeed:

PSI Wikipedia

Wynik 95/100 punktów w wersji desktop to świetny rezultat. Podobnie dobrze wygląda to w wersji mobile, gdzie Wikipedia.org osiągnęła 87 punktów. Google zapowiedziało wykorzystywanie swojego narzędzia do aktualizowania wyników w SERPach na urządzeniach mobilnych.

Co to oznacza? Oznacza to mniej więcej tyle, że wysoki wynik w PSI będzie wpływał na pozycję domeny dla konkretnych fraz na urządzeniach takich jak smartfony czy tablety. Z tego też względu Google zupdatował interfejs PageSpeed aby przekazywać nam jeszcze więcej informacji na temat prędkości strony.

W PSI możemy zauważyć nowe wytyczne: FCP oraz DCL. Ich przeznaczenie ma charakter statystyczny ale może pomóc nam zobrazować sobie sytuację użytkownika, która właśnie ładuje naszą stroną na swoim urządzeniu po raz pierwszy.

FCP to sytuacja, w której przeglądarka zrenderowała pierwszy kod naszej strony połączony z danymi zawartymi w DOM (First Contentful Paint = First Paint + Document Object Model). Samo pojęcie First Paint oznacza natomiast render zawartości ale bez contentu.

DCL to z kolei sytuacja kiedy główny plik obrazujący zawartość strony zostanie załadowany. FCP i DCL stanowią integralną całość z punktu widzenia użytkownika i obniżenie czasu ich pełnego ładowania to niewątpliwie sukces. Przy okazji – wytłumaczmy jeszcze „Rozkład wczytywania strony w PSI“. Konkretne procenty oraz kolory określają statystycznie w ilu przypadkach nastąpiła dana sytuacja. Jak widzimy, w przypadku Wikipedii w 40% sytuacji, zdarzenie FCP następuje szybko, zaś to samo ma miejsce z DCL w 51% sytuacji.

Słowem dojaśnienia, w przypadku GTmetrix spotkacie się także ze skrótem TTFB – jest to określenie czasu, w którym przeglądarka oczekuje na „ugryzienie” contentu zapisanego w plikach. (Time To First Byte). Więcej na ten temat znajdziecie w oficjalnym poradniku Google.

Krok po kroku

W narzędziu PageSpeed możemy trafić na wartościowe podpowiedzi, dzięki którym dowiemy się jak zoptymalizować tempo ładowania strony i tym samym podnieść punktowy wynik naszej domeny.

Podstawowym czynnikiem, który w każdym teście przedstawi naszą stronę blado, jest waga zdjęć analizowanego URLa. Czy będzie to PSI czy GTmetrix, czy Lighthouse czy dowolne inne narzędzie – niezoptymalizowane obrazy zawsze będą wskazywane jako najbardziej szkodliwe
w uzyskaniu wysokiej noty. Korzystnie jest kiedy wykorzystujemy jak najmniejszą ilość fotografii dla strony głównej, pamiętając jednocześnie o redukcji ich wagi. W przypadku grafik, które nie przedstawiają złożonych obrazów, możemy korzystać z formatu SVG, który jest formatem skalowalnym. Obiekty SVG zajmują mniej wagi, przez co nie spowalniają strony tak mocno jak JPGi czy PNGi. Co więcej – wykorzystując SVG, możemy wpływać na wygląd pliku przy wykorzystaniu CSS.

W narzędziach badających nasz „speed” dowiemy się także o tym, aby korzystać z pamięci podręcznej przeglądarki. Tutaj najczęstszym błędem jest brak określenia czasu cachowania w naszych zasobach plików zasysanych z serwera domeny, na którą wchodzimy. Ustawienie ważności wpływa na szybsze doładowywanie zasobów (lub ich pełny zapis na stronach rzadko aktualizowanych, statycznych) na urządzeniach, na których stronę wyświetlamy. Wszystko to, co scachuje się w naszych plikach cookies, wpłynie przede wszystkim na nasze doświadczenie użytkownika. Wchodząc po raz n-ty na daną domenę, nie będziemy musieli czekać, aż doładują się chociażby pliki CSS czy przerośnięte pliki PNG. Każde rozszerzenie plików możemy dopasować do własnych pomysłów, ale korzystnie jest przyjąć powszechne standardy, jakie znajdziemy np. w tym poradniku.

Zmiany dokonywane przez .htaccess są łatwe we wdrożeniu i w 100% konfigurowalne. Sami możemy ustalić, który typ plików „keszujemy” i na jak długo. Jeżeli np. pracujemy nad stroną i nie widzimy odświeżenia zmian w CSS, możemy zmienić okres wygaszania na 10 sekund. Oczywiście możemy skorzystać także z meta tagu cache-control ale to rozwiązanie niepraktyczne dla stron ze stałym, powracającym ruchem (nie wspominając o tym, że w takim układzie, userzy zawsze będą musieli odklikać zgodę na Cookies).

Zobaczcie jaka ilość danych znajduje się na dysku użytkownika, jeżeli już wcześniej przebywał na danej stronie:

cache

Do mojego komputera przesłane zostało zaledwie 139KB danych.

Teraz przyjrzymy się tej samej stronie po przejściu na tryb prywatny:

Cache cookies

Po usunięciu cookies przeglądarka pobrała 800KB danych. To aż 6 razy więcej niż wcześniej.

Przejdźmy do kolejnych ważnych aspektów przyspieszania strony. PSI niemal zawsze zwraca nam poradę „Skróć czas odpowiedzi serwera” – cóż, tutaj wiele zależy od naszego dostawcy. Zawsze możemy postawić domenę na dedykowanym serwerze, który dopali naszą prędkość, ale to wiąże się z dodatkowym wydatkiem.

Istotnym elementem z punktu widzenia szybkości jest redukcja plików JavaScript oraz CSS. Niejednokrotnie, zwłaszcza w przypadku sklepów internetowych, pliki stylizujące oraz ich preprocesory – jak SASS – korzystają z wielu reguł, które w gruncie rzeczy nie są wykorzystywane do obrazowania wyglądu użytkownikowi.GTmetrix

Powyżej widzimy również zapis odnoszący się do JavaScript. GTmetrix informuje nas o tym, aby nie wskazywać na pliki, z których de facto nie korzystamy. Warto zwracać uwagę na to z jakich plików korzystamy. Gdybyśmy wrzucili na serwer plik CSSowego frameworka – Bootstrapa – i nie zmodyfikowali go w żadnym stopniu – prosilibyśmy przeglądarkę o bezsensowne wczytywanie 187KB danych:

Bootstrap

Właściwa znajomość zasobów, z których korzystamy, pozwala nam zredukować wagę plików lub nawet ich liczbę. Z punktu widzenia agencji SEO jest to niezwykle istotne po otrzymaniu dostępów do strony i pierwszej analizie kodu.

Jeżeli jesteśmy już przy pliku CSS i wyglądzie strony, warto wspomnieć tutaj także o ładowaniu fontów. Jeżeli korzystamy z dedykowanego w naszym CMSie narzędzia, który fonty zasysać będzie np. z Google Fonts, możemy stracić nieco punktów w narzędziach badających prędkość.

Fonty Dev Tools
Na zrzucie ekranu zaznaczyłem źródło, które dostarcza na naszą stronę content. Spośród 151 żądań, aż 11 w przypadku analizowanego URLa to fonty. Jeżeli chcemy aby nasza strona ładowała się jeszcze szybciej, powinniśmy hostować je na własnym serwerze.

Na zrzucie ekranu powyżej zaznaczyłem źródło, które dostarcza na naszą stronę content. Spośród 151 żądań, aż 11 w przypadku analizowanego URLa to fonty. Jeżeli chcemy aby nasza strona ładowała się jeszcze szybciej, powinniśmy hostować je na własnym serwerze.

Stosunkowo duży odsetek czasu ładowania pochłania również wczytywanie wszelkich zewnętrznych skryptów social mediów. Wtyczki pobierające dane z Facebooka, Twittera i Instagrama są co prawda ładne i przyjemne, ale obciążają serwer i obniżają czas załadowania 100% contentu. Na jednej z analizowanych przeze mnie stron skrypt ładujący dane z FB to ponad 13% całej zawartości w wymiarze megabajtów:

facebook

W zależności od tego z jakich rozwiązań korzystamy, nasza strona może być wolniejsza lub szybsza. Im więcej przerzucimy na własny serwer, tym lepiej dla nas. Wtedy jednak musimy dbać o pełną stabilność.

Przyjrzymy się teraz kilku wytycznym, które możemy znaleźć w audycie Lighthouse.

LazyLoad

Bazowałem na przykładzie strony, której ładowanie się pokazałem już wcześniej. Audyt Lighthouse zwraca nam kilka ciekawych wytycznych. W tym wypadku proponuje zastosowanie tzw. lazy-loadingu czyli opóźnionego ładowania zdjęć, które w momencie wejścia pod URL znajdują się poza ekranem. Opcja ta pozwala szybko doczytać tylko to, co w danej chwili obserwujemy, następne doczytywania następują dopiero po scrollowaniu w dół.

Dla osób, którym naprawdę mocno zależy na ograniczeniu KB do ładowania i przyspieszeniu zawartości, wykorzystany może zostać format zdjęć WebP. Po przeprowadzeniu audytu, Lighthouse zwraca nam podpowiedzi odnośnie optymalizacji konkretnych plików, szacując jednocześnie ile miejsca zaoszczędzimy:

webP

Problem w tym, że WebP obsługiwany jest obecnie jedynie w przeglądarce Chrome, a to dyskwalifikuje tę opcję z powszechnego stosowania. Oczywiście możemy posłużyć się skryptem i serwować pliki WebP dla Chrome oraz PNG/JPG dla innych przeglądarek. Więcej o dostępności tego formatu na stronie Caniuse.

 

Podsumujmy

Na realną prędkość ładowania strony wpływ na mnóstwo czynników. Niektóre z nich możemy zoptymalizować bez znaczącej wiedzy technicznej, inne wymagać będą długiego weryfikowania tutoriali i dziesiątek poradników, zaś jeszcze inne – wiedzy i czasu programisty. Jeżeli decydujemy się na przyspieszanie stron, na których najbardziej nam zależy skupmy się na:

  • Redukcji wagi zdjęć i zastosowaniu odpowiednich formatów
  • Ustawieniu pamięci podręcznej dla plików, z których korzystamy
  • Redukcji kodu w CSS oraz JS oraz najlepiej ich zunifikowaniu oraz zminifikowaniu
  • Zastosowaniu autorskich rozwiązań, zamiast instalowania wtyczek/rozszerzeń/modułów itd.
  • Przerzuceniu fontów na własny serwer
  • Wprowadzeniu poprawnego ładowania zawartości strony (najlepiej w formie lazy-load przy większej wadze strony)
  • Zredukowaniu liczby żądań HTTP

W przypadku dużych serwisów możemy skorzystać dodatkowo z coraz popularniejszych CDN a nawet z HTTP2.

 

9 przemyśleń nt. „Jak realnie przyspieszyć stronę internetową?

  1. Super artykuł , czegoś podobnego szukałem od dość dawna, przewertowałem sieć, magazyny typu online marketing , blogi, wideo no i trochę już wiem na ten temat . Na pewno będę wpadał częściej

  2. Dobry art, w końcu czyta się o zmianach w htaccess, które mogą przyspieszyć ładowanie się strony operując jedynie na tym co może dać sama przeglądarka Kowalskiego W sumie można by nieco więcej jeszcze o grafice napisać, ale i tak git art, dzięki

  3. W przypadku JS warto też pamiętać o możliwości ustawienia ładowania asynchronicznego – strona nie będzie czekać z ładowaniem na doczytanie wszystkich javascriptów.

  4. Szybkość ładowania się strony ma bardzo duży wpływ na doświadczenia użytkowników, jednakże Google również nieprzychylnie patrzy na serwisy, które ładują się zbyt wolno. Jeśli chcemy być obecni w wyszukiwarce na wysokich pozycjach i chcemy osiągać pewne wyniki sprzedaży to warto jak najszybciej usprawnić swoją stronę

  5. Zgadza się wszystko. Uważacie, że wraz z coraz szybszymi serwerami warto do minimum optymalizować obrazy czy ma to drugorzędne znaczenie? JPG są coraz większe i będą coraz większe. Nowoczesne serwery powinny sobie z nimi radzić. A może jednak nie?

    1. Jeżeli tylko jest to technicznie i czasowo możliwe, to tak. Naturalnie zdjęcia, które muszą zajmować pewien fizyczny obszar nie będą mogły zajmować małej ilości kilobajtów, gdyż nie pozwoli na to kompresja (która zepsułaby ich wyglad). Skalowanie zdjęć do fizycznego rozmiaru na ekranie to podstawa, chyba, że korzystacie z lightboxa – to co innego. Jeżeli korzystamy z dużej ilości zdjęć, to zdecydowanie lepiej wgrać ja na zewnętrzny CDN i stamtąd hostować.

  6. Szybkość ładowania się strony ma szczególnie ważny wpływ na pozycję w wyszukiwarce. Im strona ma mniej dodatków i szybciej się ładuje tym Google lepiej patrzy na dany serwis, a dzięki temu pozycja jest znacznie wyższa.

  7. Super porady. Ciężar strony to realny problem. Zaciekawiło mnie zwłaszcza to z wtyczkami, że lepiej mieć swoje niż ogólnodostępne.

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *