I think it's reprehensible for google to push this so relentlessly and beyond simply stealing links it makes google into the "internet."
This (AMP) could easily be a standard, in fact it's mostly just common sense (good lightweight HTML/CSS/JS). Instead of Google forcing its way on users and creators it could just lower the page rank of the offenders.
One other thing about AMP that pisses me off as a user and an engineer is it's one more place to maintain meaning one more shitty neglected experience. As a user I hate it when AMP pages are broken and I somehow can't get to the non-AMP version. I don't blame the developers because we have enough on our plate. My anger is solely directed to google for making the damn mess in the first place.
“We started experimenting with AMP in our Bing App last May and have noticed that AMP pages load, on average, approximately 80% faster than non-AMP pages” says Marcelo De Barros, Group Engineering Manager in charge of the AMP integration at Bing.
People talk a lot of trash about AMP, but until there's another solution that allows me to go to a news website and actually read it, I'm an AMP supporter.
There's similar blogs for every small community, run by people who care about that community. Usually unfunded, and only covering stories of interest to that community.
Shills and Kool-aid-drinking zealots mostly - they are the ones usually motivated enough to do 'journalism' for free. Don't expect any professionalism, depth or any form of investigative journalismbeyond tweet-storms.
We outsourced our opinions and fact-finding to journalists for a few hundred years. Now that time has past. Journalists themselves have destroyed their own industry by producing a poor quality product. Maybe in future journalists will re-invent themselves as purveyors of pure factual reporting, and those that care about that kind of thing will pay for it. But it is a niche market. Democracy, decency, enlightenment and society will suffer of course. But those things were never guaranteed with any kind of real safeguards.
If you think this was ever the case, rose colored glasses are in effect.
Unless you’re doing tree shaking, which AMP can’t do duplicate, compression has rendered “minification” useless long time ago anyway.
But still you are loading ton of unnecessary content. Ad blocking on iOS still sucks (no custom filters).
If anything I prefer this way of working - Apple alone are responsible for maintaining a high performance adblocker in Safari, the wider app ecosystem just provides the block lists, rather than rely on app developers to write performant browser plugins.
I'm not aware of anything AMP does differently than non-AMP with regard to tracking, except that it's declared in a way that allows it to be cached+preloaded without falsely triggering analytics.
1. Search for some BBC news on google.com, click on an AMP link and load a BBC page
2. Notice that you're still on google.com and not on bbc.com
That said, I use StartPage, who have a contract I believe with Google. It's Google's search results, minus the tracking. It's as much as I am willing to compromise on something as fundamental as search.
At least it's honest about not having results whereas Google presents 5 billion, all of which are missing one of the three keywords (which it notes in a small, light grey text, which you only notice after the first three results were completely unrelated and you were wondering what went wrong).
For example, "new double c++" is the query I did most recently and in the top 3 there are 2 results that answer my question.
Making something up at random like "torrent clients" gives me as top hit the Wikipedia article "comparison of bittorrent clients", which is better than expected.
I can't seem to think of a vague query right now. "audio books" gives me sites with audio books; "psychology books" gives me articles of 'the best 50 psychology books' and such; and looking in my query history, "draw unicode" seems vague but the top hit (shapecatcher.com) is the one I was looking for.
Something localized then: "drankwinkel echt" (where Echt is a place and drankwinkel a liquor store) indeed gives terrible results. The store name, surprisingly, works though: "gal & gal echt" gives similar results to google.nl.
Yes, that's really bad; it's what killed Altavista and could really be Google's undoing.
Still, Google is miles ahead of the competition.
Small experiment: searching for "movie old man balloons" on Google and Bing.
On Bing there is a first line of 4 videos, none of them related to the movie "Up" in any way. The second link is to Up on Imdb (good). The 3rd link is to a crazy religious fanatic site page titled "Disney PIXAR's, 'Up' - The Sugarcoating of Pedophilia!" (WTF??!? - but at least related to the movie). The 4th link is again to a youtube video with no connection to the movie.
On Google, the first 8 links are to the movie. There is a line of images, all from the movie / movie poster. There's a list of 4 questions "People also ask" that shows questions about the movie ("How many balloons would it take to lift a house?"). To be fair, the crazy Baptist site does show up on Google too (God has good SEO!), but way down below the fold.
Anyway, my point is, when answering the question, Google is certain you're looking for information about Up, and tries to give it to you.
Bing seems to have doubts and tries to guess if maybe you're looking for a funny video of a man in the subway wearing a balloon hat (??!? it's not a "movie"!!) or the hit song "99 Luftballons" from 1983 (not a "movie" either!)
Bing tries hard, but is obviously more than a little clueless.
Your experiment's results are not repeatable. When I do that here:
* Bing gives me 8 pages about Up (including that spoof site), one about Danny Deckchair, and a page about a magician who re-creates old movies with balloons.
* Google gives me 13 pages about Up (also including that spoof site), a book of best movie scenes on its page for The Third Man, and an article from The Rotarian from 1948.
Of course, some knowledge of how these things work teaches that this is a terrible methodology, given that it does not account for the fact that both Bing and Google tailor their search results to the searcher. One should at the very minimum log out of one's Google and Bing accounts, which you made no mention of doing.
FYI, Landover Baptist Church (which that article is from) is a very old, very well known spoof site.
A perfect search engine would not return this on the first page of results about the movie, because it's not about the movie.
That's a spot-on description of Altavista :)
Other search engines feel like a noob salesperson who needs to be told 5 times in 5 different ways what you need -- and it's really simple stuff too.
I like experienced salespeople.
I got relevant results in my first day there. I didn't notice a drop in result quality.
Google is just that good even if I hate to admit it.
It seems to expect more precise queries, while Google is geared toward "close enough" searches. I've found that DDG is often preferable when I have an exact phrase in mind. Google is sometimes too helpful, correcting errors that are not actually errors and failing to take some queries literally enough.
The main issues I have with DDG are that it doesn't seem to prioritize recent results (which can be good, but usually isn't) and it fails at local results, which is basically by design.
While I am still personally a huge fan of Google's work in this are and many others, sometimes I long for the days of straight boolean search queries in search engines. I could often find exactly what I'm looking for, and get the same result each time.
Are there any other major or effective engines that allow for boolean queries beyond AND/OR?
nowadays Yandex uses its own index even for “foreign” (non-Russian) sites.
Also, if it is using Bing on inside, I'm not then sure why the results are still different than that(even at the places where there's no scope for personalization). For example type this line exactly in both bing and ddg:
difference between std list and std set
The first result DDG shows is of a difference between set and a vector - not only that, it also highlights that result in a Google Card inspired fashion (which is worse because Google does that only when they have a certain amount of confidence in the answer), while the first result Bing shows is an actual difference between list and a set. So either Bing is cheating DDG, or DDG is doing something stupid on top of its results. (Also, if you cover the above string in quotes, Bing still shows 'some' search results, while DDG doesn't).
May be after using the '!' ninja techniques it'll be same as Google, but then I have also come to love the fact that I can type in 'my next flight' or 'Show me emails from ....' or 'remind me to ... ' and other personalized things on Google so may be my priorities are different here.
PS: DDG redirected image searches to bing, but not generic searches. Which honestly seems reasonable as doing image search well is incredibly hard, with minimal payoffs.
It sounds like Bing is personalizing your results either by location or by adtech tracking, which is kinda antithetical to the point of DDG.
My contract with a search engine is that they should provide links to other sites in a relatively painless way. In exchange for this the search engine can track me while I am on the site.
AMP breaks this relationship by refusing to let me leave the site and extends tracking to other sites. The speed difference is negligible to me and not worth this violation of privacy.
Just like AMP are fundamentally websites built on a bunch of guidelines with performance and accessibility prioritized which, once you sprinkle them with enough metadata, get treated specialty by third party like google.
Yeah, I don't think I misunderstood. AMP's guidelines are just more strict before the 3rd parties start treating you specially. And in both cases, the original website/app is just fine, until it starts getting treated specially.
Update what? What do you mean by "app store"?
I could make the same argument that Apple cripples iOS Safari's implementations of emerging standards that aim to bring the web experience closer to a "native feel" to keep its app store revenue churning:
...but really it's a lot more likely that getting _all_ things right on _all_ platforms is the really, really hard thing about the web, for browser vendors and web developers alike.
Never attribute to malice that which can be adequately explained by incompetence (or in this case, sheer overwhelming difficulty).
sheer overwhelming difficulty + no incentive = no action
Apple's response was (surprisingly) to make the default scrolling like the overflow scrolling. So, with the next Safari release all pages will scroll like AMP pages. Hope Gruber is happy then :)
Please, please fix this. It's impossible to support something that's foisted on us and breaks basic web functionality. If I were cynical, I'd say bugs like this are designed to degrade the web experience on iOS. There's a lot of bad web programming out there, but very few sites manage to break search.
Edit: some detail. Safari sometimes doesn't scroll find results into view when they are in overflowed space. This issue actually affects a large percentage of web pages. Fixing it was very easy, was just an oversight in WebKit.
Having all scrolling be consistent feels good once you get used to it.
That doesn't necessarily mean it was a good idea for Google's hosted AMP pages to use overflow scroll all along. The inconsistency definitely did feel weird. And the way they do scrolling prevents Safari from auto-hiding its top and bottom bars. I believe all the desired scroll effects could have been achieved without the use of overflow scroll.
Edited to add: the AMP scrolling model also breaks tapping the top of the screen to scroll to top, and this won't be fixed by scroll rate changes.
It never occurred to me that Safari page is what the outlier, I just assumed that Safari pages matched the rest of the system and iframes for the thing that we're off.
Maybe this won't be as hard to get used to as I feared.
Oh well, maybe I'll get used to the inertia scrolling. I'll give it a shot when they make the system-wide change.
For now though, the different scrolling experience on AMP (and some other pages) is jarring to the point that I don't even bother and I just bounce.
Honestly this whole thing (AMP and your comment) come off arrogant as hell to me.
I like the current iOS behavior because it's what I'm used to. I don't find the slower scrolling speed to be an issue at all. But if everything really is going to change then I will probably annoyed me for a while but I'll get used to it.
I'm not complaining that the scrolling behavior on AMP is too fast specifically (although that's how it feels to me), I'm complaining that it's DIFFERENT from everything else. All my muscle memory of how to scroll things is broken on AMP pages and only AMP pages. (I don't care if it's how iframes work, you deployed it anyway)
Once it feels like the rest of the system then it's not really much of an issue anymore. I'll get over my personal preference.
But the snark was totally unnecessary.
They could've just as easily pushed you to a new page which contain the AMP content and wasn't an iframe, thus leaving all the standard feel and gestures working. Instead they choose to go along with what they were doing on android even though it was severely sub optimal on iOS.
I think choosing to do that WAS arrogant.
They made Google significantly harder to use as an iOS user because they didn't care and gave us no option to try and fix it.
I think the "correct" response in a case like this, where the platform owner has a bug and has committed to a fix in the pipeline for delivery, is highly dependent on the problem. Even then, it's possible to make the wrong choice given the information available at the time.
I prefer not to call the actions of a company and a group of people arrogant without more info than present, even if one of those people expressed a less than sympathetic opinion of the problem. I extend the same courtesy to Apple often enough, it would be hypocritical of me not to.
The big problem with that that only exists on iOS is that the 'weight' of the content is much much less than normal web pages. All your muscle memory of how far and how fast to move your finger to get the page to scroll a certain amount is wrong. Instead the page scrolls MUCH faster and further. This would be bad enough except you're still technically on the Google page and as soon as you go back or close the AMP result the scroll speed is what you're used to.
The end result is it's incredibly frustrating and feels "broken".
I understand that Google's preferred solution caused a behavior that is severely sub optimal because of the way Safari currently works. My problem is I think they handled this extremely poorly and forced all iOS users to deal with it for what, over a year?
I'm glad apples fixing it but I don't like the way Google handled it... effectively saying to iOS users "too bad" since they didn't do anything to mitigate it while waiting for Apple's fixed to come through the pipeline.
The majority of end users don't know anything about divs and iframes and don't care whose bug it is. So the question remains-- since they clearly know that this bug exists, why would they ship like this?
Every time I land on an AMP page on my iPhone, the scroll gets out of control and all of a sudden I've unintentionally followed a link to some video that starts playing with sound. It's ridiculously annoying.
A hypocrite (Gruber, as evidenced in another thread) calls the AMP team hacks who do terrible work. Turns out their "terrible work" is actually Apple's bug and the AMP team points this out both to Apple and to Gruber. In your eyes, this makes it all their fault.
When called out on it, you double down by saying that the team is still to blame because they chose not to work around Apple's bug. You basically want Google to be part of Apple's captive audience.
No, seriously, take a step back and consider that this is what you're saying.
I must have missed this. When did Gruber call the AMP team hacks?
> Turns out their "terrible work" is actually Apple's bug and the AMP team points this out both to Apple and to Gruber.
This is flat out disingenuous, unless you're talking about something other than the originally submitted DF article. There were multiple examples of why Gruber thinks AMP sucks. Are you claiming that all of them are "Apple's bug"?
The link of this thread was originally .
Although he didn't use the word 'hack' himself, Gruber said:
"Google has no respect for the platform. If I had my way, Mobile Safari would refuse to render AMP pages. It’s a deliberate effort by Google to break the open web."
So he sees them as intentionally sabotaging things.
- find in page: yup, Webkit bug (Google/Chrome uses Blink).
- scrolling behaviour: yup, Safari bug.
Anything else that I missed?
I.e., "not design decision".
>a state of affairs or an event that seems deliberately contrary to what one expects and is often amusing as a result.
As I said another comments though Safari was doing exactly what it was designed to do (for whatever reason they designed it that way). I don't think this is a bug on Apple's part. It makes sense to harmonize the scrolling behavior, but I don't believe it was unintentional.
Now I understand what someone was talking about when they said this might be ironic. I wasn't even sure what they were referring to. I can't place my finger on why this doesn't seem like irony to me. Maybe it's just not odd enough.
Apple seems to disagree with you, though. I would trust Apple to know better what Safari was designed to do.
It almost feels like you're looking for reasons to be upset and finger-point. I hope that's not the case.
I'm not sure it was a bug, it sounds like it was a design decision. Maybe not in GOOD one, but I doubt it was a true bug.
Apple's response indicates it was a bug, and nowhere has Apple said "this is a design decision we are now changing".
That they chose to ship that way instead of using an alternate implementation that didn't run into the problem ( or was less frustrating or provided an opt out ) was THEIR decision. They're not 100% blameless in this.
Except that thing was a bug in Safari. They used perfectly valid plain HTML without any hacks or JS.
They left it severely sub optimal and decided that was good enough… making google significantly more annoying to use on iOS than what it was before.
That was the choice they made and stuck too. No options to turn it off, no options to do it a different way; you just get stuck with it.
So my top-of-the-head guess of something that might avoid it based on what I thought the problem was from other HN discussions wasn't right. What a sin.
That doesn't invalidate my experience or frustration as an end user.
So you're blaming Google for not writing around an edge case bug that exists only on one platform?
My second comment was because I thought the original behavior of implementing AMP the way it was and forcing it on users was arrogant and has seriously annoyed the hell out of me since it originally started appearing on iOS. I've literally considered switching search engines to get away from it because it makes using Google that much harder.
Yeah, I called it terrible to their face. Because it frustrates the hell out of me. I've tried finding ways to contact google, I've tweeted at them, I've posted in previous discussions. At no point did anyone ever seem to wake knowledge the problem other than seeing people (who I assume we're not googlers) basically say it's not their fault because that's the way Apple implemented iframes.
Combined that arrogance with what I see as rudeness... and yeah. I said terrible twice. I'm frustrated as hell at this and don't like that the solution will be "it's going to stay there but Apple is going to make it a little bit better for you".
When the scrolling gets fixed? I'm still gonna be annoyed as hell at AMP pages. They break the experience, but now just a little less. Hurray.
I know, those are native platform affordances that the web doesn't need to care directly because iOS is not an open standard. But neither is AMP.
Changing the submission URL is unfortunate, because a lot of the discussion in this thread prior to 2017-05-21T00:52Z pertains as much to Gruber's material as the Register article. Now a lot of this discussion, as you seem to have noticed, appears out of context.
However, having Google load this structured content and host it on its own platform is a terrible idea. Content should remain on the publisher's site. Putting too much content in one place is dangerous for competition.
* In practice there are implementation problems too, e.g. those mentioned in the linked article.
Does that happen? If not, it's somewhat telling.
It is the implementation they chose, and it does have speed benefits. But, an edge cache that allows the end user more control, their own domain, an no hijacking header is possible, and would provide a notable speed benefit. If there were a choice between the two, publishers would likely pick the latter.
So the browser would still be downloading the exact same HTML document (straight from the publisher's server, how you want it) - just then ignoring all the clutter. Compare to AMP, which AFAICT necessitates serving a whole separate version of the page with only the blessed markup... it reminds me of the bad old days, having a separate mobile site instead of a single responsive design for all devices. All seems rather antithetical to that grand ideal of separating structure and presentation.
HTML6 document is a restricted subset, similar to what you suggest. I would still allow complete design flexibility, and I might even allow a subset of JS, but only for presentation purposes. Definitely not turing complete, and no ajax etc.. Probably I wouldn't allow cross-origin resources with credentials. So you could include an image or stylesheet, but the browser would not send along cookies. What I'm aiming for is a replacement for PDF, something you could read on an ebook, etc.. Just a plain document.
On the other hand, I'd have HTML6 app to be able to use the complete web platform.
1. There's the HTML/CSS/JS library/subset that's a good framework for building pages that load quickly
2. There's the 'CDN' that integrates with Google Search to preload and 'iFrame' the site in. Google 'has' to host/'iFrame' the content in their own google.com/amp pages because that's the only way to preload a page to make it display instantly.
We already had this two decades ago: WAP, its contemporaries (i-mode), and its immediate successors (XHTML Mobile Profile).
Google isn't the only party running an AMP cache.
> Content should remain on the publisher's site.
It does. Its also cached by aggregators, and AMP is designed to take advantage of being accessed from a shared cache.
They can offer to do a CDN like CloudFlare, but make it optional.
I want to ensure that not a single bit of my data ever runs through Google's infrastructure, while still getting all the same benefits as if it did.
If Google treats sites different just for using an AMP Cache, then I'll have to send another complaint to the EU Antitrust committee.
My pages actually increased their loadtime tenfold when I tried them with AMP — they're tested on a HUAWEI IDEOS X3 on 64kbps GPRS. AMP increases load time to over a minute. (On a modern phone, with a modern connection, my pages are obviously also faster — I'm also testing with a Nexus 5X on 100Mbps 4G)
I can't just massively increase load time for pages just for a better ranking in search results, this shouldn't even be a choice.
If it was microsoft they already would have shut this down because of the backlash. Google does it and people are fine with it.
Google is using any means possible to keep the web (html, js, css) relevant in the age of native apps (that includes Facebook app running on Android). If the web stays relevant, the same goes for Google search.
You can see a preview for what that means by checking out Wikipedia's traffic decline over the last 3 years or so.
Considering we're on the precipice of a global authoritarian-populist cycle, there are non-market consequences to such concentration, too.
WE are on the mercy of few SV companies and whatever they decide or push is our fate.
Only in this weird world of third-party-served-js-ads.
In an ideal world, I wouldn't care about where my content is served from. I just care 1) that many people see it, and if it is commercial 2) that I get money for it. I could just add some ads as inline to my article, served in the same way as my article's illustrations are. Not sure google allows that, though. Wouldn't surprize me if not.
In theory, it's a win-win-win situation. Publisher gets free hosting (with analytics and ad money still coming to them obviously), users get a faster experience and Google is happier if the users browser more content.
In reality, AMP is obviously not perfect but they have been addressing common issues and improving. I may not be fully sold on it yet, but I don't understand the massive blind hatred.
Saying "people can just optimize their website" doesn't mean shit. They've had years and no one has been. Sites have been getting slower every year despite browsers getting faster. No one gave a single shit until AMP came around...
With real web pages, the native sharing UI just works as it does everywhere else.
With AMP, you have to know to tap a different unfamiliar icon and then know that the unstyled URL displayed is actually a link you can interact with. That means that sharing goes from one tap to 2-3 and that's after people learn that Google gives substandard results doing what they're familiar with and so you need to remember to do something else only for pages which you found on Google.
An AMP page served without cache has to be treated the same, or this becomed exactly the freedom issue that this entire discussion is about.
My pages are actually optimized a lot, and they actually get about 10x slower with AMP than without.
I don't want to have to choose between fast loading and good SEO, I want both. And Google only offering good SEO to those who let Google track all user interactions with their page is also not ideal (I specifically do not use any ads, analytics, or tracking, not even storing IPs in the server logs).
If your server supports HTTP/2 and has a connection with a good bandwith then static resources can be loaded really fast without any CDN because all the resources can be loaded in parallel without waiting in a queue.
The real motivation for publishers to implement AMP is that they hope to get better position in search results.
But instead of simply pushing that aspect harder, they're actively promoting their own tech.
Edit: Disagree? What part isn't true?
An edge cache of an optimized page is plenty fast without preload. Images, in fact, can be preloaded cross domain if that is really needed.
You know it's a mess when the New York Times has to inject a "sorry this video doesn't work on AMP pages, visit our site" message on stories.
Publishers are free to implement their own cache and host their own content. AMP is open source and they can modify it however they like.
"…but there’s a big catch: if readers decide to share a link to an AMP page they’ve clicked on through a Google search, the link points to Google.com (for example, google.com/amp/yoursite.com/yourpage/amp), not to your site. A Google spokesperson confirms that there isn’t a way to both have your AMP-optimized appear in Google’s prioritized search listings without having that content hosted on Google’s AMP Cache servers."
1. You can (and must) host AMP content on servers of your own choosing.
2. Google's crawlers ingest your AMP content, validate it, and re-host it in Google's AMP Cache. Bing and other folks run similar crawlers and caches.
3. Google search results will only link to AMP content on Google's own cache.
So yes, you can host your content on your own servers. And you can give people direct URLs to that content. But Google users will only ever see links to the copy of your content that Google hosts; your servers never see that traffic.
There is no way to opt-out and still be considered a valid AMP page.
Disclaimer: I work for Google and have some involvement with AMP.
The worse case I've seen is a site in which every page crashed Mobile Safari without fail regardless of which version you ask for. It was eventually fixed but I never figured out why. If the sites are just running some script without checking then the admins have failed their line of duty.
I'm just going to file another complaint to the EU Antitrust committee otherwise, as this is a simple and clear violation. (Although I doubt my own complaint would be very relevant — all large publishers already have filed such complaints, and Google will be fined for it).
I have the choice between a massively worse user experience, or worse search ranking. And that's a choice that's just not acceptable to me.
* Build fast webpages.
The linked article says: "Yes, AMP pages load fast, but you don’t need AMP for fast-loading web pages." Well yes, but people don't build fast webpages without AMP. They could've done all the time, yet webpages got more sluggish over the years.
For example, searching for "Python" returns five pages of results where only two aren't about the programming language. But at the top of the page, bested only by python.org itself, is a huge carousel of 11 AMP stories about snakes in the everglades. These stories also appear in the normal search results, but not until the bottom of page 7.
So somehow the #68 result, "Python hunters eliminate more than 100 snakes from Everglades," got boosted to #2, because rankings #2 through #13 (if you count the AMP carousel) are not available to merely fast and relevant content.
This being the case, I think even if building fast webpages may not allow one to circumvent AMP in the instant, it is still a strong way of removing much of the grounds for its existence.
But Josh descends to hyperbole. I've been both critical and supportive of AMP on here , but it's important to not lose sight of the big picture. AMP isn't an effort by Google to kill the open web; it's a technology whose existence was forced by Facebook Instant Articles' meteoric rise, a competitor from a company that doesn't even operate on the level of the open web, but runs a family of products where the data flow is one-way: inbound.
Instant Articles made publishing harder on the web, giving preferential treatment to articles posted within Facebook's walled garden (cf. AMP giving preferential treatment to content that adheres to the AMP spec, the same way they give preferential treatment to content served with TLS). With Instant Articles fizzling a bit , AMP's importance as a strategic play is lessened, and we can enjoy its benefits without feeling like we're pawns in a game between two massive content aggregation portals.
Besides, Apple News is the same idea as AMP; I'd be curious how Josh feels about that.
Clicking on one of these AMP results in Google Search will lead to a Google-hosted page with the base URL of "google.com/amp/", which loads an iframe (or equivalent) of the AMP article content. This whole thing takes up the entire viewport, save for a small grey horizontal bar up top, which collapses (hides) with JS if you scroll down far enough, but is otherwise pinned to the top, staying adjacent to the browser chrome.
In short, Google Search on Mobile serves AMP results out of Google's own AMP Cache in a not-completely-obvious in-place wrapping viewer that tracks your visits, but it's now possible to get original URL . Meanwhile, Cloudflare, currently the only other operator of an AMP cache, offers auto-AMP links  for customer domains, and offers an SDK to customize the wrapper-viewer  that will surround the articles surfaced for that domain.
Apple News is a client application that combines a feed-reader with articles delivered from Apple News' servers; these latter types of articles are always hosted by Apple , and in the beginning the only way to publish to it was to use Apple's APIs to post to Apple News directly . Now there's integrations that will consume content out of your CMS and post it to Apple News on your behalf, which makes it easier to use, but doesn't change the fact that the the content is published into Apple's ecosystem.
AMP is just an alternate HTML framework that prevents certain things, that's all. Not sure why everyone is so eager to opt-in to a less flexible system instead of fixing their existing web presence. All it does is increase the amount of time and resources needed to now maintain effectively 2 different versions of the same site while also losing control over rendering, URL location and privacy.
Also the main reason for slow sites is all the ads - ads which are are usually served by DoubleClick, the biggest ad server on the planet and owned by Google.
To 99% of the businesses I worked with, software development is a singular expense. It's treated like buying a tractor for the farm. Hell, even farming equipment is more generously funded by the buyers for possible future expenses (compared to most software development) -- maintenance, repairs, parts that periodically need replacement, fuel.
For one reason or another, most businesses treat software development like buying a socket wrench from the local store and never even thinking of spending another penny on the developed product in the future. They expect it to run perfectly forever.
It's a sad state of affairs.
Still, maybe it's time the web development in general gets its crap together indeed. One can dream, right?
The other criticisms about how it performs on iOS seem truly secondary, they could easily fix them but we're still left with the far bigger issue.
Additionally, criticisms about iOS having a closed ecosystem seem irrelevant to this. An App Store is one thing, but starting down the path of effectively adding "high speed lanes" to the supposedly free web is scary.
AMP is a terrible idea for a lot of reasons, any one of which would in a sane market make it an instant non-starter. But the state of online publishing demonstrates that it is anything but a sane market; it's a market trapped in a death spiral, and in that situation any idea that seems to offer a way out is going to get some traction. So it is with AMP.
The only way to make AMP (or something like it) irrelevant would be for the publishers to get their houses in order on their own, without the need for external pressure. But their leadership doesn't have the kind of farsightedness such a move would require, and that leaves room for someone like Google to come in and do their jobs for them.
And in the long term, it's high time somebody built a less creepy, better functioning search engine.
I personally don't really recommend StartPage because you can't get away from Google's opinionated ranking on a site that provides Google results.
But in short, use other search engines and they'll get better. Stop giving Google your search behavior, it's what they use to keep themselves on top.
BTW, Cloudflare has an AMP cache as well....
DDG uses multiple sources, including Bing and Yandex. They also have their own efforts like their knowledge graph-type data features, which are open source and can be contributed to.
It's just as good. As others have noted, Google's search is only good when you're signed in. Because they use all that data to personalize the results.
Also, Firefox reader view fixes many websites which otherwise render empty with JS disabled for reasons I didn't bother investigating.
I can just get to the page, read it, and then leave. There's no futzing around with:
* long scrolling down "the fold" filled with clickbait in-site links or other unrelated nonsense
* interstitial and overlay ads
* crappy non-mobile interfaces
* "Shared" buttons stickied to the bottom or top of the viewframe
There's still ads around the page (in-content ads between paragraphs and "you may like" or "recommended" ads at the bottom of the page) and navigational elements to browse outside of the AMP page. It's the mobile content consumption experience as it should be.