Die leistungsstärkste

für Magento erstellt mit Vue.js

Open-Source StoreFront X PWA hilft Ihnen, in allen Lighthouse-Metriken die beste Punktzahl zu erreichen und Ihren Online-Shop ohne unnötige Komplikationen anzupassen. Dank modularer Architektur und intelligentem build-time Tree Shaking.

Performance matters

Das StoreFront X-Framework übertrifft ähnliche Produkte in allen Lighthouse Performance Score-Metriken. Hier können Sie die Leistung Ihres Online-Shops überprüfen.

StoreFront X maximiert die Website-Geschwindigkeit und andere Metriken, verbessert die Konversionsrate und CX Ihrer Website und unterstützt SSR.

Hochgradig anpassbar

Alles in StoreFront X ist leicht anpassbar. Von Design, Funktionen, Geschäftslogik bis hin zu Integrationen und vielem mehr. StoreFront X passt sich immer an Ihre Bedürfnisse an.

Skalierbar

Die modulare Architektur macht StoreFront X zur idealen Lösung für Projekte jeder Größe. Es besteht aus einem minimalen Kern und zusätzlichen Modulen für spezifische Funktionen, wodurch es leicht skalierbar ist.

Verbessert SEO

StoreFront X unterstützt Sie bei der Verbesserung der Suchmaschinenoptimierung durch seine überragende Leistung (es verbessert Google Web Vitals), serverseitiges Rendering und Metatags-Module wie Schema.org oder Open Graph.

Kombiniert das Beste aus anderen Frameworks

  StoreFront X vereint die besten Eigenschaften von SSR- und SPA/PWA-Ansätzen in einer modernen Plattform.
  Verwendet GraphQL für minimalen Datentransfer (unterstützt REST und andere Protokolle).
  Beinhaltet einen kleinen Server für Backend-Funktionen (Bildgrößenanpassung, Proxying, etc.).
✔  Verwendet einen modernen Headless-Ansatz für eine einfache und unabhängige Bereitstellung.
✔  Enthält integrierte Best Practices und Architekturrichtlinien, um jede Anwendung leistungsfähig zu machen.
✔  Ermöglicht eine schnellere Time-to-Market.

Grundlegende Funktionen
(für Magento)

Einfache Architektur...

StoreFront X ist leicht anpassbar, skalierbar und leistungsstark. Aus diesem Grund ist seine Architektur modular aufgebaut. Es besteht aus einem sehr kleinen Kern und zusätzlichen Modulen für spezifische Funktionen. Der große Vorteil dieser Art von Architektur ist ihre positive Auswirkung auf die Leistung, die für jeden E-Commerce-Shop entscheidend ist. Wichtig ist, dass der Code der deaktivierten Module überhaupt nicht an den Client gesendet wird.

Erfahren Sie mehr über Module

Die Anwendung ist in viele kleine Module unterteilt (Katalog, Blog, Kasse). Sie können zum Beispiel ein eigenes Modul mit Bestsellern erstellen und diese Funktion in den Katalog einfügen. Sie können viele verschiedene Module haben und diese nach eigenem Ermessen ein- und ausschalten.

Was aber, wenn Sie einige Module ändern möchten? Das ist der Punkt, an dem Überschreibungen ins Spiel kommen.  

  • Module sind in der Lage, das Verhalten anderer Module zu ändern, so dass Sie jeden Teil des StoreFront X-Systems modifizieren können. 

  • Gefällt Ihnen das Standardthema, aber nicht die Fußzeile? Kein Problem, Sie können es ändern.

  • Sendet die Methode "In den Warenkorb legen" nicht alle Daten an Ihren benutzerdefinierten API-Endpunkt? Das können Sie ändern.

  • Möchten Sie StoreFront X mit einem anderen Backend als Magento integrieren? Das können Sie tun.

Dies alles basiert auf unserem leistungsstarken Container für die Injektion von Abhängigkeiten, der bereits während der Erstellung vollständig aufgelöst und kompiliert wird. Das bedeutet, dass es zur Laufzeit keinen unnötigen Overhead gibt.

...und einfache Infrastruktur

StoreFront X verwendet keine Middleware oder zusätzliche Dienste. Es kommuniziert direkt mit der Backend-API über einen einfachen integrierten Proxy. Daher ist es einfach zu implementieren und zu warten. Das bedeutet jedoch nicht, dass StoreFront X nicht mit verschiedenen Back-End-APIs integriert werden kann. Anstelle eines Middleware-Dienstes verwendet StoreFront X seine Module als Abstraktionsschicht zwischen der Präsentationslogik und den verschiedenen Back-End-APIs.

Mit diesem Ansatz können Sie einen besseren Time to Interactive und Total Blocking Time erreichen (JavaScript wird nur benötigt, wenn es an den Browser gesendet wird).

Die Magie des Server-Side Rendering

Stellen Sie sich eine Situation vor: Sie wollen auf eine Schaltfläche klicken, und eine Sekunde bevor Sie klicken, erscheint an der gleichen Stelle eine Anzeige oder ein Bild und Sie klicken stattdessen. Wie kann man eine solche Horrorszene vermeiden? Verwenden Sie SSR! Das serverseitige Rendering (SSR) ermöglicht es Ihnen, die wichtigsten Inhalte bereits bei der ersten Anfrage an den Client zu senden. Dadurch sehen die Nutzer die Anwendung fast sofort und ohne lästige Layoutverschiebungen. 

Ein besseres Nutzererlebnis durch SSR erhöht die Konversionsraten und verringert die Absprungraten. Es wirkt sich auch positiv auf Web Vitals aus:

  • 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) 
  • Bessere First Contentful Paint (Inhalt ist sofort sichtbar)

  • Bessere Largest Contentful Paint (große Bilder sind vorgetaggt und daher sofort sichtbar)

  • Null Cumulative Layout Shift (serverseitiges Markup schützt die Seite vor dem Scrollen, wenn dynamische Inhalte geladen werden)

Vor allem aber führt SSR zu besserer SEO und besseren SERP-Rankings. Für Suchmaschinen ist es einfacher, serverseitig gerenderte Anwendungen zu crawlen als Anwendungen, die nur JavaScript enthalten. Zusammenfassend lässt sich sagen, dass das serverseitige Rendering nicht nur eine Win-Win-Lösung ist. Es ist eine Win-Win-Win Situation.

Wie lassen sich die Auswirkungen von JavaScript auf die Leistung beseitigen?

JavaScript ermöglicht es uns, interaktive Websites zu erstellen, die den Nutzern ein gutes Erlebnis bieten. Wenn jedoch zu viel JavaScript verwendet wird, gibt es ein Problem: Es dauert sehr lange, bis eine Seite interaktiv und reaktionsfähig wird. Dies gilt insbesondere für mobile Geräte, die bis zu 50 % des gesamten Datenverkehrs ausmachen. Unsere Lösung? SSR, zusammen mit einem Schwerpunkt auf Lazy Loading, Lazy Hydration und fortgeschrittenem Tree Shaking während der Entwicklung.

Im Wesentlichen bedeutet dies, dass die Seite in kleinere Abschnitte/Blöcke unterteilt wird und im Voraus entschieden wird, wann das JavaScript geladen werden soll. Einige JavaScript-Blöcke müssen sofort geladen werden (z. B. Warenkorb oder Produkte), andere werden bei Interaktion geladen (z. B. Menü, Filter, Suche), andere werden geladen, wenn der Block angezeigt wird (z. B. Fußzeile), und einige JS können nie oder nur bei Bedarf geladen werden (Logo, Breadcrumb-Navigation). 

Wie sieht es mit der Sichtbarkeit aus?

Das bedeutet nicht, dass diese Komponenten nicht sichtbar sind. Der Benutzer kann sie normal sehen. Allerdings laden wir den Code für die Interaktivität nur dann, wenn er tatsächlich benötigt wird. Zum besseren Verständnis sehen Sie sich das folgende Bild an.

Wie wirkt sich dieser Ansatz auf Web Vitals aus? 

Sie erreichen eine geringere Time to Interactive (JavaScript wird nur geladen, um mit der Komponente zu interagieren) und eine geringere Total Blocking Time (weniger JavaScript wird heruntergeladen und ausgeführt).