Performance-Optimierung via functions.php: Selektives Dequeuing von WordPress-Plugin-Skripten

Unnötige Dateien entfernen, Seitenfunktionen erhalten

Einige WordPress-Plugins laden CSS oder JavaScript auch auf Seiten ohne die zugehörige Funktion. Solche Dateien können zusätzliche Übertragung, Rechenarbeit oder blockierende Ladezeit verursachen. Der tatsächliche Effekt hängt von den Dateien und dem Browsercache ab. Eine große Skriptdatei bedeutet nicht automatisch einen großen DOM-Baum oder einen schlechten INP-Wert. Der DOM-Baum ist die strukturierte Darstellung der Seitenelemente im Browser, etwa Überschriften, Links und Formularfelder.

Selektives Dequeuing entfernt eine benannte Ressource für die aktuelle Anfrage aus der Lade-Warteschlange. Diese Kennung, der Handle, stammt aus dem registrierenden Code. Entscheidend ist nicht nur der Seitentyp, sondern der Bedarf aller Funktionen auf der vollständig dargestellten Seite.

1. Geladene Dateien und Abhängigkeiten erfassen

Eine Testumgebung sollte die relevanten Themes, Plugins und Vorlagen der Produktion abbilden. Die Browserreiter Network und Console zeigen angeforderte Dateien und erkennbare Funktionsfehler. Plugin-Quellcode und WordPress-Registrierungen ordnen Datei-URLs den Handles und Abhängigkeiten zu. Ein Handle ist eine Kennung und muss nicht dem Dateinamen entsprechen.

Die Warteschlangen von WP_Scripts und WP_Styles liefern hilfreiche Momentaufnahmen. Eine ausgegebene Queue ist jedoch kein vollständiges Verzeichnis aller ausgelieferten Ressourcen: Abhängigkeiten können später aufgelöst werden, Footer oder Blockdarstellung weitere Dateien vormerken. Bereits ausgegebene Ressourcen benötigen eine eigene Betrachtung. Für Skriptmodule existiert außerdem eine separate API. Temporäre Diagnoseausgaben gehören in zugriffsbeschränkte Logs der Testumgebung und nach der Prüfung wieder entfernt.

2. Dequeue und Deregister unterscheiden

• wp_dequeue_script() und wp_dequeue_style() entfernen den ausdrücklichen Queue-Eintrag. Die Registrierung bleibt erhalten.
• wp_deregister_script() und wp_deregister_style() entfernen die Registrierung. Benötigte abhängige Ressourcen können anschließend beim Laden oder Ausführen ausfallen.

Bleibt eine Datei als Abhängigkeit einer anderen vorgemerkten Ressource registriert, verhindert das alleinige Dequeuing dieser Abhängigkeit das Laden möglicherweise nicht. Das ist ein Anlass zur Prüfung des Abhängigkeitsbaums, kein Grund für erzwungenes Deregistrieren. Im Frontend besteht kein allgemeiner Schutz vor dadurch beschädigten Funktionen.

Priorität 100 läuft nach niedrigeren Prioritäten desselben Hooks. Ein späterer Callback oder ein anderer Hook kann die Datei weiterhin vormerken. Nach Ausgabe des HTML-Tags lässt sich das Laden nicht durch Dequeue rückgängig machen. Der passende Eingriffszeitpunkt ergibt sich aus der tatsächlichen Reihenfolge von Vormerkung und Ausgabe.

3. Ein bewusst begrenztes Beispiel

Das folgende Beispiel gehört in die functions.php eines Child-Themes oder in ein kleines projektspezifisches Plugin. Änderungen direkt am Parent-Theme können bei dessen Aktualisierung verloren gehen. Der Code betrifft ausschließlich ausdrücklich geprüfte einzelne Seiten oder Beiträge. Die anfangs leere Liste verändert nichts. Ein MU-Plugin benötigt die übliche PHP-Dateihülle und eine bewusste Wartung.

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 );

Nach vollständiger Prüfung könnte ein Eintrag die Form 123 => array( 'scripts' => array( 'contact-form-7' ), 'styles' => array( 'contact-form-7' ) ) haben. Die Zahl ist eine beispielhafte Beitrags-ID und keine Empfehlung für eine reale Installation. Ein solcher Eintrag ist nur begründet, wenn auf der gesamten gerenderten Seite kein Formular und keine verbleibende Abhängigkeit von diesen Handles existiert. Jede Übersetzung benötigt eine eigene geprüfte ID. Archivseiten bleiben unverändert.

Der Code erhält die Registrierungen. Vorlagen, sämtliche Abhängigkeiten, Skriptmodule und spätere Enqueue-Aufrufe werden nicht automatisch geprüft oder unterbunden. Diese Grenzen erfordern eine Quellcodeprüfung und Kontrolle im Browser. Eine pauschale WooCommerce-Sperrliste ist nicht enthalten.

4. Warum einfache Seitentyp-Regeln nicht reichen

Ein Mini-Warenkorb im Header, ein Produktblock im Artikel oder eine Kontofunktion kann Commerce-Dateien außerhalb von Shop, Warenkorb und Kasse benötigen. WooCommerce änderte das standardmäßige Laden von Cart Fragments bereits mit Version 7.8. Das klassische Warenkorb-Widget, Abhängigkeiten oder ausdrückliche Enqueue-Aufrufe können das Skript weiterhin anfordern. Die Aussage, jedes Plugin lade grundsätzlich jede Datei überall, ist falsch.

Formulare können im Footer, Widget, Template, wiederverwendeten Inhalt oder auf übersetzten Seiten stehen. Eine Prüfung nur auf die Slugs contact und support erfasst diese Fälle nicht. Auch die Shortcode-Suche ausschließlich im aktuellen Beitragsinhalt erkennt anderswo ergänzte Inhalte nicht. Contact Form 7 dokumentiert eigene Ladesteuerungen und ausdrückliche Enqueue-Funktionen. Auch diese Variante verlangt ein vollständiges Verzeichnis der Formularstellen und den korrekten Aufrufzeitpunkt.

5. Vor Veröffentlichung die Funktionen prüfen

1. Ausgangswerte für dieselbe URL, Fenstergröße, Geräteklasse und Cache-Situation erfassen.
2. Eine geprüfte Regel in der Testumgebung aktivieren. Das Verschwinden der beabsichtigten Dateien und den Erhalt notwendiger Abhängigkeiten kontrollieren.
3. Formulare, Validierung, Navigation, Kontoseiten, Hinzufügen zum Warenkorb, Mini-Warenkorb und Checkout entsprechend dem Seitenumfang ausprobieren; alle Sprachen und mobilen Ansichten einbeziehen. Darstellung und Tastaturbedienung gehören neben Konsolenfehlern zur Prüfung.
4. Angemeldete und abgemeldete Sitzungen sowie relevante Cache-Varianten prüfen. Für die Veröffentlichung sind eine rücknehmbare Änderung und Cache-Aktualisierung erforderlich. Eine kurze Produktionskontrolle folgt erst nach der Prüfung in der Testumgebung.

Übertragene Bytes, Anfragen und Laufzeiten müssen gemessen werden. Eine feste Einsparung, das Verschwinden sämtlicher Warnungen vor ungenutztem Code oder bessere Rankings sind nicht garantiert. TBT beschreibt blockierende Arbeit im Labortest; INP betrifft die Reaktionsfähigkeit bei Interaktionen und benötigt passende Interaktions- oder Felddaten. Ein niedrigerer TBT-Wert beweist keine INP-Verbesserung.