Zusammenfassung

  • Der erste öffentliche W3C-Entwurf zu Resource Hints vom Oktober 2014 beschrieb preconnect für eine bekannte Origin, bevor die vollständige Ressourcen-URL feststand. DNS-Abfrage, TCP-Handshake und gegebenenfalls TLS-Aushandlung konnten früher beginnen.
  • Spätere Entwürfe trennten dns-prefetch, preconnect, prefetch und prerender. Der Browser durfte vollständig verbinden, nur Vorarbeiten erledigen oder den Hinweis aus Rücksicht auf seine Ressourcen verwerfen.

Eine Bildergalerie kennt ihren Bildserver. Welches Bild der Besucher als Nächstes sehen möchte, weiß sie noch nicht. Auf Verdacht alle Bilder zu laden wäre ein ziemlich großzügiges Missverständnis von Gastfreundschaft. Die Verbindung zum bekannten Server vorzubereiten ist ein kleinerer Schritt. Genau die Zeit zwischen bekannter Herkunft und unbekannter Datei wollte preconnect nutzbar machen.

Im ersten öffentlichen W3C-Entwurf vom 21. Oktober 2014 war der Hinweis eine Möglichkeit für Seitenautoren oder Server, dem User Agent frühzeitig eine Origin zu nennen. Der Text zählt DNS-Auflösung, TCP-Handshake und optionale TLS-Aushandlung auf. Daneben stand in dieser frühen Fassung preload, das sich auf eine bestimmte Ressource bezog. Der Tisch lässt sich reservieren, bevor die Bestellung eingeht; das Essen steht deshalb noch nicht auf dem Tisch.

Der Entwurf vom 4. Mai 2017 unterschied vier Link-Beziehungen. dns-prefetch bittet um frühe Namensauflösung. preconnect kann die Verbindung zur Herkunft vorbereiten. prefetch holt vielleicht benötigte Ressourcen für eine spätere Navigation. prerender kann ein künftiges Dokument weiterverarbeiten. Wer diese Formen unter „vorab laden“ zusammenfasst, übersieht die entscheidende Grenze zwischen einem bekannten Ort und einer geratenen Datei.

Der W3C-Entwurf vom 27. Juni 2019 schildert einen Fall mit dynamischer URL. Die Seite kennt die Herkunft, bevor der Aufbau der Seite die genaue Ressourcenadresse bestimmt. Beginnt der Verbindungsaufbau schon in dieser Lücke, kann die spätere Anfrage ohne denselben Startaufwand losgehen. Die Anwendung hat dem Browser keine Zukunft verraten, sondern einen früher verfügbaren Teil der Gegenwart.

Ob er den Hinweis nutzt, bleibt Sache des Browsers. Der Entwurf vom 5. Oktober 2020 erlaubt einen vollständigen, einen teilweisen oder gar keinen Verbindungsaufbau. Auch die Zahl der Verbindungen pro Origin legt der User Agent fest. Netzlage, Gerätekapazität, Protokoll und allgemeine Grenzen bestimmen, wie viel Vorbereitung vernünftig ist. Ein Zettel vom Webseitenautor ist keine Reservierungsbestätigung für das ganze Lokal.

Frühe Verbindungen können ins Leere laufen. Dann haben sie Netzwerk- und Geräteleistung verbraucht, ohne eine spätere Datei schneller zu liefern. Zu viele gleichzeitig vorgeschlagene Ursprünge konkurrieren mit dem, was die aktuelle Seite tatsächlich laden muss. Der Text von 2020 bestimmt außerdem, dass ausstehende preconnect-Arbeit das Ladeereignis des Dokuments nicht verzögern darf. Der erwartete Gast soll nicht wichtiger sein als der Besucher, der schon da ist.

Die W3C-Veröffentlichungsgeschichte beginnt für Resource Hints mit dem öffentlichen Entwurf von Oktober 2014 und führt durch spätere Arbeitsentwürfe. Aus der anfänglichen Gegenüberstellung von preconnect und preload wurde eine Familie mit klarer verteilten Aufgaben. Das waren Entwürfe. Die praktische Einsicht dahinter war schlicht: Manchmal kennt die Seite den Gesprächspartner vor dem Gesprächsgegenstand. Der Browser darf dann entscheiden, ob ein frühes Hallo Zeit spart.