"Add this third tracking/analytics tool"; "Add this custom ad format here"; "Oh this partner will give us tons of money if we put this widget on the page"; "Oh let's use Brightcove video player"; "Oh let's auto-play videos"; "drive-by A/B testing"; "We don't control this third-party 2MB image", "The widget streams a 23MB .WAV file for background music that only auto-plays in mobile"; "Why build this in-house when we can just use this good third-party library?"; "Good third-party library costs too much, let's use this horrible but much cheaper one instead"; etc.
AMP allows you to tell your product manager: "Sorry! Not supported." Of course, with enough responses like this, a decision eventually comes down to not use AMP.
I like this reason. It's both a good reason for AMP to exist (albeit to solve a sad problem, with the product managers), as well as to justify not using it myself :-)
> Of course, with enough responses like this, a decision eventually comes down to not use AMP.
Perhaps. But having an external set of guidelines that relate to an all-or-nothing benefit (inclusion in Google's AMP program) seems helpful to me (from the eye of a developer who cares about bloat).
A small team of good developers could also formulate their own set of guidelines in order to avoid bloat and achieve fast loading. But those guidelines will have to be guarded by the developers against "political" forces, and there's a distinct possibility that more and more compromises will be made.
Exclusion from the AMP program provides a line in the sand, so to say.
You say that like it's a bad thing! But that's the entire point. Without a clear set of rules, almost no one makes fast pages in real life.
This is especially true when you are working in a company where a wide mix of people have competing objectives. The developers want a fast page, the designers want a pretty page, the PMs want conversion, the business folks want lots of ads, etc. It makes it nearly impossible to build something fast without clear rules.
Take a random article on the TheVerge.com as an example. I'm sure they have fantastic web developers who want the site to load quickly and they definitely know how to build beautiful pages. But check out their normal responsive page you get if you visit their site directly on your phone:
http://www.theverge.com/2016/3/15/11233030/jj-abrams-moon-sh...
Using Chrome's "Regular 2G" throttling, that page takes 19.82s to hit DOMContentLoaded and an insane 1.3 minutes to hit Load. The total mobile page weighs 2.5mb!
Now check the AMP version of that same page. You can find it by looking for the 'link rel="amphtml"' tag in the header of the page:
http://www.theverge.com/platform/amp/2016/3/15/11233030/jj-a...
Using the same Chrome throttling settings, it hits DOMContentLoaded in 802ms and Load in 33.33s. And even then, almost all of that time is spent loading fonts and (in this particular article, very poorly optimized) images.
To a mobile user, that is a way better experience - the difference between bouncing and reading. And the only difference was having "a decided-upon set of restrictions".
If the site was built from the beginning with performance in mind, we'd all benefit, no matter what we're using to view the site.
I get that it has more to do with business side of things vs. the development side of things. Lots of hands in the pot at these companies and webdevs are only one part of it.
If putting a brand on a set of techniques plus offering CDN space and serp priority gets publishers to actually build fast websites, then I am all in favor of it.
A major con against AMP in my opinion is that it is something else to learn on top of everything.
I've never understood why toddlers need training wheels on their bikes? Why don't they just bike properly in the first place?
I guess the only oversight I see in my original post is that most of the time, the webdevs aren't the ones with the final say anyway and maybe branding the restrictions will make it more palatable to publishers. It's just sad that we're at the point where it has to be done this way.
But it is telling that publishers are fine with being restricted by AMP, when they could have implemented those restrictions extremely easily on their own instead of having to be hand-held through the whole thing.
The other issue I have is that it's generally intended for mobile only. If the site was built for speed and efficiency from the ground up, it would be a fast experience everywhere
I've never understood the use of AMP, just build your normal site properly in the first place and then you won't need it. It's almost like training-wheels for learning efficiency/optimization.