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.
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]
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.
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?
Are you using a maximized browser on a 24" monitor?
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.
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.
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:
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.
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?
Analytics and advertising are core parts of how publishing works as a business, but they often seem to be implemented without thinking about speed.
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.
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?
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.
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" async></script> tag as the last element in the <head>. I find it amusing that the JavaScript library itself is 137KB big (38KB gzipped).
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.
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.
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.
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?
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.
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?
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.
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.
> 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.
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".
I think maybe you're confused? The doctype keeps the browser in standards mode and isn't modified in the amp pages. It only changes the rendering mode in the sense that adding it to any html page changes the rendering 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.
Two URLs are optional. You can make one page that is AMP valid and point link rel=canonical to self. This is still useful as it helps avoid multiple URLs for the same resources a.l.a. www.foo.com vs foo.com and ?meaningless_parameter.
Two URLs are only optional if I don't want to add anything to the page that's not allowed in AMP. Or if I don't want to have a bunch of external JS required just to show images.
This sort of "same content, different view" feels like it's what content-type was designed to solve.
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.
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.
Technologically it's not a walled garden, but "business wise" - for lack of a better word- it is definitely a way to improve content consumption experience on Facebook, not for the general Internet at large.
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."
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.
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.
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?
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.
With AMP: http://www.theguardian.com/science/2015/oct/07/lindahl-modri...
Without AMP: http://www.theguardian.com/science/2015/oct/07/lindahl-modri...