Ressourcen-Hinweise: preload und preconnect.

Ressourcen-Hinweise sind Anweisungen, die dem Browser vorab mitteilen, welche Ressourcen früh gebraucht werden oder mit welchen Servern er sich verbinden wird.

Beim Laden einer Seite fordert der Browser die Ressourcen in der Reihenfolge ihrer Entdeckung an, und die Entdeckung schreitet mit dem Parsen des Dokuments voran. Manche Ressourcen werden weit hinten in dieser Kette entdeckt — eine in einer Stildatei referenzierte Schrift ist erst bekannt, nachdem die Stildatei geladen und geparst wurde. Ressourcen-Hinweise existieren, um diese Verzögerung zu verkürzen.

Aber jeder Hinweis ist ein Prioritätsanspruch, und Priorität ist ein relativer Begriff. Allem Priorität zu geben liefert dasselbe Ergebnis wie nichts zu priorisieren — und die wirklich kritische Ressource beginnt, mit den anderen um Bandbreite zu konkurrieren.

Vier Hinweise, vier verschiedene Aufgaben

1. Preconnect — die Verbindung zum genannten Server wird vorab aufgebaut. Namensauflösung, Handschlag und Sicherheitsaushandlung sind im Voraus erledigt.
2. DNS-Prefetch — nur die Auflösung geschieht, keine Verbindung. Billiger, aber weniger Gewinn.
3. Preload — die genannte Ressource lädt mit hoher Priorität, wird aber nicht sofort ausgeführt. Schließt die Entdeckungsverzögerung.
4. Prefetch — eine Ressource, die der Nutzer auf der NÄCHSTEN Seite braucht, lädt im Leerlauf. Ein anderer Zweck: Navigationstempo.

Die ersten beiden gelten den Verbindungskosten und ergeben nur für externe Domains Sinn. Die Verbindung zum eigenen Server steht ohnehin; sich mit ihm vorab zu verbinden gewinnt nichts. Das ist der häufigste unnötige Hinweis.

Der dritte ist der stärkste und der gefährlichste. Auf die richtige Ressource angewandt senkt er LCP messbar; auf die falsche oder auf zu viele angewandt verlangsamt er die wirklich kritische.

Wie viele, und welche

Die praktische Regel: Die Zahl der auf einer Seite vorzuladenden Ressourcen ist meist eins oder zwei. Die Kandidaten sind bekannt — das LCP-Bild, oder die kritische Schrift, wenn Text das LCP-Element ist.

Auf dieser Website werden die Schriften von der eigenen Domain ausgeliefert, ein externer Verbindungshinweis ist also unnötig; die Content-Security-Policy blockiert externe Ressourcenanfragen ohnehin. Die Liste der Hinweise ist deshalb kurz, und jeder Posten hat eine Begründung.

Und eine Messregel: Nach dem Hinzufügen eines Hinweises MUSS seine Wirkung gemessen werden. Hinweise wirken intuitiv richtig, und die Intuition irrt hier oft — ein Preload kann LCP erhöhen statt senken, weil er eine andere Ressource verzögert hat. Ein ohne Vorher-Nachher-Messung ergänzter Hinweis bleibt eine Vermutung.

Ein Ressourcen-Hinweis wird nicht nach Intuition gesetzt; das Vorher und das Nachher werden gemessen.

Die Prioritätsangabe

Ein neueres Werkzeug erlaubt, die Priorität einer Ressource direkt anzugeben: Einem Bild lässt sich hohe Priorität geben, einem Skript die Priorität senken. Das ist ein leichterer Eingriff als der Preload-Hinweis, denn er erzeugt keine zusätzliche Anfrage — er ändert nur die Reihenfolge.

Die häufigste Verwendung ist das Hero-Bild: Mit hoher Priorität am Bildelement lädt der Browser es vor den anderen Bildern, und LCP verkürzt sich. Es geht auch andersherum — die Priorität eines Bildes außerhalb des sichtbaren Bereichs wird gesenkt, und die Bandbreite bleibt den kritischen Ressourcen.

Auf dieser Website werden die Hero-Bilder mit hoher Priorität und ohne Lazy Loading ausgeliefert; die Vitrinenbilder lazy und mit normaler Priorität. Die Unterscheidung beruht auf der Messung, welches Element das LCP-Element ist — nicht auf einer Vermutung.

Prefetch und Navigation

Der vierte Hinweis dient einem anderen Zweck als die übrigen: Er beschleunigt nicht die aktuelle Seite, er bereitet die NÄCHSTE vor. Die Ressourcen der Seite, die der Nutzer höchstwahrscheinlich besucht, laden mit niedriger Priorität, während der Browser leer läuft.

Richtig verwendet ist die Wirkung frappierend: Klickt der Nutzer den Link, kommt die Seite fast sofort, denn sie ist schon geladen. Falsch verwendet ist es reine Verschwendung — Bandbreite für Seiten, die der Nutzer nie besucht.

Es gibt einige Wege zu entscheiden, welche Seite vorzuladen ist. Der einfachste ist eine feste Liste: die zwei von der Startseite meistbesuchten Seiten. Klüger ist das Laden, wenn der Nutzer über einem Link schwebt oder auf ihn zuscrollt — das Warten auf ein Absichtssignal.

Eine gemessene Warnung: Für mobile Nutzer kann Prefetch auf gedeckelten Datentarifen echte Kosten erzeugen. Browser melden die Datensparpräferenz, und ist sie an, darf kein Prefetch geschehen — das ist Respekt vor einem ausdrücklich geäußerten Wunsch des Nutzers.

Prüfung und Aufräumen

Ressourcen-Hinweise sammeln sich mit der Zeit an, und niemand räumt sie auf. Ein Anbieter wird gewechselt, aber der Verbindungshinweis zu ihm bleibt; ein Bild wird erneuert, aber seine alte Adresse wird weiter vorgeladen. Das Ergebnis: Anfragen, die nichts leisten und doch Bandbreite verbrauchen.

Die Browserkonsole warnt in dieser Lage: Für eine vorgeladene, aber unbenutzte Ressource erscheint eine klare Meldung. Diese Warnung nicht zu ignorieren ist der leichteste Weg zur Sauberkeit.

1. Ein unbenutzter Preload — die Konsole warnt; er muss entfernt werden.
2. Ein Preconnect zur eigenen Domain — unnötig; die Verbindung steht ohnehin.
3. Zu viele Preloads — die Priorität verliert ihre Bedeutung; nicht über zwei.
4. Ein Preconnect zu einem alten Anbieter — wechselte der Anbieter, muss auch der Hinweis wechseln.
5. Die Datensparpräferenz — ist sie an, kein Prefetch.

Diese Liste kann und sollte zum Prüfschritt werden: Die Hinweise der Seite werden extrahiert, jeder nach seiner Begründung gefragt, und die ohne werden entfernt. Einmal im Jahr gemacht, schließt dieses Aufräumen auf den meisten Websites einige unnötige Anfragen.

Zum Abschluss eine Prioritätsnotiz: Ressourcen-Hinweise sind der letzte Schritt der Performance-Arbeit, nicht der erste. Eine große Skriptlast oder ein unoptimiertes Hero-Bild lässt sich mit Hinweisen nicht ausgleichen — der Hinweis ändert nur die Entdeckungsreihenfolge, nicht die eigenen Kosten der Ressource. Zuerst wird die Ressource verkleinert, dann ihre Reihenfolge justiert.

Eine praktische Checkliste

Übersetzt man diese Seite in einen Prüfschritt, ist an den Ressourcen-Hinweisen Folgendes zu prüfen. Die Liste bleibt kurz, denn lange Listen werden nicht abgeschritten; sechs Punkte passen in eine Sitzung.

1. Wie viele Preloads gibt es — mehr als zwei ist zu viel.
2. Was ist die Begründung jedes einzelnen — die ohne werden entfernt.
3. Warnt die Konsole — ein unbenutzter Preload erzeugt eine Warnung.
4. Gibt es einen Preconnect zur eigenen Domain — unnötig.
5. Zeigt noch ein Hinweis auf einen alten Anbieter?
6. Wird die Datensparpräferenz beachtet?

Diese Liste sollte einmal im Jahr abgeschritten werden. Hinweise sammeln sich an, und niemand räumt sie auf; das Ergebnis sind Anfragen, die nichts leisten und doch Bandbreite verbrauchen.