AMP is just a subset existing web technologies. It's entirely possible to build a page that loads just as fast or faster, without loading the AMP scripts, if you so choose. But AMP greatly simplifies the process, which is what developers need, and the script enforces the limitations necessary to make the page load and render quickly, which users love.
Right now AMP is under heavy development and lots of changes are being made very quickly. That mandatory script loads other resources from the same domain on an as-needed basis, which is a crucial aspect of how AMP is designed to work. I don't know if the v1 release will include a distribution package for self-hosting, but it's not too much of a stretch to believe they've decided to go with a central CDN just to simplify development for the early stages of the project.
At any rate, this is no worse in principle than the Google Analytics scripts everybody includes on every page everywhere, so it's mostly just a bunch of FUD.
The project is open source and open to contributions from anyone. Every single time this comes up the project contributors have said that they will gladly modify <amp-ad> to support any network they can. They're also constantly developing new <amp-X> components to fill in the gaps for other embeddable services. You want <amp-vk>? Submit a PR! Open an issue! It's open source!
And please, please tell me what's wrong with using e.g. <amp-youtube>? It's just a web component! All it does is what you want it to do, and if it doesn't do what you want then either you shouldn't do that, or you can just submit a PR.
The whole point of AMP is 1) make sure the developer doesn't do anything that'll make the page load unnecessarily slowly or repaint/relayout unnecessarily and 2) make it way easier for the developer to accomplish #1 because all you have to do is type <amp-youtube>.
AMP is no different from, say, jQuery, or React, or Angular. It's a different way of doing things, but it's not a "gatekeeper" on the web. It's just another option, one more tool in your belt, if you so choose.
> The project is open source and open to contributions from anyone. Every single time this comes up the project contributors have said that they will gladly modify <amp-ad> to support any network they can. They're also constantly developing new <amp-X> components to fill in the gaps for other embeddable services. You want <amp-vk>? Submit a PR! Open an issue! It's open source!
Who gets to decide which pull requests get accepted? What if I wanted to create an amp component for my network with a userbase of two people?
I don't see what makes it different from any other open source project. Of course it's going to have technical leads and core committers, it's not like you can go force a PR merge on jQuery trunk any time you please. I'm aghast that you would even suggest such a thing.
And CLA's aren't fun, but they're hardly new, either.[1]
If you don't like that it's Google, that's fine, but at least be honest with yourself about it. But unless you've submitted a PR or can cite a PR (on any Google OSS repo at all) that they've rejected purely on the basis that Google is somehow doing wrong by the developers, then what are we even talking about?
To me the problematic part that makes it different to at least some open source projects is that all those technical leads and core committers are apparently employed by Google (and working on company time, I assume). That could mean Google, and Google alone, gets to decide where it goes.
Honestly, the only criticism I'm hearing over and over is "because Google", and considering their track record with Chrome, Android, Angular, Polymer, Go, and literally hundreds of other open-source projects, I'm perfectly okay with that.
Right. Looking at this whole thing humorously, it seems like the uproar is over AMP is developers getting angry at a tool designed to prevent them from shooting themselves in the foot, for removing their ability to shoot themselves in the foot :)
Open Source does not really mean better and open. The role of Google as Gatekeeper remains. Android is Open source too but how many non-Google controlled Android phones do you see on market ?
Open source means there's no such thing as a "Gatekeeper". As with every other open source project ever, you can just fork it. How many open source projects today are forked from their original repo because a large enough portion of the users and developers disagreed with the ones in control?
Honestly, this argument is just silly. https://developers.google.com/open-source/projects read that list and name one time where Google abused the control they had over the project they created. They already have a good track record for open source. This "gatekeeper" nonsense is just a bunch of unnecessary FUD.
> At any rate, this is no worse in principle than the Google Analytics scripts everybody includes on every page everywhere, so it's mostly just a bunch of FUD.
This is a rather blind comment. Not everyone uses Google Analytics and those that do have actively chosen to do so. Plus, Google Analytics is inherently tied to Google services so there are no privacy or control issues.
AMP seems to be intended more as an open toolkit more akin to Bootstrap or jQuery. Requiring that AMP's scripts be loaded from a Google CDN is like saying you can't load jQuery or Bootstrap from anywhere but their CDNs. Some developers want to strictly control where their code is hosted for various reasons and Google isn't allowing them to do that.
Some developers also want to control who can and can't log their visitors. Google isn't allowing them to do that in this case. Anything that loads that script can be logged by Google.
Sometimes the "fights" between these companies, reminds me of the Democratic and Republican parties in the US.
When one company such as Facebook decides to launch a very privacy-intrusive service, people are like "Oh, no! We must support Google's very privacy intrusive-service so Facebook doesn't win!" - just like people saying "we must not let the pro-corporate Republicans win, so we must support the pro-corporate Democrats".
It's such a race to the bottom. How about we reject both? (in both cases).
The nice thing about a project like AMP is that it's a slow-moving target & all AMP pages fetch from the same URLs. That makes it easy for a tool like Decentraleyes to cache all of the AMP assets, resulting in even more speed & a privacy benefit.
I've got Ublock Origin and funnily enough, the LongReads example AMP page loads only marginally faster than the "full" one. I don't understand why people can't just remove all of the crap from their main pages rather than relying on this Google-sponsored equivalent?
Can you elaborate? From what I can tell, AMP makes use of on-demand resource loading, which HTTP/2 prefers over bundled resources thanks to multiplexing.
From what I understood, there are a few contradictions like splitting up assets (preferable in HTTP/2) as opposed to concatenating/merging them (preferable in AMP). Perhaps I misunderstood
AMP encourages you to keep your assets separated, so you only load the bits you need. If a page is going to use <amp-youtube> you'll have to include the appropriate script tag for that component in the page, for example.
Actually not at all. AMP is specifically designed with HTTP/2 in mind and takes full advantage of it. E.g. it loads articles, scripts, images, fonts, etc. through a single HTTP 2 tunnel.
I'm assuming this TC article thinks its audience is WordPress content-creators and not just media companies? Here's its first acknowledgement of tradeoffs (or rather, that the tradeoffs are no big deal)
> And you don’t lose much as AMP markup supports a wide range of features. For instance, AMP has worked with ad networks, such as Outbrain, AOL, OpenX, DoubleClick and AdSense, to create optimized tags for mobile pages. So you can still put ad tags in your AMP-enabled pages. Similarly, you can add analytics tools. But these JavaScript calls will be optimized.
I've never been in the work of dealing with ads though now that I think about it, that probably is one of the key things that the average, devoted content-creator would care about.
But I do think this is a bit underplayed:
> As for all the things that usually slow down web pages today, such as embeds, JavaScript-heavy content or Flash, WordPress strips out this content from the AMP pages. Comments are also omitted by default.
So...YouTube videos and things like embeddable Google Maps are not allowed? I was assuming "no"...because that is Google's bottom line...(also, they're whitelisted in the spec's extensions [1]). And I know the anti-comments-section sentiment is strong in the media industry, but kind of weird to see "oh yeah, no comments" as an afterthought. I'm assuming that means no WordPress comments (which come built-in with a standard WP install)...but what about Disqus and Facebook? There are more than a few media companies in which comment sections are more than trivially important.
No, your WP site supports AMP if you haven't bothered to do anything custom and don't care about anything other than standard design.... in which case you have work ahead of you.
Definitely—but far less work than starting from scratch. The goal was not to make it 100% plug-and-play for everyone, because that would be...impossible. :)
Most administrators are lazy. If you write software for thousands or millions of users, sane defaults are a must. I find it useful to keep Saint-Exupéry in mind: "It seems that perfection is attained not when there is nothing more to add, but when there is nothing more to remove."
Let's look at the first lines of WordPress's default template:
Why bother with xmlns if it's not well-formed XML anyway?
Why dir and lang if you don't really know what language the content is in? We now have the funny situation that most non-English pages wrongly declare lang="en-US" because W3C evangelists told template authors that lang is really important, rendering the attribute completely useless.
Oops, sorry, I was looking at the HTML of the theme previewer instead of the theme itself. With regard to WordPress, only my "XHTML friends network" point remains valid. Concerning web development in general, I have seen way too much cargo cult boilerplate, too many hardcoded lang attributes, etc.
I checked back to Twenty Fourteen and didn't see the lines you referenced. Regardless, it's a silly argument, the default themes are "reference" themes, meant to show off all the features WordPress offers and of course don't represent all WP themes.
A large portion of said code comes from themes and plugins. Especially the latter, which seem to use (abuse) wp_enqueue_script and wp_enqueue_style like it's going out of fashion.
A significant amount of WordPress related overhead would disappear if developers would keep resources to a minimum and provide a way to turn them off without writing additional code. Or if there was some built in system that tried to bundle together the CSS and JS files.
"More than likely, simply installing the WordPress plugin will not be enough, and you will have to go through and validate all of the pages you’d like to benefit from Accelerated Mobile Pages.
Depending on how your articles are formatted, you may need to make some changes in order to get the AMP pages to validate. The most common problems I personally experienced were with specifying height and width attributes for images and correcting old YouTube embed codes that weren’t using https."
This is all about ads. "A goal of the Accelerated Mobile Pages Project is to ensure effective ad monetization on the mobile web while embracing a user-centric approach." It's mostly about optimizing some very inefficient ad delivery systems. If you're just displaying text without ads, you don't need AMP.
That's only one benefit of AMP. Another is ensuring that all of the excessive and crappy Javascript that many sites run isn't used -- we expect to be able to do a consistent and better job archiving AMP in the Wayback Machine than arbitrary pages with arbitrary javascript.
> Another is ensuring that all of the excessive and crappy Javascript that many sites run isn't used
While I wouldn't argue that there isn't a massive amount of god-awful javascript being written today, but why does a third party, private company get to determine what is or isn't "excessive and crappy" on someone's own website? This sounds like a slippery slope to me.
I'm curious what long term ad click rates are going to be for publishers that use AMP. The user experience is very reader-centric. When you do a search and click on an AMP-enabled page (at the top of the search results) you can then swipe left and scroll to the next AMP-enabled page. It's a strong incentive to just read the headline of an article then swipe away. This is great for readers but bad for publishers since they'll get fewer clicks and less time spent on the site from users who come from google. For those of us who just skim the headlines we'll never even see an ad.
google search will funnel users to amp-enabled pages, so anybody /not/ on the amp train will suffer. In that way it is a walled garden. It's google's version of becoming a portal.
Isn't AMP intended to compete with the likes of Facebook Instant Pages?
At the same time, Google thrives by returning high quality search results. It also depends heavily on web over native. For the web to stay relevant on mobile, it needs to meet some minimum expectations met by native experiences.
I frequently find fault with the websites I arrive at through Google because of shitty performance and irritatingly obtrusive advertising. There's more to mobile friendliness than a responsive CSS grid system and publishers need to realise that.
I actually found both useful. Both target different audiences and provide different perspective on the issue. I probably wouldn't click through to 11167428 if I didn't use WordPress; whereas I wouldn't click through to 11167478 if I had already seen the AMP announcement last year ("I know about AMP; when will there be stuff I can download/install/play with?").
Benchmark time! For the example article mentioned in the article [1],
- Default page: 74 requests, 1983kB, 2.98 in Firefox
- Adding amp/ at the end: 14 requests, 464kB, 0.51s in Firefox
Good! And sad it's not the default :-/
EDIT: after proper reading of the consequences, of course it's not the default. Indulgent readers will correct the above sentence as "hope we're moving to this kind of performance by default."
The official WordPress AMP plugin doesn't currently offer much. It seems to be a simple install-and-go plugin with very little configurations.
There are some developers working on a few other plugins. I found this PageFrog plugin https://wordpress.org/plugins/pagefrog/ which AMPs your page but includes a bunch of other stuff.
Particularly PageFrog comes bundled with Facebook Instant Articles support along with configurations for ads and analytics, which seems to be missing from the official WP plugin.
51 comments
[ 3.7 ms ] story [ 110 ms ] threadRight now AMP is under heavy development and lots of changes are being made very quickly. That mandatory script loads other resources from the same domain on an as-needed basis, which is a crucial aspect of how AMP is designed to work. I don't know if the v1 release will include a distribution package for self-hosting, but it's not too much of a stretch to believe they've decided to go with a central CDN just to simplify development for the early stages of the project.
At any rate, this is no worse in principle than the Google Analytics scripts everybody includes on every page everywhere, so it's mostly just a bunch of FUD.
Want to embed content from another site? Great! You can choose from <amp-twitter>, <amp-facebook>, <amp-instagram>, <amp-pinterest>, or <amp-youtube>.
Building an advertising startup? Hooray! I hope you're one of the dozen whitelisted ad networks that <amp-ad> allows.
In Russia or China? Maybe Google will deign to implement <amp-vk> and <amp-sinaweibo> if we're sufficiently humble.
This is not the Web I want.
And please, please tell me what's wrong with using e.g. <amp-youtube>? It's just a web component! All it does is what you want it to do, and if it doesn't do what you want then either you shouldn't do that, or you can just submit a PR.
The whole point of AMP is 1) make sure the developer doesn't do anything that'll make the page load unnecessarily slowly or repaint/relayout unnecessarily and 2) make it way easier for the developer to accomplish #1 because all you have to do is type <amp-youtube>.
AMP is no different from, say, jQuery, or React, or Angular. It's a different way of doing things, but it's not a "gatekeeper" on the web. It's just another option, one more tool in your belt, if you so choose.
Who gets to decide which pull requests get accepted? What if I wanted to create an amp component for my network with a userbase of two people?
See https://medium.com/@cramforce/2016-will-be-the-year-of-concu... for the long game as to how to build such things in AMP without iframes.
The project is exclusively governed by three Google employees, listed at https://github.com/ampproject/amphtml/blob/master/GOVERNANCE..., all contributions are at their discretion.
All contributors must sign a legally binding licensing agreement with Google which includes a patent grant, per https://github.com/ampproject/amphtml/blob/master/CONTRIBUTI....
The Web is powerful because you don't have to ask permission. AMP is not cut from that cloth.
And CLA's aren't fun, but they're hardly new, either.[1]
If you don't like that it's Google, that's fine, but at least be honest with yourself about it. But unless you've submitted a PR or can cite a PR (on any Google OSS repo at all) that they've rejected purely on the basis that Google is somehow doing wrong by the developers, then what are we even talking about?
[1] https://en.wikipedia.org/wiki/Contributor_License_Agreement#...
Right. Looking at this whole thing humorously, it seems like the uproar is over AMP is developers getting angry at a tool designed to prevent them from shooting themselves in the foot, for removing their ability to shoot themselves in the foot :)
http://wiki.cyanogenmod.org/w/Devices
Open source means there's no such thing as a "Gatekeeper". As with every other open source project ever, you can just fork it. How many open source projects today are forked from their original repo because a large enough portion of the users and developers disagreed with the ones in control?
Honestly, this argument is just silly. https://developers.google.com/open-source/projects read that list and name one time where Google abused the control they had over the project they created. They already have a good track record for open source. This "gatekeeper" nonsense is just a bunch of unnecessary FUD.
And wait for google to accept it at their own discretion. That's exactly what a gatekeeper is.
This is a rather blind comment. Not everyone uses Google Analytics and those that do have actively chosen to do so. Plus, Google Analytics is inherently tied to Google services so there are no privacy or control issues.
AMP seems to be intended more as an open toolkit more akin to Bootstrap or jQuery. Requiring that AMP's scripts be loaded from a Google CDN is like saying you can't load jQuery or Bootstrap from anywhere but their CDNs. Some developers want to strictly control where their code is hosted for various reasons and Google isn't allowing them to do that.
Some developers also want to control who can and can't log their visitors. Google isn't allowing them to do that in this case. Anything that loads that script can be logged by Google.
Certainly not FUD.
When one company such as Facebook decides to launch a very privacy-intrusive service, people are like "Oh, no! We must support Google's very privacy intrusive-service so Facebook doesn't win!" - just like people saying "we must not let the pro-corporate Republicans win, so we must support the pro-corporate Democrats".
It's such a race to the bottom. How about we reject both? (in both cases).
The nice thing about a project like AMP is that it's a slow-moving target & all AMP pages fetch from the same URLs. That makes it easy for a tool like Decentraleyes to cache all of the AMP assets, resulting in even more speed & a privacy benefit.
> And you don’t lose much as AMP markup supports a wide range of features. For instance, AMP has worked with ad networks, such as Outbrain, AOL, OpenX, DoubleClick and AdSense, to create optimized tags for mobile pages. So you can still put ad tags in your AMP-enabled pages. Similarly, you can add analytics tools. But these JavaScript calls will be optimized.
I've never been in the work of dealing with ads though now that I think about it, that probably is one of the key things that the average, devoted content-creator would care about.
But I do think this is a bit underplayed:
> As for all the things that usually slow down web pages today, such as embeds, JavaScript-heavy content or Flash, WordPress strips out this content from the AMP pages. Comments are also omitted by default.
So...YouTube videos and things like embeddable Google Maps are not allowed? I was assuming "no"...because that is Google's bottom line...(also, they're whitelisted in the spec's extensions [1]). And I know the anti-comments-section sentiment is strong in the media industry, but kind of weird to see "oh yeah, no comments" as an afterthought. I'm assuming that means no WordPress comments (which come built-in with a standard WP install)...but what about Disqus and Facebook? There are more than a few media companies in which comment sections are more than trivially important.
[1] https://github.com/ampproject/amphtml/blob/master/extensions...
I develop for a dozen or more totally custom Wordpress sites for my job and the effect this will have on us is precisely zero.
More importantly, this is a band-aid fix for the problem.
Oh hey let's load up your webpages with all this cr*p by default, tons of javascript, css, external files, fonts, headers, footers useless markup.
Oh hey, let's use this plugin to strip all that out.
How about not putting it in there in the first place.
Let's look at the first lines of WordPress's default template:
Why bother with xmlns if it's not well-formed XML anyway?Why dir and lang if you don't really know what language the content is in? We now have the funny situation that most non-English pages wrongly declare lang="en-US" because W3C evangelists told template authors that lang is really important, rendering the attribute completely useless.
What the heck is profile="http://gmpg.org/xfn/11" supposed to do?
As for the "lang" attribute, it is set to the language chosen when WordPress was installed.
<!DOCTYPE html> <html lang="en" class="no-js"> <head>
I checked back to Twenty Fourteen and didn't see the lines you referenced. Regardless, it's a silly argument, the default themes are "reference" themes, meant to show off all the features WordPress offers and of course don't represent all WP themes.
A significant amount of WordPress related overhead would disappear if developers would keep resources to a minimum and provide a way to turn them off without writing additional code. Or if there was some built in system that tried to bundle together the CSS and JS files.
http://searchengineland.com/get-started-accelerated-mobile-p...
"More than likely, simply installing the WordPress plugin will not be enough, and you will have to go through and validate all of the pages you’d like to benefit from Accelerated Mobile Pages.
Depending on how your articles are formatted, you may need to make some changes in order to get the AMP pages to validate. The most common problems I personally experienced were with specifying height and width attributes for images and correcting old YouTube embed codes that weren’t using https."
While I wouldn't argue that there isn't a massive amount of god-awful javascript being written today, but why does a third party, private company get to determine what is or isn't "excessive and crappy" on someone's own website? This sounds like a slippery slope to me.
google search will funnel users to amp-enabled pages, so anybody /not/ on the amp train will suffer. In that way it is a walled garden. It's google's version of becoming a portal.
How does google make money off of this?
Isn't AMP intended to compete with the likes of Facebook Instant Pages?
At the same time, Google thrives by returning high quality search results. It also depends heavily on web over native. For the web to stay relevant on mobile, it needs to meet some minimum expectations met by native experiences.
I frequently find fault with the websites I arrive at through Google because of shitty performance and irritatingly obtrusive advertising. There's more to mobile friendliness than a responsive CSS grid system and publishers need to realise that.
- Default page: 74 requests, 1983kB, 2.98 in Firefox
- Adding amp/ at the end: 14 requests, 464kB, 0.51s in Firefox
Good! And sad it's not the default :-/
EDIT: after proper reading of the consequences, of course it's not the default. Indulgent readers will correct the above sentence as "hope we're moving to this kind of performance by default."
[1] http://blog.longreads.com/2016/02/18/the-freelancers-roundta...
There are some developers working on a few other plugins. I found this PageFrog plugin https://wordpress.org/plugins/pagefrog/ which AMPs your page but includes a bunch of other stuff.
Particularly PageFrog comes bundled with Facebook Instant Articles support along with configurations for ads and analytics, which seems to be missing from the official WP plugin.