What annoys me is how Google is selling this project. At least Facebook is honest about their Instant Articles.
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.
What about RSS? That offered good performance, was widely adopted and was a real standard working for both publishers and consumers.
Remember who actually killed it? Yeah, that was also Google.. by discontinuing their Reader - a very good tool with lots of users but no revenue. That's how much open standards matter. Too bad @aaronsw is not around anymore, he would have said something about AMP.
>Remember who actually killed it? Yeah, that was also Google.. by discontinuing their Reader - a very good tool with lots of users but no revenue.
If a single company killing a sigle product could kill RSS, then it wasn't that alive in the first place.
The fact is, after 10 years of RSS being available in blogs, news sites and elsewhere, Reader still had an insignificant number of users in the web scale of things. A few tens of millions (all estimates put it in the low tens, like 20 to 40 millions).
>And did you just say "few tens of millions" of users is insignificant?
Yes.
>How many users are we here on Hacker News again?
I'd say well under a million (or around that at most). What does that have to do with anything? Did anybody say that HN has a significant amount of users web-wise?
Slashdot and then Digg, which were both something like 100 times HN in size fell off the side and nobody much cared.
I would say that Hacker News' few hundred thousand users are extremely significant both for YC and web-wise. I really hope we'll not end up with a Facebook-only Internet because that's the only service big enough to keep running.
It's, ironically, a case of the "embrace and extinguish" philosophy that Microsoft was reviled for.
I remember reading posts by several people which said they weren't going to build a RSS reader because they didn't want to compete with Google Reader.. and then they went ahead and killed it.
RSS didn't really "take off" with mainstream users (I guess today's equivalent is Twitter), but it filled an interesting niche.
RSS -> Twitter
Usenet -> many proprietary platforms
IRC -> Slack
XMPP never took off
Many open, interoperable services died off or never took off, but companies built similar services and are enjoying success.
"Some of these parallels are obvious, and even more or less literal: Gmail is IMAP and SMTP, and Google Talk is (or was) XMPP, all on port 80 in the same browser window. Others are more metaphorical. Twitter is IRC on port 80, although one primarily listens to users instead of channels — but listening to channels is still possible, if one uses a client that can follow hashtags, and the syntax is even the same. Dropbox is FTP on port 80. Reddit is Usenet on port 80."
https://medium.com/@maradydd/on-port-80-d8d6d3443d9a
Urbit looks cool, but it will not magically make things distributed. What causes centralization are business factors. It's just a lot easier to build a great product if you have a revenue source, which is most easily acquired if you can lock people into paying for your proprietary thing.
Also, it's a lot easier to make good protocol decisions if you don't have to get them published into a standard and deal with the beauracracy etc. If you look at the level of polish in slack vs one of the many previous open source irc clients, the difference is clear. It helps to have money.
I was as annoyed as the next person when Google killed Reader but, to be honest, RSS was killed off for typical users way before that when browser manufacturers dropped/hid support for it. I still use RSS every day, as do many of our customers.
Not just browsers, but Facebook and Twitter both killed their RSS feed at some point.
That's much worse than Google killing Reader, because reader is just a reader, you can still switch to a different one. If the source doesn't provide an RSS feed, there's not much you can do.
RSS never was an open standard like you would expect from a real standards organisation, e.g. IETF or W3C.
Because of dominance posturing and fights between the multiple parties involved in the development of RSS, it is a train wreck of ad-hoccery and incompatibilities, and serves as a prime example of how not to do things. https://web.archive.org/web/2004/http://diveintomark.org/arc...
This is kind of orthogonal to RSS. AMP and RSS work great together. Your feed reader can detect that the feed item URL has an AMP alternate and chose to display that instead.
How? Multiple <link>-Element as in Atom with special rel-values? Or a link in the already linked HTML page?
There's nothing on that in the Github Wiki and neither on the project page. The superset of HTML is specced, yes, but information on the containing ecosystem is spare.
<amp-pixel> supports all kinds of tracking. You just give it a URL. Ironically it does not work with Google Analytics but we'll fix that eventually. Most others should work.
You suggest elsewhere there is revenue sharing involved, but that is not true. amp-ad just loads an ad. This is controlled by the publishers and and their agreement with the advertiser. Google only plays a role if it happens to be the ad network (or the advertiser) involved.
Scanning your comments, I haven't learned about what tracking is accomplished by serving the https://cdn·ampproject·org/v0·js file itself, can you please comment on what data (if any) is collected by being 'the' place all AMP sites phone home to on page load by default?
Two other points, and I hope these are received as constructive criticism.
1- You only score 'B' on SSL labs for the domain serving the AMP JS file.[0] Maybe this is intentional so as to include support for Android devices that no longer get updates but it's not great security for the rest of us.
2- Your page explaining the project executes Google Analytics tracking code and has no privacy policy and does not disclose the fact that you are tracking visits. This is a breach of your very own Google Analytics T&C's[1] which read in part "...You must post a Privacy Policy and that Privacy Policy must provide notice of Your use of cookies that are used to collect data. You must disclose the use of Google Analytics, and how it collects and processes data...".
Neither of these inspire confidence and I hope you can get at least one of them corrected soon.
Taking into account that Google "happens to be" the largest ad company around, it is hard to not see this as a defensive move to protect themselves at a time when the disproportionately negative impact of ad-tech has put their business at the mercy of adblockers and native apps.
In general, I think that there is an important conversation to be had about how this newly proposed cacheing tier would effect the overall cat and mouse game between tracking networks and ad blockers on mobile phones. Since the web community is being asked to choose to adopt a new technology, I don't think there's anything wrong with trying to reason about what would be technically possible to achieve in terms of tracking tech with this architecture. Here one rough estimate:
If ads are all served locally (from a single domain) then it becomes technically feasible to utilize a short-lived rotating mutation URI generation scheme. Under such a tracking system each ad unit URI would be instantiated "just in time" to redirect a certain amount of load after which it would expire away. This JIT transient URI generator could be aware of the domain's application routing table so that it can dynamically spin out each new tracking/ad unit URI in a camouflaged form. In other words each URI could appear to be only a mutated variation of organic cached content.
In computer security parlance this would establish a "covert channel" on top of HTTP via a timing attack vector (extremely short-lived URLs).
I would imagine that ads propagated through such a system would be pretty much impossible for an ad-blocker to identify within a low-enough latency window. In other words by the time the ad unit's URI is discovered by a blocking server and it's clients are notified the URI has already vanished as if it never existed.
What's I find slightly humorous about this approach to tracking is that the scheme would closely resemble several of the "blackhat SEO" techniques which are frowned upon by Matt Cutts' "Quality Guidelines" for example "link schemes", "automatically generated content", "cloaking", and "sneaky redirects". Surely it's unfathomable to think that Google would one day resort to such forms of trickery in order to confuse other search engines :)
By the way this is only something I came up with earlier today and definitely not something that I've even heard discussed although I'm not in the advertising business myself. In other words it's entirely possible that I could have missed something here.
While there's bound to be other (more efficient) solutions, blockers could start filtering by the content returned. This sort of behavior leads to an arms race, with ad blockers ultimately losing (cost to detect >> cost to circumvent).
I follow your thinking. The ad networks could begin transforming their content in subtle ways which the eye cannot detect but which could throw off simple pattern matching thereby forcing the blocker client to employ an algorithmic approach.
The networks would be able to utilize many cores in parallel to mutate the content, but the blocker client would have to run it's detection on mobile devices.
The more processing the blocker client must perform the more burden it places on that relatively underpowered mobile CPU which increases latency. Also when you get into algorithmic detection you have to start considering false positive ratio because any noticeable false positives will break the user's expectation causing them to eventually lose confidence in the client's utility.
As you rightly point out there may be both vectors for either side which neither of us has thought of though.
What are they selling, exactly? Why does this need to be a framework, with js and all that?
I'm not asking cynically, and following it up with "oh, they should just do x instead".... I legitimately do not understand what's going on here. What's the added functionality? I read the article twice, I don't get it. I'm going through the spec, I don't get it. I looked at the article source, I really don't get it, it's just html and common sense.
You might get it :)
There isn't that much to it. AMP is as much about technology as finally getttig that tech adopted. Since AMP is built on web tech there is nothing in it that you cannot chose to do yourself
The problem we are solving is that many sites don't.
So what's with the approach then? Why would websites choose to use AMP (whatever "using AMP" means), when they don't apply common sense in the first place?
One of the things that AMP allows is to know that is it save to prerender a page. Documents can be instructed by a viewer to e.g. only load resources visible above the fold and absolutely no external JS.
With general web content prerendering is pretty dangerous and you certainly cannot do it with say more than 1 doc at a time because it may use arbitrary bandwidth and CPU.
That allows for instant feeling loading of pages (because they are already loaded when the user clicks) which in turn makes users happy :) While all web pages can be fast, AMP allows proving that they are which makes such a feature possible.
A referrer like Twitter or Pinterest or Google could e.g. indicate: Clicks on these links will be super fast (because they are AMP docs). If users click them more (because they like fast) there is a strong incentive for everyone to be fast – and then we all win.
I don't think XKCD927 applies, because we only combine existing standards and restrict ourselves voluntarily to a subset of those. Its still just HTML, CSS, JS. Browsers do not need to change.
't
You're not "combining" standards though. As other comments pointed out, this is not a subset of html. It's a separate spec, based on a subset of html, which is different enough that it's not quite compatible. For example, what's with the amp-prefixed tags? Why amp-img instead of img with data-amp- attributes?
You also didn't address my first point: If you're building this for people who don't make the effort right now, why would they suddenly make a seemingly bigger effort to support something they haven't even heard of before today?
We use amp-img instead of the img tag to be able to control when resources load (read not load them unless actually needed). Doing this with a different hack like <img data-src="foo"> is possible but a less explicit hack.
To your first point: It might have been just the right point in time, but maybe it isn't. I argue that if adoption is good users will win. It could totally fail, but then it was still worth trying.
Good demo. The benefits are indeed attractive, but you still have not sold me on why this is a better approach than ... well, everything that's been suggested in this thread. This stuff is possible without what you're proposing, as you yourself admit. What I see amp giving is a framework in which it is impossible to "mess up", which can be beneficial but I agree with the general sentiment here: New tech has a cost to it. Learning it has a cost. Implementing it in browsers has a massive cost (because I'm sure this will eventually find its way in Chrome, which means Firefox will follow suit, which means a larger potential for technical debt and a higher bar to developing a web browser from scratch).
Like someone else said: If Google wants performance, Google can start aggressively penalizing article-type websites which make unnecessary requests etc. I know you guys already penalize slow sites, so what's wrong with that approach? Especially since such an approach has a much higher chance of actually working.
I totally agree that the "penalizing" approach is important.
But I like to present both a solution "this is how you make it fast" as well as the penalty.
If you only take AMP as a guide or tutorial that puts current best practices in a neat package that is fine with me. We are totally not claiming to have invented a new wheel.
Browsers could do what AMP does (e.g. super lazy prerendering) but I'm an impatient person and I don't like waiting for what a browser with a yearly release cycle might do.
The custom-elements document you linked to is a W3C Working Draft, not a Recommendation. It might someday be part of the Web platform (w.r.t. standardization), but for now it's just under discussion.
It has an implementation in Chrome and Firefox and both Microsoft Edge and the WebKit teams have indicated that they will support it. On top of that there are 2 super excellent polyfills.
In the world of the web platform it doesn't get much more standard than that.
> One of the things that AMP allows is to know that is it save to prerender a page. Documents can be instructed by a viewer to e.g. only load resources visible above the fold and absolutely no external JS.
Which begs the questions: Who prerenders and on what criteria?
Assume page A which has a link to AMP-forked page B.
Does that link need rel=prerender for every browser? Does one need to query the AMP-ness of every page one links to? Does one need to be Googles page cache to link to AMP-pages and get in the benefit of prerendering?
Or is the prerendering implemented in the AMP runtime? Does it only work if page A and page B are both AMP-enhanced?
They deliver all the amp-ads via that single piece of js, and will share some of the revenue with the publishers. It's not a bad idea after all, if only they had presented it for what it is: a Google fork of the Web. The "performance story" is just the bullshit.
If they're putting ads in custom tags that makes it extremely easy to block them.
I think it's nothing so sinister as a "fork of the web", but a badly thought out approach of going back to faster loading web1.0 by recognizing that quite a lot of JS adds no value to the end user.
My point is that this project is not about providing value to the user. Google could have done that more easily.
It may not be so sinister because it's a badly thought out approach indeed. Although they got quite a few big partners already, this undertake requires rewriting the whole Web which is too much to ask even if you are Google.
Then don't pull random statements out of your ass about it? What are accepted as standards spend most of their life as W3C working drafts. The W3C doesn't finalize a draft until the feature is obsolete, more or less.
WebWorkers, for example, is still a working draft. So is Web Storage.
The only thing that has ever mattered is browser support, not W3C specs.
To expand on this, custom elements are supported in Chrome and Firefox (behind a flag in FF at the moment), and there has been public support from both Webkit and Edge, as well as high quality, high performance polyfills.
Yes, custom elements are not fully finalized, but all of the browser vendors are invested in the spec and finalizing it. There is a lot of activity on it right now.
What annoys me are people who speak out of ignorance without really knowing what they're talking about, but like to give the impression to others they do.
AMP is an open source project any publisher can use and tailor to their needs. If you don't want to factor Google into the solution then you don't have to.
But, keep on praising Facebook because you at least got their agenda right.
>What annoys me is how Google is selling this project. At least Facebook is honest about their Instant Articles.
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.
if you run a whois on ampproject.org, the results clearly indicate it's owned by google.
Registrant ID:mmr-87489
Registrant Name:DNS Admin
Registrant Organization:Google Inc.
Registrant Street: 1600 Amphitheatre Parkway
Registrant City:Mountain View
Registrant State/Province:CA
Registrant Postal Code:94043
Registrant Country:US
Registrant Phone:+1.6502530000
Registrant Phone Ext:
Registrant Fax: +1.6502530001
Registrant Fax Ext:
Registrant Email:dns-admin@google.com
The tech lead of the project is Malte Ubl who by their twitter page : @cramforce indicates that "I make www internet web pages for Google. "
Unless it's a 20% off time project (or a side project of some kind), I can't understand why you say it's not a Google project if it's being funded by google and made by a google employee.
>I can't understand why you say it's not a Google project if it's being funded by google and made by a google employee.
For the same way that tons of open/collaborative projects with multiple partners are not "X projects" even if they started and/or are hosted by X.
Heck, even something like Webkit is not an "Apple project"...
Downvotes? Are you kidding me? What part of "open source initiative" containing multiple industry leaders (like Twitter, and lots of others) don't people understand?
Is Angular involving multiple major-name partners such as Tweeter, and has been such from the start -- to the point of downplaying Google's involvement in the project site?
For something like SPDY/HTTP2 etc, I can say it's Google first and foremost (even if it got adoption later on).
Google's slogan shifted from "don't be evil" to "do the right thing", the former is arguable to say the least based on its records, but moving to the latter is worse, as google can just do the "right" thing for its own benefit, which could be selfish, and blatantly evil sometimes.
> Google's slogan shifted from "don't be evil" to "do the right thing"
False. Google's slogan did not change.
Also the full slogan for Alphabet is "do the right thing – follow the law, act honorably, and treat each other with respect." This cannot be selfish & blatantly evil.
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.
These are systems where the read/write ratios are often 1000:1.
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.
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.
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.
It's easy to forget that html isn't the end product, the end result is lit pixels on some screen (usually). If we send json then that needs to be converted to html and that html needs to be layout and rendered. If we send html we just skip the first step. Displaying a web page isn't "free" for the client just because it's html.
The question is this: what kind of overhead is a template rendering task (in js) for a modern browser, compared to the task of layout and rendering a finished html page? It will depend of course on the complexity of the data and the resulting page, as well as the browser, templating engine etc. I have no clue whether it's 1%, 10% or 50%.
> It's easy to forget that html isn't the end product, the end result is lit pixels on some screen (usually). If we send json then that needs to be converted to html and that html needs to be layout and rendered. If we send html we just skip the first step. Displaying a web page isn't "free" for the client just because it's html.
JSON->HTML rendering may be only one step, but by not skipping it, we're making hundred thousands computers redo the computation that could be done once on a server. This has some electricity cost aggregated over all users, which we externalize to society because of a fad. You can't really skip the HTML->pixels step because of data size issues, but there's little excuse for client-side rendering of static content.
Who says you're doing JSON->HTML ? Both HTML and your data format need to get deserialized to DOM - depending on use case it can be faster/smaller to do the deserialization in JS from some format rather than using browser HTML parser.
HTML is actually non-trivial to parse and isn't really optimized for anything.
That is essentially what Opera Mini does/did: requests went through Opera's render farm which would request page and render them (with adaptations) to a packed binary format and send that back to the device. There was also rudimentary JS support in the rendering farm, the device essentially got an image with an interaction map, and interactions would be sent to the server for processing.
Not very configurable though, can't really e.g. customise font size, observe the page or pass it through a screen reader.
Opera did something like this, but instead of PNGs they gave custom markup that is precomputed so that the flip phones don't have to do layout. Or something like that. Opera mobile had server farms rendering content and re-compressing large images.
No, the end product is an ad payment to the company producing and serving the articles.
That's where all the junk comes from: tracking the user and trying to upsell them into a mobile app so you can get more personal data and a spot on their home screen.
Excellent point, I never understood that either, with developers being happy that their supercomputing buzzsaw can generate a couple of 100K of text in about a second.
OTOH...it turns out that so-called "static" content actually also requires quite a bit of processing. Apache (or whichever server you are using) is not exactly doing nothing. And it also turns out that this sort of processing is I/O heavy, which isn't exactly the fastest path on the machine, even if all the caching done by various entities (more processing) tries and mostly succeeds in making sure very little I/O actually takes place.
Add to that that moving data around nowadays is generally much more expensive than doing computation on it (several instructions per clock-cyle, multi-Gigahertz clocks, so well over a hundred clocks per main memory access, and millions per I/O, even with an SSD).
In short: if we re-examine our assumptions in light of a changing environment, might a well-optimized "dynamic" stack not be faster than a "static" one? (Compare: VoltDB...). And of course you could then cache the results in memory as well.
But the client side rendering isn't static, and it certainly isn't 1000:1 R:W. There are different browsers on different devices, with different resolutions, pixel densities, zoom-levels, minimum font sizes, window-sizes and orientations.
Static client side rendering at 1000:1 would mean that you could render an image file once and serve it to (at least) 1000 clients.
Static client side rendering means you render your site as HTML+CSS+utility JS on server once, and send a saved copy to people when asked, as opposed to client-side rendering in which you send them data, a template and JS that will build all HTML in browser.
> But the client side rendering isn't static, and it certainly isn't 1000:1 R:W. There are different browsers on different devices, with different resolutions, pixel densities, zoom-levels, minimum font sizes, window-sizes and orientations.
Yeees, and? Response CSS designs solve a lot of that with zero server-side computation overhead, and (compared to JS templating/render engines) minimal client-side overhead.
Well, I would say the common argument is that you send an intermediate format to decouple yourself from the specifics of the receiver. HTML is an intermediate format and the client is free to render it how it sees fit for the device on which it is running, which allows compatibility with newer and different clients.
It's like shipping some intermediate bytecode doesn't seem to make sense, because every client needs to compile it, until you realize it allows you to ship one format that can even be used by many different architectures and even new architectures that didn't exist when you emitted the bytecode. At the cost of a second component that needs to be present on the machine to do the compiling.
When a vast majority of clients is the same or sufficiently similar, it may of course make sense to offer an optimized format, that requires less client-side processing But what would such an optimized format for the web be?
About static vs. dynamic rendering on the server side, the Movable Type CMS used to do exactly as you suggest and it was difficult to make changes on large sites. Imagine if you want to change a link on a sidebar and have to re-build every HTML page served by your CMS to do that. Caching dynamic pages is a bit of a “hybrid” system where you can just publish your new sidebar, then clear cache on the first request for each particular changed page.
About the client side, the situation is a bit different because the JS is actually third-party software designed to be dropped in and updated easily, so it’s not just an implementation detail. Very few publishers are going to build or host their own server-side analytics or commenting systems…
Imagine if you want to change a link on a sidebar and have to re-build every HTML page served by your CMS to do that.
On the other hand, doing the processing on the client side means that work would be done every single time by every single client, and the result of that work isn't even preserved.
As decades of programmers have had absolutely no problem compiling software with many, many more dependent files than pages on a typical HTML site, I suspect the problem is in the implementation and not the concept.
build or host their own server-side analytics or commenting systems
I've not written any analytics before so I won't comment on that, but it's funny you mention commenting systems since a simple one (textboard-like) is literally less than a day's work.
> On the other hand, doing the processing on the client side means that work would be done every single time by every single client, and the result of that work isn't even preserved.
Exactly! If that amount of work on server seems big, then realize that doing it client-side means dumping a million[0] times more work on the society, with all associated electricity usage.
[0] - literally; if you have 100k visitors and each visited you 10 times, that's 1M times the work that should actually have been done.
That's exactly how a site I work on operates. True, changing a link across all pages is a very slow operation (about 50 seconds for 11,000 pages) but a) that's happening in a highly structured and powerful but resource-intensive way (i.e. DOM parsing) b) it happens so rarely that I haven't bothered to optimise it. The main trade-off for an update that happens maybe once every 1-2 months taking 50 seconds is that every single page load is faster. There are other benefits from static files, too - it's much easier to work with content in flat files, 1-per-page, than the kind of complicated database / file / code relationship used by many 'normal' CMSes.
You can do that async - have the edit experience use the db then a publish action which re-generated the site.
As for monitoring/comment systems: using external sites is actually really good for performance. Third party tools do a great job of blocking them and that makes a lot of sites very fast.
Because many publishers found that visitors wont wait the few extra seconds it takes to load the content on the server. They need to see something loading in their browser or they abandon the content.
I think you mean publishers built a slow site and are bemused by why they don't have any traffic.
Its a lack of repsect for techies and quality and not understanding that the web is not a glossy brochure that you can't optimize by shouting at a printer over the phone.
Yeah, I'm such a complainer too. Blogs are one of the last places you should ever see such a spinner because they're just static content with sidebars. There should be little to none client-side rendering involved. And the spinner on Blogger is only a (very visible) symptom of the bigger problem - the whole site is incredibly slow and resource heavy.
Implementing caching servers and horizontal scaling is complicated and requires talented people who typically need to be on call. It's lot of complicated moving parts, which can easily go wrong outside office hours when a site unexpectedly gets popular.
Where as with a static site, the complicated bit is only in the updates. A single server can handle massive numbers of requests and it's easy to scale further with a CDN.
At one point gamefaqs.com would generate static pages and serve those everywhere it could. This was before cnet bought the site though, I have no idea what they do nowadays, your post just reminded me of it.
Can you link to an example of this? I've been on gamefaqs since the very beginning and I've never seen that. In fact, the vast majority of FAQs on that site are still text.
I'm tremendously not keen on this, but am willing to be persuaded otherwise.
I don't want to have to build my sites using Google's AMP framework and their custom elements just to get good SEO.
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.
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!
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.
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!
All of those problems are design issues (in the sense of overall application/site design). They can "easily" be solved by not designing the site to work that way. Sites only work that way because site developers (the whole team) choose to do it and then implement a solution to achieve it.
The specs for the various languages and the guidelines on their "best use" already define NOT doing any of those things either by dint of it not being built-in behavior or by already actively recommending against it. There's no need to follow a 2nd, proprietary specification to do what is already the standard.
I personally choose to block ubiquitous 3rd parties by default[1], to fight both bloat AND privacy exposure.
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.
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.
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.
[1] Examples: `twitter.com`, `facebook.[com|net]`, `gravatar.com`, `fonts.googleapis.com`, etc.
I'm curious why you say "when visiting a AMP-enabled web pages, the pages do not render at all". I'm not seeing the same result. The first two 'AMP' pages I tested loaded very quickly and were easily readable.
I use Firefox with NoScript, which is definitely blocking the JS from ampproject.org. I also use Privacy Badger and uBlock Origin (thanks btw) and I'm not having any trouble at all. Here are the figures for the two pages I've tested with so far:
I've used NoScript for quite a while and while I don't expect every page to work perfectly with it, the speed gains are incredible! AMP and NoScript aren't directly comparable but they seem to be accomplishing the same thing for me. Only one of them is also blocking third-party tracking and delivering feather-light pages which nearly always render acceptably.
Can you please clarify whether you mean the pages are totally blank, or if they just don't render the same as if you had allowed them to execute JS? (obviously if you globally block ampproject.org you can't access even their index.html page but that's not the info I'm after...)
This is what I get if I block `ampproject.org` (which -- given its purpose -- is meant to become ubiquitous): A blank page.[1]
In reality, the speed gain (which is the advertised benefit of AMP) is just a matter of avoiding to pull all the optional 3rd parties.
For example, a non-AMP random article from the same site[2], the page loads quite fast when I block all 3rd-party scripts/frames, except those from `vox-cdn.com` and `voxmedia.com`. The page renders fine -- with the virtuous "side effect" that 18 more 3rd-party are not logging network requests from my IP in their server logs (in this specific case).[3]
The Verge's page initially gave me a plain white page, but then I realized I was blocking JS from ampproject.org but allowing it from theverge.com, and that combination isn't supported. You have to either block or allow both.
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.
"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."
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.
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.
I don't think it will necessarily fail, if AMP has a good ad story.
I think some publishers realize that ad blocking is taking off in an accelerated pace since iOS 9. If they have to choose between a universe between no ad revenue (because ad blocking) and more behaved and subtle advertising, they will choose the latter.
Given that AMP is pushed by Google, it's pretty obvious that they did think about ads:
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.
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.
Well, most publishers actually use fairly optimized HTML/CSS and most publishers use a CDN. But there's only so much you can do if you don't want to get rid of those 5 ad networks, 7 analytics services, 2 sidebars and just generally a whole bunch of crap that has nothing to do with the article.
The innovation of Facebook instant articles and AMP isn't technical, it's that they have been able to convince publishers that getting rid of all the bells and whistles will actually benefit them – and that if they don't do it, it will harm them because huge traffic drivers like Twitter won't put up with it anymore.
I disagree - most publishers I've seen (including large and mid-level) have some of the most bloated HTML with megabytes(!) of javascript and CSS just for rendering + all the other stuff you mentioned. They are definitely not optimized.
I dont think there is any innovation at all with either Facebook or Google, it's all about keeping the user on their service longer and by hosting the content themselves, they increase speed and claim more user time. It's a pure monopoly play with Apple, Google, Facebook having far more leverage than publishers (who have really none these days). Pubs need traffic to survive which is why they are willing to work with this, but the revenue potential is still up in the air so long-term sustainability is not anywhere near proven. I'm not convinced that this will work as a viable model, beyond the technical implementation.
> I disagree - most publishers I've seen (including large and mid-level) have some of the most bloated HTML with megabytes(!) of javascript and CSS just for rendering + all the other stuff you mentioned. They are definitely not optimized.
The search engines just need to penalize sites or result pages that have all these piles of bloat in them if they want to be a forcing function in the mobile web getting quicker. Push crappy experiences lower in the results and you can be sure news and aggregator sites will clean up their act.
That Google et. al. are publishing a parallel framework to HTML indicates their goal is not just making mobile web faster, but in controlling that experience, to whatever end they may have in mind.
> The search engines just need to penalize sites or result pages that have all these piles of bloat in them if they want to be a forcing function in the mobile web getting quicker.
Isn't Google already claiming to demote sites that are slow to load, have content below the fold, etc?
What's sad is that this is just optimized HTML + CDN packaged up by Google and heralded as some big innovation.
I think AMP is useful as a standard: setting a set of requirements to be considered an AMP page. Having such a brand plus possible beneficial treatment in search engines, will encourage publishers to adopt it.
Sometimes a strong incentive is needed to change things.
Two scrolling behaviors that I found odd on this page and on the NY Times example[1] on iOS:
- You can't scroll to the top by tapping the status bar.
- The scrolling momentum is different. There's less friction, as if you were scrolling through a list view (e.g. Mail).
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.
-webkit-overflow-scrolling makes scrolling feel like native, important for web apps and web views. It's like when you make an overflow: scroll div, and you make your main content inside this it.
It also ads the permanent url bar at the top and the navigational arrows at the bottom. This is useful for some web apps, because if those weren't permanent, you couldn't have buttons fixed on the bottom. This is because when you would click them, the back/forward arrows bar would appear pushing your button up so you have to click it again.
I used to use it but I've stopped because it's a whole level of complexity on your complex app.
I wish iOS safari scrolling would feel like native. Many people are using this property for this reason only, sacrificing screen space (the always-on browser interface). It used to be worse with the small screen of the iPhone 4.
If you take a look at the source[0], you'll notice they roll their own viewport renderer, presumably as a way for them to do their "tracking pixels". I imagine this might be what causes the difference in behavior? If anyone more knowledgeable could jump in, that would be cool.
I feel this is Google's response to Apple's ad blocking push (maybe push is too much here, what's a better word?).
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.
We don't need two behemoths fighting over the control of our web.
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)?
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.
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.
Not really. To continue the analogy, in HTML doesn't really have keywords, but has syntax in the form of brackets, quotes, =, etc. Tags are like function calls, and the built in tags are like the standard library. Until custom elements you couldn't declare "functions".
"Performance is just the story they are selling in exchange of absolute control of the Web."
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).
Phrases like "make the web faster" are disingenuous and should not pass any intelligent user's BS filter.
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.
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".
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.
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.
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.
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.
So I as a user put up with all that loading of resources, because I don't have the time and money (resources) to set up my own version of the web. And because I consume a lot of content I don't otherwise pay for.
To pretend that the infrastructure that allows companies to pay for the content I want to consume is incidental to the true purpose of the web (text documents??) is pretty narrow.
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.
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.