A target for Time to First Byte (TTFB) should be under 200ms. For Largest Contentful Paint (LCP) — when the main content becomes visible — we aim for under 1.5 to 2 seconds. Anything under 2.5 seconds for the full page build is considered "good" by Google (the green zone), but in the high-end segment we target values under 1 second.

Only to a degree. An extremely powerful server can mask bad code up to a point, but it doesn't solve the problem of inefficient database queries or bloated JavaScript in the customer's browser. Real performance always comes from the symbiosis of optimized hardware, a perfectly configured stack (Varnish/Redis) and lean frontend code.

Magento's internal FPC stores pages on disk or in Redis, but still has to invoke PHP to serve them. Varnish, on the other hand, sits as a standalone service in front of the web server and serves pages directly from RAM. That's far faster and massively relieves the server, since PHP never has to start at all for cached pages.

Often this comes from a database overloaded with log entries, report data or abandoned carts. "Cache sprawl" or inefficient indexes can also be the cause. Without regular maintenance and technical monitoring, small performance killers accumulate and, together, noticeably slow the system down. We therefore recommend a monthly maintenance check.

Every extension adds new code and often additional database queries. Especially poorly coded third-party modules can slow down the entire shop, for example by bypassing caching mechanisms. In every audit, we critically review which extensions are actually necessary and optimize or replace "performance hogs" with leaner custom builds.

No, PWAs are often extremely complex and expensive to maintain. A more modern and efficient solution for most shops is Hyvä Themes. It delivers PWA-level speed while being built on Magento's classic structure, which halves development cost and greatly improves compatibility with existing modules. Hyvä is currently our gold standard for fast frontends.

Images are the most common cause of poor LCP scores. With modern formats like WebP, we can often reduce file size by 80% at identical quality. Combined with lazy loading and correctly sized thumbnails, we make sure the browser only loads what the user is actually looking at, which massively improves perceived load time.

Magento is built to handle millions of products, but database queries grow more complex as catalog size increases. Category filters (layered navigation) in particular can get slow with large assortments. We solve this by using Elasticsearch or OpenSearch, so search queries and filtering no longer burden the SQL database but come blazingly fast from a specialized search index instead.

Yes, absolutely — especially if you have customers across different countries or continents. A CDN like Cloudflare mirrors your images, CSS and JS files on servers around the world. A customer from the US then loads that data from a server in New York instead of a data center in Germany. This reduces physical latency and takes load off your main server.

TTFB measures the time from sending the request to receiving the first byte from the server. A high TTFB points to server issues or slow PHP processing. We optimize TTFB through fast hosting (NVMe), PHP tuning, Redis caching, and above all a perfectly configured Varnish cache that bypasses PHP entirely.

Small things like compressing images before upload or disabling unused modules through the backend can be done by any administrator. Real enterprise-grade performance, the kind that hits Google PageSpeed scores of 90+, requires deep changes to server configuration and code, though. That's where the expertise of a specialized developer is essential, to avoid mistakes that could take the shop offline.

Yes, in modern Magento 2 versions Adobe recommends disabling flat catalogs, since the indexer has become so efficient that flat tables often create more overhead than benefit. We check your specific version and configuration and make sure you're using the latest best practices instead of holding on to outdated tuning methods.

Magento's default JS bundling is often counterproductive, since it creates huge files that block the browser. We instead rely on smarter solutions like "Magepack," which only bundles the scripts actually needed for each page. Even better is skipping Magento's heavy default JS altogether by switching to a Hyvä frontend.

These protocols let the browser load many files simultaneously over a single connection instead of one after another. For Magento's file-heavy default frontend in particular, that's a huge win. We make sure your server supports HTTP/2 or even modern HTTP/3 (QUIC), to minimize network latency for your customers.

Just send us your shop URL. We'll run an initial free analysis and show you in black and white where your bottlenecks are. Afterwards we'll set up a call to build a step-by-step plan for your high-speed online shop — transparent, honest, and focused on your measurable results.