Google’s AMP is a gilded cage

Ah interesting. Thanks for bringing this up. I use uBlock but didn't have any issues rendering it. Since I don't really care about the SEO/Google hosting it it might make sense to just link to my own locally hosted version to avoid the adblocking block.

i could see other apps that use a native browser preferring the AMP version. something like yelp, that lets you click through to the source page, for instance.

The catch here is that if DFP were to enforce technical standards to the extent of including performance, publishers would leave en masse. What they want from DFP (as I understand it) is hosting that just works; they don't want anyone in the way causing some ad campaigns to not get trafficked at the right time, or killed after serving for a while, or anything else. And worse, I think that you'd find that a very large number of ads wouldn't comply with any such standard - display ads aren't good, by and large. So even with a perfect offering publishers would look at the numbers and say "you know what, nevermind...turn the crappy ads back on." A pretty good approximation for publishers I've found was to say "if you give them a knob between anything and revenue, they'll turn it towards revenue." That by and large includes sacrificing user-first principles.

So one difference to your example is that viewability is desired - it's a direct metric that helps to approximate value, which advertisers like. But performance is not. Users cannot generally tell _which_ ad made their browser lag, or that it wasn't the page's fault. The best you could possibly do is to measure long-term-value, but because any given publisher only gets a tiny fraction of a user's time, and any single ad that much less, my recollection is that the LTV isn't really moved at all regardless of experience. It's going to take an industry-wide shift to move the needle here.

HTTPS is a closer comparison, except that it takes big parties again to force the issue - it's user positive but revenue negative and lots of work. So it comes back to the issue of who can get this change pushed through, without some party (pubs, advertiser, or users) just walking away. Look at examples of where/why HTTPS has been adopted if you want to see more.

AMP may get to that point, we'll see, but I like it as a possibility. And it's doing more to simply not show ads if they're taking too many resources (with browser assistance iirc? Delay loading? Don't recall what I've read), which is good in other ways.

Which reminds me, that's another plausible solution that I'm liking...if browsers can be more involved in aborting rendering bad iframe'd content, or preventing them from janking the page, etc, then the burden is squarely on the advertisers to fix or suffer reduced impact, irrespective of publisher/ad network. That's great, it puts the incentives cleanly where they should be. So I'm also hopeful that browsers can push through positive results here. Doesn't help with content badness (only latency and other such browser-measurable "bad ad" issues), but is a great starting place. (And to be fair, I don't think AMP solves for content badness either).

> pre fetching is dangerous given you don't know if the origin can support it or not.

That's not true unless your site already has a huge exposed vulnerability. It's also irrelevant to the discussion of how a search engine could provide an opt-in feature which you could choose to enable.

> AMP is faster than the alternative.

Do you have any data to support that assertion? Remember, you're replying to a thread about possible standards-based alternatives but Google has never implemented that, so we all we can say is that AMP is faster than not doing anything at all. We don't have any data saying that the solution to web performance problems is a bunch of proprietary markup and JavaScript. I've certainly found AMP to be slower as often as it is faster, because the proprietary markup means you have a bunch of resource requests which will be delayed until ~125KB of JavaScript loads and executes whereas a standard tag would have started the same transfer without that delay (see e.g. https://www.webpagetest.org/video/compare.php?tests=161129_X... where the non-AMP version starts rendering over a second faster on an iPhone 6 over LTE).

As an example of how this could be different, imagine if Google simply started aggressively using measured page-load times and transfer size with the same weight they currently give to AMP, giving all publishers the same incentive to reduce things like the massive amount of ad-related JavaScript they traditionally serve, and started serving rel=dns-prefetch/preconnect/preload hints for the top-n search results (or on mouse hover states, etc.). That might not be quite as fast as the best-case for AMP but I suspect it would rapidly get into the territory where the user benefit is diminishing compared to the benefits of not dictating a restricted tech stack.

That last part is pretty important because AMP is not without cost: it breaks the sharing UX on mobile devices, desktop users get a mobile-optimized page which isn't as good for their devices, and most importantly it limits you to the subset of functionality which they choose to implement. It seems risky to push everyone towards a single company's view of how the web should work rather than allowing independent experimentation and optimization for different types of content and users.

I hate to +1 these things but I have had similar experiences with 0 control over the ads that were showing up on a platform. It was a single page app and performance was a huge deal. Often ads didn't even load because of the quality.

Maybe it shouldn't be DFP forcing things as I said, but I think if the controls even existed for publishers it might mean that they tune things to be pleasant for their users such that they get more impressions.