This article covers more than just common performance issues you might encounter during a project’s lifecycle. It also describes a workflow that can make your life easier for future projects by building performance optimization into your development process from day one.
It feels wrong if you know ecommerce systems and then use Shopware's variants for the first time. You click on a variant, and the entire storefront page is reloaded. This is very helpful (and good for SEO) if your variants differ in text and images. But it isn't delightful if the server is not very fast. Also, if you have many similar options in text and pictures. There is also the use case where you want to show all possible options on the product listing page (category). So you may ask yourself if you need to invent the wheel for a more configurable approach to the Variants Selection. Or how could you improve this in a simple, fast, composable, and headless frontend?
With Composable Frontends, you can create your own JavaScript/Typescript based API Client from your local or online running Shopware 6 Instance. This brings you the advantage that all Custom Endpoints are also included in the API Client if they have a proper OpenAPI Schema definition. In this post, I describe how and what steps are needed to do so.
How would we work without an API? If you were debugging something right now, you would surely say "much better" 😉 But let's face it, without an API, the modern e-commerce world wouldn't work at all. And what do we do to make sure our API works the way we expect it to? How do we test our API? How do we validate our schema?
The question is always where to fix a problem. For example, if data is missing from an API, you could fix that with a second request or change the response of the first request. So in a headless setup, you always want to have the minimum amount of data you need, but things will always change and you need more data or data in a different structured form. So you might find yourself talking to backend developers to optimize the API, or moving logic to the frontend that doesn't actually have anything to do with the frontend. So in this blog post, let's look at how we can add a layer between frontend and API to transform and optimize our data according to our needs. Plus we can add caching (if needed) very easily to make it blazing fast.
You already heard about the new Shopware Frontends? It uses the headless approach known from 😇 the administration area of Shopware. In general Shopware provides an admin API, the sync API and the store API. So basically the store API is for every action that a website visitor can do in your store. But to be honest Shopware Frontends is not a out-of-the-box solution. You need developers that can put every headless thing together for you. In this blog post I want to show how easy you can add your own Vue.js composable that will get additional data from another source into your Shopware Frontend. Let's look into some code 🚀
When you think about the core web vitals then you will find this claim "Avoid an excessive DOM size". This is easy to say, but sometimes hard to achieve. Also the page about dom-size at web.dev gives you only some general advices. When you once had a page that is really slow, just because someone created a quantity select element with over 500 options for every product on a category page with 48 products. And then Lighthouse tells you that the DOM size should be below 12.000 elements.
