Performance
How long the framework core needs to assemble a page, measured in an isolated local environment. Not a website speed test.
What is measured
The time the framework core needs to assemble a page: from the start of the request script, through the autoloader, the route, the Site, its Sections, Boxes and Models and the Renderer, to the moment the response is ready to be sent.
It is not the speed of a website. It leaves out the network, the web server, the hosting and the browser. How fast a website feels also depends on its content, images, scripts, the hosting and the visitor's connection, so WBengine claims no number for it. A measurement of the browser, such as the largest contentful paint, is much larger than the time below: it includes the network and the painting.
Results
The time in PHP until the response is ready, in an isolated local environment, and the number of SQL queries of that request.
| Case | Median | 95th percentile | Requests per second | SQL queries |
|---|---|---|---|---|
| Anonymous visitor, no cache at all | 7.1 ms | 10.7 ms | 428 | 6 |
| Anonymous visitor, data cache warm | 5.7 ms | 7.6 ms | 488 | 2 |
| Anonymous visitor, full-page cache hit | 1.8 ms | 2.2 ms | 1,308 | 0 |
| Logged-in user, no cache at all | 12.4 ms | 13.0 ms | 284 | 10 |
| Logged-in user, data cache warm | 10.3 ms | 11.4 ms | 345 | 6 |
| Route that answers without a page | 1.6 ms | 1.8 ms | 1,466 | 0 |
The home page of this skeleton is assembled in about 7 ms with every cache off, in about 6 ms with the data cache warm and in about 2 ms from the full-page cache. A logged-in user is never served from the full-page cache. The requests per second are for four clients at once.
How it was measured
On 1 November 2026 with WBengine 6.7.0, PHP 8.4.27 and MySQL 8.4.13, in an isolated Docker Compose project on a developer laptop. A PHP built-in server with four workers, the client on the same machine (no network), OPcache enabled as on a production server, 20 requests per case, each on a new connection. The data was the one of this skeleton: 24 pages, 17 articles and 29 boxes. All SQL of the framework is counted.
A run with OPcache switched off gave medians that differed by about a millisecond at most (7.1 ms for an anonymous visitor with no cache in both runs), so these numbers do not depend on OPcache. The whole HTTP request, including the connection and the transfer, took about 0.4 ms longer than the time in PHP.
How to repeat it
In an environment prepared as for the smoke test of the skeleton (see the README):
docker compose -p wbengine-skeleton-modernization -f compose.smoke.yml run --rm -T tools php tests/benchmark-cms.php
The result is printed as JSON. With -e WB_BENCHMARK_OPCACHE=0 the server runs without OPcache. The recorded result of the run above is in tests/benchmark-cms-result.json.
What to keep in mind
- A test on a laptop is not a promise for your server. The hardware, the size of the database, the number of boxes on a page and the PHP settings decide.
- Each case has 20 samples, so the 95th percentile is close to the slowest request. Repeat the test on your own hardware before you rely on it.
- A page with more boxes and queries takes longer than the home page of this skeleton. The caches exist for that: see Caching.
- This is not a comparison with other frameworks.