WordPress Performance optimieren: In 3 Schritten zum 95% PageSpeed Score

3.1 LCP‑Optimierung über HTTP‑Header und Bildattribute

Damit das Hero‑Bild sofort lädt, setze ich den Preload‑Impuls direkt im Header und ergänze ihn im Markup. Wir nutzen hier die „Power-Variante“, die auch statische Startseiten und den Blog-Index erkennt:

add_action('wp_head', function () {
    $lcp_url = '';
    if (is_front_page()) {
        $lcp_url = get_the_post_thumbnail_url(get_option('page_on_front'), 'large');
    } elseif (is_singular()) {
        $lcp_url = get_the_post_thumbnail_url(get_the_ID(), 'large');
    }

    if ($lcp_url) {
        header('Link: <' . esc_url($lcp_url) . '>; rel=preload; as=image; fetchpriority=high', false);
        echo '<link rel="preload" as="image" href="' . esc_url($lcp_url) . '" fetchpriority="high">';
    }
}, -200);

Zusätzlich passe ich die Bildattribute an, damit das LCP‑Element (und andere kritische Infografiken) nicht verzögert werden:

add_filter('wp_get_attachment_image_attributes', function ($attr) {
    if (isset($attr['class']) && str_contains($attr['class'], 'wp-post-image')) {
        $attr['loading']       = 'eager';
        $attr['fetchpriority'] = 'high';
        $attr['decoding']      = 'sync';
    }
    return $attr;
}, 999);

3.2 Der „Stille Killer“: Astra Autoload-Optimierung

Ein oft übersehener Performance-Fresser in WordPress sind die options-Tabelle und der autoload-Mechanismus. Das Astra-Theme lädt standardmäßig ca. 265 KB an Einstellungen bei jedem Seitenaufruf – auch wenn sie nur im Customizer gebraucht werden.

Wichtiger Hinweis: Diese Funktion sollte nicht bei jedem Seitenaufruf „nackt“ in der functions.php stehen, da die Datenbankabfrage sonst den Performance-Gewinn wieder auffrisst. Wir führen sie entweder einmalig manuell aus oder hängen sie an einen täglichen Wartungs-Cronjob.

In der functions.php entlasten wir die Datenbank so:

function seotologie_fix_autoload_issues() {
    global $wpdb;
    // Deaktiviere Autoload für große Theme-Settings
    $wpdb->query("UPDATE $wpdb->options SET autoload = 'no' WHERE option_name = 'astra-settings'");
    // Cleanup von verwaisten Transients, die den Autoload aufblähen
    $wpdb->query("DELETE FROM $wpdb->options WHERE option_name LIKE '_transient_astra_%'");
}

3.3 Serverseitiges Hardening & Caching (.htaccess)

Bevor WordPress überhaupt eine Zeile Code ausführt, sorgt die .htaccess für die nötige Basis-Geschwindigkeit. Drei Hebel sind hier entscheidend:

1. Gzip-Kompression: Über mod_deflate werden Text-Ressourcen (HTML, CSS, JS) komprimiert an den Browser geschickt.
2. Immutable Caching: Statische Dateien (Fonts, Logos) erhalten einen Cache-Control Header von einem Jahr mit dem Zusatz immutable. Einmal geladen, fragt der Browser nie wieder beim Server nach.
3. 404-Bypass für statische Dateien: Wenn ein Bild fehlt, soll WordPress nicht versuchen, eine 404-Seite zu generieren (was eine teure Datenbank-Abfrage triggert). Wir fangen das direkt im Apache ab:

<FilesMatch "\.(css|js|ico|gif|jpg|jpeg|png|svg|webp|avif|woff|woff2)$">
    ErrorDocument 404 "File Not Found"
</FilesMatch>

3.4 JavaScript‑Kette entschärfen: Borlabs verzögert laden

Borlabs Cookie ist unverzichtbar, aber schwer. Um die TBT bei 0 ms zu halten, lade ich die Skripte kontrolliert verzögert. Wir nutzen hier ein Throttling-Script, das erst nach 1.000ms (nach dem LCP-Fenster) die echten Borlabs-Skripte nachlädt.

3.5 CSS-Strategie: Entkoppeln statt Blockieren

Um den schnellen Speed Index zu stabilisieren, extrahiere ich die wichtigsten Layout‑Styles in ein kritisches Inline-Stylesheet. Alles andere landet asynchron im Footer.