Accelerated Mobile Pages Project
ampproject.org
ampproject.org
With AMP: http://www.theguardian.com/science/2015/oct/07/lindahl-modri...
Without AMP: http://www.theguardian.com/science/2015/oct/07/lindahl-modri...
• 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/ [2] https://www.ampproject.org/how-it-works/
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.
But to show what I'm talking about, here's how the page looks on my desktop in Chrome:
Again, that just seems like wasted real-estate.
That's not what I do, because it doesn't make sense. Text that takes up the entire width of the monitor is either in an unreadably long line, or in unpleasantly large text. There's only so much margin you can handle on either side of the text before it just looks silly. And I don't think multi-column is the way sites should or are going - it interacts poorly with scrolling.
Thus I don't use maximized browser windows on big monitors. I use tree-style tabs, which uses a bunch of horizontal browser space much more productively than big margins, and I cascade my browser window with other windows so I can easily switch windows using the lower left corner of each window. With it occupying the rightmost and tallest position in the cascade, it is further reduced in horizontal size.
tl;dr: Web browsing, being primarily a text medium, doesn't scale up to wider and wider monitors. So don't make the window so wide.
A big problem is that they don't and AMP is as much about fixing that as about technology.
https://developers.google.com/speed/pagespeed/service/Deprec...
AMP makes it harder (impossible?) for them to misuse analytics and advertising by putting those features into their own elements in the page and preventing arbitrary JS.
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.
...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.
This works in mobile Safari and doesn't require updating any browsers.
It's really just best practices rolled into a kit.
Most newspapers are crammed with crud that provides zero value to me.
I also read claims that this is a move against ad-blockers. Is there some truth in that?
SVG tags are banned. Isn't this taking the web a little backwards, seeing as interactive components like D3.js won't be supported?
Fixing right now.
>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/
http://www.niemanlab.org/2015/10/get-ampd-heres-what-publish...
<!doctype html>
<html amp>
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?
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.
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.
https://developer.mozilla.org/en-US/docs/Quirks_Mode_and_Sta...
> The doctype keeps the browser in standards mode
Yes, I'm following that. It keeps it in standards mode because it's saying "Hey, this page is HTML5" and browsers can say "Oh good, a modern standards compliant website, this should be just fine"
What I mean is that these AMP pages are not valid HTML5. I don't like the idea of adding a tag which says "this is valid HTML5" when it isn't, just so that there is a side effect of changing the rendering mode that browsers use.
This sort of "same content, different view" feels like it's what content-type was designed to solve.
I can't even put it in a HN comment.
Html.getAttribute()
<div [facebook icon]>friend me</div>
https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes
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.
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."
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.
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?
maximum-scale=1,user-scalable=no
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".
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.
"free" is incorrect, "obfuscated costs to the users" is more accurate.