Custom Code vs. Baukasten: Was wirklich hinter einer schnellen, sicheren Website steckt
Wer eine Website erstellen lässt, entscheidet früh über eine technische Grundfrage, die später kaum noch günstig zu korrigieren ist: Baukasten oder WordPress mit einem Dutzend Plugins auf der einen Seite, schlanker Custom Code auf der anderen. Diese Entscheidung wirkt sich direkt auf drei Dinge aus, die für jedes Unternehmen zählen: wie schnell die Website lädt, wie angreifbar sie ist, und wie viel Pflege sie über Jahre verursacht. Wer die Website-Ladezeit optimieren will oder sich über Website-Sicherheit für KMU informiert, landet fast immer bei derselben Wurzel: der technischen Basis, auf der die Seite steht.
Im ersten Teil dieser Serie ging es um den groben Ablauf von der Idee zum Go-Live, im zweiten Teil um die gestalterischen Grenzen von Baukästen. Dieser Artikel geht einen Schritt technischer und zeigt, was unter der Haube passiert, wenn WordPress plus 20 Plugins gegen schlanken Custom Code mit einem Framework wie Next.js antritt.
Zwei Wege zur Website
Der eine Weg: ein Content-Management-System wie WordPress, ein Theme, ein Page-Builder-Plugin, dazu SEO-Plugin, Formular-Plugin, Cache-Plugin, Cookie-Consent-Plugin, Sicherheits-Plugin, ein Plugin für die Bildoptimierung, eines für den Shop, eines für Backups. Jedes einzelne davon löst ein konkretes Problem. In Summe entsteht aber ein System, das aus Dutzenden Fremdcode-Bausteinen besteht, die alle miteinander und mit dem Kern kompatibel bleiben müssen.
Der andere Weg: Custom Code, häufig auf Basis eines Frameworks wie Next.js. Hier wird nur der Code ausgeliefert, der für die jeweilige Seite tatsächlich gebraucht wird, ohne Administrationsoberfläche im Frontend, ohne Dutzende Fremdabhängigkeiten, die im Hintergrund mitlaufen.
Website-Ladezeit optimieren: Was Core Web Vitals mit der technischen Basis zu tun haben
Was LCP, INP und CLS konkret messen
Core Web Vitals ist eine Reihe von Metriken, die die reale Nutzererfahrung bei Ladeleistung, Interaktivität und visueller Stabilität einer Seite messen. Largest Contentful Paint (LCP) misst die Ladeleistung: Für eine gute Nutzererfahrung sollte LCP innerhalb der ersten 2,5 Sekunden nach Beginn des Seitenladens eintreten. Interaction to Next Paint (INP) misst die Reaktionsfähigkeit: Für eine gute Nutzererfahrung sollte INP unter 200 Millisekunden liegen. Cumulative Layout Shift (CLS) misst die visuelle Stabilität: Für eine gute Nutzererfahrung sollte der CLS-Wert unter 0,1 liegen. Diese drei Werte sind kein akademisches Detail, sondern Teil des Page-Experience-Signals, das Google seit 2021 in die Bewertung von Suchergebnissen einbezieht.
Besonders die Umstellung auf INP hat die Messlatte höher gelegt: Google führte Core Web Vitals 2020 ein und machte sie 2021 als Teil des Page-Experience-Signal-Updates zu einem Rankingfaktor. Im März 2024 kam die bislang wichtigste Änderung: First Input Delay (FID) wurde offiziell durch Interaction to Next Paint (INP) ersetzt, eine Metrik, die deutlich anspruchsvoller ist, weil sie die Interaktivität über den gesamten Seitenbesuch misst und nicht nur bei der ersten Nutzerinteraktion. Eine Seite kann also beim ersten Klick völlig flüssig wirken und trotzdem schlecht abschneiden, wenn ein späterer Klick, etwa auf einen Filter oder ein Formularfeld, hängt.
Wie ernst das Problem in der Praxis ist, zeigt eine aktuelle Auswertung: 72 % der mobilen Seiten, die 2025 getestet wurden, verfehlten den INP-Schwellenwert, laut Chrome-User-Experience-Daten. Der wirtschaftliche Hebel dahinter ist ebenfalls belegt: Eine Studie von SEOClarity fand heraus, dass eine Verbesserung des LCP um 0,8 Sekunden zu einer Steigerung der Konversionsrate um 8,35 % führen kann. Wie hoch die Kosten einer langsamen Seite konkret ausfallen können, hat der Artikel zu Ladezeit und Kundenverlust bereits vorgerechnet; der Grundlagenartikel zu Pagespeed und Core Web Vitals erklärt die Messwerte im Detail.
Warum jedes Plugin die Ladezeit belastet
Der technische Grund, warum Plugin-Stacks tendenziell langsamer sind, liegt selten an einem einzelnen schlechten Plugin, sondern an der Summe. Jedes Plugin bringt eigenes CSS, eigenes JavaScript und häufig eigene Datenbankabfragen mit. Ein einfacher Aufruf einer WordPress-Seite erzeugt standardmäßig rund 59 SQL-Abfragen; dieser Performanceverlust wird häufig nur durch einen zusätzlichen Caching-Layer wie Varnish abgemildert. Kommen 15 bis 20 aktive Plugins dazu, potenziert sich das: Jedes lädt eigene Skripte, oft unkoordiniert mit den anderen.
Das Ergebnis lässt sich in konkreten Zahlen fassen: Ohne aufwändige Optimierung sind bei WordPress Ladezeiten von 3 bis 6 Sekunden keine Seltenheit. Genau das trifft auf den INP- und LCP-Schwellenwert, an dem Google die "gute" Nutzererfahrung festmacht.
Was Custom Code mit Next.js technisch anders macht
Bei einem schlanken Custom-Code-Setup verschiebt sich die Logik. Die Ladezeit ist extrem schnell durch Pre-Rendering und automatische Bildoptimierung, es gibt keine direkte Datenbank-Verbindung im Frontend, wodurch die Angriffsfläche minimal bleibt, und die Wartung ist stabil, weil keine Plugins von Drittanbietern das System durcheinanderbringen können. Next.js rendert Seiten wahlweise vorab statisch, serverseitig oder nur teilweise dynamisch je nachdem, was der jeweilige Inhalt braucht.
Konkret bedeutet das: Bilder werden automatisch in moderne Formate wie WebP oder AVIF konvertiert und in der passenden Größe ausgeliefert, Schriftarten werden so geladen, dass kein Text-Flackern entsteht, und JavaScript wird intelligent nachgeladen, ohne den Haupt-Thread zu blockieren. Ein wesentlicher Baustein moderner Next.js-Architektur sind zudem Server Components: Sie laufen auf dem Server und schicken weniger JavaScript an den Browser, die Seiten laden schneller, das Bundle bleibt schlank, und Client Components werden nur dort eingesetzt, wo tatsächlich Interaktivität gebraucht wird. Das Ergebnis sind kleinere Bundles, schnellere initiale Ladezeiten und ein direkter Datenzugriff ohne zusätzliche API-Umwege.
Website-Sicherheit für KMU: Warum die Angriffsfläche mit jedem Plugin wächst
Die Zahlen hinter WordPress-Sicherheitslücken
Sicherheit ist der Bereich, in dem sich der Unterschied zwischen Plugin-Stack und Custom Code am deutlichsten zeigt. Nicht, weil WordPress selbst unsicher wäre, sondern weil die Angriffsfläche mit jeder Erweiterung wächst. WordPress betreibt 41,5 % aller Websites weltweit und 59,2 % aller Seiten mit bekanntem CMS , mehr als alle anderen Systeme zusammen. Diese Dominanz macht WordPress automatisch zum lohnendsten Ziel: Was gegen WordPress funktioniert, funktioniert potenziell gegen Millionen Seiten.
Die aktuellen Zahlen zu Schwachstellen bestätigen das Muster: 91 % der 2025 gemeldeten Schwachstellen lagen in Plugins, 9 % in Themes und nur eine Handvoll im WordPress-Core, alle niedrig priorisiert. Im WordPress-Ökosystem wurden 2025 11.334 neue Schwachstellen entdeckt. Ein Anstieg von 42 % gegenüber 2024. Besonders heikel: 46 % der 2025er Lücken hatten zum Zeitpunkt der Veröffentlichung keinen Patch, und die Zahl der High-Severity-Lücken stieg um 113 %. Die mediane Zeit bis zur Massen-Ausnutzung stark angegriffener Lücken lag 2025 bei nur 5 Stunden.
Was das in der Praxis bedeutet, zeigt eine weitere Auswertung: Rund 91 % der WordPress-Sicherheitslücken stecken in Plugins, etwa 13.000 Seiten werden täglich gehackt, und die häufigste Ursache ist schlicht veraltete Software. Das Risiko ist also weniger eine Frage von ausgefeilten Angriffen als von schlichter Wahrscheinlichkeit: Je mehr Plugins aktiv sind, desto höher die statistische Chance, dass zu jedem Zeitpunkt mindestens eine ausnutzbare Lücke offen ist.
Warum Custom Code strukturell weniger angreifbar ist
Bei Custom Code entfällt die gesamte Angriffsfläche, die aus Drittanbieter-Plugins entsteht, schlicht durch die Architektur. Ein wesentlicher Sicherheitsvorteil von Next.js gegenüber WordPress liegt in der reduzierten Abhängigkeit von Plugins: Durch den Verzicht auf zahlreiche Plugins minimiert Next.js potenzielle Sicherheitslücken und erleichtert die Wartung des Systems. Es gibt kein öffentlich erreichbares Admin-Backend nach dem Muster von /wp-login.php, keine Datenbank, die direkt vom Frontend aus erreichbar ist, und keine 20 unabhängig gepflegten Fremdcode-Pakete, deren Sicherheitslage man einzeln überwachen müsste. Das heißt nicht, dass Custom-Code-Websites von Natur aus unhackbar sind – Abhängigkeiten, Server-Konfiguration und Zugangsdaten bleiben relevant. Aber die Zahl der Einfallstore, die überwacht werden müssen, ist um eine Größenordnung kleiner.
Wartungsaufwand: Was nach dem Launch an Arbeit übrig bleibt
Der laufende Aufwand unterscheidet sich zwischen beiden Wegen strukturell. Bei einem Plugin-Stack müssen Core, Theme und jedes einzelne Plugin regelmäßig aktualisiert werden und jedes Update kann mit einem anderen Plugin kollidieren. Genau deshalb reagieren viele Betreiber zurückhaltend auf Updates: WordPress-Updates machen häufig etwas kaputt. Das Ergebnis ist ein Dilemma: Wer nicht aktualisiert, bleibt verwundbar; wer aktualisiert, riskiert, dass die Seite an anderer Stelle bricht.
Bei Custom Code verschiebt sich der Wartungsaufwand von "20 unabhängige Systeme im Blick behalten" zu "ein überschaubares, versioniertes Repository pflegen". Abhängigkeiten sind über ein Lockfile fixiert, Deployments sind reproduzierbar, und ein Update betrifft ein einziges, unter Kontrolle des Entwicklungsteams stehendes Projekt statt eines losen Verbunds aus Drittanbieter-Code. Was nach dem Launch an Hosting, Backups und Update-Routine grundsätzlich zählt, unabhängig vom gewählten System, beschreibt der fünfte Teil dieser Serie.
WordPress vs. Next.js: Wann sich welcher Weg wirklich lohnt
Die ehrliche Antwort ist nicht "Custom Code immer, WordPress nie". Wenn ein begrenztes Budget und wenig technische Anforderungen vorliegen, oder wenn ein Team das WordPress-Backend bereits kennt und nutzt, bleibt WordPress eine sinnvolle Wahl, etwa für einen redaktionslastigen Blog mit täglichen Veröffentlichungen oder einen WooCommerce-Shop mit vielen tausend Produkten. Für ein Unternehmen, das primär eine Präsenz mit wenigen, aber gut gepflegten Seiten betreibt und bei dem Ladezeit, Sicherheit und niedrige Betriebskosten im Vordergrund stehen, kippt die Rechnung dagegen zugunsten von Custom Code.
Diesen Zielkonflikt zwischen Aufwand und Ergebnis hat auch der zweite Teil dieser Serie für die Design-Seite beschrieben: Baukästen sind schnell aufgesetzt, stoßen aber bei individuellen Anforderungen an Grenzen. Auf der technischen Seite gilt dasselbe Prinzip, nur dass die Grenze hier nicht bei der Optik, sondern bei Ladezeit, Angriffsfläche und Wartungsaufwand verläuft. Eine detaillierte Gegenüberstellung beider Wege findest du im Vergleich Custom Code vs. WordPress.
Custom-Code-Website-Vorteile in der Praxis
Wie sich das in einem realen Projekt niederschlägt, zeigt ein Case von uns. Der Elektrofachbetrieb ist beim Website-Relaunch auf einen kompletten Custom-Code-Stack umgestiegen: Next.js als Frontend-Basis, eine eigene PostgreSQL-Datenbank, ein eigener Mailserver, eine Whitelabel-Nextcloud-Integration sowie eine OCR-gestützte Belegerfassung. Für die Besucheranalyse kommt Matomo ohne Cookies zum Einsatz, gehostet in Deutschland. Der Effekt dieser Kombination: keine Drittanbieter-Plugins, die Angriffsfläche bieten, keine externen Tracking-Dienste, die zusätzliche Consent-Pflichten auslösen, und eine Architektur, die von Anfang an auf die tatsächlichen Anforderungen des Betriebs zugeschnitten ist statt auf einen generischen Plugin-Baukasten.
Wie schnell ist eure aktuelle Seite wirklich?
Bevor du dich zwischen Baukasten, WordPress und Custom Code entscheidest, lohnt sich ein nüchterner Blick auf den Ausgangspunkt: Wie schnell lädt die aktuelle Seite tatsächlich, und wie viele Fremdanbieter-Bausteine laufen im Hintergrund mit? Mit dem Website-Check-Tool von zyntix bekommst du in wenigen Sekunden eine ehrliche Einschätzung zu Ladezeit, Core Web Vitals und offenkundigen Schwachstellen deiner aktuellen Website. Darauf aufbauend zeigt der Konfigurator, welcher technische Weg, Baukasten, WordPress oder Custom Code, für dein konkretes Projekt tatsächlich sinnvoll ist, statt eine Standardlösung über jedes Vorhaben zu legen.
Fazit
Ladezeit und Sicherheit sind keine Nebenschauplätze eines Website-Projekts, sondern direkte Folgen der technischen Basis, für die sich ein Unternehmen zu Beginn entscheidet. Ein Plugin-Stack löst kurzfristig viele Einzelprobleme, erzeugt aber langfristig eine wachsende Angriffsfläche und eine Ladezeit, die mit jeder zusätzlichen Erweiterung leidet. Schlanker Custom Code verlangt mehr Planung am Anfang, liefert dafür aber eine Website, die schneller lädt, weniger Angriffsflächen bietet und über Jahre mit deutlich geringerem Wartungsaufwand läuft. Welcher Weg zu einem konkreten Projekt passt, hängt von Umfang, Team und Budget ab. Die Entscheidung sollte aber bewusst und mit den tatsächlichen Zahlen im Blick getroffen werden, nicht aus Gewohnheit.
Quellen:
Google Search Central – Understanding Core Web Vitals and Google search results, https://developers.google.com/search/docs/appearance/core-web-vitals
Ruskin Consulting – Why Core Web Vitals Matter for SEO in 2026, https://ruskinconsulting.com/why-core-web-vitals-matter-for-seo-in-2026/
MorningRank – Mastering Core Web Vitals in 2026: An In-Depth Technical SEO Guide, https://morningrank.com/blog/mastering-core-web-vitals-in-2026-an-in-depth-technical-seo-guide
Forge12 – WordPress-Sicherheit in Zahlen 2026, https://www.forge12.com/de/blog/wordpress-sicherheit-in-zahlen-2026
ShiftPress – WordPress-Sicherheitslücken 2026: Warum veraltete Seiten gehackt werden, https://shiftpress.ai/de/blog/wordpress-sicherheitsluecken
webvise – Veraltetes WordPress: Die Sicherheitsrisiken, die Sie wirklich eingehen, https://www.webvise.io/de/blog/wordpress-security-risks
webse.at – Next.js vs. WordPress: Warum Technik über Speed entscheidet, https://www.webse.at/de/blog/next-vs-wordpress-technologie-speed
Webwerk IT – Next.js oder WordPress: Was ist besser?, https://www.webwerk.app/magazin/nextjs-vs-wordpress
Naturaily – The Next.js Framework: Features, Benefits, and Case Studies, https://naturaily.com/blog/nextjs-features-benefits-case-studies
synaigy – NextJS: der Gamechanger für deine Web Performance, https://www.synaigy.com/blog/nextjs-gamechanger-web-performance
webAION – Die beste Website-Technologie 2027: Astro vs. Next.js vs. WordPress, https://webaion.de/ratgeber/astro-vs-nextjs-vs-wordpress
