How I Made a Luma Theme Faster Than Hyva on Hypernode — Without Spending Days
Hyva on Hypernode is the premium combo for a fast Magento store. But what if your existing Luma theme could beat it — without a rewrite or days of work?
On paper it shouldn’t have been close. In one corner, Hyva on Hypernode — the premium combo everyone reaches for when a Magento store has to be fast. In the other, a five-year-old Luma theme with a dated design and images not even saved as WebP, running on a plain Hetzner box at roughly half the monthly cost. The old store answered faster.
A disclaimer before anything: this isn’t a knock on Hyva or Hypernode or the agency — all are genuinely excellent, and I’ll show you exactly where they win. I also don’t have access to the Hyva-on-Hypernode box, so I can’t run hardcore server-side metrics on it. This is Lighthouse plus an honest, perceived-speed comparison on two real, live stores — read it as “here’s what I saw,” not a lab verdict.
Credit where it’s due. Hyva is the most solid choice in open-source Magento 2 if you want real performance and a nice templating frontend — and the clever part is what it leaves out.
It pairs Tailwind with Alpine.js (I first met Alpine over in the Laravel world) and sheds the pile of old library bloat Magento carried for years. Tailwind especially: you build a frontend without the CSS quietly ballooning.
Small personal aside. I’ve believed in this approach for a long time. Around 10 years ago, while I was still an employee, my habit of leaning on utility classes right in the markup earned me some side-eye — this was the Bootstrap-4-hung-the-moon era, before Tailwind existed.
Now utility-first is the industry standard, all AI generated is all Tailwind. Sigh.... I guess I was just early.
Hyva is also a relief after the PWA detour. Magento 2’s frontend is hard enough on its own; PWA Studio made it dramatically harder — a completely separate stack with its own build and deploy procedure, foreign to anyone (inc. me) whose muscle memory is PHP. A lot of teams bounced off it. Hyva went the other way: modern interactivity without abandoning the .phtml and XML we already knew, and that’s a big part of why it won.
Split frontend and backend might still have its comeback — as AI-agent aces Javascript like Magnus Carlsen plays blindfolded Chess against 8 Grand masters, and something like Claude can design and build a frontend end to end in seconds, a decoupled stack could finally be worth the overhead. But that’s a story for another day.
Anyway — enough about Hyva. We all know it’s good great. So why wouldn’t a merchant just go straight for it? Cost, mostly — and not mine, theirs. A Hyva license (recently made free, hooray) plus a premium modules from Amasty and host like Hypernode is a real monthly bill, and plenty of merchants simply don’t want to take it on.
And it isn’t only hosting and licensing: moving to Hyva means every module you depend on has to be adapted to its frontend — Hyva-compatible builds or porting work — more cost and more time before you’ve sold a single extra product.
Setting the ground
So I set up an honest comparison, and laid out the rules first.
The deal: a comparable Hypernode plan runs €637/month. The StoreFrame side is €340 — €250 for the management hub plus €90 for the Hetzner bare metal. Here's the hardware, side by side:
| StoreFrame (Luma Based) | Hypernode (Hyva) | |
|---|---|---|
| Server | Hetzner EX101 — bare metal | Jackal S — dedicated tier |
| CPU | Intel i9-13900 · 24 cores / 32 threads · up to 5.6 GHz | AMD Ryzen · 12 cores |
| Memory | 64 GB DDR5 ECC · 4400 MT/s | 64 GB |
| Storage | 2× 1.92 TB Gen4 NVMe | — |
| Cost / month | €340/mo (€250 hub + €90 server) | €637/mo |
The StoreFrame stack: OpenResty with Brotli, HTTP/3 and QUIC, three Redis instances, MariaDB, PHP-FPM, OpenSearch, our licensed Luma-based theme (which include Swissup module for page speed), and Varnish, obviously. There’s no magic sauce — just properly tuned Ubuntu and Docker containers working in sync.
And the honest handicaps, all on my side: the Luma store runs an older Magento 2.4.8 on PHP 8.4 — a basic theme - plain StoreFrame theme design I've made 5 years ago (back then the focus was not the design, just to get a proper single Magento2 webshop merge from multiple Magento1), so the design itself is dated. The images aren’t even optimized to WebP. The Hyva-on-Hypernode store is newer across the board, fresh - clean and sharp.
A level playing field
One rule mattered more than the rest: keep it a level playing field. I deliberately left the exotic performance options on the shelf — no FrankenPHP, no ARM, none of the tricks StoreFrame can pull.
Just a familiar, almost boring stack on plain x86 that any Magento team would recognise. The point wasn’t to win with something you’ve never heard of; it was to show how a setup everyone can relate to actually holds up. If it works on the boring stack, it works.
What I actually saw
You can scan them yourself:
fastartechniek.storeframe.store (Hetzner bare metal + StoreFrame Luma)
fastarshop.nl (Hyva + Hypernode)
At a glance, the Luma store doesn’t feel slow at all — it’s genuinely comparable. Try Add to Cart and filter on layered navigation, feels a snap on both.
On uncached pages, and especially in the backend, it’s actually a tad quicker.
The fastartechniek.storeframe.store demo stays online only through the end of June 2026.
Which sounds strange until you remember what’s underneath: raw bare-metal performance versus a managed hosting platform.
So the split is honest — we win on raw performance; Hypernode wins on stability, and Hyva wins on Lighthouse.
Here are the hard figures — three identical pages on each store (the homepage, a category, and the exact same product), five runs each:
Server response time (TTFB) — the bare-metal win
| Metric | StoreFrame (Luma Based) | Hyva |
|---|---|---|
| Homepage | 16ms | 38ms |
| Category page | 21ms | 106ms |
| Product page | 18ms | 49ms |
Google Lighthouse — mobile
| Metric | StoreFrame (Luma Based) | Hyva |
|---|---|---|
| Homepage | 55 | 66 |
| Category page | 51 | 47 |
| Product page | 51 | 90 |
Google Lighthouse — desktop
| Metric | StoreFrame (Luma Based) | Hyva |
|---|---|---|
| Homepage | 67 | 85 |
| Category page | 77 | 48 |
| Product page | 74 | 99 |
Measured early on a Sunday morning, around 5-6 AM CET — on purpose: that's when this B2B shop sees almost no real traffic, so neither store is fighting load. Google PageSpeed Insights (Lighthouse 13.3.0), median of 5 runs, across three identical pages — the homepage, a category, and the exact same product on both stores.
“Server response” is PageSpeed Insight's server-response-time. The Luma side runs lean and stock — no WebP, no CDN, no critical-CSS, no JS deferral — to keep it a level playing field; the Hypernode store is proxied through Cloudflare, so this is origin to origin. Lighthouse scores still swing ±10–15 run-to-run on these heavy pages.
Legacy site — the tuned Luma theme on StoreFrame bare metal (fastartechniek.storeframe.store). The table below is its 10 runs:
URL="https://fastartechniek.storeframe.store/" # legacy: Luma theme, StoreFrame on bare metal
N=10
printf "%-4s %-13s %-11s %-13s\n" run "appconn(ms)" "ttfb(ms)" "srv-wait(ms)"
wait=()
for i in $(seq 1 $N); do
read app ttfb <<< "$(curl -s -o /dev/null -w '%{time_appconnect} %{time_starttransfer}' "$URL")"
sw=$(awk "BEGIN{printf \"%.1f\", ($ttfb-$app)*1000}")
printf "%-4s %-13s %-11s %-13s\n" "$i" \
"$(awk "BEGIN{printf \"%.1f\", $app*1000}")" \
"$(awk "BEGIN{printf \"%.1f\", $ttfb*1000}")" "$sw"
wait+=("$sw")
done
median=$(printf '%s\n' "${wait[@]}" | sort -n | awk '{v[NR]=$1} END{print (NR%2)?v[int(NR/2)+1]:(v[NR/2]+v[NR/2+1])/2}')
echo "----------------------------------------------"
echo "median server-wait over $N runs: ${median} ms"
run appconn(ms) ttfb(ms) srv-wait(ms)
1 73.5 88.0 14.5
2 107.1 112.9 5.8
3 88.9 100.5 11.6
4 83.9 90.2 6.3
5 54.6 60.8 6.1
6 88.8 100.2 11.4
7 64.0 74.5 10.5
8 70.5 82.8 12.3
9 64.8 75.7 11.0
10 58.3 68.5 10.2
----------------------------------------------
median server-wait over 10 runs: 10.75 ms
Current production — the live Hyva store on Hypernode, behind Cloudflare (www.fastarshop.nl). The table below is its 10 runs:
URL="https://www.fastarshop.nl/" # current production: Hyva on Hypernode (Cloudflare)
N=10
printf "%-4s %-13s %-11s %-13s\n" run "appconn(ms)" "ttfb(ms)" "srv-wait(ms)"
wait=()
for i in $(seq 1 $N); do
read app ttfb <<< "$(curl -s -o /dev/null -w '%{time_appconnect} %{time_starttransfer}' "$URL")"
sw=$(awk "BEGIN{printf \"%.1f\", ($ttfb-$app)*1000}")
printf "%-4s %-13s %-11s %-13s\n" "$i" \
"$(awk "BEGIN{printf \"%.1f\", $app*1000}")" \
"$(awk "BEGIN{printf \"%.1f\", $ttfb*1000}")" "$sw"
wait+=("$sw")
done
median=$(printf '%s\n' "${wait[@]}" | sort -n | awk '{v[NR]=$1} END{print (NR%2)?v[int(NR/2)+1]:(v[NR/2]+v[NR/2+1])/2}')
echo "----------------------------------------------"
echo "median server-wait over $N runs: ${median} ms"
run appconn(ms) ttfb(ms) srv-wait(ms)
1 101.2 217.0 115.8
2 60.6 183.3 122.7
3 55.6 205.4 149.7
4 54.2 198.5 144.3
5 48.9 166.8 117.9
6 50.7 165.5 114.9
7 57.5 215.9 158.3
8 52.8 178.4 125.6
9 51.7 135.1 83.4
10 67.4 175.9 108.5
----------------------------------------------
median server-wait over 10 runs: 120.3 ms
A note on method: both snippets run from a single fixed host, so these are origin-side server-response times — not Google’s PageSpeed vantage. The legacy store is hit directly; the production store is Cloudflare-fronted (served dynamically, proxied to the Hypernode origin), so its figure includes that extra network hop and isn’t pure origin think-time. What’s comparable here is the run-to-run median and the size of the gap, not the raw milliseconds.
So who wins?
The honest answer splits along what you choose to measure. By TTFB — the time the server takes to answer at all — yes, we win, and not by a hair: uncached pages come back genuinely quick, and the cached ones land right alongside Hyva, near enough to call even.
All of that with nothing fancy under the hood — just a plain, properly tuned stack. But if the number you live by is the Lighthouse score, Hyva still takes it here. Both are true at once; pick the benchmark that matches what your store actually needs.
So did I actually win? On the one metric I set out to beat — raw server response — yes. Under the conditions I laid out (idle, cached, same page), a tuned Luma store on Hetzner bare metal answers faster than Hyva on Hypernode. And to be clear about the matchup: this is a Jackal S box (also Hypernode dedicated).
Most Hypernode shops I've seen run Falcon — their common tier — and Hypernode scales well past this into far heavier, far pricier configurations that "might pull ahead again", yet I doubt as OpenStack is another layer of virtualization. I'm not racing those. The point was never “I beat a great platform” — it's that fast doesn't have to be expensive.
If you have the budget, Hyva on Hypernode — and I mean that. It wins on Lighthouse, on the things Google rewards, on look-and-feel and the overall experience, and it’s built on newer technology that earns its price. (And if you genuinely want to go nuts on speed, Hyva on bare metal would be the ridiculous best of both — a post for another day.)
Two honest caveats. On SEO: yes, Hyva's stronger Lighthouse scores feed Google's ranking signals — though how much weight Core Web Vitals really carry today is anyone's guess; nobody seems sure anymore.
And on what I didn't measure: this was page-load speed, not load capacity — requests per second, behaviour under concurrency, tail latency at peak weren't tested here.
That said, the StoreFrame box runs more CPU cores (24 vs 12) at the same 64 GB RAM on dedicated bare metal — so on paper it has more headroom and should hold up at least as well under pressure. Theoretically. That's a benchmark for another day.
And you don’t even need bare metal to get here. Bare metal is the extreme — Fastarshop is a high-traffic store (more than 5 multi-sites), so it earns it. For most merchants, without that kind of traffic, a normal Hetzner cloud box with 64 GB of RAM is plenty: not quite as fast as raw bare metal, but comfortably fast enough. Same tuned stack, smaller bill.
And that’s only the comparison against the premium end. Plenty of Magento 2 stores still run on shared hosting — cPanel and the like — oversubscribed and creaking, sharing a box with who-knows-what, especially with the daily dose of ZeroDay we face today. Against that, a properly tuned cloud server isn’t a close call; it’s night and day. If that’s where you are, the jump is bigger than anything in this post.
So who is StoreFrame for? Merchants who’d rather keep their Luma store — whether that’s about cost or any other reason — but still want a faster, modern-performing alternative. Let the server do the work. If that’s you, that’s exactly where we can help.
One last thing. How does a plain server — root access, port 22, and nothing else — turn into any of this? That took me five years, and honestly it’s a story I haven’t seen told anywhere. I’ll give it its own post. Trust me on that one — stay tuned.
Rather keep your store and just make it faster? StoreFrame runs your existing Magento fully tuned on your own cloud — no re-platforming, no theme swap, operated by AI plus a human.
Top comments (0)