WordPress + Elementor oder Craft CMS 5: drei identische Websites auf demselben Server, gemessen an TTFB, SQL-Abfragen und Lighthouse

Alle Zahlen stammen aus unserem Labor: eine Maschine, sechs Container mit demselben PHP-Image, eine Datenbank, Messung vom selben Host. Ohne Netzwerklatenz sind die Serverzeiten niedriger als im Internet; Lighthouse auf dem Smartphone simuliert eine langsame 4G-Verbindung und ein schwächeres Gerät.

Für beide Systeme gleich (Stand: 2026-11):

• Image wordpress:php8.3-apache mit pdo_mysql (PHP 8.3.36, Apache 2.4.69, mod_php, prefork),
• dieselbe Instanz von MariaDB 11.4 mit Standardkonfiguration,
• dasselbe php.ini: memory_limit 256M, OPcache 128 MB, max_accelerated_files 20000, revalidate_freq 2,
• Produktivmodus (WP_DEBUG und devMode aus), kein Cache-Plugin, kein persistenter Objektcache, kein {% cache %} in den Templates,
• 512 MB Speicher pro Container.

FROM wordpress:php8.3-apache
RUN docker-php-ext-install -j2 pdo_mysql \
 && groupmod -o -g 1000 www-data && usermod -o -u 1000 www-data

Den Inhalt hat ein Skript übertragen (Export per WP-CLI nach JSON, Import mit einem Konsolenbefehl von Craft). Die Bilder sind dieselben WebP-Dateien aus wp-content/uploads, die Varianten haben dieselben Maße und dieselbe Qualität wie die Bildgrößen des Themes, dazu srcset, sizes, loading und fetchpriority wie im HTML von WordPress. Die URLs sind gleich, einschließlich Schrägstrich am Ende; alte URLs leiten in beiden Systemen mit 301 weiter. Bei 82 Screenshot-Paaren (1440 × 900 und 390 × 844) beträgt der Höhenunterschied der Seite bei 78 Paaren 0 px und bei 4 Paaren 1 px: Craft berechnet für zwei Bilder eine Variante mit 803 statt 804 px. Menü, Slider, Tabs, Filter, Lightbox, Formulare und die Karte nach Einwilligung funktionieren gleich, und ein neuer Besucher bekommt in beiden Fassungen 0 Cookies und 0 Verbindungen zu fremden Domains.

WordPress mit oder ohne Elementor

WordPress ohne Page Builder ist eine andere Leistung: Der Kunde würde im Blockeditor arbeiten oder bekäme Templates ohne freie Gestaltung des Layouts. Damit sichtbar wird, was Elementor allein kostet, haben wir auch WordPress mit deaktivierten Plugins gemessen (Kern und dasselbe Theme, Seiten aus der HTML-Kopie, die Elementor in post_content speichert). Diese Variante sieht anders aus und dient nur der Messung am Server. Eine Fassung „WordPress ohne Elementor, mit Templates wie in Craft“ würde praktisch dasselbe HTML, CSS und JS ausliefern wie Craft, deshalb haben wir sie nicht gebaut.

Messung am Server: Eine Datei auto_prepend_file in beiden Systemen, nur bei einem eigenen Messheader aktiv, schreibt PHP-Zeit, Speicherspitze, Zahl der geladenen PHP-Dateien und den Zähler der SQL-Befehle auf der Verbindung der Anwendung selbst:

// WordPress
$sql = (int) $GLOBALS['wpdb']->get_var("SHOW SESSION STATUS LIKE 'Questions'", 1) - 1;
// Craft
$row = \Craft::$app->getDb()->createCommand("SHOW SESSION STATUS LIKE 'Questions'")->queryOne();
$sql = (int) $row['Value'] - 1;

Antwortzeit (TTFB): curl vom selben Host, 20 Anfragen zum Aufwärmen von OPcache, danach 50 gemessene für jede der fünf URLs einer Website. Gewicht und Anfragen: Chromium, leerer Cache, Scrollen über die ganze Seite, 3 Durchläufe. Lighthouse 12.8: Smartphone und Desktop, 3 Durchläufe pro URL, Median.

Galerie in Craft: 439 SQL-Abfragen für eine Seite

Die Galerieseite mit 82 Bildern, jedes mit srcset aus vier Varianten, hatte in der ersten Fassung 439 SQL-Befehle und eine TTFB von 106 ms, mehr als WordPress mit Elementor. .eagerly() lädt die Assets mit einer Abfrage, aber $asset->getUrl('transform') sucht die fertige Variante in der Tabelle imagetransformindex mit einer eigenen Abfrage für jedes Bild und jede Variante. Eine Zeile im Template lädt den Variantenindex für die ganze Galerie auf einmal:

{%- set images = block.images.eagerly().all() -%}
{%- do craft.app.imageTransforms.eagerLoadTransforms(images, ['medium', 'large', 'thumbnail', 'mlarge']) -%}

WordPress hat in derselben Galerie seine eigene Form des N+1-Problems: zwei Abfragen pro Bild (SELECT * FROM wp_posts WHERE ID = … und eine Abfrage der Metadaten). Ein Vorladen der Galeriebilder senkt sie im Test, ohne das Theme des Kunden zu ändern:

add_action( 'elementor/frontend/widget/before_render', function ( $widget ) {
    if ( 'theme-gallery' === $widget->get_name() ) {   // Name des Galerie-Widgets im Theme
        _prime_post_caches( wp_list_pluck( (array) $widget->get_settings( 'gallery' ), 'id' ), false, true );
    }
} );

Auf Website 1 dasselbe: die Projektliste von 67 auf 34 Befehle, die Galerie von 62 auf 33. Das Template „funktioniert“ in beiden Systemen auch ohne das.

Dieselbe Qualität, andere Bytes

Varianten aus denselben WebP-Originalen, in denselben Maßen und mit derselben Qualität (80 und 82), sind in Craft 8 bis 11 % größer (Website 1: 4,3 und 4,8 MB für alle Varianten, Website 3: 47,8 und 51,6 MB). WordPress verkleinert mit dem Filter Triangle und leichtem Nachschärfen, Craft (Bibliothek Imagine) mit dem Standardfilter von Imagick. Dazu komprimiert Craft eine Datei, die nicht über das Control Panel hochgeladen wird, standardmäßig neu: Alle 32 Originale von Website 1 hatten nach dem Import andere Bytes als in WordPress, bis wir das abgeschaltet haben:

$asset->sanitizeOnUpload = false;   // Dateien aus WordPress sind bereits bereinigt; sonst schreibt Craft das WebP neu

Imagick passt nicht ins memory_limit

Der Speicher von ImageMagick zählt nicht zum PHP-Limit und wird in einem Prozess zwischen den Bildern nicht freigegeben. Der Import von 308 Bildern und der erste Aufruf der Galerie (Varianten beim Anzeigen erzeugt, Option generateTransformsBeforePageLoad) endeten im Container mit 512 MB mit einem hart beendeten Prozess, ohne Antwort an curl:

exit 137

Bei rund 1 100 Varianten in einem Prozess meldete ImageMagick:

cache resources exhausted ... @ error/cache.c/OpenPixelCache/3931

WordPress erzeugt die Bildgrößen beim Hochladen, ein Bild pro Anfrage. In Craft erzeugen wir die Varianten vorab mit einem eigenen Befehl in einem einmaligen CLI-Container mit höherem Limit:

docker run --rm -m 2g ... cs-cms-php:8.3 craft site/import/transforms   # einmaliger CLI-Container, dasselbe Image

WordPress-Theme ohne Elementor: fataler Fehler

Bei der Messung „WordPress ohne Plugins“ lieferte Website 1 den Status 500:

PHP Fatal error:  Uncaught Error: Class "Elementor\Plugin" not found in /var/www/html/wp-content/themes/<theme>/inc/elementor.php:161

Schuld war der Hook wp_print_footer_scripts, der das JavaScript von Elementor auf Seiten ohne Interaktion abschaltet. Ein Theme, das für einen Page Builder gebaut ist, hängt enger an ihm, als das Backend erkennen lässt; für die Messung haben wir diesen einen Hook mit einer temporären Datei in mu-plugins entfernt.

Erneutes schema/apply in Craft 5 löschte den Inhalt

Craft 5 speichert Feldwerte in der JSON-Spalte elements_sites.content unter der UID des Feldlayout-Elements, nicht des Feldes selbst. Ein Schemaskript, das bei jedem Lauf neue Layout-Elemente anlegte, „verlor“ nach dem zweiten Durchlauf alle Texte: Sie waren in der Datenbank, aber unter den alten UIDs, und resave/entries machte den Verlust dauerhaft. Die Korrektur: die UIDs der vorhandenen Layout-Elemente übernehmen. Wichtig für alle, die das Schema von Craft im Code halten.

Text aus Elementor ist nicht der Text auf der Seite

Elementor speichert rohes HTML, und WordPress schickt es bei der Ausgabe durch wptexturize: Ein Bindestrich zwischen Wörtern wird zum Halbgeviertstrich (–), gerade Anführungszeichen werden zu typografischen. Ein Import aus den Elementor-Daten hätte andere Zeichen ergeben als auf der Live-Website, deshalb haben wir Texte und Titel von Website 2 aus dem gerenderten HTML übernommen.

Die Suche liefert bei gleichem Inhalt andere Ergebnisse

WordPress sucht per LIKE in post_content, wo Elementor eine HTML-Kopie der Seite samt Alternativtexten und Dateinamen der Bilder ablegt. Craft sucht in einem Wortindex der Felder, die als durchsuchbar markiert sind, und in Craft 5 ist ein Feld standardmäßig nicht durchsuchbar: Die Suche fand nur Titel. Nach dem Einschalten des Index liefert WordPress für dasselbe Wort 6 Seiten, Craft 4; in zwei davon stand das Wort nur in Dateinamen von Bildern.

Dieser Vergleich zeigt beide Systeme unter Idealbedingungen: beide Fassungen von Grund auf gebaut, mit einem Plugin auf der Seite von Craft und einem Page Builder auf der Seite von WordPress, ohne Fertig-Theme und ohne Plugins „auf Vorrat“. Eine typische WordPress-Website sieht anders aus. Dazu haben wir Daten von denselben drei Websites, die wir vor dem Umbau auf sauberes WordPress gemessen haben (Tabelle unten, dieselbe Nummerierung; Website 3 vor dem Umbau ohne Lighthouse-Messung).

Nach dem Umbau hat jede Website ein Page-Builder-Plugin, Website 3 zusätzlich ein Plugin für den Mailversand. Zwischen sauberem WordPress und Craft liegen wenige Lighthouse-Punkte und wenige Millisekunden am Server. Das typische WordPress, aus dem diese Websites hervorgingen, liegt Dutzende Punkte und beim LCP bis zu mehrere Dutzend Sekunden hinter beiden.

Der Unterschied liegt nicht im Kern des Systems, sondern darin, was das System zusätzlich zulässt. Craft hat keinen Markt für fertige Themes oder Page Builder: Twig-Templates werden für jedes Projekt neu geschrieben, und auf Produktion, wo Konfigurationsänderungen im Control Panel gesperrt sind, kommen Plugins nur über Composer und Deployment, nicht mit einem Klick eines Redakteurs. Eine Craft-Website entsteht deshalb immer in dem Standard, den wir in diesem Test ideal nennen. WordPress erlaubt eine ebenso saubere Website, wie unsere Umbauten zeigen, erzwingt sie aber nicht: Das Ergebnis hängt von der Disziplin des Dienstleisters ab und davon, was später nachinstalliert wird.