Hyvä für Magento

Das Problem lautet nicht immer: „Unser PageSpeed-Wert ist schlecht.“

Wichtiger ist, dass das Frontend mit der Zeit zu einem Hindernis für die Weiterentwicklung des Shops geworden ist. Jede weitere Änderung wird schwieriger, der Code komplexer, die Performance bleibt schwach und ein geplantes Redesign würde einer ohnehin modernisierungsbedürftigen Lösung zusätzliche Schichten hinzufügen.

Für neue Magento-Implementierungen empfehlen wir standardmäßig Hyvä. Wir bauen auch bestehende Storefronts mit Hyvä neu auf, wenn die alte Frontend-Schicht die Weiterentwicklung zu begrenzen beginnt.

Wir können den gesamten Prozess übernehmen: von Analyse und UX/UI über Entwicklung und Checkout bis zu Tests und Go-live.

Ein kostenloses Gespräch von 30–60 Minuten. Wir besprechen Ihr aktuelles Frontend, die Performance-Ergebnisse und die Rahmenbedingungen der Implementierung. Sie erhalten eine erste Einschätzung, ob Hyvä der richtige Weg ist und welche Analyse erforderlich ist.

Anzeichen

Wenn das Frontend zum begrenzenden Faktor wird

Probleme entstehen meist schrittweise.

  • Der Shop ist trotz einer guten Backend-Antwortzeit langsam.
  • Eine scheinbar kleine Änderung erfordert Eingriffe in mehrere Codeebenen.
  • Weitere Individualisierungen erhöhen die Wartungskosten.
  • Die Werte in Google-Tools bleiben trotz weiterer Korrekturen schwach.

Ein häufiger gemeinsamer Nenner ist ein über Jahre auf einem älteren Stack entwickeltes und mit individuellem Code erweitertes Frontend.

An diesem Punkt können weitere punktuelle Korrekturen ihre Wirtschaftlichkeit verlieren. Dann sollte geprüft werden, ob ein Neuaufbau der Präsentationsschicht sinnvoller ist.

Grundlage

Was Hyvä verändert

Hyvä bietet eine einfachere und schlankere Grundlage für das Magento-Frontend.

Einfachere Weiterentwicklung

Weniger Schichten und Abhängigkeiten vereinfachen spätere Änderungen. Dadurch lässt sich das Frontend leichter warten und verlässlicher weiterentwickeln.

Weniger Overhead

Hyvä reduziert den für die ältere Magento-Frontend-Schicht typischen Overhead deutlich.

Eine bessere Basis

Das schafft eine bessere Grundlage für die Arbeit an den Core Web Vitals und der tatsächlichen Geschwindigkeit der Oberfläche.

Ein bestimmter Wert ist damit jedoch nicht garantiert - das Ergebnis hängt auch von Backend, Bildern, Drittanbieter-Skripten, Umsetzung und Infrastruktur ab.

Ein Neuaufbau ist eine gute Gelegenheit, nicht jede historische Individualisierung weiterzuführen.

Einige werden weiterhin benötigt und müssen an Hyvä angepasst werden. Andere lassen sich vereinfachen oder vollständig entfernen.

Grenzen der Technologie

Was Hyvä nicht behebt

Hyvä löst Probleme der Frontend-Schicht.

Es beschleunigt keine langsame Datenbank und behebt weder fehlerhafte Integrationen noch Probleme mit Indexierung, OpenSearch oder einer ungeeigneten Infrastruktur.

Wenn das Backend lange für eine Antwort benötigt, muss auch ein schlankes Frontend darauf warten.

Deshalb prüfen wir vor der Empfehlung eines Neuaufbaus, wo die tatsächliche Einschränkung liegt.

Liegt das Problem im Backend, ist der richtige Ausgangspunkt Magento-Performanceoptimierung →

Szenarien

Neue Implementierung oder Neuaufbau eines bestehenden Magento-Shops

Wir arbeiten in zwei Hauptszenarien mit Hyvä.

Hyvä ist unsere Standardwahl für neue Magento-Storefronts

So entsteht die neue Plattform von Anfang an auf einem Frontend, das weiterentwickelt werden soll, anstatt das Projekt mit einer älteren Technologieschicht zu beginnen.

Das Magento-Backend kann bleiben, während die Präsentationsschicht neu aufgebaut wird

So lässt sich das problematische Frontend entfernen, ohne die gesamte Plattform von Grund auf neu aufzubauen.

Ein solches Projekt erfordert jedoch vorab die Entscheidung, welche Teile der bestehenden Lösung tatsächlich übernommen werden sollten.

Altsystem

Wir kopieren das alte Frontend nicht eins zu eins

Ein Neuaufbau mit Hyvä sollte nicht bedeuten, automatisch jede Funktion und Individualisierung des alten Shops nachzubauen.

Vor Beginn der Entwicklung klären wir:

  • was tatsächlich genutzt wird,
  • welche Bestandteile weiterhin geschäftlich sinnvoll sind,
  • was sich vereinfachen lässt,
  • welche Lösungen allein wegen Einschränkungen des bisherigen Frontends entstanden sind.

Dadurch startet die neue Schicht nicht mit technischen Schulden aus der vorherigen Lösung.

UX/UI

UX/UI kann Teil des Projekts sein

Der Kunde muss kein fertiges Design mitbringen.

Wir können den vollständigen UX/UI-Prozess durchführen, das Interface gestalten und anschließend mit Hyvä umsetzen.

Wir können auch mit einem Design arbeiten, das vom Team des Kunden oder einer anderen Agentur geliefert wurde.

Der Wechsel zu Hyvä ist oft ein guter Zeitpunkt für ein Redesign, doch ein Redesign ist kein zwingender Bestandteil des technologischen Neuaufbaus.

Checkout

Hyvä und Checkout

Wir betrachten den Checkout als Teil der gesamten User Experience und nicht als separates Produkt, das an den Storefront angehängt wird.

Das Projekt kann auch die Checkout-UX und die Implementierung einer passenden Checkout-Lösung im Hyvä-Ökosystem umfassen.

Das ist besonders wichtig, wenn der Checkout des alten Shops zu den Bereichen mit dem größten Änderungsbedarf gehört.

Kompatibilität

Individuelle Module und Kompatibilität

Die Änderung des Magento-Frontends endet nicht mit der Installation eines neuen Themes.

Alle Elemente mit eigener Frontend-Schicht müssen geprüft werden:

  • Magento-Module,
  • individuelle Funktionen,
  • Zahlungen,
  • Versandarten,
  • Analytics,
  • Marketing-Tools,
  • Integrationen, die im Browser ausgeführt werden.

Einige Erweiterungen sind bereits mit Hyvä kompatibel. Andere müssen angepasst werden, und in manchen Fällen ist es sinnvoller, ein altes Modul durch eine einfachere Lösung zu ersetzen.

Deshalb berücksichtigen wir die Kompatibilität von Erweiterungen bereits bei der Umfangsanalyse und nicht erst am Ende der Entwicklung.

Prozess

So läuft ein Hyvä-Projekt ab

Der Umfang kann die Analyse eines bestehenden Frontends oder Discovery für einen neuen Shop, UX/UI, Hyvä-Entwicklung, die Anpassung von Modulen und individuellen Funktionen, Checkout, Tests, Go-live und Stabilisierung umfassen.

  1. 01

    Analyse

    Analyse des bestehenden Frontends oder Discovery für einen neuen Shop.

  2. 02

    UX/UI

    Konzeption von User Experience und Benutzeroberfläche.

  3. 03

    Entwicklung

    Frontend-Implementierung mit Hyvä.

  4. 04

    Anpassung

    Anpassung von Modulen und individuellen Funktionen.

  5. 05

    Checkout und Tests

    Checkout-Implementierung und Tests der gesamten Lösung.

  6. 06

    Go-live

    Go-live und Stabilisierung der neuen Frontend-Schicht.

Nicht alle Arbeiten müssen nacheinander erfolgen. UX/UI, die Entwicklung ausgewählter Elemente und Integrationsarbeiten können teilweise parallel stattfinden.

Projektkontext

Hyvä als Teil einer umfassenderen Veränderung

Ein Frontend-Neuaufbau ist nicht immer ein eigenständiges Projekt.

Hyvä kann Teil sein von:

  • einer neuen Magento-Implementierung,
  • eines Redesigns,
  • eines Optimierungsprojekts,
  • einer Projektrettung,
  • einer umfassenderen Modernisierung eines bestehenden Shops.

Entscheidend ist, welches Problem wir lösen möchten.

Wenn das bestehende Frontend gut funktioniert, leicht zu warten ist und nur eine kosmetische Änderung benötigt wird, kann ein Technologiewechsel unnötige Kosten verursachen.

Velocity

Warum Velocity

Hyvä ist unsere Standardrichtung für neue Magento-Implementierungen.

Beim Neuaufbau bestehender Shops ist außerdem wichtig, dass wir nicht nur an der Frontend-Schicht arbeiten. Wir verstehen Magento-Backend, Datenbank, OpenSearch, Integrationen und Infrastruktur.

So können wir zunächst prüfen, ob das Problem tatsächlich im Frontend liegt, statt anzunehmen, Hyvä sei die Antwort auf jedes Performanceproblem.

Wir können auch nach dem Go-live bei der Plattform bleiben und ihre Weiterentwicklung sowie Wartung verantworten.

Die richtige Richtung

Wann Hyvä nicht die richtige Lösung ist

Magento-Performanceoptimierung

Wenn das Hauptproblem ein langsames Backend ist, ist die Magento-Performanceoptimierung der richtige Ausgangspunkt.

Magento-Performanceoptimierung →

Magento-Projektrettung

Wenn die gesamte Plattform instabil ist, Fehler immer wieder auftreten und ihr technischer Zustand schwer einzuschätzen ist, kann die Übernahme und Stabilisierung des Magento-Projekts der erste Schritt sein.

Magento-Projektrettung →

Eine visuelle Änderung

Geht es ausschließlich um ein neues Erscheinungsbild und ist das bestehende Frontend gesund und wartbar, kann ein Technologiewechsel wirtschaftlich nicht gerechtfertigt sein. Wir empfehlen Hyvä auch nicht allein, um einen bestimmten PageSpeed-Wert zu erreichen. Zunächst muss geklärt werden, was den Shop tatsächlich begrenzt.

Fragen

FAQ

VLCT

Wenn ein wesentlicher Teil des Problems in der Frontend-Schicht liegt, kann Hyvä eine deutliche Verbesserung bringen. Eine langsame Datenbank sowie Probleme mit Indexierung, OpenSearch oder Integrationen behebt es jedoch nicht. Vor einer Empfehlung klären wir, wo tatsächlich Zeit verloren geht.

VLCT

Hyvä bietet eine schlankere Frontend-Basis und erleichtert die Arbeit an den Core Web Vitals, garantiert jedoch keinen bestimmten Wert. Der Engpass kann weiterhin im Backend, bei Bildern, Drittanbieter-Skripten, der Suche oder der Infrastruktur liegen.

VLCT

Nein. Wir können die bisherige visuelle Richtung beibehalten oder das Projekt als Gelegenheit für ein Redesign nutzen.

VLCT

Einige sind bereits mit Hyvä kompatibel, andere müssen angepasst werden. Manchmal ist es sinnvoller, eine alte Erweiterung durch eine andere Lösung zu ersetzen. Das prüfen wir bei der Analyse des Umfangs.

VLCT

Ja. Wenn Backend und übrige Architektur in gutem Zustand sind, kann die bestehende Plattform erhalten bleiben und nur die Frontend-Schicht neu aufgebaut werden.

VLCT

Ja. Wir können das vollständige UX/UI erstellen oder ein vom Kunden geliefertes Design umsetzen.

VLCT

Ja. Wir betrachten den Checkout als Teil des Frontends und der Customer Journey. Daher kann er gemeinsam mit der übrigen Hyvä-Schicht konzipiert und umgesetzt werden.

VLCT

Ja. Damit lassen sich auch Oberflächen für B2B-Prozesse erstellen, darunter Schnellbestellungen, Firmenkonten und weitere individuelle Abläufe. Mehr: B2B-E-Commerce →