WordPress-Medienoptimierung mit WebP und AVIF

#WordPress-Medienoptimierung: Geschwindigkeit und Skalierbarkeit

Mehr über unsere WordPress-Geschwindigkeitsoptimierung erfahren Sie auf der Leistungsseite.

Diese Strategien wirken nur, wenn Sie technische Optimierung und Inhaltsqualität systematisch zusammenbringen. So setzen Sie die einzelnen Schritte um.

#1. WebP und AVIF in WordPress mit Imagick oder GD

Die klassischen Formate JPEG und PNG sind im Vergleich zu modernen Alternativen sehr ineffizient.

• WebP: WordPress unterstützt WebP seit Version 5.8. Das Format bietet verlustfreie und verlustbehaftete Kompression. Laut Googles WebP-Dokumentation sind verlustbehaftete WebP-Dateien 25 bis 34% kleiner als vergleichbare JPEGs, verlustfreie WebP-Dateien 26% kleiner als PNG.
• AVIF (AV1 Image File Format): Seit WordPress 6.5 unterstützt. AVIF nutzt Intra-Frame-Kodierung aus dem Videocodec AV1. Bei gleicher visueller Qualität schlägt es WebP meist, der Abstand hängt aber vom Bild ab, messen Sie also an Ihrer eigenen Mediathek. Der Leitfaden zu AVIF und JPEG XL behandelt Kodierungsaufwand und Browser-Unterstützung.

#Prüfen, ob PHP WebP und AVIF unterstützt

Um diese Formate zu erzeugen, muss PHP Imagick oder GD mit AVIF- und WebP-Unterstützung verwenden. Welche Bibliotheken auf Ihrem Server verfügbar sind, prüfen Sie über die Kommandozeile:

# WebP- und AVIF-Unterstützung in den PHP-Modulen prüfen
php -r "print_r(gd_info());"
php -r "if (class_exists('Imagick')) { print_r(Imagick::getConfigureOptions()); }"

Suchen Sie im GD-Array nach WebP Support => 1 und AVIF Support => 1. Fehlen diese Einträge, müssen die PHP-Pakete Ihres Servers mit libwebp und libavif kompiliert werden.

Dieselbe Prüfung lässt sich auch in PHP selbst durchführen, etwa für eine Statusanzeige im Admin-Bereich:

function check_avif_support() {
    $support = [
        'gd' => function_exists('imagecreatefromavif'),
        'imagick' => extension_loaded('imagick') && 
                     in_array('AVIF', Imagick::queryFormats())
    ];
    
    return $support;
}

#Imagick oder GD für die Bildverarbeitung in WordPress

In der WordPress-Entwicklung übernehmen zwei Bibliotheken die Bildbearbeitung im Backend: GD und Imagick. Die Wahl wirkt sich direkt auf Ressourcenverbrauch und Ausgabequalität aus:

• Imagick (ImageMagick): Die bevorzugte Engine für größere Umgebungen. Sie liefert bessere Farbwiedergabe, behält Metadatenprofile (etwa EXIF-Rotationswerte) und beherrscht fortgeschrittene Operationen wie Vorschauen mehrseitiger PDFs. Allerdings braucht Imagick viel Speicher, weil der dekodierte Pixelpuffer mit der Pixelzahl wächst und nicht mit der Dateigröße: Ein 12-Megapixel-JPEG mit 3 MB auf der Platte belegt im RAM mehrere Dutzend Megabyte.
• GD (Graphics Library): Eine schlanke Engine mit geringem Ressourcenbedarf. Für typische Skalierungen ist GD die leichtere der beiden. Veröffentlichte Benchmarks sind sich über die Größe des Abstands uneinig, manche sogar über die Richtung, messen Sie daher auf Ihrem eigenen Stack, statt einer Prozentzahl aus einer Überschrift zu vertrauen. GD fehlen allerdings fortgeschrittene Farbraumkonvertierungen (die Farben wirken nach der Umwandlung oft etwas blass), und EXIF-Profile gehen verloren.
• Beim Erzeugen von WebP und AVIF nutzt der Encoder von Imagick mehrere Threads, während GD synchron auf einem CPU-Kern arbeitet. Für Plattformen mit viel Traffic sollten Sie Imagick bevorzugen und den Speicherverbrauch mit strikten Ressourcenrichtlinien begrenzen.

#Speicherlimits für Imagick in policy.xml setzen

Das Erzeugen von AVIF-Dateien belastet CPU und Speicher stark. Werden mehrere hochauflösende Bilder gleichzeitig hochgeladen, kann dem PHP-Prozess der Speicher ausgehen (OOM), oder das Skript läuft in einen Timeout.

Dagegen helfen die Ressourcenrichtlinien von Imagick. Bearbeiten Sie /etc/ImageMagick-6/policy.xml oder /etc/ImageMagick-7/policy.xml und legen Sie passende Speichergrenzen fest:

<policymap>
  <!-- Speicher pro Prozess auf 512MiB begrenzen -->
  <policy domain="resource" name="memory" value="512MiB"/>
  <policy domain="resource" name="map" value="1GiB"/>
  <!-- Threads begrenzen, damit die CPU nicht ausgelastet wird -->
  <policy domain="resource" name="thread" value="2"/>
  <!-- Externe Delegate-Programme sperren -->
  <policy domain="delegate" rights="none" pattern="*"/>
</policymap>

Mit diesen Grenzen läuft die Bildverarbeitung stabil in Ihrer Hosting-Umgebung, auch wenn Sie die gesamte Mediathek neu generieren.

#2. Bildkompression in WordPress einstellen

Standardmäßig komprimiert WordPress hochgeladene JPEGs mit 82% Qualität. Für Thumbnails und Hintergrundelemente ist das unnötig hoch und bläht die Dateien auf.

#Kompressionsqualität pro Bildformat festlegen

Fügen Sie diese Filter in die functions.php Ihres Themes ein, um die Qualität je nach MIME-Typ anzupassen:

declare(strict_types=1);

namespace WPPoland\Performance\Media;

/**
 * Passt die Kompressionsqualität je Bildformat an.
 */
function set_media_compression_quality( int $quality, string $mime_type ): int {
    switch ( $mime_type ) {
        case 'image/jpeg':
            return 75; // Spart ca. 20% Speicherplatz gegenüber den Standard-82%
        case 'image/webp':
            return 80;
        case 'image/avif':
            return 65; // AVIF hält die Qualität auch bei stärkerer Kompression
        default:
            return $quality;
    }
}
add_filter( 'wp_editor_set_quality', __NAMESPACE__ . '\\set_media_compression_quality', 10, 2 );
add_filter( 'jpeg_quality', function() { return 75; } );

#3. Nicht genutzte Bildgrößen in WordPress deaktivieren

Lädt jemand ein Bild hoch, erzeugt WordPress für jede registrierte Zwischengröße eine eigene Datei. Allein der Core registriert sechs (thumbnail, medium, medium_large, large, 1536x1536 und 2048x2048), und jedes Theme oder Plugin, das add_image_size() aufruft, fügt weitere hinzu. Ein einziger Upload kann so ein Dutzend Dateien auf der Platte hinterlassen, was Speicherplatz, Inodes und bei Medienmigrationen CPU-Zeit kostet.

#Ungenutzte Bildgrößen in functions.php entfernen

Entfernen Sie nicht verwendete Thumbnailgrößen, um Speicherplatz zu sparen und die Verarbeitung beim Upload zu entlasten:

declare(strict_types=1);

namespace WPPoland\Performance\Thumbnails;

/**
 * Entfernt nicht genutzte Thumbnail-Dimensionen.
 */
function unregister_bloated_thumbnail_sizes( array $sizes ): array {
    // Größen entfernen, die das Theme-Layout nicht nutzt
    unset( $sizes['medium_large'] ); // 768px breit
    unset( $sizes['1536x1536'] );     // Extra groß
    unset( $sizes['2048x2048'] );     // 2K groß
    return $sizes;
}
add_filter( 'intermediate_image_sizes_advanced', __NAMESPACE__ . '\\unregister_bloated_thumbnail_sizes' );

/**
 * Registriert die Größen, die aktive Layouts tatsächlich verwenden.
 */
function register_theme_image_sizes(): void {
    add_image_size( 'hero-lg', 1920, 800, true );
    add_image_size( 'blog-card', 600, 400, true );
}
add_action( 'after_setup_theme', __NAMESPACE__ . '\\register_theme_image_sizes' );

#4. Lazy Loading für das LCP-Bild in WordPress deaktivieren

Seit Version 5.5 hängt WordPress automatisch loading="lazy" an Bilder in Beiträgen. Insgesamt hilft das der Ladezeit, doch Lazy Loading bei Elementen im sichtbaren Bereich bremst den Preloader des Browsers aus und verschlechtert den LCP (Largest Contentful Paint). Seit WordPress 6.3 lässt der Core das erste große Bild bereits ohne Lazy Loading und gibt ihm fetchpriority="high", wie der Leitfaden zur Bildverarbeitung erklärt. Die folgenden Filter funktionieren trotzdem (der Core behält wp_img_tag_add_loading_attr aus Gründen der Abwärtskompatibilität) und sind wichtig für eigene Templates und Listen, in denen der Core falsch rät.

#Bilder im sichtbaren Bereich mit fetchpriority sofort laden

Richten Sie Ihre Templates so ein, dass das erste Bild in Beitragslisten sofort geladen wird und Hero-Bilder eine hohe Ladepriorität bekommen:

declare(strict_types=1);

namespace WPPoland\Performance\LCP;

/**
 * Deaktiviert Lazy Loading für das erste Bild im Beitrag.
 */
function disable_lazy_load_on_first_image( string|bool $value, string $image_tag, string $context ): string|bool {
    static $first_image = true;

    if ( 'the_content' === $context && $first_image ) {
        $first_image = false;
        return false; // Verhindert das Einfügen von loading="lazy"
    }

    return $value;
}
add_filter( 'wp_img_tag_add_loading_attr', __NAMESPACE__ . '\\disable_lazy_load_on_first_image', 10, 3 );

/**
 * Ergänzt fetchpriority="high" bei sofort geladenen Bildern.
 */
function apply_fetchpriority_to_eager_images( array $attr, \WP_Post $attachment ): array {
    if ( isset( $attr['loading'] ) && 'eager' === $attr['loading'] ) {
        $attr['fetchpriority'] = 'high';
    }
    return $attr;
}
add_filter( 'wp_get_attachment_image_attributes', __NAMESPACE__ . '\\apply_fetchpriority_to_eager_images', 10, 2 );

#5. Responsive Bildgrößen konfigurieren

Damit Browser aus dem srcset-Attribut die passende Bildgröße anfordern, müssen Sie die Definitionen im sizes-Attribut anpassen. Das Standardattribut fällt oft auf 100vw zurück, sodass auf Desktop-Bildschirmen zu große Bilder geladen werden.

#Eigenes sizes-Attribut für die srcset-Breakpoints

declare(strict_types=1);

namespace WPPoland\Performance\Responsive;

/**
 * Überschreibt das sizes-Attribut passend zu den Breakpoints des Themes.
 */
function filter_responsive_image_sizes_attribute( string $sizes, array $size_array ): string {
    $width = $size_array[0];

    // Prüfen, ob das Bild in die Grenzen des Beitragslayouts passt
    if ( $width >= 800 ) {
        return '(max-width: 840px) 100vw, 800px';
    }

    return $sizes;
}
add_filter( 'wp_calculate_image_sizes', __NAMESPACE__ . '\\filter_responsive_image_sizes_attribute', 10, 2 );

#6. AVIF statt JPEG per .htaccess ausliefern

Liegen auf Ihrer Website ältere JPEGs, Sie möchten modernen Browsern aber WebP- oder AVIF-Versionen liefern, ohne das HTML zu ändern, helfen serverseitige Regeln zur Content Negotiation.

#AVIF mit Apache-Rewrite-Regeln ausliefern

Diese Regeln in der .htaccess liefern automatisch die AVIF-Datei aus, wenn der Browser das Format akzeptiert und die Datei auf dem Server existiert:

<IfModule mod_rewrite.c>
  RewriteEngine On
  
  # Prüfen, ob der Browser AVIF unterstützt
  RewriteCond %{HTTP_ACCEPT} image/avif
  
  # Prüfen, ob die AVIF-Version auf der Platte liegt
  RewriteCond %{DOCUMENT_ROOT}/$1.avif -f
  
  # Anfragen nach JPEG/PNG auf die AVIF-Version umleiten
  RewriteRule ^(wp-content/uploads/.*)\.(jpe?g|png)$ $1.avif [T=image/avif,E=accept:1]
</IfModule>

Mit diesen Rewrite-Regeln auf Serverebene bekommen kompatible Browser moderne, stark optimierte Dateien, während ältere Systeme weiterhin ihre Fallbacks erhalten.

#7. WordPress-Medien mit CDN auf S3 auslagern

Bei großen Mediatheken begrenzt lokaler Serverspeicher die Skalierbarkeit und erschwert Backups. Für Websites mit viel Traffic ist es üblich, Medien in einen Object Storage (etwa AWS S3, DigitalOcean Spaces oder Google Cloud Storage) auszulagern und über ein Content Delivery Network (CDN) auszuliefern.

#Was sich beim Auslagern von WordPress-Medien ändert

Wenn Medien ausgelagert sind:

1. Zustandslose Webserver: Einzelne Webserver brauchen keine Synchronisierung persistenter Volumes mehr. Sie können Web-Container mit Autoscaling-Gruppen dynamisch hoch- und herunterskalieren.
2. Weniger lokaler Speicher: Ist die Integration so eingestellt, dass lokale Dateien nach erfolgreichem Upload sofort gelöscht werden, läuft die lokale Platte nicht voll, und die Kosten der Anwendungsserver bleiben im Rahmen.
3. CDN-Caching und geografische Verteilung: Die Anfragen gehen nicht mehr an den Hauptserver, sondern an Edge-Caches (etwa Cloudflare, Amazon CloudFront oder KeyCDN). Das senkt Bandbreitenverbrauch und Latenz für Nutzer weltweit.

#Einstellungen für WP Offload Media in wp-config.php

Die Dokumentation der Einstellungskonstanten von WP Offload Media beschreibt AS3CF_SETTINGS als serialisiertes Array. Als Storage-Provider stehen aws, do und gcp zur Verfügung; eine eigene CDN-Domain setzen Sie über die Delivery-Schlüssel, nicht über die Storage-Schlüssel:

// S3-Zugangsdaten und Bucket-Details sicher in wp-config.php definieren
define( 'AS3CF_SETTINGS', serialize( [
    'provider' => 'aws',
    'access-key-id' => getenv( 'AWS_ACCESS_KEY_ID' ),
    'secret-access-key' => getenv( 'AWS_SECRET_ACCESS_KEY' ),
    'bucket' => 'wppoland-media-bucket',
    'region' => 'eu-central-1',
    'copy-to-s3' => true,
    'serve-from-s3' => true,
    'remove-local-file' => true, // Spart Speicherplatz auf dem Anwendungsserver
    'object-versioning' => true, // Pfade mit Zeitstempel, geänderte Dateien bekommen neue URLs
    'delivery-provider' => 'cloudflare',
    'enable-delivery-domain' => true,
    'delivery-domain' => 'media.wppoland.com' // Eigene CDN-Subdomain
] ) );

#CORS- und Cache-Control-Header für einen S3- oder R2-Bucket

Damit Vektorgrafiken (SVGs) und eigene Webfonts aus Ihrem Medien-Bucket auch auf entkoppelten Headless-Domains korrekt angezeigt werden (zum Beispiel bei Astro-Frontends auf einer anderen Domain), braucht der Bucket eine Konfiguration für Cross-Origin Resource Sharing (CORS).

Hinterlegen Sie diese JSON-Richtlinie in den Einstellungen Ihres S3- oder R2-Buckets:

[
  {
    "AllowedHeaders": ["*"],
    "AllowedMethods": ["GET", "HEAD"],
    "AllowedOrigins": ["https://wppoland.com", "https://www.wppoland.com"],
    "ExposeHeaders": ["ETag"],
    "MaxAgeSeconds": 3000
  }
]

Achten Sie außerdem darauf, dass Dateien aus dem Bucket statische Cache-Header tragen. Konfigurieren Sie Ihre Offload-Integration oder das CDN so, dass dieser Header gesetzt wird: Cache-Control: public, max-age=31536000, immutable

Damit speichern Browser und Edge-Server die Mediendateien dauerhaft zwischen, was Anfragen spart und die Ladezeit verkürzt. Die Direktive immutable ist nur sicher, weil object-versioning eine geänderte Datei unter einem neuen Pfad ablegt. Ohne diese Option behält ein bearbeitetes Bild seine alte URL und bleibt ein Jahr lang im Cache.

#8. Upload-Größe für Bilder in WordPress begrenzen

Damit Redakteure keine unkomprimierten 10-MB-Kamerafotos direkt in Blöcke des Beitragseditors laden (was Bandbreite und Speicher verschwendet), setzen Sie an der Servergrenze einen automatischen Prüffilter.

#Warum die Upload-Größe auf dem Server geprüft werden sollte

Eine Prüfung der Dateigröße auf dem Server verhindert Timeouts bei der PHP-Verarbeitung. Lädt ein Redakteur ein 10-MB-Bild hoch:

1. Der Server muss die temporäre Datei nach /tmp/ schreiben.
2. Der PHP-Prozess versucht, das Bild zum Skalieren in den Speicher zu laden. Werden die Grenzen von GD oder Imagick erreicht, bricht das Skript ab und hinterlässt unvollständige Dateien auf der Platte.
3. Ein Filter am Hook wp_handle_upload_prefilter fängt die Datei direkt beim Empfang ab und prüft die Größe, bevor eine Bildumwandlung startet. Der Abschnitt zu upload_max_filesize weiter unten zeigt, wie der Uploader im Browser dieselbe Grenze schon vor dem Senden durchsetzt.

So sieht der PHP-Filter aus:

declare(strict_types=1);

namespace WPPoland\Performance\Limits;

/**
 * Setzt beim Upload Größengrenzen je Bildtyp durch.
 */
function restrict_large_uploads( array $file ): array {
    $size_kb = $file['size'] / 1024;
    $type    = $file['type'];

    // Normale Rasterbilder auf 1.5MB begrenzen
    if ( strpos( $type, 'image/' ) !== false && 'image/gif' !== $type ) {
        if ( $size_kb > 1536 ) {
            $file['error'] = 'Image upload failed: File size exceeds the 1.5MB limit. Please compress your asset before uploading.';
        }
    }

    return $file;
}
add_filter( 'wp_handle_upload_prefilter', __NAMESPACE__ . '\\restrict_large_uploads' );

#9. Was WordPress zu jedem hochgeladenen Bild speichert

Jede Datei in der Mediathek ist ein Beitrag vom Typ attachment. Auf die Datei selbst verweisen zwei Post-Meta-Zeilen, und die meisten Medienprobleme (kaputte Thumbnails nach einer Migration, ein Offload-Plugin, das die falsche Größe ausliefert, eine Regenerierung, die nie fertig wird) laufen darauf hinaus, dass diese beiden Zeilen nicht mit dem Inhalt der Platte übereinstimmen.

• _wp_attached_file enthält den Pfad relativ zum Upload-Verzeichnis, zum Beispiel 2026/10/workshop-floor.jpg. War das Original größer als der Schwellenwert für große Bilder, zeigt dieser Eintrag auf die -scaled-Kopie, nicht auf das Original.
• _wp_attachment_metadata enthält ein serialisiertes Array, das wp_generate_attachment_metadata() erzeugt: width, height, file, filesize (gespeichert seit WordPress 6.0), sizes mit einem Eintrag pro erzeugter Zwischengröße (Dateiname, Breite, Höhe, MIME-Typ), image_meta mit den EXIF- und IPTC-Daten, die der Core ausliest, sowie original_image, wenn der Upload verkleinert wurde.

Lesen Sie das Array selbst aus, bevor Sie dem Bericht eines Plugins darüber vertrauen:

# Metadaten von Anhang 1874 als JSON ausgeben
wp post meta get 1874 _wp_attachment_metadata --format=json

# Gespeicherten relativen Pfad anzeigen
wp post meta get 1874 _wp_attached_file

Seit WordPress 5.3 schreibt der Core diese Metadaten nach jeder erzeugten Zwischengröße, nicht erst am Ende. Bricht PHP mitten in einem großen Upload ab, sind die fertigen Größen bereits erfasst, und wp_update_image_subsizes() erzeugt beim nächsten Versuch nur die fehlenden. Deshalb hat die REST API auch eine post-process-Route (/wp/v2/media/<id>/post-process mit der Aktion create-image-subsizes): Nach einem Serverfehler kann der Uploader die fehlenden Größen anfordern, statt die Datei erneut zu senden.

Der Filter big_image_size_threshold (standardmäßig 2560 Pixel) entscheidet, wann die -scaled-Kopie entsteht. Wie Sie ihn ändern oder abschalten, zeigt der Leitfaden zur Bildverarbeitung, der auch wp media regenerate Schritt für Schritt erklärt.

#Registrierte Bildgrößen mit WP-CLI auflisten

Bevor Sie in Abschnitt 3 etwas abmelden, sehen Sie nach, was tatsächlich registriert ist. wp media image-size gibt jede Größe mit Breite, Höhe, Crop-Flag und Seitenverhältnis aus, auch Größen von Plugins, die Sie vielleicht vergessen haben:

wp media image-size --format=table
wp media image-size --fields=name,width,height,crop --format=csv

Vergleichen Sie diese Liste mit den Dateien in einem aktuellen Monatsordner. Eine Größe, die auf der Platte liegt, aber nicht in der Liste steht, stammt von einem Theme oder Plugin, das nicht mehr aktiv ist, und wp media regenerate erzeugt sie nicht neu. Die Standardwerte unter Einstellungen > Medien stammen aus dem Installationsschema: thumbnail 150 x 150 beschnitten, medium 300 x 300, medium_large 768 breit ohne Höhenbegrenzung und large 1024 x 1024. Setzen Sie auf dieser Seite Breite und Höhe auf 0, erzeugt der Core diese Größe für neue Uploads nicht mehr.

#Gesamtgröße der Mediathek per PHP ermitteln

Wie viel Platz die Originale belegen, ermitteln Sie mit einer kleinen Funktion, die die Dateigrößen aller Bildanhänge summiert und das Ergebnis ins Fehlerprotokoll schreibt. Zwischengrößen zählt sie nicht mit, nur die Datei aus _wp_attached_file:

function log_image_sizes() {
    $args = [
        'post_type' => 'attachment',
        'post_mime_type' => 'image',
        'posts_per_page' => -1,
    ];
    
    $images = get_posts($args);
    $total_size = 0;
    $count = 0;
    
    foreach ($images as $image) {
        $file = get_attached_file($image->ID);
        if (file_exists($file)) {
            $total_size += filesize($file);
            $count++;
        }
    }
    
    error_log("Total images: $count, Total size: " . size_format($total_size));
}

#10. Ordnerstruktur für WordPress-Uploads ändern

Standardmäßig legt WordPress Uploads in Jahres- und Monatsordnern ab (wp-content/uploads/2026/10/). Das Kontrollkästchen unter Einstellungen > Medien, das Uploads in Monats- und Jahresordner einsortiert, steuert die Option uploads_use_yearmonth_folders, die bei einer frischen Installation auf 1 steht. Deaktivieren Sie es, betrifft das nur neue Uploads: Vorhandene Dateien behalten ihre Pfade, weil der Pfad pro Anhang in _wp_attached_file gespeichert ist.

Der Filter upload_dir bestimmt, wo neue Dateien landen. Er erhält ein Array mit path, url, subdir, basedir, baseurl und error, und Sie ändern subdir zusammen mit path und url:

declare(strict_types=1);

namespace WPPoland\Performance\Uploads;

/**
 * Speichert PDF-Uploads in /uploads/documents/ statt in den Datumsordnern.
 */
function route_pdf_uploads( array $uploads ): array {
    $name = $_FILES['async-upload']['name'] ?? '';

    if ( ! str_ends_with( strtolower( $name ), '.pdf' ) ) {
        return $uploads;
    }

    $uploads['subdir'] = '/documents';
    $uploads['path']   = $uploads['basedir'] . $uploads['subdir'];
    $uploads['url']    = $uploads['baseurl'] . $uploads['subdir'];

    return $uploads;
}
add_filter( 'upload_dir', __NAMESPACE__ . '\\route_pdf_uploads' );

Die Mediathek im Core kennt keine Ordner. Die Ordneransicht, die manche Plugins ergänzen, ist eine Taxonomie auf dem Beitragstyp attachment. Sie liegt also in der Datenbank und verschiebt keine Dateien auf der Platte. Bauen Sie eine solche Taxonomie selbst mit register_taxonomy( 'media_folder', 'attachment', ... ), verwenden Sie _update_generic_term_count als Callback für die Zählung: Der Standardzähler zählt einen Anhang nur über einen veröffentlichten übergeordneten Beitrag, nicht zugeordnete Dateien tauchen in der Begriffszählung also nie auf.

#11. Alternativtext in der WordPress-Mediathek verwalten

Das Feld für den Alternativtext in der Mediathek wird im Post-Meta _wp_attachment_image_alt gespeichert. wp_get_attachment_image() liest es bei jeder Ausgabe neu (nach trim() und strip_tags()), daher übernehmen Beitragsbilder und Theme-Templates, die diese Funktion nutzen, einen geänderten Wert sofort.

Der Bild-Block verhält sich anders. Sein alt-Attribut stammt aus dem alt-Attribut des <img> im gespeicherten Beitragsinhalt. Der Block kopiert den Wert aus der Mediathek also beim Einfügen und behält danach seine eigene Kopie. Wer den Alternativtext in der Mediathek korrigiert, aktualisiert damit keine Beiträge, die das Bild bereits enthalten; dort muss der Block selbst bearbeitet werden.

Eine Prüfabfrage findet Bilder ohne Alternativtext (passen Sie das Präfix wp_ an Ihre Installation an):

wp db query "SELECT p.ID, p.post_title FROM wp_posts p
  LEFT JOIN wp_postmeta m ON m.post_id = p.ID AND m.meta_key = '_wp_attachment_image_alt'
  WHERE p.post_type = 'attachment' AND p.post_mime_type LIKE 'image/%'
  AND (m.meta_value IS NULL OR m.meta_value = '')"

# Alternativtext für einen Anhang setzen
wp post meta update 1874 _wp_attachment_image_alt "Two developers reviewing a staging site on a laptop"

Ein leeres Ergebnis ist nicht automatisch das Ziel. Laut Entscheidungsbaum des W3C für Alternativtexte bekommt ein rein dekoratives Bild, oder eines, dessen Text bereits als echter Text daneben steht, ein leeres alt-Attribut. Schreiben Sie Alternativtexte für Bilder, die Information tragen, und beschreiben Sie bei Bildern, die als Link oder Button dienen, deren Funktion.

#12. upload_max_filesize für WordPress erhöhen

Die maximale Upload-Dateigröße, die der Uploader anzeigt, kommt aus wp_max_upload_size(). Die Funktion liest zwei PHP-Einstellungen, upload_max_filesize und post_max_size, nimmt den kleineren Wert und reicht ihn durch den Filter upload_size_limit. Derselbe Wert geht als max_file_size an den Uploader im Browser, sodass eine zu große Datei abgelehnt wird, bevor sie überhaupt gesendet wird.

Das PHP-Handbuch nennt als Standardwerte 2M für upload_max_filesize und 8M für post_max_size und kennzeichnet beide als INI_PERDIR. Das hat eine praktische Folge: ini_set() in der wp-config.php kann sie nicht erhöhen. Setzen Sie die Werte in der php.ini, in einer .user.ini, in der Pool-Konfiguration von PHP-FPM oder (bei Apache mit mod_php) in der .htaccess, und halten Sie post_max_size größer als upload_max_filesize, weil das Handbuch es so verlangt.

; .user.ini im WordPress-Stammverzeichnis (PHP-FPM / CGI)
upload_max_filesize = 16M
post_max_size = 20M

Die PHP-Grenzen anzuheben ist nur die halbe Arbeit. Die andere Hälfte besteht darin, Redakteure davon abzuhalten, den neuen Spielraum für 12-Megapixel-Originale aus der Kamera zu nutzen. Der Filter upload_size_limit kann die wirksame Grenze in der Praxis nur senken (PHP verwirft alles über seiner eigenen Einstellung, bevor WordPress läuft), und er eignet sich besser für die 1,5-MB-Regel aus Abschnitt 8, weil der Uploader dann die tatsächliche Grenze anzeigt:

add_filter( 'upload_size_limit', static fn ( int $size ): int => min( $size, 1536 * KB_IN_BYTES ) );

Bei Multisite gibt es eine dritte Grenze. Die Netzwerkeinstellung für die maximale Upload-Dateigröße wird in der Site-Option fileupload_maxk gespeichert, ohne Änderung 1500 KB, und der Core wendet sie über denselben Filter an, zusammen mit dem verbleibenden Upload-Kontingent der Website.

#13. 90-Tage-Plan für die Bildoptimierung in WordPress

Mit diesem Zeitplan optimieren und überwachen Sie die Medien Ihrer Website:

• Tag 1 bis 30 (sofortige Konfiguration): Prüfen Sie die PHP-Module Ihres Servers auf native AVIF- und WebP-Unterstützung. Richten Sie in der functions.php Qualitätsfilter ein, die die Kompression je Format festlegen. Nehmen Sie Hero-Elemente im sichtbaren Bereich vom Lazy Loading aus und setzen Sie Hooks für hohe Ladepriorität, um den Largest Contentful Paint (LCP) zu verbessern.
• Tag 31 bis 60 (Größen ausdünnen und regenerieren): Ermitteln Sie ungenutzte Bildgrößen des Themes und melden Sie sie über den Hook intermediate_image_sizes_advanced ab, um Speicherplatz zu sparen. Schreiben Sie einen PHP-Filter, der große Uploads an der Servergrenze ablehnt, und stimmen Sie upload_size_limit darauf ab. Führen Sie die Prüfabfrage für Alternativtexte aus und korrigieren Sie Bilder, die Information tragen. Erzeugen Sie die vorhandenen Thumbnails per WP-CLI mit den neuen Qualitätsprofilen neu.
• Tag 61 bis 90 (Skalierung und Auslagerung in die Cloud): Migrieren Sie die Mediathek in einen S3- oder R2-Object-Storage und lassen Sie lokale Quelldateien per Konfiguration entfernen. Richten Sie eine eigene, cookiefreie CDN-Subdomain mit passenden CORS- und Cache-Control-Headern ein und prüfen Sie die Verbesserungen in der Search Console.

Sie möchten eine eigene Pipeline für die Medienoptimierung aufbauen oder das Auslagern auf S3 einrichten? Unser Team für WordPress-Geschwindigkeitsoptimierung prüft Ihre Mediathek, kompiliert Serverpakete und konfiguriert Edge-CDNs. Kontaktieren Sie uns, um Ihr Projekt zu besprechen. Weitere Hintergründe finden Sie im Leitfaden zur WordPress-Optimierung.