8 ms·

Accelerated Mobile Pages Project

173 points by cbowal 11y ago

cbowal 11y ago
The Guardian sample AMP page: With AMP: http://www.theguardian.com/science/2015/oct/07/lindahl-modrich-and-sancar-win-nobel-chemistry-prize-for-dna-research/amp http://www.theguardian.com/science/2015/oct/07/lindahl-modri... Without AMP: http://www.theguardian.com/science/2015/oct/07/lindahl-modrich-and-sancar-win-nobel-chemistry-prize-for-dna-research http://www.theguardian.com/science/2015/oct/07/lindahl-modri...
- djrogers 11y ago
  Odd, the second page loaded much faster for me...
  - on_ 11y ago
    Which page did you click first?
- solidpy 11y ago
  No flash, no sidebars, no bottom bars, no comments, a total of 6 requests vs 98. Of course it loads faster. And looks better. This is the way the web should be.
  - julien 11y ago
    Exactly! The WEB! Not yet another format that a small percentage of people will ever use but that everybody else will have to deal with for centuries.
    - bryanlarsen 11y ago
      AMP is a subset of HTML.
      - cpeterso 11y ago
        AMP : HTML :: asm.js : JavaScript?
        callumlocke 11y ago
        That's a good analogy (as long as you mean "HTML" as a banner term to include the HTML spec and associated specs like CSS and Custom Elements [1]). • AMP is a subset of HTML. • Any normal HTML engine can, therefore, render any AMP file, without needing to know about the AMP spec. • It's also possible to make an engine that specialises in rendering AMP (either exclusively, or by switching to a faster mode when it detects the file is just AMP). • Even in normal HTML engines, AMP files will generally be fast because they avoid 'slow' parts of HTML. The above points all hold true if you switch the terms to JavaScript and asm.js. Where the analogy falls short: • It's easy to write AMP by hand, but asm.js is really only meant to be generated by a compiler. • Obviously, what is meant by 'fast' is very different in each case. In HTML:AMP, it's about things like reducing network usage, and avoiding layout thrashing by requiring up-front declarations of image dimensions, etc. In JS:asm.js, it's about making compiler optimisations possible so code can execute faster. Note: AMP does create extra elements, like `<amp-img>`, but these are legit uses of the Custom Elements spec. You can see these elements rendering correctly in Chrome. [2] [1] http://w3c.github.io/webcomponents/spec/custom/ http://w3c.github.io/webcomponents/spec/custom/ [2] https://www.ampproject.org/how-it-works/ https://www.ampproject.org/how-it-works/
      - callahad 11y ago
        s/subset of/overlapping set with/ AMPHTML whitelists a handful of HTML tags, but adds a bunch of its own custom elements, like <amp-instagram>, <amp-img>, and <amp-ad> on top. It's neither a subset nor a superset of HTML in the common understanding of those terms.
        cramforce 11y ago
        Custom elements are a thing in HTML. Using them doesn't make it a superset. http://w3c.github.io/webcomponents/spec/custom/ http://w3c.github.io/webcomponents/spec/custom/
- AdmiralAsshat 11y ago
  So the AMP page looks great on a mobile device, but am I the only one that thinks we don't have enough emphasis on the desktop side of "mobile-friendly" styling? I'm reading this page on a 24" monitor, and literally 2/3rds of the page is whitespace. Why isn't more of that space being filled with text?
  - randomguy7788 11y ago
    hey would you mind linking me? just unsure if you're talking about the landing page or the how-to page i work for the amp team and would love to fix it and give our marketing site some love.
    - cbowal 11y ago
      I'm guessing he's talking about The Guardian article linked to above with AMP. The AMP site looks great to me on a large display.
    - AdmiralAsshat 11y ago
      Hi there! Thanks for taking the time to reply. To be clear, I was referring to the AMP version of the Guardian page from the parent comment, so that would probably be outside of your domain to fix. But to show what I'm talking about, here's how the page looks on my desktop in Chrome: https://imgur.com/OGy3ltz https://imgur.com/OGy3ltz Again, that just seems like wasted real-estate.
      - randomguy7788 11y ago
        gotcha thanks for clarifying!
      - what_ever 11y ago
        I actually would prefer the page this way while reading a text article. They want to cut down on the sidebars to make the page faster and only load the main content. And making the content wider just makes more difficult to read. I often lose track of the lines.
  - 11y ago
- imaginenore 11y ago
  Both are very fast, especially on the second load.
IanCal 11y ago
I've raised an issue on the repo but I'm not a fan of <!doctype html> <html amp> I'm not sure it's actually valid. Also, these pages seem to be served just with text/html, what's the best way of me returning this format rather than a full webpage for the same resource? Isn't this a perfect use-case for content type negotiation?
- cramforce 11y ago
  It isn't valid technically HTML but custom attributes aren't really that unheard of. Certainly there are no known user agents that have even close to a problem with it. As to discovery: You use a link rel=amphtml tag on the canonical and then point the AMP file back via a link rel=canonical They can, of course, be the same file if your AMP file is the canonical.
  - IanCal 11y ago
    > It isn't valid technically HTML but custom attributes aren't really that unheard of. Certainly there are no known user agents that have even close to a problem with it Is it worth having a doctype then? I don't see the logic in adding a description of a validator you then deliberately break. > As to discovery: You use a link rel=amphtml tag on the canonical and then point the AMP file back via a link rel=canonical Ah thanks. I'm not a huge fan of having two urls for the same resource, but this is at least some way of linking things.
    - skybrian 11y ago
      The doctype is the standard way to turn off quirks mode in some browsers: https://developer.mozilla.org/en-US/docs/Quirks_Mode_and_Standards_Mode https://developer.mozilla.org/en-US/docs/Quirks_Mode_and_Sta...
      - IanCal 11y ago
        Hmm. Specifying an incorrect validator to change a rendering mode in a specific set of browsers feels... well pretty nasty. It feels like the "old days".
bb101 11y ago
The spec: https://github.com/ampproject/amphtml/blob/master/spec/amp-html-format.md https://github.com/ampproject/amphtml/blob/master/spec/amp-h... SVG tags are banned. Isn't this taking the web a little backwards, seeing as interactive components like D3.js won't be supported?
- cramforce 11y ago
  Doc bug. Github issue is here https://github.com/ampproject/amphtml/issues/96 https://github.com/ampproject/amphtml/issues/96 Fixing right now.
- dvoytenko 11y ago
  SVGs are 100% supported with very few restrictions.
  - bb101 11y ago
    Thanks for clarifying. Happy to see SVG will be included, especially after so many years of IE8- not supporting it.
- 1wheel 11y ago
  No javascript, so no d3 on the page or any interactive graphics that can't be stuffed into an iframe. >One thing we realized early on is that many performance issues are caused by the integration of multiple JavaScript libraries, tools, embeds, etc. into a page. This isn’t saying that JavaScript immediately leads to bad performance, but once arbitrary JavaScript is in play, most bets are off because anything could happen at any time and it is hard to make any type of performance guarantee. With this in mind we made the tough decision that AMP HTML documents would not include any author-written JavaScript, nor any third-party scripts. https://www.ampproject.org/how-it-works/ https://www.ampproject.org/how-it-works/ http://www.niemanlab.org/2015/10/get-ampd-heres-what-publishers-need-to-know-about-googles-new-plan-to-speed-up-your-website/ http://www.niemanlab.org/2015/10/get-ampd-heres-what-publish...
applecore 11y ago
Shouldn't this technology work just as well for accelerating non-mobile web pages?
- dvoytenko 11y ago
  It does. However, the benefit is much more obvious on mobile given the CPU/memory and bandwidth constraints.
  - noir_lord 11y ago
    Not sure how long those constraints will matter though, phones get faster and faster, bandwidth increases and webassembly is on the horizon, this could end up like wap.foo.com all over again.
    - sigmar 11y ago
      CPU and bandwidth will always matter. Once those restraints aren't an issue for phones, people will want webpages to load on their watch.
    - dvoytenko 11y ago
      That's exactly what I said 5 years ago.
    - Raphael 11y ago
      The problem with mobile is the ping.
matthewmacleod 11y ago
I've thought about it, but I'm obviously missing the point completely here. Can't publishers already create high-performance web pages using non-bastardized HTML? Aren't the vast majority of performance issues on the mobile web due to publishers misusing analytics and advertising, rather than anything that would be solved by this project?
- cbowal 11y ago
  Part of AMP is caching on Google's servers (and others). That can't quite be done individually.
  - matthewmacleod 11y ago
    I guess I'm not really seeing why that's the case, though; what prevents 'Google and others' from providing caching existing web content, subject to publishers making their content effectively cacheable?
    - cramforce 11y ago
      Since this exclusively uses web tech there is absolutely nothing publishers cannot do today. A big problem is that they don't and AMP is as much about fixing that as about technology.
  - niutech 11y ago
    Google has provided PageSpeed Service for a long time.
    - cpeterso 11y ago
      Google shut down the PageSpeed Service on 2015-08-03: https://developers.google.com/speed/pagespeed/service/Deprecation https://developers.google.com/speed/pagespeed/service/Deprec...
- lukasb 11y ago
  AMP pages can also only use Javascript as part of web components that have been added to the open source AMP project.
pranaya_gh 11y ago
Google says these will be the areas of focus on the AMP project: (from http://googlepolicyeurope.blogspot.com/2015/10/introducing-amp-project-for-faster-open.html http://googlepolicyeurope.blogspot.com/2015/10/introducing-a...): 1)Content: Publishers increasingly rely on rich content like image carousels, maps, social plug-ins, data visualizations and videos to make their stories more interactive and stand out. 2)Distribution: Publishers want people to enjoy the great journalism they create anywhere and everywhere, so stories or content produced in Spain can be served in an instant across the globe in say Chile. 3)Advertising: Ads help fund free services and content on the web. It looks like google is encouraging publishers to join its initiative in the same way how it herded everyone to get "responsive".
- on_ 11y ago
  Link is 404. Initially I was turned off by this, but maybe it makes sense. They need to save advertising for their business and ads cost users a lot of money on mobile bandwith so hopefully that will change. Slow load times and much less content control than on a computer have made mobile painful. If they don't fix it, content blockers will just stop them, and if a site tries to override it, people will stop going to it.
- gorhill 11y ago
  > Ads help fund free services and content on the web. "free" is incorrect, "obfuscated costs to the users" is more accurate.
ziles88 11y ago
Does this not make anyone else queasy? This is such a rabbit hole. Not to mention they list all these major companies on their homepage implying they're using AMP when it looks like the project only started early-mid summer. Seems a bit deceptive trying to oversell people into adopting it when they barely know if it works or wont be superseded shortly. Frustrating when big companies do this in open source.
- cromwellian 11y ago
  It's standard web tech that renders in any browser, why is it queasy? This is basically asm.js-style "subset a spec and adhere to a convention and get better performance" This works in mobile Safari and doesn't require updating any browsers. It's really just best practices rolled into a kit.
- DanBC 11y ago
  I would much rather people just removed bloat from their websites. Most newspapers are crammed with crud that provides zero value to me.
gorhill 11y ago
I could not find any entry in the FAQ about how this new way of delivering web pages will negatively affect users who have made the conscious choice to reduce their privacy exposure through the express blocking of undesirable 3rd parties. For example, if I block network requests to Facebook everywhere by default, I feel confident that my IP address does not show up in the logs of Facebook's servers. Blocking those 3rd parties on web pages is what actually contributes best to make web pages load much faster. I loaded the URL of the AMP-based web page posted somewhere here[1], and it does look like the ability to clearly distinguish and filter network requests based on whether they are 3rd-party is removed. I would like more details about this, because so far my understanding is that 3rd parties are becoming obfuscated with this new method of delivering web pages. I find having one entity (ampproject.org) to serve pages from various sites is quite worrisome privacy-wise. [1] https://news.ycombinator.com/item?id=10345795 https://news.ycombinator.com/item?id=10345795
fredliu 11y ago
Interesting to see how different companies address the "mobile web sucks" problem. Google is coming from the top, pushing for "the right way to do mobile web" for the entire Internet, while Facebook is building its own walled garden of Instant Articles. Both of these strategies require the content provider to adopt yet another "standard", which takes time and money to make happen. IMOH, any of these tech company driven "push-for-a-certain-tech" is less likely to work, or at least not cost effective. In contrast, the transition to "mobile web first" is already done in China, which I would argue has the largest monetizable mobile consumer market in the world (because it's not only for hip young people. Most if not all of the grandma generation in China are getting on the internet for the 1st time, and only through WeChat on smartphones). Any user of the WeChat app knows the astonishing volume of contents shared within that social app, and all of them are mobile centric, actually it's fair to say it's "mobile only" (if you load the same URL of a shared article in WeChat on a desktop browser it'll look aweful i.e. they are not responsive, and they don't care). Yet, this transition happened not because of WeChat pushed all content providers to adopt a certain standard, but done spontaneously by each content provider, on their own to figure out what looks good on WeChat. The need to make "mobile only" content comes from the desire to reach the huge user base in WeChat, which, unlike facebook, is a "mobile only" app. The tech for making mobile friendly webpages are there for years. I would argue the reason it's not happening in the US is because of weak demand, not supply. If you have the sort of "mobile only" demand as seen in WeChat (Facebook is better positioned in that regard than Google), you'd see content providers switch to whatever suits them overnight.
- julien 11y ago
  I don't mean to defend Facebook but Instant Articles is based on RSS... hardly a walled gardern. On the other end, AMP is (yet another) re-invention of the wheel from Google.
  - cramforce 11y ago
    AMP is just HTML.
    - deleted 11y ago
niutech 11y ago
The cause is good, but AMP are overcomplicated. They rely heavily on JS, Web Components, Custom Elements. They need a polyfill for other browsers which don't support Web Components natively. They add too much bloat to HTML: custom attributes, weird <style>body {opacity: 0}</style><noscript><style>body { opacity: 1}</style></noscript>, etc. Instead, content providers should stick to plain old HTML with a small CSS script and no JS, just like RSS feeds. That would be blazing fast and backwards compatible.
- bduerst 11y ago
  Doesn't the lack of js make it impossible for content creators to provide ad-subsidized content?
  - niutech 11y ago
    No, the ads could perfectly be like: <a href="..."><img src="..." alt=".."></a> with src generated server-side.
    - bduerst 11y ago
      >perfectly That would kill any targeting, thus destroying conversion rates on cpc ads and diminishing the value of display ads. This perfect system would lead to more spammy ads, not less. Content creators aren't going to jump on that. And do exchanges actually let publishers dynamically serve ad content from server-side? Wouldn't they be able to fake impressions?
  - zukee 11y ago
    No, there is built in support for ads in the AMPHTML framework, see: https://github.com/ampproject/amphtml/blob/master/builtins/amp-ad.md https://github.com/ampproject/amphtml/blob/master/builtins/a...
antichaos 11y ago
According to the spec, AMP developers are prohibited from adding their own JS, yet they are mandated to include a <script src="https://cdn.ampproject.org/v0.js" https://cdn.ampproject.org/v0.js" async></script> tag as the last element in the <head>. I find it amusing that the JavaScript library itself is 137KB big (38KB gzipped).
- 51Cards 11y ago
  However like any CDN content, the goal would be for it to be cached if it's in common use across AMP sites. One JS module that covers a large number of content delivery sites seems like a plus to me. I can't vouch for the whole concept yet though, still reading through their spec.
  - cramforce 11y ago
    Also: We can use a Service Worker for reliable caching of the JS.
- callahad 11y ago
  <img> and <video> are also prohibited in favor of mandatory custom elements like <amp-img> and <amp-video>. ...and vendor-specific tags like <amp-youtube>, <amp-twitter>, and <amp-instagram>, the library of which is controlled by a single gatekeeper. There must be less invasive ways of achieving the same goal.
- niutech 11y ago
  Now compare this to Instant Articles spec: https://developers.facebook.com/docs/instant-articles/reference https://developers.facebook.com/docs/instant-articles/refere... No JS, no Custom Elements, just pure HTML.
brlewis 11y ago
I'd like to see detailed rationale for disabling zoom, which can be important for accessibility. maximum-scale=1,user-scalable=no
- cramforce 11y ago
  We'll most likely relax this. Related to embedding fidelity.
Someone 11y ago
So, basically, Google announced a free CDN, if you restrict yourself to a HTML/JavaScript subset that promises fast page load times for users, and invites other parties to do that, too, using the same restrictions? I also read claims that this is a move against ad-blockers. Is there some truth in that?
est 11y ago
WML anyone?

173 points by cbowal 11y ago

The Guardian sample AMP page: With AMP: http://www.theguardian.com/science/2015/oct/07/lindahl-modrich-and-sancar-win-nobel-chemistry-prize-for-dna-research/amp http://www.theguardian.com/science/2015/oct/07/lindahl-modri... Without AMP: http://www.theguardian.com/science/2015/oct/07/lindahl-modrich-and-sancar-win-nobel-chemistry-prize-for-dna-research http://www.theguardian.com/science/2015/oct/07/lindahl-modri...

djrogers 11y ago
Odd, the second page loaded much faster for me...
- on_ 11y ago
  Which page did you click first?
solidpy 11y ago
No flash, no sidebars, no bottom bars, no comments, a total of 6 requests vs 98. Of course it loads faster. And looks better. This is the way the web should be.
- julien 11y ago
  Exactly! The WEB! Not yet another format that a small percentage of people will ever use but that everybody else will have to deal with for centuries.
  - bryanlarsen 11y ago
    AMP is a subset of HTML.
    - cpeterso 11y ago
      AMP : HTML :: asm.js : JavaScript?
      - callumlocke 11y ago
        That's a good analogy (as long as you mean "HTML" as a banner term to include the HTML spec and associated specs like CSS and Custom Elements [1]). • AMP is a subset of HTML. • Any normal HTML engine can, therefore, render any AMP file, without needing to know about the AMP spec. • It's also possible to make an engine that specialises in rendering AMP (either exclusively, or by switching to a faster mode when it detects the file is just AMP). • Even in normal HTML engines, AMP files will generally be fast because they avoid 'slow' parts of HTML. The above points all hold true if you switch the terms to JavaScript and asm.js. Where the analogy falls short: • It's easy to write AMP by hand, but asm.js is really only meant to be generated by a compiler. • Obviously, what is meant by 'fast' is very different in each case. In HTML:AMP, it's about things like reducing network usage, and avoiding layout thrashing by requiring up-front declarations of image dimensions, etc. In JS:asm.js, it's about making compiler optimisations possible so code can execute faster. Note: AMP does create extra elements, like `<amp-img>`, but these are legit uses of the Custom Elements spec. You can see these elements rendering correctly in Chrome. [2] [1] http://w3c.github.io/webcomponents/spec/custom/ http://w3c.github.io/webcomponents/spec/custom/ [2] https://www.ampproject.org/how-it-works/ https://www.ampproject.org/how-it-works/
    - callahad 11y ago
      s/subset of/overlapping set with/ AMPHTML whitelists a handful of HTML tags, but adds a bunch of its own custom elements, like <amp-instagram>, <amp-img>, and <amp-ad> on top. It's neither a subset nor a superset of HTML in the common understanding of those terms.
      - cramforce 11y ago
        Custom elements are a thing in HTML. Using them doesn't make it a superset. http://w3c.github.io/webcomponents/spec/custom/ http://w3c.github.io/webcomponents/spec/custom/
AdmiralAsshat 11y ago
So the AMP page looks great on a mobile device, but am I the only one that thinks we don't have enough emphasis on the desktop side of "mobile-friendly" styling? I'm reading this page on a 24" monitor, and literally 2/3rds of the page is whitespace. Why isn't more of that space being filled with text?
- randomguy7788 11y ago
  hey would you mind linking me? just unsure if you're talking about the landing page or the how-to page i work for the amp team and would love to fix it and give our marketing site some love.
  - cbowal 11y ago
    I'm guessing he's talking about The Guardian article linked to above with AMP. The AMP site looks great to me on a large display.
  - AdmiralAsshat 11y ago
    Hi there! Thanks for taking the time to reply. To be clear, I was referring to the AMP version of the Guardian page from the parent comment, so that would probably be outside of your domain to fix. But to show what I'm talking about, here's how the page looks on my desktop in Chrome: https://imgur.com/OGy3ltz https://imgur.com/OGy3ltz Again, that just seems like wasted real-estate.
    - randomguy7788 11y ago
      gotcha thanks for clarifying!
    - what_ever 11y ago
      I actually would prefer the page this way while reading a text article. They want to cut down on the sidebars to make the page faster and only load the main content. And making the content wider just makes more difficult to read. I often lose track of the lines.
- 11y ago
imaginenore 11y ago
Both are very fast, especially on the second load.

IanCal 11y ago

I've raised an issue on the repo but I'm not a fan of <!doctype html> <html amp> I'm not sure it's actually valid. Also, these pages seem to be served just with text/html, what's the best way of me returning this format rather than a full webpage for the same resource? Isn't this a perfect use-case for content type negotiation?

cramforce 11y ago
It isn't valid technically HTML but custom attributes aren't really that unheard of. Certainly there are no known user agents that have even close to a problem with it. As to discovery: You use a link rel=amphtml tag on the canonical and then point the AMP file back via a link rel=canonical They can, of course, be the same file if your AMP file is the canonical.
- IanCal 11y ago
  > It isn't valid technically HTML but custom attributes aren't really that unheard of. Certainly there are no known user agents that have even close to a problem with it Is it worth having a doctype then? I don't see the logic in adding a description of a validator you then deliberately break. > As to discovery: You use a link rel=amphtml tag on the canonical and then point the AMP file back via a link rel=canonical Ah thanks. I'm not a huge fan of having two urls for the same resource, but this is at least some way of linking things.
  - skybrian 11y ago
    The doctype is the standard way to turn off quirks mode in some browsers: https://developer.mozilla.org/en-US/docs/Quirks_Mode_and_Standards_Mode https://developer.mozilla.org/en-US/docs/Quirks_Mode_and_Sta...
    - IanCal 11y ago
      Hmm. Specifying an incorrect validator to change a rendering mode in a specific set of browsers feels... well pretty nasty. It feels like the "old days".

bb101 11y ago

The spec: https://github.com/ampproject/amphtml/blob/master/spec/amp-html-format.md https://github.com/ampproject/amphtml/blob/master/spec/amp-h... SVG tags are banned. Isn't this taking the web a little backwards, seeing as interactive components like D3.js won't be supported?

cramforce 11y ago
Doc bug. Github issue is here https://github.com/ampproject/amphtml/issues/96 https://github.com/ampproject/amphtml/issues/96 Fixing right now.
dvoytenko 11y ago
SVGs are 100% supported with very few restrictions.
- bb101 11y ago
  Thanks for clarifying. Happy to see SVG will be included, especially after so many years of IE8- not supporting it.
1wheel 11y ago
No javascript, so no d3 on the page or any interactive graphics that can't be stuffed into an iframe. >One thing we realized early on is that many performance issues are caused by the integration of multiple JavaScript libraries, tools, embeds, etc. into a page. This isn’t saying that JavaScript immediately leads to bad performance, but once arbitrary JavaScript is in play, most bets are off because anything could happen at any time and it is hard to make any type of performance guarantee. With this in mind we made the tough decision that AMP HTML documents would not include any author-written JavaScript, nor any third-party scripts. https://www.ampproject.org/how-it-works/ https://www.ampproject.org/how-it-works/ http://www.niemanlab.org/2015/10/get-ampd-heres-what-publishers-need-to-know-about-googles-new-plan-to-speed-up-your-website/ http://www.niemanlab.org/2015/10/get-ampd-heres-what-publish...

applecore 11y ago

Shouldn't this technology work just as well for accelerating non-mobile web pages?

dvoytenko 11y ago
It does. However, the benefit is much more obvious on mobile given the CPU/memory and bandwidth constraints.
- noir_lord 11y ago
  Not sure how long those constraints will matter though, phones get faster and faster, bandwidth increases and webassembly is on the horizon, this could end up like wap.foo.com all over again.
  - sigmar 11y ago
    CPU and bandwidth will always matter. Once those restraints aren't an issue for phones, people will want webpages to load on their watch.
  - dvoytenko 11y ago
    That's exactly what I said 5 years ago.
  - Raphael 11y ago
    The problem with mobile is the ping.

matthewmacleod 11y ago

I've thought about it, but I'm obviously missing the point completely here. Can't publishers already create high-performance web pages using non-bastardized HTML? Aren't the vast majority of performance issues on the mobile web due to publishers misusing analytics and advertising, rather than anything that would be solved by this project?

cbowal 11y ago
Part of AMP is caching on Google's servers (and others). That can't quite be done individually.
- matthewmacleod 11y ago
  I guess I'm not really seeing why that's the case, though; what prevents 'Google and others' from providing caching existing web content, subject to publishers making their content effectively cacheable?
  - cramforce 11y ago
    Since this exclusively uses web tech there is absolutely nothing publishers cannot do today. A big problem is that they don't and AMP is as much about fixing that as about technology.
- niutech 11y ago
  Google has provided PageSpeed Service for a long time.
  - cpeterso 11y ago
    Google shut down the PageSpeed Service on 2015-08-03: https://developers.google.com/speed/pagespeed/service/Deprecation https://developers.google.com/speed/pagespeed/service/Deprec...
lukasb 11y ago
AMP pages can also only use Javascript as part of web components that have been added to the open source AMP project.

pranaya_gh 11y ago

Google says these will be the areas of focus on the AMP project: (from http://googlepolicyeurope.blogspot.com/2015/10/introducing-amp-project-for-faster-open.html http://googlepolicyeurope.blogspot.com/2015/10/introducing-a...): 1)Content: Publishers increasingly rely on rich content like image carousels, maps, social plug-ins, data visualizations and videos to make their stories more interactive and stand out. 2)Distribution: Publishers want people to enjoy the great journalism they create anywhere and everywhere, so stories or content produced in Spain can be served in an instant across the globe in say Chile. 3)Advertising: Ads help fund free services and content on the web. It looks like google is encouraging publishers to join its initiative in the same way how it herded everyone to get "responsive".

on_ 11y ago
Link is 404. Initially I was turned off by this, but maybe it makes sense. They need to save advertising for their business and ads cost users a lot of money on mobile bandwith so hopefully that will change. Slow load times and much less content control than on a computer have made mobile painful. If they don't fix it, content blockers will just stop them, and if a site tries to override it, people will stop going to it.
gorhill 11y ago
> Ads help fund free services and content on the web. "free" is incorrect, "obfuscated costs to the users" is more accurate.

ziles88 11y ago

Does this not make anyone else queasy? This is such a rabbit hole. Not to mention they list all these major companies on their homepage implying they're using AMP when it looks like the project only started early-mid summer. Seems a bit deceptive trying to oversell people into adopting it when they barely know if it works or wont be superseded shortly. Frustrating when big companies do this in open source.

cromwellian 11y ago
It's standard web tech that renders in any browser, why is it queasy? This is basically asm.js-style "subset a spec and adhere to a convention and get better performance" This works in mobile Safari and doesn't require updating any browsers. It's really just best practices rolled into a kit.
DanBC 11y ago
I would much rather people just removed bloat from their websites. Most newspapers are crammed with crud that provides zero value to me.

gorhill 11y ago

I could not find any entry in the FAQ about how this new way of delivering web pages will negatively affect users who have made the conscious choice to reduce their privacy exposure through the express blocking of undesirable 3rd parties. For example, if I block network requests to Facebook everywhere by default, I feel confident that my IP address does not show up in the logs of Facebook's servers. Blocking those 3rd parties on web pages is what actually contributes best to make web pages load much faster. I loaded the URL of the AMP-based web page posted somewhere here[1], and it does look like the ability to clearly distinguish and filter network requests based on whether they are 3rd-party is removed. I would like more details about this, because so far my understanding is that 3rd parties are becoming obfuscated with this new method of delivering web pages. I find having one entity (ampproject.org) to serve pages from various sites is quite worrisome privacy-wise. [1] https://news.ycombinator.com/item?id=10345795 https://news.ycombinator.com/item?id=10345795

fredliu 11y ago

Interesting to see how different companies address the "mobile web sucks" problem. Google is coming from the top, pushing for "the right way to do mobile web" for the entire Internet, while Facebook is building its own walled garden of Instant Articles. Both of these strategies require the content provider to adopt yet another "standard", which takes time and money to make happen. IMOH, any of these tech company driven "push-for-a-certain-tech" is less likely to work, or at least not cost effective. In contrast, the transition to "mobile web first" is already done in China, which I would argue has the largest monetizable mobile consumer market in the world (because it's not only for hip young people. Most if not all of the grandma generation in China are getting on the internet for the 1st time, and only through WeChat on smartphones). Any user of the WeChat app knows the astonishing volume of contents shared within that social app, and all of them are mobile centric, actually it's fair to say it's "mobile only" (if you load the same URL of a shared article in WeChat on a desktop browser it'll look aweful i.e. they are not responsive, and they don't care). Yet, this transition happened not because of WeChat pushed all content providers to adopt a certain standard, but done spontaneously by each content provider, on their own to figure out what looks good on WeChat. The need to make "mobile only" content comes from the desire to reach the huge user base in WeChat, which, unlike facebook, is a "mobile only" app. The tech for making mobile friendly webpages are there for years. I would argue the reason it's not happening in the US is because of weak demand, not supply. If you have the sort of "mobile only" demand as seen in WeChat (Facebook is better positioned in that regard than Google), you'd see content providers switch to whatever suits them overnight.

julien 11y ago
I don't mean to defend Facebook but Instant Articles is based on RSS... hardly a walled gardern. On the other end, AMP is (yet another) re-invention of the wheel from Google.
- cramforce 11y ago
  AMP is just HTML.
  - deleted 11y ago

niutech 11y ago

The cause is good, but AMP are overcomplicated. They rely heavily on JS, Web Components, Custom Elements. They need a polyfill for other browsers which don't support Web Components natively. They add too much bloat to HTML: custom attributes, weird <style>body {opacity: 0}</style><noscript><style>body { opacity: 1}</style></noscript>, etc. Instead, content providers should stick to plain old HTML with a small CSS script and no JS, just like RSS feeds. That would be blazing fast and backwards compatible.

bduerst 11y ago
Doesn't the lack of js make it impossible for content creators to provide ad-subsidized content?
- niutech 11y ago
  No, the ads could perfectly be like: <a href="..."><img src="..." alt=".."></a> with src generated server-side.
  - bduerst 11y ago
    >perfectly That would kill any targeting, thus destroying conversion rates on cpc ads and diminishing the value of display ads. This perfect system would lead to more spammy ads, not less. Content creators aren't going to jump on that. And do exchanges actually let publishers dynamically serve ad content from server-side? Wouldn't they be able to fake impressions?
- zukee 11y ago
  No, there is built in support for ads in the AMPHTML framework, see: https://github.com/ampproject/amphtml/blob/master/builtins/amp-ad.md https://github.com/ampproject/amphtml/blob/master/builtins/a...

antichaos 11y ago

According to the spec, AMP developers are prohibited from adding their own JS, yet they are mandated to include a <script src="https://cdn.ampproject.org/v0.js" https://cdn.ampproject.org/v0.js" async></script> tag as the last element in the <head>. I find it amusing that the JavaScript library itself is 137KB big (38KB gzipped).

51Cards 11y ago
However like any CDN content, the goal would be for it to be cached if it's in common use across AMP sites. One JS module that covers a large number of content delivery sites seems like a plus to me. I can't vouch for the whole concept yet though, still reading through their spec.
- cramforce 11y ago
  Also: We can use a Service Worker for reliable caching of the JS.
callahad 11y ago
<img> and <video> are also prohibited in favor of mandatory custom elements like <amp-img> and <amp-video>. ...and vendor-specific tags like <amp-youtube>, <amp-twitter>, and <amp-instagram>, the library of which is controlled by a single gatekeeper. There must be less invasive ways of achieving the same goal.
niutech 11y ago
Now compare this to Instant Articles spec: https://developers.facebook.com/docs/instant-articles/reference https://developers.facebook.com/docs/instant-articles/refere... No JS, no Custom Elements, just pure HTML.

brlewis 11y ago

I'd like to see detailed rationale for disabling zoom, which can be important for accessibility. maximum-scale=1,user-scalable=no

cramforce 11y ago
We'll most likely relax this. Related to embedding fidelity.

Someone 11y ago

So, basically, Google announced a free CDN, if you restrict yourself to a HTML/JavaScript subset that promises fast page load times for users, and invites other parties to do that, too, using the same restrictions? I also read claims that this is a move against ad-blockers. Is there some truth in that?

est 11y ago

WML anyone?