N1 Nex1on

Szybsza strona w jeden wieczór: 9 kroków z pomiarem przed i po

Gotowe strony, kompresja, tylko potrzebne style, obrazy, harmonogram i OPcache: każdy krok to trzy linijki: co zrobić, jak sprawdzić to liczbą lub poleceniem i co się stanie, jeśli go pominiesz. Z pomiarem przed i po.

Odwiedzający nie czeka: jeśli strona otwiera się wolno, odchodzi, a wyszukiwarki biorą szybkość pod uwagę. Dobra wiadomość jest taka, że na większości małych stron spowalniają je te same rzeczy i można je naprawić w jeden wieczór bez zmiany motywu czy hostingu. Poniżej dziewięć kroków. Każdy ma trzy linijki: co zrobić, jak sprawdzić (ekran, polecenie lub liczba) i co się stanie, jeśli go pominiesz. Zaczynamy i kończymy pomiarem, żeby było widać, co pomogło.

Kroki są niezależne, możesz zacząć od dowolnego. Jedno zastrzeżenie od razu: liczby poniżej pochodzą z naszego stanowiska testowego, a nie z Twojej strony. U Ciebie będą inne, liczy się kierunek.

Twój panel: „Co poprawić” i „Stan systemu” #

Otwórz „Zarządzanie witryną → SEO i dostępność → Co poprawić” i wybierz kartę „Szybkość”: wymienia ona to, co nie jest jeszcze włączone na Twojej stronie. A w „System → Diagnostyka → Stan systemu” na dole jest blok „Zalecenia”: podpowiada w sprawie pamięci podręcznej, harmonogramu i OPcache.
„Co poprawić”, karta „Szybkość”: silnik sam wskazuje, co nie jest jeszcze włączone
„Co poprawić”, karta „Szybkość”: silnik sam wskazuje, co nie jest jeszcze włączone

Krok 1. Najpierw zmierz #

Co zrobić. Otwórz PageSpeed Insights, wklej adres strony głównej i uruchom test dla telefonu. Albo w przeglądarce Chrome: narzędzia deweloperskie, karta Lighthouse, „Analizuj wczytywanie strony”. Zapisz trzy liczby: LCP (kiedy pojawiła się główna część strony), CLS (jak bardzo strona „skacze”) i INP (jak szybko strona reaguje na dotknięcie). Cele według web.dev: LCP nie więcej niż 2,5 sekundy, INP nie więcej niż 200 milisekund, CLS nie więcej niż 0,1, i to dla trzech odwiedzających na czterech (75. percentyl). Jak sprawdzić. Masz zapisane trzy liczby i datę pomiaru. Jeśli pominiesz. Nie będziesz wiedzieć, czy zmiany pomogły. Zapamiętaj jeszcze dwie rzeczy. Wynik Lighthouse różni się między uruchomieniami: uruchom go trzy razy i weź środkowy. A wynik 100 nie jest celem: dokumentacja Chrome mówi, że jest niezwykle trudny do osiągnięcia i nie jest oczekiwany, a zielona strefa zaczyna się od 90.

Krok 2. Gotowe strony dla gości #

Co zrobić. W „Ustawienia serwisu → Szybkość i konserwacja” włącz „Podawaj gościom gotowe strony”. Strona zbudowana dla jednego gościa jest podawana pozostałym w gotowej postaci, bez pracy z bazą danych. Zalogowani dostają swoje strony jak zwykle, a pamięć podręczna czyści się sama przy każdej zmianie wprowadzonej w panelu. „Ile sekund przechowywać” możesz zostawić bez zmian: pięć minut (300) wystarczy. Jak sprawdzić. Pobierz stronę główną dwa razy:
Bash
curl -I https://example.com/
curl -I https://example.com/
Druga odpowiedź powinna zawierać linię X-Nex1on-Cache: hit. Na naszym stanowisku testowym strona budowana od nowa była podawana w 0,6–0,8 sekundy, a gotowa w 0,12–0,17.
Ustawienia „Szybkość i konserwacja”: gotowe strony, kompresja HTML i podpowiedzi dla obrazów
Ustawienia „Szybkość i konserwacja”: gotowe strony, kompresja HTML i podpowiedzi dla obrazów

Jeśli pominiesz. Każdy gość zmusza serwer do ponownego budowania strony z bazy danych. Na ruchliwej stronie ten krok zdejmuje z serwera większość pracy.

Krok 3. Skompresuj HTML #

Co zrobić. W tym samym miejscu włącz „Kompresuj strony HTML”: ze stron znikają zbędne spacje, podziały wierszy i komentarze. Wygląd się nie zmienia, panel administracyjny pozostaje nietknięty. Jeśli po włączeniu jakaś strona wygląda źle, wyłącz tę opcję. Jak sprawdzić. Porównaj rozmiar odpowiedzi przed i po:
Bash
curl -s https://example.com/ | wc -c
Na naszej testowej stronie głównej odpowiedź zmniejszyła się ze 157 do 138 KB, czyli o około 12 procent. Kompresja HTML jest bardziej przydatna razem z gotowymi stronami (krok 2): bez nich serwer kompresuje każdą stronę od nowa dla każdego gościa, o czym przypomni „Stan systemu”. Jeśli pominiesz. Strony ważą więcej, niż muszą. Nic się nie psuje, po prostu każdy odwiedzający płaci za zbędne kilobajty.

Krok 4. Tylko potrzebne style #

Co zrobić. Włącz „Tylko potrzebne style na stronie”: zamiast kilku pełnych arkuszy stylów strona dostaje jeden, z samymi regułami, które mogą jej dotyczyć. Wygląd się nie zmienia. Jak sprawdzić. Otwórz źródło strony (Ctrl+U) i znajdź rel="stylesheet". Na naszym stanowisku testowym trzy arkusze stylów (około 634 KB bez kompresji) zastąpił jeden (157 KB). Jeśli pominiesz. Telefon pobiera reguły dla stron, których nie otworzył: strona główna otwiera się wyraźnie wolniej, zwłaszcza w sieci komórkowej.

Krok 5. Obrazy #

Co zrobić. W „Ustawienia serwisu → Obrazy i wideo” sprawdź trzy rzeczy. Po pierwsze: „Największa szerokość obrazu, px” domyślnie wynosi 0, co oznacza brak limitu. Ustaw liczbę, której naprawdę potrzebujesz (na przykład 2000): duże obrazy są zmniejszane przy przesyłaniu z zachowaniem proporcji. Zdjęcie szerokie na sześć tysięcy punktów to za dużo dla kolumny szerokiej na tysiąc. Po drugie: „Kompresja obrazów”: domyślnie jest ustawiona na „Lokalnie” i nic nie opuszcza strony; zewnętrzna usługa TinyPNG zwraca lżejsze pliki, ale Twój obraz jest wtedy wysyłany na cudzy serwer. Po trzecie: włącz „Obrazy także w WebP”: strona przechowuje też lżejszą kopię i podaje ją przeglądarkom, które o nią proszą. Kopie powstają tylko dla nowych plików; dla obrazów już przesłanych uruchom na serwerze polecenie php nex1on media:webp. „Podpowiedzi dla przeglądarki o obrazach” zostaw włączone: silnik sam dodaje rozmiary, leniwe ładowanie poniżej pierwszego ekranu i priorytet dla głównego obrazu.
Ustawienia „Obrazy i wideo”: największa szerokość, kompresja i WebP
Ustawienia „Obrazy i wideo”: największa szerokość, kompresja i WebP

Jak sprawdzić. Zobacz, co silnik zapisał na stronie:

Bash
curl -s https://example.com/ | grep -o '<img[^>]*>' | head -3

Obrazy powinny mieć width i height (strona nie skacze podczas ładowania), srcset oraz decoding="async". Główny obraz na pierwszym ekranie ma fetchpriority="high" i nie ma loading="lazy"; te niżej na stronie mają loading="lazy". Tak ma być: web.dev wprost ostrzega przed leniwym ładowaniem obrazu widocznego od razu, bo wtedy strona otwiera się wolniej.
Jeśli pominiesz. Obrazy to zwykle najcięższa część strony, a jedno nieodpowiednie zdjęcie może ważyć więcej niż cała reszta.

Krok 6. Czcionki #

Co zrobić. Motywy dostarczane z silnikiem nie ładują czcionek z serwera: tekst używa czcionek, które już są na urządzeniu odwiedzającego, więc nic się nie pobiera. Jeśli mimo to dodajesz własną czcionkę, trzymaj się zasad web.dev: format WOFF2, tylko potrzebne odmiany, font-display: swap (lub optional) i nie wczytuj z wyprzedzeniem wszystkiego. Jak sprawdzić. W narzędziach deweloperskich, na karcie Network, z filtrem Font: dla strony bez ładowanych czcionek lista jest pusta. Jeśli pominiesz. Każda dodana czcionka to dodatkowy plik, który blokuje tekst albo sprawia, że strona „skacze”, gdy czcionka zostaje podmieniona.

Krok 7. Harmonogram i OPcache #

Co zrobić. Otwórz „System → Diagnostyka → Stan systemu” i spójrz na blok „Zalecenia”. Jeśli jest tam „Poczta wychodzi przy wejściach odwiedzających”, dodaj na hostingu harmonogram (cron) uruchamiany co minutę: samo zalecenie pokazuje gotowe polecenie. Wtedy poczta i zadania w tle są przetwarzane bez udziału odwiedzających, a strony nie czekają na pocztę. Jeśli jest tam „PHP OPcache jest niedostępny”, poproś pomoc techniczną hostingu o włączenie go: OPcache trzyma przetworzony PHP w pamięci i serwer nie analizuje tych samych plików przy każdej wizycie. Jak sprawdzić. Odpowiednie wiersze w „Zaleceniach” znikają. Jeśli pominiesz. Strona wykonuje dodatkową pracę przy każdej wizycie, a zauważysz to dopiero w godzinach szczytu.

Krok 8. Błyskawiczne przejścia (opcjonalnie) #

Co zrobić. Włącz „Błyskawiczne przejścia”: gdy odwiedzający najedzie kursorem na link, przeglądarka (Chrome i podobne) pobiera stronę z wyprzedzeniem, a kliknięcie otwiera ją niemal natychmiast. Działa to dla gości i dla stron, które są już w pamięci gotowych stron, więc najpierw włącz krok 2. Wyświetlenia i liczniki nie rosną od wczytywania z wyprzedzeniem. Panel administracyjny, logowanie, pobieranie plików, linki potwierdzające e-mail i adresy ze znakiem zapytania nigdy nie są wczytywane z wyprzedzeniem. Jak sprawdzić. W narzędziach deweloperskich, na karcie Network: gdy najedziesz kursorem na link, na liście pojawia się żądanie tej strony. Jeśli pominiesz. Nic strasznego: to dodatek, a nie konieczność.

Krok 9. Zmierz po #

Co zrobić. Powtórz krok 1 i porównaj trzy liczby. Aby patrzeć nie na dane laboratoryjne, lecz na prawdziwych odwiedzających, włącz „Rzeczywista szybkość u odwiedzających”: przeglądarka odwiedzającego mierzy LCP, CLS i INP i przy wyjściu wysyła tylko liczby. Adresy IP, ciasteczka i dane przeglądarki nie są przechowywane, boty i osoby, które włączyły „do not track”, nie są liczone, zgoda odwiedzającego zwykle nie jest potrzebna, bo nie ma tu danych osobowych, ale sprawdź to z prawnikiem w swoim kraju. Wyniki pojawiają się w „SEO i dostępność → Szybkość”. Jak sprawdzić. Trzy nowe liczby obok starych. Pomiar laboratoryjny pokazuje jedno urządzenie i jedną sieć, a prawdziwy obraz to to, co widzą Twoi odwiedzający, więc gdy się różnią, ufaj temu drugiemu. Jeśli pominiesz. Będziesz zgadywać zamiast wiedzieć.

Czego ta lista nie robi #

Usuwa zbędną pracę, ale nie przyspieszy tego, co jest ciężkie z natury: bardzo ciężkiego motywu, dziesiątek zewnętrznych widżetów i liczników czy przeciążonego hostingu. Jeśli po wszystkich krokach strona nadal działa wolno, sprawdź na karcie Network, co ładuje się najdłużej, i od tego zacznij.
Udostępnij: Telegram WhatsApp

Przeczytaj też

Dyskusja

Komentarze

Dyskusja jeszcze się nie zaczęła

Nikt jeszcze nie skomentował. Bądź pierwszy.

Zgłoś ten wpis