User: Password:
|
|
Subscribe / Log in / New account

advertisers will love this

advertisers will love this

Posted Nov 18, 2009 21:47 UTC (Wed) by dlang (subscriber, #313)
In reply to: advertisers will love this by jake
Parent article: Reducing HTTP latency with SPDY

true, but a large chunk of the problem with advertisements is the slowdown that they cause by just using up bandwidth.

since these are usually compressed to start with, nothing in this proposal will help with this. all that this can do is reduce the added overhead of making a request for the users that would view the advertisement anyway.


(Log in to post comments)

advertisers will love this

Posted Nov 18, 2009 23:18 UTC (Wed) by Los__D (guest, #15263) [Link]

Usually, what causes advertisements to suck the life out of the browsers, isn't bandwidth, but the adserver not answering, and the browser (for some ridiculous reason) deciding to wait for it.

advertisers will love this

Posted Nov 19, 2009 12:41 UTC (Thu) by jzbiciak (subscriber, #5246) [Link]

...which points out the other reason why this won't be as much of a problem as a couple posts up suggested: Ads quite often come from an entirely different server. For SPDY to prioritize or push ads ahead of other content, the ads and the content need to come from the same server, which would require some rearchitecting of the web.

Now, that said, if Google moves another step further, providing SPDY support to browsers through a SPDY-to-normal-HTTP caching proxy (as I suggested it might in this comment), then the ad-push concern returns.

advertisers will love this

Posted Nov 19, 2009 18:12 UTC (Thu) by Simetrical (guest, #53439) [Link]

The browser needs to wait on any <script> before it can render the rest of
the page, because the semantics of <script> have historically been
synchronous. <script>s need to be executed before later parts of the page
are rendered, or else you'll have unexpected bugs arising, because that's
not the way anyone has ever done it since <script> first existed.

Recent browsers are getting better at doing whatever they can in advance of
the actual script load -- fetching resources that they expect they'll need,
parsing, and so on. But I don't think any will actually render the rest of
the page before the script is done executing. What would happen if the
script did something like document.write("<!--")? Or if it redirected to
the different page? The user would have been shown something they were
never supposed to see according to the applicable standards.

This is one of the problems <script async> is meant to solve, incidentally,
but it won't really work for most ad scripts -- they tend to use
document.write() to output the ad. In principle you could use DOM methods
to insert the ad after the fact instead, of course. Then again, this would
mean the user could scroll right past the ad location without ever seeing
it . . .

I'm a web developer, though, and not a browser implementer, so take this
explanation with a grain of salt.

advertisers will love this

Posted Nov 27, 2009 1:03 UTC (Fri) by efexis (guest, #26355) [Link]

On your past point about DOM insertion - you can reserve space on a page and then later fill it, for many <embed>'ed ads like those in flash, this is usually already the way.

advertisers will love this

Posted Nov 20, 2009 10:25 UTC (Fri) by ballombe (subscriber, #9523) [Link]

> Usually, what causes advertisements to suck the life out of the browsers, isn't bandwidth, but the adserver not answering, and the browser (for some ridiculous reason) deciding to wait for it.

That is why my /etc/hosts carries
0.0.0.0 www.google-analytics.com
0.0.0.0 pagead2.googlesyndication.com
etc. with other adservers.

(not that google servers are the slowest to answer...)

advertisers will love this

Posted Nov 25, 2009 14:31 UTC (Wed) by marcH (subscriber, #57642) [Link]

> That is why my /etc/hosts carries
> 0.0.0.0 www.google-analytics.com
> 0.0.0.0 pagead2.googlesyndication.com
> etc. with other adservers.

Does that actually make a difference? I assumed adservers hide much better than that from AdBlock and others.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds