Preconnect und Preload

Zwei Lighthouse-Befunde drehen sich darum, dem Browser früher zu sagen, was er brauchen wird: Vorab mit erforderlichen Ursprüngen verbinden und Wichtige Anfragen vorab laden. Beides sind Ressourcen-Hinweise, kleine Tags im Kopf des HTML, mit denen der Browser Arbeit beginnt, bevor er den Bedarf selbst entdecken würde. Richtig eingesetzt sparen sie beim Largest Contentful Paint und beim Rendern der Schriften mehrere hundert Millisekunden. Unbedacht eingesetzt konkurrieren sie mit den Ressourcen, auf die es ankommt, und machen die Seite langsamer. Dieser Ratgeber erklärt, was jeder Hinweis tut, wann er hilft und welche Fehler einen Hinweis in Kosten verwandeln.

Preconnect: die Verbindung vor der Anfrage öffnen

Jede Anfrage an einen neuen Ursprung bezahlt eine DNS-Auflösung, einen TCP-Handshake und eine TLS-Aushandlung, bevor das erste Byte Inhalt fließt. Auf einer Mobilfunkverbindung kostet allein dieser Aufbau mehrere hundert Millisekunden. rel="preconnect" weist den Browser an, diesen Aufbau sofort und parallel zum Parsen des HTML zu erledigen, damit die erste echte Anfrage an diesen Ursprung eine warme Verbindung vorfindet:

<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
<link rel="preconnect" href="https://cdn.example-images.com">

Das Attribut crossorigin ist entscheidend: Schriften und fetch()-Anfragen laufen über CORS und brauchen eine andere Verbindung als Bild- oder Skriptanfragen. Ein Preconnect ohne crossorigin bringt für eine Schriftdatei nichts, und umgekehrt.

Lighthouse listet Ursprünge, bei denen eine frühere Verbindung Zeit gespart hätte, gemessen daran, wie spät die erste Anfrage an diesen Ursprung startete. Gute Kandidaten sind die ein bis zwei Ursprünge, die Ressourcen für den ersten Seitenaufbau liefern: ein separates Bild-CDN, ein Schriftdienst oder eine API, die die Seite vor dem Rendern braucht. Analyse- und Chat-Widgets von Drittanbietern sind keine Kandidaten; die sollen spät laden, nicht früh.

Halten Sie die Liste kurz. Jeder Preconnect öffnet eine Verbindung, die auf dem Gerät Rechenzeit und Speicher kostet, und eine Verbindung, die die Seite nicht binnen weniger Sekunden nutzt, wird wieder geschlossen und war umsonst. Mehr als eine Handvoll Preconnects zeigt, dass die Seite von zu vielen Ursprüngen abhängt, ein Problem, das Ressourcen-Hinweise nicht lösen.

rel="dns-prefetch" ist der leichtere Verwandte: Er löst nur den Hostnamen auf. Für Ursprünge, die erst später auf der Seite gebraucht werden, ist das ein vernünftiger Rückfall, und er kostet fast nichts.

Preload: eine spät entdeckte Ressource früh laden

Die meisten Ressourcen entdeckt der Browser beim Parsen des HTML. Manche sieht er erst viel später: eine Schrift, die in einer CSS-Datei referenziert wird, ein Hero-Bild als background-image im CSS oder ein Skript, das ein anderes Skript nachlädt. rel="preload" holt sie an den Anfang der Warteschlange:

<link rel="preload" href="/fonts/inter-var.woff2" as="font" type="font/woff2" crossorigin>
<link rel="preload" href="/img/hero.avif" as="image" fetchpriority="high">

Das Attribut as ist Pflicht; ohne es kann der Browser keine passende Priorität vergeben und lädt die Datei womöglich zweimal. Lighthouse meldet Wichtige Anfragen vorab laden für Ressourcen, die tief in der Anfragekette sitzen und den kritischen Pfad verzögern.

Preload ist ein scharfes Werkzeug. Jede vorab geladene Datei konkurriert in den ersten Sekunden mit HTML, CSS und dem LCP-Bild um Bandbreite. Fünf Schriften und drei Skripte vorab zu laden macht nicht alle schnell, es macht das LCP-Bild langsam. Die richtige Zahl liegt auf den meisten Seiten zwischen null und drei: das LCP-Bild, wenn CSS oder JavaScript es vor dem Parser verstecken, und ein bis zwei Schriften, die im sichtbaren Bereich verwendet werden.

fetchpriority: die einfachere Lösung für das LCP-Bild

Ist das LCP-Bild ein normales <img> im HTML, braucht es keinen Preload. Der Parser findet es; das einzige Problem ist, dass der Browser Bildern eine niedrige Priorität gibt, bis er weiß, dass sie sichtbar sind. Genau das behebt fetchpriority="high":

<img src="/img/hero.avif" width="1200" height="600" alt="..." fetchpriority="high">

Nutzen Sie Preload für das LCP-Bild nur, wenn es ein CSS-Hintergrund ist oder per JavaScript eingefügt wird. Für alles unterhalb des sichtbaren Bereichs gilt das Gegenteil: verzögert laden.

Ressourcen-Hinweise Schritt für Schritt

1. Kritische Ursprünge und Dateien finden. Sortieren Sie im Netzwerk-Panel der Chrome DevTools nach Startzeit und prüfen Sie, wovon der erste Paint und das LCP-Element abhängen. Lighthouse nennt die Kandidaten in beiden Befunden.
2. Höchstens zwei Preconnects für Ursprünge mit renderkritischen Ressourcen, mit crossorigin, wo Schriften oder CORS-Anfragen beteiligt sind.
3. Das LCP-Bild markieren mit fetchpriority="high", oder per Preload, wenn der Parser es nicht sehen kann.
4. Die ein bis zwei Schriften des ersten Bildschirms vorab laden, und nur diese. Kombinieren Sie das mit font-display, damit Text schon während des Ladens erscheint.
5. Erneut messen und die LCP-Aufschlüsselung vergleichen. Ein hilfreicher Preload verkürzt die Ladeverzögerung des LCP-Elements. Wird der LCP schlechter, entfernen Sie den zuletzt gesetzten Hinweis.
6. Hinweise entfernen, wenn sich die Ressourcen ändern. Ein Preload für eine Schrift, die die Seite nicht mehr nutzt, ist reiner Aufwand; Audits bemerken das selten, weil die Datei weiterhin problemlos lädt.

Hinweise je Plattform

• WordPress: Caching- und Optimierungs-Plugins setzen Preconnects für Google Fonts und Preloads für Schriften. Prüfen Sie, dass sie nicht zusätzlich jedes Stylesheet vorab laden, ein verbreiteter Standard, der dem LCP schadet. Selbst gehostete Schriften machen den Preconnect zu Google Fonts überflüssig.
• Shopify: Das Theme bestimmt den Kopf der Seite. Themes aus dem Shopify Theme Store laden die Hauptschrift bereits vorab und priorisieren das Hero-Bild; Apps mit eigenen Schriften und Skripten sind die übliche Quelle unnötiger Ursprünge.
• Next.js: next/image mit priority kümmert sich um das LCP-Bild, next/font hostet Schriften selbst und lädt sie vorab. Manuelle Preload-Tags sind selten nötig und verdoppeln oft, was das Framework schon tut.

Häufige Fragen

Soll ich einen Preconnect zu Google Fonts setzen?

Wenn Sie Google Fonts laden, ja: zu fonts.gstatic.com mit crossorigin, denn dort liegen die Schriftdateien, das CSS von fonts.googleapis.com verweist nur darauf. Die schnellere Lösung ist Self-Hosting, das beide Ursprünge überflüssig macht.

Können zu viele Preloads schaden?

Ja. Preloads konkurrieren in den ersten Sekunden mit den kritischen Ressourcen um Bandbreite. Beschränken Sie sie auf das LCP-Bild, falls nötig, und ein bis zwei Schriften im sichtbaren Bereich.

Was ist der Unterschied zwischen preload und prefetch?

Preload holt eine Ressource für die aktuelle Seite mit hoher Priorität. Prefetch holt eine Ressource für eine wahrscheinliche nächste Seite mit niedriger Priorität, sobald die aktuelle Seite im Leerlauf ist. Nutzen Sie prefetch nie für etwas, das die aktuelle Seite braucht.

Warum warnt Chrome, dass eine vorab geladene Ressource nicht verwendet wurde?

Entweder passt das Attribut as oder crossorigin nicht zur echten Anfrage, sodass der Browser die Datei zweimal geladen hat, oder die Ressource wird in den ersten Sekunden gar nicht gebraucht. Korrigieren Sie die Attribute oder entfernen Sie den Preload.