Websites and apps, measured — six kinds on one server
SixPanel's Latest channel runs websites beside the 6amMart shop: a static site, a single-page app, a Node.js app, a PHP site, WordPress and a site built with Create with AI. This page is what each one took to answer at the server, and what the round that shipped them found wrong first.
The short version: every kind answered in 5–18 ms at the origin, WordPress included once its page cache was warm; the one slow figure is WordPress rendering a page with the cache bypassed, 71.7 ms. None of these is a benchmark against another panel. They are the cost of each kind on SixPanel, so you know what you are adding to a server that already runs a shop.
Measured 29 September 2026 on one test server: Ubuntu 26.04, 4 vCPU, 8 GB, installed from the channel's own installer command. Every sample went in through the panel's own interface calls — the ones its pages make — not by hand on the server.
What was deployed
| Kind | What it carried |
|---|---|
| Static | a café site uploaded as a folder, with its own 404.html |
| Single-page app | a Vite and React Router source, built on the server |
| Node.js | a Next.js loyalty app with a MariaDB database, its .env.local imported, and a scheduled job |
| PHP | a reservations app with a MariaDB database, its own PHP settings and a scheduled job |
| WordPress | installed by the panel: About and Contact pages, three posts, a contact form, a restore point |
| Create with AI | the starter site, before any AI change |
Each ran as its own Linux account in its own folder, and each had only what its kind needs: the static site and the single-page app had no PHP pool, no process and no database; the PHP site had no Node.js process.
Time to answer, at the server
Loopback, a fresh TLS connection on each request — about 4 ms of every figure is that handshake. The first request, then the average of five more.
| Sample | First | Then (avg of 5) |
|---|---|---|
| WordPress, from the page cache | 5 ms | 5.0 ms |
| WordPress, cache bypassed | 79 ms | 71.7 ms |
| WordPress About page, from the page cache | 5 ms | 5.3 ms |
| Static | 5 ms | 5.5 ms |
| Single-page app | 5 ms | 5.2 ms |
| Next.js + MariaDB | 20 ms | 18.0 ms |
| PHP + MariaDB | 27 ms | 10.0 ms |
| Create with AI (starter) | 8 ms | 7.4 ms |
The page cache is what makes WordPress cost the same as a static file for a visitor: a published page is served by nginx without starting PHP, and it clears itself when you publish. A signed-in editor always gets a fresh page.
Where the rest of a visitor's wait comes from
A browser in India saw about 1.3 seconds for the same pages. That is the distance to the test server — in the central United States — through Cloudflare, not the server. Put the server near your visitors.
What was checked beyond the timing
- Through Cloudflare, from India: the WordPress home page (74 KB, served from Cloudflare's cache), About, Contact with its form, a single post, and a real 404 page for a post that does not exist.
- A restore, live: WordPress was restored to a point taken while its theme was missing. The restore put the code and the database back, reinstalled the theme and emptied the cache; the home page answered with its posts.
- A database round trip: a view created by the Node.js app's own database account was exported, downloaded and imported back through the panel's Database page, and all ten rows and the view came back.
- Scheduled jobs ran: the PHP site's morning report printed the week's bookings.
What the round found first
The kinds did not work on the first build, and the worst defect passed a check that only read the status code. The fixes that mattered:
- Every new WordPress showed its visitors an empty page. The installer asked for the default theme before WordPress's configuration existed, the request was refused, and the refusal was hidden. WordPress then answered 200 with a 0-byte body, the page cache kept it, and the sample check — which read only the status — called it a working site. The theme now installs after WordPress does, a site missing its active theme is mended at start-up, after a restore and after an update, and every sample now has to show a phrase of its own content.
- No site could use its own cache. Creating a missing shared folder with one site's private permissions locked every site out of it, so the first build failed with a permission error. Shared folders are now traversable and never listable, and are repaired at every start.
- The WordPress restore point hung for ever, which meant every WordPress update would have hung, since each takes a restore point first.
- A database import ran as the database's root account, so a dump naming another database could land in one the site does not own — a 6amMart one included. It runs as the site's own account now, and a view created by another account is rewritten to that account instead of stopping the import.
- A long server hostname broke the panel's own address, because nginx refused the whole configuration and the refused file was left in place. The panel now puts the previous files back on a refusal.
The first three and the hostname were found on the test server by the sample rounds; the import defects were found by review. Each fix has a check that fails when the fix is taken back out.
Related
Security and isolation is where the per-site accounts are tested as an attacker would · How we measure · the Websites and apps chapter of the manual for how to set each kind up.
Quelque chose n'est pas clair ?Demandez à Tia