Magento Hyva Theme Hosting — What You Actually Need

Luma, Magento's default frontend theme, was built at a time when JavaScript bundling approaches were different. It ships a large RequireJS bundle and relies heavily on jQuery. The result is significant JavaScript parse time in the browser — particularly on mobile devices with slower CPUs. Every Magento page using Luma sends hundreds of kilobytes of JavaScript regardless of what the page actually does. Google's Lighthouse scores reflect this: Luma stores typically have poor Total Blocking Time and slow Largest Contentful Paint on mobile.

Hyva replaces the entire frontend stack: Alpine.js handles interactivity with a much smaller footprint, Tailwind CSS generates only the CSS actually used in the theme, and server-side rendering replaces client-side rendering for most page elements. A comparable Hyva page might send 90% less JavaScript to the browser. The browser parses less code, renders faster, and scores better on Core Web Vitals. For merchants and agencies focused on conversion rate and organic search, the shift from Luma to Hyva is one of the highest-impact investments available in the Magento ecosystem.

Hyva does not change Magento's server requirements — it runs on the same stack. What changes is the importance of each component. Full-page cache (Varnish) becomes more important, not less, because Hyva's fast frontend makes cache misses more noticeable by contrast. A cached Hyva page served by Varnish loads in under 100ms. The same page served from PHP takes 800ms–2 seconds regardless of how lean the frontend is. PHP 8.4 with OPcache is required — not because Hyva demands it specifically, but because serving dynamic Magento pages quickly requires a fast PHP execution environment, and PHP 8.4 is significantly faster than earlier versions for Magento's workload. The full stack a Hyva store needs is exactly what a specialist Magento 2 hosting UK plan provisions as standard.

NVMe storage is equally important. Magento's full-page cache, session data, and OpenSearch index all involve disk I/O. On a Hyva store where the frontend is fast, any disk latency becomes perceptible. NVMe drives deliver read speeds up to 7GB/s — an order of magnitude faster than traditional SSDs. The practical effect for a Magento store is faster cache writes, faster database reads during cache misses, and faster reindexing. For a Hyva store specifically, where server performance is the limiting factor on every non-cached request, NVMe storage closes the gap between cached and non-cached response times.

The performance case for Hyva rests on delivering a fast initial response from the server and a lightweight experience in the browser. If the server takes 2 seconds to generate the first byte, a lean Hyva frontend cannot compensate. Google's Core Web Vitals measure Largest Contentful Paint (LCP) — the time until the largest visible element loads. For a Hyva store to achieve a Good LCP score, the server must deliver the initial HTML response quickly. That requires a Time to First Byte (TTFB) under 200ms, which is only achievable with Varnish serving from cache on a server with sufficient dedicated resources.

Shared hosting environments create a specific problem for Hyva stores: resource contention. When your server CPU, RAM, and I/O are shared with other customers, response times become unpredictable. A page that loads in 80ms at 9am might take 600ms at noon when other customers on the same hardware are busy. For a Luma store, the performance is already slow enough that this variation is masked. For a Hyva store optimised to hit sub-100ms load times, variable server performance is immediately noticeable — both to users and in Core Web Vitals field data. Managed Magento hosting on properly isolated infrastructure eliminates this variable.

For a Hyva store operating at any meaningful traffic level, dedicated Magento hosting removes the shared-resource variable entirely. Your CPU, RAM, and NVMe storage are not divided between other customers. Varnish serves your cached Hyva pages without competing for server resources. During peak trading periods — Black Friday, January sales, product launches — your server performance remains consistent because nothing external can affect it. This is the baseline that Hyva's performance potential assumes: a server that responds predictably because its resources belong to one store.

A production Hyva store should run NGINX as the web server (required by Adobe for Magento production deployments), Varnish 7.7 configured with Magento's official VCL as the full-page cache, PHP 8.4 with OPcache and PHP-FPM, OpenSearch 3 for catalogue search, Redis or Valkey 8 for sessions and the object cache (two dedicated instances), and NVMe SSD storage for the database, cache layer, and Magento's generated files. Each of these components was specified by Adobe as part of Magento's official system requirements — and each has a direct impact on the performance a Hyva store can deliver. Running a Hyva theme on a host that omits any of these components is like installing a high-performance engine in a car with worn tyres: the potential is there but the system as a whole won't perform.

EveryHost runs the full Adobe-recommended Magento stack on dedicated hardware — NGINX, Varnish 7.7, PHP 8.4 with OPcache, OpenSearch 3, and NVMe SSD on every plan. We've migrated and hosted Hyva stores and can configure the server specifically for Hyva's requirements as part of onboarding. If you're launching a new Hyva build or migrating an existing Hyva store, speak to our team: 0333 577 6191.