Best-performing

for Magento built with Vue.js

StoreFront X will help you achieve the top score in all Lighthouse metrics and easily customize your online store without unnecessary complications. Thanks to modular architecture and smart build-time tree shaking.

Performance matters

StoreFront X framework outperforms similar products in all Lighthouse Performance Score metrics. Here you can check how your online store is performing. 

StoreFront X maximizes website speed & other metrics, improves conversion rate and CX of your website and supports SSR.

Highly customizable

In StoreFront X, everything is easily customizable. From design, functionality, business logic to integrations, and much more. StoreFront X will always adapt to your needs.

Scalable

 Thanks to its modular architecture, StoreFront X is the ideal solution for projects of any size. It consists of a minimal core and additional modules for particular features so it easily scalable.

Improves SEO

StoreFront X will help you with SEO thanks to the excellent performance (improves Google's Web Vitals), server-side rendering and modules for meta-tags like Schema.org or Open Graph. 

Combines the best from other frameworks

 ✔ StoreFront X combines the best features from SSR and SPA/PWA approaches into one modern platform.
✔  Uses GraphQL for minimal data transfer (REST and other protocols supported).
✔  Contains a small server for backend-related features (image resizing, proxy, etc.).
✔  Uses the modern headless approach for simple, independent deployment.
✔  Comes with built-in best practices and architecture guidelines to make every app performant.
✔  Provides a better Time to Market.

Simple architecture...

StoreFront X is designed to be easily customizable, scalable, and high-performing at the same time. Therefore, its architecture is modular. It consists of a very small core and additional modules for particular functionalities. A great advantage of this type of architecture is its positive effect on performance, which is crucial for every e-commerce business. The important part here is that code from turned-off modules is not sent to the client at all.

Learn more about modules

The application is divided into many small modules (catalog, blog, checkout). For example, you can create your own module with bestsellers and add this functionality to the catalog. You can have a lot of different modules and turn them off and on as you wish.

What if you want to change some modules? That’s when overriding comes into play. 

  • Modules are able to change the behavior of other modules, which allows you to modify any part of StoreFront X. 
  • Do you like the default theme but not the footer? No problem, you can change it.
  • Doesn't the" add to cart" method send some data to your custom API endpoint? You can change that.
  • Do you want to integrate StoreFront X with a different backend other than Magento? You fix that.

All of this is built on top of our powerful dependency injection container, which is fully resolved and compiled out during build-time, which means no unnecessary overhead during runtime.

...and simple infrastructure

Many generic frontends use middleware service as an abstraction translating requests to different backend APIs. This type of architecture is unnecessarily complicated and hard to maintain. When modifying one service, the other service has to be modified too, and both deployed simultaneously.

StoreFront X does not use middleware or any additional services. It communicates with the backend API directly via a simple built-in proxy server. Therefore, it is easy to deploy and maintain. However,  this does not mean that StoreFront X can’t be integrated with different back-end APIs. Instead of a middleware service, StoreFront X leverages its modules as an abstraction layer between presentation logic and different back-end APIs. 

How does this approach impact Web Vitals? 

This approach allows you to achieve better Time to Interactive and Total Blocking Time (JavaScript is only needed when sent to the browser).

The server-side rendering magic

Imagine that: you want to click a button, and a second before clicking, an ad or image appears in the same place, and you click on it instead. How to avoid this kind of horror scene? Use SSR! Server-side rendering (SSR) allows you to send the most important content to the client during the initial request. As a result, users will see the app almost immediately and without annoying layout shifts.

Better UX, improved by SSR, boosts conversion rate and decreases bounce rate. It also positively affects Web Vitals:

  • Better First Contentful Paint (content is visible right away)
  • Better Largest Contentful Paint (large images are pre-tagged and therefore visible right away)
  • Zero Cumulative Layout Shift (server-rendered markup protects the page from scrolling when dynamic content is loaded) 

And most importantly, SSR leads to better SEO and better SERP ranking. It's easier for search engines to crawl server-side rendered applications than those containing  JavaScript only. Let’s sum it up, server-side rendering is not just a win-win solution. It's a win-win-win one.

How to eliminate the effect of JavaScript on performance?

JavaScript allows us to create interactive websites with good UX. However, when there’s too much JavaScript, you have a problem - it takes a long time for a page to become interactive and responsive. This happens especially on mobile devices that make up to 50% of total traffic. Our solution? SSR, along with a focus on lazy loading, lazy hydration, and advanced tree shaking during build time.

Basically, this means breaking the page into smaller sections/blocks where you decide in advance when to load the JavaScript. Some JavaScript blocks must be loaded immediately (like cart or products), some will load on interaction (like menu, filter, search), some will load when we see the block (like footer), and some JS may load never or only on demand (logo, breadcrumb navigation). 

How about visibility?

This doesn't mean that these components are not visible. The user sees them normally. We only load the necessary code for their interactivity when it is actually needed. For a better understanding, take a look at the diagram.

How does this approach impact Web Vitals?  

You will reach lower Time to Interactive (JavaScript is loaded only to interact with the component) and lower Total Blocking Time (less JavaScript is downloaded and executed).

Basic features