The full report
Typical and slowest pages, side by side.
The typical page (p50) and the slowest 5% (p95), measured end to end from the shoppers’ country, next to the server time, success rate and memory from the same run.
Performance report
Measured on a real store.Fast on modest hardware.
We load-tested a live fashion store on its own 2 vCPU server, with real shopper journeys sent from the shoppers’ own country. Here is what it handled, how we measured it, and why it stays fast as your business grows.
A live store and catalogueSent from the shoppers’ countryServer time with no page cacheStandard PHP-FPM
83–89 msServer time per page, with no page cache
0.24–0.52 sTypical page with 20–30 shoppers at once
≈0.4 sTypical page with 40 shoppers at once
99.97%Of 7,714 requests served without an error
What the test showed
A small server with room to spare.
Application, PostgreSQL, Redis and the background workers all shared one 2 vCPU box with 3.8 GB of RAM.
20–30 shoppers at once
Typical page in 0.24–0.52 s and the slowest 5% within 1.5 s, with the CPU at half load or less.
40 shoppers at once
Typical page about 0.4 s, with the CPU at 58–83% and headroom still left.
43,000–50,000 requests an hour
At 12–14 requests a second, the same small box keeps up with a busy shopping hour.
Memory that stays flat
The web container stayed at 225–262 MiB for the whole run, with more than 2.4 GB of RAM free.
83–89 ms on the server
Measured for a signed-in shopper with no page cache, the hardest case for the server.
Search in about 170 ms
Product search answers in about 170 ms of server time on the same small server.
How we measured
Real store, real journeys, real distance.
Numbers you can trust come from conditions you would recognise, so we measured the way your shoppers actually arrive.
1
A live store
A real fashion catalogue and checkout on a 2 vCPU, 3.8 GB server, with everything on one box.
2
Real journeys
70% new visitors, one to four pages each, search, add to cart and 5–15 seconds of reading between clicks.
3
Real distance
k6 sent traffic from the shoppers’ own country with gzip on, and every virtual shopper had its own session.
4
Honest timing
Network and TLS included in page times, no page cache in server times, and plain PHP-FPM with OPcache.
Why it stays fast
Engineered lean, tested on every release.
Speed is not a server upgrade we ask you to buy. It comes from how the application is built and checked.
Lean by design
We measured, then made it lighter and faster.
Every page renders on the server and is readable before any script runs. Data that is the same for every visitor ships as cached files, and modules start only when a request needs them.
- Storefront page cut from 501 KB to 78 KB
- App ready to answer in 87–92 ms, down from 480–770 ms
- Guest pages cached per host and language, so repeat visits skip the database
- Images converted to WebP and sized for each slot
No special runtime
Fast on ordinary hosting.
These numbers come from standard PHP-FPM with OPcache. No Octane, Swoole, FrankenPHP or JIT, so you get the same speed on any Linux server with Docker and nothing exotic to maintain.
Standard PHP-FPMThe runtime every PHP host already supports
OPcache tunedSized for a large application out of the box
Lean queriesRelated data loaded up front, not row by row
Cached at the edgeOptional CDN in front of guest pages
Quality
Every release passes the same gates.
Static analysis and more than 14,000 automated tests run before a release is built, so a new feature never quietly makes your store slower or less reliable.
Room to grow
More shoppers? Add capacity, not rewrites.
The application is CPU-bound and keeps no local state, so capacity grows with cores: move to 4 vCPU, give the database its own server, then add app servers behind a load balancer.
Performance questions
Straight answers about speed.
Will it be this fast on my server?
On a comparable 2 vCPU server close to your shoppers, yes. Page times include the network, so hosting near your customers matters as much as the server size.
What does “shoppers at once” mean?
People actively browsing at the same moment, each reading for 5–15 seconds between clicks. A store with 40 of them at once is serving thousands of visitors a day.
What should I do when traffic grows?
Move to 4 vCPU first, then give the database its own server, then add app servers behind a load balancer. The software and the data stay the same at every step.
Do you cache pages?
Yes. Guest pages are cached per host and language, so repeat visits skip the database, and you can add a CDN in front. The server times on this page were measured with no page cache.
Why not Octane or Swoole?
You do not need them. Standard PHP-FPM keeps hosting simple and predictable, and the application is already lean enough to be fast without a special runtime.
Try it on your own server.
Start a 14-day trial, deploy with Docker and see the speed with your own catalogue.