Zusammenfassung

  • Der W3C-Entwurf Resource Priorities von 2013 schlug unter anderem lazyload und postpone für Hinweise zur Downloadreihenfolge vor. Eine Arbeitsgruppennotiz von 2014 erklärte die Spezifikation ausdrücklich für aufgegeben.
  • Der spätere WICG-Bericht Priority Hints wurde aus einem anderen Grund obsolet: Seine relevanten Teile gingen in HTML und Fetch auf. Das heutige fetchpriority unterscheidet high, low und auto gegenüber Ressourcen mit demselben Zieltyp; Fetch führt zusätzlich eine interne Browserpriorität.

Das Aufmacherbild erklärt die Geschichte. Eine Ziergrafik im Fußbereich kann warten. Im HTML kann sie trotzdem früher stehen. Der Browser verarbeitet diese Dateiwünsche bei begrenzter Verbindung und auf einem begrenzten Gerät. Er kennt die Netzlage. Die Redaktion kennt den Sinn der Bilder. Prioritätshinweise verbinden beide Kenntnisse.

Der erste öffentliche W3C-Arbeitsentwurf vom 29. Oktober 2013 nannte sich Resource Priorities. Er beschrieb lazyload, postpone und eine CSS-Eigenschaft als Wege, die Downloadpriorität anzudeuten. Bei lazyload ging es um geringere Dringlichkeit unter Konkurrenz; postpone betraf ein Aufschieben, bis sich ein Element dem sichtbaren Bereich näherte. Die Einleitung bezweifelte, dass die Dokumentreihenfolge immer die wahrgenommene Ladeleistung begünstigt. Der Text belegt einen Vorschlag, keine allgemeine Einführung in damaligen Browsern.

Die W3C-Arbeitsgruppennotiz vom 23. Oktober 2014 machte mit dem Vorschlag Schluss. Sie bezeichnete die Spezifikation als aufgegeben, kündigte das Ende der Pflege an und verwies auf Resource Hints. lazyload stand noch im Dokument, der frühere Abschnitt zu postpone nicht mehr. Wer daraus eine direkte Ahnenreihe zum gegenwärtigen fetchpriority zeichnet, überspringt eine Lücke in den Quellen. Gleiche Frage, verschiedene Dokumente und technische Verträge.

Eine zweite Akte führt zu Priority Hints, dem WICG-Bericht vom 22. Februar 2023. Entwickler sollten damit eine relative Priorität für die Berücksichtigung durch den Browser melden. Auch dieser Bericht trägt inzwischen das Etikett „obsolet“. Hier wurde die relevante Materie jedoch in HTML und Fetch übernommen. Ein Dokument starb, weil das Vorhaben aufgegeben wurde; das andere verlor seine Rolle, weil der Inhalt ein neues Zuhause erhielt. Der Aufkleber ist gleich, die Geschichte dahinter nicht.

Im aktuellen HTML Living Standard hat fetchpriority die Werte high, low und auto. Sie gelten relativ zu anderen Ressourcen mit demselben Zieltyp. Fehlende und ungültige Angaben ergeben auto. Gerade diese Begrenzung ist wichtig: Ein high macht aus keiner Datei einen absoluten König aller Downloads. Der Autor kann unter vergleichbaren Anfragen unterscheiden, etwa zwischen Titelbild und Schmuckgrafik.

Der Fetch Living Standard trennt zudem die Priorität einer Anfrage von ihrer internen Priorität. Erstere lautet high, low oder auto; Letztere kann als implementierungsabhängiges Objekt geführt werden. Das ist mehr als ein technisches Detail. Der Browser behält eigene Mittel, um mit Auslastung, Konkurrenz und Gerätezustand umzugehen. Der Vermerk der Seite wird gehört, aber er ersetzt die Arbeitsliste nicht.

Die fünf Originaldokumente zeigen, wie aus einer Frage zwei verschiedene Dokumentengeschichten wurden. Die Seite kann sagen, welches Bild sie zuerst braucht. Der Browser muss zugleich die ganze Verbindung im Blick behalten. Ruft jede Grafik „Eilig!“, geht die hilfreiche Unterscheidung verloren. Dann steht der Browser wieder vor einer Schlange voller gleich lauter Stimmen.