
Accelerated Mobile Pages Project - cbowal
https://www.ampproject.org/
======
cbowal
The Guardian sample AMP page:

With AMP: [http://www.theguardian.com/science/2015/oct/07/lindahl-
modri...](http://www.theguardian.com/science/2015/oct/07/lindahl-modrich-and-
sancar-win-nobel-chemistry-prize-for-dna-research/amp)

Without AMP: [http://www.theguardian.com/science/2015/oct/07/lindahl-
modri...](http://www.theguardian.com/science/2015/oct/07/lindahl-modrich-and-
sancar-win-nobel-chemistry-prize-for-dna-research)

~~~
AdmiralAsshat
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
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.

~~~
AdmiralAsshat
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.

~~~
what_ever
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.

------
matthewmacleod
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
Part of AMP is caching on Google's servers (and others). That can't quite be
done individually.

~~~
matthewmacleod
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
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.

------
gorhill
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)

------
antichaos
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
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
Also: We can use a Service Worker for reliable caching of the JS.

------
ziles88
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
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.

------
Someone
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?

------
bb101
The spec:
[https://github.com/ampproject/amphtml/blob/master/spec/amp-h...](https://github.com/ampproject/amphtml/blob/master/spec/amp-
html-format.md)

SVG tags are banned. Isn't this taking the web a little backwards, seeing as
interactive components like D3.js won't be supported?

~~~
dvoytenko
SVGs are 100% supported with very few restrictions.

~~~
bb101
Thanks for clarifying. Happy to see SVG will be included, especially after so
many years of IE8- not supporting it.

------
IanCal
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?

~~~
sesutton
I'm really not a fan of the fact that their preferred version is <html
[lightning bolt emoji]>

I can't even put it in a HN comment.

~~~
on_
Why is this downvoted? I am not a stickler for 100% compliance here, but look
at the MDN[0] attribute list. They are all logical and semantic things and
they are converted into objects. This comment is correct. They are additional
values for configuring elenents. Html.getAttribute([emoji bolt]) is
rediculous.

    
    
        Html.getAttribute()
    

I included the attribute above, it is not there however. While that is a HN
feature, I am wondering what the response to the rebuttal to the above comment
is? Do we want to start doing brand logos in markdown?

    
    
        <div [facebook icon]>friend me</div>
    

Edit: before anyone says it, I know amp is accepted as well. I guess the only
thing reading that attr is googlebot, but I just find it really offputting.

[https://developer.mozilla.org/en-
US/docs/Web/HTML/Attributes](https://developer.mozilla.org/en-
US/docs/Web/HTML/Attributes)

------
fredliu
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
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
AMP is just HTML.

~~~
callahad
But it's not, really. It's HTML + a mandatory web components polyfill and
standard library loaded from a remote origin. If I just rendered the HTML, I
wouldn't see any images or videos, because they're hidden behind custom <amp-
img> and <amp-video> tags.

I guess the upside is that I also wouldn't see content in the <amp-ad> or
<amp-pixel> elements.

I wouldn't disagree with AMP being "just web technologies," but it's sure as
hell not "just HTML."

~~~
cramforce
OK "just web technologies". I stopped seeing HTML as just the markup language,
but I'm fine with people liking that distinction!

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

~~~
dvoytenko
It does. However, the benefit is much more obvious on mobile given the
CPU/memory and bandwidth constraints.

~~~
noir_lord
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
CPU and bandwidth will always matter. Once those restraints aren't an issue
for phones, people will want webpages to load on their watch.

------
niutech
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
Doesn't the lack of js make it impossible for content creators to provide ad-
subsidized content?

~~~
niutech
No, the ads could perfectly be like: <a href="..."><img src="..."
alt=".."></a> with src generated server-side.

~~~
bduerst
>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?

------
brlewis
I'd like to see detailed rationale for disabling zoom, which can be important
for accessibility.

maximum-scale=1,user-scalable=no

~~~
cramforce
We'll most likely relax this. Related to embedding fidelity.

------
est
WML anyone?

------
pranaya_gh
Google says these will be the areas of focus on the AMP project: (from
[http://googlepolicyeurope.blogspot.com/2015/10/introducing-a...](http://googlepolicyeurope.blogspot.com/2015/10/introducing-
amp-project-for-faster-open.html)):

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_
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.

