Magento Performance Optimisation: Faster Stores on Tuned Servers

Magento performance optimisation means finding where your store loses time and fixing it at the right layer. Some of it is the server: the cache, the session store, search, PHP and the web server. Some of it is your store's own code, extensions and theme, which no host can fix from the server alone. We tune the server layer on our servers in our London data centre, tell you honestly what sits outside it, and quote or hand over anything that needs code changes.

Talk to us 0333 577 6191

Your tuned Magento server

Cached pages skip PHP. The rest reach a server sized and tuned for your store.

Varnish hit rate
Redis or Valkey
OpenSearch
PHP-FPM sized
Cron and indexers
Production mode

Changes tried on staging first

Where Magento speed actually comes from

A slow Magento store usually has more than one cause, and they sit in different places. It helps to split them before spending money:

Layer	What it covers	Can hosting fix it?
Server	Full page cache, cache and session store, search, PHP-FPM, web server, database, disk, cron and indexers	Yes. This is the layer we run and tune
Store configuration	Production mode, cache types enabled, indexer modes, Magento's own settings	Partly. We check it and fix the server side; some settings are your developer's call
Code and extensions	Custom modules, third-party extensions, blocks that switch off the full page cache, slow database queries	No, not from the server alone. We can show where the time goes; the code change is your developer's, or quoted work
Front end and theme	Images, JavaScript, CSS, fonts, third-party scripts, the theme itself	Mostly no. The server delivers the files quickly; how much the browser has to do is down to the theme

A bigger server helps when the store is genuinely short of capacity. It helps much less when the real problem is a cache that is being bypassed, an indexer on the wrong mode or an extension doing too much work on every page. That is why we look before we recommend an upgrade. For a step-by-step version of this split, see our guide Why is Magento slow?.

The server layer we tune

Every EveryHost server runs a stack matched to your store's Magento version and configured for Magento. These are the parts that decide how fast pages come back from the server.

Full page cache with Varnish

Varnish holds ready-made copies of public pages, such as category and product pages, so most visitors are served without Magento rebuilding the page. Its value depends on the hit rate: a page marked as uncacheable, or a cache that is cleared too often, sends every request back to PHP. We configure Varnish for Magento and watch the hit rate. More on Varnish cache for Magento.

Redis or Valkey for cache and sessions

Magento's cache and customer sessions belong in an in-memory store rather than on disk. We use Valkey where your Magento version supports it and Redis on older releases, and we size it for your store. See Redis and OpenSearch for Magento and Valkey for Magento.

OpenSearch

Catalogue search and layered navigation run through OpenSearch. It needs its own memory, and an unhealthy search service slows category pages and search results long before anything looks broken. We run the version your Magento release supports and keep an eye on its health. More on OpenSearch for Magento.

PHP-FPM

PHP-FPM runs Magento's PHP code. Too few workers and requests queue under load; too many and the server runs out of memory. We size the worker pool and PHP's code cache (OPcache) to your server and your traffic.

Nginx

Nginx handles HTTPS and serves static files, such as images, CSS and JavaScript, without involving PHP. See how Nginx and Varnish work together for Magento.

Production mode, cron and indexers

Three Magento basics that quietly decide speed:

Production mode. Adobe says production mode has better performance and is the mode for a live store; developer mode is for building and debugging.
Cron. Magento relies on cron for indexing, emails, sitemaps and queued jobs. If cron stops, data goes stale and work piles up.
Indexers. On "Update by Schedule", Magento indexes changes in the background through cron instead of during every save in the admin.

We check all three when we set a store up, and our Managed and Fully Managed plans monitor the cron heartbeat, indexers and message queues.

Core Web Vitals for Magento

Core Web Vitals are Google's measures of how a page feels to a real visitor. There are three:

Largest Contentful Paint (LCP): how long the main content, such as the hero image or product photo, takes to appear.
Interaction to Next Paint (INP): how quickly the page responds when someone taps or clicks.
Cumulative Layout Shift (CLS): how much the layout jumps around while the page loads.

Google's own thresholds for a "good" score are an LCP of 2.5 seconds or less, an INP of 200 milliseconds or less and a CLS of 0.1 or less, measured at the 75th percentile of real page loads (Google, web.dev: Web Vitals). These are Google's figures for any website, not a measure of EveryHost's servers.

Hosting has the most influence on LCP, because the server has to return the page before the browser can draw anything. A good full page cache hit rate and a fast server help here. INP and CLS depend mostly on the theme and its JavaScript: how much script runs, how images and fonts are sized, and how many third-party tags the store loads.

That is why the theme matters as much as the server. Hyvä is a lighter Magento front end built with this in mind; our guide to Magento Hyvä theme hosting explains what it changes and what it doesn't.

For a CDN in front of your store, we recommend Cloudflare, on your own Cloudflare account. EveryHost does not provide or manage a CDN.

Bots and crawlers eating capacity

Not every request comes from a customer. Aggressive crawlers, AI scrapers and abusive bots can take a large share of a server's capacity, and because they often request uncached pages, such as filtered category URLs and search results, they land on PHP rather than on the cache.

Sentinel, our server-side security monitoring, reads your server's logs and blocks abusive sources at the server firewall. It is not a web application firewall, a CDN, a proxy or DDoS protection. For the crawlers you want to control rather than block, see how to block AI crawlers on Magento 2.

Right-sizing: VPS, dedicated or high availability

Sometimes the honest answer is that the store has outgrown its server. Signs include CPU or memory that stays high after the cache, indexers and bots have been sorted, OpenSearch competing with PHP for memory, a growing catalogue or more store views, and peaks that the current server only just survives.

Managed VPS, from £119 a month + VAT, suits small and growing stores.
Dedicated servers, from £249 a month + VAT, give the store a whole machine, with no neighbours sharing it.
High availability, from £799 a month + VAT, is a multi-node web tier with high-availability database options, built to order, for stores that cannot rely on a single server.

Use the Magento server calculator for a starting point, or see every plan on plans and prices.

How we work

Review. We look at how your store runs on our servers: cache hit rate, PHP-FPM and database load, slow requests, cron and indexers, and bot traffic. Our Managed plan, at £85 a month + VAT, includes a server-side performance review twice a year, and Fully Managed, at £169 a month + VAT, includes one every quarter. Outside those plans, a one-off performance review is quoted, or charged at £85 an hour + VAT.
Staging first. Every EveryHost plan includes a staging environment. Changes are tried there before they go near the live store.
Production. Server-side changes then go to production at a time agreed with you.
Code findings. Where the time is going in your code, extensions or theme, we tell you or your developer what we found. Changes to your store's code are not part of any plan: your developer or agency can make them, or we can quote for the work. Work outside a plan is £85 an hour + VAT, and larger jobs are quoted before any work starts.

Every hosting plan includes 24/7 UK support by ticket through our support portal and 99.5% uptime. For ongoing monitoring and regular reviews, see our Magento managed services. Our roots in UK Magento hosting go back to 2008.

Frequently asked questions

Start by finding where the time goes before changing anything. Check the store runs in production mode, that the full page cache is on and actually being hit, that indexers are on Update by Schedule and cron is running, and that the cache and sessions use Redis or Valkey. Then look at extensions, the theme and bot traffic. Upgrading the server helps only once those basics are right.

Yes, but it is not the whole story. The server decides how fast pages come back: the full page cache, the cache and session store, search, PHP-FPM and the hardware. Your code, extensions and theme decide how much work each page needs and how much the browser has to do. Good hosting cannot make up for an uncacheable page or a heavy theme.

In the admin, go to System, then Cache Management. From the command line, bin/magento cache:clean clears the enabled cache types and is the safe everyday choice, while bin/magento cache:flush empties the whole cache storage, including anything else stored there. Our guide Why is Magento slow? explains the difference in full.

Both, because they do different jobs. Varnish is the full page cache: it serves whole public pages without running Magento. Redis, or Valkey on newer Magento versions, stores Magento's internal cache and customer sessions in memory. A well-run Magento server uses Varnish in front and Redis or Valkey behind it.

It can. Magento itself does not pass or fail: each store's pages are measured separately. Google counts a page as good when its LCP is 2.5 seconds or less, its INP 200 milliseconds or less and its CLS 0.1 or less, at the 75th percentile of real visits. A fast server and a good full page cache hit rate help with Largest Contentful Paint. Interaction to Next Paint and Cumulative Layout Shift depend mostly on the theme, its JavaScript and third-party scripts, which is where a lighter theme such as Hyvä can help.

We tune the server side on every plan and pass code findings to you or your developer. Changes to your store's code, extensions or theme are not part of any plan. Your developer or agency can make them, or we can quote for the work; work outside a plan is £85 an hour + VAT, and larger jobs are quoted first.

Is your Magento store slower than it should be?

Tell us about your store and what feels slow, and we will tell you honestly whether it is the server, the code or the theme.

Talk to us See plans and prices Call 0333 577 6191