OpenCart und Next.js: Eine Frage des Storefronts

OpenCart gibt Ihnen bereits, wofür gehostete Plattformen Geld nehmen: den Katalog, den Warenkorb, den Checkout, Ihre Daten auf Ihrem Server und keinen Prozentsatz je Bestellung. Nichts davon steht hier zur Debatte, und keine Zeile dieser Seite schlägt vor, es zu ersetzen.

Zur Debatte steht etwas Engeres. OpenCart rendert auch Ihren Storefront, und nur darum geht es hier.

Was das Theme gut macht

Für einen Shop, der ein Shop ist, ist der Standard-Renderpfad in Ordnung. Produktseiten, Kategorieseiten, Suche, Warenkorb. Es ist servergerendertes HTML, es ist cachebar, und ein gepflegtes Theme auf ordentlichem Hosting ist schnell.

Wenn das Ihre Seite beschreibt, ist das Frontend nicht Ihr Problem, und ein Neubau würde eine ähnliche Seite zu erheblichen Kosten liefern. Messen Sie, bevor Sie anders entscheiden.

Die Messung, die zuerst kommt

Nehmen Sie die umsatztragenden Templates. Startseite, eine Kategorie, eine Produktseite. Lesen Sie Felddaten statt eines Laborwerts.

Die Ursachen einer langsamen Seite sind konkret und es sind nicht viele. Auf einem PHP-Storefront lautet die Antwort sehr oft: ein Hero-Bild, das der Browser spät entdeckt, eine Webfont, die das Zeichnen blockiert, und ein paar über die Jahre hinzugekommene Skripte für Analytics und Chat. Das sind Eingriffe auf Theme-Ebene, sie dauern etwa eine Woche und kosten einen kleinen Bruchteil eines neuen Frontends.

Machen Sie das zuerst. Werden die Zahlen gut, haben Sie Ihre Antwort, und ein Framework kam darin nicht vor.

Wo das Frontend wirklich anders werden muss

Es gibt eine echte Grenze, und sie ist nicht Geschwindigkeit.

Sie liegt dort, wo der Storefront Dinge tun muss, für die ein Template kein guter Behälter ist. Ein Konfigurator mit echter Interaktion. Filterung über einen großen Katalog, die schnell und verlinkbar sein muss. Ein eingeloggter Bereich mit eigenem Verhalten. Ein Design System, das mit etwas geteilt wird, das nicht der Shop ist. Inhalte, die eine eigene Rendering-Strategie verdienen statt eine an den Warenkorb geschraubte CMS-Seite zu sein.

Ab da geht es nicht mehr um Performance, sondern darum, was das Frontend ist. Das Rendering-Modell ist das, was man zuerst verstehen sollte, denn zu entscheiden, welche Routen statisch sind, welche revalidieren und welche dynamisch sind, ist der größte Teil des Entwurfs.

Wie es zusammenpasst

OpenCart behält Katalog, Warenkorb, Checkout und Backend. Next.js rendert den Storefront und spricht über die REST-API mit OpenCart, meist mit einer dünnen Schicht davor, weil diese API um den Warenkorb herum geformt ist und nicht darum, eine allgemeine Inhaltsquelle zu sein.

Der Checkout bleibt in den meisten Varianten, wo er ist. Zahlungsanbindungen und Bestellabwicklung funktionieren bereits, und sie zu verschieben ist eine eigene Entscheidung mit eigenem Risiko.

Der Umzug läuft Route für Route. Zuerst die Templates mit dem Traffic, alles andere weiter von OpenCart ausgeliefert, und eine schriftliche Notiz, welches System welche URL beantwortet. So schneiden wir diese Art Arbeit zu, und die URL-Zuordnung wird als Erstes vereinbart, nicht als Letztes.

Wann man es in Ruhe lässt

Ein Shop, der ein Shop ist. Niemand im Haus, der JavaScript schreibt. Produkte, die sich schneller drehen als der Code. Ein Erweiterungsbestand, der funktioniert und den jemand versteht.

Ein Theme, das jemand pflegt, schlägt einen Storefront, den niemand besitzt, und Letzteres haben Sie zwölf Monate nach einem Neubau ohne Übergabe.