Optymalizacja wydajności przez functions.php: selektywne usuwanie skryptów wtyczek WordPressa z kolejki

Usuwanie zbędnych plików bez utraty funkcji strony

Niektóre wtyczki WordPressa ładują CSS lub JavaScript także na stronach bez odpowiedniej funkcji. Takie pliki mogą zwiększać transfer, obciążenie procesora lub czas blokowania renderowania. Rzeczywisty wpływ zależy od zasobów i pamięci podręcznej przeglądarki. Duży skrypt nie oznacza automatycznie dużego drzewa DOM ani złego wyniku INP. Drzewo DOM to uporządkowany zapis elementów strony w przeglądarce, na przykład nagłówków, linków i pól formularza.

Selektywne usuwanie z kolejki, czyli dequeuing, usuwa wskazany zasób z kolejki ładowania dla bieżącego żądania. Identyfikator zasobu, nazywany uchwytem lub handle, pochodzi z kodu rejestrującego. Istotny jest nie tylko typ podstrony, lecz zapotrzebowanie wszystkich funkcji na całej wyrenderowanej stronie.

1. Inwentaryzacja plików i zależności

Środowisko testowe powinno odzwierciedlać istotne motywy, wtyczki i szablony produkcji. Karty Network i Console przeglądarki pokazują żądane pliki oraz widoczne błędy funkcji. Kod wtyczki i rejestracje WordPressa pozwalają przypisać adresy plików do uchwytów oraz zależności. Uchwyt nie musi odpowiadać nazwie pliku.

Kolejki WP_Scripts i WP_Styles dostarczają przydatnych migawek diagnostycznych. Zrzut kolejki nie jest pełnym spisem dostarczonych zasobów: zależności mogą zostać rozwiązane później, a renderowanie stopki lub bloków może dodać kolejne pliki. Osobnego uwzględnienia wymagają zasoby już wypisane. Moduły skryptów korzystają ponadto z oddzielnego API. Tymczasowe logi diagnostyczne powinny być dostępne wyłącznie w ograniczonym środowisku testowym i usunięte po audycie.

2. Dequeue i deregister to różne operacje

• wp_dequeue_script() oraz wp_dequeue_style() usuwają bezpośredni wpis z kolejki. Rejestracja pozostaje dostępna.
• wp_deregister_script() oraz wp_deregister_style() usuwają rejestrację. Potrzebne zasoby zależne mogą następnie nie zostać załadowane albo przestać działać poprawnie.

Jeżeli plik pozostaje zarejestrowaną zależnością innego zasobu w kolejce, samo usunięcie tej zależności z kolejki może nie zapobiec ładowaniu. To powód do zbadania drzewa zależności, a nie do wymuszania blokady przez wyrejestrowanie. Frontend nie zapewnia ogólnej ochrony przed uszkodzeniem funkcji wskutek wyrejestrowania.

Priorytet 100 oznacza wykonanie po niższych priorytetach tego samego haka. Późniejszy callback lub inny hak nadal może dodać plik. Usunięcie z kolejki po wypisaniu znacznika HTML nie cofa ładowania w przeglądarce. Odpowiedni moment wynika z rzeczywistej kolejności dodawania i wypisywania zasobów.

3. Przykład z celowo ograniczonym zakresem

Poniższy przykład nadaje się do functions.php motywu potomnego lub niewielkiej wtyczki przeznaczonej dla danej witryny. Aktualizacja motywu nadrzędnego może nadpisać zmiany wprowadzone bezpośrednio w tym motywie. Kod dotyczy wyłącznie jawnie sprawdzonych pojedynczych stron lub wpisów. Początkowo pusta lista niczego nie zmienia. Wtyczka MU wymaga standardowego pliku PHP i świadomego utrzymania.

add_action( 'wp_enqueue_scripts', function () {
    if ( is_admin() || ! is_singular() ) {
        return;
    }

    // Empty by default. Each entry requires a complete page audit.
    // Structure: post ID => scripts and styles proven unnecessary.
    $audited_pages = array();
    $post_id = (int) get_queried_object_id();
    if ( ! isset( $audited_pages[ $post_id ] ) ) {
        return;
    }

    $assets = $audited_pages[ $post_id ];
    foreach ( $assets['scripts'] ?? array() as $handle ) {
        wp_dequeue_script( $handle );
    }
    foreach ( $assets['styles'] ?? array() as $handle ) {
        wp_dequeue_style( $handle );
    }
}, 100 );

Po pełnym audycie wpis może mieć postać 123 => array( 'scripts' => array( 'contact-form-7' ), 'styles' => array( 'contact-form-7' ) ). Liczba jest przykładowym identyfikatorem wpisu, nie zaleceniem dla rzeczywistej instalacji. Taka reguła jest uzasadniona tylko wtedy, gdy cała wyrenderowana strona nie zawiera formularza ani pozostałej zależności od tych uchwytów. Każde tłumaczenie wymaga osobnego, sprawdzonego ID. Strony archiwów pozostają bez zmian.

Przykład zachowuje rejestracje. Kod nie analizuje automatycznie szablonów ani wszystkich zależności, nie usuwa modułów skryptów i nie blokuje późniejszego dodawania do kolejki. Te ograniczenia wymagają kontroli źródeł i przeglądarki. Przykład nie zawiera zbiorczej blokady zasobów WooCommerce.

4. Dlaczego sam typ podstrony nie wystarcza

Mini-koszyk w nagłówku, blok produktu w artykule lub funkcja konta może wymagać zasobów sklepu poza głównymi stronami sklepu, koszyka i zamówienia. WooCommerce zmienił domyślne ładowanie Cart Fragments już w wersji 7.8. Klasyczny widżet koszyka, zależności albo jawne wywołania enqueue nadal mogą zażądać tego skryptu. Twierdzenie, że każda wtyczka zawsze ładuje wszystkie pliki wszędzie, jest nieprawdziwe.

Formularze mogą występować w stopce, widżecie, szablonie, treści wielokrotnego użytku lub tłumaczeniu strony. Warunek obejmujący tylko slugi contact i support pomija takie lokalizacje. Wyszukiwanie shortcode wyłącznie w treści bieżącego wpisu również nie obejmuje treści dodanej gdzie indziej. Contact Form 7 dokumentuje własne mechanizmy sterowania ładowaniem oraz funkcje enqueue. Także ten wariant wymaga kompletnej listy lokalizacji formularzy i właściwego momentu wywołania.

5. Testy funkcji przed wdrożeniem

1. Pomiar bazowy powinien dotyczyć tego samego adresu, rozmiaru okna, klasy urządzenia i warunków pamięci podręcznej.
2. W środowisku testowym należy aktywować jedną sprawdzoną regułę oraz potwierdzić brak zamierzonych plików i zachowanie potrzebnych zależności.
3. Test powinien objąć formularze, walidację, nawigację, konto, dodawanie do koszyka, mini-koszyk i zamówienie odpowiednio do funkcji witryny, we wszystkich językach i układach mobilnych. Wygląd i obsługa klawiaturą wymagają sprawdzenia niezależnie od błędów konsoli.
4. Potrzebne są próby dla sesji zalogowanych i niezalogowanych oraz istotnych wariantów cache. Wdrożenie wymaga możliwości wycofania zmiany i aktualizacji pamięci podręcznej. Krótka kontrola produkcyjna następuje dopiero po testach.

Liczba przesłanych bajtów, żądań i czasy wymagają pomiaru. Nie ma gwarancji określonej oszczędności, zniknięcia wszystkich ostrzeżeń o nieużywanym kodzie ani poprawy pozycji w wyszukiwarce. TBT opisuje blokującą pracę w teście laboratoryjnym; INP dotyczy reakcji na interakcje i wymaga odpowiednich testów interakcji lub danych terenowych. Niższy TBT nie dowodzi poprawy INP.