{"id":3841,"date":"2026-08-05T13:45:49","date_gmt":"2026-08-05T13:45:49","guid":{"rendered":"https:\/\/www.magento2-agentur.de\/?p=3841"},"modified":"2026-08-05T13:45:49","modified_gmt":"2026-08-05T13:45:49","slug":"how-a-bad-server-can-impact-your-magento-performance","status":"publish","type":"post","link":"https:\/\/www.magento2-agentur.de\/en\/how-a-bad-server-can-impact-your-magento-performance\/","title":{"rendered":"How A Bad Server Can Impact Your Magento Performance"},"content":{"rendered":"

Most Magento speed advice stops at the frontend. Compress your images. Minify your JavaScript. Switch to\u00a0Hyv\u00e4. All of that is worth doing.<\/span>\u00a0<\/span><\/p>\n

None of it matters much if the server underneath is the actual bottleneck.<\/span>\u00a0<\/span>A Magento store can run a beautifully optimised theme and still load slowly, because the real work happens several layers down: the database, the cache, the PHP processes handling each request. Fix the visible layer and the underlying problem is still there.\u00a0It’s\u00a0just better\u00a0disguised.<\/span>\u00a0<\/span><\/p>\n

<\/b>Why Frontend Optimisation Only Gets You So Far<\/span><\/b>\u00a0<\/span><\/h2>\n

A fast frontend still\u00a0has to\u00a0wait for a response from the backend. If a product page takes two seconds to generate because of a slow database query, no amount of image compression changes that.<\/span>\u00a0<\/span><\/p>\n

This is why two Magento stores running an identical theme can perform completely differently. The difference usually\u00a0isn’t\u00a0the code customers see.\u00a0It’s\u00a0the infrastructure they\u00a0don’t.<\/span>\u00a0<\/span><\/p>\n

<\/b>What’s Actually in a Magento Server Stack<\/span><\/b>\u00a0<\/span><\/h3>\n

A production-ready Magento 2.4.8 setup typically runs Nginx, PHP 8.3 or 8.4, MySQL\u00a08.4\u00a0or MariaDB 11.4,\u00a0Valkey\u00a08 or Redis 7.2, Varnish, and\u00a0<\/span>OpenSearch<\/span><\/a>.<\/span> Each piece handles a different job.<\/span>\u00a0<\/span>Miss one, or configure it badly, and the whole stack slows down even if everything else is running fine.<\/span>\u00a0<\/span><\/p>\n

<\/b>Redis (or\u00a0Valkey) Handles the Data Magento Touches Constantly<\/span><\/b>\u00a0<\/span><\/h3>\n

Sessions and cache used to live in the filesystem or the database on older setups. Both are slow compared to in-memory storage, which is what Redis, or its newer alternative\u00a0Valkey, is built for. <\/span>Current guidance is\u00a0<\/span>blunt\u00a0about it:\u00a0<\/span>don’t\u00a0use the filesystem for either in production.<\/span>\u00a0<\/span><\/p>\n

Valkey\u00a0is a community-maintained fork of Redis, now under the Linux Foundation. <\/span>Magento 2.4.8\u00a0<\/span>supports it as a drop-in replacement<\/span><\/a>\u00a0with no code changes\u00a0required.<\/span>\u00a0<\/span><\/p>\n

The detail agencies get wrong most often: running cache and sessions through the same Redis database. Splitting them lets you flush one without wiping out the other, and it stops a session spike from pushing cached data out of memory.<\/span>\u00a0<\/span><\/p>\n

<\/b>Varnish Does Most of the Heavy Lifting<\/span><\/b>\u00a0<\/span><\/h3>\n

Varnish sits in front of the whole stack and serves cached pages before PHP or the database ever get involved. <\/span>In\u00a0<\/span>benchmark\u00a0testing<\/span><\/a>, Varnish serves cached pages\u00a0roughly three\u00a0times faster than Redis full-page cache, and about four times faster than file-based caching.<\/span>\u00a0<\/span><\/p>\n

The catch: Varnish\u00a0doesn’t\u00a0handle HTTPS on its own. It needs Nginx or\u00a0HAProxy\u00a0in front of it to\u00a0terminate\u00a0SSL, which adds a layer most default setups\u00a0don’t\u00a0configure correctly the first time.<\/span>\u00a0<\/span><\/p>\n

Getting Varnish right also means handling \u201ccache holes\u201d properly, the cart contents, recently viewed items, and logged-in states that\u00a0can’t\u00a0just be served from a shared cache.\u00a0<\/span>Get this wrong\u00a0<\/span>and customers start seeing pieces of each other’s sessions, which is a\u00a0considerably worse\u00a0problem than a slow page.<\/span>\u00a0<\/span><\/p>\n

<\/b>Nginx vs Apache: A Smaller Decision\u00a0With\u00a0a Real Impact<\/span><\/b>\u00a0<\/span><\/h3>\n

Nginx has become the default web server for Magento, mostly because it\u00a0<\/span>handles concurrent connections more efficiently<\/span><\/a>\u00a0and integrates more cleanly with Varnish.<\/span>\u00a0<\/span><\/p>\n

It’s\u00a0not a dramatic decision on its own.\u00a0It’s\u00a0one of several small choices that compound. A store running Apache instead of Nginx\u00a0isn’t\u00a0broken,\u00a0it’s\u00a0just carrying a small tax on every request that\u00a0didn’t\u00a0need to be there.<\/span>\u00a0<\/span><\/p>\n

<\/b>The Database Is Where Slowdowns Usually Start<\/span><\/b>\u00a0<\/span><\/h3>\n

Magento’s page load involves complex queries, live pricing calculations, and inventory checks\u00a0on nearly\u00a0<\/span>every request<\/span><\/a>.<\/span> A database that\u00a0isn’t\u00a0tuned for that load becomes the actual bottleneck, no matter how well everything else is configured.<\/span>\u00a0<\/span><\/p>\n

Reindexing makes this worse if\u00a0it’s\u00a0set up carelessly. Running a full reindex during business\u00a0hours, or\u00a0leaving indexers on \u201cupdate on save\u201d in production, creates unpredictable load spikes that show up as random slow periods with no obvious cause.<\/span>\u00a0<\/span><\/p>\n

<\/b>PHP Workers: The Setting Nobody Checks Until Checkout Breaks<\/span><\/b>\u00a0<\/span><\/h3>\n

PHP-FPM workers are what\u00a0actually process\u00a0each request. Too few, and requests queue up during a traffic spike. Too many, and the server runs out of memory trying to handle them all at once.<\/span>\u00a0<\/span><\/p>\n

This is usually invisible until a busy period exposes it: a product launch, a sale, a spike from a marketing email.\u00a0That’s\u00a0when checkout starts timing out for no reason anyone can\u00a0immediately\u00a0explain.<\/span>\u00a0<\/span><\/p>\n

OPcache\u00a0matters here too. <\/span>PHP\u00a08.x’s\u00a0JIT compilation benefits Magento’s class-heavy codebase directly, but only if\u00a0OPcache\u00a0has enough memory allocated.\u00a0<\/span>512 MB\u00a0is the usual minimum<\/span><\/a>\u00a0recommendation.<\/span>\u00a0<\/span><\/p>\n

<\/b>Autoscaling: Growing\u00a0With\u00a0Traffic Instead of Crashing Under It<\/span><\/b>\u00a0<\/span><\/h3>\n

Not every part of a Magento stack should scale the same way. PHP-FPM and web server instances scale horizontally without much difficulty.\u00a0<\/span>The primary database write node generally shouldn’t<\/span><\/a>.<\/span> Search infrastructure needs manual resizing rather than automatic scaling.<\/span>\u00a0<\/span><\/p>\n

AWS EC2 Auto Scaling Groups and Kubernetes HPA are the two most common approaches for production Magento stores, tracking metrics like p95 and p99 request latency, error rate, and instance utilisation to decide when to add capacity.<\/span>\u00a0<\/span><\/p>\n

Get the scaling rules wrong and a traffic spike either overwhelms the store, or the infrastructure scales up cost without the performance to show for it.<\/span>\u00a0<\/span><\/p>\n

<\/b>Cloud Hosting: Why Generic Hosting Doesn’t Work<\/span><\/b>\u00a0<\/span><\/h3>\n

Shared hosting causes exactly the problems\u00a0you’d\u00a0expect:\u00a0<\/span>slow load times, checkout failures under load<\/span><\/a>, and configuration limits that make proper tuning impossible in the first place.<\/span>\u00a0<\/span><\/p>\n

Magento specifically needs a Linux-based production environment, a minimum of 4 GB RAM, and SSD storage as a baseline, not an upgrade path. <\/span>A VPS can handle a smaller store if\u00a0it’s\u00a0properly tuned, but a store with real traffic or a large catalogue needs\u00a0<\/span>dedicated infrastructure<\/span><\/a>\u00a0to avoid resource contention with other tenants.<\/span>\u00a0<\/span><\/p>\n

<\/b>Monitoring: You Can’t Fix What You Can’t See<\/span><\/b>\u00a0<\/span><\/h3>\n

Most performance problems\u00a0don’t\u00a0announce themselves. They show up as a slow week, a drop in conversion rate, a support ticket about checkout, long before anyone traces it to a specific cause.<\/span>\u00a0<\/span><\/p>\n

Application performance monitoring closes that gap. New Relic, Datadog, and Blackfire cover different layers, application performance, infrastructure, and code-level profiling. <\/span>A real production Magento setup with proper monitoring\u00a0<\/span>typically runs to\u00a0$400 or more a month<\/span><\/a>\u00a0once APM and infrastructure monitoring are combined.<\/span>\u00a0<\/span><\/p>\n

It tends to be worth the cost. <\/span>One agency\u00a0<\/span>reported cutting diagnosis time and cost by half<\/span><\/a>\u00a0after adding Blackfire profiling to a client’s stack, catching problems before they became customer-facing.<\/span>\u00a0<\/span><\/p>\n

<\/b>How a Magento Agency Actually Approaches This<\/span><\/b>\u00a0<\/span><\/h3>\n

This is the part that rarely makes it into a blog post: proper Magento performance optimisation\u00a0isn’t\u00a0just installing Redis and calling it done.\u00a0It’s\u00a0tuning cache invalidation rules, splitting cache and session storage, setting PHP-FPM worker counts based on actual traffic patterns, and configuring autoscaling rules that match how a specific store behaves rather than a generic template.<\/span>\u00a0<\/span><\/p>\n

As a Magento agency, Ingold Solutions handles this at the infrastructure level rather than treating it as an afterthought bolted onto a frontend project. That includes server stack configuration, ongoing performance monitoring, and hosting built around how a store\u00a0actually performs\u00a0under real traffic, not just in a benchmark test.<\/span>\u00a0<\/span><\/p>\n

<\/b>Frequently Asked Questions<\/span><\/b>\u00a0<\/span><\/h3>\n

<\/b>Why is my Magento store slow even with a fast theme?<\/span><\/b>\u00a0<\/span><\/h4>\n

Because the theme only controls what happens after the server has already generated the page. If PHP, the database, or the cache layer is slow, no frontend optimisation fixes that.<\/span>\u00a0<\/span><\/p>\n

<\/b>What’s\u00a0the difference between Redis and Varnish in Magento?<\/span><\/b>\u00a0<\/span><\/h4>\n

Redis handles object caching and sessions. Varnish handles full-page caching, serving whole pages before Magento’s PHP code even runs. Most production stores use both together, for different jobs.<\/span>\u00a0<\/span><\/p>\n

<\/b>Do I need Elasticsearch or OpenSearch for Magento?<\/span><\/b>\u00a0<\/span><\/h4>\n

OpenSearch. Elasticsearch is being phased out of Magento’s supported stack, and OpenSearch is the recommended search engine going forward.<\/span>\u00a0<\/span><\/p>\n

<\/b>How much RAM does a Magento store\u00a0actually need?<\/span><\/b>\u00a0<\/span><\/h4>\n

4 GB is the baseline minimum for production, and\u00a0that’s\u00a0a starting point, not a target. Larger catalogues and higher traffic need\u00a0considerably more.<\/span>\u00a0<\/span><\/p>\n

<\/b>Is shared hosting ever good enough for Magento?<\/span><\/b>\u00a0<\/span><\/h4>\n

Not for a production store. Magento’s resource demands and configuration requirements outgrow shared hosting almost\u00a0immediately, even for a\u00a0relatively small\u00a0catalogue.<\/span>\u00a0<\/span><\/p>\n

<\/b>Talk to a Magento Agency That Looks at the Whole Stack<\/span><\/b>\u00a0<\/span><\/h4>\n

If your Magento store’s frontend has already been optimised and\u00a0it’s\u00a0still slow, the server stack is worth a proper look.\u00a0<\/span>Contact Us – Magento<\/span><\/a>\u00a0to talk through what that looks like for your infrastructure.<\/span><\/p>\n","protected":false},"excerpt":{"rendered":"

Most Magento speed advice stops at the frontend. Compress your images. Minify your JavaScript. Switch to\u00a0Hyv\u00e4. All of that is worth doing.\u00a0 None of it matters much if the server underneath is the actual bottleneck.\u00a0A Magento store can run a beautifully optimised theme and still load slowly, because the real work happens several layers down: […]<\/p>\n","protected":false},"author":3,"featured_media":3843,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[17,18],"tags":[],"class_list":["post-3841","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-magento-2","category-magento-b2b-en"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t