How We Fixed Core Web Vitals in a Shopware 6 Store in Under 3 Months

Is Poor Website Performance Costing Your Shopware 6 Store Sales?

The world of eCommerce is obsessed with ways to grab user attention. Video footage backgrounds, animated interactions, and shiny new agentic eCommerce are just some of the tricks used to keep users engaged. However, nothing has as much impact on user conversion as website performance. Numerous sources suggest that site speed remains the key factor determining customer conversion and bounce rates.

With such a convincing case for its importance, it stands to reason that web performance must be the key concern for eCommerce businesses. Yet, our experience has shown that performance optimization is rarely a priority for the business stakeholders. Being tricky to spot if not already paid attention to, slow site speed may do significant damage while remaining under the radar.

Case study: Fixing Core Web Vitals for a Shopware 6 eCommerce Store

At Kiwee, we proactively raise awareness of this topic with our clients and aid them with identifying, measuring, prioritizing, and resolving performance-related issues. Our client Christopeit Sport has contacted us after realizing that slow page loads and laggy navigation are holding their online web store back and lowering sales. After initial discussion, we quickly realized an in-depth performance audit was needed.

By following our tried-and-tested data-driven auditing process, we helped our client's Shopware 6 store go from failing the Core Web Vitals report to scoring "green" on all three of its metrics (LCP, CLS, INP) in just under 3 months. How did we do that?

Step 1: Shopware 6 Performance Audit—Benchmarking and Baseline Measurement

Before any improvements can be made, we must first perform a comprehensive performance audit of the site. We start with benchmarking, that is, measuring the current performance and comparing it to the scores of the shop's competitors to determine a realistic target for improvement. Since "performance" is a rather vague term with no unit of measure, the first step is to select concrete, repeatable measurement procedures. We use two tools developed by Google to achieve this: Lighthouse and Core Web Vitals.

What Lighthouse Measures in a Shopware 6 Performance Audit

Lighthouse is an open-source performance, accessibility, and SEO testing tool built into Google Chrome. It simulates user interaction to measure performance metrics, which gives a standardized score from 0 to 100. It can be compared with scores of other sites, or used to track progress when implementing improvements. Additionally, the Lighthouse audit may give clues as to where to look for possible causes of performance issues.

Why Core Web Vitals Matter for Real Shopware Customers

Core Web Vitals (CWV) is a set of user-centric metrics that best encapsulate how usable the website is for real customers. Unlike Lighthouse, the metrics are calculated from actual usage data and the scores depend on the type of traffic your website gets. They focus on three essential aspects of the user experience: how quickly the main content becomes visible (LCP), how responsive the page is when users interact (INP), and whether the layout remains stable while loading (CLS). Instead of giving an average, CWV is calculated on the 75th percentile, meaning that 75% of users have experience equal to or better than the resulting scores. Each of the three metrics have threshold values, splitting the range into three categories: Poor, Need improvement, and Good. If any of the three metrics is Poor, the whole CWV assessment is marked as Poor. CWV is part of the Web Vitals report, which also contains the FCP and TTFB metrics (more on them later).

	Lighthouse	Core Web Vitals
Type	Diagnostics tool	Actual usage report
Measurement	in the lab	in the field
Score	0 to 100	"Poor", "Needs improvement", "Good"
Purpose	Performance troubleshooting and comparison	Long-term usability monitoring
Part of	Chrome DevTools	Google Search Console

By combining the results from both tools, we can already paint a picture of what the biggest pain points are, and where the biggest improvements can be made. It must be noted that this analysis must be done on different types of pages (landing, category listing, product detail), and device types (desktop, mobile).

If not already present, we also advise setting up an Application Performance Monitoring (APM) tool like New Relic or Sentry.io in order to track server-side performance. Such tools give an in-depth view of what happens on the server during each request, which has a downstream effect on the LCP score.

Step 2: Diagnosing Core Web Vitals Failures in a Shopware 6 Store

At this stage, we've got a big-picture view of how the performance of the analyzed website affects its usability. Now we need to find the myriad root causes. While this process is unique for each site, we can give a general idea of how we go about it. We'll discuss the Core Web Vitals metrics, how they relate to each other, as well as what else to pay attention to.

What Causes a Poor LCP Score in eCommerce Stores—and How to Fix It

Let's start with LCP. It concerns the largest element on a page, which is very often some sort of a banner containing a large image. An acceptable value should be under 2.5s for the 75th percentile. Common causes of poor LCP include:

• Lazy-loading the LCP image
• Large image size
• Image request is not discoverable in initial content (i.e. loaded via client-side JS)
• No differentiation of LCP content for the mobile view
• Not setting fetchpriority=high on the LCP image
• Setting fetchpriority=high on too many images other than the LCP one
• Too many render-blocking resources being fetched

Investigating Lighthouse results gives us a starting point:

Here, we can see that we could probably improve this page LCP score by adding fetchpriority=high for this given image. However, we should remember that the LCP score is the total time it takes for the element to load starting from the time a user navigates to the page. This means that server connection lag, request processing, possible redirects—all of that contributes to the Time To First Byte metric, and thus to the LCP score as well. Therefore, the issue with LCP might lie elsewhere.

How High TTFB Slows Down Your Shopware 6 Store (and What to Do About It)

It is the time it takes the server to receive and process the request, and the browser to get the response back. This metric is extremely helpful as it isolates all delays that happen before the browser starts rendering the page. Therefore, the causes of large TTFB must lie in backend performance and infrastructure. The common culprits are:

• Large travel distance between where the server is located and where most user traffic is originating
• Lacking or misconfigured caching mechanisms
• Insufficient server infrastructure capacity to handle the amount of traffic the website gets
• Slow server disk I/O speed
• Time-consuming HTTP compression
• Costly server-side processing of requests
• Resource-intensive operations being run alongside request processing
• Poor quality custom code or plugins

Some TTFB issues are easily resolvable. For example, removing any same-origin redirects eliminates unnecessary client-server round trips. Provided the caching mechanism is present, properly configuring the Cache-Control header will also bring immediate improvement. Adding a CDN layer will further speed up TTFB of cached pages by bringing them closer to the users' location, as well as by reducing DNS resolution times.

Large TTFB may be caused by bottlenecks in a dozen different places during the request-response lifecycle.

Still, many TTFB issues are architectural and will require substantial effort to investigate and resolve. While proper caching is essential, it may mask the problems affecting TTFB when users request uncached content. At Kiwee, we perform detailed infrastructure analysis and benchmarking in both cached and uncached scenarios. We then employ the aforementioned APM tools to monitor performance and spot issues in production runtime.

APM: web transaction time before and after optimizations for www.christopeit-sport.com

How Excessive Page Weight Hurts Your Store’s Load Time and Core Web Vitals

It must be noted that no matter how low your TTFB is, slow internet connection on the part of the user may still result in long loading time of the page content itself, and thus negatively affect the LCP score. While neither Lighthouse nor Core Web Vitals present payload size as a metric, high First Contentful Paint (FCP) time while having low TTFB may indicate a problem with large payload. In the Lighthouse report, an indication of the issue is a diagnostic message that goes: "Avoid enormous network payloads". Lighthouse can also be run with DevTools network throttling to simulate poor connection and measure its impact on FCP and LCP. Some improvement can be made relatively easily via these practices:

• Applying CSS and JS minification
• Using newer compression algorithms like Brotli or zstd instead of gzip
• Using web-optimized image formats like AVIF and WebP
• Increasing compression levels for both images and payload

Reducing payload size will have a much larger effect on usability than simply reducing loading times over a slower network connection. Smaller payloads mean leaner pages, which often go with structural changes to page UI and UX, which in turn may support a transition to a leaner tech stack and will positively impact all Web Vitals metrics. In the last 15 years, the median page weight on the Web has increased sixfold for desktop devices. Have we got 6 times more usable websites now than we did back then? Addressing this bloat necessitates a paradigm shift from "more is better" to "less is more". Read more about a holistic approach to usability and performance in our blog post about Green UX.

The median increase in payload size is 550% for desktop and over 1750% for mobile!

Why Your eCommerce Pages Jump Around on Load—Fixing CLS Issues

CLS measures the change in the position of page elements as the page initially renders. The ideal value is 0 (i.e. no shift), and any value under 0.1 is considered "Good". Calculating CLS is somewhat non-trivial; for more information, refer to the Web Dev article on the topic.

The usual suspects causing poor CLS score are images. For example, it's common to see a blog article render the text content first, only to suddenly "jump" when the banner image is loaded. To avoid this, set the width and height HTML attributes on image elements to let the browser know how much space to reserve for them before they are fetched.

Another common source of layout shifts are page elements added to the DOM dynamically by client-side JS—think dynamic ads, product recommendations, and other 3rd-party content. There are two strategies to deal with them. One is to pre-render as much as possible on the server, so that the needed HTML is present on initial page load. In cases where it's impossible or costly, another way to reduce CLS is to create a container for the dynamic content and set its size explicitly via CSS.

Slow Click Response on Your Store? How to Diagnose and Fix Poor INP

Last but not least, Interaction to Next Paint is concerned with the responsiveness of the page after any user interaction is triggered, be it a mouse click, keyboard press, or screen touch. It is the hardest to measure "in the lab" and in Core Web Vitals, it is calculated as the worst delay between initiating user input and the page reacting to it with visual feedback (excluding some outliers). As with other CWV metrics, the 75th percentile is reported, and the page is considered to have good responsiveness if INP is below 200ms. The factors that cause poor INP are numerous, and the measurement will depend on the device used and other processes running on it.

The initial page render may affect INP in some cases, for example, when very large DOM rendering or un-deferred JavaScript block the main thread after the First Contentful Paint. This delay is represented in Lighthouse by the Total Blocking Time (TBT) metric. To address it, reduce all parser-blocking JS to a minimum. If possible, avoid large DOM trees as well. Where DOM size cannot be reduced, using the new content-visibility CSS property may help improve TBT, and thus INP.

Throughout the page visit, INP delay can be divided into three constituent phases:

Input delay is the time it takes for the browser to even start processing the interaction. It is caused by JS tasks already running and blocking the main thread. Ideally, such tasks should not exist on the client in the first place. Therefore, try to reduce costly operations, such as Virtual DOM lookup and modification. Other mitigation strategies worth considering:

• Split long tasks into smaller units and run them outside the main thread
• Use debounce and throttle techniques to avoid interaction overlap (be careful not to introduce additional delays to input feedback)
• Abort network fetch requests to reduce their processing time

Event callbacks run upon user input may contain resource-intensive computation and thus cause a delay. Look for ways to optimize them as much as possible. Any longer tasks triggered by input should be deferred to a separate thread (see the link above).

Presentation delay is the time it takes for the browser to actually render the changes to DOM after the callback has finished running. As with the initial render, optimizing the DOM size and using content-visibility can reduce the rendering time.

There is one quirk with INP—it does not actually care whether any visual feedback occurs. The metric simply measures the delay in interaction and the moment when the main thread is able to re-render. Therefore, if a callback triggers an asynchronous call, say, a network request and yields back to the main thread without any visual feedback, the INP score will not be negatively affected. Still, this is obviously bad user experience and must be addressed as well. The solution is simply to add a loading spinner on any other indication that the interaction was received and is being processed. Make sure to place the indicator such that it's clear it was caused by the interaction. Replace it with fetched content when available, or signal an error if one has occurred.

Core Web Vitals Troubleshooting Cheat Sheet: Problems, Causes, and Fixes

As you can see, there's a lot of symptoms and possible causes of poor website usability and performance. We summarized the problems and mitigation strategies in the table below.

Problem	Mitigation	Measuring	Diagnostic Tools
Large TTFB	Analyze where the bottleneck is: infrastructure (scalability, latency, server I/O, etc.), delivery (CDN, caching), or server application performance	TTFB metric (Web Vitals), problem-specific benchmarking tests	Application Performance Monitoring (APM) tools, Network tab in DevTools
Poor server application performance under low loads	Diagnose, monitor, and debug the server app (highly specific to each case)	APM, custom backend performance tests	APM and Observability tools, stack-specific debugging tools (e.g. Clinic.js for Node)
Poor server application performance under high loads	Increase server infrastructure, work on scalability	APM, Infrastructure load tests	Locust, k6
Large difference in FCP/LCP scores on good versus poor internet connection	Reduce payload & asset size, better compression, assets minification, de-prioritize and defer non-critical requests until after the initial render	Lighthouse (with network throttling)	Network tab in DevTools, Lighthouse
Large difference in FCP/LCP scores on desktop versus mobile	Use responsive UX, set appropriate srcset on image elements	Lighthouse, Web Vitals report	Lighthouse
Poor FCP score	All of the above + minimize render-blocking requests and parser-blocking JS scripts	Web Vitals report	Lighthouse, Performance tab in DevTools
Poor LCP score	All of the above + prioritize LCP element loading during initial render	Web Vitals report	Lighthouse
Poor CLS score	Add width and height attributes on image elements, pre-render markup on the server, look out for 3rd-party JS that inserts elements into DOM	Web Vitals report	Lighthouse, Performance tab
Poor INP score	Reduce DOM size, add content-visibility property to off-screen elements, indicate loading states when interaction triggers a network request, optimize event callbacks	Web Vitals report	Lighthouse (Timespan mode), Performance and Sources tabs, client-side JS debugging

Step 3: Prioritising Shopware 6 Performance Fixes— Remediation Roadmap

Now that the troubleshooting work is done and we've gathered all the issues and their mitigation strategies, the last step is to plan the remediation process. An effective way to prioritize the issues is to use the 2x2 Impact and Effort matrix. The X-axis is the perceived amount of effort required to resolve an issue, and the Y-axis represents the impact it would have (on performance) when completed.

The Impact and Effort matrix. The way you position the tasks greatly depends on your application architecture, infrastructure setup, your team's expertise, and even existing technical debt

After placing all the issues, we divide the space into four quadrants:

High Impact/Low Effort These are the so-called "Quick Wins", so resolving them first makes the biggest improvement in the shortest time.

High Impact/High Effort Important issues to resolve, yet usually require bigger, complex changes.

Low Impact/High Effort Those are not worth the effort.

Low Impact/Low Effort Optional improvements that can be picked up if there's spare time.

With the 2x2 matrix completed, our suggestion is to start right away with the High Impact/Low Effort items and get them to production fast. We could then already start seeing the results of our work, while continuing to further improve the performance by addressing the High Impact/High Effort issues.

Results: From Failing to Passing Core Web Vitals in Under 3 Months

Core Web Vitals historical data for Christopeit Sport

The auditing process we described here is a general template we follow with our clients, with some adjustments to better fix each business case. With Christopeit Sport, it took us about 2 weeks to perform the audit and another week to resolve the most important issues, which mainly concerned the INP and LCP metrics.

Within a week, we started seeing the Core Web Vitals report improve. Note that there is a time lag between the actual gains in performance and the CWV results reflecting that. This is because CWV relies on the Chrome User Experience dataset (CrUX for short). CrUX is updated daily, but the 75th percentile is calculated on the 28-day sliding window period. Thus, it takes roughly 28 days for the improvements to be fully reflected in the report. Moreover, the historical data is calculated on a weekly basis (likewise using the 28-day window), and is released every Monday—this is what you see on the image above.

Our Proven Web Performance Process for Fast Shopware 6 Stores

To sum up, web performance is one of the most impactful factors to usability, and thus success, of an eCommerce store. At Kiwee, we first conduct a comprehensive performance audit, including benchmarking, market positioning, frontend/backend testing, and infrastructure comparison.

We then identify the "quick wins" and resolve them first, while also outlining a long-term roadmap to ensure performance considerations are addressed at the architectural level and are baked into any future development and maintenance work. Throughout the process, we focus on concrete business outcomes rather than particular technological solutions, making sure the client and their customers start seeing marked improvement in mere weeks.

Tired of losing your shop visitors to poor usability and performance? Let's discuss how we can help you out!

• Performance
• SEO
• Shopware 6
• user experience