Resource Hints prüfen (preload / preconnect)
Mit Resource Hints sagen Sie dem Browser: \"Das frage ich gleich an, fang schon mal an.\" Richtig gesetzt beschleunigen sie den ersten Bildaufbau spürbar; falsch gesetzt richten sie stillen Schaden an, weil Ressourcen doppelt geladen werden, Verbindungen ohne Grund aufgehen und kritische Dateien dahinter anstehen. Dieses Werkzeug zählt die preload-, preconnect-, dns-prefetch- und prefetch-Tags Ihrer Seite nicht nur; es prüft, ob jedes richtig konfiguriert ist und ob ihm eine Ressource entspricht, die die Seite tatsächlich lädt.
Was tut jeder Hinweis eigentlich?
Die vier sehen sich ähnlich, tun aber Verschiedenes. preload lädt in hoher Priorität eine bestimmte Datei, die auf DIESER Seite gebraucht wird. prefetch lädt in niedriger Priorität eine Datei für eine KÜNFTIGE Seite, während der Browser gerade nichts zu tun hat. preconnect baut vorab die TCP-Verbindung und die TLS-Aushandlung zu einem Ursprung auf und zahlt die Verbindungskosten im Voraus, noch bevor feststeht, welche Datei angefragt wird. dns-prefetch löst lediglich den Domainnamen auf, ohne eine Verbindung aufzubauen; es ist der leichte Verwandte von preconnect. Der übliche Fehler ist, sie austauschbar zu verwenden: Eine Ressource für eine künftige Seite vorzuladen verbraucht jetzt Bandbreite, und die kritische Schrift dieser Seite per prefetch zu holen kommt zu spät.
Warum ist das as-Attribut unverzichtbar?
Das as-Attribut an einem preload-Tag sagt dem Browser, welcher Art die Anfrage ist: script, style, font oder image. Diese Angabe wird nicht nur für die Priorisierung gebraucht, sondern für die ZUORDNUNG. Ohne as lädt der Browser die Datei zwar, kann sie aber, wenn die Seite sie in ihrem echten Zusammenhang anfragt (etwa aus dem CSS oder einem script-Tag), nicht mit dem bereits Geladenen verbinden und lädt sie ein zweites Mal. Ein Tag, das die Seite schneller machen sollte, verdoppelt am Ende die Bandbreite. Chrome meldet das in der Konsole als Warnung, die meist unbemerkt bleibt.
crossorigin bei Schriften: der teuerste stille Fehler
Schriftanfragen unterliegen den CORS-Regeln, selbst wenn die Datei von derselben Domain kommt, das heißt der Browser fragt die Schrift im \"anonymen\" Modus an. Fehlt Ihrem preload-Tag das crossorigin-Attribut, findet das Vorladen im normalen Modus statt und passt nicht zu der echten Schriftanfrage, die das CSS auslöst. Die Schrift wird zweimal geladen: einmal umsonst, einmal wirklich. Schlimmer noch, der erste Ladevorgang verbraucht Bandbreite und kann die echte Anfrage verzögern, sodass ein hinzugefügtes Schrift-preload die Seite langsamer macht als gar keines. Richtig ist, das crossorigin-Attribut ganz ohne Wert zu setzen; Sie müssen keinen schreiben.
Warum schadet ein ungenutztes preconnect?
Jedes preconnect stößt drei Arbeiten an: die DNS-Auflösung, einen TCP-Handschlag und bei HTTPS eine TLS-Aushandlung. Lädt die Seite von diesem Ursprung tatsächlich etwas, sind die Kosten vorab bezahlt und werden zum Gewinn. Tut sie es nicht, ist es reine Verschwendung: Die Verbindung geht auf, liegt eine Weile brach und schließt wieder. Hinzu kommt, dass die Zahl gleichzeitiger Verbindungen begrenzt ist, sodass grundlos geöffnete Verbindungen mit Ihren kritischen Ressourcen konkurrieren. Dieses Werkzeug vergleicht die Ursprünge, zu denen Sie preconnect setzen, mit den Skripten, Stilen und Bildern, die die Seite wirklich lädt, und meldet jene, hinter denen nichts steht. In der Praxis werden diese Hinweise einmal gesetzt und jahrelang vergessen, sodass beim Wechsel eines Drittanbieters tote preconnects zurückbleiben.
Maß halten: wenige und gezielt
\"Mehr ist besser\" gilt bei Resource Hints nicht. Mehr als vier preconnects belasten den Verbindungsvorrat; mehr als zehn preloads zerstören den Sinn der Priorisierung, denn wenn alles Vorrang hat, hat nichts Vorrang. Ein gesundes Setup sieht meist so aus: ein crossorigin-preload für die ein oder zwei im ersten Bildaufbau sichtbaren Schriften, ein preload für kritisches CSS und preconnects für die zwei oder drei wirklich genutzten Drittanbieter-Ursprünge. Alles darüber hinaus, ohne Messung hinzugefügt, richtet höchstwahrscheinlich Schaden an.
Ihre Fragen
Häufig gestellte Fragen
Worin unterscheiden sich preload und prefetch?
preload lädt eine auf dieser Seite genutzte Ressource sofort und mit hoher Priorität. prefetch lädt eine Ressource für eine Seite, die die Nutzerin wahrscheinlich als Nächstes besucht, mit niedriger Priorität, während der Browser gerade nichts zu tun hat. Die kritische Ressource dieser Seite per prefetch zu holen kommt zu spät; die Ressource einer künftigen Seite per preload zu holen verbraucht jetzt Bandbreite.
Was passiert, wenn ich bei einem Schrift-preload crossorigin weglasse?
Die Schrift wird zweimal geladen. Schriftanfragen unterliegen auch vom selben Ursprung dem CORS-Modus, also passt ein ohne crossorigin gesetztes preload nicht zu der echten Anfrage, die das CSS auslöst. Unterm Strich macht das hinzugefügte preload die Seite langsamer statt schneller.
Wie viele preconnects sollte ich verwenden?
Mehr als vier sind im Allgemeinen nicht zu empfehlen, und sie sollten nur zu Drittanbieter-Ursprüngen gehen, die im ersten Bildaufbau wirklich genutzt werden. Jedes preconnect verbraucht Verbindungsressourcen, und jene, hinter denen nichts steht, konkurrieren mit Ihren kritischen Anfragen.
Soll ich preconnect und dns-prefetch beide schreiben?
Nein. preconnect schließt die DNS-Auflösung bereits ein, beides für denselben Ursprung zu schreiben ist also überflüssig. Die Gewohnheit, dns-prefetch als Rückfallebene für preconnect zu setzen, stammt aus der Sorge um sehr alte Browser; heute gibt es dafür keinen praktischen Grund.
Ich verwende gar keine Resource Hints. Ist das ein Problem?
Nein. Resource Hints sind freiwillige Optimierungen, und ein falsch gesetzter Hinweis ist schlechter als keiner. Hält eine Schrift oder eine Drittanbieter-Ressource Ihren ersten Bildaufbau unmittelbar auf, bringt ein gezielter Hinweis einen messbaren Gewinn; wenn nicht, ist es richtig, sie wegzulassen.
Misst dieses Werkzeug, ob die Hinweise wirklich helfen?
Es misst, ob sie richtig konfiguriert sind und ob ihnen Ressourcen entsprechen, die die Seite lädt; so findet es Verschwendung und doppelte Ladevorgänge. Den Gewinn in Millisekunden zu messen verlangt einen echten Ladevorgang im Browser; nutzen Sie dafür den Labortest in unserem PageSpeed-Portal.