WordPress lohnt sich nicht. Liefere lieber Next.js.
- Next.js
- WordPress
- Performance
- Web Dev
Jedes WordPress-Projekt, das ich angefasst habe, endet in einem Plugin-Treadmill und einem Lighthouse-Desaster. Nach der Migration zweier Kundenseiten auf Next.js kehre ich nicht zurück.
WordPress betreibt 43 Prozent des Webs und verursacht einen unverhältnismäßig großen Anteil an Kundensupport-Anfragen. Ich weiß das, weil ich zwei Jahre lang WordPress-Seiten gebaut und gewartet habe, bevor ich jedes neue Projekt auf Next.js umgestellt habe. Der Wechsel ist keine Frage der Ideologie. Es geht um Zeit, Sicherheit und die tatsächlichen Core Web Vitals-Werte einer Seite.
Der Plugin- und Sicherheits-Patch-Treadmill
Ein typisches WordPress-Projekt endet mit 15 bis 25 Plugins. Jedes Plugin ist eine separate Abhängigkeit mit eigenem Release-Zyklus, eigenem Autor und eigener CVE-Geschichte. WordPress Core selbst liefert Sicherheits-Patches kurzfristig. Wenn eine kritische Schwachstelle bekannt wird, ist das Zeitfenster eng: schnell patchen oder kompromittiert werden.
Die Wegweiser Leben-Website war mein erstes ernsthaftes Migrationsziel. Sie hatte einen Page-Builder, drei SEO-Plugins mit teilweiser Überschneidung, ein Caching-Plugin, das mit dem CDN des Hosters in Konflikt stand, und ein Formular-Plugin, das zweimal wegen XSS gemeldet worden war. Jeder Monat fühlte sich an wie ein Spiel nach dem Motto: "Welches Update bricht heute das Layout?" Der Kunde zahlte für Wartung, nicht für eine zuverlässige Seite.
- Plugin A aktualisiert sich und bricht die CSS-Injektion von Plugin B.
- Der Hoster hebt die PHP-Version an, zwei Plugins werfen fatale Fehler.
- WordPress-Core-Sicherheitspatch, Page-Builder noch nicht kompatibel.
- Malware-Scanner meldet ein Plugin, das seit 18 Monaten nicht aktualisiert wurde.
- Wiederholt sich endlos.
Mit einem Next.js-Projekt schrumpft die Angriffsfläche. Keine PHP-Laufzeitumgebung, die dem Internet ausgesetzt ist. Kein Admin-Panel unter /wp-admin. Keine Datenbankzugangsdaten in einer flachen Konfigurationsdatei, die ein falsch konfigurierter Server ausliefern könnte. Die Anwendung ist statisches HTML, CSS und JavaScript, das auf einem Edge-CDN bereitgestellt wird. An einem Sonntagsnachmittag gibt es nichts zu patchen, weil ein Plugin-Autor ein fehlerhaftes Update geliefert hat.
Page-Builder-Markup und Core Web Vitals
Öffne den Quellcode einer beliebigen Elementor- oder Divi-Seite. Du findest tief verschachtelte div-Suppen, Inline-Stile auf jedem Element, render-blockierende Skripte und Font-Dateien, die von drei verschiedenen Ursprüngen geladen werden. Dieses Markup ist die Ausgabe eines Drag-and-Drop-Tools, das für visuelle Bearbeitung optimiert ist, nicht für die Layout-Engine des Browsers oder den Crawler.
Der Largest Contentful Paint leidet, weil das Hero-Image über einen JavaScript-injizierten Container geladen wird, der beim initialen Rendering nicht sichtbar ist. Der Cumulative Layout Shift steigt, weil der Page-Builder den Platz dynamisch nach dem Font-Laden reserviert. Die Total Blocking Time steigt, weil jedes Widget sein eigenes Skript-Bundle liefert, unabhängig davon, ob das Widget auf dieser Seite sichtbar ist.
Die Jumpino View-Website erzielte auf WordPress einen Performance-Score von 41 auf Mobilgeräten. Nach der Migration auf Next.js erreicht sie 96. Der Inhalt ist identisch. Der Unterschied liegt vollständig darin, was das Framework generiert und wie es Assets lädt.
Du besitzt die Ausgabe, also gehört dir die Geschwindigkeit
Mit Next.js schreibst du die Komponente, entscheidest das Markup, kontrollierst den <head>. Die next/image-Komponente verwaltet responsive srcset, Lazy Loading und moderne Formatkonvertierung automatisch. Dafür brauchst du kein Plugin. Du bezahlst keinen Plugin-Autor dafür, wachzubleiben.
import Image from 'next/image';
import type {FC} from 'react';
type HeroProps = {
src: string;
alt: string;
headline: string;
};
// Replaces a WordPress "Hero Section" plugin block.
// next/image handles srcset, WebP conversion, and LCP prioritization.
const HeroSection: FC<HeroProps> = ({src, alt, headline}) => {
return (
<section className="relative isolate overflow-hidden">
<Image
src={src}
alt={alt}
fill
priority // marks this as LCP candidate
sizes="100vw"
className="object-cover -z-10"
/>
<div className="mx-auto max-w-3xl px-6 py-24">
<h1 className="text-4xl font-bold tracking-tight text-white sm:text-6xl">
{headline}
</h1>
</div>
</section>
);
};
export default HeroSection;Diese Komponente ist der vollständige Ersatz für ein Plugin, das 40 kB JavaScript, einen PHP-Backend-Endpunkt und drei Datenbankabfragen pro Seitenaufruf hinzufügte. Die priority-Prop weist Next.js an, das Bild vorzuladen und es als LCP-Element zu markieren. Der Browser erhält einen Hinweis, bevor er überhaupt den Body geparst hat. Kein Konfigurationspanel, kein Lizenzschlüssel, keine Verlängerungs-E-Mail.
Formulare, Kontakt und die letzten Plugin-Ausreißer
Die zwei Plugins, die Kunden am längsten auf WordPress halten, sind das Kontaktformular und die Newsletter-Anmeldung. Beide haben saubere Lösungen in Next.js. Eine React Hook Form-Komponente kombiniert mit einem Route Handler macht alles, was Contact Form 7 macht, mit null PHP, null Datenbankschreibvorgängen auf dem Frontend-Server und vollständigen TypeScript-Typen auf dem Submission-Payload.
// app/api/contact/route.ts
// Replaces Contact Form 7 + a mail plugin entirely.
import {NextRequest, NextResponse} from 'next/server';
import {Resend} from 'resend';
const resend = new Resend(process.env.RESEND_API_KEY);
export async function POST(req: NextRequest) {
const body = await req.json();
const {name, email, message} = body as {
name: string;
email: string;
message: string;
};
if (!name || !email || !message) {
return NextResponse.json({error: 'Missing fields'}, {status: 400});
}
const {error} = await resend.emails.send({
from: 'contact@jumpinotech.com',
to: 'gabriel@jumpinotech.com',
subject: `Contact from ${name}`,
text: `${message}\n\nReply to: ${email}`,
});
if (error) {
return NextResponse.json({error: 'Send failed'}, {status: 500});
}
return NextResponse.json({ok: true});
}Das ist das gesamte Backend. Resend übernimmt die Zustellung. Die Frontend-Komponente ruft fetch("/api/contact", ...) auf. Kein Plugin, keine SMTP-Konfigurationsoberfläche, kein Honeypot-Feld, das du daran denken musst hinzuzufügen, kein WP-Cron-Job, der die Warteschlange verwaltet.
Wie ein KI-Coding-Agent das Langzeitgedächtnis eines Next.js-Projekts pflegt
Sobald die WordPress-Codebasis verschwunden ist, ist das Projekt sauber genug, dass ein KI-Coding-Agent es sitzungsübergreifend zuverlässig betreiben kann. Der Schlüssel ist persistenter Markdown-Kontext. Ein Agent, der ein gut gepflegtes AGENTS.md im Projektstamm liest, kennt die Konventionen, die Befehle, die Umgebungsvariablen und die Fallstricke, ohne jedes Mal erneut informiert zu werden.
Für die Wegweiser Leben-Migration pflege ich eine AGENTS.md, die der Agent zu Beginn jeder Sitzung liest. Sie deckt die Ordnerstruktur, das Content-Authoring-Format (TypeScript-Module für Posts, genau wie ich es hier verwende), das Deployment-Ziel und die Dinge ab, die mich während der Migration überrascht haben. Der Agent rät nicht. Er liest die Datei und handelt danach.
Markdown-Gedächtnis ist kein Workaround. Es ist die richtige Architektur, um einen Agenten auf einem Projekt zuverlässig zu halten, das er nicht kontinuierlich besucht.
Hier ist ein repräsentativer Auszug aus der Agenten-Kontextdatei des Projekts:
# AGENTS.md — Wegweiser Leben Next.js Project
## Stack
- Next.js 15 (App Router), TypeScript strict, Tailwind CSS v4
- Content: TypeScript modules in src/content/posts/ typed against Post in src/content/types.ts
- Images: next/image only, no raw <img>; WebP assets in public/blog/[slug]/
- Deployment: Vercel, auto-deploy on push to main
## Commands
- dev: npm run dev (localhost:3000)
- build: npm run build — must pass before any PR
- lint: npm run lint — ESLint + Prettier, no warnings allowed
## Content authoring
- Each post is a .ts file exported as default Post
- body array uses Block types (p, h2, h3, ul, ol, quote, code, callout, image)
- readingMinutes must match actual word count (approx 200 wpm)
- date field is ISO string, do not change after publish
## Gotchas
- Tailwind v4 uses @import "tailwindcss" not @tailwind directives
- next/font must be imported in layout.tsx only, not in individual components
- Route Handlers in app/api/ use NextRequest/NextResponse from 'next/server'
- RESEND_API_KEY must be set in Vercel env vars and in .env.local for local dev
- Do not add wordpress, elementor, or divi class names anywhere
## Known issues
- Large hero images above 1 MB will fail Vercel's 4.5 MB limit; compress first
Wenn ich eine neue Sitzung öffne und den Agenten bitte, ein Kontaktformular hinzuzufügen oder einen Build-Fehler zu beheben, liest er zuerst diese Datei. Er weiß, dass er keine rohen <img>-Tags verwenden darf. Er kennt das Inhaltsformat. Er weiß, wo Umgebungsvariablen gespeichert sind. Das ist operative Kontinuität ohne ein Übergabedokument oder ein langes verbales Briefing.
Die Migrations-Checkliste
Sowohl Wegweiser Leben als auch Jumpino View folgten der gleichen Abfolge. Für eine Seite mit weniger als 20 Seiten dauert es ein konzentriertes Wochenende.
- 01Alle Inhalte aus WordPress exportieren (XML-Export oder direkte DB-Abfrage).
- 02Posts und Seiten in TypeScript-Inhaltsmodule konvertieren.
- 03Navigation und Layout als React-Komponenten neu aufbauen.
- 04Kontaktformular-Plugin durch einen Route Handler und Resend ersetzen.
- 05SEO-Plugin durch die Next.js Metadata API und
next-sitemapersetzen. - 06Jedes Bild prüfen: komprimieren, in WebP konvertieren, nach
public/verschieben. - 07Lighthouse auf jeder Seite ausführen und LCP- oder CLS-Regressionen beheben.
- 08AGENTS.md mit dem vollständigen Projektkontext schreiben.
- 09Auf Vercel deployen, DNS umleiten, alten Hoster kündigen.
Das war es. Keine laufenden Plugin-Abonnements. Keine monatlichen Sicherheits-Scans. Keine Page-Builder-Lizenz. Der Kunde zahlt für Vercels Hobby-Plan oder gar nichts bei einem statischen Export. Die Seite ist schneller, sicherer und günstiger im Betrieb. Das Einzige, was verloren geht, ist der Drag-and-Drop-Editor, der die Hälfte der Probleme verursacht hat.
WordPress ergab Sinn, als die Alternative darin bestand, PHP von Hand zu schreiben. Die Alternative heute ist ein typisiertes, komponentenbasiertes Framework mit einem globalen CDN, automatischer Bildoptimierung und einer Deployment-Pipeline, die 90 Sekunden dauert. Die Kalkulation hat sich verändert. Hör auf, das zu warten, was du einfach ersetzen kannst.