Strony internetowe często przyspiesza się w niewłaściwej kolejności: ktoś instaluje wtyczkę optymalizacyjną, włącza każdą opcję, a potem szuka przyczyny, dla której formularz przestał działać. Właściwa kolejność to pomiar, hipoteza, jedna zmiana, sprawdzenie działania i ponowny pomiar.
W starszej wersji opisywałem również podejścia, których już nie polecam, takie jak lokalne proxy’owanie cudzych skryptów czy ogólne wdrażanie AMP i PWA. Przynosiły częściową poprawę w testach laboratoryjnych, ale zwiększały ryzyko pojawienia się przestarzałego kodu, problemów z aktualizacjami i bardziej skomplikowanego utrzymania. Nowoczesna strona powinna być szybka w swojej głównej wersji.
Co mierzyć dzisiaj
W przypadku Core Web Vitals Google wykorzystuje trzy stabilne metryki:
- LCP: ładowanie głównej treści; dobra wartość wynosi maksymalnie 2.5 sekundy.
- INP: reakcja na interakcje; dobra wartość wynosi poniżej 200 milisekund.
- CLS: nieoczekiwane przesunięcia układu; dobra wartość wynosi najwyżej 0.1.
Progi dotyczą 75. percentyla i zostały podsumowane w oficjalnym przeglądzie Core Web Vitals dla wyszukiwarki Google. Wyniki od rzeczywistych użytkowników w Search Console lub CrUX mają pierwszeństwo przed jednym testem laboratoryjnym na moim laptopie.
Narzędzia laboratoryjne nadal mają znaczenie: pokazują wodospad, główny wątek, nieużywany kod i konkretne możliwości naprawy. Dane terenowe mówią, że problem istnieje; laboratorium pomaga wyjaśnić dlaczego.
Najpierw określ zakres problemu
- Porównaj urządzenia mobilne i komputery.
- Rozdziel szablony: stronę główną, artykuł, usługę, listę, formularz i sklep internetowy.
- Sprawdź szybkie i wolne kraje, urządzenia oraz źródła ruchu.
- Znajdź grupy adresów URL ze słabymi danymi terenowymi.
- Zarejestruj powtarzalny ślad laboratoryjny dla reprezentatywnej strony.
Jedna szybka strona główna nie oznacza szybkiej witryny. Jedna powolna wizyta na starym telefonie nie oznacza, że cały system trzeba napisać od nowa.
Działania o najczęstszym wpływie
1. Serwer i HTML
Zmierz czas do pierwszego bajtu i podziel go na DNS, połączenie, oczekiwanie na serwer oraz przekierowania. Długie oczekiwanie może wynikać z hostingu, bazy danych, strony bez pamięci podręcznej, wolnego API lub łańcuchów przekierowań. Włącz odpowiednią pamięć podręczną stron dla publicznych treści oraz pamięć obiektów tam, gdzie ma to sens. Prawidłowo wyłącz z pamięci podręcznej zalogowanych użytkowników, koszyki i personalizację.
2. Główny obraz
LCP często dotyczy głównego obrazu. Dostarcz jego rozmiar dopasowany do wyświetlania, użyj srcset, kompresji oraz nowoczesnego formatu WebP lub AVIF z rozsądnym rozwiązaniem awaryjnym. Nie wczytuj głównego obrazu leniwie; obrazy poniżej pierwszego widoku wczytuj leniwie. Ustaw szerokość i wysokość obrazu, aby przeglądarka zarezerwowała miejsce, a CLS pozostał niski.
3. CSS i fonty
Ostrożnie usuń nieużywane style i utrzymuj niewielki krytyczny CSS. Ogranicz fonty do wymaganych grubości i zestawów znaków, długo przechowuj lokalne pliki w pamięci podręcznej i wstępnie wczytuj tylko font, który rzeczywiście jest potrzebny wcześnie. Wstępne wczytanie dziesięciu fontów tworzy jedynie kolejną kolejkę.
4. JavaScript i interakcje
Podziel duże pakiety, odrocz niekrytyczny kod i wczytuj zewnętrzne skrypty tylko wtedy, gdy są potrzebne i pozwala na to zgoda. async i defer nie są magią; przetestuj kolejność skryptów i zależności. Podziel długie zadania głównego wątku i nie każ czekać na analitykę po kliknięciu.
5. Skrypty zewnętrzne
Czaty, mapy cieplne, piksele reklamowe, filmy i narzędzia A/B dodają żądania sieciowe oraz obciążenie procesora. Każdy skrypt potrzebuje właściciela i biznesowego uzasadnienia. Nie wczytuj go synchronicznie w nagłówku tylko dlatego, że instrukcja instalacji jest najkrótsza. Analitykę można obsługiwać przez Google Tag Manager, ale sam kontener nie uratuje wydajności.
WordPress: mniej warstw, większa kontrola
Dokumentacja WordPressa zaleca poprawę wydajności poprzez hosting, liczbę i jakość wtyczek, obrazy, pamięć podręczną oraz sieć dostarczania treści. Przeczytaj przegląd optymalizacji oraz osobne wyjaśnienie dotyczące pamięci podręcznej.
- Najpierw zaktualizuj na środowisku testowym WordPressa, PHP, motyw i wtyczki.
- Usuń nieużywane wtyczki oraz nakładające się narzędzia pamięci podręcznej lub minifikacji.
- Przeanalizuj zapytania do bazy danych i wolne wywołania zewnętrzne.
- Zaplanuj konserwację bazy danych, ale nie usuwaj bezmyślnie rewizji ani metadanych.
- Po każdej optymalizacji przetestuj formularze, wyszukiwanie, logowanie i proces zakupu.
Rozmawiam o rozsądnym wyborze dodatków w artykule najlepsze wtyczki do WordPressa.
Czego nie robić
- Nie pobieraj cudzych skryptów analitycznych ani reklamowych na swój serwer tylko dla lepszego wyniku; możesz stracić aktualizacje bezpieczeństwa i funkcjonalności.
- Nie ustawiaj rocznej pamięci podręcznej dla zmieniającego się pliku bez wersjonowania jego nazwy.
- Nie usuwaj CSS ani JavaScriptu z automatycznego raportu bez przetestowania każdego szablonu.
- Nie oceniaj sukcesu wyłącznie na podstawie Lighthouse. Google wyraźnie mówi, że dobre Core Web Vitals same w sobie nie gwarantują wysokich pozycji ani świetnego doświadczenia użytkownika.
- Nie przyspieszaj strony przez ukrywanie treści lub funkcji potrzebnej klientowi.
Plan na cztery tygodnie
- Tydzień 1: punkt odniesienia z danych terenowych, pomiary laboratoryjne i lista szablonów.
- Tydzień 2: serwer, pamięć podręczna, przekierowania i największe zasoby LCP.
- Tydzień 3: obrazy, fonty, CSS, JavaScript i skrypty zewnętrzne.
- Tydzień 4: test regresji, nowe pomiary, monitorowanie i dokumentacja.
Dla każdej zmiany zapisz datę, adres URL, metrykę przed i po, wpływ na funkcjonalność oraz możliwość wycofania. Śledź także współczynnik konwersji, ukończenie formularzy i błędy; szybsza strona, która sprzedaje mniej, nie oznacza zakończonej optymalizacji.
Zacznij od sprawdzenia technicznych podstaw strony i analityki w audyt techniczny oraz GA4. Jeśli potrzebujesz ustalić priorytety napraw według wpływu i kosztu, skontaktuj się ze mną przez kontakt.