Just for kicks, folks, let's collect all of the adjectives, adverbs and qualifiers used in this post to describe ~AMP:
* a leading format
* consistently excellent
* invest strongly in ...
* well-lit
* user-first
* instant-loading
* tightly-integrated
* highly-optimized
* great
* well-lit
* great
* well documented
* easily deployable
* validatable
* opinionated about user-first principles
* fast development
* constant adjustment
* more important than ever before
* invest strongly in ...
* engaging storytelling experiences
* pushing the boundaries
* deep integrations
* well under way
* super excited
* instant-loading
* well-lit
* great
* continue to invest heavily in ...
* continue to innovate on ...
* incredibly excited
* can't wait
I'm imagining a Dilbert cartoon, where this list is a cheatsheet of things you can say about your project to get approval from your pointy-haired boss...
Most of them are silly, some of them are true. It is super integrated, it is fast, and it is opinionated. User-first is debatable, but it's not exactly publisher first and it's definitely not (external) advertiser first. No idea what well-lit means.
I guess the takeaway is that the garden is great, build the walls higher?
Text editors should have a feature to warn about a high number of qualifies/adverbs: "you are using to many qualifiers and adverbs, you may look biased to your readers, it may be a good idea to remove or rethink some of them."
I suggest everyone use one of many popular & excellent tools to check your professional articles for excessive & unnecessary words & long or hard to read sentences, for example here are some amazingly free tools I really enjoy:
But as I said in my post, the problem with posts like today's AMP blog post is that they're too full of jargon to be comprehensible to a general audience. The Web Packaging standard is really cool, but today's blog post just linked out to a ton of web standards without defining them or explaining how they'll work in the future.
If you've got your head deep in AMP's community, this post is quite meaningful, but to everyone else, and especially to the huge community of developers who hate AMP, it reads like Greek.
It reflects a core problem with AMP's developer outreach strategy: a refusal to accept and acknowledge criticism. There are overwhelmingly more AMP detractors than AMP promoters, and the detractors have good arguments, arguments that the AMP team even kinda sorta accepts (which is why they're trying to push through these browser standards, to address the bugs).
But you'll never hear AMP technical leaders like Malte Ubl or Paul Bakaus saying, "Yes, we accept that criticism, and the problems with AMP are really serious, and here's what we're doing to fix this. In the meanwhile, for many sites the tradeoff is worth it anyway."
The top thread in the HN thread was not whether the AMP brand was toxic but why the AMP brand is toxic. I think that if the AMP team had somebody focused on telling AMP's story, humbly and honestly, with a focus on the web developer community on HN, Reddit, Smashing, etc. it could have really helped.
Now, I think it's too late. The new Web Packaging thing shouldn't be called "AMP." The new "AMP for email" thing shouldn't be called AMP, either, because everybody knows that AMP sucks, and there's really no way to claw your way back from that.
tl;dr: iframes cause all of AMP's problems, but they provide unbeatable performance, thanks to prerendering. Prerendering is faster than http://motherfuckingwebsite.com. The Web Packaging standard will allow Google to prerender sites in search results without AMP, and without violating users' privacy.
But here's the point: most people think that Google wants to host nytimes articles on google.com, to seize control of the web's traffic. They don't. They've done a bunch of work to get out of that business while preserving the performance benefits of prerendering, but nobody knows that, because they talk about it in bizarre technical jargon like today's OP AMP blog post.
Why should we trust a monopolist that -- and this is totes a coincidence! -- is pushing a standard that breaks all urls to point to them? This is the next attempt after google plus or whatever their stupid social network is/was. They're basically terrified of facebook and, instead of supporting the internet, they're trying to become fb. But in your browser.
Pretending google didn't want to steal all urls requires actively ignoring the last 10 years of google's corporate decisions.
The user experience they wanted to achieve (provide an Apple News and Facebook Instant Articles experience on the web) was not technically possible. They added the hacks and workarounds that is AMP + AMP Cache + News carousel prerendering to Google to create something competitive.
Now they're working with the standards bodies to remove the need for the hacks they've developed. Web Packaging (for loading and verifying a bundled website - this is the preloading part) and iFrame Promotion (for 'promoting' an iFrame to the root browsing context - this is the 'clicking the search result and having the resulting page display instantly' part) is really cool and it'll be great to have this available to everyone without the downsides that Google's current solution has (URL fucking)
Weird how the technical compromises they just had to make work out, well, wildly to their advantage. Better not piss off google or they break all links to your site!
It's not up to Google to deploy. It's up to the browser vendors to implement, and that won't happen with Apple dragging its feet on every web standard.
what do you think is too technical in the linked blog post? i have never worked with AMP code or implemented AMP, and i was able to understand it just fine. And i don't think i'm any cleverer than the average web developer on here.
They're expanding the carousel of AMP links on the SERP to include content packaged using the new web packaging standard . Seems straightforward enough to me.
>The new Web Packaging thing shouldn't be called "AMP".
So, this is pretty much everything the HN crowd was asking for, right? Pull AMP apart into a bunch of web standards and switch Google search to promote any content which follows those standards rather than AMP content specifically?
Probably because AMP should not have existed in the first place :) We already have everything we need to make fast and performant pages - we can't do it, because of marketing and trackers and spying and shit though: not technological factors, but human factors.
You're absolutely right. Everything we need, in a strictly technical sense, to make wonderfully fast and performant web pages already exists. And has accomplished little, because as you say it's a human problem.
AMP exists because Google figured out a way to make non-technical humans want to be fast and performant. It's a nice carrot to offer people who normally don't care at all about performance.
And yet, AMP has succeeded at getting publishers to deliver fast and performant pages where other efforts did not.
I dispute the idea that technological factors are not at play here. AMP's preloading and automatic CDN caching system have a pretty big impact on load times, and its technically-enforced restrictions on what sort of performance-impacting content publishers are allowed to include in their pages seems to do a pretty good job of ensuring pages do not become bloated.
The fact that Google Search is a monopoly is not a technological factor. Google gives preference to AMP sites on Google Search, therefore publishers must implement AMP.
I actually have a lot less issue with AMP as a technological solution, as I do with the Google's "our way or the highway" treatment of the Internet. Google uses both it's search monopoly and it's browser monopoly (and often, both at the same time) to force the entire world to do whatever Google wants them to.
Sometimes you might perceive the result to be "good", but that doesn't justify the behavior. That's why another technical implementation change blog doesn't improve anyone's mood about the whole thing: Because Malte Ubl is still pretending he's on #teamweb and not #teamgoogle.
You're really missing the broader context here, which was the rise of wholly proprietary news formats like Facebook Articles and Apple News. This was Google's entry into the market that was very much #teamweb vs Facebook and Apple's #teamproprietary because it based itself on open web standards and had a clear pathway towards standardization (that you see materializing in the OP's article).
This was the best solution the web could hope for that balanced open standard concerns with the necessary commercial backing that advantaged AMP's proprietary competitors.
Fair point, but that problem (at least as far as AMP is concerned) is exactly the one this blog post is addressing: Google is planning to stop pushing AMP specifically in its search results and instead push a set of open web standards which achieve the same technical goals.
Even so, I’m tired of jumping through hoops to adhere to bullshit standards that make life hard without any actual benefit. We have HTML and CSS, why do we need AMP? How does my personal webpage benefit from HTTPS? Why did they enforce mandatory HTTPS across the entire .dev TLD in WebKit, breaking my local test env, when it’s only used by a few internal projects at Google?
They seem to have a vested interest in making web development harder than it needs to be.
The non-AMP page is twice as big and takes an order of magnitude longer to load. So, yes. I would _absolutely_ describe the AMP version as a "slimmed down performant webpage".
Could it be better? Of course! But users are still _much_ better off with AMP than without, at least in terms of performance. (And that's ignoring the fact that preloading is part of AMP. It's not "cheating" if it works in a real-world situation.)
My personal non-AMP page weighs ~800 KB (including all images and JS). It still has no chance in hell competing against a 2.4 MB AMP page because I don't have Google's CDN.
Even if I follow all of Google's own performance guidelines, it won't help, as AMP pages load faster than text-only http://motherfuckingwebsite.com
> It's not "cheating" if it works in a real-world situation.
Call it cheating if you want. I as a user still strongly prefer a "cheating" site that loads instantly over a "non-cheating" one that I have to wait 5 seconds to load.
Google could still be planning to keep the top banner, the left/right swipe to your competitor functionally for carousels, etc. That top banner, for example, has an [x] button that end users expect to dismiss the banner and stay on the page. Instead, it goes back to Google.
The negativity is because they aren’t being explicit as to what is actually being delivered. They are still retaining the right to run their own arbitrary JS on YOUR site, which could do almost anything they want.
TLDR: too soon to tell how genuine the message is, and Google isn’t working very hard to clear it up.
And AMP having "the right to run their own arbitrary JS on YOUR site" is not something that can happen when you're not even being required to use AMP in the first place:
> we now feel ready to take the next step and work to support more instant-loading content not based on AMP technology
Can you quote something specific that says either the top banner or carousel takeover UI goes away? To me, it seems very high level and opaque. They could have been very specific, but haven’t been.
Web packaging does still require including a named google js url, right? With little restrictions on what it’s able to do with the DOM.
Why, for example, is there no Google source saying that the AMP page header is going away? They have not yet specified if they will only allow a very specific implementation of web packaging that allows your site into the carousel and other top of page search result URLs.
Probably because the actual message is buried under a mountain of self-serving, AMP-praising buzzwords ("user-first," "well-lit," etc.). The post spends so much time patting AMP on the back that it's easy to miss the point that it's actually announcing Google's retreat from AMP.
If they'd taken the same message and presented it as "we hear you: forcing you to reformat your web site using our own format sucks, and tying your search visibility to your adoption of that format sucks even harder, so we've decided to stop doing both those things," fewer people would have missed the point.
I managed to completely miss the point in the post. So much bloviating I switched off before I got half way through, and I'm someone who loves reading and routinely reads long blog posts.
”we now feel ready to take the next step and work to support more instant-loading content not based on AMP technology in areas of Google Search designed for this, like the Top Stories carousel”
Seems encouraging. Any step away from a walled garden is good.
I wish one day marketing, print designers and useless business architects would just step back and let me build a damn page.
No trackers, no spying, no fancy multilayered parallax video scrollers, no animated video carousels, no fucking ads, no taboola shit, no related clickbait articles, no tag cloud sidebar, no ooh-so-shiny bleeding edge web frameworks that has a lifecycle of a single year (megabytes of minified angular), no isomorphic shit, just a plain site with the relevant information and minimal styling.
We chose to use PHP for our site redesign after using React, Elm and Jekyll in other projects. It’s really liberating. No spending days setting up a build/deploy process. Gets out of your way unless you actually need it. Everything including the kitchen sink included. Pre-installed on all Macs. Our designer can code and deploy changes by himself.
I used to hate PHP. Then I tried the alternatives.
It's not the framework, it's the people (and their whoring greed mixed with dilettantism). I love vue, I'm okay with A5 and react. I usually do node stuff, but php is okay nowdays, symphony is a good thing too.
From the point of view of a user concerned with Google's influence, this seems like a good move.
From the point of view of a SRE who would have to help configure a server side implementation of web packaging, having yet another http request/response type to build and maintain seems like a bloody nightmare. And OCSP with the signature when Chrome themselves have disabled its use? It also requires custom behavior from the client, all-but-guaranteeing it won't be broadly honored.
And ultimately, I'm confused about how this replaces, or supplements AMP.
I don't believe it's intended to really replace AMP. It sounds like Google is establishing a set of performance guidelines (as many have been encouraging them to do). If you want to meet those guidelines, one way is to use AMP which I expect they'll continue to maintain and build on. If you don't like AMP for whatever reason, you can use whatever solution you want to meet the same guidelines.
Google will continue doing what it does: caching and preloading whatever content it prefers (select publishers, select advertisers) and penalize everyone else even if they follow all of Google’s guidelines to a T.
Web Packages, no matter how well you disguise them as a web standard, will not solve that.
> Heck, the blog post is hosted on WordPress instead of Google's own Blogger.
That made me chuckle, and gave me a sense of how much they value this PR chum. Please, guys; at least make a semi-convincing attempt to pretend you think we're not morons. Hosting a blog post on your own domain would cost you almost nothing. You could even load it up with your own ads to recoup the cost.
Lots of talk and no code or proposals, in so far as I can tell.
The thing that makes the web slow isn't web standards, but too many ads and too much tracking code. If only there were a company that controlled a lot of the ads and tracking code on the web...
There's an IETF proposal for certificate-signed web content (Web Packages) which can be rendered offline. The browser address bar will no longer show the URL of the web server (e.g. Google AMP), it will show the authenticated origin of the Web Package.
I'm wondering what happens if web packaging really takes off. Could mirror sites basically do what ipfs does, but without inventing a new protocol? Or do Cloudflare and other content networks already do everything website owners want?
The fact that Malte is still trying to call the AMP project "well-lit" is really what throws a lot of question on this blog post. AMP is not a "well-lit" project.
Why not hand AMP itself over to standards groups as well as all of the other things mentioned here? What about the proprietary GMail implementation of AMP4Email? Or the fact that none of the justifications for AMP given in this (or The Verge interview[0]) hold up as reasons for AMP4Email.
How so? As the blog post points out, the whole thing is open-source with almost all discussion surrounding the project happening out in the open on their GitHub repo. You might not agree with the direction the project is going, but I'd say it's about as well-lit as any open source project can be.
It seems like that until you start asking questions. Then you discover that AMP4Email is controlled by Gmail team, that you can't get a straight answer to save your life, and when they don't like the topic, they subtly threaten the Code of Conduct when no violations are occurring to indicate they are actively searching for an excuse to close down discussion.
Posting some discussions in the open doesn't make it well-lit. There are many projects following this path where the real decisions are made in private meetings by people in the controlling companies. Open washing is not open source.
Indeed, while discussing AMP4Email, it seemed that, despite being a proposal in the AMP Project, all decisions for it's implementation were already made (and committed to) by the Gmail team, it had already been "reviewed" by a security team (although any such security protections are limited to Gmail's own internal protections, other implementers are on their own), and there seemed to be no opportunity for the greater email community to comment before these things were decided.
Having it up on GitHub after that doesn't really mean much. This is the same for Android and Chrome, of course.
Well, technically, it is. Open source doesn't imply governance by an independent standards body. There are just requirements for what counts as an open source license.
A project run by a "benevolent dictator for life" (like Python or Elm) is entirely compatible with open source. The same is true for a project run by a corporation (like React).
With difficult discussions being locked and limited to collaborators.
With the main answer to questions being, we can discuss this somewhere else, some-other (unknown) time in the future, usually in a more private setting. Unless pressed further.
Or as carmforce(Ubl) so nicely put it. "our project, our rules" but those rules keep changing, are not public and the raised issue about defining/clearing up those rules is obviously not a priority.
> ... open-source with almost all discussion surrounding the project happening out in the open on their GitHub repo.
Yeah, well... "Open-source" in the sense that they throw something over the wall from time to time. "Almost all discussion" in the sense that they use a heavily-moderated public newsgroup for some things. It's better than completely internal development, I guess, but don't kid yourself: it's a PR exercise coupled to a near-complete capture of the RFC process.
Handing over AMP would prevent the standards committee from making backward-incompatible changes to please other participants. It seems better to start fresh and have a compatibility break? Not to mention that there's little point in preserving a name that's pretty controversial.
And in the meantime, AMP would still need to be maintained.
We've seen this before in less controversial areas. For example, SPDY was proprietary and HTTP/2 is a standard that entirely replaced it.
I'm wary of AMP4Email as well, but the process of doing something quick and dirty and then standardizing the 2.0 version (under a different name) is pretty common.
Google is not replacing AMP, or promoting the standards group to replace AMP. Google is using things like web packaging with AMP, and intends to continue to do so. Their statements today, if anything, state a clear intent to continue to invest in and build on AMP.
So, while all of these other components are going to be going to standards orgs, why not let them also have AMP? (A standards org is never beholden to keep an existing standard, they can always make a new one.)
No, together they give anyone aggregating content to do that, and they allow CDNs to serve up top level content with the original domain intact.
So much noise in these threads deliberating trying to concoct some hidden agenda around this rather than the obvious: the mobile web was a looming disaster, years of people advocating for writing fast pages failed, to the point that native apps were becoming silos to serve proprietary news content from. All of the macho-code jockeys here boasting how they can write fast pages don't seem to get that like 100 million pages out there are slow as molasses and efforts like AMP manage to fix A LOT of load issues that independent super-hackers didn't.
Independent efforts to spur people to optimize their sites and get some loading consistency failed -- multiple times. An industry wide effort is needed that deliberately pushes those, by carrot or whip, to improve the situation, giving them a cookie-cutter formula -- a subset of HTML and structure, validated for optimum parse, render, and caching, so that it is easy and consistent.
AMP was the first attempt at this. People don't like it because it's proprietary, don't like the UI choices, ok then, let's rectify that and get the W3C and browser vendors on board to have a neutral version. Let's address all of the problems and criticisms and make a public standard.
But stop pretending that if no one does anything the problem will go away. Yes, eventually it will go away, as more and more websites are replaced by native apps or embedded viewers in messaging or social apps like FB or WeChat, which become new proprietary browsers that eschew the web.
Accusing the AMP guys of ulterior motives is really wearing thin, AFAIK these guys love the web with a passion, they're trying to fend off an assault from native platforms. Most of these guys could go work on new hot-news at Google like new machine learning projects, they could have their pick of work, but have dedicated a lot of effort to make faster, a platform that a lot of people don't care about anymore and view as legacy.
How about a holding your gun-powder for once and see what comes out of this rather than setting off nukes.
> Accusing the AMP guys of ulterior motives is really wearing thin, AFAIK these guys love the web with a passion, they're trying to fend off an assault from native platforms.
You are confusing individual people working on the project and the corporation that ultimately decides the entire direction of the project.
You are also assuming that all people are inherently good and will immediately leave if something morally questionable is asked of them, and that people can even realise that something is morally questionable.
In no particular order:
- Google is a corporation which is driven by two metrics: advertisement revenue and Monthly Active Users. AMP is driven to improve and increase the two.
- Every single discussion outside of implementation questions have been shut down by the AMP team. The latest round was about AMP4Email where the team has gone out of the way to derail, shut down and outright ignore any direct questions: https://github.com/ampproject/amphtml/issues/13597
- A regular AMP page rarely weighs less than 1 MB when reached from cold cache. The only reason they are fast is because: Google dominates search, and Google aggressively preloads AMP pages from its own huge geographically distributed CDN.
So when you click on an AMP page it's instant only because it's already been preloaded. Meanwhile Google's own page speed tools say that AMP are not fast. And to add insult to injury, AMP is not even valid HTML5. https://ferdychristant.com/amp-the-missing-controversy-3b424...
Of course independent superhackers can't do anything because they don't have Google-level infrastructure. Because Google makes AMP appear to be faster than even http://motherfuckingwebsite.com which is just text.
Just a quote: "The performance benefit of prerendering is enormous, so enormous that prerendered pages can load hundreds of KB of JavaScript and still display “instantly” by the time the user taps on a link." https://redfin.engineering/how-to-fix-googles-amp-without-sl...
- Taking the previous bullet point further: AMP is a hack that has nothing to do with actual website performance or "slimming down" of websites. The only reason AMP exists is because of Facebook Instant Articles. It's not because of walled gardens. It's not because of "open web". It's just the desire to not be outdone by competition and the strive for ad revenue and MAUs.
Any and all concerns about AMP where entirely dismissed by Google (and AMP team) until a significant portion of publishers have started voicing their concerns and some have even started pulling out of AMP.
Why publishers you ask? AMP is primarily targeted at publishers and publishers are the only ones even allowed to somewhat participate in AMP. To quote "Standardizing lessons": "constant adjustment to publisher and user feedback." which is half truth at best. The only working group on AMP is amp-news-publishers (https://github.com/ampproject/amphtml/blob/master/contributi...), and any "user feedback" that is allowed is "intents to implement" and comments on how a feature is implemented. All other discussions are shut down.
- The new standards proposed by Google only seek to cement the status quo.
Web Packages is a way to store signed prerendered and preloaded pages on a CDN
iframe promotion explicitly describes how and why AMP pages are "fast": they are preloaded in invisible iframes during search. The only goal of this proposal is to help google make those frames visible and switch the browser URL when the iframe is presented to the user.
This does not actually solve any performance issues. You can still develop your 8 MB site. However, it will load instantly just because Google has preloaded it while you were searching.
Do not be fooled by the use cases. The primary benefactor of aggressive preloading and caching is Google, who already has the entire infrastructure in place, and dominates search. No mater how much you try and adhere to all the performance guidelines, you will never beat a pre-rendered and preloaded page stored on Google's CDN.
- And yes. Ultimately the AMP team in its entirety fails to accept or acknowledge any shortcoming of AMP. Even the "Standardizing lessons" spew the same easily falsifiable myths around AMP heavily sugar-coated in self-aggrandizement.
On top of that, no matter how many times they say that the process is well-lit (they say it three times in the article), the process is entirely opaque, developed by Google, for Google, and in Google's products and then presented post-factum as a "standards proposal".
Is anyone out there doing anything with AMP besides Google? It seems like it could be super useful for aggregator sites like Reddit. Or HN for that matter. Like a heavyweight version of OpenGraph meta tags.
The reddit AMP pages you land on from Google searches are particularly irritating. You aren’t logged in when you go to them, and various UI expectations are broken. Web packaging could help here since it would remove the google url, allowing cookies/sessions to function again.
Web Packaging (at least on its own) wouldn't help with that, since the whole point of that standard is to allow content to be prefetched from a CDN (like AMP pages currently are), and CDNs can't cache content that's user-specific.
What _would_ work is serving the main content immediately, then using JS to fetch user-specific stuff after the page load.
I meant from the other direction. Like Reddit could pull the AMP versions of pages users link to.
As for their implementation of AMP pages for Google's use, I think that's sound strategy. People landing on Reddit from Google are at the lowest level of engagement and a lot of sites serve more ads conditionally based on your level of engagement. Native visitors get a better experience, logged in contributors get the white glove treatment.
CloudFlare, Bing, Baidu, and Yahoo Japan run their own AMP caches. I agree that it makes sense for external link heavy sites like search engines and Reddit.
Async still prevents the DOMcontentloaded event from firing, and if you can’t sandbox JS into an iframe you’re screwed security-wise if the linked source gets owned or turns evil.
> From a peak of 1.9% conversion rate at around 2 seconds
This sentence and the graph it accompanies seems to imply that if your site is too fast it could reduce your conversion rate. What's going on here?
Well, at the bottom of the article that graph came from:
> What about all those fast pages with low conversion rates and high bounce rates?
> Good question. Faster pages should retain and convert more visitors, right? In general, yes, but some of the speediest pages on a site are 404/error pages, hence the poorer business metrics.
It seems like you'd want to control for this, to get statistics on bounce rates only for pages that wouldn't otherwise bounce the user anyway.
