Performance & professionelles HTML

Das lernst du in dieser Lektion

Du verstehst den kritischen Rendering-Pfad und warum HTML dabei die Regie führt.
Du kannst LCP, CLS und INP als Messgrößen einordnen.
Du wählst sicher zwischen defer, async und type="module".
Du setzt Ressourcen-Hints wie preconnect und preload gezielt ein.
Du hast eine Checkliste für professionelles HTML für alle künftigen Projekte.

Willkommen in der letzten Lektion – und die hat es in sich. Wenn von Web-Performance die Rede ist, denken viele an Serverfarmen und JavaScript-Tricks. Dabei liegt der größte Hebel viel näher: in deinem HTML. Es ist die erste Datei, die der Browser bekommt – der Bauplan, aus dem er alle weiteren Ressourcen überhaupt erst entdeckt. Jede Reihenfolge, jedes Attribut in diesem Bauplan entscheidet mit, ob sich deine Seite blitzschnell oder zäh anfühlt. Zum Abschluss beider Kurse lernst du, diesen Bauplan wie ein Profi zu schreiben.

Der kritische Rendering-Pfad

Was passiert zwischen „Adresse eingetippt“ und „Seite sichtbar“? Der Browser arbeitet eine Kette ab, die man den kritischen Rendering-Pfad nennt. In einfachen Worten:

HTML zuerst: Der Browser lädt dein HTML und liest es von oben nach unten. Dabei baut er den Dokumentbaum auf – und entdeckt nach und nach alle weiteren Ressourcen: Stylesheets, Skripte, Bilder, Schriften.
CSS blockiert das Rendern: Trifft er auf ein Stylesheet, zeigt er nichts an, bis es geladen und verarbeitet ist. Das ist Absicht – sonst würdest du erst unformatierten Text sehen, der eine Sekunde später ruckartig umspringt.
Klassisches JavaScript blockiert das Parsen: Bei einem <script> ohne Zusatzattribute stoppt der Browser sogar das Lesen des HTML, lädt das Skript, führt es aus – und liest erst danach weiter. Denn das Skript könnte das Dokument ja mitten im Aufbau verändern.

Aus dieser Kette folgen die zwei ältesten Performance-Regeln des Webs fast von selbst: CSS so früh wie möglich in den <head>, damit der Browser sofort mit dem Rendern planen kann – und JavaScript niemals blockierend, sondern mit defer (oder notfalls ans Ende des <body>).

Core Web Vitals: LCP, CLS, INP

Damit „schnell“ messbar wird, hat Google drei Kennzahlen etabliert – die Core Web Vitals. Sie fließen ins Suchmaschinen-Ranking ein, und du solltest sie zumindest einordnen können:

LCP (Largest Contentful Paint): Wie schnell ist das größte Inhaltselement – meist das Hero-Bild oder die Hauptüberschrift – sichtbar? Als gut gelten Werte unter 2,5 Sekunden.
CLS (Cumulative Layout Shift): Wie stark springt das Layout während des Ladens? Jeder kennt den Moment, in dem man auf einen Link zielt und stattdessen die nachgerückte Werbung trifft.
INP (Interaction to Next Paint): Wie schnell reagiert die Seite auf Eingaben wie Klicks und Tastendrücke?

Das Schöne daran: Alle drei beeinflusst du direkt mit HTML-Mitteln. LCP über Ladeprioritäten, CLS über reservierte Flächen, INP über nicht blockierendes JavaScript. Genau darum geht es in den nächsten Abschnitten.

Ruhe im Layout: width, height und Ladeprioritäten

Layout-Springen entsteht fast immer durch Inhalte ohne reservierten Platz – allen voran Bilder. Die Lösung kennst du aus der Bilder-Lektion, aber sie gehört hier noch einmal aufs Podest: Gib jedem <img> (und jedem iframe) width und height. Aus den beiden Zahlen berechnet der Browser das Seitenverhältnis und hält die Fläche frei, noch bevor das erste Byte des Bildes geladen ist. Mit max-width: 100% und height: auto im CSS bleibt das Bild trotzdem responsiv – die Attribute legen nur das Verhältnis fest, nicht die endgültige Anzeigegröße.

Zur Erinnerung in zwei Sätzen: loading="lazy" lädt Bilder und iframes unterhalb des sichtbaren Bereichs erst bei Bedarf. Und fetchpriority="high" markiert dein wichtigstes Bild – meist das LCP-Element – als Chefsache, damit der Browser es vor allem anderen lädt.

Zwei Bilder, zwei Prioritäten

<!-- Das Hero-Bild: sofort und mit Vorrang laden -->
<img src="hero-backstube.jpg"
     alt="Blick in die Backstube am frühen Morgen"
     width="1200" height="600"
     fetchpriority="high">

<!-- Galerie weiter unten auf der Seite: darf warten -->
<img src="galerie-brote.jpg"
     alt="Sechs frisch gebackene Sauerteigbrote"
     width="400" height="300"
     loading="lazy">

JavaScript laden: defer, async, module

Für das Einbinden von Skripten gibt es vier Varianten – und der Unterschied entscheidet darüber, ob dein HTML flüssig verarbeitet wird oder ständig anhält:

Variante	Download	Ausführung	Wann nehmen?
`<script src="…">`	blockiert das Parsen	sofort – das HTML wartet	Gar nicht mehr – Altlast aus einer anderen Zeit.
`<script defer src="…">`	parallel zum Parsen	nach dem vollständigen Parsen, in Dokument-Reihenfolge	Der Standard für eigene Skripte, die mit dem DOM arbeiten.
`<script async src="…">`	parallel zum Parsen	sofort nach dem Download – Reihenfolge zufällig	Nur für unabhängige Skripte ohne Abhängigkeiten (z. B. Statistik).
`<script type="module" src="…">`	parallel zum Parsen	wie defer – nach dem Parsen	Moderne Projekte: import/export, strikter Modus, defer-Verhalten inklusive.

Die Merkregel: defer ist dein Standard. Es lädt nebenbei, führt in verlässlicher Reihenfolge aus, und das DOM ist beim Ausführen garantiert fertig aufgebaut. async lohnt sich nur, wenn ein Skript wirklich mit nichts anderem zusammenhängt – bei mehreren async-Skripten ist die Ausführungsreihenfolge Glückssache. Und type="module" bringt das defer-Verhalten automatisch mit; ein zusätzliches defer wäre dort wirkungslos.

Ressourcen-Hints: dem Browser einen Vorsprung geben

Manche Ressourcen entdeckt der Browser erst spät – eine Schriftdatei etwa taucht erst tief im CSS auf, und zu fremden Servern muss er erst umständlich eine Verbindung aufbauen (DNS-Auflösung, TCP, TLS – das kostet schnell mehrere hundert Millisekunden). Mit <link rel="…">-Hinweisen im <head> gibst du ihm einen Vorsprung:

preconnect baut die komplette Verbindung zu einem fremden Server schon einmal auf. Nur für die ein, zwei Origins einsetzen, die garantiert sofort gebraucht werden.
dns-prefetch erledigt nur die Namensauflösung – deutlich billiger, gut geeignet für weniger kritische Drittserver.
preload lädt eine konkrete Datei mit hoher Priorität vor, die sonst zu spät entdeckt würde. Pflicht ist das as-Attribut (etwa as="font"), sonst kann der Browser Priorität und Cache nicht korrekt zuordnen; Schriften brauchen zusätzlich crossorigin.
prefetch lädt mit niedriger Priorität etwas für die nächste Navigation – etwa die Seite, die vermutlich gleich angeklickt wird.

Ressourcen-Hints im head

<!-- Verbindung zum Schriften-Server früh aufbauen -->
<link rel="preconnect" href="https://fonts.beispiel-cdn.de" crossorigin>

<!-- Nur DNS auflösen: reicht für Unkritisches -->
<link rel="dns-prefetch" href="https://statistik.beispiel.de">

<!-- Spät entdeckte Schrift mit Vorrang laden – as ist Pflicht! -->
<link rel="preload" href="/schriften/inter.woff2"
      as="font" type="font/woff2" crossorigin>

<!-- Wahrscheinliche nächste Seite schon in den Cache legen -->
<link rel="prefetch" href="/rezepte/sauerteigbrot">

Zeit, alles zusammenzusetzen. Das folgende Dokument zeigt einen sauber sortierten Kopf und ein Bild mit reservierter Fläche – ein Miniatur-Muster für jede Seite, die du künftig baust:

Probier es ausÄndere den Code – die Vorschau aktualisiert sich sofort.

<!doctype html>
<html lang="de">
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <title>Perfekt sortierter Kopf</title>
  <!-- CSS früh: der Browser kann sofort mit dem Rendern planen -->
  <style>
    body { font-family: system-ui, sans-serif; margin: 1.5rem; }
    img  { max-width: 100%; height: auto; background: #dbeafe; }
  </style>
</head>
<body>
  <h1>Reisebericht: Ostsee</h1>
  <!-- width/height reservieren den Platz – selbst wenn das
       Bild (wie hier) gar nicht existiert: nichts springt -->
  <img src="strandkorb.jpg" alt="Strandkorb am Ostseestrand"
       width="400" height="250" loading="lazy">
  <p>Der Text unter dem Bild bleibt an Ort und Stelle.</p>
</body>
</html>

Entferne im Editor testweise width und height beim Bild: Die blaue Fläche verschwindet, und der Text rückt nach oben – im echten Netz wäre genau das der Layout-Sprung, den deine Besucher beim Laden erleben würden.

Serverseite und schlankes HTML

Zwei Stellschrauben liegen streng genommen hinter dem Server-Vorhang, gehören aber zur Allgemeinbildung: Kompression und Minifizierung. Webserver komprimieren Textdateien wie HTML, CSS und JavaScript vor dem Versand mit gzip oder dem moderneren Brotli – das schrumpft sie typischerweise auf ein Viertel bis ein Fünftel und ist meist nur eine Konfigurationszeile. Minifizierung entfernt zusätzlich Kommentare und überflüssige Leerzeichen aus den Dateien; das erledigen Build-Werkzeuge automatisch.

Dein eigener Beitrag ist mindestens so wertvoll: schlankes, valides HTML. Jede Div-Wüste – du erinnerst dich an die Semantik-Lektion – bläht den Dokumentbaum auf, den der Browser aufbauen, im Speicher halten und bei jeder Stiländerung neu durchrechnen muss. Und invalides HTML zwingt den Browser in die Fehlerkorrektur: Er repariert still, aber nicht immer so, wie du es gemeint hast. Die Faustregel des ganzen Kurses gilt deshalb auch hier: Jedes Element muss sich seine Existenz verdienen. Weniger Markup ist schneller geladen, schneller gerendert und – mindestens ebenso wichtig – leichter zu warten.

Zusammenfassung

Der kritische Rendering-Pfad: HTML wird von oben nach unten gelesen, CSS blockiert das Rendern, klassisches JavaScript blockiert das Parsen.
LCP, CLS und INP messen Ladegeschwindigkeit, Layout-Stabilität und Reaktionsfreude – alle drei steuerst du mit HTML mit.
width und height auf Bildern reservieren Platz und verhindern Layout-Springen; fetchpriority="high" adelt das Hero-Bild, loading="lazy" entlastet den Rest.
defer ist der Standard fürs Skript-Laden, async nur für Unabhängiges, type="module" bringt defer-Verhalten mit.
Ressourcen-Hints (preconnect, dns-prefetch, preload mit as, prefetch) gezielt und sparsam einsetzen.
gzip/Brotli und Minifizierung erledigt der Server – schlankes, valides HTML lieferst du.

Checkliste: professionelles HTML

Zum Abschluss beider Kurse: die Essenz aus allen Lektionen, verdichtet zu einer Checkliste, die du vor jedem Livegang durchgehen kannst.

Das Dokument beginnt mit <!doctype html>, das <html>-Element trägt ein lang-Attribut.
Der <head> ist aufgeräumt: charset und viewport zuerst, sprechender <title>, Meta-Description – CSS früh, Skripte mit defer.
Die Seite hat ein Skelett aus Landmarks: header, nav, genau ein main, footer.
Die Überschriften bilden eine lückenlose Hierarchie mit genau einer <h1>.
Semantik vor Optik: Elemente sagen, was Inhalte sind – <div> nur als ehrlicher Technik-Container.
Jedes Bild hat ein sinnvolles alt, dazu width und height; unterhalb des sichtbaren Bereichs zusätzlich loading="lazy".
Links sind sprechend beschriftet (nie „hier klicken“), jedes Formularfeld hat ein <label>.
Eingebettetes ist gezähmt: iframes mit title und sandbox, Drittanbieter-Embeds hinter einer Zwei-Klick-Lösung.
Inhalte, die Rich Results verdienen, sind als JSON-LD ausgezeichnet – und zwar nur das, was sichtbar auf der Seite steht.
Das HTML ist valide und frei von Div-Wüsten – der Validator gehört zum Abschluss jedes Projekts.
Vor dem Livegang: mobil getestet, komplett mit der Tastatur bedient und die Core Web Vitals im Blick.

Geschafft – und zwar wirklich. Mit dieser Lektion hast du nicht nur den Fortgeschrittenen-Kurs, sondern beide Kurse abgeschlossen: vom allerersten <p> bis zu Ressourcen-Hints und strukturierten Daten. Du schreibst jetzt HTML, das semantisch, barrierefrei, maschinenlesbar und schnell ist – mehr, als so mancher Profi von sich behaupten kann. Und wie geht es weiter? Bau etwas Eigenes: Im Playground kannst du frei experimentieren und deine ersten eigenen Projekte umsetzen, und der Spickzettel steht bereit, wann immer dir ein Attribut entfallen ist. Danke, dass du bis hierhin dabei warst – und jetzt: Bau das Web ein Stückchen besser.

Zur Kursübersicht →