The Starting Point: A Slow Shop in a Fast Industry

The client is a specialized manufacturer of industrial machinery with 120 employees, operating across the DACH region. Their B2B online shop had become a critical channel for acquiring new customers, but after a recent migration to Magento 2, the platform was underperforming. The core issue was stark: pages took over 8 seconds to load. In the industrial sector, where buyers often compare complex specifications on desktop or mobile devices, this latency was unacceptable. The result was a high bounce rate and frustrated potential buyers who abandoned their carts or left the site entirely.

The technical debt from the migration had created a bottleneck. The site suffered from an unoptimized database with missing indexes and inefficient queries. Furthermore, the frontend was burdened with heavy, unoptimized assets, including uncompressed images and bloated CSS and JavaScript files. Most critically, there was no effective full-page caching (FPC) for product pages, meaning every request hit the database and PHP engine directly. This combination made the shop unusable for high-traffic periods and detrimental to SEO rankings.

The Challenges

We identified four specific hurdles that had to be overcome to achieve a sub-4-second load time without compromising functionality:

  1. Database Overhead: The Magento 2 database schema was not tuned for read-heavy B2B traffic. Queries for product filters and inventory checks were timing out under load.
  2. Asset Weight: The average image size for product galleries was over 500KB, with no modern compression formats applied. CSS and JS bundles were unminified, adding significant parsing time.
  3. Cache Invalidation Issues: The previous caching strategy was too aggressive, leading to stale data, while the lack of FPC meant the cache was rarely utilized for full page renders.
  4. Geographic Latency: The original hosting setup was located in a single data center, causing high latency for customers in Austria and Switzerland compared to the German user base.

How We Measured It

Before touching a single line of code, we established a rigorous baseline. We used Google Lighthouse and WebPageTest to measure the Largest Contentful Paint (LCP), First Input Delay (FID), and Cumulative Layout Shift (CLS). We defined LCP as our primary KPI, targeting a score under 2.5 seconds for good performance, but aiming for under 4 seconds as a realistic initial goal given the legacy codebase.

We also integrated server-side monitoring to track database query execution times and PHP processing times. For the business metrics, we correlated the technical data with Google Analytics 4 data, specifically tracking bounce rate and conversion rate (defined as a completed quote request or order) on a weekly basis. This allowed us to isolate the impact of performance changes from other marketing activities.

The Implementation

The project was executed in three distinct phases over four weeks, preceded by a two-week audit.

Projektverlauf in 5 Phasen: Two-week performance audit & baseline, Backend: Redis, SQL & FPC setup, Frontend: WebP, minification, lazy load …

Phase 1: Backend & Database (Weeks 1-2) We began by addressing the root cause of the slowness: the backend. We implemented Redis for session handling and caching, which offloaded a significant amount of data from the main database. We then performed a deep-dive into the SQL queries, identifying and optimizing the top 20 slowest queries. Missing indexes on key tables, such as catalog_product_entity and catalog_product_index_price, were added. Crucially, we activated and configured the Full-Page-Cache (FPC). This ensured that product pages were served as static HTML files whenever possible, bypassing the PHP engine entirely for cached requests.

Phase 2: Frontend & Assets (Week 3) With the backend stabilized, we turned to the frontend. All product images were converted to the WebP format, reducing file sizes by an average of 30% without visible quality loss. We implemented a minification and bundling pipeline for CSS and JavaScript, combining multiple files into single, optimized bundles. To further reduce the initial payload, we added lazy loading for all images below the fold and for embedded iframes. This ensured that users only downloaded assets that were immediately visible.

Phase 3: Infrastructure (Week 4) The final phase involved migrating the shop to a high-performance cloud hosting stack. We configured a Content Delivery Network (CDN) to serve static assets from edge locations closest to the user. This was particularly important for the DACH region, ensuring that customers in Vienna or Zurich experienced similar load times to those in Munich. We also enabled HTTP/2 and Brotli compression at the server level, allowing for more efficient data transfer and faster page rendering.

The Results

After the implementation, we entered a four-week testing phase to monitor stability and gather real-world data. The results were significant. The LCP time dropped from 8.2 seconds to 3.3 seconds, a reduction of 60%. This technical improvement directly translated into better user behavior. The bounce rate decreased from 65% to 42%, indicating that users were staying on the site longer. Most importantly, the conversion rate increased by 58%, from 1.2% to 1.9%. This meant that for every 100 visitors, the shop now generated nearly two additional completed orders.

Performance & Engagement Metrics: Vorher-Nachher-Vergleich der Kennzahlen in %

The faster load time led to increased dwell time, allowing buyers to explore the complex product catalogs more thoroughly. The reduced friction in the user journey also improved the overall brand perception, making the digital experience feel more professional and reliable.

What We Would Do Differently Today

While the project was a success, there are areas where we would adjust our approach in future engagements.

First, we would have started the CDN configuration earlier in the process. Initially, we focused on the backend and frontend optimizations, but the geographic latency was a significant factor that could have been addressed in parallel. Starting the CDN setup in Week 2 would have allowed us to measure the combined effect of local caching and global delivery earlier.

Second, we would have implemented a more granular cache invalidation strategy from the start. The initial FPC configuration was broad, leading to some stale data issues during the testing phase. A more fine-grained approach, using specific cache tags for price and stock updates, would have reduced the risk of data inconsistency.

Finally, we would have involved the client’s marketing team earlier in the process. The conversion rate increase was partly due to better UX, but also because the faster site allowed for better A/B testing of landing pages. Involving marketing from the start would have allowed us to align performance goals with campaign goals more closely.

Lessons Learned

This case study highlights that performance is not a one-time project but a continuous process. In the B2B sector, where users often browse complex product catalogs, speed is crucial for the user experience. Database optimization offers the greatest leverage for Magento performance, as it addresses the root cause of slowness. However, CDN and cloud hosting are essential for global DACH customers with international requests. Regular monitoring is necessary to detect performance regressions early, especially as the product catalog grows and new features are added. The combination of technical optimization and strategic infrastructure choices is key to achieving sustainable performance gains.

Passend dazu