est-il possible de faire des demandes ad Serverside au lieu de navigateur à l'aide d'un navigateur sans tête?

Question

La motivation de cette idée est que les demandes de publicité du navigateur sont souvent très lent et peut bloquer le rendu des pages, sans parler de consommer le fil javascript du navigateur. Si un chargement de la page plusieurs annonces, qui est beaucoup de peu fiables, le blocage des appels de tiers. En utilisant un événement navigateur entraîné côté serveur sans tête, serait-il possible de faire ces demandes et de transmettre les actifs publicitaires au navigateur à la fois? En particulier, cela fonctionnerait avec doubleclick, dont les réseaux ad font souvent une série de demandes que les balises de script document.write qui vont chercher alors plus de script, peut charger un swf flash qui demande alors quelques gifs supplémentaires? On dirait un peu beaucoup, mais les annonces sont le diable, et si cela peut être déchargé du client, cela améliorerait sitespeed énormément, car une solution de serveur peut faire des demandes d'annonces et javascript processus en parallèle.

EDIT: En réponse à @dthorpe:

Tous les bons points à prendre en considération.

En ce qui concerne la latence adserving, une solution côté serveur devrait aider pour les raisons suivantes:

Tout d'abord, plusieurs demandes de publicité peut être faite en parallèle. Bien qu'il existe des méthodes de chargement des ressources en parallèle dans le navigateur, il n'y a pas de bonne solution que je connaisse qui est tout à fait non-blocage (par exemple en termes de rendu des pages et par rapport à l'événement onload), à moins que vous chargez paresseux tous vos les publicités. Je suis à la recherche d'un moyen d'annonces de charge en parallèle et de manière non bloquante tandis que le reste de la page est en cours de chargement.

En second lieu, et peut-être plus important encore, annonces chargement Doubleclick implique généralement plusieurs scripts de chargement intermédiaires. Javascript dans le navigateur est un seul thread. Cela implique directement que le javascript de ma page va bloquer l'annonce-javascript, ce qui ralentit l'impression d'annonce. Le javascript de l'annonce, à son tour, va bloquer le javascript de ma page, ralentir ma page. Je peux avoir d'autres appels de tiers en jeu, pour le suivi ou d'autres fins. J'ai aussi plusieurs annonces sur la page, tout en aidant le rendu des pages de ralentissement et de l'exécution javascript. En déchargeant l'annonce de chargement sur le serveur, le javascript de ma page ne concurrencera pas de l'annonce. La latence apportée par les annonces sera fonction d'une annonce (la plus longue), mais le comportement de chargement pour une annonce ne sera pas influencé par les autres annonces ou ma page, et en théorie devrait être plus rapide en conséquence.

Le but est de dissocier les annonces de la page de base de telle sorte que les annonces ne bloquent pas le rendu des pages, la page événement onLoad ou ralentir la page ou l'autre. Je ne connais pas de solution côté client qui peut atteindre désolidarisation parfait aussi longtemps que dans le navigateur javascript est un seul thread. Alors que les annonces de chargement longue sont remplies via javascript, le reste de la page doit attendre.

Je suis au courant des divers mécanismes de chargement paresseux, certains impliquant des iframes, et d'autres qui override document.write pour recevoir le chargement différé, mais aucun d'entre eux ont eu des résultats satisfaisants, uniquement en raison du comportement de série d'interférer l'exécution javascript.

Je me demande si je peux obtenir les avantages de chargement d'annonces côté serveur en utilisant des applets Java dans le navigateur et éviter la situation cookies / préchargement vous avez mentionné? Je considère en fait ces approches non conformes en raison de la grave dégradation que nous voyons avec des annonces Doubleclick. La façon dont ces annonces tuer la vitesse de chargement de la page est la vraie abomination:)

Answer 1

Pour représenter entièrement la machine cliente avec précision, votre navigateur serveur sans tête aurait besoin d'être en mesure de présenter les cookies du navigateur résidant sur le client pour le domaine du réseau publicitaire (s). Ce sera difficile, car le nom de domaine de votre serveur ne sera pas dans le domaine du réseau publicitaire (s), de sorte que le navigateur client ne vous donnera pas les cookies du réseau publicitaire.

Vous pourriez probablement saisir les annonces dans votre navigateur serveur « pré-charge » les au nom du client, mais sans les cookies du navigateur du client vous manquerait la continuité et le suivi que les réseaux publicitaires comptent beaucoup sur. Les annonces sélectionnées pour l'affichage par les réseaux publicitaires seront basés sur les pages de votre navigateur serveur a vu au nom du client, et non pas ce que le client a vu.

En outre: Si le chargement du contenu publicitaire est ce qui bloque le rendu des pages dans le navigateur client, comment rendre les mêmes pages sur votre serveur va quoi que ce soit accélérer? Votre navigateur serveur souffrira du même réseau et le décalage de script comme le navigateur client, et le client sera toujours assis là, attendant pour « quelque chose », mais ne montrera rien que la page soit complètement chargée et a été traitée dans le navigateur de serveur et relayés vers le navigateur client? Déplacement du problème « en amont » ne résout rien.

Enfin: même si vos intentions peuvent être honorables (pour améliorer l'expérience de navigation des clients), les réseaux publicitaires vont très probablement considérer votre annonce navigateur serveur « préchargement » une abomination et une violation de leurs termes de réseau d'annonces de service précisément parce qu'elle interfère avec leur capacité à suivre l'activité de navigation du client réel.

Answer 2

L'utilisation d'un plugin java côté client serait probablement encore plus le gaspillage des ressources de la machine client, comme le plugin Java doit être chargé dans le navigateur qui peut souvent prendre plusieurs secondes.

Gardez à l'esprit que, avec la régularité de Java exploite dans le 0 jours sauvage ( http: // java-0 jours. com / ). Le plug-in Java est recommandé d'être désactivé sur tous les navigateurs Web. Mac viennent maintenant avec Java plugins désactivés par défaut. En outre, aucun plug-ins Java existent sur les appareils mobiles tels que les smartphones et les tablettes. Donc, vous seriez incapable de livrer la publicité à tout à côté des navigateurs de bureau, et probablement que les navigateurs de bureau utilisés à l'extérieur d'un environnement d'entreprise.

Si les annonces de chargement paresseux ne sont pas acceptables, vous devrez probablement accepter les temps de chargement de DoubleClick tels qu'ils sont. Les réseaux publicitaires ne prennent pas de bien vouloir l'ingérence d'un point de vue contractuel, et si vous envisagez de vendre votre inventaire publicitaire directement, vous rencontrerez la résistance des annonceurs eux-mêmes comme ils tentent de livrer les riches en vogue annonces médiatiques. (vidéos, annonces extensibles, interstitielles, etc)

Vous allez finir par passer plus de temps en essayant d'obtenir votre annonce parfaite de la couche d'émulation pour chaque nouveau type d'annonce qui vient, que le montant que vous ferez du coût par millier de taux sur la publicité d'affichage.

Peut-être que vous devriez reconsidérer si les annonces même sens, ou si besoin de votre modèle d'affaires pour monétiser votre site Web d'ajustement. la publicité d'affichage est devenu un marché des matières premières et le coût de la construction de cette couche d'émulation dans votre temps apparaît supérieure à la prestation de la vitesse page accrue, et les impressions légèrement plus élevées que la vitesse de page peut apporter.

Chapeau à vous soucier de vos utilisateurs finaux cependant, les demandes de publicité DoubleClick peut être un frein réel sur les temps de chargement de la page. J'aimerais que quelqu'un vienne et de fournir un moyen de chargement ad defer de manière robuste et fiable.