Measured numbers for a page with 200 units: what saving costs, what a page view costs on the server, how many bytes of CSS and JavaScript Sidcraft adds, and how long the editor takes to open. The same commands are in the plugin, so you can measure your own site.
Updated . Measured with Sidcraft 0.15.0, without Sidcraft Pro unless noted.
Test setup
Test page
200 units: 20 containers, each with a heading, rich text, image, button, icon list, divider, counter, accordion and testimonial. Document JSON 117 KB.
Comparison page
A plain block-editor page with one paragraph, on the same site.
Software
WordPress 6.9, Twenty Twenty-Five theme, PHP 8.3 with OPcache, no persistent object cache. Linux container, PHP's built-in web server with 4 workers, SQLite database.
Browser
Headless Chromium, 1440 × 900, cache cleared before each run.
Runs
Server figures: median of 3 runs. Editor: median of 5 runs. Times on a tuned host with MySQL and a full web server will be lower; compare the two pages and the before/after rows rather than the absolute milliseconds.
Page views
Measure
200-unit page
Plain page
Server time (request start to end)
325 ms
54 ms
Peak PHP memory
14 MB
14 MB
Database queries
34
28
Database writes during the page view
0
0
HTML
211 KB
64 KB
CSS added by Sidcraft
139 KB (21 KB gzip)
0
JavaScript added by Sidcraft
40 KB (12 KB gzip)
0
Pages without a Sidcraft layout load no Sidcraft CSS or JavaScript at all. On a Sidcraft page the CSS is three files: the shared front-end stylesheet (78 KB, 14 KB gzip), the site's design tokens (14 KB, 2 KB gzip) and the page's own compiled CSS (46 KB, 4 KB gzip). Unit scripts load only for the units on the page.
Render cost. Rendering the 200 units takes about 205 ms the first time in a request and about 40 ms when the unit fragment cache already holds them. The fragment cache lasts across page views only with a persistent object cache (Redis or Memcached); without one, each page view renders from scratch. Full-page caching avoids the render entirely, and Sidcraft clears the page from the common page-cache plugins when you save.
With Sidcraft Pro active, page-view times were in the same range (305 to 360 ms).
An unchanged save is recognised by comparing a hash of the normalized layout, so it does not rewrite the document, create a revision, clear CSS or purge page caches.
Editor start-up
Measure
200-unit page
10-unit page
Time until every unit is on the canvas and in the Navigator
1.8 s
1.4 s
JavaScript heap in use
31 MB
30 MB
Editor scripts and styles
1,388 KB (306 KB gzip), cached by the browser after the first visit
Editor page HTML (includes unit definitions)
659 KB (88 KB gzip)
548 KB
Improved in 0.15.0. Every unit used to carry its own copy of the ~100 shared Style and Advanced control definitions. They are now sent once, which made the editor page much smaller:
Editor page HTML
0.14.4
0.15.0
Sidcraft
1,657 KB (110 KB gzip), ready in 2.0 s
659 KB (88 KB gzip), ready in 1.8 s
Sidcraft with Sidcraft Pro (208 units)
5,913 KB (426 KB gzip)
2,007 KB (254 KB gzip), ready in 2.5 s
Where the remaining cost is
The shared front-end stylesheet (78 KB) loads in full on every Sidcraft page, whichever units the page uses.
The menu-anchor stylesheet and script (2 KB) load on Sidcraft pages that have no menu anchor.
The editor sends every unit's control definitions at start-up, including units the page does not use.
It creates two temporary published pages (one with a 200-unit layout, one without), measures saving, rendering and a real page view of each, and deletes them again. Page views are requested over HTTP from the server to itself; if a page cache answers instead of WordPress, the command says so. Add --keep to keep the pages.
In a browser, from the plugin's source repository (needs Node.js and Playwright):
