Documented Performance Improvements From Real-World Projects

The following project examples demonstrate the breadth of our performance work: e-commerce shops with tens of thousands of products, corporate websites with extensive product catalogs, SaaS dashboards with complex data visualization and internal enterprise portals. Each project posed individual performance challenges, and in every case we combined server-side measures with frontend optimizations to achieve the best possible results. Before-and-after measurements were always conducted under identical test conditions: same test location, same network conditions, same device simulation.

A mid-sized online retailer from Lower Saxony operated a Shopware-based shop with approximately 85,000 products and complex filter navigation. Load times on category pages exceeded 5 seconds on mobile devices, and the Lighthouse performance score stood at 28 out of 100. Search engine crawls increasingly showed indexing issues due to timeouts on large categories.

Our analysis identified three main causes: missing server-side caching layers (every request triggered full database queries), uncompressed product images in PNG format without responsive delivery and 14 third-party scripts that together caused 2.3 megabytes of JavaScript and 1.8 seconds of main thread blocking. Server optimization included introducing Redis as application cache, Elasticsearch tuning for product search and OPcache optimization. On the frontend side, we implemented an automated image pipeline with WebP conversion, critical CSS inlining and the removal or asynchronous loading of non-essential scripts. Particularly noteworthy is the Elasticsearch tuning effect: the faceted search across 85,000 products, which previously executed direct SQL queries on the product table and regularly took four to six seconds, responded within 80 to 150 milliseconds after switching to optimized Elasticsearch indices. The implemented cache invalidation strategy with cache tags ensured that price and inventory changes from the ERP system became visible in the shop within seconds without needing to flush the entire cache.

An industrial company from North Rhine-Westphalia operated a corporate website with an integrated product catalog built on WordPress. The website comprised approximately 320 pages including product data sheets as PDF downloads. The Lighthouse score stood at 41 on mobile devices, Time to First Byte fluctuated between 1,600 and 3,200 milliseconds and the Core Web Vitals failed the Google assessment.

The analysis uncovered a bundle of problems: a page builder plugin generated over 800 kilobytes of unused CSS per page. Twelve WordPress plugins loaded their own JavaScript files on every page regardless of whether their functionality was needed there. The web server ran on shared hosting without any caching configuration, meaning every page view went through the full PHP processing chain and all database queries. Product images were delivered as uncompressed JPEG files at original camera size, some with file sizes exceeding 5 megabytes per image. Optimization included a hosting migration to a managed server with Redis and OPcache, selective plugin loading via conditional tags, CSS purging with critical CSS extraction, an automated image optimization pipeline with WebP conversion and responsive sizes, and the implementation of an nginx reverse proxy cache for anonymous visitors. The Core Web Vitals have consistently passed the Google assessment since optimization.

A regional specialty food online shop built on WordPress/WordPress-Shop with approximately 2,400 products and seasonal promotional campaigns suffered from massive performance problems during peak times. When promotions launched with newsletter distribution, load times spiked to over 12 seconds and the server sporadically returned 502 errors. Under normal operations, the Lighthouse score was 35, dropping below 15 during promotional load.

Root cause analysis revealed: the MySQL database ran on the same server as the web server, competing for CPU and memory, which caused mutual interference during load spikes. WordPress-Shop executed dozens of uncached database queries on every page load including inventory checks, price calculations and transient data queries that bloated the wp_options table with autoload entries. A poorly configured backup plugin blocked the server daily at 2 PM for several minutes, coinciding with peak customer shopping hours. Product images were delivered in a single format and size for all viewports, with even mobile devices loading the 1,920-pixel-wide desktop variant. Server optimization included separating web and database servers onto dedicated hardware, introducing Redis Object Cache with intelligent cache invalidation on inventory changes, PHP-FPM tuning with adjusted worker counts and memory limits, and moving backups to off-peak hours. Frontend optimization included responsive image delivery with automatic WebP conversion, critical CSS extraction and selective WordPress-Shop script loading that only loads cart and checkout scripts on pages where they are actually needed.

A SaaS provider from northern Germany operated a browser-based dashboard for data analysis. The application loaded over 6 megabytes of JavaScript on initial open and required 8 to 12 seconds before the user could interact. INP exceeded 600 milliseconds due to heavy charting libraries blocking the main thread. Customers complained about sluggishness when switching between dashboard views.

The analysis identified multiple causes: the entire charting library with over 800 kilobytes of minified JavaScript was loaded at page start despite users initially seeing only one dashboard view and most chart types being needed only on demand. Unused JavaScript code from feature flags of past releases had never been removed and accounted for 1.4 megabytes of the bundle alone. API responses for dashboard data contained fields not used in the frontend and were uncompressed, meaning a single dashboard query transferred 480 kilobytes of JSON. Data tables with thousands of rows rendered synchronously in the DOM, blocking the main thread for up to three seconds. Optimization included code splitting by dashboard view, lazy loading the charting library with dynamic imports, API response optimization with field filtering and Brotli compression, virtual scrolling for large data tables and offloading compute-intensive data preparation to web workers.

A fashion company from southern Germany operated a Shopware-based shop with approximately 12,000 products serving customers in Germany, Austria and Switzerland. The main problems were a poor mobile Lighthouse score of 31, a CLS value of 0.52 from late-loading product images and banners, and an LCP exceeding 6 seconds on product detail pages.

Our analysis revealed a typical pattern: high-resolution product photos were delivered uncompressed at original size (up to 4,800 pixels wide) because the image pipeline had never been configured. A slider plugin on the homepage preloaded 18 hero images although only one was initially visible. Cookie consent banners and newsletter popups pushed content downward upon display, causing massive CLS values. The theme CSS footprint was 620 kilobytes, of which no single page used more than 15 percent. Frontend optimization included a complete overhaul of image delivery with automatic WebP/AVIF conversion and responsive sizes, elimination of slider overhead, reserved placeholder areas for dynamic content and CSS purging with critical CSS extraction. Server optimization included Redis caching and Elasticsearch tuning for faceted navigation.

A financial sector company operated an internal web portal for approximately 400 employees. The application was built on a PHP framework with JavaScript frontend and suffered from extreme load times of 10 to 15 seconds during login and when switching between work areas. Employee productivity was measurably impacted, and the internal IT department could not resolve the issues with incremental fixes.

Deep analysis revealed a cascade of performance problems: the database contained 47 million rows in the activity log table that was fully scanned on every login because the index on the timestamp column was missing. The frontend reloaded the entire application on every page navigation instead of updating only the changed area. Document thumbnails were regenerated server-side on every access instead of being cached. After optimization, which included database indexing, partitioning of the log table, introduction of SPA-style navigation, thumbnail caching and Redis for session management, load time dropped to below 2 seconds.

The following overview summarizes the core metrics from all six featured reference projects. Despite different platforms, industries and starting situations, the results show a consistent pattern: through the combination of server-side optimization, frontend improvements and targeted caching, load times can typically be reduced by 60 to 85 percent.

Across all projects, certain optimization measures consistently deliver the greatest performance gains. The order reflects the typical impact we observe in practice. What matters is not just the individual measure but how they interact: server-side caching only reaches its full potential when combined with optimized database queries, and frontend optimizations are most effective when the foundation, the TTFB, is already at a low level.

In practice, we therefore always start with server-side optimization because it forms the basis for all subsequent measures. A server that takes 3 seconds for its first response cannot be compensated by any frontend measure. Conversely, a fast server makes the effect of critical CSS, lazy loading and image optimization significantly more noticeable for the end user.

Behind every successful performance project stands a structured process. We work data-driven: every decision is based on measurements, every measure is validated before and after. This approach ensures optimizations actually work and cause no unintended side effects.

Performance optimization is not a one-time event. Every new feature, content update and third-party integration can jeopardize achieved improvements. New product images uploaded without compression, an additional marketing tag loaded synchronously or a plugin update that introduces unexpected CSS overhead can deteriorate the hard-earned Lighthouse score within days. That is why we recommend ongoing performance monitoring for all clients to detect regressions early.

In the projects presented here, four out of six clients use our continuous monitoring package. The automated weekly audits detected an average of 2.3 performance regressions per project in the first six months after project completion, before they affected user experience. Typical causes: new marketing scripts integrated without consultation, uncompressed images from content editors and plugin updates that introduced unexpected CSS overhead. Through proactive intervention, Core Web Vitals remained consistently in the green zone across all monitored projects. Learn more about our optimization approach on the services page.

Optimizing a website is not a one-time project but the beginning of a continuous process. Content updates, new features, plugin updates and changing usage patterns can degrade optimized values. For this reason, we offer all clients ongoing performance monitoring after the initial optimization is complete. Our monitoring infrastructure checks your website's Core Web Vitals at regular intervals using both synthetic and real user data. When values deteriorate, you automatically receive a notification with root cause analysis and specific action recommendations. In our existing monitoring engagements, we typically respond to performance regressions within 24 hours and restore target values promptly. This proactive support ensures that the improvements achieved during optimization are maintained long-term and your website remains fast even with growing traffic and increasing demands. Get in touch to learn more about our monitoring packages.