Włączyłeś optymalizację szybkości i przestał działać przycisk. Dlaczego automaty psują strony

Wtyczka do przyspieszania strony nie wie, który skrypt obsługuje kasę, a który animuje ikonkę. Traktuje oba tak samo. Dlatego po włączeniu opcji, którą narzędzie samo rekomenduje jako poprawę wydajności, potrafi przestać działać przycisk „dodaj do koszyka”, formularz kontaktowy albo wyszukiwarka produktów. Strona nadal się ładuje, wygląda dobrze i ma lepszy wynik w PageSpeed. Po prostu nie da się na niej kupić.

Ten tekst pokazuje, dlaczego tak się dzieje, jak w pięć minut sprawdzić, czy to twój przypadek, i co zrobić zamiast odinstalowywania wtyczek po kolei.

Najkrótsza możliwa odpowiedź

Jeśli po zmianie ustawień wydajności przestała działać jakaś akcja na stronie, w dziewięciu przypadkach na dziesięć winna jest kolejność ładowania skryptów, a nie wtyczka, która zgłosiła błąd.

Otwórz stronę, wciśnij F12, przejdź do zakładki Konsola i przeładuj stronę. Jeśli widzisz czerwone komunikaty zawierające is not defined albo is not a function, masz potwierdzenie. Wtedy wyłącz w ustawieniach wydajności opcję odraczania lub opóźniania JavaScriptu, wyczyść cache i sprawdź ponownie.

Nazwa opcji zależy od narzędzia. Szukaj sformułowań w rodzaju „odroczenie skryptów blokujących renderowanie”, „defer JavaScript”, „opóźnij wykonanie JS”, „delay JavaScript execution” albo „łącz pliki JavaScript”.

Awaria, która nie wygląda na awarię

Zwykła awaria strony jest łaskawa. Strona nie działa, wszyscy to widzą, ktoś dzwoni, problem zostaje naprawiony w godzinę.

Ta jest inna i dlatego droższa. Strona się ładuje. Zdjęcia są na miejscu, menu działa, teksty są czytelne. Monitoring dostępności pokazuje zielone światło, bo serwer grzecznie odpowiada kodem 200. Wynik w PageSpeed poszedł w górę, więc zmiana wygląda na sukces. A klient, który chciał kupić, klika w przycisk i nic się nie dzieje. Klika drugi raz, czeka, wychodzi.

Nikt nie dostaje alertu, bo z punktu widzenia każdego automatu nic się nie stało. Właściciel dowiaduje się z przypadkowego pytania klienta po tygodniu albo nie dowiaduje się wcale i widzi tylko słabszy miesiąc, który przypisuje sezonowi.

To jest najdroższy rodzaj awarii, jaki może spotkać sklep: taki, który nie zgłasza się sam.

Dlaczego automat nie może tego wiedzieć

Narzędzie do optymalizacji widzi listę plików i czas ich wczytywania. Nie widzi twojego biznesu.

Dla niego skrypt obsługujący płatność i skrypt animujący ikonę serduszka to dwa wpisy na tej samej liście. Oba blokują renderowanie, oba warto odroczyć, oba dostają tę samą obróbkę. Narzędzie nie ma pojęcia, że jeden z nich odpowiada za dziewięćdziesiąt procent twoich przychodów.

Do tego dochodzi druga rzecz, o której mało kto mówi: te opcje są rekomendowane. Panel pokazuje je jako zalecane usprawnienie, często z ładnym zielonym znacznikiem i szacowanym zyskiem czasu. Człowiek, który je włącza, nie robi nic głupiego ani nieostrożnego. Robi dokładnie to, co podpowiada narzędzie. I to jest sedno problemu: rekomendacja jest ogólna, a strona jest konkretna.

Producenci zresztą o tym wiedzą. Każde poważne narzędzie tego typu ma listę wykluczeń, czyli miejsce, gdzie wpisuje się skrypty, których ruszać nie wolno. Tyle że lista wykluczeń jest pusta na starcie i nikt nie mówi ci, co masz do niej wpisać, dopóki coś nie padnie.

Co się dzieje pod spodem

Ta sekcja jest techniczna. Jeśli nie interesuje cię mechanizm, przeskocz do części o teście w pięć minut, nic nie stracisz.

WordPress ładuje skrypty parami. Najpierw plik, zaraz po nim krótki dopisek wpisany wprost w kod strony, który ten plik konfiguruje: ustawia język, strefę czasową, adres, pod który mają iść zapytania. Plik i dopisek to jedna całość i kolejność między nimi nie podlega negocjacji.

Optymalizator wchodzi w tę parę i rozbija ją na dwa sposoby.

Po pierwsze, odracza plik, ale nie dopisek. Atrybut defer działa wyłącznie na skryptach wczytywanych z osobnego pliku. Na kodzie wpisanym bezpośrednio w stronę jest ignorowany, co opisuje dokumentacja MDN. Narzędzie może więc dokleić ten atrybut wszędzie, ale przeglądarka posłucha go tylko w połowie przypadków. Efekt: plik czeka na koniec wczytywania strony, a dopisek wykonuje się natychmiast i szuka czegoś, czego jeszcze nie ma. W konsoli pojawia się is not defined.

Po drugie, dzieli zależności na dwie grupy. Skrypt A potrzebuje skryptu B, żeby zadziałać. Optymalizator obrabia B, ale A zostawia nietknięte, bo na przykład wcześniej go zminifikował, a tamtego nie. Teraz A startuje pierwsze i pyta o funkcję, której B jeszcze nie zdążył udostępnić. W konsoli pojawia się is not a function.

I trzecia rzecz, najważniejsza praktycznie: błąd zgłasza ostatnie ogniwo łańcucha, nie sprawca. Jeśli pięć skryptów zależy od siebie po kolei, a rozjazd nastąpił na drugim, w konsoli najgłośniej krzyczy piąty. Zwykle jest nim jakaś wtyczka z nazwą producenta w pliku. Właściciel strony widzi tę nazwę, uznaje ją za winowajcę i odinstalowuje działającą wtyczkę, która była ofiarą.

To jest dokładnie ten moment, w którym popularna rada „wyłączaj wtyczki po kolei, aż znajdziesz konflikt” prowadzi w złą stronę. Nie ma tam konfliktu wtyczek. Jest jedna zmiana w ustawieniach wydajności, która przestawiła kolejność wszystkim naraz.

Przypadek z naszej pracy

Sklep na WooCommerce, branża wykończeniowa, rynek amerykański. Przestał działać przycisk dodawania produktu do listy życzeń. Nic poza tym: strona ładowała się szybko, koszyk działał, płatności działały.

W konsoli było pięć różnych czerwonych komunikatów, pochodzących z pięciu różnych miejsc. Ostatni z nich wskazywał na wtyczkę obsługującą listy życzeń i to ona wyglądała na winną.

Nie była. Po wypisaniu wszystkich skryptów strony w kolejności ładowania obraz zrobił się jednoznaczny: czterdzieści sześć z sześćdziesięciu plików było odroczonych, czternaście nie. Do tego sześć dopisków konfiguracyjnych miało doklejony atrybut odraczający, który przeglądarka i tak ignoruje. Cała piątka błędów miała jedną przyczynę: rozjechaną kolejność. Wtyczka od list życzeń była na końcu łańcucha i zgłosiła cudzy problem.

Sygnatura sprawcy była widoczna w adresach plików. Te, które optymalizator przerobił, miały w adresie inny zapis wersji niż te, których nie tknął, a odroczenie dostały dokładnie te pierwsze. Zero wyjątków w obie strony, więc nie było już czego zgadywać.

Naprawa polegała na wyłączeniu jednej opcji i wyczyszczeniu cache. Cała diagnoza zajęła kilkanaście minut, ale dopiero po tym, jak przestaliśmy patrzeć na wtyczkę, która zgłaszała błąd.

Test w pięć minut, bez wiedzy technicznej

1. Otwórz stronę, na której coś nie działa, w oknie prywatnym.
2. Wciśnij F12 i wybierz zakładkę Konsola. Na Macu w Chrome i Safari zadziała też skrót Cmd, Option i J.
3. Przeładuj stronę i popatrz na czerwone komunikaty. Zignoruj żółte ostrzeżenia, one są prawie zawsze i prawie nigdy nic nie znaczą.
4. Kliknij w zepsuty element i sprawdź, czy w konsoli pojawia się nowy błąd.

Co zobaczysz i co to znaczy:

Komunikat w konsoli	Co się dzieje	Gdzie szukać
is not defined	skrypt szuka czegoś, co jeszcze się nie wczytało	odraczanie i opóźnianie JavaScriptu
is not a function	zależności wykonały się w złej kolejności	odraczanie, łączenie plików
Failed to load resource z kodem 404	plik w ogóle nie istnieje pod tym adresem	łączenie i minifikacja, czyszczenie cache
Unexpected token	plik został uszkodzony przy przetwarzaniu	minifikacja albo łączenie
pusta konsola, a element i tak nie działa	to prawdopodobnie nie jest ten problem	cache stron, ciasteczka, sesja

Ostatni wiersz jest ważny. Jeśli konsola milczy, a funkcja nadal nie działa, przestań szukać w skryptach. Wtedy podejrzanym numer jeden jest cache serwujący tę samą kopię strony wszystkim odwiedzającym, co na sklepie objawia się pustym albo cudzym koszykiem.

Dlaczego problem czasem wychodzi po miesiącach

Bywa, że ustawienie zostało włączone dawno, wszystko działało, a awaria pojawiła się nagle po zupełnie innej zmianie. To nie jest przypadek.

Na jednej stronie potrafią pracować równolegle dwie albo trzy warstwy optymalizacji: wtyczka w WordPressie, mechanizm po stronie hostingu i jeszcze coś na poziomie usługi sieciowej przed stroną. Każda z nich przestawia kolejność skryptów po swojemu. Kiedy działają razem, jedna potrafi przykryć skutki drugiej: narzuca własną kolejność i przypadkiem naprawia to, co tamta zepsuła.

Wyłączenie tej wierzchniej warstwy, choćby z całkowicie słusznego powodu, odsłania problem, który siedział pod spodem od miesięcy. Wygląda to wtedy tak, jakby awarię spowodowała ostatnia zmiana, a ona ją tylko ujawniła.

Praktyczny wniosek jest prosty: po każdym wyłączeniu czegokolwiek z warstwy wydajności przejdź funkcje strony, nie tylko sprawdź, czy się ładuje. Zmiana, która niczego nie psuje, może odkryć coś, co było zepsute wcześniej.

Które opcje niosą jakie ryzyko

Nie wszystkie ustawienia wydajności są równie niebezpieczne. Poniższa tabela porządkuje te, które spotykamy najczęściej. Nazwy różnią się między narzędziami, ale mechanizm jest ten sam w WP Rocket, LiteSpeed Cache, Perfmatters, Autoptimize, FlyingPress i wtyczkach dostarczanych przez hostingi.

Opcja	Co robi	Ryzyko	Co przetestować po włączeniu
Kompresja i cache przeglądarki	wysyła pliki mniejsze i każe je zapamiętać	niskie	nic szczególnego
Minifikacja CSS i JS	usuwa spacje i skraca zapisy	niskie	wygląd strony, ikony, czcionki
Lazy load obrazków	wczytuje zdjęcia dopiero przy przewijaniu	niskie	slidery, galerie, zdjęcia w pierwszym ekranie
Usuwanie nieużywanego CSS	wycina reguły uznane za zbędne	średnie	rzadkie widoki: kasa, konto, potwierdzenie zamówienia
Łączenie plików JS	scala wiele plików w jeden	wysokie	wszystkie akcje dynamiczne
Opóźnianie JS do interakcji	czeka z wykonaniem na ruch myszy	wysokie	czaty, mapy, liczniki, popupy, płatności
Odraczanie JS blokującego renderowanie	przesuwa wykonanie na koniec wczytywania	najwyższe	koszyk, formularze, wyszukiwarka, wszystko klikalne
Cache stron na sklepie	serwuje gotową kopię strony	wysokie	koszyk i konto u zalogowanego, nie tylko u gościa

Reguła, która wynika z tej tabeli: im wyżej w tabeli, tym spokojniej możesz włączać. Dwie ostatnie pozycje na sklepie z ruchem zawsze wymagają testu, nigdy nie są ustawieniem „włącz i zapomnij”.

Co robić zamiast wyłączania wtyczek po kolei

Metoda „dezaktywuj wszystkie wtyczki i włączaj je jedna po drugiej” jest sensowna przy prawdziwym konflikcie wtyczek. Przy rozjechanej kolejności skryptów jest gorsza niż bezużyteczna, bo prowadzi do fałszywego winowajcy i przy czterdziestu wtyczkach zajmuje pół dnia.

Kolejność, która działa szybciej:

1. Sprawdź, czy zmiana w wydajności poprzedza awarię. Jeśli tak, masz podejrzanego bez żadnego testu.
2. Wyłącz jedną opcję, tę najbardziej ryzykowną z tabeli wyżej, wyczyść cache wtyczki i cache usługi przed stroną, sprawdź ponownie. Zawsze jedna zmiana naraz.
3. Dopiero gdy to nie pomoże, wracaj do wtyczek. I zacznij od tych dodanych ostatnio, a nie od tej, której nazwa pojawiła się w konsoli.
4. Zanotuj datę i treść każdej zmiany. Przy trzeciej rundzie nikt już nie pamięta, co było włączone na starcie, i to jest moment, w którym drobna awaria zamienia się w wieczór pracy.

Jeśli chcesz wrócić do wyłączonej opcji, bo zależy ci na wyniku wydajności, zrób to przez listę wykluczeń, a nie przez ponowne włączenie wszystkiego. I przetestuj na kopii strony, nie na sklepie, który w tym czasie sprzedaje.

Jak my z tym pracujemy

Zaczynamy od pomiaru, nie od włączania opcji. Na wejściu PageSpeed Insights, bo jest najprostszy i każdy klient go zna. Do konkretnych optymalizacji WebPageTest i Query Monitor, bo pokazują, co dzieje się w środku, a nie sam wynik punktowy.

Kolejność prac jest u nas zawsze taka sama i idzie od najtańszego i najbezpieczniejszego do najbardziej ryzykownego. Najpierw podstawy: grafiki, fonty, cache obiektowy i cache przeglądarki, minifikacja CSS, JS i HTML, do tego usuwanie zbędnych skryptów na różnych typach stron, żeby nie ładować wszędzie tego, co potrzebne jest w jednym miejscu. Dopiero potem wchodzimy w optymalizację ładowania skryptów, czyli w to, co opisuje ten wpis. CDN i płatne usługi zostawiamy na koniec, w ostateczności.

Na blogu i wizytówce podstawy zwykle wystarczają do płynnego działania. Wyjątkiem są duże błędy w budowie, na przykład kilka builderów naraz i wtyczki ładujące zewnętrzne skrypty; wtedy zamiast optymalizacji potrzebna jest przebudowa. Na sklepie przebudowa bywa bardzo kosztowna, więc robimy podstawy i uruchamiamy cache dynamiczny, jeśli serwer na to pozwala. Bardzo często największy skok szybkości daje zmiana serwera, a jest to jedno z najtańszych możliwych działań.

W samym WooCommerce problem zwykle nie leży tam, gdzie wskazują narzędzia: siedzi na stronach koszyka i zamówienia oraz w szybkości dodawania do koszyka. Dlatego szukamy tam wolnych zapytań do bazy, bo to one najczęściej są przyczyną, a dopiero potem nadmiarowych skryptów i styli, które się ładują, choć nikt ich nie używa.

Po każdej zmianie klikamy ręcznie kluczowe akcje: dodanie do koszyka, dodanie do listy życzeń, otwarcie koszyka, usunięcie produktu z koszyka, wysłanie formularza wraz ze sprawdzeniem, czy dane doszły na zaplecze, przetworzenie zamówienia, popupy oraz wszystkie rozwiązania zbudowane pod konkretnego klienta. Każdą z tych akcji w trzech stanach: zalogowany, niezalogowany i w oknie prywatnym. Różnica między tymi stanami to najczęstsze miejsce, w którym awaria się chowa.

Kiedy nasze podejście nie jest dla ciebie: gdy problemem jest serwer albo sposób zbudowania strony, CDN niczego nie naprawi. W takiej sytuacji maskuje problem, zamiast go rozwiązywać, więc zapłacisz za usługę i dostaniesz ładniejszy wykres zamiast szybszej strony. Najpierw hosting i budowa strony, dopiero potem warstwy nad nimi.

Podsumowanie

Narzędzia do optymalizacji nie są złe i nie chodzi o to, żeby ich nie używać. Chodzi o to, że automat nie ma pojęcia, co na twojej stronie jest ważne, a rekomendacja, którą wyświetla, jest napisana dla strony przeciętnej.

Trzy rzeczy do zapamiętania:

1. Ta awaria nie zgłasza się sama. Strona się ładuje, monitoring milczy, a funkcja nie działa. Dlatego test po zmianie robi się ręcznie, klikając.
2. Wtyczka, która zgłasza błąd w konsoli, to zwykle ofiara, a nie sprawca. Zanim ją odinstalujesz, wyłącz ostatnią zmianę w ustawieniach wydajności.
3. Jedna zmiana naraz, z zapisaną datą. To jedyny sposób, żeby przy trzeciej rundzie wiedzieć, co właściwie się dzieje.

Jeśli chcesz zrozumieć drugą stronę tego problemu, czyli sytuację, w której optymalizacja jest włączona i po prostu nie pomaga, opisaliśmy dlaczego strona bywa wolna mimo wtyczki cache. Gdy błąd nie jest widoczny w przeglądarce, zostaje czytanie logów błędów po stronie serwera.

Nie wiesz, czy twoja strona ma ten problem?

Sprawdzenie zajmuje kilka minut i nie wymaga żadnych zmian na stronie. Jeśli wolisz, żeby ktoś przeszedł przez to za ciebie, zrób audyt strony albo po prostu napisz do nas. Prowadzimy sklepy na WooCommerce i w ramach opieki nad stroną takie rzeczy wychodzą, zanim zauważy je klient.

FAQ

Czy to znaczy, że nie powinienem w ogóle optymalizować strony?

Nie. Znaczy tyle, że optymalizacja ma kolejność i że po każdej zmianie trzeba sprawdzić funkcje, a nie tylko wynik punktowy. Podstawy z pierwszej połowy tabeli ryzyka są bezpieczne i dają większość zysku.

Dlaczego narzędzie rekomenduje opcję, która potrafi zepsuć stronę?

Bo rekomendacja jest ogólna i dotyczy typowej strony, a nie twojej. Narzędzie mierzy czas ładowania, nie sprawdza, czy da się złożyć zamówienie. To ograniczenie każdego automatu tego typu, nie wada jednej marki.

Skąd mam wiedzieć, którą opcję wyłączyć, skoro nazywają się inaczej w każdej wtyczce?

Szukaj słów „defer”, „delay”, „odrocz”, „opóźnij”, „połącz” albo „combine” w sekcji dotyczącej JavaScriptu. To są cztery mechanizmy, które odpowiadają za zdecydowaną większość takich awarii.

Wyłączyłem opcję, a błąd nadal jest.

Wyczyść cache w dwóch miejscach: we wtyczce i w usłudze, która stoi przed stroną, jeśli taką masz. Do tego sprawdź w oknie prywatnym, bo twoja przeglądarka może trzymać starą wersję plików. Jeśli po tym błąd zostaje, prawdopodobnie masz drugą warstwę optymalizacji, o której nie wiesz.

Czy stracę pozycje w Google, jeśli wyłączę odraczanie skryptów?

Szybkość jest jednym z wielu sygnałów i różnica kilku punktów w PageSpeed nie przekłada się wprost na pozycje. Niedziałający przycisk zakupu przekłada się wprost na przychód. Przy takim wyborze decyzja jest prosta.

Mam wizytówkę bez sklepu. Czy mnie to dotyczy?

W mniejszym stopniu, ale tak. Najczęstsze ofiary na stronach bez sklepu to formularz kontaktowy, menu mobilne, popup z zapisem na newsletter i mapa dojazdu. Warto je kliknąć po każdej zmianie ustawień.

Czy da się to wykryć automatycznie, żeby nie sprawdzać ręcznie?

Da się monitorować konkretne ścieżki, na przykład dodanie produktu do koszyka, ale to już nie jest zwykły monitoring dostępności, tylko test scenariusza. Zwykłe sprawdzanie, czy strona odpowiada, tej awarii nie wykryje nigdy.

—