Ein grüner Wert im Performance-Test ist kein Selbstzweck. Er ist das sichtbare Ergebnis einer Architekturentscheidung: Wird eine Seite bei jedem Aufruf neu zusammengesetzt, oder liegt sie fertig auf dem Server und wird nur noch ausgeliefert? Dieser eine Unterschied bestimmt, wie viel Arbeit zwischen dem Klick und dem ersten sichtbaren Inhalt liegt. Dieser Artikel erklärt, warum statisch ausgelieferte Seiten bei den Core Web Vitals strukturell im Vorteil sind, was LCP, INP und CLS im Alltag bedeuten und wie Sie Messwerte lesen, ohne sich von einer einzelnen Zahl in die Irre führen zu lassen.
Was ein PageSpeed-Wert von 100 wirklich aussagt
Ein Performance-Score fasst mehrere Labormessungen zu einer einzigen Zahl zusammen: simuliertes Gerät, gedrosseltes Netz, definierter Startpunkt. Genau das macht ihn reproduzierbar, und genau deshalb erzählt er nur die halbe Geschichte.
Bewertet wird, wie viel Arbeit eine Seite dem Browser abverlangt, bevor jemand etwas sieht. Die Ausgangslage ist dabei ernüchternd: Eine mobil abgerufene Seite überträgt im Median rund 2,4 Megabyte (HTTP Archive Web Almanac), davon entfallen mehr als 500 Kilobyte (HTTP Archive Web Almanac) allein auf JavaScript. Gleichzeitig betreiben rund 89 Prozent (Statistisches Bundesamt) der Unternehmen mit Internetzugang eine eigene Website. Wer in diesem Umfeld schnell sein will, muss zuerst eine Frage beantworten: Wo entsteht die Seite eigentlich — im Browser, im Renderpfad des Servers oder bereits beim Build? Ein hoher Wert ist dabei kein Beweis für eine gute Website, sondern ein Hinweis darauf, dass die technische Grundlage sauber ist. Umgekehrt ist ein schwacher Wert selten ein Zufallsprodukt: Er zeigt an, dass an irgendeiner Stelle Arbeit in den Moment des Seitenaufrufs verschoben wurde. Unsere Leistungen rund um Aufbau und Auslieferung setzen genau an dieser Stelle an.
Labor und Feld messen Unterschiedliches
Die drei Core Web Vitals im Klartext
Die Core Web Vitals bündeln drei Fragen: Wann sieht der Nutzer den Hauptinhalt (LCP)? Wie schnell reagiert die Seite auf eine Eingabe (INP)? Und bleibt das Layout dabei ruhig (CLS)?
Nur rund 48 Prozent (HTTP Archive Web Almanac) der mobil abgerufenen Websites erreichen in allen drei Werten eine gute Bewertung. Der Grund ist selten ein einzelner Fehler, sondern die Summe vieler kleiner Laufzeitentscheidungen: ein zu großes Titelbild, eine spät nachgeladene Schrift, ein Skript, das den Hauptthread blockiert, ein Banner, das den Text nach unten schiebt. Praktisch heißt das: Wer die drei Werte verbessern will, muss weniger ausliefern, früher ausliefern und nach dem ersten Zeichnen weniger verändern. Alle drei Punkte hängen unmittelbar davon ab, wie die Seite überhaupt entsteht. Wie das heute abläuft, beschreibt der Beitrag Website mit KI erstellen — die dort gewählte Architektur entscheidet später über die Messwerte.
LCP: Hauptinhalt sichtbar
Misst, wann das größte sichtbare Element im Sichtfenster fertig gezeichnet ist, meist ein Bild oder eine Überschrift. Serverzeit, Bildgröße und blockierende Ressourcen wirken unmittelbar auf diesen Wert.
INP: Reaktion auf Eingaben
Bewertet die Verzögerung zwischen Klick oder Tastendruck und der nächsten sichtbaren Reaktion. Lange JavaScript-Aufgaben belegen den Hauptthread und verschlechtern den Wert spürbar.
CLS: Ruhe im Layout
Erfasst, wie stark Inhalte nach dem ersten Zeichnen noch verspringen. Bilder ohne Größenangabe, spät geladene Schriften und eingeblendete Banner sind die typischen Auslöser.
Tabelle waagerecht wischen
| Metrik | Gut | Verbesserungswürdig | Schwach |
|---|---|---|---|
| LCP (größtes Inhaltselement) | bis 2,5 Sekunden | 2,5 bis 4,0 Sekunden | über 4,0 Sekunden |
| INP (Reaktion auf Eingaben) | bis 200 Millisekunden | 200 bis 500 Millisekunden | über 500 Millisekunden |
| CLS (Layoutverschiebung) | bis 0,1 | 0,1 bis 0,25 | über 0,25 |
Warum Rendern zur Laufzeit Zeit kostet
Bei einer zur Laufzeit erzeugten Seite beginnt die eigentliche Arbeit erst mit der Anfrage.
Der Server startet einen Interpreter, lädt ein Framework, verbindet sich mit der Datenbank, führt Abfragen für Inhalte, Navigation und Einstellungen aus, setzt Templates zusammen, lässt Erweiterungen ihre Filter anwenden — und schickt erst danach das erste Byte auf die Reise. Jeder dieser Schritte ist für sich genommen kurz. In Summe entsteht daraus die Zeit bis zum ersten Byte, und die verschiebt alles Nachfolgende nach hinten: Erst wenn das HTML ankommt, erfährt der Browser überhaupt, welche Schriften, Bilder und Skripte er noch braucht. Damit verschlechtert sich in der Regel auch das LCP. Hinzu kommt, dass diese Kette bei jedem einzelnen Aufruf erneut durchlaufen wird, auch dann, wenn sich am Inhalt seit Wochen nichts geändert hat. Zwischenspeicher können das abmildern, führen aber eine weitere Ebene ein, die konfiguriert, überwacht und bei jeder Änderung geleert werden muss. Wie der Weg vom Briefing bis zur ausgelieferten Seite bei uns aussieht, zeigt die Übersicht So funktioniert XICflow.
- Die Anfrage trifft den Webserver und wird an den Interpreter weitergereicht
- Framework, Konfiguration und Erweiterungen werden geladen und initialisiert
- Datenbankabfragen für Inhalte, Navigation, Einstellungen und Übersetzungen laufen
- Templates werden zusammengesetzt, Filter und Erweiterungspunkte greifen ein
- Das fertige HTML wird ausgegeben, erst jetzt beginnt die Übertragung
- Der Browser entdeckt Schriften, Bilder und Skripte und fordert sie einzeln nach
Jede Millisekunde, die ein Server mit dem Zusammensetzen einer Seite verbringt, fehlt dem Browser später beim Zeichnen des sichtbaren Inhalts.
Der strukturelle Vorteil statischer Auslieferung
Statisch ausgeliefert heißt: Das HTML existiert bereits, bevor der erste Besucher kommt. Der Webserver sucht eine Datei und sendet sie aus — mehr passiert pro Aufruf nicht.
Damit entfällt der komplette Renderpfad zur Laufzeit, und die Zeit bis zum ersten Byte hängt praktisch nur noch von Netzweg und Dateigröße ab. Eine solche Datei ist zudem unveränderlich, solange sie nicht neu gebaut wird. Genau das macht sie zwischenspeicherbar: im Browser, im vorgelagerten Proxy, an verteilten Auslieferungspunkten. Ein Cache-Treffer ist der kürzeste denkbare Weg zum ersten Byte, weil dabei kein Anwendungsserver mehr beteiligt ist. Für die redaktionelle Arbeit ändert sich dadurch wenig: Inhalte werden weiterhin in einer Oberfläche gepflegt, nur liegt zwischen Eingabe und Auslieferung ein Build-Schritt, der aus der Konfiguration fertige Seiten erzeugt. Der Unterschied liegt im Zeitpunkt der Arbeit, nicht im Arbeitsablauf. Wie sich das im Ergebnis anfühlt, zeigen unsere Beispiel-Websites in der Demo-Übersicht.
Kein Renderpfad zur Laufzeit
Kein Interpreter-Start, keine Datenbankabfrage, kein Zusammensetzen von Templates pro Aufruf. Der Server liest eine vorbereitete Datei und liefert sie unverändert aus.
Cache- und CDN-freundlich
Unveränderliche Dateien lassen sich mit langen Gültigkeiten ausliefern und an verteilten Standorten vorhalten. Wiederkehrende Besucher laden häufig kaum noch etwas neu.
Weniger bewegliche Teile
Ohne Laufzeit-Erweiterungen entfallen typische Störquellen wie langsame Abfragen, Modulkonflikte oder Lastspitzen bei vielen gleichzeitigen Zugriffen.
Tabelle waagerecht wischen
| Aspekt | Zur Laufzeit erzeugt | Statisch ausgeliefert |
|---|---|---|
| Zeit bis zum ersten Byte | Abhängig von Datenbank, Templates und Erweiterungen | Datei wird gelesen und direkt gesendet |
| Verhalten unter Last | Rechenaufwand wächst mit jedem Aufruf | Dieselbe Datei bedient alle Aufrufe |
| Cache-Strategie | Fragmentiert, oft durch Personalisierung eingeschränkt | Lange Gültigkeiten, hohe Trefferquote |
| Typische Bremsen | Erweiterungen, Abfragen, Sitzungsverwaltung | Bildgrößen und eingebundene Drittanbieter |
| Betriebsrisiko | Aktualisierungen können die Auslieferung verändern | Änderungen entstehen im Build, nicht im laufenden Betrieb |
Ballast: Erweiterungen, Skripte und Drittanbieter
Der zweite große Hebel liegt nicht im Server, sondern im Seitenkopf.
Rund 94 Prozent (HTTP Archive Web Almanac) aller untersuchten Seiten binden mindestens eine Drittanbieter-Ressource ein: Schriftdienste, Videoeinbettungen, Kartenmaterial, Werbe- und Messbausteine. Jede dieser Ressourcen kostet eine Namensauflösung, einen Verbindungsaufbau und Übertragungszeit — und viele führen anschließend eigenen Code aus, der den Hauptthread belegt und damit direkt auf die Reaktionsfähigkeit schlägt. Bei klassischen CMS-Installationen kommt der Erweiterungs-Stack hinzu: Jedes zusätzliche Modul bringt eigene Stylesheets und Skripte mit, oft global auf allen Seiten geladen, auch dort, wo die Funktion gar nicht vorkommt. Ein einfacher Test hilft weiter: Zählen Sie auf einer typischen Unterseite alle Verbindungen zu fremden Servern und fragen Sie bei jeder einzelnen, welchen messbaren Beitrag sie leistet. Übrig bleiben erfahrungsgemäß deutlich weniger Einbindungen als ursprünglich vorhanden. Was das für die Wahl einer Plattform bedeutet, ordnet unsere Gegenüberstellung der Ansätze ein.
- Schriftdateien von externen Diensten statt selbst gehostet im eigenen Verzeichnis
- Videoeinbettungen, die schon vor dem ersten Klick umfangreiche Skripte nachladen
- Kartenmaterial auf jeder Seite eingebunden statt ausschließlich auf der Kontaktseite
- Mehrere Mess- und Marketing-Werkzeuge parallel, teilweise mit derselben Funktion
- Erweiterungen, deren Stylesheets global geladen werden, obwohl sie eine Seite betreffen
- Slider- und Animationsbibliotheken für Effekte, die sich auch mit CSS umsetzen ließen
Drittanbieter sind auch ein Rechtsthema
Messwerte richtig lesen
Messen heißt vergleichen, und dafür braucht es feste Bedingungen.
Ein einzelner Testlauf schwankt je nach Netz, Serverauslastung und Cache-Zustand deutlich; aussagekräftig wird das Bild erst über mehrere Läufe und über mehrere Seitentypen hinweg. Weil in Deutschland etwa neun von zehn (Bitkom) Menschen ein Smartphone nutzen, ist die mobile Messung der Maßstab und nicht die Desktop-Ansicht auf einem schnellen Anschluss. Für die Bewertung im Feld gilt zusätzlich das 75. Perzentil: Drei von vier Seitenaufrufen sollen unter dem Schwellenwert liegen, der Durchschnitt spielt dabei keine Rolle. Und schließlich gehört zu jeder Messung die Frage, was gerade gemessen wurde: eine Seite mit oder ohne akzeptiertes Einwilligungsbanner, mit kaltem oder warmem Cache. Hilfreich ist außerdem ein schlichtes Protokoll: Datum, Seite, Gerätetyp, Netzprofil und Ergebnis in einer Tabelle. So lässt sich später nachvollziehen, ob eine Verschlechterung mit einer bestimmten Änderung zusammenfällt oder ob lediglich die Messbedingungen andere waren. Welche Bausteine bei uns ab Werk enthalten sind, steht in der Leistungsübersicht.
- Mobil messen, nicht nur am Desktop mit schnellem Anschluss
- Mindestens drei Läufe pro Seite durchführen und den mittleren Wert verwenden
- Startseite, eine Leistungsseite und eine Detailseite getrennt betrachten
- Laborwert und Felddaten nebeneinanderlegen, statt sie gegeneinander auszuspielen
- Nach jeder größeren Änderung neu messen und das Ergebnis mit Datum festhalten
- Cache-Zustand und Einwilligungsstatus jedes Testlaufs bewusst dokumentieren
Das 75. Perzentil ist der Maßstab
Bilder, Schriften und Cache-Strategie
Wenn die Architektur steht, sind die verbleibenden Stellschrauben handwerklich.
Bilder brauchen feste Breiten- und Höhenangaben, damit der Browser den Platz reservieren kann, bevor die Datei eingetroffen ist; das allein verhindert einen großen Teil der Layoutsprünge. Sie gehören zudem in moderne Formate und in die Größe, in der sie tatsächlich angezeigt werden. Schriften gehören auf den eigenen Server, reduziert auf die benötigten Schnitte, mit gesteuertem Anzeigeverhalten über font-display und einer Vorladeanweisung für den Schnitt im sichtbaren Bereich. Bei der Auslieferung gilt eine einfache Trennung: versionierte Dateien lange gültig, HTML kurz und mit Revalidierung. Wirksam ist zudem die Reihenfolge im Quelltext: Was im sichtbaren Bereich gebraucht wird, sollte früh geladen werden, alles andere später oder erst bei Bedarf. Bilder unterhalb des Sichtfensters lassen sich verzögert laden, ohne dass die Besucher davon etwas bemerken. Was in welchem Umfang enthalten ist, zeigt die Preisübersicht.
<!-- Schriften selbst hosten und den sichtbaren Schnitt vorladen -->
<link rel="preload" href="/fonts/inter-var.woff2" as="font"
type="font/woff2" crossorigin>
<!-- Feste Maße reservieren Platz und verhindern Layoutsprünge -->
<img src="/bilder/empfang.avif" width="1280" height="720"
alt="Empfangsbereich der Praxis"
fetchpriority="high" decoding="async">
<!-- Auslieferung: versionierte Dateien lange gültig, HTML kurz -->
Cache-Control: public, max-age=31536000, immutable (CSS, JS, Bilder)
Cache-Control: public, max-age=300, must-revalidate (HTML)So setzt XICflow das um
XICflow hält jede Website als Konfiguration in der Datenbank und baut daraus statische Dateien, die pro Domain ausgeliefert werden.
Es gibt keinen Renderpfad zur Laufzeit, keinen Erweiterungs-Stack und keine Modulaktualisierung, die im laufenden Betrieb etwas verschiebt. Ziel der Auslieferung ist ein Lighthouse-Ergebnis von 100 in allen vier Kategorien, also auch in der Barrierefreiheit — und das ist mehr als Kosmetik: Rund 95 Prozent (WebAIM Million) der untersuchten Startseiten weisen automatisiert erkennbare Verstöße gegen die Richtlinien der WCAG (W3C) auf, während der European Accessibility Act (Europäische Kommission) seit dem 28. Juni 2025 für viele Anbieter verbindlich ist. Auch Bilder, Rechtstexte und der Einwilligungsdialog stammen aus demselben Build und werden zusammen mit der Seite ausgeliefert; es kommen keine nachträglich eingesetzten Fremdbausteine hinzu, die den Ladepfad verlängern. Was daraus folgt, beschreibt der Beitrag BFSG: barrierefreie Website für Unternehmen; den Weg von der Eingabe bis zur fertigen Datei zeigt der Ablauf im Detail.
- Statische Auslieferung je Domain, kein Erzeugen der Seite zur Laufzeit
- Selbst gehostete Schriften und Bilder in modernen Formaten mit festen Maßen
- Barrierefreiheit auf Grundlage der WCAG 2.2 AA von der ersten Seite an
- Einwilligungsbanner ab Werk, ohne externen Dienst im Ladepfad
- Mehrsprachigkeit mit hreflang und übersetzten Slugs ohne Zusatzmodul
- Kontaktformular, Blog und KI-Assistent ohne schweren Laufzeit-Stack
Ihr Fahrplan für die nächsten Wochen
Ein Performance-Projekt scheitert selten am Wissen, sondern an der Reihenfolge. Beginnen Sie mit einer Bestandsaufnahme, bevor Sie einzelne Werte optimieren: Was wird geladen, von wem, und wofür eigentlich?
Häufig verschwindet ein erheblicher Teil des Seitengewichts, sobald Ressourcen entfernt werden, die niemand vermisst. Erst danach lohnt der Blick auf die Auslieferungsarchitektur und die Frage, ob die Seite überhaupt bei jedem Aufruf neu entstehen muss. Wie Einwilligungen dabei sauber und trotzdem schlank umgesetzt werden, beschreibt der Beitrag DSGVO und Consent richtig aufsetzen. Konkrete Beispiele für das Zusammenspiel finden Sie in den Demo-Websites.
- Alle geladenen Ressourcen einer typischen Seite auflisten und nach Herkunft sortieren
- Jede externe Einbindung schriftlich begründen oder ersatzlos entfernen
- Bilder auf die reale Anzeigegröße bringen und in ein modernes Format umwandeln
- Schriften selbst hosten, auf die benötigten Schnitte reduzieren und gezielt vorladen
- Prüfen, ob die Seite überhaupt zur Laufzeit erzeugt werden muss
- Nach dem Umbau mobil neu messen und die Felddaten vier Wochen lang beobachten
Schnelligkeit ist am Ende eine Frage der Architektur und nicht der Feinjustierung. Wer bei jedem Aufruf eine Seite neu zusammensetzt, arbeitet dauerhaft gegen die eigene Auslieferung; wer fertige Dateien ausliefert, verlagert diese Arbeit einmalig in den Build und hat danach erfahrungsgemäß ruhige Messwerte. Diese Entscheidung wirkt weit über die Ladezeit hinaus: auf Barrierefreiheit, auf Datenschutz und auch auf die internationale Auffindbarkeit, wie der Beitrag über mehrsprachige Websites mit hreflang zeigt. Für viele Unternehmen ist das auch die praktikabelste Reihenfolge: zuerst die Auslieferung klären, danach Inhalte und Sichtbarkeit ausbauen. Der Wert im Testwerkzeug bestätigt am Ende nur eine Entscheidung, die sehr viel früher gefallen ist.