Child-Themes und Performance

Ein Theme bestimmt nicht nur das Aussehen, sondern maßgeblich auch die Geschwindigkeit einer Website. Überladene Themes mit großen Stylesheets, vielen Skripten und eingebauten Slidern machen Seiten langsam, schlanke Block-Themes machen sie schnell. Gleichzeitig muss ein Theme anpassbar bleiben, ohne dass Updates die Anpassungen zerstören. Diese Lektion verbindet beide Themen: wie Sie mit Child-Themes sicher anpassen und wie Sie dafür sorgen, dass die Website auf dem Handy schnell lädt – was Besucher, Suchmaschinen und die Zahl der Anfragen gleichermaßen belohnen.

1. Child-Themes

Bei Block-Themes ist ein Child-Theme besonders schlank. Eine style.css mit dem Verweis auf das Eltern-Theme genügt; eine eigene theme.json überschreibt nur die Werte, die sich unterscheiden. Eigene Vorlagen im Ordner templates haben Vorrang vor denen des Eltern-Themes, fehlende werden von dort übernommen.

1/*
2Theme Name:   Studio Child
3Template:     twentytwentyfive
4Version:      1.0.0
5Description:  Anpassungen für das Yogastudio
6*/

2. Skripte und Stile richtig laden

Eigene Stylesheets und Skripte werden in WordPress niemals direkt in Vorlagen eingebunden, sondern über wp_enqueue_style und wp_enqueue_script angemeldet. So weiß WordPress, welche Dateien geladen werden, vermeidet doppelte Einbindungen und kann Abhängigkeiten und Versionen verwalten. Noch besser für die Geschwindigkeit: Stile und Skripte nur dort laden, wo sie gebraucht werden. Block-Stile lädt WordPress bei Block-Themes ohnehin nur für Blöcke, die auf der Seite vorkommen. Für eigene Skripte lassen sich Ladestrategien wie defer angeben, damit sie das Anzeigen der Seite nicht blockieren.

1<?php
2add_action( 'wp_enqueue_scripts', function () {
3    if ( ! is_singular( 'kurs' ) ) {
4        return;                                   // nur auf Kursseiten
5    }
6    wp_enqueue_script(
7        'studio-merkzettel',
8        get_stylesheet_directory_uri() . '/assets/merkzettel.js',
9        [],
10        '1.0.0',
11        [ 'strategy' => 'defer', 'in_footer' => true ]
12    );
13} );

3. Was eine Seite langsam macht

Die Ladezeit wird heute vor allem mit den Core Web Vitals gemessen: wie schnell der größte sichtbare Inhalt erscheint (LCP), wie schnell die Seite auf Eingaben reagiert (INP) und wie stabil das Layout beim Laden bleibt (CLS). Die häufigsten Bremsen in WordPress sind große, unoptimierte Bilder, zu viele Plugins mit eigenen Skripten, externe Schriften und fehlendes Caching. Probieren Sie aus, welche Maßnahmen wie viel bringen:

4. Messen und belegen

5. Ein Beispiel

Die Website einer Zahnarztpraxis lud auf dem Handy in über fünf Sekunden. Die Analyse zeigte ein Kopfbild mit 3 MB, einen Slider, der auf jeder Seite drei Skripte lud, externe Schriften von einem fremden Server und fehlendes Caching. In einem Tag wurde umgestellt: Kopfbild als WebP in passenden Größen mit Vorrang beim Laden, Slider entfernt und durch ein statisches Bild mit Muster ersetzt, Schriften lokal eingebunden, Seitencache beim Hoster aktiviert. Die Ladezeit des größten Inhalts sank auf unter zwei Sekunden, alle Core Web Vitals sind grün, und die Absprungrate auf der Startseite ging spürbar zurück.

Bilder und Schriften im Detail

Bilder sind auf den meisten Seiten der größte Posten. WordPress erzeugt beim Hochladen automatisch mehrere Größen und gibt sie mit srcset aus, sodass Handys kleinere Dateien laden. Seit einigen Versionen erzeugt WordPress auf Wunsch auch moderne Formate wie WebP oder AVIF, und Bilder außerhalb des sichtbaren Bereichs erhalten automatisch loading="lazy". Wichtig ist das Gegenteil für das Kopfbild: Es ist meist das LCP-Element und sollte sofort und mit hoher Priorität geladen werden. WordPress setzt dafür fetchpriority="high" beim ersten großen Bild selbst, eigene Vorlagen sollten das nicht versehentlich aushebeln, etwa durch ein Hintergrundbild per CSS. Bei Schriften gilt: so wenige Schnitte wie möglich, im Format WOFF2, lokal eingebunden über theme.json und mit font-display: swap, damit Text sofort in einer Ersatzschrift erscheint. Zwei Schnitte einer variablen Schrift reichen für die meisten Websites völlig aus.

6. Häufige Fragen

Brauche ich ein Caching-Plugin? Das hängt vom Hosting ab. Viele gute WordPress-Hoster bieten Seitencache auf Serverebene, der schneller ist als jedes Plugin. Wo das fehlt, ist ein etabliertes Caching-Plugin sinnvoll. Wichtig ist, dass dynamische Bereiche wie Warenkorb oder Buchungsformular vom Cache ausgenommen werden.

Warum sind externe Schriften ein Problem? Sie verursachen zusätzliche Verbindungen zu fremden Servern und verzögern die Anzeige von Text. Zudem kann das Laden von Schriften fremder Anbieter datenschutzrechtlich problematisch sein. Block-Themes können Schriften über theme.json lokal einbinden, die Schriftbibliothek im Website-Editor lädt sie auf Wunsch direkt auf den eigenen Server.

Wie viel bringt ein neuer Server? Oft weniger als gedacht. Die größten Gewinne liegen meist bei Bildern, Skripten und Caching, also auf der eigenen Seite. Ein schnellerer Server hilft vor allem bei dynamischen Seiten, die nicht zwischengespeichert werden können, etwa im Backend oder bei Shops.

7. Übung zum Selbermachen

Messen Sie die Startseite Ihrer eigenen oder einer bekannten WordPress-Website mit PageSpeed Insights auf dem Handy. Notieren Sie LCP, INP und CLS und klicken Sie auf das angezeigte LCP-Element: Ist es ein Bild? Wie groß ist es? Prüfen Sie anschließend unter „Diagnose“, welche Skripte das Rendern blockieren. Formulieren Sie drei konkrete Maßnahmen, geordnet nach erwarteter Wirkung und Aufwand. Diese Übung schult den Blick dafür, wo Performance-Probleme tatsächlich entstehen – und verhindert, dass Zeit in Maßnahmen fließt, die kaum etwas bringen.

Stand: September 2026, WordPress 7.1, PHP 8.3. Kursmaterial der Klarwerk Akademie. WordPress entwickelt sich schnell – maßgeblich ist die aktuelle Dokumentation auf developer.wordpress.org.