Select Page

⚠️ Warnung: Wenn deine WordPress-Entwicklungsumgebung mit Docker auf Windows über 5 Sekunden pro Seitenladen braucht — dieser Guide wird dir 90% deiner Ladezeit sparen. Ohne Plugin-Konflikte. Ohne Kompromisse.

The Ultimate Fix: Repairing Extremely Slow WordPress in Docker on Windows

Wenn du eine WordPress-Site mit Docker auf einem Windows-Rechner entwickelst, kennst du wahrscheinlich diesen frustrierenden Moment: Deine Hardware bietet 16 CPUs, 32 GB RAM und blitzschnelle NVMe-SSDs — doch ein simpler Seitenaufruf dauert 5, 10 oder sogar 15 Sekunden.

Du weist mehr Ressourcen in Docker Desktop zu. Du installierst Cache-Plugins. Doch nichts hilft. Das Problem liegt weder an deiner Hardware noch an deinem Code — sondern an einem architektonischen Engpass zwischen Windows und Linux.

Das Problem: Der NTFS-Übersetzungs-Bottleneck

Warum tausende Dateizugriffe die Performance killen

Eine moderne WordPress-Installation — besonders in Kombination mit komplexen Page Buildern wie Divi oder zahlreichen Plugins — lädt Hunderte von kleinen PHP-, CSS- und JS-Dateien pro Seitenanfrage. Jeder Mal, wenn der Webserver eine dieser Dateien anfordert, muss Docker diese Anforderung über die Grenze hinweg übersetzen:

Linux-Container (ext4) ←→ Windows-Host (NTFS)

Diese Translation-Schicht ist mikroskopisch langsam. Multipliziert mit Tausenden von Dateizugriffen pro Seitenladevorgang — und die Performance kollabiert vollständig.

Weder CPU noch RAM können durch diesen rein software-basierten Engpass hinweg wegbrute-forceieren.

Die perfekte Lösung: Native WSL2-Architektur von Grund auf

Um diese Übersetzungsschicht vollständig zu eliminieren, müssen die Projektdateien nicht mehr auf der Windows-Partition reside. Stattdessen müssen sie direkt im native Linux-Dateisystem des Windows Subsystem for Linux (WSL2) operieren.

Schritt 1: Echte Linux-Umgebung installieren (WSL2 & Ubuntu)

docker wordpress performance issue

Zuerst benötigst du eine vollständige Linux-Umgebung auf Windows:

  1. Windows PowerShell als Administrator öffnen.
  2. Führe diesen Befehl aus, um WSL und das Standard-Ubuntu-Image zu installieren:

wsl --install -d Ubuntu

Starte deinen Computer nach der Installation neu.

Nach dem Neustart öffnet sich ein terminalbasierter Bildschirm, in dem du deinen gewünschten Linux-Benutzernamen und -passwort einrichten kannst.

Schritt 2: Docker Desktop mit Ubuntu verbinden

Standardmäßig verwendet Docker Desktop seine eigenen isolierten, minimalen Distributionen. Wir müssen der Anwendung sagen, dass sie sich mit deiner neuen Ubuntu-Umgebung verbinden soll.

  1. Öffne die Docker Desktop-Anwendung auf Windows.
  2. Klicke auf das Zahnrad-Symbol (Settings) in der oberen rechten Ecke.
  3. Navigiere im linken Menü zu Resources → WSL Integration.
  4. Aktiviere die Option "Enable integration with my default WSL distro".
  5. Schalte den Schalter für Ubuntu auf ON.
  6. Klicke unten rechts auf Apply & restart.

Ab jetzt ist der Docker-Engine nahtlos in dein Linux-Dateisystem integriert.

Schritt 3: Projekt in das Linux-Dateisystem verschieben

Deine Projektdateien können nicht mehr in Pfaden wie C:\\Projects liegen. Sie gehören in das Home-Verzeichnis deines Linux-Benutzers.

  1. Öffne das Ubuntu-Terminal aus dem Windows Startmenü.
  2. Navigiere zu deinem persönlichen Benutzer-Verzeichnis:

cd ~

  1. Öffne den Windows Explorer direkt von Linux heraus mit diesem Befehl (achte auf den Punkt am Ende):

explorer.exe .

Ein Windows-Fenster öffnet sich, das den Linux-Pfad anzeigt (z.B. \\wsl.localhost\Ubuntu\home\dein-benutzername).

💡 Wichtig: Kopiere deinen gesamten WordPress-Projektordner von deinem Windows-Laufwerk in dieses Fenster.

Du solltest die Berechtigungen setzen:

sudo chown -R 33:33 ~/yourpath/wordpress/html
sudo chown -R 999:999 ~/yourpath/wordpress/db

Schritt 4: Relative Pfade in docker-compose.yml verwenden

Da die Dateien nun nativ im Linux-System reside, benötigt deine docker-compose.yml keine absoluten Windows-Pfade oder /mnt/c/-MOUNTS mehr. Du kannst saubere, relative Pfade verwenden:

services:
  wordpress:
    image: wordpress:latest
    ports:
      - "80:80"
    volumes:
      # Direkt in den lokalen Unterordner in Linux
      - ./wordpress/html:/var/www/html
      - ./wordpress/php.ini:/usr/local/etc/php/conf.d/uploads.ini

In deinem Ubuntu-Terminal navigiere zu deinem Projektordner und starte die Container:

cd ~/your-project-folder
docker compose up -d

Schritt 5 (optional): Die Berechtigungs-Falle umgehen (403 Forbidden)

Nach dem Kopieren von Dateien über den Windows Explorer weist Apache manchmal Zugriff mit einem 403 Forbidden-Fehler blockiert. Das passiert, weil Windows den lokalen Linux-Benutzer oder root als Eigentümer der Dateien zuweist. Allerdings läuft der Apache-Webserver im offiziellen WordPress-Container unter dem strikt isolierten Systembenutzer www-data.

Die drei Befehle zur Berechtigungsfix

  1. Eigentum an den Apache-Benutzer übertragen:

docker compose exec wordpress chown -R www-data:www-data /var/www/html

  1. Standard-Verzeichnis-Berechtigungen (755) setzen:
docker compose exec wordpress find /var/www/html -type d -exec chmod 755 {} \;

  1. Standard-Datei-Berechtigungen (644) setzen:
docker compose exec wordpress find /var/www/html -type f -exec chmod 644 {} \;

Das Ergebnis

Sofortige Antwortzeiten, wie von einem echten Linux-Produktionsserver

Sobald die Berechtigungen korrekt sind und die Dateien direkt vom native ext4-Dateisystem von WSL2 bedient werden, verschwindet die Translationsschicht vollständig.

Der Docker-Engine greift ohne Verzögerung auf die Dateien zu und nutzt deine Systemressourcen optimal. Lokale Seitenladevorgänge, Backend-Interaktionen und Plugin-Aktivierungen reagieren sofortig — genau so wie du von einem dedizierten Linux-Produktionsserver erwarten würdest.

Zusammenfassung & SEO-Fazit

  • Haupt-Problem: NTFS ↔ ext4 Translation Layer bei Docker Bind Mounts
  • Lösung: Volle WSL2-Integration + Ubuntu als Linux-Distribution
  • Dateien: Verschiebe Projekte in das native Linux-Dateisystem (\\wsl.localhost)
  • Pfade: Nutze relative Pfade statt absoluter Windows-Pfade (/mnt/c/)
  • Berechtigungen: Fix mit chown www-data:www-data und chmod 755/644


Die Translationsschicht zwischen Windows (NTFS) und Linux (ext4) ist der unsichtbare Performance-Killer — und WSL2 ist die einzige echte Lösung.