Herzlich willkommen im SEO Forum der ABAKUS Internet Marketing GmbH
registrieren registriertes Mitglied
Warum nicht beides? Diese beiden Menchanismen sind für unterschiedliche Dinge gedacht: HTTP Push geht nur für Ressourcen, die auf deinem eigenen Server liegen, während dns-prefetch und preconnect für Ressourcen auf fremden Servern gedacht sind.supervisior hat geschrieben: ↑24.04.2020, 14:31 Wenn Du Deiner eigenen Seite was Gutes antun willst und die Ladezeit verbessern willst, dann verwende HTTP Server PUSH. An der richtigen Stelle im Code platziert und vorausgesetzt Dein Provider hat diese Funktion nicht deaktiviert, kannst damit deiner Seite den buchstäblichen PUSH verschaffen. Dann aber bitte kein prefetch & Co. mehr verwenden.
Natürlich kannst Du rein technisch beides verwenden, aber am Beispiel des Themenstarters wird ja überdeutlich, dass es keinen Sinn macht. Es kommt auf das richtige Maß an.Hanzo2012 hat geschrieben: ↑24.04.2020, 14:35Warum nicht beides? HTTP Push geht doch nur für Ressourcen, die auf deinem eigenen Server liegen, während dns-prefetch und preconnect für Ressourcen auf fremden Servern gedacht sind.supervisior hat geschrieben: ↑24.04.2020, 14:31 Wenn Du Deiner eigenen Seite was Gutes antun willst und die Ladezeit verbessern willst, dann verwende HTTP Server PUSH. An der richtigen Stelle im Code platziert und vorausgesetzt Dein Provider hat diese Funktion nicht deaktiviert, kannst damit deiner Seite den buchstäblichen PUSH verschaffen. Dann aber bitte kein prefetch & Co. mehr verwenden.
Micha_Es hat geschrieben: ↑25.04.2020, 08:56 Danke für eure Meinungen. Nun, es geht um AdSense, Yieldlove, Analytics und noch etwa von einem Zweitserver (Bilder).
Ich denke, dass der Zweitserver eine Berechtigung hat. Analytics wird zum Schluss geladen, AdSense mit Supervior Script, sodass das nicht unbedingt notwendig ist.
Bleibt Yieldlove mit Header Bidding und den geschätzen 50 Netzwerken - das ist das overdosed.
Also belasse ich es auf den Zweitserver. Server Push muss ich mir einmal anschauen![]()
Nein, will ich nicht, doch die Frage zielte u.a. drauf hin ab, wobei ich das ja sagte, dass das voraussichtlich nicht zeitgemäß ist.Ich weiß nicht, ob ich Dich jetzt richtig verstanden habe, aber willst Du die Aufrufe zu den Werbenetzwerken vorladen?
Code: Alles auswählen
<link rel="preconnect" href="https://ad.71i.de/" crossorigin>
<link rel="preconnect" href="https://71i.nuggad.net/" crossorigin>
<link rel="preconnect" href="https://probe.yieldlab.net/" crossorigin>
<link rel="preconnect" href="https://ad.yieldlab.net/" crossorigin>
Micha_Es hat geschrieben: ↑25.04.2020, 13:03Nein, will ich nicht, doch die Frage zielte u.a. drauf hin ab, wobei ich das ja sagte, dass das voraussichtlich nicht zeitgemäß ist.Ich weiß nicht, ob ich Dich jetzt richtig verstanden habe, aber willst Du die Aufrufe zu den Werbenetzwerken vorladen?
Schaut man sich aber große Seiten an, so findet man:Code: Alles auswählen
<link rel="preconnect" href="https://ad.71i.de/" crossorigin> <link rel="preconnect" href="https://71i.nuggad.net/" crossorigin> <link rel="preconnect" href="https://probe.yieldlab.net/" crossorigin> <link rel="preconnect" href="https://ad.yieldlab.net/" crossorigin>
Der Gedanke dabei ist wahrscheinlich, dass beim Header Bidding typischerweise jedem Werbenetzwerk nur ein paar hundert Millisekunden Zeit gegeben werden, um sein Gebot abzugeben. Gerade bei geografisch weit entfernten Servern und über HTTPS kann die erste Anfrage so lange dauern, dass das Gebot zu spät ankommt, wodurch potenziell Einnahmen verloren gehen. Natürlich könnte man auch einfach den Timeout erhöhen, wenn der Header Bidding-Anbieter das zulässt.Micha_Es hat geschrieben: ↑25.04.2020, 13:03Nein, will ich nicht, doch die Frage zielte u.a. drauf hin ab, wobei ich das ja sagte, dass das voraussichtlich nicht zeitgemäß ist.Ich weiß nicht, ob ich Dich jetzt richtig verstanden habe, aber willst Du die Aufrufe zu den Werbenetzwerken vorladen?
Schaut man sich aber große Seiten an, so findet man:Code: Alles auswählen
<link rel="preconnect" href="https://ad.71i.de/" crossorigin> <link rel="preconnect" href="https://71i.nuggad.net/" crossorigin> <link rel="preconnect" href="https://probe.yieldlab.net/" crossorigin> <link rel="preconnect" href="https://ad.yieldlab.net/" crossorigin>
Wenn dem so wäre, woran ich spontan auch schon gedacht hatte, spricht das aber nicht wirklich für Yieldlove, bzw. deren Netzanbindung. Adsense bietet etwas ähnliches wie Header Bidding, heißt dort nur anders, dort hat man die von Dir genannte Problematik aber nicht.. Aber selbst wenn man versucht mit diesem Preconnect das Header Bidding zu unterstützen, ist die Methodik dennoch zweifelhaft. Erstens ist es Quatsch den Preconnect bei jedem Seitenaufruf immer und immer wieder zu machen, wo es doch mit dem Preconnect nur darum geht schon mal vorab die Netzinformationen für die bevorstehenden Aufruf abzufragen und dann zu cachen. Jeder erneute preconnect macht dann wenig bis gar keinen Sinn mehr. Quatsch ist auch, weil das erste zu ladende Script nur dazu dient weitere Scripte nachzuladen und dabei entsteht die größte Wartzeit.Hanzo2012 hat geschrieben: ↑25.04.2020, 17:02 Der Gedanke dabei ist wahrscheinlich, dass beim Header Bidding typischerweise jedem Werbenetzwerk nur ein paar hundert Millisekunden Zeit gegeben werden, um sein Gebot abzugeben. Gerade bei geografisch weit entfernten Servern und über HTTPS kann die erste Anfrage so lange dauern, dass das Gebot zu spät ankommt, wodurch potenziell Einnahmen verloren gehen. Natürlich könnte man auch einfach den Timeout erhöhen, wenn der Header Bidding-Anbieter das zulässt.
Siehe: https://www.reddit.com/r/adops/comments ... effective/
Da muss ich dich korrigieren: Der Preconnect veranlasst den Browser schonmal eine HTTP-Verbindung zum jeweiligen Server aufzubauen, die dann für folgende Anfragen genutzt werden kann. Das Aufbauen einer Verbindung kann inkl. DNS-Lookup, Zertifikatvalidierung und Handshake hunderte Millisekunden dauern. Wenn ich also weiß, dass in Zukunft eine nicht cachebare Anfrage an einen gewissen Server stattfinden wird (wie es beim Header Bidding der Fall ist), dann ist das nicht Quatsch. Die Verbindung muss so oder so aufgebaut werden, ohne den Preconnect würde sie jedoch erst später aufgebaut werden (wenn das Pre-Bidding startet, also nachdem das Pre-Bidding-Skript geladen und ausgeführt wurde), wodurch das Gebot ggf. zu spät ankäme.supervisior hat geschrieben:wo es doch mit dem Preconnect nur darum geht schon mal vorab die Netzinformationen für die bevorstehenden Aufruf abzufragen und dann zu cachen