Engineering
Eine Studio-Website unter einer Sekunde: unser Performance-Budget
Wie wir Studio-Websites ausliefern, deren erster Inhalt auf einem Mittelklasse-Smartphone über 4G in unter einer Sekunde erscheint – das Budget, an das wir uns halten, was wegfällt und welche kleinen Architekturentscheidungen für die Core Web Vitals am meisten zählen.
In diesem Artikel
Es gibt eine bestimmte Art von Studio-Website – die, bei der jeder Scroll einen Parallax-Schimmer auslöst, einen Font-Wechsel, ein automatisch startendes Showreel, das drei Sekunden puffert, und einen Cursor, dem beim Hover Reißzähne wachsen –, die auf einem Mittelklasse-Smartphone acht Sekunden lädt und sich auf jeder Verbindung ohne Glasfaser kaputt anfühlt. So etwas liefern wir nicht aus. Die Vorgabe, an die wir uns halten, ist brutal und einfach: First Contentful Paint in unter einer Sekunde, auf einem Pixel 6a, über eine gedrosselte 4G-Verbindung.
Diese Vorgabe zu erfüllen, hat nichts mit heroischer Optimierung zu tun. Es geht um wenige Architekturentscheidungen, die sich gegenseitig verstärken, und um eine viel größere Zahl von Dingen, die wir bewusst lassen. Dieser Artikel zeigt das Budget, mit dem wir arbeiten, die Entscheidungen dahinter und die Feldmessungen, die belegen, dass das Budget gehalten hat. Wenn Sie eine Studio-Website, eine Agentur-Website oder irgendeine Art von Portfolio ausliefern, ist das ein Ziel aus der Praxis, das Sie fast eins zu eins übernehmen können.
Das Budget in Zahlen
Jede Studio-Website, die wir ausliefern, zielt auf diese Werte – auf einem Pixel 6a mit Fast-3G-Drosselung in den Chrome DevTools. Über 4G ist es in der Realität schneller; Fast 3G dient uns als Worst-Case-Untergrenze. Wir messen mit Lighthouse und mit Real-User-Metriken im Live-Betrieb über Vercel Analytics.
- Largest Contentful Paint (LCP): unter 1,2 s im Labor, unter 1,8 s (p75) im Feld. Googles Schwelle für „gut“ liegt bei 2,5 s.
- First Contentful Paint (FCP): unter 1,0 s im Labor.
- Cumulative Layout Shift (CLS): unter 0,05. Googles Schwelle für „gut“ liegt bei 0,1; wir halten uns an die Hälfte.
- Interaction to Next Paint (INP): unter 100 ms. Googles Schwelle für „gut“ liegt bei 200 ms.
- Gesamte Transfergröße beim ersten Laden: unter 150 KB komprimiert, inklusive HTML, CSS, Fonts, JS und Hero-Bild.
- JavaScript-Bundle beim ersten Laden: unter 80 KB komprimiert.
Verfehlt eine Seite einen dieser Werte, behandeln wir das als P1-Bug. Nicht als „machen wir später“. Als P1, den wir beheben, bevor die Website live geht.
Warum so streng?
Aus zwei Gründen. Erstens sind die Core Web Vitals ein Rankingfaktor bei Google. Kein Zünglein an der Waage – ein Rankingfaktor. Websites, die die Schwellenwerte erreichen, kommen für den Page-Experience-Boost infrage; alle anderen werden am Rand abgestraft. Für ein Studio, das um enge Keyword-Cluster konkurriert, zählt dieser Rand.
Zweitens ist gefühlte Performance ein Markensignal. Eine Website, die sofort lädt, wirkt kompetent. Eine Website, die hängt, während ein Tracking-Pixel lädt, wirkt es nicht. Für ein Studio, dessen ganzes Versprechen „wir liefern durchdachte, moderne Arbeit“ lautet, muss die Website dieses Versprechen beim ersten Kontakt einlösen. Die Website ist das Briefing.
Entscheidung 1: Alles statisch rendern
Die wichtigste Performance-Entscheidung ist die Rendering-Strategie. Wir nutzen Next.js mit dem App Router, und jede Seite unserer Studio-Websites wird zur Build-Zeit statisch gerendert. Keine Datenbankabfragen zur Laufzeit. Keine Serverarbeit pro Request über die Edge-Funktion hinaus, die das HTML ausliefert. Die gesamte Website besteht aus Dateien auf einem CDN.
Was Ihnen das konkret bringt: Die TTFB am Edge ist, was Ihr CDN hergibt – typischerweise 30–80 ms, überall auf der Welt. Das erste Byte HTML kommt an, bevor der Browser bei einer serverseitig gerenderten Alternative seinen TLS-Handshake abgeschlossen hat. Alles, was folgt – Darstellung, Interaktivität, die nächste Seite –, beginnt entsprechend früher.
Der Preis dafür: Inhaltsänderungen erfordern ein Deployment. Für eine Studio-Website, die monatlich aktualisiert wird, ist ein Deployment kein Thema – es dauert auf Vercel 90 Sekunden. Für eine Publikation, die stündlich aktualisiert wird, sieht die Rechnung anders aus, und ISR (Incremental Static Regeneration) ist das richtige Werkzeug. Aber Studio-Websites werden nicht stündlich aktualisiert.
Entscheidung 2: Ein Webfont, zwei Schnitte
Eigene Schriften sind der größte steuerbare Kostenfaktor beim ersten Rendern. Ein Webfont-Subset für einen einzigen Schnitt wiegt typischerweise 25–40 KB komprimiert. Eine Website, die drei Schnitte aus zwei Familien lädt, liefert 150 KB Fonts aus, bevor das erste Byte Inhalt erscheint. Wir liefern eine Familie in zwei Schnitten aus, selbst gehostet und gehasht über next/font – kein Drittanbieter-Request an Google Fonts, kein DNS-Lookup bei einem Font-CDN.
Die Konsequenz nehmen wir in Kauf: kein Kursiv, kein Thin, kein Extrabold. Jede typografische Unterscheidung muss über Größe, Farbe, Laufweite oder den Kontrast zwischen unseren zwei Schnitten entstehen. Diese kreative Einschränkung zahlt sich aus. Websites, die acht Schnitte brauchen, verstecken oft eine schwache Hierarchie hinter typografischer Vielfalt; Websites mit zwei Schnitten müssen sich ihre Hierarchie strukturell erarbeiten.
Entscheidung 3: Das Budget fürs Hero-Bild – und wie man es ausgibt
Auf einer Studio-Website ist das LCP-Element fast immer das Hero-Bild. Das LCP-Budget ist also das Hero-Budget. Wir geben dem Hero-Bild eine feste Obergrenze: 80 KB komprimiert am Desktop-Breakpoint, 40 KB auf Mobilgeräten. Alles darüber ist eine kreative Aufgabe, die bei Bildauswahl oder -bearbeitung zu lösen ist – keine Ausrede, das Budget zu überziehen.
Vier Praktiken, mit denen wir im Budget bleiben:
- AVIF, wo unterstützt, mit WebP als Fallback. AVIF ist bei gleicher Qualität typischerweise 30–40 % kleiner als WebP.
- Responsive Größen über die next/image-Komponente ausliefern. Smartphones laden nie das Desktop-Hero, Desktops nie die Retina-2x-Version, außer der Bildschirm ist tatsächlich Retina.
- Explizite Breite und Höhe für jedes Bild setzen. Genau das verhindert Layout-Verschiebungen – der Browser reserviert die richtige Pixelzahl, bevor das Bild ankommt.
- Das Hero-Bild vorladen. <link rel="preload" as="image" href="…"/> in den Head. Kostet eine Zeile und spart 200–400 ms beim LCP, weil der Browser die Bildanfrage startet, bevor er den Rest der Seite parst.
Entscheidung 4: JavaScript als letztes Mittel
Jedes Kilobyte JavaScript muss heruntergeladen, geparst und auf dem Main Thread ausgeführt werden, bevor die Seite interaktiv ist. Wir behandeln das JS-Budget als knappes Gut und halten uns an zwei Regeln:
- Standardmäßig Server Components. Eine Komponente nur dann mit 'use client' markieren, wenn sie wirklich Interaktivität braucht. Der Standard von React Server Components ist für inhaltsstarke Websites der richtige.
- Keine Drittanbieter-Skripte beim ersten Laden. Keine Analytics, die 80 KB Vendor-Code mitbringen. Keine Tag-Manager. Analytics lädt erst, wenn die Seite interaktiv ist – wir nutzen Vercel Analytics mit rund 1 KB.
Unser Budget für Studio-Websites liegt unter 80 KB komprimiertem JS beim ersten Laden – das meiste davon ist React selbst. Die interaktive Schicht (Navigationsmenü, Sprachumschalter, Kontaktformular) macht nur ein paar Kilobyte aus.
Entscheidung 5: CSS-Architektur ohne Layout-Shift-Bugs
Cumulative Layout Shift ist der Core Web Vital, den man am leichtesten versehentlich reißt – und am leichtesten gezielt behebt. Vier Gewohnheiten halten den CLS nahe null:
- Platz reservieren für alles, was spät kommt. Bilder, Fonts, iframes, Anzeigen – alles bekommt einen aspect-ratio-Container mit expliziten Maßen.
- CSS vermeiden, das vom geladenen Font abhängt. Während des Swap-Fensters System-Fonts als Fallback nutzen, mit font-display: swap. Einen Fallback wählen, dessen Metriken zum Webfont passen, damit der Wechsel unsichtbar bleibt.
- Nach dem Laden keine Inhalte im sofort sichtbaren Bereich einfügen. Banner, Cookie-Hinweise und Ankündigungsleisten, die nach dem ersten Rendern auftauchen, sind vorprogrammierte Layout-Verschiebungen. Wenn Sie sie brauchen, rendern Sie sie im initialen HTML und blenden Sie sie per Animation ein.
- Auf langsamen Netzen testen. CLS-Probleme, die über Glasfaser unsichtbar bleiben, zeigen sich über 3G, weil die späte Ressource dort am spätesten ankommt.
Entscheidung 6: Das Animationsbudget
Zurückhaltung bei Bewegung ist eine Performance-Optimierung für sich. Jede Animation auf dem Main Thread riskiert eine INP-Verschlechterung – eine einzige ruckelnde 250-ms-Animation beim Klick wirft die ganze Website aus dem INP-Bereich „gut“. Unsere Regeln:
- Nur transform und opacity animieren. Beides wird auf der GPU zusammengesetzt und löst kein Layout aus.
- Einblend-Animationen sind CSS, nicht JavaScript. Ein IntersectionObserver fügt einen className hinzu; die eigentliche Animation ist eine Transition.
- Keine scrollgekoppelten Animationen. Sie klingen elegant und liefern auf Mittelklasse-Geräten eine furchtbare Scroll-Performance.
- Kein automatisch startendes Video im Hero. Wenn Video nötig ist, per Lazy Loading unterhalb des sichtbaren Bereichs oder erst nach einer Interaktion laden.
Entscheidung 7: Wo Barrierefreiheit und Performance sich decken
Die meisten Gewinne bei der Barrierefreiheit sind auch Performance-Gewinne. Semantisches HTML ist kleiner als Div-Suppe. Native Fokusringe rendern schneller als ein eigenes JS-Fokusmanagement. Skip-Links im Header machen Keyboard-Trap-Fixes überflüssig, die JavaScript mitbringen. Wir gestalten und bauen zuerst barrierefrei; Performance gibt es gratis dazu.
Die einzige Stelle, an der Performance und Barrierefreiheit in Spannung geraten, ist Animation. Manche Nutzer brauchen Bewegung, anderen wird davon übel. Wir respektieren prefers-reduced-motion und liefern jede Einblend-Animation mit einem Fade als Fallback aus – nicht mit einem Translate.
Messen im Live-Betrieb
Labormetriken aus Lighthouse sind notwendig, aber nicht ausreichend. Der Goldstandard ist Real-User-Monitoring (RUM) – was echte Besucher auf echten Geräten erleben. Für die Web Vitals nutzen wir Vercel Analytics, weil es kostenlos zur Plattform gehört und Feldmetriken nach Route, Gerät und Region aufschlüsselt.
Was wir wöchentlich prüfen:
- p75-LCP pro Route. Liegt eine Route bei p75 über 1,8 s, gehen wir der Sache nach.
- INP-Verschlechterungen. INP ist die heimtückischste Metrik – sie kann sich unbemerkt verschlechtern, während das JavaScript wächst.
- CLS pro Route. CLS-Verschlechterungen gehen meist auf ein einzelnes, spät ladendes Element zurück.
- JS beim ersten Laden pro Route, überwacht per Bundle Analyzer in der CI. Builds, die das Budget sprengen, lassen wir fehlschlagen.
Was wir nicht machen
Genauso wichtig – die Dinge, die wir bewusst weglassen, obwohl sie Branchenstandard sind:
- Kein clientseitiges Routing im SPA-Stil auf einer kleinen Website. Über 4G ist das Laden des kompletten Dokuments schneller als das Bundle-Delta. Wir lassen den Browser navigieren.
- Kein Service Worker. Bei einer Website mit weniger als zehn Seiten lohnt sich die Komplexität nicht.
- Kein Bild-Hosting-Dienst, der ein 30-KB-SDK einschleust. Wir liefern Bilder von derselben Domain wie die Website aus, optimiert zur Build-Zeit.
- Keine „smarte“ Lazy-Load-Bibliothek. Das native Attribut loading="lazy" erledigt das mit 0 KB.
- Kein Prefetching jedes Links beim Hover. Next.js lädt in Produktion standardmäßig vor; das lassen wir an und überlassen die Entscheidung dem Framework.
Wenn Sie eine Website planen und ein Performance-Audit Ihres Bestands möchten – oder eine, die von Anfang an nach diesem Budget gebaut wird: hello@neptay.com.