Strona przez chwilę pokazuje się bez stylów. Znalazłem przyczynę w hookach czyszczenia cache

👁 111 przeczytań

Na kilku podstronach przez moment widać było surowy HTML bez formatowania - nagłówki jeden pod drugim, linki na niebiesko, zero układu kolumn. Efekt pojawiał się tylko czasem i tylko dla części odwiedzających, więc długo nie dawał się złapać. Przyczyną okazał się hook wtyczki cache, który przy każdej publikacji czyścił całość razem z plikami CSS i JS.

Jak wyglądał objaw

Strona bez stylów to klasyczny FOUC, czyli flash of unstyled content. Zwykle tłumaczy się go asynchronicznym wczytywaniem czcionek albo krytycznym CSS wstrzykiwanym z opóźnieniem. Tutaj mechanizm był inny i prostszy: arkusz nie wczytywał się z opóźnieniem, tylko go nie było.

Dokument HTML serwowany z cache zawierał odwołanie do konkretnego zminifikowanego pliku ze znacznikiem w nazwie. Taki znacznik jest generowany w momencie tworzenia pliku i wpisywany na sztywno do HTML-a. Jeśli plik zostanie usunięty, a HTML pozostanie, odwołanie wisi w powietrzu. Serwer odpowiada czterysta czterech, przeglądarka wzrusza ramionami i rysuje treść bez żadnego formatowania.

Okno było wąskie - liczone w sekundach, czasem dziesiątkach sekund, zależnie od tego, kiedy ktoś wszedł i jak szybko odbudowała się minifikacja. Dlatego w testach ręcznych problem nie występował prawie nigdy. Odświeżało się stronę, wszystko działało, temat zamykano jako niereprodukowalny.

Skąd wzięło się kilkanaście czyszczeń na dobę

Wtyczka wołała przy każdej publikacji czyszczenie całości razem z plikami CSS i JS. Przy kilkunastu wpisach dziennie katalog był czyszczony kilkanaście razy na dobę. Każde takie czyszczenie to jedno potencjalne okno, w którym HTML wskazuje na nieistniejący arkusz.

Warto zwrócić uwagę na skalę: to nie jest awaria, która zdarza się raz w miesiącu przy aktualizacji motywu. To zdarzenie powtarzalne, wpisane w normalny rytm pracy redakcji. Im więcej publikujesz, tym częściej otwierasz okno. Serwis, który publikuje dwa teksty w tygodniu, praktycznie tego nie zauważy. Serwis newsowy z kilkunastoma wpisami dziennie będzie miał kilkanaście okien dziennie i regularne skargi czytelników, że wordpress wolno działa albo wygląda jak zepsuty.

Pełne czyszczenie kontra punktowa inwalidacja

Tabela poniżej pokazuje, co faktycznie zmieniło się w zachowaniu systemu po zmianie strategii. Zawiera wyłącznie te dane, które udało się jednoznacznie odczytać z konfiguracji i logów - bez szacunków i bez uśrednień, których nie mam czym poprzeć.

Kluczowa obserwacja jest logiczna, nie pomiarowa: nowy artykuł nie zmienia zawartości pliku CSS. Reguły stylów są takie same przed i po opublikowaniu tekstu. Nie ma więc technicznego uzasadnienia, żeby publikacja treści pociągała za sobą regenerację assetów.

Co powinno wywoływać pełne czyszczenie

To już moja opinia, oparta na tym jednym wdrożeniu, a nie twarda reguła. Pełne czyszczenie razem z CSS i JS zostawiłbym dla trzech sytuacji: zmiany w plikach motywu, aktualizacji lub zmiany konfiguracji wtyczek wpływających na front, oraz ręcznego kliknięcia przez administratora, który wie, co robi. Wszystko inne - nowy wpis, edycja starego, zmiana kategorii, nowy komentarz - powinno unieważniać wyłącznie adresy URL, których treść faktycznie się zmienia.

W praktyce lista adresów do unieważnienia przy publikacji jest krótka i przewidywalna. Sam wpis, bo dopiero się pojawił. Strona główna, bo wyświetla listę najnowszych. Listing kategorii, do których wpis należy. Kanał RSS, bo czytniki i agregatory zaciągają go niezależnie. Poza tym nic więcej nie zmienia zawartości.

Litespeed cache konfiguracja - na co patrzeć

Nazwa wtyczki jest tu drugorzędna, bo wzorzec powtarza się w wielu rozwiązaniach cache dla WordPressa. Szukaj w ustawieniach dwóch rzeczy, które często siedzą w osobnych zakładkach i nie są ze sobą wizualnie powiązane.

Pierwsza to reguły automatycznego czyszczenia przy publikacji - zwykle lista checkboxów z zakresami typu strona główna, archiwa, autor, tagi, wszystko. Druga to opcje minifikacji i łączenia CSS oraz JS, a przy nich osobny przełącznik odpowiadający za usuwanie wygenerowanych plików przy czyszczeniu cache. Problem powstaje dopiero wtedy, gdy oba zestawy ustawień są włączone jednocześnie i powiązane tym samym zdarzeniem.

Jeśli wtyczka pozwala rozdzielić te dwie warstwy - cache stron i cache assetów - rozdziel je. Jeśli nie pozwala, zostaje modyfikacja zachowania z poziomu kodu: podpięcie się pod hook publikacji, zastąpienie wywołania czyszczenia całości serią punktowych unieważnień. Rozwiązanie na poziomie ustawień jest lepsze, bo nie ginie przy aktualizacji wtyczki.

Jak to sprawdzić u siebie

1. Otwórz stronę główną w trybie incognito i podejrzyj źródło. Skopiuj pełny adres pliku CSS z sekcji head - tego zminifikowanego, ze znacznikiem w nazwie.
2. Wklej ten adres do drugiej karty i upewnij się, że plik się otwiera i zwraca treść, a nie błąd.
3. W panelu opublikuj testowy wpis. Nie edytuj motywu, nie zmieniaj żadnych ustawień - tylko publikacja treści.
4. Natychmiast po publikacji odśwież kartę z adresem pliku CSS. Jeśli dostajesz czterysta czterery, masz potwierdzenie: publikacja treści usuwa assety.
5. W tym samym momencie otwórz stronę główną w trzeciej karcie. Jeśli zobaczysz surowy HTML bez formatowania, widzisz dokładnie to, co widzą czytelnicy.
6. Sprawdź, czy adres pliku CSS w źródle nowo wygenerowanej strony jest już inny niż ten skopiowany w kroku pierwszym. Zmiana znacznika potwierdza regenerację.
7. Wejdź w ustawienia wtyczki i odszukaj regułę czyszczenia przy publikacji. Ogranicz ją do wpisu, strony głównej, kategorii i kanału RSS.
8. Odszukaj osobno opcję odpowiadającą za usuwanie zminifikowanych CSS i JS przy czyszczeniu cache i odwiąż ją od zdarzenia publikacji.
9. Powtórz kroki od pierwszego do piątego. Plik CSS powinien przetrwać publikację ze tym samym znacznikiem w nazwie.
10. Obserwuj przez kilka dni normalnej pracy redakcji. Przy kilkunastu wpisach dziennie efekt albo wróci szybko, albo nie wróci wcale - trzeciej opcji nie ma.