What annoys me is how Google is selling this project. At least Facebook is honest about their Instant Articles.<p>This isn't an "open standard" guys, and it's not about performance! It's about the single piece of js that's allowed on AMP pages and the amp-tags such as <amp-ad> and <amp-pixel> that only Google controls. Performance is just the story they are selling in exchange of absolute control of the Web. After all, any publisher can easily clean up their websites as they ought to do to make it AMP compliant, but use valid HTML tags instead of the invalid amp-tags. Google could have easily promoted performance by applying penalties to heavy pages via Page Rank. But it's not about performance. It's all about the money.
Maybe it's a sign of me getting old, but I have never understood the thought process behind building systems which server static content - newspapers, blogs - which require active processing for every request for every user.<p>These are systems where the read/write ratios are often 1000:1.<p>Ten years ago this was symptomized by systems which pulled the same content out of a database for every single request. We treated the symptoms by introducing caching servers and horizontal scaling.<p>In modern times the symptom is displayed with heavy use of client-side rendering. Because, you know, this client-side rendering is "free" for the publisher.<p>I don't understand how any "Engineer" can see 1000:1 R:W ratios and suggest doing all of the work on the R side of the ratio.
I'm tremendously not keen on this, but am willing to be persuaded otherwise.<p>I don't want to have to build my sites using Google's AMP framework and their custom elements just to get good SEO.<p>I don't want to cache my content in Google's network so they can 1) track everything my users are doing without any indication on the front end and b) start serving ads from the cache and make every ad blocker stop working overnight.<p>This looks like Trojans bearing gifts in my (maybe paranoid) mind.
I hate it when pages suddenly change their scroll position, it makes reading the site painful. So any project that aims to fix this gets my approval!<p>One more pet peeve of mine: websites with giant non-scrolling banners at the top of the page. Thanks for wasting my screen space just so you can show your stupid website logo. As well as the pixel wastage, half the sites can't even make their banner stay still, it wobbles slightly as you scroll and it tries to reposition itself. Or, it breaks page scrolling - page up/page down will skip content hidden under the banner.<p>And while I'm moaning about the web of today: Also annoying are the sites that hide/shrink the banner as you scroll down the page, but make it pop back up as soon as you scroll upwards. If you accidentally move slightly too far down a page, you shift back up a row or two to catch a missing line of text, only to find a banner popping up and obscuring the bit that you specifically tried to view. Argh!
I personally choose to block ubiquitous 3rd parties by default[1], to fight both bloat AND privacy exposure.<p>This AMP project reduces the bloat but at the cost of increased privacy exposure. If I globally block `ampproject.org` when visiting a AMP-enabled web pages, the pages do not render at all.<p>My understanding is that now all "Google and its partners" have foiled the ability of visitors to protect their privacy with this AMP project -- and all these partners are given access to my browsing history.<p>This goes completely counter to "The Internet is for End Users"[2]. I hope people will boycott by blocking wholesale `ampproject.org` as 3rd party -- this needs to fail.<p>[1] Examples: `twitter.com`, `facebook.[com|net]`, `gravatar.com`, `fonts.googleapis.com`, etc.<p>[2] <a href="http://mnot.github.io/I-D/for-the-users/" rel="nofollow">http://mnot.github.io/I-D/for-the-users/</a>
This is obviously Google's response to Facebook's Instant Articles and Apple's News. Behind all the technology is the main business goal of delivering a content platform that has the sponsoring company's ad network baked in to it.
I suspect that the issue of web performance is less a technical problem than an organisational one. We have the technology to build performant pages right now, as well as best practises — they're just not used pervasively enough. As long as the business processes that produce the slow pages don't change, no shift in technology alone can save us.
That the page is itself an AMP HTML document would be really impressive if it wasn't really simple to make a completely valid html page that looks the same as that one that loads extremely fast on every platform.
This really comes across as some sort of elaborate joke. Their solution to a slow web is to circumvent the standards and use a javascript library?<p>My only contribution to the conversation is utter bewilderment someone thought this would be a good idea.<p>The improvements are because they've removed everything.<p>Also, side note but I thought there was already a proposal in HTML for reusable elements?
I don't seem to understand what this is for. If you want a fast loading page, don't add slow stuff to it.<p>What new is AMP bringing to the table? It seems to be some kind of a framework? Is it code or is it a preprocessor or what is it?
"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."<p>Quite a bold decision there! Ultimately this will fail, of course, because the vast majority of sites that attempt to make money will need third-party scripts in some form. A much better move would be to try and produce a standard which third-party library authors could adhere to so that their scripts behaved nicely.
AMP reminds me of "i-mode", a Japanese mobile HTML variant originally launched in 1999 that was hugely popular in the country for many years:<p><a href="https://en.wikipedia.org/wiki/I-mode" rel="nofollow">https://en.wikipedia.org/wiki/I-mode</a><p>Then, as now, regular HTML pages were considered too slow and complicated for mobile phones. I-mode was conceived by the large network operator NTT Docomo.<p>The big difference is that NTT Docomo were the exclusive gatekeepers for publishing content. Google also gives you the option of publishing AMP content on their CDN, but it's not mandatory.
What's sad is that this is just optimized HTML + CDN packaged up by Google and heralded as some big innovation.<p>If publishers spent a few hours they could make extremely lightweight pages too (even with media and ads).<p>Here's an AMP page: <a href="https://amp.gstatic.com/v/mobile.nytimes.com/2015/10/08/us/reassurances-end-in-flint-after-months-of-concern.amp.html?amp_js_v=0" rel="nofollow">https://amp.gstatic.com/v/mobile.nytimes.com/2015/10/08/us/r...</a>
<i>> Resources must declare their sizing up-front</i><p>This is <i>such</i> a great idea. Jerky web pages that jump around while you're trying to click on something are maddeningly annoying.
Two scrolling behaviors that I found odd on this page and on the NY Times example[1] on iOS:<p>- You can't scroll to the top by tapping the status bar.<p>- The scrolling momentum is different. There's less friction, as if you were scrolling through a list view (e.g. Mail).<p>Anyone know how/why? I thought it might be some -webkit-overflow-scrolling trickery[2] with a full-size container div or something, but I don't see anything too weird like that.<p>[1] <a href="https://amp.gstatic.com/v/mobile.nytimes.com/2015/10/08/us/reassurances-end-in-flint-after-months-of-concern.amp.html?amp_js_v=0" rel="nofollow">https://amp.gstatic.com/v/mobile.nytimes.com/2015/10/08/us/r...</a><p>[2] <a href="https://css-tricks.com/snippets/css/momentum-scrolling-on-ios-overflow-elements/" rel="nofollow">https://css-tricks.com/snippets/css/momentum-scrolling-on-io...</a><p>EDIT: Turns out there <i>is</i> some -webkit-overflow-scrolling trickery going on[3]. But again, why?<p>[3] <a href="https://github.com/ampproject/amphtml/blob/77d9f31263866e56a83a7ee7194f1ec46bed65f9/src/viewport.js#L533-L559" rel="nofollow">https://github.com/ampproject/amphtml/blob/77d9f31263866e56a...</a>
I feel this is Google's response to Apple's ad blocking push (maybe push is too much here, what's a better word?).<p>Neither AMP nor ad blocking are what is needed. We need sensible ads that are unobtrusive. We need web pages that do not track the consumer. We need smarter designs that don't use huge images everywhere. We need JS where it is needed and not just because it's cool.<p>We don't need two behemoths fighting over the control of our web.
TLDR; I mostly agree with monopoly idea.<p>We had WML for mobile devices before mobile devices were powerful enough to render HTML. Then we got smartphones better than my computer bought 5 years ago. AMP in my oppinion is a step back, yes you can do a lot of things in CSS. But in reality there are cases where it needs to happen dynamically. For example: javascript input validation, you cannot validate data using CSS. Are we then going to reinvent Javascript using some new fancy name?. Also, how about backwards compatibility(IE7-8 I'm looking at you)?<p>Those companys could spend their resources on better things, like implementing ways to load viewport dependent images(it seems it's already done using picture tag). Because multimedia takes huge chunk of the website.<p>And like always there are ways to write performant websites using existing technology and even more ways to write slow websites using all the "bleeding edge" technology. It's up to the developer mostly.
This isn't an HTML subset, it's some freakish pseudo-HTML JS library weirdness.<p>Why not define an <i>actual subset</i> of HTML? You know, like XHTML Strict Mode?<p>Why must everything be a JavaScript library?!
"Performance is just the story they are selling in exchange of absolute control of the Web."<p>To be fair, they are not the only ones that use this "story" as a ploy to get more control over users (and hence gather more saleable personal information).<p>Phrases like "make the web faster" are disingenuous and should not pass any intelligent user's BS filter.<p>The very reason the web is slow is because of these companies which need to serve ads and other crud to survive. That means more DNS lookups, more TCP connections, more HTTP requests, more Javascript, longer URL's, more unwanted IMG's (e.g., beacons), more tags, etc., etc. The list is so long I cannot even hope to capture it all. That end result is simple: staring at a screen waiting for the computer to respond. Not to mention frequent leakage of personal information.<p>As a user of netcat and text-only browsers that retrieve pages in milliseconds, I am astounded at how long users today are willing to wait for their content (i.e., "page loads"). I also run my own web servers at home to serve content to my family's mobile devices. I am well-aware of what (i.e., who) slows down "the Web".<p>The user does not start from the assumption that she needs to (down)load "resources" (as in Uniform Resource Locator) from a number of advertisers for every page she views. Those are the assumptions that the web company starts with. Those are the constraints they must work within. Not true for users.<p>I do not need Google DNS. I run my own locally, primed with all the domains I routinely visit. No remote DNS cache is going to be faster than my loopback.<p>Nor do I need HTTP/2. I just use HTTP/1.1 pipelining to retrieve 100's of pages of content, usually 100 pages at a time. HTTP/2 is something the web companies may need to accomplish their goals of serving ads and collecting personal information. But it is not something users need.<p>To drive adoption they must convince users that users need these "improvements". So the web companies purport to offer "solutions" to the problem they themselves created: a slow, bloated www.
I have a 45 Mbps line (with low latency).<p>Even so their crappy webfonts took like 1-2 seconds with a FOIT before that, while all the text was available almost immediately.
The problem is that publishers want to know everything about their users, so they add tons of "spyware" that slow down the site.<p>Who does already know EVERYTHING about your users? But can they sell it?<p>startup idea: Make a blazingly fast CMS that tracks everything and show pretty graphs.
With custom_element and web_component support not being complete in other browsers, will the polyfills provide as much benefit in these other browsers as it does in chrome.
The only thing that's getting accelerated here is the filter bubble.<p>The Internet and all of its neutral standards are being eviscerated by faceless avarice, and no one gives a shit.