WordPress + Elementor kontra Craft CMS 5: trzy identyczne strony, ten sam serwer, pomiar TTFB, SQL i Lighthouse

Wszystkie liczby pochodzą z naszego laboratorium: jedna maszyna, sześć kontenerów z tym samym obrazem PHP, jedna baza, pomiar z tego samego hosta. Bez opóźnień sieci czasy serwera są niższe niż w internecie; Lighthouse na telefonie symuluje wolne łącze 4G i słabszy telefon.

Wspólne dla obu systemów (stan na 2026-11):

• obraz wordpress:php8.3-apache z pdo_mysql (PHP 8.3.36, Apache 2.4.69, mod_php, prefork),
• ta sama instancja MariaDB 11.4 z konfiguracją domyślną,
• ten sam php.ini: memory_limit 256M, OPcache 128 MB, max_accelerated_files 20000, revalidate_freq 2,
• tryb produkcyjny (WP_DEBUG i devMode wyłączone), bez wtyczki cache, bez trwałego cache obiektów, bez {% cache %} w szablonach,
• 512 MB pamięci na kontener.

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

Treść przeniósł skrypt (eksport przez WP-CLI do JSON, import konsolowym poleceniem Crafta). Zdjęcia to te same pliki WebP z wp-content/uploads, warianty w tych samych wymiarach i z tą samą jakością co rozmiary obrazków motywu, a srcset, sizes, loading i fetchpriority jak w HTML WordPressa. Adresy takie same, łącznie z ukośnikiem na końcu; stare adresy przekierowują 301 w obu systemach. Na 82 parach zrzutów (1440 × 900 i 390 × 844) różnica wysokości strony wynosi 0 px na 78 i 1 px na 4: Craft liczy dla dwóch zdjęć wariant 803 zamiast 804 px. Menu, slider, zakładki, filtr, lightbox, formularze i mapa po zgodzie działają tak samo, a świeży odwiedzający dostaje w obu wersjach 0 ciasteczek i 0 połączeń z obcymi domenami.

WordPress z Elementorem czy bez

WordPress bez konstruktora stron to inna usługa: klient edytowałby w edytorze blokowym albo dostałby szablony bez swobody układu. Żeby było widać, ile kosztuje sam Elementor, zmierzyliśmy też WordPress z wyłączonymi wtyczkami (rdzeń i ten sam motyw, strony z kopii HTML, którą Elementor zapisuje w post_content). Ten wariant wygląda inaczej i służy tylko do pomiaru serwera. Wersja „WordPress bez Elementora, z szablonami jak w Crafcie” wysyłałaby praktycznie ten sam HTML, CSS i JS co Craft, więc jej nie budowaliśmy.

Pomiar po stronie serwera: plik auto_prepend_file w obu systemach, aktywny tylko z nagłówkiem pomiarowym, zapisuje czas PHP, szczytową pamięć, liczbę wczytanych plików PHP i licznik poleceń SQL na połączeniu samej aplikacji:

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

Czas odpowiedzi (TTFB): curl z tego samego hosta, 20 żądań rozgrzewających OPcache, potem 50 mierzonych na każdy z pięciu adresów strony. Waga i żądania: Chromium, pusta pamięć podręczna, przewinięcie całej strony, 3 przebiegi. Lighthouse 12.8: telefon i komputer, 3 przebiegi na adres, mediana.

Galeria w Crafcie: 439 zapytań SQL na jedną stronę

Strona galerii z 82 zdjęciami, każde z srcset z czterech wariantów, miała w pierwszej wersji 439 poleceń SQL i TTFB 106 ms, więcej niż WordPress z Elementorem. .eagerly() ładuje zasoby jednym zapytaniem, ale $asset->getUrl('wariant') szuka gotowego wariantu w tabeli imagetransformindex osobnym zapytaniem dla każdego zdjęcia i każdego wariantu. Jedna linia w szablonie ładuje indeks wariantów dla całej galerii naraz:

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

WordPress ma w tej samej galerii swoją wersję problemu N+1: dwa zapytania na zdjęcie (SELECT * FROM wp_posts WHERE ID = … i zapytanie o meta). Wstępne wczytanie zdjęć galerii zmniejsza je w teście, bez zmiany motywu klienta:

add_action( 'elementor/frontend/widget/before_render', function ( $widget ) {
    if ( 'theme-gallery' === $widget->get_name() ) {   // nazwa widgetu galerii motywu
        _prime_post_caches( wp_list_pluck( (array) $widget->get_settings( 'gallery' ), 'id' ), false, true );
    }
} );

Na stronie 1 to samo: lista projektów z 67 do 34 poleceń, galeria z 62 do 33. Szablon „działa” w obu systemach także bez tego.

Ta sama jakość, inne bajty

Warianty z tych samych oryginałów WebP, w tych samych wymiarach i z tą samą jakością (80 i 82) są w Crafcie o 8 do 11 % większe (strona 1: 4,3 i 4,8 MB wszystkich wariantów, strona 3: 47,8 i 51,6 MB). WordPress zmniejsza filtrem Triangle z lekkim wyostrzeniem, Craft (biblioteka Imagine) domyślnym filtrem Imagicka. Do tego Craft przy wgrywaniu spoza panelu domyślnie ponownie kompresuje plik: wszystkie 32 oryginały strony 1 miały po imporcie inne bajty niż w WordPressie, dopóki tego nie wyłączyliśmy:

$asset->sanitizeOnUpload = false;   // pliki z WordPressa są już oczyszczone; inaczej Craft zapisuje WebP od nowa

Imagick nie mieści się w memory_limit

Pamięć ImageMagicka nie liczy się do limitu PHP i w jednym procesie nie jest zwalniana między obrazami. Import 308 zdjęć i pierwsze wejście na galerię (warianty generowane przy wyświetlaniu, opcja generateTransformsBeforePageLoad) kończyły się w kontenerze 512 MB zabiciem procesu, bez odpowiedzi dla curl:

exit 137

Przy około 1 100 wariantach w jednym procesie ImageMagick zgłaszał:

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

WordPress tworzy rozmiary przy wgrywaniu, jeden obraz na żądanie. W Crafcie warianty generujemy z góry osobnym poleceniem w jednorazowym kontenerze CLI z większym limitem:

docker run --rm -m 2g ... cs-cms-php:8.3 craft site/import/transforms   # jednorazowy kontener CLI, ten sam obraz

Motyw WordPress bez Elementora: błąd krytyczny

Przy pomiarze „WordPress bez wtyczek” strona 1 zwracała 500:

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

Winny był hook wp_print_footer_scripts, który wyłącza JavaScript Elementora na stronach bez interakcji. Motyw zbudowany pod konstruktor stron jest z nim związany mocniej, niż widać w panelu; do pomiaru zdjęliśmy ten jeden hook tymczasowym plikiem w mu-plugins.

Ponowne schema/apply w Craft 5 kasowało treść

Craft 5 zapisuje wartości pól w kolumnie JSON elements_sites.content pod UID elementu układu pola, nie samego pola. Skrypt schematu, który przy każdym uruchomieniu tworzył nowe elementy układu, po drugim przebiegu „gubił” wszystkie teksty: w bazie były, ale pod starymi UID, a resave/entries utrwalał stratę. Poprawka: przejmować UID istniejących elementów układu. Ważne dla każdego, kto trzyma schemat Crafta w kodzie.

Tekst z Elementora to nie tekst ze strony

Elementor zapisuje surowy HTML, a WordPress przy wyświetlaniu przepuszcza go przez wptexturize: dywiz między słowami staje się półpauzą (–), proste cudzysłowy drukarskimi. Import z danych Elementora dałby inne znaki niż na żywej stronie, więc teksty i tytuły strony 2 przenieśliśmy z wyrenderowanego HTML.

Wyszukiwarka daje inne wyniki przy tej samej treści

WordPress szuka LIKE w post_content, gdzie Elementor trzyma kopię HTML strony razem z tekstami alternatywnymi i nazwami plików zdjęć. Craft szuka w indeksie słów z pól oznaczonych jako przeszukiwalne, a w Craft 5 pole domyślnie przeszukiwalne nie jest: wyszukiwarka znajdowała tylko tytuły. Po włączeniu indeksu dla tego samego słowa WordPress zwraca 6 stron, Craft 4; w dwóch słowo było tylko w nazwach plików zdjęć.

To porównanie pokazuje oba systemy w warunkach idealnych: obie wersje zbudowane od zera, z jedną wtyczką po stronie Crafta i jednym konstruktorem stron po stronie WordPressa, bez gotowego motywu i bez wtyczek „na zapas”. Typowa strona WordPress wygląda inaczej. Mamy na to dane z tych samych trzech stron, zmierzonych przez nas przed przebudową na czysty WordPress (tabela niżej, ta sama numeracja stron; strona 3 przed przebudową bez pomiaru Lighthouse).

Po przebudowie każda strona ma jedną wtyczkę konstruktora, strona 3 dodatkowo wtyczkę do wysyłki poczty. Czysty WordPress i Craft dzieli kilka punktów Lighthouse i kilka milisekund na serwerze. Typowy WordPress, z którego te strony wyszły, dzieli od obu kilkadziesiąt punktów i do kilkudziesięciu sekund LCP.

Różnica nie leży w rdzeniu systemu, tylko w tym, co system pozwala dołożyć. Craft nie ma rynku gotowych motywów ani kreatorów stron: szablony Twig pisze się od zera dla każdego projektu, a na produkcji, gdzie zmiany konfiguracji w panelu są wyłączone, wtyczki wchodzą tylko przez Composer i wdrożenie, nie jednym kliknięciem redaktora. Strona w Crafcie zawsze powstaje więc w standardzie, który w tym teście nazywamy idealnym. WordPress pozwala zbudować stronę równie czysto, co pokazują nasze przebudowy, ale tego nie wymusza: wynik zależy od dyscypliny wykonawcy i od tego, co doinstaluje się później.