WordPress oder Next.js: Wann ein Theme nicht mehr reicht
Beide liefern HTML an einen Browser, dieser Vergleich ist also anders als die meisten wirklich direkt. Für die meisten Sites gewinnt WordPress bei den Betriebskosten. Hier endet das.
Die meisten Seiten, die diese Frage beantworten, stammen von einer Firma, die eines von beidem verkauft. Also zuerst die Offenlegung: Wir bauen Next.js-Anwendungen, und für einen großen Teil der Sites, die hier landen, lautet unsere Antwort, dass Sie auf WordPress bleiben sollten.
Die ehrliche Ausgangslage
Eine Broschürenseite, ein Blog, eine Unternehmensseite, eine Publikation mit Redaktion. Das macht WordPress gut, günstig und mit einem Wartungsweg, der kein Frontend-Team braucht. Ein Umzug zu Next.js kauft eine theoretisch schnellere Seite und kostet Sie ein Redaktionserlebnis, ein Plugin-Ökosystem und eine Hosting-Rechnung, die vorher belanglos war.
Wenn auf Ihrer Seite niemand nach uns eine JavaScript-Codebasis übernimmt, ist das keine Randbedingung. Das ist die ganze Antwort.
Was Sie tatsächlich aufgeben
Diesen Teil lassen die Vergleichsseiten aus, hier also als Liste.
Den Editor. Nicht das Textfeld, das Ganze. Vorschau, Revisionen, geplante Veröffentlichung, Medienverwaltung und der Block-Editor, für den Ihr Team Muskelgedächtnis hat. Einiges kommt zurück. Nichts davon kommt umsonst zurück.
Formulare. Ein Kontaktformular ist in WordPress ein Plugin. In Next.js sind es vier Entscheidungen: wohin es postet, was Spam stoppt, wo die Einsendung liegt und wer davon erfährt.
Das SEO-Plugin. Yoast und Verwandte stellen Metadaten, Sitemaps, Weiterleitungen und Schema hinter eine Oberfläche, die eine Marketing-Person bedienen kann. In Next.js ist das Code. Am Ende ist das besser, weil das falsche Tag unmöglich statt bloß unerwünscht wird, aber an Tag eins ist es Arbeit, die jemand machen muss.
Weiterleitungen. Verwaltet in einer Admin-Maske oder verwaltet im Code. Nur eines davon kann Ihr Marketing-Team freitags um fünf erledigen.
Wo ein Theme aufhört, der richtige Behälter zu sein
Es gibt eine echte Grenze, und sie ist weder Traffic noch Seitenzahl.
Sie liegt dort, wo das Frontend anfängt, Anwendungsverhalten zu haben. Eingeloggter Zustand, der ändert, was eine Seite zeigt. Filterung über Tausende Einträge, die schnell und verlinkbar sein muss. Ein Design System, das mit einem Produkt geteilt wird, das nicht die Website ist. Personalisierung. Ein Checkout, den Sie tatsächlich kontrollieren.
Ein Theme lässt sich in all das hineindrücken. Wir haben es gesehen. Das Ergebnis sind PHP-Templates mit mehreren Tausend Zeilen jQuery darauf, eine Caching-Schicht, die für die Hälfte der Routen umgangen werden muss, und niemand, der den Header anfassen will.
Core Web Vitals, was nicht das Argument ist, für das Sie es halten
Ein gut gebautes WordPress-Theme auf ordentlichem Hosting schlägt eine schlecht gebaute Next.js-Anwendung. Wir haben beides oft genug gemessen, um das deutlich zu sagen.
Das Framework ist nicht die Variable. Über LCP entscheidet, wann der Request für das größte Element startet, und eine Next.js-Site bekommt das genauso leicht falsch hin wie ein Theme. Was Next.js gibt, ist eine höhere Decke und Werkzeuge, sie in der CI zu verteidigen. Den Boden bekommen Sie nicht geschenkt.
Wenn Ihnen jemand einen Neubau mit dem Versprechen eines grünen Scores verkauft, fragen Sie, wie der Score jetzt ist und was die Zahl verursacht. Meist sind es drei Bilder und eine Schrift.
Headless WordPress, der Mittelweg
WordPress bleibt die Redaktionsoberfläche. Gerendert wird mit Next.js. Die Redaktion behält ihr Werkzeug, die URLs bleiben Ihre, und das Frontend bekommt die Grenze, die ihm gefehlt hat.
Das ist eine legitime Architektur und oft der günstigste Weg. Es ist auch die Stelle, an der diese Projekte schiefgehen, auf genau eine Art: die Vorschau. Können Redakteure einen Entwurf nicht so sehen, wie er wirklich erscheinen wird, verlieren sie binnen eines Monats das Vertrauen, und das Ganze wird aus Gründen abgeschrieben, die mit Rendering nichts zu tun haben.
Wie man ohne Neuentwicklung entscheidet
Nehmen Sie die zwei oder drei Templates, die Ihren Traffic und Ihre Conversions tragen. Nicht die ganze Site.
Wenn sie schlecht sind wegen Bildern, Schriften und einem Plugin, das etwas Albernes tut, ist das ein WordPress-Problem mit einer WordPress-Lösung, zu einem Bruchteil der Kosten eines Neubaus. Wenn sie schlecht sind, weil die Seite eine Anwendung sein muss und ein Template ist, haben Sie Ihre Antwort. Ziehen Sie diese Routen zuerst um und lassen Sie den Rest, wo er ist.
Wo das Frontend wirklich eine Anwendung werden muss, ist das der Bau. Wo nicht, und die ehrliche Antwort lautet, dass Next.js für Ihre Site das falsche Werkzeug ist, gibt es auch dazu eine Seite.
Ein Shop auf Shopify ist noch einmal ein anderes und kürzeres Gespräch. Shopify bleibt dort so oder so, entschieden wird also nur, wer den Storefront rendert.
