Technologie

WordPress ausliefern ohne PHP

Ein WordPress-Seitenaufruf startet einen PHP-Worker. Der Worker lädt den WordPress-Kern, Ihr Theme und jedes aktive Plugin, öffnet eine Verbindung zu einem MySQL-Server, läuft durch den Loop und baut das meiste davon wieder ab. Das tut er bei jedem Request.

Ihre Website ist der Inhalt, das Theme, das ihn darstellt, und das Admin, mit dem Sie ihn bearbeiten. BookPress behält diese drei und ersetzt, was darunter läuft.

Der Auslieferungspfad ist eine Neuentwicklung in C++. Router, Block-Theme-Renderer, Query-Schicht und wp-admin sind nativer Code, kein PHP. PHP läuft nur für Ihre Themes und Plugins, auf der eigenen PHP-Engine von BookPress. Eine Website ohne Plugins erledigt ihre gesamte Arbeit, ohne PHP auszuführen.

Die Engine

• Zu nativem Code kompiliert. C++, gebaut für aktuelle Intel- und ARM-Linux-Server, mit handoptimiertem Request-Parsing und HTML-Erzeugung. Der WordPress-Kern läuft als nativer Code, Plugins laufen als PHP auf unserer eigenen Engine. Der ganze Server ist eine Binärdatei von 1,8 MB.
• Eingebetteter SQLite-Speicher. Die Datenbank ist SQLite, sie läuft im selben Prozess auf demselben WordPress-Schema. Inhaltsabfragen kommen in Mikrosekunden zurück, und kein Datenbankserver sitzt im Request-Pfad.
• Worker nach Maschine bemessen. Beim Start legt BookPress die Zahl seiner Worker nach Prozessoren und Arbeitsspeicher der Maschine fest. Ein von Ihnen gesetzter Wert hat Vorrang. Die Zahlen auf dieser Seite haben wir mit vier Workern gemessen.
• PHP beim Start kompiliert. BookPress kompiliert die PHP-Dateien einer Website beim Start und erneut, wenn sich eine Datei ändert. Der erste Besucher wartet nicht auf die Kompilierung.

Echtes Theme-Rendering

BookPress rendert WordPress-Block-Themes nativ. Es liest dieselben Template-Dateien, dasselbe Block-Markup und dieselbe theme.json und erzeugt das HTML und CSS, das WordPress erzeugt: globale Styles, Layout-Klassen, Schrift-Presets, fluide Typografie. Twenty Twenty-Five, das Standard-Theme von WordPress, rendert heute pixelnah aus seinen unveränderten Theme-Dateien, Webfonts eingeschlossen.

Das Admin folgt demselben Ansatz. /wp-login.php prüft Ihre vorhandenen WordPress-Passwort-Hashes. /wp-admin gibt Ihnen Dashboard, Beitragslisten und Editor, ausgeliefert von derselben Engine in derselben Geschwindigkeit.

Was wir verglichen haben: ein harter Test für BookPress

Wir nehmen eine echte Website: das Kadence-Theme mit WooCommerce, eine gebaute Elementor-Schaufensterseite, Yoast SEO und Contact Form 7. Wir migrieren denselben Inhalt in beide Engines, mit gleichen Zeilenzahlen in beiden Datenbanken. WordPress stimmen wir vor der Messung so ab, wie ein fähiger Hoster es täte: PHP 8.3.35 mit OPcache und eingeschaltetem JIT, ein Redis-Objekt-Cache über einen Socket, MariaDB und PHP-FPM hinter nginx, mit der neueren Bestellspeicherung von WooCommerce (HPOS) aktiv. Wir messen eine Seite erst, nachdem wir geprüft haben, dass WordPress und BookPress dieselbe Seite zeigen: dasselbe Elementor-Markup, dieselbe Produktseite, derselbe Shop-Katalog.

WordPress wird ohne Seiten-Cache gemessen, und wir prüfen vor der Messung, dass er aus ist, denn eine Seite, die ein Cache ausliefern kann, kommt bei beiden Setups aus dem Cache und misst nicht die Engine. Jede Zahl unten ist WordPress mit laufendem PHP, der Fall, den ein Warenkorb, eine Suche oder eine eingeloggte Sitzung immer trifft.

Die Server

Wir haben zwei Google-Cloud-Server genutzt, die jeder mieten und nachprüfen kann. Der Intel-Server ist ein c2-standard-4 mit 4 vCPUs (Intel Xeon mit 3,10 GHz, 2 physische Kerne mit je zwei Threads, 16 GB RAM). Der ARM-Server ist ein c4a-standard-4 mit 4 vCPUs (Google Axion, 4 physische Kerne, 16 GB RAM). Beide laufen mit Debian 12, und BookPress ist auf beiden gleich kompiliert.

Lesen Sie die beiden Kernzahlen, bevor Sie eine andere Zahl lesen. "4 vCPU" ist auf jeder Familie eine andere Menge Hardware, deshalb vergleichen wir eine ARM-Zahl nur mit einem WordPress auf demselben Server.

Das Ergebnis: mehr Requests pro Sekunde, auf beiden Servern

Wir haben jede Engine bis zu den meisten Requests pro Sekunde getrieben, die sie ausliefert, solange 99 % davon unter einer Sekunde bleiben und keiner fehlschlägt. Auf echten Shop-Seiten liefert BookPress etwa das 4,5-Fache der Requests pro Sekunde des optimierten WordPress auf dem Intel-Server und über das 5-Fache auf dem ARM-Server. Jede Zahl unten ist BookPress gegen WordPress auf demselben Server.

Gemessen auf Google Cloud c2-standard-4 (Intel) und c4a-standard-4 (Arm), dynamische Seiten ohne Cache, BookPress 0.2.64 (der paketierte Build, den Sie installieren) gegen WordPress 7.1.3 / PHP 8.3.35 mit nginx, PHP-FPM, Redis-Objekt-Cache, OPcache mit JIT und MariaDB.

Requests pro Sekunde gilt am Knickpunkt jeder Engine; p50 und p99 sind die Vielfachen der Median- und 99-Perzentil-Antwortzeit auf der Laststufe am Knickpunkt von WordPress, derselben Parallelität für beide. WordPress wird ohne Seiten-Cache gemessen.

Shop-Seiten bestehen überwiegend aus dem PHP des Plugins selbst, deshalb sind sie der härteste Fall. Anders als eine Seite ohne Plugins lassen sie sich nicht beantworten, ohne dieses PHP auszuführen. BookPress führt es auf seiner eigenen PHP-Engine aus, die auf diesen Seiten mit PHP 8.3.35 und dem JIT mithält oder es schlägt. Diese Seiten waren früher der schwache Fall, heute führt BookPress auf ihnen.

Eine Website ohne Plugins führt gar keinen PHP-Interpreter aus. Dort liefert BookPress das 112,9-Fache der Requests pro Sekunde von WordPress auf dem Intel-Server (5.234 gegen 46) und das 125-Fache auf dem ARM-Server (11.436 gegen 91), ohne installierte Plugins.

Seiten-Caches sind eine eigene Schicht

Ein Seiten-Cache liefert gespeichertes HTML aus, ohne etwas zu rendern, auf WordPress wie auf BookPress. Ein Cache-Treffer misst deshalb keine der beiden Engines. Jede Zahl auf dieser Website ist ein dynamisches Rendering ohne Cache auf beiden Stacks.

Einige klassische PHP-Themes. Die klassischen Templates von WordPress sind leichter als seine Block-Themes. Das Rendering klassischer Themes ist in BookPress jünger als der Block-Pfad, und einige der rund zwei Dutzend mitgelieferten klassischen Themes enden heute noch in einem Fehler. Die Behebung steht auf unserer Roadmap. Die Shop-Seiten oben sind Block-Themes.

Arbeitsspeicher

Der Arbeitsspeicher ist eine eigene, frühere Messung auf BookPress 0.2.57. Wir haben ihn auf beiden Servern nach einem vollen Lastlauf gemessen, auf derselben Website mit allen Plugins aktiv, wobei zwischen Prozessen geteilter Speicher einmal zählt.

Unter Last brauchten vier BookPress-Worker etwa 0,6 GB. Das ist ungefähr so viel wie ein passend dimensioniertes WordPress (8 PHP-Kindprozesse, 0,55 GB), das weniger Seiten ausliefert, und ein Drittel eines optimierten Pools mit 64 Kindprozessen (1,8 GB). Dreißig Sekunden nach Ende der Last fiel BookPress auf etwa 0,3 GB. WordPress hielt 0,43 GB (8 Kindprozesse) oder 1,8 GB (64 Kindprozesse).

Worker laden den Engine-Code und den Plugin-Bytecode einmal und teilen ihn. Jeder weitere Worker bringt unter Last sein eigenes Working Set mit und gibt das meiste davon im Leerlauf zurück. Ein Worker ohne Request für 30 Sekunden gibt Speicher an das System zurück, deshalb sinkt der Leerlaufwert. Ein WordPress-Pool hält, was er vorab gestartet hat, beschäftigt oder nicht. Die Speicherwerte stammen von BookPress 0.2.57, 13. Oktober 2026; der Durchsatzlauf oben ist eine spätere, eigene Messung.

Kein Objekt-Cache, kein Datenbankserver, kein Seiten-Cache

WordPress-Hoster bauen diese Schichten auf, damit PHP keine Arbeit doppelt tut. Jeder Lesezugriff auf den Objekt-Cache ist ein Roundtrip zu Redis und ein Dekodieren in PHP. Ein Datenbankserver ist ein weiterer Roundtrip. Ein Seiten-Cache speichert eine gerenderte Kopie, damit nginx antworten kann, ohne den Stack zu betreten.

BookPress hat keine davon. Der Speicher ist eingebettet und läuft im selben Prozess, es gibt also keinen Roundtrip einzusparen. Es gibt keine gerenderte Kopie aufzuheben, denn die Seite von Grund auf zu rendern ist der schnelle Pfad. Ein CDN lohnt sich weiterhin, aus den üblichen Gründen: Entfernung zu Ihren Besuchern und statische Dateien.

Jede Schicht kann falsch konfiguriert sein, ihr Speicher kann ausgehen, sie kann veraltete Inhalte halten oder nach einem Deployment geleert werden müssen. BookPress hat keines dieser beweglichen Teile. Das zählt zuerst für den Betrieb und erst danach für die Geschwindigkeit.

Ein Ergebnis spricht gegen uns. Betreibt ein Hoster bereits einen Redis-Objekt-Cache, lassen wir ihn installiert. Ihn abzuschalten, um unsere Zahlen zu verbessern, wäre unredlich. Unsere Plugin-Engine aktiviert das Plugin und die Website wird ausgeliefert, aber das Plugin kann seine Arbeit nicht tun: Die PHP-Engine von BookPress stellt weder den Redis-Client noch die Netzwerkaufrufe bereit, die es braucht. Das Plugin fällt auf den Cache pro Request von WordPress zurück und speichert nichts über Requests hinweg. Jedes aktive Plugin bedeutet, dass die Website für jeden Request PHP ausführt, deshalb macht ein aktiver Objekt-Cache eine Seite ohne Plugins viel langsamer und bringt nichts. BookPress kann die Funktion dieses Plugins nicht ausführen. Das ist etwas anderes, als keines zu brauchen. Installieren Sie keinen Objekt-Cache auf BookPress. Er kostet Sie und bringt Ihnen nichts.

Was ein Seiten-Cache leistet und was er nicht kann

Mit einem Seiten-Cache davor lieferte WordPress in diesem Benchmark Zehntausende Requests pro Sekunde, weit mehr als BookPress. Die Zahl ist echt. Sie ist zugleich nginx, das eine Datei von der Platte liest, ohne dass PHP läuft.

Ein Seiten-Cache endet, wo seine Erlaubnis endet. Er liefert keinen Warenkorb, keine Kasse, keine Kontoseite, nichts mit Sitzungs-Cookie, nichts mit Query-String und nichts für einen eingeloggten Besucher. Diese Seiten entscheiden über die Kapazität eines Shops. Auf ihnen tritt der Cache beiseite, und der Request erreicht das PHP, vor dem er stand. Jede Zahl auf dieser Seite misst diesen Fall.

Das WordPress, gegen das wir verglichen haben, vollständig

Es ist WordPress 7.1.3 auf PHP 8.3.35-FPM, abgestimmt wie ein fähiger Hoster es tut: OPcache so bemessen, dass nichts verdrängt wird, mit eingeschaltetem JIT, ein warmer Redis-Objekt-Cache über einen Socket, MariaDB mit einem gesunden Buffer-Pool und WooCommerce auf seiner neueren Bestellspeicherung (HPOS). Wir haben es in zwei Pools laufen lassen, damit die Pool-Größe den Vergleich nicht verzerrt: ein optimierter Pool (statisch, 64 Kindprozesse) und ein passend dimensionierter Pool (dynamisch, 8 Kindprozesse).

Genaue Konfiguration

• OPcache mit eingeschaltetem JIT. 512 MB kompilierter Code, ein Puffer von 64 MB für interned Strings, ein Limit von 100.000 Dateien, Zeitstempel-Prüfung aus und ein JIT-Puffer von 256 MB.
• Ein Redis-Objekt-Cache (Redis 7) über einen UNIX-Socket, mit installiertem Object-Cache-Drop-in und warmem Cache.
• MariaDB 11 mit einem InnoDB-Buffer-Pool von 4 GB.
• PHP-FPM hinter nginx 1.27. Ein Pool (statisch, 64 Kindprozesse) und ein passend dimensionierter Pool (dynamisch, 8 Kindprozesse), beide gemessen.
• WooCommerce auf HPOS, seiner neueren Bestellspeicherung.

Die Plugins sind die Versionen der Demo: WooCommerce 11.0.1, Elementor 4.2.3, Yoast SEO 28.3 und Contact Form 7 6.1.7, auf dem Kadence-Theme 1.5.2. Wir messen eine Seite erst, nachdem wir geprüft haben, dass WordPress und BookPress dieselbe Seite zeigen: die Elementor-Schaufensterseite, die Produktseite und den Shop-Katalog, geprüft auf beiden Servern.

Die BookPress-Konfiguration, nach demselben Maßstab

bookpress --root /srv/sites/<site> --db /srv/sites/<site>/data/site.db \
          --port <port> --workers 4

BookPress läuft ohne php.ini, ohne PHP-FPM-Pool, ohne Objekt-Cache, ohne Opcode-Cache, ohne Seiten-Cache und ohne Reverse-Proxy. Jede BookPress-Zahl auf dieser Seite ist eine von Grund auf gerenderte Seite.

Welchen Server Sie mieten sollten

Mieten Sie den Arm-Server: vier echte Kerne, wo der Intel-Server zwei hat, etwa 14 Prozent weniger Listenpreis und etwa das 2.2- bis 2.3-Fache der Elementor- und WooCommerce-Requests pro Sekunde auf BookPress 0.2.64.

Listenpreis, Google Cloud us-central1 On-Demand: c4a-standard-4 131.11 $ im Monat gegen c2-standard-4 152.43 $.

Die Rechnung für Hoster

Ein Hoster bemisst einen Server nach Arbeitsspeicher. Unter voller Last brauchte dieselbe Website etwa 0,6 GB auf vier BookPress-Workern (gemessen auf 0.2.57), gegen 0,55 GB für ein passend dimensioniertes WordPress und 1,8 GB für einen optimierten Pool mit 64 Kindprozessen. Im Leerlauf gibt BookPress Speicher zurück, die WordPress-Pools nicht. Wir messen gerade, wie viele Websites eine Maschine trägt.

Unsere Preise leiten wir aus der Infrastruktur ab, für die ein Hoster nicht mehr zahlt, und genau das messen die Zahlen auf dieser Seite. Sie reichen von $1.00€0.85 pro Website und Monat bei Starter bis $0.45€0.38 bei Agency, und ab 500 Websites pro lizenzierter vCPU. Die Preisseite listet die Stufen und zeigt, wie die Zahl für Ihre eigene Flotte berechnet wird.

Was das heißt, wenn Sie viele Websites betreuen →