So wählen Sie ein Theme aus und erkennen jene, die alles in eine einzige riesige JavaScript-Datei packen

Wir reden viel über Cache-Plugins, CDNs, Bilder im WebP-Format. Selten reden wir über die Entscheidung, die allen vorausgeht und über den Rest bestimmt: das Theme. Noch vor einer einzigen Zeile Inhalt legt Ihr Theme fest, was ein Browser herunterladen, parsen, kompilieren und ausführen muss, um die Seite zu zeichnen. Und unter all seinen technischen Entscheidungen wiegt eine bei der Geschwindigkeit schwerer als die anderen: die Art, wie es sein JavaScript ausliefert.

Es gibt zwei Familien. Themes, die ihren Code in kleine, bei Bedarf geladene Teile aufteilen, und Themes, die alles in einen einzigen Block stapeln, die berühmte main.js, theme.js oder bundle.min.js, die das Menü, den Slider, die Lightbox, die Tabs, die Formulare, die Scroll-Animationen und die AJAX-Aufrufe steuert. Diese zweite Familie sperrt Sie in eine niedrige Performance-Obergrenze ein. Hier ist der Grund, und wie Sie das erkennen, bevor Sie sich festlegen.

Feine Optimierung heißt, aufteilen zu können

Eine gute Frontend-Optimierung ist nie ein einzelner Schalter. Sie ist chirurgische Arbeit: behalten, was sofort sichtbar ist, den Rest nach hinten schieben, entfernen, was überhaupt nicht genutzt wird. Konkret wollen wir auf einer gut optimierten Seite in der Lage sein:

• Das strikte Minimum laden, damit der obere Teil der Seite (der ATF, above the fold) so schnell wie möglich gezeichnet und interaktiv ist.
• Verzögern, alles, was nicht sofort gebraucht wird (ein Footer-Karussell, ein Chat, ein Share-Widget), bis zur ersten Interaktion oder zum ersten Scroll.
• Gar nicht laden, was auf der aktuellen Seite nicht erscheint (das Galerie-Skript auf einer Seite ohne Galerie).

Diese drei Hebel teilen eine Voraussetzung: Der Code muss aufteilbar sein. Ein Teil lässt sich nur verzögern, wenn es als Teil existiert. Ein bedingtes Skript lässt sich nur weglassen, wenn es bedingt eingebunden wurde. Darauf beruht die gesamte Finesse. Ein monolithisches Theme beseitigt die Voraussetzung. Es gibt keine Teile mehr, es gibt einen Block.

Anatomie eines Monolithen

Öffnen Sie den Network-Tab einer Website, filtern Sie nach JS und schauen Sie sich das Gewicht der größten Datei an, die das Theme ausliefert. Bei einem monolithischen Theme sehen Sie eine einzige Datei, die das Wesentliche bündelt:

acme-theme/assets/js/main.min.js      287 KB   <- everything
jquery.min.js                          89 KB
jquery-migrate.min.js                  13 KB

Diese Datei tut nicht eine Sache. Sie tut zwanzig. Und vor allem sind sie miteinander verdrahtet im selben Scope, derselben Closure, derselben jQuery-Abhängigkeitskette. Das Dropdown-Menü teilt seine Initialisierung mit dem Hero-Slider, der seine mit dem Testimonials-Modul teilt, das von einem Scroll-Plugin abhängt, das von jQuery abhängt, das von jQuery Migrate abhängt. Entfernen Sie einen Baustein, und die anderen fallen.

Hier stößt die Optimierungsstrategie an die Wand. Nehmen wir noch einmal unsere drei Hebel. Alles verzögern: Sie können den ganzen Block bis zur ersten Interaktion nach hinten schieben, aber dann bezahlt die erste Interaktion (ein simpler Klick auf das Burger-Menü) auf einen Schlag den Download, das Parsen, das Kompilieren und das Ausführen der vollen 287 KB. Der Nutzer klickt, und nichts reagiert, während der Main Thread ein Karussell verdaut, für das er keine Verwendung hat. Sie haben das Problem verschoben, nicht gelöst. Nichts verzögern: Der Block läuft beim Laden, bläht die TBT (Total Blocking Time) auf, verzögert die Interaktivität und verschlechtert, wenn er das DOM im sichtbaren Bereich berührt, den LCP. Fein aufteilen: unmöglich, es gibt nichts aufzuteilen. Es gilt Alles oder Nichts.

Die wahren Kosten sind das Parsen, nicht der Download

Ein hartnäckiger Irrtum: "300 KB komprimiertes JS, das ist doch nichts zum Herunterladen." Der Download ist nicht das Hauptproblem. JavaScript hat Kosten, die Bilder nicht haben: es muss auf dem Main Thread geparst, kompiliert und ausgeführt werden, genau dem, der die Nutzerinteraktionen beantworten muss.

Ein Bild-Byte wird auf einem Nebenthread dekodiert. Ein JS-Byte blockiert potenziell die Interaktivität. Auf einem Mittelklasse-Smartphone wird das Parsen und Ausführen von 300 KB Anwendungs-JS in Hunderten von Millisekunden gemessen, nicht im Netzwerkgewicht. Und ein Monolith lässt Sie diese Kosten voll bezahlen, für Code, der in 80 % der Fälle nichts mit der Seite auf dem Bildschirm zu tun hat.

"Aber eine Datei ist doch besser für HTTP/2, oder?"

Ein berechtigter Einwand, der eine ehrliche Antwort verdient statt einer Abfuhr. Ja, historisch war es gute Praxis, die Anzahl der Requests zu senken, und ja, das Zusammenführen ergab über HTTP/1.1 Sinn. Aber zwei Dinge haben sich geändert. Erstens, HTTP/2 und HTTP/3 multiplexen: mehrere kleine Dateien parallel kosten nicht mehr den Preis der sequenziellen Requests von früher. Das Argument "weniger Requests" hat weitgehend an Kraft verloren.

Zweitens, und das ist der entscheidende Punkt, die wahren Kosten von JS sind nicht der Request, sondern die Ausführung. Zehn kleine Skripte, von denen Sie nur zwei ausführen, kosten weit weniger als ein einziges großes, das Sie vollständig ausführen. Granularität ist nicht dazu da, mehr Requests zu erzeugen, sie ist dazu da, weniger Code auszuführen. Das ist ein anderer Vorteil, und er überlebt HTTP/2 einwandfrei.

Drei konkrete Fälle

Bei einem solchen Theme ist das klassische Symptom ein Burger-Menü, das sich erst beim zweiten Tippen öffnet. Die allgemeine Methode, um herauszufinden, welches Skript eine Verzögerung kaputt gemacht hat, finden Sie in unserem Leitfaden zur JavaScript-Verzögerung.

// Menü: winzig, ohne jQuery, immer nötig
wp_enqueue_script( 'acme-nav', $uri.'/nav.js', array(), null, true );

// Galerie: nur dort, wo es wirklich eine Galerie gibt, verzögert
if ( has_block( 'core/gallery' ) ) {
  wp_enqueue_script( 'acme-gallery', $uri.'/gallery.js', array(), null, true );
}

So erkennen Sie einen Monolithen, bevor Sie sich festlegen

Sie können ein Theme in wenigen Minuten prüfen, an seiner Demo, ohne es überhaupt zu installieren.

1. Network-Tab, JS-Filter. Schauen Sie sich die größte Datei an, die das Theme ausliefert. Eine einzelne Datei von 150 KB oder mehr, die auf jeder Seite vorhanden ist, ist ein Warnsignal. Mehrere Dateien von bescheidener Größe sind ein gutes Zeichen.
2. Coverage-Tab (in DevTools, "Coverage"). Laden Sie die Seite neu und lesen Sie den "Unused"-Prozentsatz. Zeigt das große Skript auf einer Unterseite 60 % oder mehr ungenutzten Code, lädt das Theme zu viel, überall, ohne Bedingungen.
3. Der Test mit der nackten Seite. Vergleichen Sie das JS, das auf der Startseite geladen wird, mit dem einer minimalistischen Kontaktseite. Wenn es exakt dasselbe Bundle ist, lädt das Theme nichts bedingt. Es kippt alles ab, die ganze Zeit.
4. Die jQuery-Abhängigkeit. Ein Theme, das jQuery, jQuery Migrate und einen Haufen jQuery-Plugins zu einer einzigen Kette stapelt, ist im Geiste fast immer monolithisch, selbst wenn es seine Dateien aufteilt. Diese Abhängigkeiten halten sich an den Händen und weigern sich, getrennt zu werden.
5. Der Blick in den Code, falls zugänglich. Schauen Sie, wie Skripte registriert werden. Ein einziges globales wp_enqueue_script ohne Seiten- oder Komponentenbedingung sagt alles. Ein seriöses Theme bindet seine Skripte nah bei den Komponenten ein, die sie nutzen, und unter Bedingungen.

Was ein gutes Theme ausmacht, was JS betrifft

• Granulare Assets: mehrere gezielte Skripte statt eines einzigen Blocks.
• Bedingtes Laden: ein Skript ist nur auf den Seiten vorhanden, die seine Komponente nutzen.
• Geringe jQuery-Abhängigkeit, idealerweise natives JavaScript für die kritischen Bausteine wie das Menü.
• Von Natur aus verzögerbar: der Code kann nach hinten geschoben werden, ohne den sichtbaren Bereich zu zerbrechen, weil der sichtbare Bereich nicht von ihm abhängt.
• Nichts Unnützes, das beim Laden ausgeführt wird, für den oberen Teil der Seite.
• Saubere Hooks, die es einer Optimierungsplattform erlauben, einen Teil ohne Nebenwirkungen zu entfernen, zu verzögern oder zu ersetzen.

Keiner dieser Punkte betrifft das "Gewicht" des Themes im Marketingsinn. Es geht bei allen um die Aufteilbarkeit. Das ist die wahre Kennzahl.

Das Fazit

Eine Website zu optimieren heißt, feine Entscheidungen zu treffen, Seite für Seite, Komponente für Komponente: diese jetzt, jene später, diese dritte nie. Diese Entscheidungen setzen voraus, dass das Theme seinen Code als Teile geliefert hat, die Sie einzeln handhaben können. Ein monolithisches Theme liefert keine Teile, es liefert einen verschweißten Block und verurteilt Sie zu Alles oder Nichts.

Eine Optimierungsplattform kann selbst in diesem Fall viel tun: einen Cache ausliefern, im Block verzögern, was verzögerbar ist, Bilder leichter machen, das Layout stabilisieren. Aber sie kann eine Kopplung, die in den Theme-Code geschrieben ist, nicht rückgängig machen. Die Obergrenze wurde vorab festgelegt, in dem Moment, als das Theme gewählt wurde.