Schnelle Website mit KI bauen (und was Websites wirklich bremst)

„Welches ist das schnellste CMS?“ ist meistens die erste Frage. Es ist die falsche erste Frage. Ein Content-Management-System bestimmt, wie Seiten gespeichert und ausgeliefert werden. Aber das, was die Websites in unseren Daten langsam gemacht hat, lässt sich in jedes CMS einbauen, und genauso leicht von einer KI, der niemand gesagt hat, dass sie es weglassen soll.

Das wird jeden Monat wichtiger, weil immer mehr Websites von KI-Werkzeugen geschrieben werden. Bei neu gegründeten Firmen in Deutschland trugen 2026 2,5 % der Websites einen klaren Fingerabdruck eines KI-Baukastens, und bis zu 15 % waren moderner Code in dem Stil, den KI-Werkzeuge schreiben (unsere Studie zu 1.536 Neugründungen, mehr dazu in wie viele Firmen-Websites schon mit KI gebaut sind). Bei etablierten Betrieben ist es noch seltener: Von 2.538 Websites in 16 Städten in Deutschland, Österreich und der Schweiz waren 0,4 % mit einem KI-Baukasten gebaut und höchstens 3,1 % sehen nach KI-Code aus. Eine KI baut genau so schnell, wie das Briefing es verlangt.

Das Wichtigste in Kürze

• Die Messlatte: Largest Contentful Paint (LCP) von höchstens 2,5 Sekunden bei mindestens 75 % der Besuche. Über 4 Sekunden gilt als schlecht.
• Die typische Firmen-Website reißt sie: LCP im Median 7,1 Sekunden und ein mobiler PageSpeed-Wert von 64 in unserer Stichprobe aus 2026.
• Es liegt nicht am JavaScript: Die Total Blocking Time lag im Median bei nur 17 Millisekunden. Die Verzögerung steckt im ersten großen Element und in dem, was davor lädt.
• Die üblichen Verdächtigen waren langsamer: Seiten mit Tag Manager oder Tracking-Pixel hatten einen LCP von 11,0 Sekunden im Median, ohne waren es 6,4 Sekunden.
• Mit KI ist Ladezeit eine Frage des Briefings: Schreib ein Budget und ein paar Regeln in den Prompt oder in die CLAUDE.md und prüf das Ergebnis mit PageSpeed Insights.

Was „schnell“ heißt: die Werte, die Google verwendet

Google misst Ladezeit mit drei Core Web Vitals. Die Zielwerte unten stammen von web.dev, Googles eigener Dokumentation, und gelten für das 75. Perzentil der Seitenaufrufe, getrennt nach Handy und Desktop.

Der PageSpeed-Wert von 0 bis 100 ist etwas anderes: ein Labortest von Lighthouse. Google wertet 90 bis 100 als gut, 50 bis 89 als verbesserungswürdig und 0 bis 49 als schlecht. Für den mobilen Test simuliert PageSpeed Insights ein Mittelklasse-Handy mit Mobilverbindung. Deshalb kann eine Seite, die sich am Bürorechner flott anfühlt, schlecht abschneiden.

Was wir bei Firmen-Websites gemessen haben

Bevor wir eine Website neu bauen, testen wir ihre Startseite mit Google PageSpeed Insights im mobilen Labortest, derselbe Test, den unsere kostenlose Website-Analyse macht. Die Zahlen unten stammen von mehr als 130 Websites kleiner Unternehmen, die wir 2026 so getestet haben, eine Messung pro Seite, überwiegend WordPress (ShiftPress-Daten, 2026).

Auffällig ist der vorletzte Wert. Die Total Blocking Time misst, wie lange JavaScript den Browser beschäftigt. Mit 17 Millisekunden im Median lag sie fast bei null. Die typische Seite war also nicht langsam, weil schwerer Code lief. Sie war langsam, weil das größte Element im ersten Bildschirm sieben Sekunden brauchte. Das deutet auf die Bildgröße und auf alles, was der Browser vor diesem Bild noch laden muss.

Was die langsamen Seiten gemeinsam hatten

Wenn unser Kopierwerkzeug eine Website einliest, notiert es, was darauf läuft: Tag Manager, Cookie-Tool, Page-Builder, Slider. Neben die PageSpeed-Ergebnisse gelegt, zeigt sich ein Muster.

Lies das als Muster, nicht als Beweis. Diese Dinge treten oft gemeinsam auf (eine Seite mit Tag Manager hat meist auch ein Cookie-Tool), und manche Gruppen sind klein. Aber die Richtung ist in jeder Zeile dieselbe, und sie passt zu Googles eigener Anleitung zum LCP: Alles, was den Browser davon abhält, das Hauptbild zu finden und zu laden, macht die Seite langsamer.

Das Gewicht erzählt dieselbe Geschichte. In unserem Website-CO2-Report wog die Startseite einer neuen Firma im Median 1,62 MB. Ein Handy im Mobilnetz braucht für jedes dieser Megabytes Zeit.

Die Checkliste, sortiert nach Wirkung

1. Den ersten Bildschirm leicht machen

Ein Titelbild, kein Slider. Exportier es in der Größe, in der es angezeigt wird (rund 1.600 Pixel Breite reichen für ein Bild über die volle Breite), als WebP oder AVIF, und komprimier es. Gib dem <img> eine width und height, damit nichts springt, setz fetchpriority="high" und lade es nie verzögert: Laut Google führt Lazy Loading beim LCP-Bild immer zu unnötiger Wartezeit. Ist der Einstieg eine Überschrift auf Farbe, umso besser: Text ist das schnellste LCP-Element, das es gibt.

2. Fremd-Skripte streichen, angefangen beim Tag Manager

In unseren Daten war das der größte Unterschied: 11,0 gegen 6,4 Sekunden. Ein Tag Manager ist ein Behälter, der weitere Skripte nachlädt, und er wächst gern. Frag dich, welche Werkzeuge du wirklich anschaust. Für die meisten kleinen Unternehmen reicht ein Analyse-Skript, das erst nach der Einwilligung lädt. Karten, Videos und Social-Feeds weiter unten können eine statische Vorschau zeigen und erst auf Klick laden.

3. Das Cookie-Tool mit Blick auf die Ladezeit wählen

Ein Banner, das vor allem anderen sein eigenes Framework, Schriften und eine Anbieterliste lädt, kostet bei jedem Besuch Zeit. Weniger Tracker heißt kleinerer Banner, und eine Seite ganz ohne Tracking-Cookies braucht viel weniger Einwilligungs-Technik. Ob du einen Banner brauchst, ist eine Rechtsfrage für deinen Fall. Die Wirkung auf die Ladezeit ist es nicht.

4. Auf den Page-Builder verzichten

Visuelle Page-Builder packen jeden Abschnitt in Schichten aus zusätzlichem Markup, CSS und Skripten. Der Unterschied war in unseren Daten kleiner als bei den Skripten (7,8 gegen 6,7 Sekunden), aber er steckt in jeder Seite. Wenn KI die Website schreibt, gibt es keinen Grund für einen Builder: Schlichtes HTML und CSS kann Claude ohnehin am besten.

5. Schriften auf zwei Dateien begrenzen

Hoste die Schriften selbst (keine Anfrage an einen Schriften-Dienst), nimm woff2, höchstens zwei Schnitte und font-display: swap, damit der Text sofort in einer Ersatzschrift erscheint.

6. Statische Dateien über ein CDN ausliefern

Eine statische Seite wird einmal gebaut und dann als fertige Datei von Servern nahe beim Besucher ausgeliefert. So kommt das erste Byte schnell an. An dieser Stelle zählt die Wahl des Systems wirklich, und deshalb passen statische Websites gut zu kleinen Unternehmen (mehr dazu in Vorteile und Nachteile statischer Websites).

7. Alles unterhalb des ersten Bildschirms: verzögert, mit Maßen, leicht

Bilder weiter unten bekommen loading="lazy", Breite und Höhe und ein srcset, damit Handys keine Desktop-Größen laden. So bleibt die Layout-Verschiebung klein und der erste Bildschirm frei.

Sag es Claude: die Regeln in einem Block

Claude hält sich gut an ein Ladezeit-Briefing. Ohne eines greift es oft zu großen Stockfotos, mehreren Schriftschnitten und der einen oder anderen Bibliothek. Kopier diesen Block in deinen ersten Prompt oder in die CLAUDE.md, wenn du mit Claude Code baust, damit er für jede Seite gilt:

## Regeln für die Ladezeit (gelten für jede Seite)
    - Budget: LCP unter 2,5 s auf einem Mittelklasse-Handy, CLS unter 0,1,
      Startseite insgesamt unter 1 MB.
    - Einstieg: ein Bild oder schlichter Text auf Farbe. Kein Slider,
      kein Karussell, kein Video mit Autoplay.
    - Titelbild: höchstens 1600 px breit, WebP oder AVIF, komprimiert,
      width und height gesetzt, fetchpriority="high", nie loading="lazy".
    - Alle anderen Bilder: loading="lazy", width und height gesetzt,
      srcset mit einer Handy- und einer Desktop-Größe.
    - Schriften: selbst gehostet als woff2, höchstens 2 Dateien,
      font-display: swap.
    - Schlichtes HTML und CSS. Kein Page-Builder, kein UI-Framework für
      Inhaltsseiten, JavaScript nur, wo eine Funktion es braucht.
    - Kein Tag Manager. Ein Analyse-Skript, das erst nach Einwilligung lädt.
    - Karten, Videos und Social-Feeds: statische Vorschau, Laden auf Klick.
    - Am Ende: Gesamtgewicht und LCP-Element jeder Seite auflisten.

Design-Skills sorgen dafür, dass das Ergebnis besser aussieht, ohne diese Regeln zu brechen. Welche du laden solltest, steht in den besten Claude-Skills für Webdesign, welches Modell du nimmst, im Artikel bestes Claude-Modell für Webdesign. Lass nach jedem Bau die Startseite mobil durch PageSpeed Insights laufen und gib Claude die wichtigsten Hinweise zurück.

Und welches CMS ist nun das schnellste?

Für ein kleines Unternehmen ist das schnellste Setup das, das fertige statische Seiten ausliefert und sich sonst heraushält. Wenn du schon viele Inhalte hast, nimm ein System, das sie ohne Neubau importiert, statische Seiten veröffentlicht oder jede Seite komplett zwischenspeichert und dir keinen Page-Builder aufzwingt. Teste dann eine echte Seite, bevor du den Rest umziehst. Unser Vergleich der CMS-Plattformen geht die Möglichkeiten durch. Denk dabei an die Zahlen oben: Keine der langsamen Seiten in unserer Stichprobe war wegen des CMS-Namens im Footer langsam. Langsam machte sie, was im ersten Bildschirm stand. Noch keine Website? Du kannst dein Unternehmen beschreiben und eine erste Version bekommen, die du danach per Chat änderst.

Häufige Fragen

Fazit

Schnell ist eine Entscheidung, die im ersten Bildschirm fällt: ein leichtes Bild, wenige Skripte, kein Builder, statische Dateien. Die typische Firmen-Website in unseren Daten hat das verpasst und brauchte sieben Sekunden für ihren Hauptinhalt. Eine KI kann dir eine Website bauen, die in unter zweieinhalb Sekunden lädt, solange das Briefing es verlangt.