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.
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ą:
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ę.
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ć.
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:
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 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.:
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.:
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:
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:
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: