Jak przyspieszyć stronę WordPress: praktyczne kroki

Jak przyspieszyć stronę WordPress? Zmierz najpierw, potem naprawiaj w kolejności rentowności: czas odpowiedzi serwera i cache strony, następnie duży obraz bohaterski, potem CSS i JavaScript blokujące renderowanie, na koniec baza danych i obciążenie wtyczkami. Większość wolnych witryn zwalnia z powodu dwóch lub trzech z nich, nie wszystkich. Uruchom PageSpeed Insights na najwolniejszym szablonie, zanotuj element Largest Contentful Paint i postępuj zgodnie z tą listą, aż liczba zmieni się na zielony.

Zacznij od pomiaru bazowego, bo inaczej optymalizować będziesz nie to

Prace nad szybkością bez pomiaru to przesąd. Zanim dotkniesz wtyczki, zapisz trzy liczby na najwolniejszym rzeczywistym szablonie (zazwyczaj wpis z dużym obrazem bohaterskim lub strona produktu WooCommerce): Largest Contentful Paint, Interaction to Next Paint i Time to First Byte. Testuj na mobilnych ustawieniach, bo tam widać przepaść między „szybko na moim komputerze" a „szybko dla klientów odbiorcy".

Cele są opublikowane, nie to legenda. Przewodnik Google web.dev dotyczący LCP traktuje 2,5 sekundy lub mniej jako dobrą wartość na 75. percentylu rzeczywistych wizyt. INP powinno pozostać poniżej 200 milisekund, a przesunięcie układu poniżej 0,1. Zapisz to na karteczce obok monitora.

Narzędzia laboratoryjne takie jak Lighthouse dają powtarzalny punkt odniesienia. Dane z raportu Chrome User Experience, wyświetlane u góry PageSpeed Insights, mówią, co odwiedzający faktycznie uzyskali. Gdy się różnią, zaufaj danym rzeczywistym i użyj biegu laboratoryjnego, aby znaleźć przyczynę.

Marginalia: ta kolejność prac obowiązuje dla WordPress 6.5 i nowszych. Starsze instalacje mają więcej do naprawy, zanim cokolwiek z tego ma znaczenie.

Najpierw napraw serwer: hosting, PHP i Time to First Byte

Każda sztuczka front-endowa spoczywa na pierwszej odpowiedzi. Jeśli HTML trafia przez 1,5 sekundy, żadna kompresja obrazu nie uratuje LCP. Time to First Byte to liczba ujawniająca słabego hosta, przestarzałą gałąź PHP lub stronę, którą odbudowuje się od nowa przy każdym żądaniu.

Sprawdź trzy rzeczy w tej kolejności. Uruchom gałąź PHP będącą w bieżącym wsparciu, bo każde wydanie jest mierzalnie tańsze na żądanie niż poprzednie. Potwierdź, że host oferuje trwały cache obiektów (Redis lub Memcached), bo usuwa powtarzające się odczyty z bazy danych dla opcji, menu i zapytań. I spójrz na sam plan: serwer wspólny ze stu sąsiadami będzie Cię ograniczać w dokładnym momencie, gdy ruch wzrośnie.

Jeśli zarządzasz wieloma witrynami klientów, to jest moment, w którym hosting zarządzany zarabia na swoją opłatę. Platforma, która łączy hosting, cache i cel wydajności usuwa całą kategorię zgadywania. 10Web to jeden przykład, który hostuje WordPress na Google Cloud i dąży do wyniku PageSpeed powyżej 90 na start, co jest rozsądnym ustawieniem domyślnym dla małej agencji bez dedykowanej osoby ds. operacji.

Pomiń pokusę kupienia większego planu, zanim włączysz cache. Ulepszenie sprzętu do serwowania stron niezapamiętanych to płacenie więcej za robienie tej samej marnowniczej pracy szybciej.

Włącz cache pełnej strony i sprawdź, czy naprawdę działa

WordPress buduje każdą stronę za pomocą PHP i MySQL za każdym razem, gdy ktoś o nią pyta. Cache strony zapisuje gotowy HTML i zamiast tego służy do tego pliku. Dla witryny głównie czytanej, takiej jak blog, witryna promocyjna czy portfolio, ta pojedyncza zmiana często przenosi TTFB z sekund na dziesiątki milisekund.

Wybierz jedną warstwę cache strony i tylko jedną. Stosowanie cache na poziomie hosta, wtyczki cache i cache CDN bez wiedzy, który z nich serwuje żądanie, to jak spędzić cały popołudek debugując zatwierdzone treści. Zapytaj hosting, co już zapewnia, zanim cokolwiek instalujesz.

Następnie sprawdź, czy cache trafia. Otwórz panel sieciowy przeglądarki, przeładuj stronę publiczną dwa razy i przeczytaj nagłówki odpowiedzi. Większość cache'y ogłaszają trafienie lub chybienie, a wiele dodaje wartość wieku. Jeśli widzisz tylko chybienia, cache jest ominięty przez ciasteczko, ciąg zapytań lub stan zalogowanego, a „optymalizacja" to tylko dekoracja.

Sklepy wymagają dodatkowej ostrożności. Koszyk, kasa i strony konta nigdy nie powinny być buforowane, a witryny WooCommerce zwykle zależą od wtyczki cache, która zna te wyłączenia. Jeśli wyłączenia będą złe, klienci zobaczą koszyki siebie nawzajem, co jest gorszym problemem niż wolna strona.

Zmniejsz obraz bohaterski, typowego winowajcę LCP

Na większości wolnych stron WordPress elementem LCP jest obraz: bohater, obraz wyróżniony lub pełnoszerokie tło. To sprawia, że waga obrazu jest najczęstszą przyczyną niepowodzenia wyniku. JPEG 4000 pikseli szerokości eksportowany bezpośrednio z aparatu, wyświetlany w kolumnie 1200 pikseli, wysyła kilka razy więcej bajtów niż układ może używać.

Postępuj przez potok obrazu w tej kolejności:

• Zmień rozmiar na największy rozmiar, który układ naprawdę wyświetla, nie rozmiar, który eksportował projektant.

• Serwuj WebP lub AVIF, obie z których rdzeń WordPress obsługuje od kilku wydań.

• Pozwól rdzeniowi wygenerować warianty srcset responsywne zamiast kodować jeden duży plik.

• Nie leniwości ładuj bohatera. Rdzeń pominął leniwym ładowanie pierwszego obrazu zawartości i dodał fetchpriority="high" od WordPress 6.3, sprawdź, czy motyw lub wtyczka tego nie cofnęła.

• Daj każdemu obrazowi jawną szerokość i wysokość, aby przeglądarka zarezerwowała miejsce i przesunięcie układu pozostało bliskie zera.

Poniżej załamania strony leniwym ładowanie jest poprawne i bezpłatne. Powyżej załamania to samowolne opóźnienie i to błąd, który pojawia się najczęściej, gdy ktoś instaluje wtyczkę „leniwego ładowania wszystkiego".

Dla handlu elektronicznego waga często pochodzi z fotografii produktów. Tworzenie spójnych, prawidłowo ustalonych zdjęć u źródła jest tańsze niż kompresowanie pięćdziesięciu oversized plików później, a platforma fotografii produktów AI, taka jak Klayn, zamienia jedno zdjęcie produktu w zestaw scen, dzięki czemu możesz zaplanować wymiary przed czymkolwiek osiągnięciem biblioteki mediów.

Usuń CSS i JavaScript blokujące renderowanie u źródła

Po serwera i bohatera posortowaniu, następnym opóźnieniem jest to, co przeglądarka musi pobrać i uruchomić, zanim namaluje. Każdy arkusz stylów w główce blokuje renderowanie. Każdy skrypt synchroniczny blokuje analizowanie. Konstruktory stron i motywy wielofunkcyjne to zwykli winowajcy, ponieważ wysyłają style i skrypty dla każdej funkcji, niezależnie od tego, czy strona ich używa.

Motywy blokowe mają tutaj przewagę strukturalną. Rdzeń ładuje style dla bloku tylko wtedy, gdy ten blok pojawia się na stronie, więc zwykły wpis nie płaci za Loop Zapytania lub Galerię. To jeden powód, dla którego szczupły motyw Full Site Editing zaczyna do przodu od starego motywu z wbudowanym suwakiem i wbudowaną czcionką ikon. Klasyczne konstruktory stron mogą zamknąć lukę, ale tylko jeśli wyłączysz moduły, których nie używasz.

Divi to uczciwy przypadek testowy. Divi 5 zostało przebudowane na bardziej nowoczesną architekturę i wysyła setki modułów, co jest dokładnie powodem, dla którego jego ustawienia wydajności, takie jak dynamiczny CSS i krytyczny CSS, zasługują na uważne spojrzenie na każdej dostarczanej stronie.

Praktyczne kroki, w kolejności ryzyka:

• Odłóż niekrytyczne JavaScript i załaduj skrypty stron trzecich (widżety czatu, analityka, menedżery tagów) po interakcji, gdzie możesz.

• Wbuduj krytyczny CSS dla zawartości powyżej łamania i załaduj resztę asynchronicznie, jeśli Twoje narzędzie cache to obsługuje.

• Samodzielnie hostuj czcionki, podziel je na podzbiory i używaj font-display: swap, aby tekst był widoczny podczas ładowania czcionki.

• Usuń lub zastąp wtyczkę, która ładuje duży skrypt na każdej stronie dla funkcji używanej na jednej.

• Testuj po każdej zmianie. Agresywne odroczenie JavaScript to główny powód zepsutego menu lub martwego przycisku kasy.

Przytnij stos wtyczek i daj bazie danych oddychać

Liczba wtyczek to słaba metryka. To, co ma znaczenie, to to, co każda wtyczka ładuje na front-end i co robi przy każdym żądaniu. Jedna źle napisana wtyczka z ciężkim zapytaniem może kosztować więcej niż trzydzieści dobrze się zachowujących. Użyj Query Monitor na kopii przejściowej, aby zobaczyć wolne zapytania, wtyczkę, która je uruchomiła, i skrypty, które każda z nich umieszcza w kolejce.

Następnie spójrz na tabelę opcji. Wtyczki usunięte lata temu często pozostawiają za sobą wiersze oznaczone do automatycznego ładowania, co oznacza, że WordPress odczytuje je do pamięci przy każdym żądaniu. Site Health zaczyna flagować opcje autoloadowane, gdy osiągają około 800 KB. Jeśli widzisz to ostrzeżenie, sprawdź największe wiersze i wyczyść pozostałości z wtyczek, które już nie uruchamiasz.

Wersje wpisów, wygasłe transient i osierocone metadane dodają wagę na przestrzeni czasu, ale traktuj to jako konserwację, a nie jako główną naprawę. Najpierw utwórz kopię zapasową, uruchom czyszczenie na przejściu i zmierz ponownie. Wzrost jest często skromny na małej stronie i znaczący w sklepie mającym lata zamówień i sesji.

Użyj CDN i spekulacyjnego ładowania do ostatniego kroku

Sieć dostarczania treści serwuje pliki statyczne, a czasami także buforowany HTML, z lokalizacji blisko odwiedzającego. Dla odbiorcy rozłożonego na regiony, takiego jak strona w języku arabskim czytana ze Złotego Półwyspu i Afryki Północnej, podczas gdy serwer pochodzenia siedzi w Europie, oszczędzana latencja nie jest kosmetyczna. Odległość to koszt, a CDN to najtańszy sposób na jego skrócenie.

WordPress 6.8 dodał coś, co kosztuje nic: ładowanie spekulacyjne. Używa Speculation Rules API do prefetch strony, gdy odwiedzający zaczyna klikać, więc następna nawigacja czuje się niemal natychmiast. Zespół rdzenia raportuje, że witryny korzystające z wcześniejszej wersji wtyczki poprawiły współczynnik przejścia LCP o około 1,9% na medianie, zgodnie z opisem w nocie dewelopera spekulacyjnego ładowania WordPress 6.8. To jest małe na witrynę i nie wiąże się z żadną konfiguracją.

Rdzeń włącza go dla gości wylogowanych na witrynach z ładnymi stałymi linkami. Jeśli wtyczka używa adresów URL akcji, które zmieniają stan na zwykłym żądaniu GET, wyklucz te ścieżki za pomocą filtru wp_speculation_rules_href_exclude_paths, zanim ustawisz to bardziej chętnie. Zostań na domyślnym, aż sprawdzisz swoje koszyki i analitykę.

Kiedy przestać wyregulowywać i którą naprawę uruchomić pierwszą

Jest moment, w którym więcej strojenia WordPress kosztuje więcej niż zwraca. Jeśli mały sklep każdego miesiąca spędza walkę z wyłączeniami cache, konfliktami wtyczek i ulepszeniami hostingu, uczciwe pytanie brzmi, czy stos pasuje do biznesu. Platforma hostowana, taka jak WiziShop, wymienia elastyczność na sklep, którego szybkość jest czyjąś pracą, i warto wycenić to względem godzin, które rozliczasz za konserwację.

Dla witryn zawartości, agencji i projektów RTL WordPress pozostaje odpowiednim narzędziem, a wszystko powyżej pozostaje warte zrobienia. Chodzi o to, aby wiedzieć, po której stronie linii siedzi każdy klient.

Uruchom pomiar bazowy na najwolniejszym szablonie dzisiaj. Jeśli TTFB jest powyżej 800 milisekund, zacznij od hostingu, PHP i cache. Jeśli TTFB jest zdrowy, ale LCP zawodzi, otwórz kaskadę i znajdź obraz bohaterski. Jeśli oba przechodzą i interakcja jest powolna, spójrz na JavaScript i stos wtyczek. Która z tych trzech zawodzi najwolniejsza strona?