--- title: 'Storefront, Performance, and Error-Free Behavior | Shopware Community Hub' description: >- Learn how to prepare storefront-facing extensions for responsive behavior, accessibility, performance, and error-free Store Review. canonical_url: >- https://hub.shopware.com/learn/unit/storefront-performance-and-error-free-behavior --- - Design storefront functionality reliably for mobile, tablet, and desktop. - Include performance and accessibility in quality assurance. - Test checkout and storefront stability before submission. - Identify and resolve issues such as console errors, HTTP 500 errors, or extension-related 404 errors early. # Storefront, Performance, and Error-Free Behavior Storefront-facing extensions are visible to the merchant's customers. If the layout breaks on mobile, checkout throws a JavaScript error, or a page becomes noticeably slower, the issue affects the shopping experience directly. That is why storefront quality is part of Store readiness. A Store extension should not only work in a developer environment. It should behave reliably across viewports, avoid avoidable errors, respect accessibility expectations, and avoid measurable performance regressions. In this unit, you will learn how to think about storefront quality before submission. ## Storefront Quality Is Visible Quality The storefront is the customer-facing layer of a Shopware shop. The storefront development documentation describes it as the place where extensions can add pages, modify templates, inject data, add JavaScript behavior, and customize styling and assets. Because this layer is visible to customers, small technical problems can become business problems: - A layout issue can reduce trust. - A JavaScript error can block interaction. - A slow page can hurt conversion. - A broken checkout flow can stop revenue. - A privacy issue can create legal or compliance risk. The important mental model is this: > Storefront quality is not only visual polish. It is part of the extension's functional reliability. ## Design for Mobile, Tablet, and Desktop The storefront, performance, and errors documentation states that Store extensions should support mobile, tablet, and desktop viewports. This means partners should test more than one browser width. A storefront extension may look correct on a desktop screen and still fail on a phone or tablet. Before submission, partners should check: - mobile viewport behavior - tablet viewport behavior - desktop viewport behavior - navigation and interaction states - checkout and product detail behavior where relevant - compatibility with the surrounding storefront layout The goal is not to create a separate design for every device. The goal is to make sure the extension does not break the store experience at common viewport sizes. ## Use Maintainable Styling Storefront extensions should not use inline CSS in storefront templates. Styling should be structured through classes and compiled CSS. This matters because inline CSS is harder to maintain, harder to override, and easier to spread across templates without a clear structure. It also makes it harder to reason about side effects. A maintainable styling approach should: - use clear CSS classes - keep styles in the extension's styling structure - avoid inline CSS in Twig templates - avoid `!important` unless there is no better option - keep the surrounding Shopware storefront design in mind Accessibility should also be considered early. Partners should check whether the extension remains usable with keyboard navigation, readable text contrast, meaningful labels, and predictable interaction behavior. ## Performance Is Part of Review Readiness An extension must not measurably impair store or server performance. We recommend running a Lighthouse audit before and after activating the extension. This helps partners compare the storefront with and without the extension and identify regressions in areas such as performance, accessibility, best practices, or SEO. For a first quality check, partners can ask: - Did page load or interaction become noticeably slower? - Did Lighthouse scores drop significantly after activation? - Does the extension load unnecessary JavaScript or CSS? - Are external resources required for critical storefront behavior? - Does the extension affect checkout performance? Lighthouse is not the only performance tool, but it gives a practical baseline. The important point is to compare the state before and after activation. ## Errors Must Be Found Before Review Storefront and checkout errors are review risks because they directly affect customer experience. Before submission, partners should check that the extension does not introduce: - JavaScript errors - console errors - HTTP 500 errors - extension-related 404 errors - unexpected 400 or 500 responses outside documented API behavior - unclear error messages The browser developer tools are useful for this. Partners should test the storefront and checkout with the console and network panel open, not only by looking at the visible result. Error messages should also be understandable. If something fails, the message should explain what happened or what the user should do next. ## Cookies and Privacy Need Clear Handling If a storefront extension sets cookies or processes personal data, privacy behavior must be considered. Cookies set through the shop URL should be registered correctly in the Cookie Consent Manager. They should only be classified as technically required when they are essential for the shop to function. Partners should also consider whether the extension uses external services or processes personal data. If personal data is processed by external processors, the Store listing and related account fields may need to reflect that. For Store readiness, ask: - Does the extension set cookies? - Are cookies registered in the correct consent category? - Are optional cookies unchecked by default where required? - Does the extension use external services that process personal data? - Is this behavior disclosed clearly? Privacy behavior is not separate from storefront quality. It is part of building a trusted customer-facing extension. ## Example: Testing a Storefront Banner Extension Imagine a partner builds an extension that displays a promotional banner in the storefront. The banner looks simple, but it still needs review-ready behavior: - It should fit mobile, tablet, and desktop layouts. - It should not use inline CSS in Twig templates. - It should not overlap checkout or navigation elements. - It should not create console errors. - It should not add measurable performance regressions. - It should be accessible, readable, and keyboard-safe where interaction is involved. - If it sets a cookie to remember that the banner was closed, the cookie needs correct consent handling. This example shows why storefront quality is broader than design. It combines layout, performance, accessibility, error handling, and privacy. ## Common Pitfalls ### Testing Only on Desktop Many storefront issues appear only on smaller viewports. Mobile and tablet behavior should be part of the submission check. ### Styling Directly in Templates Inline CSS can make the extension harder to maintain and review. Use structured classes and compiled styling instead. ### Ignoring the Browser Console The page may look correct while JavaScript errors still appear in the console. Those errors can affect other interactions later. ### Treating Lighthouse as Optional Decoration Lighthouse audits help partners catch performance, accessibility, best practice, and SEO regressions before Store Review. ### Forgetting Cookie Consent Cookies and personal data behavior must be handled transparently. Hidden tracking or incorrectly classified cookies can create review and compliance problems. ## Summary - Storefront extensions should work reliably on mobile, tablet, and desktop. - Styling should be maintainable, avoid inline CSS, and respect the surrounding Shopware storefront. - Performance and accessibility should be checked before and after activation, for example with Lighthouse. - Storefront and checkout must not contain JavaScript errors, console errors, HTTP 500 errors, or extension-related 404 errors. - Cookie and privacy behavior should be handled clearly and disclosed where required. Next, you will connect these technical quality expectations into the course overview for Extension Quality and Integration Readiness.