This move is aimed to quell the critique based on a hypothetis that contributions to AMP that go against Google's vision would be rejected. It also is a move in good faith to transition the project's governance away from Google to a goal-oriented crew of many interested parties who can derive benefit from its solutions.
I've written about AMP on here a lot [1], and frequently include this disclaimer. My views on it have evolved as time went on, being more sympathetic to some of the critiques, but also to the efforts of the AMP team to address many of the complaints.
While a number of technical critiques to AMP remain, increasingly, the criticism is:
- ideological (e.g. "Google is trying to destroy the open web"),
- misinformed (e.g. "Google is stealing traffic from publishers"),
- nihilist (e.g. "everyone who uses AMP only does so because you need it to rank high in search"),
- full of naïve bravado (e.g. "all we need is clean HTML"),
- or related to the fact that Google's mobile search page has stealth-morphed into a captive newsreader that surfaces AMP-ified articles with Javascript without ever leaving the page.
Out of these, the lattermost is the only one that raises a true anticompetitive concern, which Google seems keen on ignoring. However, I'd say that's for the Google Search team, rather than the AMP team, to address.
It doesn't change the fact that AMP is mostly about Google et al. gaining control over the web.
- What you call ideological is a mere fact; google is by definition not an open source movement, and it is creating things with the primary purpose of gaining more users into their own gated ecosystem
- Google is obviously gaining control about how content is rendered, which makes it possible for google to control the monetarization
- If you ever spent some time among SEO and marketing people this is a pretty obvious conclusion, as those people usually run that part of a company
- There are very simple solutions available for making websites faster, it just so happened that AMP was a great way for Google to kill two birds with one stone, i.e. making the web faster and more googly at the same time; their incentives are just not so aligned with other parties
All in all the entire thing is similar to the attitude of Google with their plan of changing how URLs work.
The problem is not that it is in their best interest to control the web, the problem is that Google seems entirely unaware as a company that others want to have a different version of our future, and that it is entirely legitimate to not use Google solutions as a foundation of that future.
As a whole company, Google appears to be somehwat autistic to me.
"But this is good for everyone" Google says. No it isn't.
The way Google is crippling open source is by offering open source on paper, but then controlling the gateways, like forcing smartphone manufacturers to ship their version of Android. So on the leadership level it is also acting deeply hypocritical.
Looking beyond that, it would be nice if you had engaged with the GP post instead of talking past it. Most of your post seems to back up the summary there.
Like, "makes it possible for google to control the monetarization"...in what way? It always comes up in these threads that you can include any ad network in AMP pages, but it always comes up again.
> their plan of changing how URLs work
Their non-specific plan that displaying URLs in the location bar needs work?
First, by crushing all the smaller players in ad-tech that can't keep up with all the criteria needed to be included in AMP (Ads are very limited on AMP). Fundamentally, by essentially controlling how content and ads are displayed and being directly involved in this with a lot of available resources and no barrier to entry. It is a bit subtle, which is why others are still playing along right now.
Regarding the URL thing, they announced "Oh by the way, we have too look into this URL thing, we may change that during the next years, it's not good"
This was published via Twitter.
When devs complained and said that things like this needs to be discussed openly and not via invitation to the Google HQ, they got ignored.
This is what I mean with 'autistic', which maybe isn't accurate, I don't know. You could probably say 'arrogant' instead.
Here's a very fitting quote:
"This guise of openness is perhaps even worse than the Apple News Format, which at the very least does not pretend to be an open standard."
> all the criteria needed to be included in AMP (Ads are very limited on AMP)
What does this mean, specifically? It sounds like you're saying that advertisers have to get their shit together and not provide a crummy experience to users to be valid AMP.
What, no more monkey punching? No more meta-meta-meta ad networks that load 4 nested networks that sit in your browser and auction off the right to auction off the right to display an ad? No more epilepsy-triggering flashing images? No more 2MB js-based animations that kill your battery life and distract you? That sounds... great actually, where can I sign up?
AMP certainly has benevolent side effects for the user. Google is obviously adding tremendous value to what they offer.
It was a genius move by Google to come up with AMP.
How can you solve the problem of an ad-infested web if you make most of your money with Ads? You can't simply block your competition within the dominant browser, that would bring anti-trust action on the scene.
AMP is the answer. You create something that makes publishers give up their freedom willingly.
Then Google realized that even AMP is too dangerous in the current culture of techlash. So they came up with this idea of creating an open governance model. The public is basically forcing them to do this step, which is a good first step.
It's not very surprising that google's is the first major ad network that is AMP compatible (it's not my favorite part either), but the requirements are quite public [1]. I'm also very glad that AMP is moving to an open governance model, this step is absolutely necessary to make any real headway to becoming more widely adopted.
In an ideal world AMP would just be a validation step -- defined as a specific subset of technologies and behaviors -- that search engines and your browser performs when indexing/viewing content, and then a system for reporting violations back up to inform ranking. Since we're living in my fantasy land lets also have all publishers host their own first party ads too.
> makes publishers give up their freedom
There's nothing about AMP that inherently requires giving up freedom. Who hosts the content is mostly a matter of caching and data locality (which just so happens the vast majority of publishers fail at), and non-google ad networks are fully supported.
Apple News and Snapchat Stories appear to be proprietary content viewers that don't directly affect the open Web. (I don't use Apple or Snapchat and probably never will.) AMP is aggressively hijacking the entire Web, and there is no way to avoid it. Google is even trying to hide URLs in Chrome so that users won't know the difference between AMP (a proprietary scheme masquerading as "open source") and real open standards (HTML).
The speed problem is about JavaScript, not HTML. The industry needs to address JavaScript bloat, not create an alternate form of HTML.
> The problem is not that it is in their best interest to control the web, the problem is that Google seems entirely unaware as a company that others want to have a different version of our future, and that it is entirely legitimate to not use Google solutions as a foundation of that future.
This is really well stated.
> As a whole company, Google appears to be somehwat autistic to me.
And... this isn't. Being proud or strongheaded, or having dysfunctional internal politics is not remotely the same thing as being autistic; let's avoid stigmatizing.
----
I think that Google has a lot of self-confidence, and it bothers them that they need to do this dance with other members of the community. Google makes its own decisions, on its own, and then is surprised when other stakeholders are "difficult" and don't just go along with their vision. "Because obviously we wouldn't be proposing something unless we were sure it was the right decision, so why is everyone running around questioning it?"
That's not to say that there aren't good intentions (although it's become painfully obvious that when well-meaning employees clash with upper management on subjects like privacy or advertising, upper management will always win). But those good intentions have to be coupled with an understanding that the web is bigger and more complicated than Google is. Google isn't the web's parent or guardian, it is an equal stakeholder sitting at the table next to other equal stakeholders. It is not a laudable act of charity for Google to listen to those stakeholders or to include them in decision processes. It is expected.
No single company is ever going to be diverse enough, or smart enough, or benevolent enough to control the web. Google certainly isn't -- ignoring user-hostile groups within upper management, Google will still only ever be able to solve problems from the perspective of an advertising company.
Moving AMP to an open governance model is very positive, but doesn't get rid of my concerns about the technology. It's a very Google move to go off and do a thing despite significant criticism and pushback outside of the company, and then once they've shaped the result according to their own specifications to come back and say, "See, it's a community effort now. Why are you complaining?"
The URL stuff you mentioned is a perfect example. This is the Chrome dev team internally deciding that URLs are an "obvious" problem, releasing a browser update that acts on that internal decision, and then responding to critics by saying, "well, we're just trying to start a conversation. Let's talk about it."
That is the wrong order to use when messing with how the web works.
It's not even necessarily a question of what's specifically wrong with AMP at this point -- it's that if we were collectively trying to solve the problem of page bloat, we could probably do a much better job in general than AMP does. AMP is an advertiser's solution to web bloat retrofitted to address the broader community's criticism. So you get Javascript requirements on each page load, you get URL breakages that have to be solved by future standards, you get prescriptive metrics about what components Google thinks pages need rather than descriptive metrics about what render targets a page should hit.
Not necessarily because Google is evil, but because Google isn't the entire web and can't represent all of its needs.
> it's that if we were collectively trying to solve the problem of page bloat, we could probably do a much better job in general than AMP does.
There are a lot of people interested in reducing page bloat. Outside of AMP, I'm not aware of any other efforts. (Discounting just telling people to write better pages which is basically just telling people to status quo harder)
One of the repeated critisicms of AMP seems to be that its debloating could easily be done better - but if it's so easy, why is no one doing it?
> (Discounting just telling people to write better pages which is basically just telling people to status quo harder)
Well, AMP is just that, telling people to status quo harder, but with incentives from a monopoly (or rather abuse of power, forcing others to do that) and in a specific way said monopoly wants it.
I would argue that there are efforts, many of them in radically different directions from AMP, and many of them already far more effective than AMP. Adblocking, for example, which several browsers now have built in and explicitly advertise it as a way to speed up pages and increase performance. Reader modes and Pocket will also take existing pages and re-serve them with cruft removed. Before HTTPS became the norm, Opera was offering turbo modes that allowed users to opt-into middleware rather than publishers. And along those lines, Opera Mini is still an incredibly popular mobile browser as soon as you leave the US.
These are very different solutions from AMP, but that's the point. A diverse set of solutions to page bloat will look diverse. It won't just be 5 companies doing the same thing slightly differently.
In regards to why there hasn't been broader success with the solution that most people default to, "just write better pages", that's because you need a carrot, and Google has that carrot -- preferential search placement. The original post dismissed the idea that people were only interested in AMP to get into search rankings, but I think it's a very strong argument. Obviously news sites are using AMP for reasons other than making their pages fast, or they would have made their pages fast before AMP came around. It is, pretty objectively, not hard to make a website that would be faster than most news sources. The problem has always been how to make publishers care.
The fact that Google currently has the most power to dictate to publishers how they structure their content does not mean that Google's decisions on how to wield that power are always in the community's best interest. If you wanted to build an alternative standard to AMP built on the input of many different stakeholders, you would almost definitely need Google's help implementing it. That's not the same thing as saying that Google should decide on its own what that solution is.
There is, finally, the kind of controversial answer to this question. I don't like this answer, but I don't dismiss it. It's that the broader web community may not actually care about web speed. I am very interested in finding ways to reduce page bloat -- but what if it turns out that most of the stakeholders online, most of the people who are actually building websites and visiting them, disagree that this is a significant problem?
What if the solution to having slow webpages is literally just that users click away after a few seconds and go about their day? What if it's just that slow websites will gradually get less traffic, and if they don't care about that, then we shouldn't either?
I'm skeptical of this answer, and I would be very unhappy if it turned out to be true. But I can't dismiss it entirely out of hand. In a large, diverse web, it is possible that there will occasionally be broad consensus that goes in the opposite direction of what Google or I want. And part of embracing that diversity is being at least a tiny bit open to the idea that the web is bigger than what I want it to be.
But I don't think that's likely. I think the most likely answer is that publishers are embracing AMP to get search priority, and if Mozilla owned the world's largest search engine we probably would have a better version of AMP right now that took more people's input into account.
As a user, I really like AMP. It converts terrible web experiences into non-terrible ones because it forcibly removes the rope for major websites to hang themselves with.
As a developer, most of my concerns with AMP are with it being very Google centric and controlled - and the addition of Cloudflare didn't really solve those for me. Seeing AMP move to a TSC however does, and I really hope that it helps AMP become a globally adopted standard instead of a "Google thing".
I hate AMP as a user. It breaks iOS Safari reader mode, and i always have to do extra work to get the actual link to the page. I'm also on LTE, so there's not really any noticeable speed difference on mobile. Initially there were also rendering bugs making 50% of amp clicks result in blank pages for me.
Exactly the same for me. It starts wir subtle things: Why do they have to override the system scroll speed? Then, as you point out, I’m a heavy user of safaris read mode which is essentially solving for the same problem as AMP. For me, the best thing about amp is the link leading to the non amp version
EDIT: I have to apologize for both of my points. The scrolling thing was fixed as somebody pointed out and the reading mode works just fine for most pages I just checked. Have tried to avoid AMP for a long time I guess...
I heavily use my browsers' reader modes as well but isn't the idea that if you load the regular page then use the reader mode you end up downloading more data than you would have if you just visited an AMP page? From a user's perspective (absent ideological concerns about the implications of AMP in its current implementation) the latter is preferable to me.
It's not delivery speed that I care about, it's "time to first paint". I want to read the damned news article, not wait for your crappy fonts to load and have to mute your autoplaying video nonsense.
I think the (much, much) bigger problem with AMP is that it restricts the future.
If you're only allowed a subset of HTML otherwise your site won't rank which is entirely dictated by how fast you can get back to Google serving more ads, bye-bye HTML, bye-bye innovation, bye-bye open web.
When all websites have to be AMP as you get heavily penalised for not being AMP, why would you keep up the HTML version of your site? The internet will be forced by Google onto a standard that heavily benefits google, and heavily penalises the things we should actually care about, which is an open web on our own servers, not controlled by centralized CDNs, and content makers.
What's worse, how long before google start including "other people searched for" in their top bar as soon as you scroll up a bit? And then how long before google start showing their adverts at the top of your web page?
The problem with AMP is... it forces JS just to push less data and focus on content while the solution would be... to simply use less junk on the website. IMHO this could be done with limiting what is allowed on the website.
Of your 5 bullet points, what's the difference between #2 and #5? You say people believing #2 are misinformed, but that #5 raises a true anticompetitive concern, but they're the same thing, no?
As for it being for the Google Search team to address, rather than the AMP team, I'd be inclined to disagree. AMP Cache is a part of the AMP spec., the Google Search team are just implementing it as described. What they're doing is just what the AMP Cache is designed to do, nothing more.
Also, while you describe #3 as nihilist,I fear it's the most true among the wider, non-HN implementers of AMP on sites.
The difference between "stealing traffic" and the "Google Search Mobile is a captive newsreader" is nuanced.
It's surprising and upsetting to people when they find out that in Google Search Mobile, their attempt to navigate to an AMP-lightning-marked search result doesn't result in a navigation to the target site, while an attempt to navigate to a non-AMP search result does go to the target site, as one would damn well expect. It's upsetting, because the designers of Google Search Mobile have gone through great lengths to hide the fact that the navigation didn't occur, and have adopted UI elements that intentionally try to mimic familiar navigation cues from browsers, rather than playing up the fact that they're viewing proxied content in a wrapping frame.
On the other hand, the 'stealing traffic' critique is memetic from a catchy title by a much-revised blog post, and seems to genuinely be upset that bytes that would ordinarily be transferred between the end user and the article's originating host stop short of of the distant origin [1], and get served from a Google-owned CDN instead. It's a technically unsound mishmash of complaints, most probably deriving from the aforementioned behavior of the Google Search Mobile page, but imbued with the subtext that Google is exploiting publishers by providing a CDN. That's absurd. Maybe Google's exploiting publishers with its captive newsreader, but not by providing a CDN.
Google is not 'providing' a CDN. Google is inserting a CDN between its search and my servers on its own initiative and without asking me how I felt about it.
> It's a technically unsound mishmash of complaints, most probably deriving from the aforementioned behavior of the Google Search Mobile page, but imbued with the subtext that Google is exploiting publishers by providing a CDN. That's absurd. Maybe Google's exploiting publishers with its captive newsreader, but not by providing a CDN.
Sorry if I'm missing some vital sentence in your analysis, but I can't see where you explain what exactly is absurd about it? How is Google's AMP cache not stealing traffic from the origin site? This is exactly what they're doing from a technical perspective: this seems to me to be an unambiguous fact.
> How is Google's AMP cache not stealing traffic from the origin site?
Traffic is a cost. Advertising impressions have value, and usually correlate to traffic, and analytics associated with the traffic has value, but AMP is designed to allow content owners to control and benefit from advertising, and recieve analytics, even though the content is served from a third-party cache (which Google isn't the only party operating.)
What is the operator of the original site losing aside from costs associated with serving traffic?
Stealing traffic also means stealing information about how many hits a page has if such is recorded via the webserver logs.
Honestly third party websites serving a proxy/cdn/transparent cache of a website is something that should require affirmative consent from either side of the party. Something Google is not getting, and as such stealing traffic is an acceptable critique.
It also reduces the security of the website by allowing users to get used to it being hosted from a google search page. SEO an imposter website that shows the same fake ui border and phish logins, the user wouldn't notice as it looks absolutely normal. (Something I might make a grey hat attempt at just because it's likely the only way to get google to stop doing it.)
The publisher of the AMP content can configure hooks into their analytics solution [1]. These events can fire during any AMP pageview. Given this, I'm not convinced they'll mourn the lack of httpd logs.
The typical practice for CDNs is that only the publisher consents; the CDN assumes responsibility for routing and serving the content (and has the private key for the origin's cert, to masquerade as them), and the requester doesn't get a choice. This isn't whataboutism, just an observation that CDNs are always the choice of the content originator, and never the content requester, who possesses few tools to convincingly tell the two apart.
I think the main point here from an analytics perspective is that, even if you don't choose to use Google Analytics or opt for any other service from Google, if you implement the (allegedly non-Google) AMP specification, Google gets to analyse your users while they browse your content, even after they've clicked away from the Google results page and are—for all intents and purposes—browsing a non-Google property. This is in contravention of both user and publisher expectations, and is non-optional for both parties.
You can definitely care about #5 without caring about #2:
Morphing my search results into a captive newsreader gives me a demonstrably terrible experience browsing to sites on my phone. The swipe-back gesture is broken, scrolling doesn't move the safari borders away like it's supposed to, there's a big AMP border I can't get rid of, swiping just moves between results instead of going back (or did they "fix" this?), the URL bar shows google.com instead of the site, making it harder to share, etc etc.
I don't care that they're "stealing traffic", I care that my mobile experience is demonstrably worsened.
That's true, but I was more addressing that #2 and #5 are two different outputs of the same technical mechanism—therefore saying that #2 is misinformed while #5 is valid is a contradiction.
> being more sympathetic to some of the critiques [...] efforts of the AMP team to address many of the complaints
> full of naïve bravado (e.g. "all we need is clean HTML")
These statements seem contradictory unless I am missing the "sympathetic" part wrt this critique and I am missing the "effort" part to address this complaint.
The suggestion that the advantages that AMP purports to bring can be better realized instead with just lean websites that aren't full of obtrusive Javascript and dynamic ads seems to entirely miss the fact that just-in-time ad auctions, made possible by scripting in the browser, are a critical revenue source for outfits that publish text and (and short video) content on the web at upfront cost. This makes for awful UX, but expecting publishers to forego most types of display ads is simplistic.
AMP raises the standards for ad networks and ad formats [1], and has hooks for analytics [2], giving publishers the features they -- well, at least, their marketing and engagement folks -- want, while insulating them from the most desperate attempts of adtech monetization that they'd otherwise feel the pressure to add. Therefore, AMP provides a story for business models [3] -- and fits into Google's vision where they provide solutions to derive revenue from content, either through ads, or through a user payment scheme [4].
That this can't be done server side speaks volumes about their real goals. From your first link:
> The AMP Project's goals are to do what's best for the user by helping to deliver fast web pages.
Clearly what they mean is best for revenue THEN users. This deception makes it clear they will not compromise on revenue (such as requiring server-side ads as img elements). Inability to compromise is quite the opposite of being sympathetic towards critiques and putting forth effort to address complaints.
Let's meet in the middle for the user's sake...have your ads, lose your client-side JS. But no, and then they wonder why it gets backlash.
You're absolutely right about this, and the casual dismissal from GP is the kind of attitude that landed us in the scenario that AMP claims (ostensibly) to fix.
It isn't misinformed to say that Google is effectively stealing traffic from publishers. Visitors literally do not visit your site when they land on AMP pages from Google Search. If the visitors copy the URL and paste it somewhere, it doesn't point to your site. An AMP CDN visit is not a website visit. There are extra elements added to those AMP CDN pages (back buttons, swipes) that are detrimental to the goals of publishers.
AMP is an attempt to hijack the entire WWW and appify it on Google's platform. The speed problem is not due to HTML -- it's due to bloated JavaScript. There doesn't need to be a new HTML-like standard. There are other ways to fix the problems with bloated JavaScript.
This isnt true. You're right in the sense that bits are not transferred from publisher's servers, but AMP page can report metrics as instrumented by the publisher, ads get attributed to the publisher and links back to the publisher. It is a cache, and behaves like a cache.
You're confusing this with an illegal upload of a video to a different site. The other site is 'stealing' the traffic, and the original creator is losing $$, ad impressions, attribution, exposure etc. None of that is happening with AMP Cache.
It definitely isn't a web site visit. It is not only a cache -- it has extra junk added to the page (back button, left/right swipes), and isn't even on the same domain. Copied links and referrers don't point back to your site/domain. Publishers do not have a choice.
I don’t know, I’ve been very critical of AMP both in terms of transparency [1] and conflicts of interest [2].
I still find the whole project dispiriting for several reasons:
1. Forking HTML: They’re now forming a defacto standards body on top of the W3C and WHATWG. (HTML is now forked 3 ways, for those keeping score.) We now are supposed to implement either (a) HTML + AMP, or (b) AMP alone (which is what the project has advocated for). Either way, that sucks as a developer and for the web. AMP team talks about AMP both being the future for everything always, and a mere stop gap that will enable better, native web tech. Which is it? It’s a mess.
2. Engineering-is-always-the-answer ideology: Ideologically, I dislike the “What the web needs is more corporate-driven engineering”. The whole reason the project exists is to fend off Facebook and native apps like Apple News. (It’d be better named FoF-HTML.) That’s the corporate side. And the way to do that was to massively overengineer solutions to problems that could have been addressed largely through SEO incentives (treat it as a spam problem) and left things like URLs (!) intact. Instead we’ll be left with years of AMP detritus that’s going to pollute the web for who knows how long. It’s all corporation-driven engineering and no spirit or science. No one is actually studying if these overengineered micro-solutions actually matter. All we need is more engineering!
3. Picking winners: Google used its own market dominance to bless AMP as the web framework of the future. It could have worked on common standards; it could have created other incentives, but it chose not too. Imagine if Microsoft actually succeeded in creating some kind of MS-HTML in the 90s or 00s. Thus there’s no market-driven competition for Google’s over-engineered solutions.
4. The cognitive dissonance inherent in the project: It’s an “open source” project that was born out of Google’s corporate interests. It has a public tech lead, but the actual Google exec above him responsible for the project doesn’t respond to anyone or answer anything. They cherry pick contributor stats to mislead the actual amount of Google-driven involvement. They desperately want it to be this thing of pure intentions for the benefit of the web and have us all singing kumbaya, but fundamentally it’s the product of a corporation acting in its short term competitive interests and using whatever engineering it has as its disposal to achieve those ends.
5. I still hate the UX. Reader mode support has improved but can be hit-or-miss, URLs are still broken and will be for years, and frankly I want to go to the actual web site and use Reader mode if necessary, rather than read the web through Google’s faux news reader. While developers have to maintain multiple versions of their code base (AMP & responsive HTML) things are going to break.
And all this for what? Slightly faster page loading and Google Web Reader experience, so Google can stick it to Facebook somehow? Is there any data on people using the web more instead of apps en masse now AMP is a thing? What %? And does that make forking the web worth it? I guess we’ll never know.
I think we can do better than AMP. How about having no Google affiliation and making it a strict subset of HTML+CSS? Those AMP tags make the likelihood of independent implementations much lower. Can we just remove client-side dynamism/interactivity from the picture at least at first or as an option? We can go a long way with pure, strict, reduced HTML+CSS (still includes HTML forms). I've been toying with this idea myself [0], but the key is strictness and complete no-runtime-needed backwards compat w/ current HTML+CSS. And for goodness sake, no proxies, pre-rendering, etc.
> Page load speeds are, frankly, none of Google's business
If I as a user care about page speed when choosing between search results (many do, every single amp-related thread has several, this one included), then Google cares and it is their business.
If the industry were capable of making fast web pages then they'd already be doing it. Claiming that "only using some features of system X" is equivalent to "use system Y which is defined as a subset of X" because a technical comparison claims that they're the same is completely missing the mark.
> It's a text book case of Embrace, Extend, Extinguish. All the Devs working on this project should be deeply ashamed of themselves.
I think that anyone who works at Google has an obligation to speak up. The company is on a path to destroy the open WWW. The primary reasons for pushing AMP are clearly not about fast web pages. Open governance isn't going to fix it.
The AMP project should be shut down replaced with an open discussion about how to make the Web less bloated using existing standards. Serving from CDNs in restricted formats should not be a requirement for publishing on the Web. The source of the problem is JavaScript, not HTML.
> Why is it needed at all? We have HTML, we have an agreed upon governance for it.
For my selfish reasons, so I can write a competing browser that only accepts that format. While I want the spec smaller and more strict for selfish reasons (ease of implementation), it has bonus value for performance use cases.
Also, there is value for devs to signify that they are attempting to conform to a certain specification (i.e. the purpose of a doctype). Sans validation the value is less, but still, having a simplified spec subset for web pages at least lets the community/ecosystem grow around it.
Google can care about page load speeds without needing AMP, I would hope that at some point they use their own tools (Their page load speed benchmarking tool) to inform their search rankings instead of invention solutions in search of a problem.
How about use the normal HTML+CSS spec that we already have and refrain from dumping 5 MB of JS and assets into every page?
If we go down the AMP road of a faster and more minimal web spec, I'd bet that we're going to spend the next 10 years gradually adding more capabilities/cruft into it until AMP 5.0 ends up just as bad as HTML/CSS except now we're have two diverged standards for making slow webpages.
Your solution to increasing page size is to hope that people just stop doing the thing that they were doing?
I don't particularly care if a new standard is defined or not, but at some point you have to shift incentives and Google has shown itself to be willing to throw its weight around.
IMO Google's previous moves to derank search results of pages with poor load times is a reasonable way to do it. Social sites could apply similar leverage, not promoting content as much if they know it loads slowly.
Beyond that, I wonder if in browser "This page is loading slowly" wall of shame messages could work, styled similarly to the "This page tried to open four popup windows" alerts.
Users don't have any visibility into page size or javascript load beyond how sluggish it feels, but both of these impact your user experience and battery life, so I'd love to see browsers do more to expose poorly performing sites. Browsers setting a benchmark for "This is unacceptably crappy" would let users know they should expect better.
The hard part of that would be differentiating sites that use tons of resources for bullshit reasons from sites that are actually doing something.
I use uMatrix, which makes JS opt-in rather than opt-out. It’s a hassle, but I get to choose to enable content I want while blocking trackers and bloat.
It’d be great if those portions just weren’t transferred to me.
I think what I'd like to have is a "Use significant resources" permission for sites. Off by default, and unless it's granted a webpage has a hard cap on how many CPU cycles it gets.
When a site is trying to go over its limit, you can either continue to browse it in slow mode, allow the permission prompt for better performance, or GTFO and find a less shitty website.
It's just assumed right now that webpages get to be as much of a resource drain as they'd like, and site owners are acting as they've been incentivized too. Fifteen ad networks and a Monero miner? Sounds great!
You can look at the list of AMP components we have right now[0], including some stuff from the social section:
- Facebook comments
- Vine
- Twitter
- #!?X Riddle.com
So what happens when Facebook changes how its comments works, or adds more Javascript or bloat to the component? What happens when Vine closes down?
Does anyone really think that an AMP committee is going to say, "No, your component isn't efficient enough Facebook, we won't update what code gets shipped"? We've traded a composable API for company-specific widgets. And once you decide to have company specific widgets, two things happen.
First, when the AMP standard really does become commonplace you get complaints that it's too difficult to get new components approved and updated, and that this is anti-competitive and unfair to smaller companies who are just trying to launch their own Vine replacement. Second, once you open up the process and make it easier to approve new components, people start shipping a bunch of awful code that breaks existing widgets and slows down pages because some CEO somewhere decides, "we can have an fancy widget on the Google? We need that by next week."
So then we'll try to come up with some kind of automated system to tell if components themselves are performant which will... sort of work. And the question we apparently won't ask at that point is, "why didn't we just start with the automated system for weeding out bad code and use that to rank websites, and skip the whole AMP thing?"
Seriously, AMP has only 15 social components right now, and 1 of them is already for a dead service that no longer exists and that will absolutely go completely offline at some point in the future. I'm sure this system is going to scale just great.
A strict subset of HTML+CSS doesn't give 100% of the benefits of AMP and apparently at Google the perfect is the enemy of the good so they're going all or nothing on performance. Standardization of AMP is underway in the form of Feature Policy, Web Packaging, iframe promotion, Performance Timeline, and Paint Timing but it's going to take years. https://amphtml.wordpress.com/2018/03/08/standardizing-lesso...
You can certainly try to invent your own standard, but you won't get the major news publishers to adopt it without incentives from a big company like Google, Facebook, or Apple. Who else controls that much traffic?
These publishers are going to feel the wrath of easy-to-use, widely distributed client-side page proxy/distillation apps if they're not careful with their anti-user stances.
This doesn't change the bad smell. AMP feels like it's being forced on us to appease Google so sites will appear in search rankings.
The kerfuffle over React's licensing was different. React was a tool the community loved that was hamstrung by a license and opaque ties to Facebook. React's licensing switch was a liberation, this feels like appeasement.
One possible upside, this should provide some long-term stability -- something Google is generally not good at.
AMP is a feature that users love. The difference between the two is that here there's a much higher ratio of developers, and most users don't realize when they are using AMP. If you gave them a comparison of a fast loading light page or not (just compare a site's page pre and post them deploying AMP capability), I'm confident this would be easily shown.
There are some problems with AMP, and there are some problems with how Google utilizes it, but it does help the problem of page bloat and slow loading pages.
> React's licensing switch was a liberation, this feels like appeasement.
A lot of the complaints are about Google's control over AMP, and how they might change it in the future in directions that are harmful for the minority. This does address that somewhat. I see them as very similar. Both are projects where a large company spurred release for their own reasons, but had to make it more open to appease the public and actually get more of the adoption they wanted.
People love fast websites, not AMP. For users, not much would have changed if the lightning icon on Google Search meant "This site loads really quickly" and AMP was a JS-framework made by Google as an example how to make fast sites, but basically all objections from the dev side would be invalidated.
AMP is not your website. It's a restricted shell of your website's content that is hosted on google.com. People aren't visiting your website when they visit those AMP pages.
I use Firefox on Android, which if I understand correctly isn't sent to the cache, but some sites still are AMP. + AMP links shared by others, on other sites/channels.
AMP requires me to manually edit URLs to remove AMP before sharing, several times per day, because some people have an aversion to MitM between their browser and publishers.
There is no "AMP itself" outside of Google. The AMP project consists of three parts[1]:
1. a specification for an HTML/CSS subset (almost) which is relatively easy for browsers to render efficiently.
2. an open source client-side JS library designed to automatically apply a number of performance optimizations to pages written against the specification above
3. a closed-source proprietary proxy server designed to further optimize content delivery for pages written with the above tooling.
The first two are pretty awesome; full stop. The third one is probably also pretty awesome from a technical perspective, but it's hard to say for sure since I can't spin up my own proxy server to find out.
AMP pages can be served without the proxy layer, but then they're not really AMP pages. They're just unusually svelte HTML pages with some slightly esotreric JS runtime extensions. In order for the end user to actually get most of the benefits of AMP the page needs to be filtered through a compatible proxy, and that means Google (or Cloudflare, who also host a proxy layer with Google's blessing).
I've got nothing against Google's proprietary tools. I've got a Gmail account, all my spreadsheets live in Google Docs, I still miss Reader. But let's call a spade a spade. AMP is fundamentally a proprietary Google offering with a handful of open source components. Nothing short of enabling third parties to host their own proxy servers will change that fundamental fact.
Most defences of AMP seem to focus on how all the Bad Stuff(tm) is a property of how Google does AMP (As if anyone else showing users AMP pages is relevant), and how its an open standard you can "fix the problems with" (You can't fix things in the way Google decides to show users things).
It really smells like an android-esque "fake open" move where any complaints about Google's control over the situation is deflected with arguments about how parts of it being open source (But not the parts that are giving Google said control)
That sounds like a you problem. Lots of sites use CDNs. Do you refuse to use any site that uses Cloudflare? Or is it just because AMP is easier to see that it bothers you?
> I absolutely hate being taken to an AMP page instead of a web page
Are you saying you hate to be taken to a page designed with AMP in mind (AMP compliant), or that you hate being taken to Google's cached version of AMP pages served through their CDN, which is not at the target site?
These are not the same things. AMP is a spec for how to design and implement your page. Google uses the specifics to cache the page and show it. People seem to think these are inextricably linked, but there are other CDNs, and this whole announcement is about giving AMP itself it's own governance.
Google AMP was never great as a standard. It's too fuzzy and random and nobody _really_ cares about it beyond the search ranking benefits.
I understand where they were coming from, but creating a reduced-interaction, faster-loading HTML subset would require way more spec work than they put in to be self-consistent and long-term maintainable.
This is the same sort of reason PNaCl didn't get traction. Both were great science projects, but neither was appropriate as a long-term standard. Hopefully we'll see the WebAssembly equivalent to AMP from the ashes of that project.
I will never, ever deploy AMP on my website or any website I have any control over. One poster in this thread made a dismissive statement about ideological criticism of AMP "(e.g. "Google is trying to destroy the open web")". Well, I am absolutely happy to stand by that criticism. AMP is diametrically opposed to the open web. The web is built upon three fundamental technologies, any of which—if replaced—constitute a platform OTHER than the open web: HTML/CSS, HTTP, and URI/DNS.
Google seems keen on breaking down that last bit as recent updates to Chrome demonstrate, and AMP is essentially a replacement for HTML. I don't see the open web being appreciated or respected by the Google of today, and I plan to do everything in my power to stand against this shocking land grab of influence over the web not seen since the bad old days of 90s era Microsoft.
You should also block Cloudflare's AMP bots [1] on the websites you control and flag AMP defending and promoting articles.
The sad part is it's all just the beginning. All those ad-billions will go into more land grab and control, rather than innovation and progress. And governments will be so happy about it, no need for censorship laws if you can just ask a megacorp to "moderate" content that reaches most of the population.
Angular allows you to create your own HTML elements that cannot be used without the Javascript accompanying the page.
That seems similar to AMP to me: AMP is a (very) opinionated framework that provides a set of HTML elements. It can run in any browser.[1] Like Angular, AMP is a Google project. Why does your criticism of AMP ("replacement of HTML" "shocking land grab of influence") not also apply to Angular?
Maybe your objection is more about the CDN or presentation in Google search? I'm genuinely confused by the strong reaction AMP seems to elicit.
> I don't see the open web being appreciated or respected by the Google of today
I'd generalise it more, "I don't expect the open web being appreciated or respected by any business." Business is to make money, preferably now, open or not is irrelevant.
Is this Google getting desparate they will soon be seen as the monolithic behemoth they are already?
AMP will definitely backfire in the hands of Google, but for an open standard the model itself shouldn't be tied to their incentives in such a drastic way.
I know people in the media and publishers who despise everything AMP and would do everything to get away from Google, but they can't due to heavy inertia of creating alternatives in such a tightly controlled market dominated by a single entity that is miles ahead when it comes to resources on all levels.
AMP is pursued by google to kick out competitive third parties from the mobile ecosystem, that's all. It's nothing to be proud of, and doesn't solve a problem except forcing selfish publishers to reconsider their patchwork of dozens third parties cluttering and burdening the user (nowadays consumer).
A true solution is already there - it is called HTML + CSS, and if Google was honest they would simply rank via speed, which they always did. There is simply no problem. The only problem is that Google can't control the types of third party scripts running on the fastest websites, that's why they created a selfish solution to that problem.
Only because something is structurally open source, doesn't make it good, and only because something is open source and structurally governed by multiple entities, doesn't make it a worthwhile endeavour.
This is all about the big players controlling the narrative. Twitter, Pinterest, Yahoo and eBay are not better than Google when it comes to letting them define how the web works.
Why not simply weight the search results and make an open grading project? Site loads slowly versus other sites that do similar things? Give it a C or a D instead of an A. Weight the results instead of just giving the top to amp pages. Easy.
For users with some objection to Google, it's not clear to me how they are supposed to change their personal AMP cache provider, like with a browser configuration setting or something. Is it Cloudflare's intention that other search engines like DDG use their AMP cache?
There's no such thing as a "personal AMP cache provider", as the AMP cache used is mostly tied to "where you came from". Google Search will always use Google's AMP cache, which is why the "you could always run your own AMP cache" concept is silly.
The goal of AMP is functionally to allow your search engine to preload the content from search results, at it's own origin. So any AMP-enabled search engine would need to run it's own AMP cache and serve the site out of their AMP cache. AMP doesn't realistically speed up web browsing in any other context (it adds plenty of it's own JavaScript).
Seems like they completely missed the point. They need to make search results not rely on the page using AMP but just being light and fast. If the page uses AMP to do that, great, if not, shouldn't matter.
When they're giving contributor statistics are they talking about commits? Looking at the commit log and contributors list on github, the vast majority of the code appears to be written by google. It looks like they're counting a user with a single commit equal alongside google developers who work on the code base every other day.
Will you be able to use AMP without ever touching Google servers/services? So it actually works like said subset of HTML to clean up the mess we're in. You have to force those things directly in the core, you can already make pages fast with current tech, that's probably why they also talk about ads in the spec. At least for non-SPAs (I wouldn't complain about another layer for SPAs that cleans up the rest of the web). You can't even open most of the official AMP project pages and docs with JS disabled, that's often a red flag.
I'm not really an expert on AMP, but would only support it if they actually made things better without pushing for their own services or pull things like AMP for Gmail, variations of EEE.
I don’t think this is going to affect my opinion of google one way or another, but coming so short on the heels of a bunch of controversy, I have to wonder at their motivations.
I am agast at the comment section here. The number of people seemingly purposly misunderstanding or misrepresenting a rather simple issue is disheartening. I know talk of shills is frowned upon here, but you can't really ignore it in threads like these. What is the HN approved way to call these, often high ranking, accounts out? I don't want to rock boats but this is absurd.
> "Please don't impute astroturfing or shillage. That degrades discussion and is usually mistaken. If you're worried about it, email us and we'll look at the data."
You can contact the mods via the Contact link in the footer.
Fair enough. But the nature of the beast makes a semi-well thought out promotion and/or suppression campaign rather hard to pin down in concrete terms. Perhaps just a loyal fanbase or independent employee or 2 is responsible, but I cant exactly sumbit a smoking gun now can I?
This whole policy seems rife for abuse. But I honestly don't know a better way, without introducing adjunt issues. My sincere apologies if I reduced the quality of discourse as implied in the guidelines.
The reason for AMP is surveillance capitalism. If you absolutely, positively believe you have to track your users, writing simple web pages is not an option.
Your choice is either the status quo (pull in lots of third-party cruft), or having a fast-loading page where Google runs the tracking and advertising infrastructure.
The docs explain that "AMP analytics is specifically designed to measure once and report to many". Google's not trying to drive out other players, they're making sure they run the table.
Edit: The whole point of AMP is so Google can gain more influence and lock out competitors in the search space. The original article said they have decided to "move AMP into open governance". It is therefore hilarious (and substantive) to say they should "move it into the trash".
Note: you guys should really get admin badges for actual HN admins. I thought this was some rando pedantically quoting the rules (and/or an actual Google shill) in response to what would be a straightforward typical comment on any other tech news platform. That said this has seriously shaken my confidence in the quality of discourse on HN and ruined my day. I miss slashdot.
(I had a nice long thought-out response for you until a windows update popup appeared mid-sentence, and I accidentally triggered it. Maybe I'll write it all out again later, maybe not. What I write now is a much condensed version)
> you guys should really get admin badges for actual HN admins.
That might be a good idea
> straightforward typical comment on any other tech news platform
I visit HN explicitly because it's not a typical tech news platform and isn't full of those typical comments.
> It is therefore hilarious (and substantive)
hilarious != substantive
It was a shallow dismissal, however you slice it. Such comments are not welcome on HN. Please don't post them.
> What's so hypocritical about you guys is you upvoted it until dang commented.
Upvotes are not king here. Just because people upvoted it does not mean it was a good comment.
> That said this has seriously shaken my confidence in the quality of discourse on HN and ruined my day.
I am confused that how your comment fared in upvotes somehow has something to do with the quality of discourse on HN. There was no discourse. The fact that you got upvotes but no responses means that despite the fact people engaged with your comment, they didn't discuss anything. There was no discourse. (until my own attempt at a meta-response)
And yes, believe it or not, all that is still shorter than what I originally wrote.
> I am confused that how your comment fared in upvotes somehow has something to do with the quality of discourse on HN. There was no discourse. The fact that you got upvotes but no responses means that despite the fact people engaged with your comment, they didn't discuss anything. There was no discourse. (until my own attempt at a meta-response)
Nothing to do with the upvotes, but you feeling the need to chime in and police.
> but you feeling the need to chime in and police.
I hadn't responded prior to writing that, I'm a different person to the one who mentioned the HN guidelines, so I'm confused who exactly you are referring to as "you". Would you mind clarifying?
I've written about AMP on here a lot [1], and frequently include this disclaimer. My views on it have evolved as time went on, being more sympathetic to some of the critiques, but also to the efforts of the AMP team to address many of the complaints.
While a number of technical critiques to AMP remain, increasingly, the criticism is:
- ideological (e.g. "Google is trying to destroy the open web"),
- misinformed (e.g. "Google is stealing traffic from publishers"),
- nihilist (e.g. "everyone who uses AMP only does so because you need it to rank high in search"),
- full of naïve bravado (e.g. "all we need is clean HTML"),
- or related to the fact that Google's mobile search page has stealth-morphed into a captive newsreader that surfaces AMP-ified articles with Javascript without ever leaving the page.
Out of these, the lattermost is the only one that raises a true anticompetitive concern, which Google seems keen on ignoring. However, I'd say that's for the Google Search team, rather than the AMP team, to address.
[1] https://hn.algolia.com/?query=niftich%20%22AMP%22&sort=byDat...