PHP Apache vs NGINX für WordPress

Executive Summary

Für WordPress ist die Frage „Apache oder NGINX?“ selten ein reines Geschwindigkeits‑Duell. In der Praxis entscheidet meistens, wie viel Traffic du ohne PHP/MySQL ausliefern kannst (Caching), wie sauber Permalinks/Redirects umgesetzt sind, und wie gut dein Setup in der Realität wartbar bleibt (Updates, Plugins, Team‑Workflows, Hosting‑Einschränkungen). WordPress selbst empfiehlt sowohl Apache als auch NGINX als robuste Server für WordPress und nennt aktuell (Stand Februar 2026) als empfohlene Basis u. a. PHP 8.3+ sowie aktuelle Datenbankversionen und HTTPS. [1]

Die Kernabgrenzung für WordPress‑Alltag lautet:

• Apache spielt seine Stärken aus, wenn du (oder deine Plugins) .htaccess nutzen: Per‑Directory‑Regeln für Permalinks, Redirects, Zugriffsschutz, Header – oft ohne Root‑Zugriff und ohne „Server neu laden“. WordPress nutzt .htaccess u. a. für „pretty permalinks“ und erwähnt explizit, dass Plugins die Datei auch beschädigen können. [2]
• NGINX ist für WordPress besonders stark, wenn du konsequent auf PHP‑FPM plus FastCGI‑Page‑Cache bzw. Reverse‑Proxy‑Caching setzt und viele Requests als bereits gerenderte HTML‑Antworten liefern kannst. WordPress betont dabei zentral: NGINX hat keine .htaccess‑Funktionalität, alles ist serverseitig zu konfigurieren, und WordPress kann Regeln nicht automatisch erzeugen oder anpassen. [3]

Zwei aktuelle WordPress‑Messreihen (2025–2026) zeigen zudem ein sehr typisches Muster: ohne Cache sind Unterschiede zwischen Apache und NGINX oft moderat; mit FastCGI‑Cache können Durchsatz und Latenz massiv besser werden – weil PHP/MySQL für viele Seitenaufrufe komplett umgangen wird. [4]

Kurz-Zusammenfassung

(Abstract)

Apache und NGINX funktionieren beide sehr gut mit WordPress – aber sie „passen“ zu unterschiedlichen Betriebsrealitäten. Apache ist im WordPress‑Ökosystem extrem kompatibel, weil .htaccess ein Standard‑Weg ist, Permalinks, Redirects und Sicherheits‑Regeln pro Verzeichnis zu verwalten. WordPress nutzt diese Mechanik selbst und nennt sogar den Fall, dass Plugins .htaccess beschädigen können. [2]

NGINX ist dagegen ein Setup, das mehr Infrastruktur‑Denken verlangt: Permalinks werden nicht „automatisch“ über .htaccess erzeugt, sondern müssen zentral im Server‑Block (z. B. via try_files) korrekt definiert werden. Gleichzeitig ist NGINX als Event‑/Worker‑Architektur sehr effizient bei vielen gleichzeitigen Verbindungen und eignet sich hervorragend, um Caching‑Schichten (FastCGI‑Cache, Reverse‑Proxy‑Cache, CDN) konsequent nach vorne zu ziehen. [3]

Wenn du WordPress als Website/Blog mit typischen Plugins (SEO, Security, Social‑Autoposting) betreibst, entscheidet die „beste“ Wahl weniger ideologisch, sondern nach drei Fragen:
Welche Regeln/Plugins hängen an .htaccess? Welche Inhalte sind dynamisch (Login, Formulare, ggf. Shop) und dürfen nicht gecacht werden? Und wie viel Traffic kann (und darf) wirklich am PHP vorbei ausgeliefert werden? Benchmarks 2025–2026 illustrieren, dass genau hier der größte Performance‑Hebel liegt. [4]

Artikel

(ausführlich)

Schlüsselwörter
WordPress, Apache, NGINX, .htaccess, server blocks, PHP‑FPM, mod_proxy_fcgi, FastCGI cache, Reverse Proxy, CDN, Core Web Vitals (LCP/INP/CLS), WP‑Cron, Caching, SEO, Sicherheit, Shared Hosting, Managed Hosting. [5]

Einführung
WordPress ist eine PHP‑Anwendung, die für eine einzelne „Seitenanfrage“ oft mehrere Ebenen berührt: Webserver nimmt die Anfrage an, PHP‑Runtime rendert, WordPress lädt Core/Theme/Plugins, Datenbankabfragen laufen, danach wird HTML ausgeliefert. Für SEO‑ und Performance‑Wirkung zählen am Ende gemessene Nutzer‑Signale wie Core Web Vitals; Google beschreibt diese Metriken (LCP, INP, CLS) als messbare Indikatoren und verweist auf Mess‑/Debug‑Tooling. [6]

In typischen WordPress‑Setups (Website/Blog) sind große Teile der Seiten für nicht eingeloggte Besucher identisch. Genau deshalb kann serverseitiges Page‑Caching – also HTML aus Cache ausliefern – die Last drastisch reduzieren. WordPress dokumentiert für NGINX sogar konkrete Muster, wie FastCGI‑Caching zu konfigurieren ist und welche Bereiche man unbedingt ausschließen sollte (Admin, Login‑Cookies, XML‑RPC, Feeds, Sitemaps etc.). [7]

Methodik
Diese Bewertung kombiniert (i) Primärquellen von WordPress/Apache/NGINX/PHP/G oogle, (ii) aktuelle Marktdaten zur realen Verbreitung, (iii) konkrete WordPress‑Benchmarks 2025–2026 mit „ohne Cache“ vs. „mit FastCGI‑Cache“, sowie (iv) Hosting‑Realität aus Control‑Panel‑/Provider‑Dokus (Reverse‑Proxy‑Betrieb, Caching‑Layer). Die Marktdaten beziehen sich auf den Stichtag 21.02.2026. [8]

Ergebnisse

Vergleichstabelle

Kompatibilität: .htaccess vs. server blocks ist in WordPress ein echter Unterschied

WordPress dokumentiert für Apache: .htaccess ist eine verteilte Konfigurationsdatei, die WordPress aktiv nutzt, insbesondere für „pretty permalinks“, und es gibt sogar einen Mechanismus zum „Restore“, falls ein Plugin .htaccess beschädigt. [2]

Für NGINX dokumentiert WordPress dagegen mehrere harte Konsequenzen: Es gibt keine Verzeichnis‑Konfiguration wie .htaccess; alles muss auf Server‑Ebene durch Admins erfolgen; WordPress kann das nicht automatisch anpassen; Rewrite‑Regeln werden nicht generiert; ohne Anpassungen taucht index.php in Permalinks auf. [9]

Für WordPress‑Teams heißt das sehr konkret: Wenn du heute Redirect‑Regeln, Header‑Policies oder Zugriffsschutz via .htaccess (oder über Plugins, die dort schreiben) etablierst, musst du bei NGINX diese Governance‑Schicht verlagern: von „pro Projekt im Dateisystem“ zu „zentral im Server‑Block“. [21]

Performance: Warum WordPress‑Caching fast immer mehr zählt als „Apache vs NGINX“

Architektur‑Grundlage (NGINX): NGINX beschreibt einen Master‑Prozess, der Konfiguration liest/auswertet und Worker verwaltet; Worker erledigen Requests in einem event‑basierten Modell. Reload (SIGHUP/nginx -s reload) startet neue Worker mit neuer Konfiguration und lässt alte Worker die laufenden Requests sauber beenden. [22]

Architektur‑Grundlage (Apache, modern): Apache dokumentiert Multi‑Processing‑Module (MPMs); der event‑MPM ist darauf ausgelegt, mehr gleichzeitige Requests bedienen zu können, indem Arbeit auf Listener‑Threads verteilt wird. Außerdem beschreibt Apache für 2.4, dass der Standard‑MPM „event“ ist (als Default‑MPM austauschbar per LoadModule). [23]

Praktisch bedeutet das: In heutigen WordPress‑Setups ist es weniger „Apache kann keine Concurrency“ vs „NGINX kann Concurrency“, sondern eher: Wie gut sind PHP‑FPM, Page‑Cache und statische Auslieferung gelöst? WordPress selbst dokumentiert FastCGI‑Caching als starke Option unter NGINX sowie typische Excludes (POST, Query‑Strings, Admin, Login‑Cookies etc.). [7]

Performance‑Benchmarks 2025–2026

Die folgenden Zahlen sind nicht „universelle Wahrheiten“, sondern aussagekräftige Beispiele, weil sie WordPress unter realistischen Mustern „ohne Cache vs. mit FastCGI‑Cache“ messen und damit genau die typische WordPress‑Hebelwirkung zeigen. [24]

Sicherheit: Zentral vs. „verteilte“ Regeln und typische WordPress‑Angriffsflächen

WordPress‑Hardening empfiehlt u. a. stärkere Dateirechte und adressiert die besondere Rolle von wp-config.php; das gehört zur Basis‑Hygiene unabhängig davon, ob Apache oder NGINX verwendet wird. [29]

Auf Server‑Ebene ist ein sehr realer WordPress‑Angriffsvektor, dass Upload‑Verzeichnisse missbraucht werden können. WordPress dokumentiert in seiner NGINX‑Konfigurationssammlung explizit eine Regel, die den Zugriff auf .php‑Dateien in Uploads/Files‑Verzeichnissen verweigert, und warnt außerdem: Tippfehler in globalen Restriktionsdateien können Schlupflöcher erzeugen; man soll Upload‑PHP‑Ausführung aktiv testen. [30]

Auf Apache‑Seite ist die Kehrseite der Flexibilität, dass .htaccess nicht nur performance‑relevant sein kann, sondern auch die Regeln „verstreut“ sind: Apache selbst weist darauf hin, dass bei erlaubtem AllowOverride der Server in jedem Verzeichnis nach .htaccess sucht und diese Datei bei jeder Anfrage lädt (Performance‑Hit unabhängig davon, ob sie genutzt wird). [31]

Für WordPress bedeutet diese Kombination:
Ein NGINX‑Setup hat weniger „Plugin schreibt Serverregeln“ (weil WordPress das nicht kann), aber es verlagert Sicherheit stark in die zentrale Ops‑Konfiguration. Apache‑Setups sind oft „self‑service‑fähig“ (Shared Hosting), aber im Team‑Betrieb steigt die Gefahr, dass unterschiedliche Projekte durch .htaccess‑Änderungen inkonsistent werden oder im Worst Case eine .htaccess‑Korruption den Betrieb stört. [32]

Betrieb und Markt: Was wird tatsächlich häufig eingesetzt?

WordPress unterstützt NGINX und nennt explizit, dass NGINX auch als Reverse Proxy vor Apache eingesetzt werden kann; außerdem weist WordPress darauf hin, dass viele Sites, die „NGINX im Header“ melden, tatsächlich Apache hinter einem NGINX‑Reverse‑Proxy sind. [10]

Panel‑/Hosting‑Dokus bestätigen genau dieses Muster: entity[„company“,“cPanel & WHM“,“hosting control panel“] erklärt, dass deren „NGINX with reverse proxy“ dynamische Inhalte via Proxy an Apache übergibt und Caching nutzt, um Inhalte schneller auszuliefern. [15]

Auch Plesk[33] beschreibt NGINX als Reverse‑Proxy‑Frontend zwischen Internet und Apache, mit dem Ziel, statische Inhalte effizient zu bedienen und die Anzahl gleichzeitiger Verbindungen zu erhöhen; zugleich erklärt Plesk, dass Apache weiterhin URL‑Rewrite/.htaccess‑Logik anwenden kann und NGINX die Datei dann ausliefert. [13]

Als Markt‑Kontext (nicht WordPress‑spezifisch, aber relevant für Hosting‑Realität): W3Techs weist für den Stichtag 21.02.2026 NGINX mit rund 32,8 % und Apache mit rund 24,2 % (unter Websites mit bekanntem Webserver) aus. [34]

SEO: Warum der Webserver indirekt zählt (Core Web Vitals)

Google beschreibt Core Web Vitals (LCP, INP, CLS) und verweist auf Mess‑Mechanismen und Search‑Console‑Reports; außerdem wurde INP als Reaktions‑Metrik eingeführt und ersetzt FID im Core‑Web‑Vitals‑Kontext (März 2024). [6]

Für WordPress heißt das: „Apache vs NGINX“ ist kein direkter Ranking‑Faktor, aber die Wahl beeinflusst indirekt, wie stabil du TTFB/Server‑Antwortzeiten und damit deine Messwerte hältst – besonders unter Lastspitzen (Social‑Traffic, virale Posts). Benchmarks aus 2025–2026 zeigen, dass serverseitiges Page‑Caching den größten Effekt auf Response‑Zeiten hat. [35]

Plugins, Social‑Autoposting und die WP‑Cron‑Realität

WP‑Cron ist WordPress’ System für zeitbasierte Aufgaben (Updates prüfen, geplante Posts veröffentlichen usw.). WordPress beschreibt explizit, dass WP‑Cron bei jedem Page Load prüft, welche Tasks „fällig“ sind, und fällige Tasks während dieses Page Loads ausführt. [36]

Für Social‑Autoposting‑Plugins (Post‑Verteilung, Re‑Shares, API‑Calls), SEO‑Plugins (Sitemap/Index‑Updates) und Security‑Plugins (Scans, Log‑Rotation, IP‑Checks) bedeutet das: Wenn solche Tasks stark getaktet sind oder langsam laufen, belasten sie die PHP‑Schicht und können – besonders ohne sauberes Caching – spürbare Latenz erzeugen. Gleichzeitig zeigen NGINX‑Caching‑Muster in WordPress‑Dokus und in 2026‑Benchmarks, dass, sobald Seiten aus Cache kommen, PHP‑Budget für genau solche Hintergrundlast frei wird. [37]

Diskussion

„Besser“ heißt in WordPress oft: Welche Governance passt zu deinem Betrieb?

Wenn du die Verantwortung für Server‑Konfiguration sauber zentralisieren kannst (DevOps/Root‑Zugriff, Staging‑Testing, CI‑Deploys), ist NGINX für WordPress häufig „besser“ im Sinne von: klare Regeln, starke Caching‑Optionen, effiziente Concurrency‑Handhabung. WordPress’ NGINX‑Handbuch zeigt nicht nur Rewrite‑Grundlagen (try_files), sondern auch Sicherheits‑Restriktionen (z. B. deny PHP in Uploads) und Cache‑Purge‑Mechanismen (FastCGI‑Purge‑Modul + Plugin), was die typische Produktions‑Denke widerspiegelt. [38]

Wenn du dagegen in Shared‑Hosting‑Realität steckst oder Teams ohne Root‑Zugriff arbeiten, ist Apache oft „besser“, weil .htaccess genau für diesen Anwendungsfall gedacht ist (Konfiguration ohne Zugriff auf Hauptkonfig). Gleichzeitig dokumentiert Apache die Performance‑Nachteile: AllowOverride/.htaccess führt dazu, dass pro Request mehrere Verzeichnisse nach .htaccess durchsucht und Dateien jeweils neu geladen werden. Das ist ein klassischer WordPress‑Trade‑off: maximale Flexibilität vs. maximale Effizienz. [39]

Was Hostings in der Praxis häufig tun: Hybrid‑Setups

Ein sehr verbreiteter „Kompromiss mit echten Vorteilen“ ist das Hybrid‑Setup: NGINX als Reverse‑Proxy‑Frontend mit Caching und statischer Auslieferung, Apache als Backend (inkl. .htaccess‑Kompatibilität). WordPress beschreibt Reverse‑Proxy‑Betrieb als „sehr mächtig“ und betont, dass Header‑Statistiken dadurch irreführend sein können. [10]
cPanel und Plesk dokumentieren dieses Modell ebenfalls explizit. [18]
Als konkretes Hoster‑Beispiel: SiteGround[40] nennt NGINX als Reverse‑Proxy‑Server, der statische Ressourcen cached und schneller ausliefert. [41]

Eigene Bewertung (praxisnah, WordPress‑fokussiert)

Für typische WordPress‑Sites (Website/Blog, SEO‑Plugin, Security‑Plugin, Social‑Autoposting) halte ich folgende Entscheidungsregel für die robusteste:

• Wenn du nicht sicherstellen kannst, dass NGINX‑Regeln (Permalinks, Redirects, Security‑Blocklisten, Cache‑Excludes) sauber zentral gepflegt und getestet werden, ist Apache als „default‑sicherer“ Betrieb (weniger infra‑Setup‑Fehler) oft der bessere Start – auch wenn es nicht maximal effizient ist. [42]
• Wenn du sauber „infra‑geführt“ arbeitest (Staging, Logs, strukturierte Deploys) und deine Site überwiegend „Gast‑Traffic“ hat, ist NGINX + FastCGI‑Cache sehr häufig die bessere WordPress‑Antwort – weil Benchmarks zeigen, dass Caching die Performance‑Kurve fundamental verändert. [43]
• Wenn du eine „echte“ Shared‑Hosting/Panel‑Welt hast, ist die Hybrid‑Variante oft faktisch das, was du ohnehin bekommst – und häufig auch das, was du willst. [44]

Praxis‑Teil: Schritt‑für‑Schritt Migration Apache → NGINX (WordPress‑fokussiert)

Die Migration scheitert in WordPress selten an PHP selbst, sondern an „Klebstoff“: Permalinks, Redirects, .htaccess‑Security‑Regeln, Cache‑Header, und an Plugins, die erwarten, dass sie Serverregeln ändern dürfen. WordPress dokumentiert für NGINX klar, dass WordPress keine serverseitigen Regeln generiert und .htaccess nicht existiert. [9]

Pre‑Migration: Verifizieren, was du heute wirklich nutzt

WP‑Cron‑Begründung: WordPress beschreibt den Mechanismus explizit als „checkt auf jedem Page Load“ und führt fällige Tasks dann aus. [36]

.htaccess‑Regeln auf NGINX abbilden: typische Muster

Basissnippets (minimal, als Startpunkt)

NGINX server block (WordPress, Permalinks, PHP‑FPM, Upload‑Hardening):

server {
listen 80;
server_name example.com;
root /var/www/example.com/public;

index index.php;

location / {
try_files $uri $uri/ /index.php?$args;
}

location ~ \.php$ {
include fastcgi.conf;
fastcgi_pass unix:/run/php/php8.3-fpm.sock;
}

# Uploads: keine PHP-Ausführung
location ~* /(?:uploads|files)/.*\.php$ { deny all; }
}

Die try_files‑Logik und das Upload‑Hardening sind in WordPress’ NGINX‑Konfigurationsbeispielen dokumentiert. [20]

Apache → PHP‑FPM via mod_proxy_fcgi (Beispiel mit Unix‑Socket):

<FilesMatch „\.php$“>
SetHandler „proxy:unix:/run/php/php8.3-fpm.sock|fcgi://localhost/“
</FilesMatch>

Apache dokumentiert diese „Proxy via Handler“‑Variante in mod_proxy_fcgi und erläutert außerdem die Interaktion mit PHP‑FPM (inkl. Hinweise zu Connection Reuse und möglichen Timeout‑Szenarien bei falscher Dimensionierung). [46]

PHP‑FPM Pool (Beispiel; Werte sind lastabhängig):

[www]
user = www-data
group = www-data
listen = /run/php/php8.3-fpm.sock
listen.owner = www-data
listen.group = www-data
pm = dynamic
pm.max_children = 20
pm.start_servers = 4
pm.min_spare_servers = 2
pm.max_spare_servers = 6
pm.max_requests = 500

Zur Einordnung: PHP‑FPM wird als FastCGI Process Manager beschrieben und ist insbesondere für Websites mit hoher Last relevant; das PHP‑Handbuch verweist zudem auf Konfigurationsaspekte (z. B. nicht öffentlich bindende FPM‑Listener). [47]

Post‑Migration: Tests, die WordPress‑Realität abdecken

Die NGINX‑Warnung zum Testen der Upload‑Sperre und das konkrete Deny‑Muster sind in WordPress’ NGINX‑Handbuch dokumentiert. [30]

Abbildungen und Diagramme (online) – im DOCX bereits eingefügt
Im DOCX sind Diagramme eingebettet; hier die Originalquellen (Sprache jeweils genannt):

• Plesk‑Diagramm „Apache mit nginx“ (DE, Bild): https://docs.plesk.com/de-DE/onyx/administrator-guide/images/70996.png [48]
• NGINX „Worker‑Process / State Machine“ Infografik (EN, Bild): https://nginxblog-8de1046ff5a84f2c-endpoint.azureedge.net/blobnginxbloga72cde487e/wp-content/uploads/2015/06/infographic-Inside-NGINX_worker-process.png [49]
• NGINX „Reload ohne Downtime“ Infografik (EN, Bild): https://nginxblog-8de1046ff5a84f2c-endpoint.azureedge.net/blobnginxbloga72cde487e/wp-content/uploads/2015/06/infographic-Inside-NGINX_load-config-1.png [50]

Mermaid‑Diagramm: typische WordPress‑Architektur im Hybrid‑Betrieb

flowchart LR
U[User Browser] –>|HTTPS| CDN[CDN / Edge Cache]
CDN –>|Cache MISS| NRP[NGINX Reverse Proxy]
NRP –>|static assets| NRP
NRP –>|dynamic requests| AP[Apache Backend]
AP –>|FastCGI| FPM[PHP-FPM Pools]
FPM –> DB[(MySQL/MariaDB)]
AP –>|responses| NRP –> CDN –> U

Dieses Modell wird in der Praxis häufig durch Panel‑Setups beschrieben: z. B. cPanel spricht explizit von NGINX als Reverse Proxy, der dynamische Inhalte an Apache weitergibt; Plesk beschreibt ebenso NGINX als Frontend zwischen Internet und Apache. [18]

Conclusiones innerhalb Block B
WordPress‑Entscheidungen sollten nicht „Server‑Religion“ sein, sondern Betriebs‑ und Caching‑Strategie. WordPress selbst signalisiert Neutralität: Apache oder NGINX sind empfohlen, Hauptsache PHP/MySQL‑Support und moderne Versionen/HTTPS. [1]
In aktuellen WordPress‑Benchmarks zeigt sich aber: Page‑Caching (z. B. FastCGI‑Cache) ist meistens der dominante Faktor, weil es PHP und Datenbank weitgehend aus dem Hot‑Path nimmt. [35]
Für Teams ohne Root‑Zugriff und mit starkem .htaccess‑/Plugin‑Workflow bleibt Apache oft die pragmatischere Wahl, während NGINX (standalone oder als Reverse‑Proxy) besonders dann gewinnt, wenn du skalierbares Caching und saubere zentrale Konfiguration etablieren kannst. [51]

Finale Schlussfolgerung

Wenn du WordPress als Website/Blog mit typischen Plugins betreibst, gibt es keine „eine“ richtige Antwort – aber es gibt eine sehr robuste Praxis‑Empfehlung:

• Apache ist besser, wenn du ohne Root‑Zugriff arbeitest, .htaccess‑Regeln häufig brauchst oder Plugins/Workflows darauf angewiesen sind. WordPress nutzt .htaccess aktiv für Permalinks und nennt Plugin‑bedingte .htaccess‑Korruption als realen Fall. [19]
• NGINX ist besser, wenn du Leistung und Stabilität bei Concurrency/Traffic‑Spitzen priorisierst und bereit bist, zentrale Konfiguration sauber zu betreiben – besonders mit PHP‑FPM + FastCGI‑Cache und korrekten Excludes. WordPress dokumentiert hierzu klare Anforderungen und Sicherheits‑Warnings. [52]
• Hybrid ist oft am besten, wenn du sowohl Apache‑Kompatibilität (.htaccess) als auch NGINX‑Effizienz/Caching willst. WordPress nennt Reverse‑Proxy‑Betrieb ausdrücklich als mächtiges Setup; cPanel und Plesk beschreiben es als Standard‑Architektur. [53]

Referenzen

Zugriffdatum für alle Links: 21.02.2026 (Europe/Berlin).

• WordPress Requirements (EN): https://wordpress.org/about/requirements/ [1]
• WordPress Developer Resources – Apache HTTPD / .htaccess (EN): https://developer.wordpress.org/advanced-administration/server/web-server/httpd/ [2]
• WordPress Developer Resources – NGINX (EN): https://developer.wordpress.org/advanced-administration/server/web-server/nginx/ [54]
• WordPress Plugin Handbook – Cron / WP‑Cron (EN): https://developer.wordpress.org/plugins/cron/ [36]
• Apache HTTP Server – .htaccess Tutorial (EN): https://httpd.apache.org/docs/current/howto/htaccess.html [55]
• Apache HTTP Server – Performance Tuning / AllowOverride (EN): https://httpd.apache.org/docs/2.4/misc/perf-tuning.html [56]
• Apache HTTP Server – Performance Scaling / Default MPM event (EN): https://httpd.apache.org/docs/trunk/misc/perf-scaling.html [57]
• Apache HTTP Server – MPM event (EN): https://httpd.apache.org/docs/current/mod/event.html [58]
• Apache HTTP Server – mod_proxy_fcgi (EN): https://httpd.apache.org/docs/current/mod/mod_proxy_fcgi.html [46]
• NGINX – Beginner’s Guide (EN): https://nginx.org/en/docs/beginners_guide.html [17]
• NGINX Community Blog – Inside NGINX / Architektur (EN): https://blog.nginx.org/blog/inside-nginx-how-we-designed-for-performance-scale [59]
• NGINX – FastCGI Module Reference (EN): https://nginx.org/en/docs/http/ngx_http_fastcgi_module.html [60]
• Google Search – Core Web Vitals (DE): https://developers.google.com/search/docs/appearance/core-web-vitals?hl=de [61]
• Google Search Central Blog – Introducing INP (DE): https://developers.google.com/search/blog/2023/05/introducing-inp?hl=de [62]
• PHP Manual – PHP‑FPM (DE): https://www.php.net/manual/de/install.fpm.php [63]
• W3Techs – NGINX vs Apache usage (EN): https://w3techs.com/technologies/comparison/ws-apache%2Cws-nginx [34]
• SpinupWP – WordPress ohne Cache vs. mit NGINX FastCGI‑Cache Benchmark (EN, 2026): https://spinupwp.com/hosting-wordpress-yourself-server-monitoring-caching/ [64]
• Ostrich Blog – WordPress Benchmark Apache vs NGINX (EN, 2025): https://ostrich.kyiv.ua/en/2025/11/04/wordpress-benchmark-apache-vs-nginx/ [28]
• cPanel – NGINX with Reverse Proxy (EN): https://docs.cpanel.net/knowledge-base/nginx/nginx-with-reverse-proxy/ [15]
• Plesk – Apache mit nginx (DE): https://docs.plesk.com/de-DE/onyx/administrator-guide/webserver/apache-und-ngnixwebserver-linux/apache-mit-nginx.70837/ [13]
• SiteGround – Speed‑Stack (EN): https://world.siteground.com/kb/siteground-speed-website/ [41]
• Kinsta[65] – Architektur/Threads/Caching für WordPress (EN, 2026): https://kinsta.com/blog/kinsta-php-threads-caching-performance/ [66]

[1] [5] https://wordpress.org/about/requirements/

[2] [19] https://developer.wordpress.org/advanced-administration/server/web-server/httpd/

[3] [7] [9] [10] [14] [20] [21] [30] [32] [38] [42] [45] [51] [52] [53] [54] https://developer.wordpress.org/advanced-administration/server/web-server/nginx/

[4] [24] [28] https://ostrich.kyiv.ua/en/2025/11/04/wordpress-benchmark-apache-vs-nginx/

[6] [61] https://developers.google.com/search/docs/appearance/core-web-vitals?hl=de

https://developers.google.com/search/docs/appearance/core-web-vitals?hl=de

[8] [34] https://w3techs.com/technologies/comparison/ws-apache%2Cws-nginx

https://w3techs.com/technologies/comparison/ws-apache%2Cws-nginx

[11] [57] https://httpd.apache.org/docs/trunk/misc/perf-scaling.html

https://httpd.apache.org/docs/trunk/misc/perf-scaling.html

[12] [17] [22] https://nginx.org/en/docs/beginners_guide.html

https://nginx.org/en/docs/beginners_guide.html

[13] https://docs.plesk.com/de-DE/onyx/administrator-guide/webserver/apache-und-ngnixwebserver-linux/apache-mit-nginx.70837/

https://docs.plesk.com/de-DE/onyx/administrator-guide/webserver/apache-und-ngnixwebserver-linux/apache-mit-nginx.70837

[15] [18] [44] https://docs.cpanel.net/knowledge-base/nginx/nginx-with-reverse-proxy/

https://docs.cpanel.net/knowledge-base/nginx/nginx-with-reverse-proxy

[16] [31] [39] [55] https://httpd.apache.org/docs/current/howto/htaccess.html

https://httpd.apache.org/docs/current/howto/htaccess.html

[23] [25] [58] https://httpd.apache.org/docs/current/mod/event.html

https://httpd.apache.org/docs/current/mod/event.html

[26] [27] [33] [35] [40] [43] [64] https://spinupwp.com/hosting-wordpress-yourself-server-monitoring-caching/

[29] https://developer.wordpress.org/advanced-administration/server/file-permissions/

[36] [37] https://developer.wordpress.org/plugins/cron/

[41] https://world.siteground.com/kb/siteground-speed-website/

https://world.siteground.com/kb/siteground-speed-website

[46] https://httpd.apache.org/docs/current/mod/mod_proxy_fcgi.html

https://httpd.apache.org/docs/current/mod/mod_proxy_fcgi.html

[47] [63] https://www.php.net/manual/de/install.fpm.php

https://www.php.net/manual/de/install.fpm.php

[48] https://docs.plesk.com/de-DE/onyx/administrator-guide/images/70996.png

https://docs.plesk.com/de-DE/onyx/administrator-guide/images/70996.png

[49] https://nginxblog-8de1046ff5a84f2c-endpoint.azureedge.net/blobnginxbloga72cde487e/wp-content/uploads/2015/06/infographic-Inside-NGINX_worker-process.png

https://nginxblog-8de1046ff5a84f2c-endpoint.azureedge.net/blobnginxbloga72cde487e/wp-content/uploads/2015/06/infographic-Inside-NGINX_worker-process.png

[50] [65] https://nginxblog-8de1046ff5a84f2c-endpoint.azureedge.net/blobnginxbloga72cde487e/wp-content/uploads/2015/06/infographic-Inside-NGINX_load-config-1.png

https://nginxblog-8de1046ff5a84f2c-endpoint.azureedge.net/blobnginxbloga72cde487e/wp-content/uploads/2015/06/infographic-Inside-NGINX_load-config-1.png

[56] https://httpd.apache.org/docs/2.4/misc/perf-tuning.html

https://httpd.apache.org/docs/2.4/misc/perf-tuning.html

[59] https://blog.nginx.org/blog/inside-nginx-how-we-designed-for-performance-scale

[60] https://nginx.org/en/docs/http/ngx_http_fastcgi_module.html

https://nginx.org/en/docs/http/ngx_http_fastcgi_module.html

[62] https://developers.google.com/search/blog/2023/05/introducing-inp?hl=de

https://developers.google.com/search/blog/2023/05/introducing-inp?hl=de

[66] https://kinsta.com/blog/kinsta-php-threads-caching-performance/