Next.js vs. WordPress: Warum ich meine persönliche Website migriert habe
Next JS
Meine eigene Website, peterwindholz.at, lief lange Jahre auf WordPress – wie ein Großteil des Webs. Funktioniert hat es, aber je mehr ich mit modernen Frontend-Technologien gearbeitet habe, desto mehr hat mich gestört, wie träge sich WordPress-Seiten oft anfühlen und wie eingeschränkt man bei Animationen und Interaktionen ist, sobald man über Standard-Page-Builder hinausgeht. Vor Kurzem habe ich deshalb den Schritt gewagt und meine Seite komplett neu aufgebaut: mit Next.js, React, TypeScript, Tailwind CSS und motion.dev für die Animationen, als Backend kommt Payload zum Einsatz.
Der Auslöser war vor allem die Geschwindigkeit – und die Möglichkeit, flüssige, präzise kontrollierte Animationen umzusetzen, die mit einem klassischen WordPress-Theme kaum sauber machbar gewesen wären. Dazu kam ein zweiter, sehr pragmatischer Grund: Mittlerweile verlangt fast jedes brauchbare WordPress-Plugin ein Abo-Modell, bevor es seine volle Funktionalität freischaltet. Was einzeln nach wenigen Euro im Monat aussieht, summiert sich über mehrere Plugins hinweg schnell zu einer laufenden Kostenstruktur – und das für eine Website, die eigentlich einmal gebaut und dann in Ruhe genutzt werden sollte. In diesem Artikel teile ich, warum sich dieser Umstieg für mich gelohnt hat, wo Next.js WordPress klar überlegen ist – aber auch, wo WordPress nach wie vor die einfachere und pragmatischere Wahl bleibt.
Die Argumente für Next.js
Geschwindigkeit, die man spürt
Next.js rendert Seiten serverseitig oder sogar komplett statisch vor, lädt nur die JavaScript-Bündel, die eine Seite tatsächlich braucht, und optimiert Bilder automatisch. Das Ergebnis: spürbar kürzere Ladezeiten und bessere Core Web Vitals als bei einer typischen WordPress-Installation mit PHP-Rendering, Datenbankabfragen bei jedem Aufruf und oft aufgeblähten Themes.
Flüssige, präzise Animationen
Mit motion.dev (vormals Framer Motion) lassen sich Animationen bauen, die exakt auf Scroll-Position, State-Änderungen oder Interaktionen reagieren – performant, weil sie direkt in React eingebettet sind und nicht über schwergewichtige jQuery-Plugins oder Page-Builder-Add-ons laufen. Genau das war für mich der ausschlaggebende Punkt: Ich wollte eine Seite, die sich lebendig anfühlt, ohne dabei langsam zu werden.
TypeScript sorgt für Stabilität
TypeScript bringt Typsicherheit in den gesamten Entwicklungsprozess. Fehler, die in einem lose typisierten PHP/JavaScript-Setup erst zur Laufzeit auffallen würden, zeigt TypeScript schon während der Entwicklung. Für mich bedeutet das weniger böse Überraschungen nach einem Deployment.
Volle Design-Freiheit mit Tailwind
Tailwind CSS erlaubt es, jedes Detail des Designs direkt im Markup zu steuern, ohne gegen die Vorgaben eines Themes anzukämpfen. Man ist nicht auf das beschränkt, was ein WordPress-Theme oder ein Page-Builder hergibt, sondern baut jede Komponente exakt so, wie man sie haben möchte.
Headless-Architektur mit Payload
Payload als Headless CMS trennt Content-Verwaltung und Frontend sauber voneinander. Ich kann Inhalte in einem entwicklerfreundlichen, TypeScript-nativen Backend pflegen, während das Frontend völlig unabhängig davon gestaltet werden kann. Das gibt mir die Freiheit, das Frontend jederzeit weiterzuentwickeln, ohne an ein starres CMS-Templating-System gebunden zu sein.
Sicherheit durch reduzierte Angriffsfläche
WordPress-Seiten sind wegen ihrer Verbreitung ein beliebtes Angriffsziel, und ein Großteil der Sicherheitsprobleme entsteht durch veraltete Plugins oder Themes. Bei einem schlanken Next.js-Setup mit wenigen, bewusst gewählten Abhängigkeiten ist die Angriffsfläche von Haus aus kleiner – es gibt schlicht weniger Komponenten, die ständig gepatcht werden müssen.
Keine wiederkehrenden Plugin-Abos
Ein Punkt, der in der Diskussion oft untergeht: Viele WordPress-Plugins funktionieren heute nach dem Freemium-Prinzip – die Grundversion ist kostenlos, aber sobald man Funktionen braucht, die über das Nötigste hinausgehen, landet man in einem monatlichen oder jährlichen Abo. Bei einer typischen Website mit SEO-, Formular-, Caching- und Sicherheits-Plugin kommen so schnell mehrere laufende Kostenpunkte zusammen. Bei einem selbst entwickelten Next.js-Setup zahlt man einmalig für die Entwicklung der benötigten Funktionalität – danach gehört der Code einem selbst, ohne dass man Gefahr läuft, dass ein Plugin-Anbieter irgendwann Preise erhöht oder Funktionen hinter eine neue Bezahlschranke verschiebt.
Modernes Hosting und Deployment
Next.js-Projekte lassen sich unkompliziert auf Plattformen wie Vercel deployen, inklusive automatischem Preview-Deployment für jeden Branch, globaler CDN-Auslieferung und serverlosen Funktionen. Das fühlt sich für mich als Entwickler deutlich zeitgemäßer an als klassisches Shared-Hosting mit FTP-Uploads.
Die möglichen Nachteile
Auch hier gilt: Next.js ist nicht automatisch die bessere Wahl für jedes Projekt. Im Vergleich zu WordPress gibt es einige klare Nachteile.
Deutlich höhere Entwicklungskomplexität
Eine Next.js-Seite baut man nicht mit ein paar Klicks zusammen. Es braucht Programmierkenntnisse in React und TypeScript – für jemanden ohne Entwicklungshintergrund ist der Aufstieg ungleich steiler als bei WordPress, wo man mit einem Theme und einem Page-Builder in kurzer Zeit startklar ist.
Content-Pflege ist weniger niedrigschwellig
Auch wenn Payload eine gut nutzbare Admin-Oberfläche bietet, fehlt das riesige Ökosystem an intuitiven WordPress-Page-Buildern (Elementor, Divi & Co.), mit denen auch technisch weniger versierte Redakteur:innen komplexe Layouts selbst zusammenklicken können. Bei Next.js braucht jede strukturelle Änderung am Layout in der Regel Entwicklungsarbeit.
Höhere Kosten für einfache Projekte
Für eine einfache Firmenwebsite oder einen Blog ohne besondere Anforderungen an Performance oder Interaktivität ist der Aufwand einer individuellen Next.js-Entwicklung oft nicht zu rechtfertigen. WordPress liefert hier in Stunden statt Wochen ein brauchbares Ergebnis.
Kleineres Plugin-Ökosystem
Für nahezu jede Funktion – Formulare, SEO-Optimierung, E-Commerce, Mitgliederbereiche – gibt es in WordPress ein fertiges Plugin. Im Next.js-/Payload-Umfeld muss man solche Funktionen häufiger selbst bauen oder über Drittanbieter-Services integrieren, was zusätzliche Entwicklungszeit bedeutet.
Fazit
Für mich persönlich hat sich die Migration von peterwindholz.at auf Next.js, React, TypeScript, Tailwind und motion.dev mit Payload als Backend klar gelohnt: Die Seite ist spürbar schneller, die Animationen sind genau so flüssig, wie ich sie mir vorgestellt habe, und ich habe als Entwickler die volle Kontrolle über jedes Detail.
Das bedeutet aber nicht, dass ich WordPress pauschal für schlechter halte. Für Kund:innen, die eine einfache, redaktionell pflegbare Website ohne aufwändige Individualisierung brauchen und die selbst Inhalte pflegen wollen, ist WordPress nach wie vor eine sehr pragmatische und kosteneffiziente Lösung. Next.js spielt seine Stärken dort aus, wo Performance, individuelles Design, Animationen und technische Kontrolle im Vordergrund stehen – und ein Entwicklungsteam ohnehin laufend involviert ist.
Am Ende ist es, wie so oft, eine Frage der Anforderungen: Wer Geschwindigkeit, Design-Freiheit und moderne Technologie priorisiert und bereit ist, dafür etwas mehr Entwicklungsaufwand zu investieren, ist mit Next.js bestens beraten. Wer eine schnell einsatzbereite, selbst verwaltbare Website ohne großen technischen Aufwand sucht, bleibt mit WordPress gut bedient.
