prefetch & preconnect zeitgemäß?

[supervisior]

@ Hanzo2012

Jetzt hast Du Dir so viel Mühe gemacht alles zu beschreiben, aber durch partielle Fehlinformationen machst Du Dein gesamtes Statement dazu fast falsch. Ginge es hier ausschließlich nur um Header Bidding, könnte man es fast so stehen lassen, aber durch die Kombination mit dem Preconnect, kann man Dein Statement so nicht stehen lassen. Da sind ein paar gravierende Fehler drin.

Zunächst mal das Wichtigste voran zum Thema Preconnect. Wie der Name selbst schon beinhaltet, geht es dabei um eine Vorkontaktierung, allerdings nicht in Form eines vollständigen Requests und auch nicht zum Ziel Host. Was Du angibst, übersteigt bei weitem das Prinzip eines Preconnects, der sich letztlich auf den Handshake reduziert, bzw. dort endet. Eine eigentliche Verbindung im Sinne eines vollständigen Requests zum Host wird dabei noch gar nicht aufgebaut.

siehe auch: https://docs.google.com/presentation/d/ ... 3305a_0106

Anders als Du es darstellst, ist an meiner vorherigen Aussage, dass mit dem Preconnect lediglich Netz(werk)informationen abgefragt werden, nichts falsches daran. Gleichermaßen gilt das für das Cachen dieser Informationen. Dementsprechend ist es der besagte Quatsch diese Informationen bei jedem Seitenaufruf immer und immer wieder abzufragen.

Vor dem Hintergrund, dass mit den vom Themenstarter aufgeführten Code Beispielen nur der Host von Yieldlove preconnected wird, aber eben nicht die Server mit denen der Anzeigendeal ausgehandelt wird, macht den Versuch mit dem Preconnect etwas zu Gunsten des Header Bidding Vorgangs zu beschleunigen sinnfrei. Vor dieser Tatsache bestand also kein Bedarf mich korrigieren zu müssen.

Damit das mit dem Preconnect nicht fälschlicherweise als Ganzes falsch verstanden wird, hat dieses Preconnect natürlich seine Daseinsberechtigung, aber in nur unbedeutender Weise, wie im konkreten Fall zum Zwecke, um die Bereitstellung der Anzeigen über das Header Bidding zu verbessern.

Ein Beispiel für einen sinnigen Einsatz von Preconnect wäre, wenn man diese Funktion dazu nutzt, um von extern eingebundene Schriftarten von Google Fonts, bzw. den Ladevorgang zu beschleunigen, wobei ich dann gleich prefetch verwenden würde. Allerdings auch nur dann, wenn die Schriftarten im HTML Header definiert sind und eben nicht wie so oft und viel zu spät in den css Dateien.

[Hanzo2012]

Sorry, Herr Lehrer, aber das kann ich wiederum nicht so stehen lassen.

Zunächst mal das Wichtigste voran zum Thema Preconnect. Wie der Name selbst schon beinhaltet, geht es dabei um eine Vorkontaktierung, allerdings nicht in Form eines vollständigen Requests

1.) Zum Namen: Das Teil heißt „Preconnect“, weil die Verbindung zum Host schonmal im Voraus aufgebaut werden soll, um spätere Requests an diesen Host zu beschleunigen.

2.) Von einem „vollständigen Request“ habe ich nicht gesprochen. Ein vollständiger Request kann es ja auch gar nicht sein, denn dazu müsste man bereits eine spezifische Ressource/URL abfragen. Das wäre dann Prefetch.

und auch nicht zum Ziel Host.

Doch, genau das! Natürlich zum angegeben Ziel-Host. Wohin denn sonst, etwa zum Mond?

Was Du angibst, übersteigt bei weitem das Prinzip eines Preconnects, der sich letztlich auf den Handshake reduziert, bzw. dort endet. Eine eigentliche Verbindung im Sinne eines vollständigen Requests zum Host wird dabei noch gar nicht aufgebaut.

Sorry, das ist auf mehreren Ebenen falsch!

1.) Du vermischst die Begriffe Verbindung und Request. Ein Request erfolgt über eine Verbindung. Diese Netzwerkverbindung zum angegeben Ziel-Server wird mit Preconnect bereits vorher aufgebaut, bevor der Browser überhaupt wissen kann, dass er eine Anfrage an diesen Server schicken muss. Über diese Verbindung, die offen gehalten wird, kann der Browser später HTTP-Requests abschicken, und sich das zeitraubende Aufbauen einer neuen Verbindung sparen, weil ja bereits eine geöffnet ist. Genau das ist doch der Sinn der Sache.

2.) Der Aufbau einer Verbindung ist viel mehr als nur ein „Handshake“ (was auch immer du damit meinst, denn hier findet sowohl ein TCP- als auch ein TLS-Handshake statt):

- Zuerst muss die IP-Adresse des Ziel-Hosts ermittelt werden (entweder ist sie schon bekannt, oder sie muss über den Nameserver abgefragt werden).
- Dann muss eine TCP-Verbindung aufgebaut werden, wobei ein Three-way-Handshake stattfindet.
- Schließlich erfolgt beim Einsatz von HTTPS noch ein TLS-Handshake über die TCP-Verbindung, wobei der Client das Zertifikat des Servers validieren muss. Dabei muss der Client auch noch prüfen, ob das Zertifikat nicht widerrufen wurde.

All diese Schritte werden beim Preconnect bereits durchgeführt. Danach hat der Browser eine Verbindung zum Ziel-Host und ist „ready to go“, um darüber HTTP-Requests zu übertragen und die Antworten zu empfangen.

siehe auch: https://docs.google.com/presentation/d/ ... 3305a_0106

Das unterstützt meine Aussage, danke

Hier ist es etwas ausführlicher beschrieben: https://developer.mozilla.org/en-US/doc ... s-prefetch

While dns-prefetch only performs a DNS lookup, preconnect establishes a connection to a server. This process includes DNS resolution, as well as establishing the TCP connection, and performing the TLS handshake

Der Vollständigkeit halber wird dort allerdings auch von dem Preconnecten zu sämtlichen fremden Hosts abgeraten.

Anders als Du es darstellst, ist an meiner vorherigen Aussage, dass mit dem Preconnect lediglich Netz(werk)informationen abgefragt werden, nichts falsches daran.

1.) Falsch bzw. irreführend wird deine Aussage durch das Wörtchen „lediglich“. Du stellst es so dar, als würde Preconnect z. B. lediglich die IP-Adresse ermitteln (das wäre DNS-Prefetch) o. Ä., tatsächlich wird aber schon eine richtige Verbindung zum angegeben Ziel aufgebaut.

2.) Vielleicht magst du mal erläutern, was du ganz konkret mit „Netz(werk)informationen abfragen“ meinst?

Dementsprechend ist es der besagte Quatsch diese Informationen bei jedem Seitenaufruf immer und immer wieder abzufragen.

Quatsch ist es dann, wenn die durch Preconnect aufgebaute Verbindung nicht genutzt wird, denn dann hätte der Browser die Verbindung völlig umsonst aufgebaut. Im Falle von Header Bidding, wo die Anfragen nicht gecached werden können, ist es also definitiv kein Quatsch (zumindest nicht in dieser Hinsicht), da die Verbindung früher oder später immer aufgebaut wird.

Vor dem Hintergrund, dass mit den vom Themenstarter aufgeführten Code Beispielen nur der Host von Yieldlove preconnected wird, aber eben nicht die Server mit denen der Anzeigendeal ausgehandelt wird, macht den Versuch mit dem Preconnect etwas zu Gunsten des Header Bidding Vorgangs zu beschleunigen sinnfrei.

Das ist korrekt, aber egal ob der Themenstarter das so meinte oder nicht, meine Argumentation bezieht sich explizit auf das Aufbauen einer Verbindung zu den am Header Bidding teilnehmenden Hosts.

[supervisior]

Sorry, Herr Lehrer, aber das kann ich wiederum nicht so stehen lassen.

Von einem „vollständigen Request“ habe ich nicht gesprochen, und ein vollständiger Request kann es ja auch gar nicht sein, denn dazu müsste man bereits eine spezifische Ressource/URL abfragen. Das wäre dann Prefetch.

Eine Begrifflichkeit vollständig oder unvollständig gibt es nicht bei einem Request. Er ist entweder vollständiig oder nicht. Außerdem verwendest Du das Wort Anfrage, womit Du einen Request implizierst was der Definition für einen Request nach falsch ist.

Und das Teil heißt „Preconnect“, weil die Verbindung schonmal im Voraus aufgebaut werden soll, um spätere Abfragen zu beschleunigen.

Für sich allein gestellt, absolut richtig, aber falsch, wenn es um das Thema hier geht. Warum denn x-mal zu immer dem Gleichen Host preconnecten, wenn letztendlich zu ganzen anderen und sich veränderten Hosts die dann eigentlichen Requests stattfinden. Wenn ich weiß wo Du wohnst und wie ich zu Dir hinkomme, dann lauf ich doch nicht bei jedem Mal, wenn ich Dich etwas fragen will vorher den Weg zu Dir ab? Erklär mir mal bitte welchen Vorteil ich dadurch erlangen soll?

Doch, genau das! Natürlich zum angegeben Ziel-Host. Wohin denn sonst, zum Mond?

Du widerlegst damit das Header Bidding Funktionsprinzip, wenn Du gleichzeitig sagst, dass beim Header Bidding sich wechselnde Verbindungen zu verschiedenen Hosts aufgebaut werden.

1.) Du vermischst die Begriffe Verbindung und Request. Ein Request erfolgt über eine Verbindung. Diese Netzwerkverbindung zum angegeben Ziel-Server wird mit Preconnect bereits vorher aufgebaut, bevor der Browser wissen kann, dass er eine Anfrage an einen bestimmten fremden Host schicken muss. Über diese Verbindung, die offen gehalten wird, kann der Browser später einen HTTP-Request abschicken, und sich dann das Aufbauen einer neuen Verbindung sparen, weil ja bereits eine geöffnet ist. Genau das ist doch der Sinn der Sache.

Ohje, jetzt vermischt Du aber sehr viele eigentlich genormte Begrifflichkeiten und definierst,was ganz Neues. Was Du da beschreibst, würde nur dann einen Sinn machen, wenn außer Yieldlove kein weiterer Host am Header Bidding beteilgt wäre. Und du wirst mehr jetzt aber nicht sagen wollen, dass das nicht so ist? Ha?

2.) Der Aufbau einer Verbindung ist viel mehr als nur ein „Handshake“. Zuerst muss die IP-Adresse ermittelt werden (entweder ist sie schon bekannt, oder sie muss über den Nameserver abgefragt werden). Dann muss eine TCP-Verbindung aufgebaut werden. Schließlich erfolgt beim Einsatz von HTTPS noch ein TLS-Handshake, wobei der Client das Zertifikat des Servers validieren muss. Dabei muss der Client auch noch prüfen, ob das Zertifikat nicht widerrufen wurde. Die Verbindung ist danach „ready to go“, um HTTP-Requests zu übertragen.

Ich hatte nicht gesagt, dass die Verbindung nur aus einem Handshake besteht. Ich hatte gesagt, dass die Verbindung beim Handshake endet, bevor es zu einem eigentlichen Request kommt. Tu mir mal bitte nicht das Wort im Mund umdrehen, gell!

siehe auch: https://docs.google.com/presentation/d/ ... 3305a_0106

Das unterstützt meine Aussage, danke

Negativ, das korrigiert Deine Aussage.

Siehe auch: https://developer.mozilla.org/en-US/doc ... s-prefetch

Das ist die Vorstufe zum Preconnect. Ja und?

While dns-prefetch only performs a DNS lookup, preconnect establishes a connection to a server. This process includes DNS resolution, as well as establishing the TCP connection, and performing the TLS handshake

Welche Rolle spielt jetzt dns-prefetch bei Deiner Argumentation?

Der Vollständigkeit halber wird dort allerdings auch von dem Preconnecten zu sämtlichen fremden Hosts abgeraten.

Also war/ist die ganze Diskussion darüber für den Popo gewesen?

Falsch bzw. irreführend wird deine Aussage durch das Wörtchen „lediglich“. Du stellst es so dar, als würde Preconnect z. B. lediglich die IP-Adresse ermitteln (das wäre DNS-Prefetch) o. Ä., tatsächlich wird aber schon eine richtige Verbindung zum angegeben Ziel aufgebaut.

Du legst mir da Wörter in den Mund, die ich so nie gesagt habe. Ich habe die zu sammelten Informationen während eines Preconnects nur deswegen als "lediglich" bezeichnet, weil es eben kein vollständiger Request ist. Deine Aussage zu "richtige Verbindung" wäre demnach aber auch falsch, weil "richtig" impliziert, dass es ein vollständiger Request wäre, was es, wie wir beide nun wissen, nicht ist.

Quatsch ist es dann, wenn die durch Preconnect aufgebaute Verbindung nicht genutzt wird, denn dann hätte der Browser die Verbindung völlig umsonst aufgebaut. Im Falle von Header Bidding, wo die Anfragen nicht gecached werden können, ist es also definitiv kein Quatsch (zumindest nicht in dieser Hinsicht), da die Verbindung früher oder später immer aufgebaut wird.

Du bist immer noch auf dem falschen Dampfer. Sag mir doch bitte, wie ein Preconnect zu allen beteiligten Hosts gelangen soll, wenn der Preconnect schon beim Handshake bei Yieldlove Host endet? Der Vorteil des Preconnects endet doch, bzw. reduziert sich doch auf die Verbindung zum Yieldlove Host! Du argumentierst ständig mit einem in sich widersprechenden Argument?!

Das ist korrekt, aber egal ob der Themenstarter das so meinte oder nicht, meine Argumentation bezieht sich explizit auf das Aufbauen einer Verbindung zu den am Header Bidding teilnehmenden Hosts.

So wie Du argumentierst, hat man eigentlich den gegenteiligen Eindruck....

[Hanzo2012]

Oh Mann, du machst das mit Absicht, oder? ... Nochmal Schritt für Schritt, sag mir bitte, ab wo du nicht mehr einverstanden bist:

1.) Um einen HTTP-Request an einen Server zu senden und eine Antwort darauf zu erhalten, bedarf es einer Netzwerkverbindung zu diesem Server.

2.) Normalerweise baut der Browser die Netzwerkverbindung zu einem Server erst dann auf, wenn er sieht, dass er eine Ressource von diesem Server benötigt. Vorher kann er es ja auch nicht wissen. Die Ressource kann z. B. ein Font, ein Skript oder auch ein Header Bidding-Gebot sein.

3.) Das Aufbauen einer HTTP(S)-Netzwerkverbindung kann zeitraubend sein, da dazu die IP-Adresse ermittelt werden muss, eine TCP-Verbindung aufgebaut werden muss und - bei HTTPS - der TLS-Handshake inkl. Validierung des Zertifikats erfolgen muss.

4.) Preconnect weist den Browser an, eine Verbindung (siehe Punkt 3) zu einem angegeben Server im Voraus aufzubauen - also bevor er wissen kann, dass er eine Ressource von diesem Server benötigt - und diese Verbindung im Hintergrund offen zu halten. Der Browser kann viele Verbindungen gleichzeitig zu vielen verschiedenen Hosts geöffnet halten.

5.) Beim Header Bidding werden viele Server gleichzeitig kontaktiert und darum gebeten, ein Gebot für eine Werbeeinblendung abzugeben. Dabei wird ein Timeout eingesetzt: Nach z. B. 500 ms wird die Auktion beendet. Wer bis dahin kein Gebot abgegeben hat, wird nicht berücksichtigt. Besser gesagt: Das Gebot muss innerhalb dieser Zeitspanne beim Client ankommen.

6.) Wenn der Browser die Verbindungen zu den am Header Bidding teilnehmenden Servern (nicht Yieldlove, sondern die verschiedenen eingebundenen Werbenetzwerke!) erst dann aufbaut, wenn das Header Bidding gestartet wird, tickt währenddessen bereits die Timeout-Uhr. Da das Aufbauen einer Verbindung lange dauern kann, ist es möglich, dass Gebote unter den Tisch fallen, weil sie zu spät eintreffen.

7.) Wenn der Browser schon vor dem Start des Header Biddings die Verbindungen zu den teilnehmenden Servern aufbaut, kann er diese nutzen, um die Gebote einzuholen. Somit wird, während der Timeout läuft, keine Zeit mit dem Aufbau von Verbindungen verschwendet, und potenziell mehr Gebote kommen rechtzeitig vor Ablauf des Timeouts an. Das wiederum sorgt potenziell für höhere Einnahmen.

[supervisior]

Du musst das nicht ständig versuchen zu widerlegen. Der allesentscheidende Punkt im Interesse des Themas ist, dass sich der Einsatz von Preconnect in Verbindung mit Header Bidding alles andere als gesichert vorteilhaft bestätigen lässt, eben weil es zu viele Widrigkeiten und Besonderheiten dabei gibt. Man muss schon sehr weit, wie in Deiner Argumentation, ausholen, um sich da was Schlüssiges erzählen zu können. Für mich macht es in jedem Fall keinen wirklichen Sinn und wenn, dann nur einmalig im Sinne von 1 Preconnect. Wenn Du mir was anderes erzählen willst, dann stellst Du damit max. eine Theorie auf, die sich aber nur sehr schwer bis gar nicht belegen lässt.

[Hanzo2012]

Du hast das Prinzip von Preconnect und den Unterschied zwischen Requests und Verbindungen immer noch nicht verstanden, seufz. Ich möchte dir eigentlich nur helfen dieses falsche Verständnis abzulegen, aber wenn du nicht willst, dann lassen wir es.

[supervisior]

Du hast das Prinzip von Preconnect und den Unterschied zwischen Requests und Verbindungen immer noch nicht verstanden, seufz. Ich möchte dir eigentlich nur helfen dieses falsche Verständnis abzulegen, aber wenn du nicht willst, dann lassen wir es.

Ich kann Deiner Argumentationskette nicht folgen, weil Du diese mit Widersprüchlichkeiten rechtfertigst und dabei auch noch neue Begrifflichkeiten nebst neuen Beschreibungen einführst, die bis dato noch niemand kannte. Das gilt aber nicht generell, sondern bei Deiner Vermischung von Preconnect und Header Bidding. Jeder der beiden Punkte für sich und allein gestellt, müssen wir darüber nicht diskutieren. Ich steige jedoch aus, wenn Du nur eine Theorie aufstellst, die Du praktisch nicht belegen kannst und das kannst Du nicht. Bringe mir diesen und ich lobpreise Dich in meiner Signatur.

[Hanzo2012]

Welche Begrifflichkeiten führe ich neu ein?

Dass es in der Praxis wenig Sinn ergibt, sage ich bereits die ganze Zeit. Es geht mir nur noch darum deine falschen Vorstellungen auszuräumen und deine unberechtigte Kritik an meinen Ausführungen zu widerlegen.

Es gibt da bei dir immer noch ein Missverständnis. Du redest die ganze Zeit von einem einmaligen Preconnect. Was meinst du damit?

[supervisior]

Es gibt da bei dir immer noch ein Missverständnis. Du redest die ganze Zeit von einem einmaligen Preconnect. Was meinst du damit?

Ist doch nicht so schwer.... Setze beim erstmaligen Aufruf einer Seite 1 Cookie und mache das Preconnecten von der Existenz dieses Cookies abhängig, worauf beim Seitenwechsel der Preconnect nicht erneut stattfindet.

Diese Praktik setze ich z.B. bei Server PUSH ein, um CSS,JS und Schriften vorzuladen. Allerdings muss ich mir nicht die Mühe machen den Cookie erst zu definieren, weil mein "Lichtgschwindkeitsserver" automatisch erkennt, wenn ich den Server PUSH verwende und mir dann ebenso automatisch einen Cookie schickt und ich diesen dann so gezielt einsetze, dass die besagten statischen Sourcen nur einmal per PUSH laden muss.

[Hanzo2012]

OK, so dachte ich mir schon, dass du es so meinst. Wollte nur sicher gehen. Nur was soll das bringen? Warum nicht beim zweiten, dritten Besuch auch Preconnect machen? Die Verbindungen zu den Header Bidding-Servern werden schließlich bei jedem Besuch aufgebaut, nicht nur beim ersten.

[supervisior]

Warum nicht beim zweiten, dritten Besuch auch Preconnect machen? Die Verbindungen zu den Header Bidding-Servern werden schließlich bei jedem Besuch aufgebaut, nicht nur beim ersten.

Mit dieser Frage schickst Du uns in einen Loop und wir fangen wieder von vorne an. Wenn Du Dir den Code des Themenstarters nochmal anschaust, wirst Du feststellen, dass dort nur die jeweils fixe Domain Namen eingetragen sind. Da gibt es also keine sich wechselnden URLs, die aber Voraussetzungen wären, damit Deine Frage eine Rechtfertigung bekäme.

[Hanzo2012]

Korrekt, fixe Domainnamen. Mein Vorschlag war es, konkret die Domainnamen der am Header Bidding teilnehmenden Hosts einzutragen.

Ich glaube hier liegt das Missverständnis: Für den Preconnect brauchst du keine komplette URL, sondern nur den Domainnamen. Und die wechseln nicht. Ich weiß, welche Domains für das Header Bidding relevant sind.

[supervisior]

Somit schließt sich der Kreis und wir vertreten gar keine gegensätzlichen Standpunkte. Allerdings warst/bist Du der Auslöser für diese nicht ganz sinnfreie Diskussion. Zu Deiner Verteidigung gebe ich Dir aber recht, dass dieses Preconnect - Header Bidding Konstrukt nur dann einen Sinn macht, wenn man die Domains kennt.

[Micha_Es]

Ok, dann ist das preconnenct und prefetch zu den 100 Prozent Quellen (CDN, Analytics) sinnvoll, der Rest fragwürdig!?

[supervisior]

Ok, dann ist das preconnenct und prefetch zu den 100 Prozent Quellen (CDN, Analytics) sinnvoll, der Rest fragwürdig!?

Das kannst Du so nicht pauschalieren. GA z.B. ist weit weitverbreitet, deswegen befindet sich das dazugehörige Script schon im Cache der meisten Browser. Von daher braucht es kein pre*. Ein CDN ist was komplett anderes. Da gehts nicht darum eine Source von einer Quelle zu laden.

Nimm das Beispiel mit dem Laden von Schriftarten von Google Fonts. Da macht nicht nur ein Preconnect Sinn, sondern eher ein Prefetch. Du müsstest ein präzises Beispiel nennen, um das konkret beantworten zu können.