是否可以使用无头浏览器发出服务器端广告请求而不是浏览器内广告请求？
这个想法的动机是浏览器广告请求通常非常慢，并且可能会阻塞页面渲染，更不用说消耗浏览器 JavaScript 线程了。如果一个页面加载多个广告，就会产生大量不可靠的、阻塞的第三方调用。通过使用事件驱动的无头服务器端浏览器，是否可以发出这些请求并将广告资源一次性传递到浏览器？特别是，这是否适用于 doubleclick，其广告网络经常发出一系列请求，document.write 脚本标记然后获取更多脚本，可能会加载 flash swf，然后请求一些额外的 gif？听起来有点多，但广告是魔鬼，如果可以从客户端卸载，它将极大地提高网站速度，因为服务器解决方案可以并行发出广告请求和处理 JavaScript。
编辑：回复@dthorpe：
所有值得考虑的好点。
至于广告投放延迟，服务器端解决方案应该有所帮助，原因如下：
首先，可以并行发出多个广告请求。虽然有在浏览器中并行加载资源的方法，但据我所知，没有一个好的解决方案是完全非阻塞的（即在页面渲染方面和 onload 事件方面），除非您延迟加载所有资源广告。我正在寻找一种在加载页面其余部分时以非阻塞方式并行加载广告的方法。
其次，也许更重要的是，加载双击广告通常涉及加载多个中间脚本。浏览器中的 JavaScript 是单线程的。这直接意味着我的页面的 javascript 将阻止广告 javascript，从而减慢广告展示速度。广告的 JavaScript 反过来会阻止我页面的 JavaScript，从而减慢我的页面速度。我可能有其他第三方通话正在进行，用于跟踪或其他目的。我的页面上还有多个广告，所有广告都有助于减慢页面渲染和 JavaScript 执行速度。通过将广告加载卸载到服务器，我的页面的 JavaScript 将不会与广告的竞争。广告带来的延迟将取决于一个广告（最长的广告），但一个广告的加载行为不会受到其他广告或我的页面的影响，理论上应该会更快。
目标是解除广告与基本页面的关联，使广告不会阻止页面呈现、页面加载事件或减慢页面或彼此之间的速度。我不知道有任何客户端解决方案可以实现完美的分离，只要浏览器内的 JavaScript 是单线程的。虽然长时间加载的广告是通过 JavaScript 完成的，但页面的其余部分必须等待。
我知道各种延迟加载机制，有些涉及 iframe，有些覆盖 document.write 以适应延迟加载，但这些机制都没有取得令人满意的结果，纯粹是由于干扰 javascript 执行的串行行为。
我想知道我是否可以在浏览器中使用 java applet 获得服务器端广告加载的好处，并避免您提到的 cookie/预加载情况？实际上，我正在考虑这些不合格的方法，因为我们看到双击广告的严重退化。这些广告破坏页面加载速度的方式才是真正令人憎恶的:)
The motivation for this idea is that browser ad requests are often painfully slow and can block page rendering, not to mention consume the browser javascript thread. If a page loads several ads, that's a lot of unreliable, blocking third party calls. By using an event driven headless server side browser, would it be possible to make those requests and pass the ad assets up to the browser all at once? In particular, would this work with doubleclick, whose ad networks often make a series of requests that document.write script tags that then fetch more script, may load a flash swf that then requests some additional gifs? It sounds like a bit much, but ads are the devil, and if that can be offloaded from the client, it would improve sitespeed tremendously, since a server solution can make ad requests and process javascript in parallel.
EDIT: Responding to @dthorpe:
All good points to consider.
As for ad serving latency, a server side solution should help for the following reasons:
First, multiple ad requests can be made in parallel. While there are methods of loading resources in parallel in the browser, there is no good solution I know of that is completely non-blocking (i.e. both in terms of page rendering AND with respect to the onload event), unless you lazy load all your ads. I'm looking for a way to load ads in parallel and in a non-blocking fashion while the rest of the page is loading.
Second, and perhaps more significantly, loading doubleclick ads usually involves loading multiple intermediate scripts. Javascript in the browser is single threaded. This directly implies that my page's javascript will block the ad-javascript, slowing down the ad impression. The ad's javascript, in turn will block my page's javascript, slowing down my page. I may have other third party calls in play, for tracking or other purposes. I also have multiple ads on the page, all helping slow down page rendering and javascript execution. By offloading the ad-loading to the server, my page's javascript will not compete with the ad's. The latency contributed by the ads will be a function of one ad (the longest one), but the loading behavior for one ad will not be influenced by the other ads or my page, and in theory should be faster as a result.
The goal is to disassociate the ads from the base page in such a way that the ads do not block page rendering, the page onload event, or slow down the page or each other. I don't know of any client side solution that can achieve perfect disassociation as long as in-browser javascript is single threaded. While long-loading ads are being fulfilled via javascript, the rest of the page has to wait.
I am aware of various lazy loading mechanisms, some involving iframes, and some that override document.write to accommodate deferred loading, but none of these have had satisfactory outcomes, purely due to the serial behavior of interfering javascript execution.
I wonder if I can get the benefits of server side ad loading using java applets in the browser and avoid the cookie/preloading situation you mentioned? I am actually considering these non-conforming approaches due to the serious degradation we see with doubleclick ads. The way those ads kill page load speed is the true abomination :)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
为了准确地完全代表客户端计算机，您的无头服务器浏览器需要能够显示驻留在客户端上的广告网络域的浏览器 cookie。这将很困难，因为您的服务器的域名不在广告网络域中，因此客户端浏览器不会向您提供广告网络 cookie。
您可能可以在服务器浏览器中捕获广告，以代表客户端“预加载”它们，但如果没有客户端的浏览器 cookie，您将缺乏广告网络严重依赖的连续性和跟踪。广告网络选择显示的广告将基于您的服务器浏览器代表客户端查看的页面，而不是客户端查看的页面。
另外：如果加载广告内容是阻止客户端浏览器中页面呈现的原因，那么在服务器上呈现相同页面将如何加快速度？您的服务器浏览器将遭受与客户端浏览器相同的网络和脚本延迟的影响，并且客户端仍将坐在那里等待“某事”，但在页面完全加载并在服务器浏览器中处理之前不会显示任何内容，并且转发到客户端浏览器？将问题“向上游”转移并不能解决任何问题。
最后：即使您的意图可能是光明正大的（改善客户端浏览体验），广告网络很可能会认为您的服务器浏览器广告“预加载器”是令人厌恶的，并且违反了他们的广告网络服务条款，因为这会干扰他们的能力跟踪实际客户端的浏览活动。
In order to fully represent the client machine accurately, your headless server browser would need to be able to present the browser cookies residing on the client for the ad network domain(s). This will be difficult since your server's domain name won't be in the ad network domain(s), so the client browser won't give you the ad network cookies.
You could probably capture the ads in your server browser to "pre-load" them on behalf of the client, but without the client's browser cookies you would lack continuity and tracking that the ad networks rely heavily on. The ads selected for display by the ad networks will be based on what pages your server browser has viewed on behalf of the client, not what the client has viewed.
Also: If loading the ad content is what is blocking the rendering of pages in the client browser, how is rendering the same pages on your server going to speed anything up? Your server browser will suffer from the same network and script lag as the client browser, and the client will still be sitting there waiting for "something", but will show nothing until the page has fully loaded and has been processed in the server browser and relayed down to the client browser? Moving the problem "upstream" doesn't solve anything.
Finally: even though your intentions may be honorable (to improve client browsing experience), the ad networks will quite likely consider your server browser ad "preloader" an abomination and a violation of their ad network terms of service precisely because it interferes with their ability to track the browsing activity of the actual client.
在客户端使用 Java 插件可能会更加浪费客户端计算机的资源，因为必须将 Java 插件加载到浏览器中，这通常需要几秒钟的时间。
请记住，Java 0day 漏洞在野外存在规律性 (http://java-0day.com/< /a>）。建议在所有 Web 浏览器中禁用 Java 插件。 Mac 现在默认禁用 Java 插件。此外，智能手机和平板电脑等移动设备上不存在 Java 插件。因此，您将无法向桌面浏览器之外的任何内容投放广告，并且可能只能向在公司环境之外使用的桌面浏览器投放广告。
如果延迟加载广告不可接受，您可能必须接受 DoubleClick 的现有加载时间。从合同的角度来看，广告网络不会善意地接受干扰，如果您打算直接出售您的广告库存，那么当广告商试图投放流行的富媒体广告时，您将遇到来自广告商本身的阻力。 （视频、展开式广告、插页式广告等）
您最终会花费更多的时间来尝试让您的广告模拟层完美适应出现的每种新广告类型，这比您从网站上的每千人成本费率中获得的金额要多得多。展示广告。
也许您应该重新考虑广告是否有意义，或者您的网站货币化业务模式是否需要调整。展示广告已成为一个商品市场，在您的时代构建此模拟层的成本似乎高于提高页面速度的好处以及页面速度可能带来的稍高的印象。
不过，向您关心最终用户致敬，DoubleClick 广告请求可能会真正拖累页面加载时间。我希望有人能提供一种以稳健可靠的方式推迟广告加载的方法。
Using a java plugin on client side would likely be even more wasteful of the client machine's resources, as the Java plugin must be loaded into the browser which can often take several seconds.
Keep in mind that with the regularity of Java 0-day exploits in the wild (http://java-0day.com/). The Java plugin is recommended to be disabled in all web browsers. Macs now come with Java plugins disabled by default. Also, no Java plugins exist on mobile devices such as smartphones and tablets. So you would be unable to deliver advertising to anything beside desktop browsers, and likely only the desktop browsers used outside of a corporate setting.
If lazy loading ads is not acceptable, you will likely have to accept the loading times of DoubleClick as they stand. The ad networks will not take kindly to the interference from a contractual perspective, and if you ever plan to sell your ad inventory directly, you will encounter resistance from the advertisers themselves as they attempt to deliver the in-vogue rich media ads. (videos, expandable ads, interstitials, etc)
You'll end up spending more time attempting to get your ad emulation layer perfect for every new ad type that comes along, than the amount you will ever make from the cost per thousand rates on the display advertising.
Perhaps you should reconsider if ads even make sense, or if your business model for monetizing your website needs adjustment. Display advertising has become a commodity market, and the cost of building this emulation layer in your time appears higher than the benefit of increased page speed, and the slightly higher impressions that page speed might bring.
Hats off to you for caring about your end users though, DoubleClick advertising requests can be a real drag on page loading times. I'd love for someone to come along and provide a way to defer ad loading in a robust and reliable way.