WordPress + Elementor vs Craft CMS 5: three identical websites on the same server, measured for TTFB, SQL and Lighthouse

All the numbers come from our lab: one machine, six containers with the same PHP image, one database, measurements from the same host. Without network latency the server times are lower than on the internet; Lighthouse on mobile simulates a slow 4G connection and a less powerful phone.

Shared by both systems (as of 2026-11):

• the wordpress:php8.3-apache image with pdo_mysql (PHP 8.3.36, Apache 2.4.69, mod_php, prefork),
• the same MariaDB 11.4 instance with the default configuration,
• the same php.ini: memory_limit 256M, OPcache 128 MB, max_accelerated_files 20000, revalidate_freq 2,
• production mode (WP_DEBUG and devMode off), no cache plugin, no persistent object cache, no {% cache %} in the templates,
• 512 MB of memory per 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

A script moved the content (export to JSON through WP-CLI, import with a Craft console command). The images are the same WebP files from wp-content/uploads, with transforms in the same dimensions and the same quality as the theme's image sizes, and srcset, sizes, loading and fetchpriority as in WordPress's HTML. The URLs are the same, including the trailing slash; old URLs redirect with a 301 in both systems. Across 82 pairs of screenshots (1440 × 900 and 390 × 844) the page height differs by 0 px in 78 and by 1 px in 4: for two images Craft calculates a transform of 803 instead of 804 px. The menu, slider, tabs, filter, lightbox, forms and the map after consent work the same way, and a first-time visitor gets 0 cookies and 0 connections to third-party domains in both versions.

WordPress with or without Elementor

WordPress without a page builder is a different service: the client would edit in the block editor or get templates with no freedom of layout. To show what Elementor alone costs, we also measured WordPress with plugins deactivated (the core and the same theme, pages from the HTML copy that Elementor saves in post_content). This variant looks different and serves only for the server measurement. A version "WordPress without Elementor, with templates as in Craft" would send practically the same HTML, CSS and JS as Craft, so we did not build it.

Server-side measurement: an auto_prepend_file in both systems, active only with a measurement header, records PHP time, peak memory, the number of loaded PHP files and the SQL statement counter on the application's own connection:

// 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;

Response time (TTFB): curl from the same host, 20 requests to warm up OPcache, then 50 measured requests for each of the site's five URLs. Weight and requests: Chromium, empty cache, scrolling through the whole page, 3 runs. Lighthouse 12.8: mobile and desktop, 3 runs per URL, median.

The gallery in Craft: 439 SQL queries for one page

The gallery page with 82 images, each with a srcset of four transforms, had 439 SQL statements and a TTFB of 106 ms in the first version, more than WordPress with Elementor. .eagerly() loads the assets in one query, but $asset->getUrl('transform') looks up the ready transform in the imagetransformindex table with a separate query for every image and every transform. One line in the template loads the transform index for the whole gallery at once:

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

WordPress has its own version of the N+1 problem in the same gallery: two queries per image (SELECT * FROM wp_posts WHERE ID = … and a query for the meta). Loading the gallery images in advance reduces them in the test, without changing the client's theme:

add_action( 'elementor/frontend/widget/before_render', function ( $widget ) {
    if ( 'theme-gallery' === $widget->get_name() ) {   // name of the theme's gallery widget
        _prime_post_caches( wp_list_pluck( (array) $widget->get_settings( 'gallery' ), 'id' ), false, true );
    }
} );

The same on site 1: the project list went from 67 to 34 statements, the gallery from 62 to 33. In both systems the template also "works" without this.

The same quality, different bytes

Transforms from the same WebP originals, in the same dimensions and with the same quality (80 and 82), are 8 to 11 % larger in Craft (site 1: 4.3 and 4.8 MB for all transforms, site 3: 47.8 and 51.6 MB). WordPress downscales with the Triangle filter and light sharpening, Craft (the Imagine library) with Imagick's default filter. On top of that, Craft recompresses the file by default when it is uploaded from outside the control panel: after the import all 32 originals of site 1 had different bytes than in WordPress, until we switched this off:

$asset->sanitizeOnUpload = false;   // files from WordPress are already sanitised; otherwise Craft writes the WebP again

Imagick does not fit in memory_limit

ImageMagick's memory does not count towards the PHP limit, and within one process it is not released between images. Importing 308 images and the first visit to the gallery (transforms generated on display, the generateTransformsBeforePageLoad option) ended with the process being killed in the 512 MB container, with no response for curl:

exit 137

At about 1,100 transforms in one process ImageMagick reported:

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

WordPress creates the sizes on upload, one image per request. In Craft we generate the transforms in advance with a separate command in a one-off CLI container with a higher limit:

docker run --rm -m 2g ... cs-cms-php:8.3 craft site/import/transforms   # one-off CLI container, the same image

The WordPress theme without Elementor: a fatal error

When we measured "WordPress without plugins", site 1 returned a 500:

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

The culprit was the wp_print_footer_scripts hook that switches off Elementor's JavaScript on pages without interaction. A theme built for a page builder is tied to it more closely than the admin panel shows; for the measurement we removed this one hook with a temporary file in mu-plugins.

Re-running schema/apply in Craft 5 wiped the content

Craft 5 stores field values in the JSON column elements_sites.content under the UID of the field layout element, not of the field itself. A schema script that created new layout elements on every run "lost" all texts after the second run: they were in the database, but under the old UIDs, and resave/entries made the loss permanent. The fix: reuse the UIDs of the existing layout elements. Important for anyone who keeps a Craft schema in code.

Text from Elementor is not the text on the page

Elementor stores raw HTML, and on output WordPress runs it through wptexturize: a hyphen between words becomes an en dash (–), straight quotes become typographic ones. An import from Elementor's data would have produced different characters than on the live site, so we took the texts and titles of site 2 from the rendered HTML.

Search gives different results for the same content

WordPress searches with LIKE in post_content, where Elementor keeps an HTML copy of the page together with the alt texts and file names of the images. Craft searches an index of words from fields marked as searchable, and in Craft 5 a field is not searchable by default: the search only found titles. With the index switched on, WordPress returns 6 pages for the same word, Craft 4; in two of them the word appeared only in image file names.

This comparison shows both systems under ideal conditions: both versions built from scratch, with one plugin on the Craft side and one page builder on the WordPress side, no ready-made theme and no plugins "just in case". A typical WordPress site looks different. We have data on that from the same three websites, which we measured before rebuilding them on clean WordPress (table below, the same site numbering; site 3 has no Lighthouse measurement from before the rebuild).

After the rebuild every site has one page builder plugin, site 3 also a plugin for sending mail. Clean WordPress and Craft are a few Lighthouse points and a few milliseconds on the server apart. The typical WordPress these websites started from is tens of points and up to tens of seconds of LCP away from both.

The difference lies not in the core of the system but in what the system lets you add. Craft has no marketplace of ready-made themes or page builders: Twig templates are written from scratch for every project, and in production, where configuration changes in the control panel are switched off, plugins only come in through Composer and a deployment, not with one click by an editor. A Craft website is therefore always built to the standard that this test calls ideal. WordPress lets you build a website just as cleanly, as our rebuilds show, but it does not enforce it: the result depends on the discipline of whoever builds the site and on what gets installed later.