Core Web Vitals: Optymalizacja wydajności

Po wykonaniu pierwszej analizy serwisu i wypisaniu wszystkich błędów, które mają znaczenie dla wydajności strony, możesz przejść do zastanowienia się nad rozwiązaniem tych problemów.

Ze względu na poziom skomplikowania większości popularnych w sieci skryptów CMS, poprawienie wszystkich błędów może być bardzo kosztowne, zwłaszcza gdy analizujesz wydajność strony już po zakończeniu jej tworzenia. Dlatego na początek warto spróbować wdrożyć rozwiązania, które są najszybsze i najtańsze.

Wykorzystanie usługi CloudFlare

Jeżeli z jakichkolwiek przyczyn, wielu z powyższych porad nie możesz wdrożyć na stronie, a zależy Ci na poprawie jej wydajności, rozważ skorzystanie z usługi CloudFlare. Jest to platforma, która dostarcza CDN oraz działa jako serwer proxy, zarządzając serwerami DNS Twojej witryny.

Zaletami tego rozwiązania są:

• anonimowość w sieci — Twój serwer jest ukryty, gdyż adresy DNS domeny wskazują na serwer CloudFlare,
• CloudFlare posiada punkty CDN na całym świecie, więc niezależnie skąd pochodzi użytkownik, zawsze będzie łączyć się z najbliższej zlokalizowanym od niego punktem, dzięki czemu cała transmisja danych będzie szybsza,
• „cachowanie” elementów strony, przez co zawsze ładowane są one szybciej z najbliższego miejsca od nas,
• zabezpieczenia przed atakami typu DDOS oraz spamem generowanym przez roboty sieciowe,
• zabezpieczenie przed awarią na stronie poprzez wyświetlanie użytkownikowi kopii podręcznej strony,
• możliwość zainstalowania darmowego certyfikatu SSL,
• kompresja i minifikacja plików źródłowych „w locie”,
• duża liczba funkcji w panelu zarządzania, które możesz włączyć na stronie.

Liczba zalet i funkcji, jakie oferuje CloudFlare, jest ogromna, a część z nich na chwilę pisania tego artykułu jest darmowa, dlatego dla rozwiązania niektórych problemów Twojego serwisu może być strzałem w dziesiątkę.

Wykorzystanie pamięci podręcznej

Włączając buforowanie przeglądarki (cache), możesz wskazać, jak długo ma ona zapisywać i wykorzystywać pliki witryny przy każdym powrocie użytkownika na stronę. Ten mechanizm może znacznie przyspieszyć jej działanie dla użytkowników, którzy już raz ją odwiedzili.

Aby jednak przeglądarka mogła wykorzystać mechanizm buforowania, na stronie nie mogą zachodzić częste zmiany. W przeciwnym wypadku, po ich wykryciu przeglądarka pobierze stronę od nowa. Mechanizm ten zatem może się nie sprawdzić w przypadku sklepów internetowych, forów czy blogów, gdzie zawartość strony jest często aktualizowana.

Pamięć podręczną możesz uruchomić tylko dla wybranych zasobów jak np. pliki CSS, JS czy zdjęcia, które się nie zmieniają.

Włączenie pamięci podręcznej ogranicza się często do wrzucenia kilku linijek kodu w pliku konfiguracyjnym .htaccess, który dołączy w nagłówku odpowiedzi HTTP odpowiednie instrukcje dla przeglądarki. Warunkiem musi być obsługa modułu mod_expires.c w przypadku serwerów Apache.

Przykładowa konfiguracja w pliku .htaccess dla serwerów Apache to:

<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType image/jpg „access plus 1 year”
ExpiresByType image/jpeg „access plus 1 year”
ExpiresByType image/png „access plus 1 year”
ExpiresByType image/gif „access plus 1 year”
ExpiresByType text/css „access plus 1 month”
ExpiresByType application/pdf „access plus 1 month”
ExpiresByType text/x-javascript „access plus 1 month”
ExpiresByType text/javascript „access plus 1 month”
ExpiresByType application/javascript „access plus 1 month”
ExpiresByType image/x-icon „access plus 1 year”
ExpiresDefault „access plus 4 weeks”
</IfModule>

Oczywiście poszczególne wpisy “ExpiresByType” określają typ zasobu, więc powinieneś ich listę przygotować pod pliki, które chcesz buforować oraz z myślą o tym, jak długo plik ma być przetrzymywany w pamięci podręcznej przeglądarki. Pełną dokumentację tego modułu znajdziesz na stronie https://httpd.apache.org/docs/2.4/mod/mod_expires.html.

Pamiętaj, że zmiana ta może nie wpłynąć znacząco na poprawę wydajności serwisu, ponieważ często największą liczbą użytkowników są nowe osoby, które ładują stronę pierwszy raz. Jeżeli wówczas Twoja witryna ich zniechęci, jest mała szansa, że na nią powrócą i tym samym wdrożona obsługa pamięci podręcznej może nic nie dać.

Redukcja zewnętrznych źródeł

Często bardzo trudno jest zrezygnować z konieczności ładowania skryptów zewnętrznych. Na przykład bramki płatności czy moduł czatu są elementami niezbędnymi w serwisie i nie może ich zabraknąć.

Wówczas powinieneś pamiętać o kilku kluczowych aspektach:

• skrypty zewnętrzne staraj się ładować tylko na tych podstronach, na których są niezbędne. Część z nich możesz ładować na końcu sekcji BODY tylko na wybranych podstronach po odpowiednim warunku “REQUEST-URI”,
• dobrym pomysłem jest też ładowanie skryptów tylko w momencie, gdy ich wykonanie jest niezbędne — np.na żądanie. Przykładowo skrypt może być uruchamiany dopiero po kliknięciu danego przycisku funkcjonalności (np. przycisk „Napisz do nas” spowoduje dopiero uruchomienie skryptu czatu),
• możesz opóźnić ładowanie skryptów zewnętrznych aż do pierwszej interakcji — kliknięcia, najechania kursorem myszy na dany element lub „zescrollowania” strony w dół,
• niektóre moduły zewnętrzne można w całości wdrożyć na serwerze wraz z plikami źródłowymi. Jeżeli więc tylko masz taką możliwość, powinieneś z tego skorzystać,
• warto testować, w jakim stopniu wybrane moduły, które korzystają ze skryptów, rzeczywiście są używane przez użytkowników (by zdecydować, czy są opłacalne).

Priorytetyzacja zasobów i ładowanie asynchroniczne

Odpowiednie zakolejkowanie najważniejszych zasobów na stronie wpływa bezpośrednio na metrykę LCP, która mierzy czas renderowania się największego elementu w obszarze ATF (Above The Fold). Elementy, które ładują się w obszarze BTF (Below The Fold) nie mają wpływu na tę metrykę. Jest to zgodne z tym, co dla użytkownika jest najważniejsze.

Dobrą praktyką jest odpowiednie umieszczenie zasobów w kodzie HTML, aby na górze ładowały się jako pierwsze arkusze stylów CSS, gdyż to one odpowiadają za renderowanie się strony oraz fonty.

Kolejna bardzo ważna kwestia, to wykonywanie kodu JS, który dołączony jest w sekcji HEAD. Jeżeli w kodzie nie ma żadnego skryptu, który odpowiedzialny jest za załadowanie się kluczowych elementów w obszarze ATF, wówczas powinieneś załadować go asynchronicznie lub odroczyć na sam koniec. Służą do tego atrybutu „defer” i „async”, które dodajesz do dołączanych plików JS, dzięki czemu kod HTML jest dalej parsowany niezależnie od tych plików.

Atrybut „async” powoduje, że plik JS będzie się ładował asynchronicznie wraz z ładowaniem się kolejnej części kodu HTML i uruchomiony zostanie zaraz po załadowaniu się JS, a „defer” uruchomi skrypt na samym końcu ładowania się dokumentu HTML.

Uwaga! Upewnij się, że skrypt, który chcesz załadować asynchronicznie, nie modyfikuje drzewa renderowania. Ponieważ wówczas możesz jedynie wydłużyć czas ładowania, gdyż po pełnym załadowaniu się skryptu nastąpi przeładowanie całego drzewa CSSOM. Jeżeli masz pewność, że plik JS nie wpływa na arkusze stylów CSS, wówczas możesz załadować go asynchronicznie na samym początku (nawet przed arkuszem stylów CSS).

Przykładem takiego skryptu jest np. tracker Google Analytics, który nie integruje w żaden sposób w kod HTML i drzewa renderowania, więc możesz go załadować na samym początku asynchronicznie.

Oprócz umieszczenia fragmentów CSS w odpowiedniej kolejności czasami warto małe fragmenty wklejać w ciało dokumentu HTML, zamiast w pliku CSS. Dzięki temu zostaną szybciej wykonane. Zmianę powinieneś wdrażać tylko dla małych fragmentów kodu i przeprowadzić testy przed i po wdrożeniu.

Podobnie sytuacja wygląda ze skryptami JS. Rozważ, czy małych skryptów, które odpowiedzialne są za ważne funkcje strony, nie warto przenieść bezpośrednio do kodu HTML.

Musisz też pamiętać, aby ładowanie asynchronicznie stosować z głową i nie wdrażać atrybutów „defer” w ciemno. Czasami lepszym efektem będzie ładowanie mniej kluczowych zasobów synchronicznie, ale na samym końcu kodu HTML, przed zamknięciem sekcji BODY.

Zamianę kolejności ładowanych skryptów i dostosowanie atrybutów ładowania asynchronicznego szybko się wdraża. I może to dać bardzo ciekawe efekty. Aby mieć jednak pewność, że zmiany kierują Cię w dobrą stronę, warto wdrażać je etapami naprzemiennie z testowaniem na nowo wyników PSI.

Minifikacja i kompresja zasobów

Minifikacja kodu oznacza zmniejszenie jego objętości. Aby to zrobić, możesz zacząć od najprostszego sposobu, jakim jest usunięcie zbędnych komentarzy i białych znaków poprzez kompresję całego kodu do minimum za pomocą gotowych narzędzi. Warto jednak sprawdzić, czy można to zrobić. Niektórych skryptów (jak np. JS) nie można uprościć i przepisać na prostszy kod, usuwając przy okazji nieużywane fragmenty. Minifikować można kod JavaScript, CSS oraz HTML.

W sieci znajdziesz wiele pomocnych narzędzi do minifikacji zasobów, np.:

• dla kodu HTML https://github.com/kangax/html-minifier
• dla kodu CSS https://github.com/cssnano/cssnano,https://github.com/css/csso
• dla kodu JS https://github.com/mishoo/UglifyJS

Oczywiście, do popularnych systemów CMS również znajdziesz gotowe rozwiązania. W sieci są dostępne też narzędzia do ręcznego minifikowania zasobów, a często takie funkcje są też wbudowane w popularne edytory tekstowe.

Uwaga! Przed rozpoczęciem minifikacji warto zrobić kopię plików. Zminifikowany kod nie jest już tak czytelny i jego późniejsza modyfikacja może być czasochłonna.

Jeżeli chodzi o kompresję plików, to najlepsza jest ta bezstratna, która po stronie serwera zmniejszy ich wagę i znacząco skróci czas załadowania. Popularnymi mechanizmami kompresji w internecie przez długi czas były Gzip i Deflate, oferujące kompresję na podobnym poziomie. Później Google wdrożyło swoje algorytmy kompresji: Zopfli, a następnie bardziej wydajny Brotli. Warto jednak zastanowić się, czy warto z niego korzystać. Gzip i Deflate są powszechnie dostępne, a przy kompresji ważniejszy jest sam format plików, które kompresujesz, niż wykorzystywany do tego algorytm.

Różnice w efekcie mogę być po prostu za małe w stosunku do wysiłku, jaki włożysz, aby Twój serwer obsługiwał algorytm Brotli. Wyjątkiem jest skorzystanie z CloudFlare. Nawet jego darmowej opcji.

Jakie pliki warto kompresować? Generalnie wszystkie, których używasz na stronach internetowych. Formaty plików tekstowych, takie jak np.:

• html,
• css,
• js,
• json,
• txt

bardzo dobrze się kompresują. Gorzej wypadają niektóre pliki graficzne, które już same w sobie mają kompresję. Z kolei np. pliki z rozszerzeniami exe, mp3, mp4, mkv posiadają współczynnik kompresji ponad 90%.

Włączenie konwersji na serwerze możesz wykonać na kilka sposobów:

• wklejając odpowiedni kod w pliku konfiguracyjnym.htaccess (pod warunkiem, że serwer ma zainstalowany odpowiedni mechanizm),
• instalując je na własnym lub dedykowanym serwerze (https://github.com/google/brotli),
  wykorzystując gotowe wtyczki w znanych systemach CMS
• korzystając z sieci CDN i np. usługi CloudFlare, która zwraca już skompresowane zasoby.

Optymalizacja Time To First Byte (TTFB)

Wszystko zaczyna się od pierwszego bajtu i od niego jest zależne. Jeżeli czas odpowiedzi serwera jest zbyt długi, to wdrażanie jakichkolwiek innych usprawnień na stronie nie będzie efektywne.

Jakie zatem możesz podjąć czynności, aby poprawić metrykę TTFB? Oto kilka sposobów:

• Zmiana sprzętu serwera na wydajniejszy
  Małe strony internetowe z niedużym ruchem nie wymagają od razu dedykowanych serwerów VPS, które możesz samodzielnie konfigurować i modyfikować (choć niewątpliwie zapewniają one największą wydajność). Warto jednak sprawdzić parametry serwera u hostingodawcy i wziąć pod uwagę jego zmianę na nieco szybszy.
• Zmiana lokalizacji serwera
  Jeżeli Twoimi użytkownicy są z Polski, wówczas warto, aby serwer fizycznie też znajdował się w kraju.
• Wykorzystanie sieci CDN
  Dla ładowania wielu zasobów i mediów na stronie warto wykorzystać tzw. Content Delivery Network (CDN), czyli rozproszony system danych i punktów wymiany ruchu w Internecie. CDN ma szeroką siatkę punktów i automatycznie będą one przesyłać media z najbliższego dla użytkownika miejsca. Warto wziąć pod uwagę CDN, gdy odbiorcami Twojej strony są użytkownicy z różnych zakątków świata. Nawet darmowy pakiet Cloudflare może bardzo zwiększyć wydajność strony.
• Pojemność i wydajność dysku
  Warto zwrócić uwagę, czy nie kończy się miejsce na dysku serwera. Jeśli tak, może to być powodem jego wolniejszego ładowania. Zdecydowanie w obecnych czasach standard szybkości wyznaczają już dyski SSD, dlatego warto z nich korzystać, aby usprawnić czas odpowiedzi serwera.
• Lokalizacja serwerów DNS
  Usługi DNS służą przeglądarce do tłumaczenia domeny Twojej strony na adres IP, do którego odbywa się cały ruch. Zbyt odległa lokalizacja serwera DNS może obniżać TTFB. Zmiana dostawcy serwera DNS może nie tylko przyspieszyć stronę, ale i zwiększyć jej bezpieczeństwo oraz prywatność.
• Cache
  Używanie pamięci podręcznej wpływa na czas ładowania się strony oraz na TTFB, gdyż statyczne pliki osadzane są na serwerze, dzięki czemu mogą być szybciej przesłane.
• Certyfikat SSL
  Szyfrowany ruch po protokole HTTPS to standard i jeden z czynników rankingowych Google. Warto jednak wiedzieć, że jego połączenie również zajmuje nieco czasu (serwer szyfruje, a przeglądarka odszyfrowuje). Często można zauważyć, iż po instalacji SSL prędkość ładowania się strony zmalała. Dzieje się tak w przypadku certyfikatów, które posiadają znacznie wyższy poziom szyfrowania, a ich hosting jest oddalony od użytkownika. Najczęściej jednak SSL ma minimalny wpływ na prędkość ładowania strony.
• HTTP/3 + QUIC
  Protokół HTTP w wersji 1 towarzyszył nam od 1997 roku aż do 2015 roku, kiedy to wyszła nowsza wersja HTTP/2. Obecnie najnowszym standardem jest HTTP/3 i w przeciwieństwie do wcześniejszych wersji jest oparty o protokół UDP. Protokół TCP, na którym oparte były wcześniejsze wersje, jest znacznie wolniejszy, ponieważ po każdym transferze danych wymagane było przesłanie potwierdzenia. Protokół UDP (User Datagram Protocol) już nie wymaga tego potwierdzenia, więc nie musi czekać na kolejny krok w przesyłaniu danych, które wysyłane są strumieniowo. Możesz także spotkać się z protokołem QUIC (Quick UDP Internet Connections), który idealne współgra z HTTP/3, zapewnia bardzo wysoką wydajność i zmniejsza opóźnienia transmisji danych między serwerem a przeglądarką. Zdecydowanie warto sprawdzić, czy Twój hostingodawca udostępnia nowe rozwiązania lub zmienić usługodawcę.
• Waga dokumentu HTML
  Pierwszym elementem, jaki jest wysyłany do serwera, jest przeważnie kod HTML. Jeżeli Twój kod będzie bardzo chaotyczny i będzie miał wiele niepotrzebnych elementów, to nie tylko wydłuży się generowanie drzewa DOM, ale i czas na przesłanie dokumentu.
• Czas działania skryptów
  Jeżeli Twoja strona oparta jest o skrypty, system CMS czy frameworki, to zanim powstanie kod HTML wysyłany do przeglądarki, strona musi go stworzyć za pomocą własnych skryptów. Szybkość działania silnika witryny zależny jest w dużej mierze od jej implementacji i logiki, ale też od wersji języka, w którym jest napisana (np. PHP). Jeżeli zatem nie możesz optymalizować silnika strony, zmiany zacznij od aktualizacji wersji PHP na serwerze.

Oczywiście to tylko część zaleceń. Zanim podejmiesz decyzję odnośnie jakiejkolwiek zmiany, wykonaj testy, aby upewnić się, co dokładnie jest tym „wąskim gardłem” przy pierwszej komunikacji z serwerem.

Większość serwisów w sieci oparta jest na znanych systemach CMS, które doczekały się uniwersalnych rozwiązań. Poniżej znajdziesz zalecenia dla niektórych z nich, które dodatkowo mogą poprawić czasy TTFB:

• Drupal
  Zalecane jest znalezienie optymalnego szablonu serwisu, selektywne wybieranie modułów optymalizacji oraz aktualizowanie serwera. Dodatkowo skorzystanie z pamięci podręcznej i skrócenie czasu zapytań do bazy danych.
• PrestaShop
  PrestaShop często posiada wiele modułów i wtyczek, które nie są wymagane do prawidłowego działania sklepu. Ich wyłączenie może poprawić czas TTFB. Dodatkowe zalecenia dla usprawnienia pracy silnika PrestaShop to wyłączenie funkcji wariantów (oczywiście, gdy ich nie wykorzystujesz), uruchomienie wbudowanej pamięci podręcznej, zmiany ustawień biblioteki SMARTY oraz skorzystanie z zestawu narzędzi CCC (combine, compress and cache).
• Magento
  Magento jest potężną platformą dla e-commerce, dedykowaną bardzo dużym sklepom. Dla Magento zalecane jest wykorzystanie procesu „cachowania” przy użyciu technologii Varnish i dedykowanego serwera. Więcej informacji znajdziesz tutaj:
  https://devdocs.magento.com/guides/v2.3/config-guide/varnish/config-varnish.html
• React
  W przypadku renderowania jakichkolwiek elementów po stronie serwera, zalecane jest użycie funkcji renderToNodeStream lub renderToStaticNodeStream. Pomogą one przesyłać wybrane znaczniki w odpowiedniej kolejności i czasie.
• WordPress
  Odnośnie systemu WordPress w sieci można spotkać się z wieloma poradnikami i gotowymi wtyczkami. Mogą one zdziałać cuda na stronie, ale ich nieumiejętne wykorzystanie może także zaszkodzić. W WordPressie największą bolączką często są same szablony (zwłaszcza te darmowe) oraz masa wtyczek, których łatwość instalacji sprawia, że wiele osób przestaje myśleć o wydajności strony.
  Zalecam przede wszystkim instalowanie tylko tych niezbędnych i unikanie upiększania serwisu różnymi „fajerwerkami” na stronie.
  Wtyczki warto wybierać rozważnie i opierać się na opiniach innych użytkowników. Jeżeli zdecydujesz się na instalację wtyczki dedykowanej do optymalizacji wydajności strony, zrób to z głową. Wartymi rozważenia wtyczkami są: WP Rocket, NitroPack, Asset CleanUp Pro, Smush, WP-Optimize.
  Musisz jednak pamiętać, że wtyczka nie jest lekarstwem na każdy problem. Przede wszystkim powinieneś wykonać analizę serwisu, aby postawić odpowiednią diagnozę. Dopiero po weryfikacji, które elementy wymagają poprawy oraz poznaniu specyfikacji wtyczek, możesz wybrać tę, która rozwiąże problem.
  Odpowiednie wykorzystanie wtyczki jest również kluczowe. Nie powinieneś automatycznie włączać od razu wszystkich funkcji — jedynie te, które dotyczą problemu.
  Po każdej zmianie ponów testy i podejmuj kolejne próby. W innym przypadku trudno będzie Ci wykorzystać pełny potencjał opcji, jakie oferuje wtyczka. W skrajnych przypadkach może nawet zaszkodzić.