Fotografen, Filmer, Handwerker mit Referenzbildern: Ihre Website lebt von großen Bildern und Videos – und genau die machen sie langsam. Wer mobil länger als zweieinhalb Sekunden auf das erste Bild wartet, ist oft schon wieder weg, und Google wertet langsame Seiten ab. Mit einem KI-Assistenten wie Claude Code lässt sich eine Seite heute in Stunden statt Wochen bauen. Schnell wird sie aber nur, wenn man der KI klare Regeln mitgibt. Dieser Leitfaden zeigt, welche.
Das Fundament: so wenig wie möglich
Die schnellste Technik ist die, die gar nicht erst geladen wird. Für eine Portfolio-Website braucht es kein Framework und kein Baukastensystem. Es genügen statische HTML-Seiten, ein Stylesheet, ein schlankes Skript ohne Bibliotheken und lokal gespeicherte Schriften im WOFF2-Format. Keine Google Fonts von außen, keine Slider-Plugins, keine Tracking-Skripte vor der Einwilligung. Was übrig bleibt, sind Inhalte – und die werden gezielt optimiert.
Bilder: das größte Einsparpotenzial
Ein Originalfoto aus der Kamera hat schnell 10 MB. Auf dem Handy wird es 400 Pixel breit angezeigt. Die Lösung ist, jedes Bild in festen Breiten bereitzustellen und den Browser wählen zu lassen:
- Format WebP, Qualität 78–82. Spürbar kleiner als JPG bei gleichem Eindruck.
- Drei Breiten: 480, 960 und 1920 Pixel, eingebunden mit
srcsetundsizes. - Immer
widthundheightangeben. So reserviert der Browser den Platz und nichts springt. - Lazy Loading für alles unterhalb des ersten Bildschirms, aber nie für das Titelbild. Das bekommt
fetchpriority="high"und wird im Kopf der Seite vorgeladen. - EXIF- und GPS-Daten entfernen. Das spart Bytes und verrät nicht, wo das Bild entstanden ist.
- Budget: höchstens 300 KB pro Bild in 1920 Pixeln, höchstens 1,5 MB für den ersten Seitenaufruf.
<img src="/assets/img/paar-03-960.webp"
srcset="/assets/img/paar-03-480.webp 480w,
/assets/img/paar-03-960.webp 960w,
/assets/img/paar-03-1920.webp 1920w"
sizes="(min-width: 900px) 50vw, 100vw"
width="960" height="640"
alt="Brautpaar im Schlossgarten bei Sonnenuntergang"
loading="lazy" decoding="async">Videos: Filme auslagern, Loops klein halten
Ganze Filme gehören nicht auf den eigenen Webserver. Sie liegen auf YouTube oder Vimeo und werden erst geladen, wenn jemand auf Play klickt. Bis dahin zeigt die Seite nur ein Vorschaubild. Das spart mehrere Megabyte und lädt keine fremden Cookies ohne Zustimmung.
Für Bewegung auf der Seite selbst reichen kurze, stumme Loops: autoplay muted loop playsinline preload="none" mit einem WebP-Vorschaubild. Der Titel-Loop darf höchstens 15 Sekunden und 5 MB haben, Kachel-Loops 3 Sekunden und 1 MB. Kachel-Loops starten erst, wenn sie ins Bild scrollen, und bei aktivierter Einstellung „Bewegung reduzieren“ gar nicht. Für Handys gibt es einen eigenen Schnitt im Hochformat. Mit ffmpeg entsteht so ein Loop in einer Zeile:
ffmpeg -ss 00:01:05 -i film.mp4 -an -t 3 -vf "scale=960:-2,fps=25" -c:v libx264 -crf 29 -preset slow -pix_fmt yuv420p -movflags +faststart loop-960.mp4Originale gehören nicht ins Repository
Die Website-Dateien liegen in einem Git-Repository, damit jede Änderung nachvollziehbar ist und automatisch veröffentlicht werden kann. Originalfotos und Rohfilme haben dort nichts verloren. Sie liegen in einem Cloud-Ordner, zum Beispiel Google Drive, je Projekt ein Unterordner mit den ausgewählten Fotos, dem Link zum Film und einer kurzen Textdatei mit Story und Credits. Ins Repository kommen nur die verkleinerten Web-Fassungen. So bleibt es klein, und der Cloud-Ordner ist das Archiv.
Prompts, die zu schnellen Seiten führen
Mit dem Regelwerk im Rücken kommt es auf die Aufträge an. Diese Muster haben sich bewährt:
- Konkret sagen, was entstehen soll – mit Ziel.
„Baue eine Portfolio-Seite für die Hochzeit von Anna und Ben aus dem Ordner 2026-06-schloss-anna-ben. Wähle 24 Bilder, rechne sie nach den Regeln in CLAUDE.md um und halte LCP mobil unter 2,5 s.“ - Messen lassen, nicht schätzen.
„Zeig mir vor dem Commit die zehn größten Dateien unter site/assets und ob alle Bilder width, height und alt haben.“ - Eine Sache pro Auftrag. Erst die Seite, dann die Galerie, dann der Film. Kleine Schritte lassen sich leichter prüfen und zurücknehmen.
- Vorschau verlangen, bevor veröffentlicht wird.
„Starte die lokale Vorschau und sag mir, was ich mir ansehen soll.“ - Bibliotheken ausdrücklich ausschließen.
„Baue die Lightbox ohne zusätzliche Bibliotheken, mit dem vorhandenen main.js.“ - Nach dem Livegang nachmessen.
„Prüfe die neue Seite mit PageSpeed Insights mobil und behebe alles, was unter 90 Punkten liegt.“ - Bei Problemen die Ursache suchen lassen.
„Finde heraus, was die Seite mobil langsam macht, und schlag mir die drei wirksamsten Änderungen vor.“
Checkliste vor jeder Veröffentlichung
- Alle Bilder als WebP in drei Breiten, keine Datei über dem Budget
- Jedes Bild mit
width,heightund aussagekräftigemalt-Text - Titelbild vorgeladen, alles andere lazy
- Filme nur per Klick-zum-Laden, Loops stumm und unter den Grenzen
- Keine neuen Bibliotheken oder fremden Skripte
- Neue Seite in der Sitemap, Titel und Meta-Beschreibung gesetzt
- Nach dem Livegang PageSpeed mobil mindestens 90
Fazit
Eine KI baut eine Website so schnell, wie man sie anleitet. Wer die Regeln einmal sauber in einer CLAUDE.md festhält, Originale vom Repository trennt und die KI messen statt schätzen lässt, bekommt eine Seite, die mobil schneller lädt als die meisten Baukastenseiten – und kann sie danach selbst weiterentwickeln. Detalex richtet Repository, automatische Veröffentlichung und Regelwerk ein und begleitet die ersten Schritte. Sprechen Sie uns an.