Przewodnik WPO: jak zoptymalizować szybkość Twojej strony

Czym jest WPO?

Web Performance Optimization, które nazywamy WPO, to po prostu optymalizacja różnych procesów, które wpływają na to, jak ładuje się strona.

Jak zmierzyć szybkość ładowania strony?

Istnieje wiele narzędzi do mierzenia szybkości ładowania. Najpopularniejsze z nich to:

• ›

  Google Page Speed

• ›

  Lighthouse

• ›

  GTMetrix

Przed rozpoczęciem audytu warto pamiętać, że szybkość ładowania różni się dla każdego użytkownika. Różne zmienne mogą wpływać na to, jak szybkość odczuwa użytkownik w Cuenca w porównaniu z użytkownikiem w Ottawie.

Dlatego, zamiast pracować nad czasami ładowania w sekundach, zalecamy skupienie się na optymalizacji:

• ›

  Wagi strony (MB)

• ›

  Zapytań

• ›

  Czasu odpowiedzi serwera

Jeśli poprawimy te 3 obszary, szybkość ładowania ulegnie poprawie niezależnie od tego, gdzie znajduje się użytkownik.

Zagłębimy się w każdy obszar i, poprzez różne narzędzia, zobaczymy, jak nad nimi pracować, aby poprawić wydajność każdego URL-a. Dlaczego mówię o każdym URL-u? Ponieważ, choć może wydawać się to oczywiste, spotkałem się z wieloma przypadkami, w których oceniane były tylko dane strony głównej, a oczywiście nie każda strona w witrynie ładuje te same zasoby.

Narzędzia deweloperskie Google

Zanim zaczniemy, chcę wyjaśnić kilka opcji, które Google oferuje poprzez swoje narzędzia deweloperskie. To narzędzie jest jednym z najważniejszych do analizowania, jak działa strona. Kliknij prawym przyciskiem myszy na stronie, którą ma otwartą przeglądarka, i pojawi się panel z różnymi opcjami. Przejdziemy do Inspect (Ctrl + Shift + I).

Gdy to narzędzie jest otwarte, przejdziemy do opcji NETWORK, którą znajdziesz na górze. Jeśli ponownie naciśniemy ENTER w przeglądarce, narzędzie pokaże ładowanie różnych zasobów.

Na dole obrazu możemy zobaczyć dane, które nas interesują dla ogólnego widoku tego, jak ładuje się strona.

Zagłębiając się w ten panel od góry i patrząc na strukturę kolumn, mamy:

• ›

  Name: nazwa zasobu.

• ›

  Status: kod odpowiedzi zasobu (200, 301, 404...)

• ›

  Type: typ zasobu (script, font, png, jpg, stylesheet...)

• ›

  Initiator: który zasób uruchamia żądanie.

• ›

  Time: ile trwało żądanie.

• ›

  Waterfall: graficzna reprezentacja czasów ładowania zasobu.

Jeśli klikniemy prawym przyciskiem myszy na górze, możemy dodawać i usuwać kolumny z tymi informacjami.

Włączenie dodatkowych elementów informacyjnych, takich jak Domain, Scheme lub Cookies, może w konkretnych przypadkach pomóc zlokalizować zasoby, które mogą sprawiać nam pewien problem, ale na tym etapie pozostaniemy przy tych, które są ustawione domyślnie.

Jest jeden aspekt, który, choć bardzo ciekawy, poruszę tylko pobieżnie, abyśmy mieli go na uwadze. Szybkość połączenia, zwłaszcza na urządzeniach mobilnych, jest kluczowym elementem ładowania strony. Z tego narzędzia możemy symulować wolniejsze prędkości, takie jak 3G na urządzeniach mobilnych.

Jak poznać wagę URL-a i jak ją zmniejszyć?

Waga, czy to w megabajtach czy kilobajtach, jest jednym z głównych powodów, dla których ładowanie URL-a zajmuje czas. Dlatego zaczynamy od zagłębienia się w ten aspekt, ponieważ wyznaczy on ścieżkę do osiągnięcia dobrej optymalizacji naszej strony.

Następujące dane pochodzą z narzędzia wspomnianego powyżej, GTMETRIX, i odpowiadają stronie, którą zaraz zacznę optymalizować.

Skupimy się na danych w prawej kolumnie, tej, która odnosi się do (Page Details), konkretnie na Total Page Size.

Na pierwszy rzut oka waga tej strony jest znacznie powyżej średniej, ale pamiętaj, że nie liczy się całkowita waga strony, lecz ile czasu zajmuje załadowanie tej wagi, ponieważ istnieje coś takiego jak Lazy Load, funkcja, która opóźnia ładowanie do momentu, gdy użytkownik potrzebuje zasobu. Porozmawiamy o tym później.

Możemy również znaleźć te informacje w narzędziach deweloperskich, w panelu, na który patrzyliśmy powyżej, który ponownie Ci przypomnę.

Jeśli spojrzysz na dół, zarówno 7,5 MB, jak i 215 zapytań są bardzo zbliżone do liczb podawanych przez GTMETRIX. To ważne, abyś wiedział, skąd GTMETRIX pobiera swoje informacje, na wypadek, gdybyś kiedyś chciał użyć innego narzędzia.

Teraz zobaczmy, co tak waży i jak możemy to naprawić.

Opcja Waterfall oferuje wizualne spojrzenie na to, jak ładują się zasoby, pokazując URL zasobu, status, domenę i kolumnę Size. Jeśli klikniemy na tę ostatnią kolumnę, sortuje wagi od największej do najmniejszej i od najmniejszej do największej.

Patrząc na wagi, możemy zobaczyć, jak to się dzieje w większości przypadków, że obrazy są w dużej mierze odpowiedzialne za nadmierną wagę URL-a.

Nie ma formalnej specyfikacji co do maksymalnej wagi, jaką powinien mieć obraz, ale zalecamy nie więcej niż 100 KB i, jeśli masz taką możliwość (jeśli używasz Photoshopa, masz), ustaw obrazy tak, aby ładowały się progresywnie jako JPG i unikaj PNG, kiedy nie potrzebujesz kanału Alpha (przezroczystości).

Zmniejszając wagę obrazów, znacznie poprawimy ładowanie strony, a istnieje kilka narzędzi, których możesz użyć. Osobiście optymalizuję za pomocą Photoshopa, ale są ciekawe opcje online:

• ›

  https://imagecompressor.io/compress

• ›

  https://kraken.io/web-interface

Zarówno GTMetrix, jak i narzędzie Google pozwalają nam przeglądać zasoby według typu, czyli tylko obrazy, skrypty, CSS...

Jest to przydatne dla szerszej perspektywy, gdzie pracować. W tym URL-u obrazy stanowią 4 MB z 7,2 MB, więc duża część problemu z wagą jest tam. Mimo to są inne zasoby, które wyróżniają się jako wyjątkowo ciężkie jak na swój typ, takie jak plik CSS o wadze ponad 700 KB i Skrypt o wadze ponad 300 KB.

W tym momencie chciałbym wyjaśnić, że gdy przeprowadzamy optymalizację szybkości ładowania (WPO), musimy stawić czoła pewnym problemom, które, choć mają rozwiązania, nie leżą w naszych możliwościach działania.

W tym przypadku widzimy bardzo duży plik CSS. Jeśli projektant stworzył CSS o wadze ponad 700 KB, optymalizacja tego konkretnego pliku będzie trudna.

Co możemy zrobić, aby zmniejszyć wagę tych plików?

Minify (CSS, JS i HTML)

Minifikacja to proces, który ma na celu zmniejszenie wagi pliku poprzez usunięcie zbędnych danych, takich jak komentarze, spacje, powtarzający się kod i nieużywany kod. Istnieje wiele narzędzi do przeprowadzania tego procesu, z wyjątkiem części dotyczącej nieużywanego kodu, którą trudniej zoptymalizować i która wymagałaby ręcznego wejścia do pliku (czego nie polecam).

Narzędzia do minifikacji plików

• ›

  HTML Minifier http://kangax.github.io/html-minifier/

• ›

  CSS Nano https://cssnano.co/

• ›

  Uglify http://lisperator.net/uglifyjs/

Na szczęście mówimy o WordPressie i, jak wszyscy wiemy, w WordPressie bardzo rzadko nie znajdziemy wtyczki, która obsługuje tę operację.

Osobiście lubię używać całkowicie darmowej, Autoptimize, oraz płatnej, WP Rocket.

W tym artykule nie chcę tłumaczyć, jak działają te wtyczki, lecz raczej jak przeprowadzać zadania optymalizacyjne. Bo jeśli używamy innych wtyczek, one również mają te opcje, a najlepszą rzeczą jest zrozumieć, co robimy.

Minifikacja za pomocą WP Rocket

Ta część nie jest skomplikowana. Po prostu przechodzimy do zakładki optymalizacji plików i zaznaczamy pole minify HTML. W WP Rocket ta opcja powtarza się poniżej dla plików CSS i JS. Mimo to zalecam włączanie tego pola i testowanie. Powtarzaj tę opcję pojedynczo, ponieważ jeśli coś zawiedzie, łatwiej będzie zlokalizować problem.

Przed sprawdzeniem efektu minifikacji musimy wyczyścić cache, w przeciwnym razie nie zobaczymy rezultatu zaktualizowanego HTML.

Jak wyczyścić cache przeglądarki?

Tego rodzaju wtyczki mają opcje czyszczenia cache, które możemy zobaczyć na górze.

Innym sposobem jest użycie przeglądarki, gdy włączone są narzędzia deweloperskie Google (Ctrl + Shift + I).

Kliknij prawym przyciskiem myszy strzałkę „przeładuj stronę" i wybierz „opróżnij pamięć podręczną i wymuś ponowne ładowanie."

Minifikacja za pomocą Autoptimize

W Autoptimize akcja optimize wykonuje minifikację, ze szczególną cechą oferowania opcji zachowania komentarzy HTML. Te komentarze są zwykle dodawane przez deweloperów, aby zachować informacje, które mogą być przydatne w przyszłości.

Aby sprawdzić, czy ta optymalizacja zadziałała, przejdziemy do kodu źródłowego URL-a i powinniśmy zobaczyć coś takiego:

Kod staje się nieczytelny, ale jego funkcjonalność jest taka sama.

Te opcje powtarzają się w ten sam sposób w WP Rocket i Autoptimize dla plików CSS i JS. Jak wspomniałem wcześniej, nie polecam optymalizować wszystkiego naraz, ale 1 po 1. Te wtyczki przechowują kopie zminifikowanych plików, więc powrót do oryginału jest możliwy poprzez odznaczenie odpowiedniego pola.

Aby dalej zmniejszać wagę strony, mamy 2 dodatkowe opcje:

• ›

  Usunąć lub ograniczyć wtyczki, które dodają CSS lub JS do ładowania.

• ›

  Usunąć lub przyciąć nieużywany kod z pliku CSS.

Te 2 opcje są bardziej złożone i wymagają więcej wiedzy, ponieważ trzeba być ostrożnym i upewnić się, że nie ma wywołań z innych stron do części, którą usuwasz.

Choć usuwanie wtyczek nie zawsze jest możliwe ze względu na zasób, który dostarczają, są wtyczki, które są lepiej zoptymalizowane niż inne, co oznacza mniej zapytań i lżejszy JS. Więc w cudownym ekosystemie WordPress prawie zawsze istnieje alternatywa.

Czas ładowania vs czas odpowiedzi

Teraz nadszedł czas, aby porozmawiać o zapytaniach, czasie odpowiedzi i czasie ładowania. W tym momencie musimy wspomnieć o fundamentalnej części procesu: serwerze. Optymalizacja serwera zwykle leży poza naszym zasięgiem, więc ważne jest, aby wybrać efektywne rozwiązanie.

Ale zróbmy to krok po kroku.

Czym jest zapytanie?

Zapytanie, czyli HTTP Request, to wywołanie wykonywane od klienta do serwera w celu poproszenia o dany zasób. Zapytania mogą trafiać do różnych serwerów.

Zapytania mogą być HTTP lub HTTPS. Jeśli spojrzymy na strukturę zapytania, możemy przeanalizować, gdzie występuje opóźnienie w czasie.

Analiza czasu zapytania HTTP

Rozłóżmy na czynniki to, co widzimy w tym wykresie czasowym.

• ›

  Zapytanie zostało rozpoczęte, ale jest zablokowane lub w kolejce: Jeśli blokada trwa długo, może to być spowodowane kilkoma powodami: zapytaniami o wyższym priorytecie lub wieloma zapytaniami do tego źródła.

• ›

  DNS Lookup: przeglądarka rozpoznaje adres IP zapytania.

• ›

  Connecting: czas potrzebny do połączenia z serwerem w celu rozwiązania zapytania. Jeśli ten czas jest wysoki, może to wskazywać na problemy z siecią, błędy połączenia lub przeciążony serwer.

• ›

  Sending: zapytanie o zasób jest wysyłane.

• ›

  Waiting: to czas, jaki serwer potrzebuje na rozwiązanie zapytania i wysłanie odpowiedzi; jeśli jest długi, jest problem na serwerze.

• ›

  Receiving: odbieranie zasobu.

Zapytanie HTTPS dodaje jeden krok więcej, pokazany tutaj.

Te dwa zrzuty ekranu należą do dwóch różnych witryn, jednej niezoptymalizowanej (HTTP Request) i drugiej zoptymalizowanej (HTTPS Request).

Jeśli przyjrzysz się uważnie i porównasz, największa różnica jest w czasie oczekiwania. W takich przypadkach trzeba by przeanalizować serwer bardziej szczegółowo.

Zapytania do serwera: jak możemy je zmniejszyć?

Jak widzieliśmy, liczba zapytań jest ściśle związana z czasem ładowania, więc zmniejszenie liczby zapytań poprawiłoby czasy ładowania URL-a. Zdrowy rozsądek odgrywa rolę w procesie optymalizacji oraz wiedza o tym, czy zasób jest naprawdę przydatny dla użytkownika lub naszego biznesu. To jest moment, aby pożegnać się z pewnymi zasobami, które nic nie wnoszą, ale to nie ja mam o tym decydować.

Mimo to mamy opcje poprawy zapytań, nawet jeśli te działania nie przynoszą ogromnej zmiany w ładowaniu strony. Powtórzę się: najlepszą rzeczą jest usunięcie zasobów, które nic nie wnoszą.

Łączenie CSS i JS

Kolejnym popularnym działaniem przy optymalizacji strony internetowej jest łączenie zasobów CSS i JS, ale co to oznacza?

Celem łączenia jest zmniejszenie zapytań kosztem zwiększenia wagi pliku. Łączenie oznacza ujednolicenie różnych zasobów CSS lub JS w jeden.

Jeśli czasy odpowiedzi są długie, łączenie może być korzystne. Jeśli czasy wysyłania są bardzo wolne, może lepsza będzie inna technika.

Ideałem jest łączenie przy posiadaniu dobrego serwera, więc wygrywamy na obu frontach.

Łączenie zasobów za pomocą WP Rocket i Autoptimize

Operacja łączenia za pomocą tych wtyczek jest tak prosta jak wcześniej. Po prostu zaznaczamy odpowiednie pole.

W WP Rocket opcje łączenia CSS i JS są takie same; panele są praktycznie identyczne. Jak widzimy na obrazie, jest pole do dodania ścieżki plików, których nie chcemy łączyć.

Pod polem wyboru widzimy również notatkę o niestosowaniu opcji łączenia, jeśli używamy HTTP/2. Ten artykuł wyjaśnia więcej o HTTP/2.

Autoptimize oferuje więcej opcji do pracy z CSS i zmniejszania zapytań. W opcji, którą zaznaczam, łączy i daje ostrzeżenie o efekcie, jaki może mieć, ale ostatecznie jest to zawsze relatywne.

W tej pierwszej części artykułu chciałem wyjaśnić, na czym polegają pewne podstawowe działania, te, które zwykle widzimy praktycznie we wszystkich wtyczkach optymalizacyjnych WPO, ale wciąż jest wiele, co możemy zrobić, aby poprawić zarówno zapytania, jak i czasy ładowania.

Konfiguracja cache

Bez wątpienia optymalizacja cache jest jednym z działań, w których zauważymy największe poprawy w sposobie ładowania strony. W tym artykule o SEO dla WordPress wyjaśniłem, jak działa cache. Zachęcam, abyś rzucił okiem, aby zrozumieć, jak to działa.

Autoptimize i WP Rocket wykonują działania cache, ale WP Rocket daje kilka dodatkowych opcji. Warto zauważyć, że wtyczki uczyniły tę optymalizację czymś prostszym: masz zaledwie kilka opcji, a proces jest szybki i bezbolesny.

Jak widzisz, WP Rocket pozwala pracować nad 4 rzeczami:

• ›

  Włączyć caching dla urządzeń mobilnych.

• ›

  Zapisywać pliki osobno dla urządzeń mobilnych.

• ›

  Włączyć caching dla zalogowanych użytkowników.

• ›

  Określić czas czyszczenia cache.

To zależy od każdego projektu, którą opcję wybrać, ale mając to wszystko na uwadze, moja rada to:

• ›

  Cache mobilny zawsze, ponieważ choć większość witryn jest responsywna, są treści, które możesz mieć na mobilnym, ale nie na desktopie.

• ›

  Pliki osobno.

• ›

  Brak cache dla zalogowanych użytkowników, przede wszystkim dlatego, że jeśli wprowadzam zmiany, nie chcę cache.

• ›

  Czas cache, który zależy od tego, ile zmian wprowadzasz na swojej stronie. Jeśli to dzienna witryna informacyjna, krótki; jeśli to treści, które nie są często aktualizowane, dłuższy.

Lazyload

Funkcja lazyload pomaga wyświetlać zasoby (Obrazy i Iframes), gdy użytkownik ich potrzebuje; to znaczy, przeglądarka nie ładuje tych zasobów, dopóki użytkownik nie przewinie do nich. Ta funkcja jest zaimplementowana w wielu wtyczkach, a nawet jest wstępnie skonfigurowana w niektórych motywach WordPress. Od wersji Chrome 76 włącznie jest nawet natywna w przeglądarce.

Oznacza to, że poprzez dodanie atrybutu loading="lazy", przeglądarka już interpretuje leniwe ładowanie obrazu, ale oczywiście nie każda przeglądarka będzie to interpretować, więc zalecam dalsze używanie wtyczki. Oto wideo wyciągnięte z web.dev pokazujące przykład tego, na czym polega leniwe ładowanie obrazów.

Optymalizacja iframe

Jeśli używamy iframe do osadzania treści z innych witryn, mamy dwie akcje, których możemy użyć, aby poprawić nasze ładowanie.

• ›

  Leniwe ładowanie poprzez funkcję lazyload

• ›

  Lub zastąpienie iframe obrazem, dopóki użytkownik nie kliknie na niego.

Zarówno pierwszą, jak i drugą opcję można włączyć poprzez, ponownie, naszą ulubioną wtyczkę WP Rocket.

Autoptimize nie ma tej części, ale oferuje instalację uzupełniającej wtyczki, aby to zrobić https://wordpress.org/plugins/wp-youtube-lyte/

Odroczone ładowanie plików JS za pomocą Defer lub Async

Pliki JS są jednym z winowajców tego, co audyty szybkości nazywają blokowaniem renderowania strony. Dzieje się tak, gdy podczas renderowania przeglądarka zatrzymuje się, aby pobrać plik JS i go wykonać. Celem optymalizacji WPO jest dostarczenie informacji użytkownikowi tak szybko, jak to możliwe, dlatego jest to uważane za blokowanie, ponieważ nic nie jest renderowane, dopóki pobrany JS się nie wykona.

Dlatego ten typ akcji jest zwykle oznaczany w audycie. Korzystając z wtyczek innych firm lub motywów, które nie są dobrze zoptymalizowane, możemy mieć JS, który blokuje renderowanie, ponieważ znajduje się na przykład w nagłówku.

W takich przypadkach powinniśmy użyć dwóch atrybutów, które są dodawane w kodzie wywołania JS, Defer i Async. Aby te atrybuty działały, skrypty muszą być zewnętrzne.

W SEO Alive używamy wtyczki Pre Party Resource Hints, która pozwala wybrać, które pliki i którą metodę ładowania chcesz zastosować. Cudo!

Jaka jest różnica między Defer a Async?

Choć oba atrybuty mają podobny cel, zapobieganie zatrzymaniu interpretacji DOM HTML przez JS, między nimi istnieje znacząca różnica.

Z atrybutem Async zasób jest pobierany bez zatrzymywania ładowania HTML, ale po pobraniu ładowanie HTML jest wstrzymywane, aby wykonać JS; z atrybutem defer zasób jest również pobierany równolegle z ładowaniem HTML, ale uruchamia się, gdy ładowanie się zakończy, więc nie ma blokowania przez skrypt.

Pod tym względem są różnice między WP Rocket a Autoptimize. WP Rocket podejmuje za Ciebie decyzje znacznie łatwiej i działa w sposób półautomatyczny, aby JS nie blokował renderowania; w Autoptimize natomiast możesz tylko przełączać opcję Async.

W Autoptimize, w zakładce extra, mamy tę opcję dodawania plików JS, które chcemy załadować z Async, ale dla większej elastyczności zalecają inną uzupełniającą wtyczkę, „Async Javascript".

Z tą wtyczką możemy pracować zarówno z Defer, jak i Async, a nawet oferuje opcje jednym kliknięciem, aby ułatwić sprawę. Dobrą rzeczą tej wtyczki jest to, że możemy pracować ze skryptami i wykluczać te, które uznajemy za konieczne. W WP Rocket natomiast musimy zaufać temu, co robi wtyczka, choć robi to dobrze.

Ta opcja znajduje się w tej samej zakładce optymalizacji plików.

Czym jest CDN i jak może nam pomóc?

CDN to to, co znamy jako sieć dostarczania treści. CDN odpowiada za zapisywanie części informacji i zasobów, aby ułatwić obciążenie serwera tymi zasobami i lepiej odpowiadać na obciążenie. CDN-y mają również funkcję geograficznej kopii, aby utrzymać zasób dostępny w różnych punktach i serwować go użytkownikowi niezależnie od miejsca, z którego się łączy. Zwykle ten rodzaj usługi jest używany dla ciężkich plików, takich jak Obrazy i Wideo.

Zapisanie się na tę usługę jest ważne, gdy mamy witryny z dużym ruchem, choć nie powinno być wykluczone dla witryn z niewielkim ruchem.

Inne działania, które przyniosą nam trochę więcej poprawy

Aby zakończyć artykuł, mamy 3 dodatkowe ulepszenia, które, choć nie przyniosą ogromnych zmian w czasach ładowania, pomogą nam zmniejszyć zapytania, a w końcu o to nam chodzi.

Optymalizacja czcionek

Optymalizację czcionek można przeprowadzić poprzez wtyczki lub ręcznie poprzez edycję i optymalizację CSS. Ideałem byłoby wywołanie tylko czcionki, której zamierzasz użyć, a nie, jak to się dzieje w wielu przypadkach, pobranie pliku ze wszystkimi Google Fonts.

Autoptimize ma opcję pracy nad czcionkami.

Trudno powiedzieć, którą opcję wybrać bez zobaczenia projektu, ponieważ nie wiem, jakiej czcionki używa Twój szablon i kiedy się ładuje, więc najlepszą rzeczą jest testowanie i zobaczenie rezultatu.

Jak widzisz, zaraz po opcjach Google Fonts mamy „Remove Emoji", które zaoszczędzi nam zapytanie do serwera. Jego funkcją jest po prostu konwersja symboli reprezentujących emoji na ikonę.

WP Rocket również pozwala nam wyłączyć te emoji i oferuje również opcję zapobiegania osadzaniu treści na stronach trzecich.

Ostatecznie istnieje wiele działań poprawiających szybkość ładowania strony. Nie zawsze możliwa jest dogłębna praca nad optymalizacją każdego zasobu, ponieważ zależy to od typu biznesu i tego, czego potrzebuje.

Mam nadzieję, że ten przewodnik optymalizacji WPO będzie pomocny i że będziesz mógł zastosować go w swoich projektach lub dla swoich klientów.