Google AMP Cache, AMP Lite, and the Need for Speed
developers.googleblog.com
developers.googleblog.com
Beyond the distasteful navigation hijacking, and often broken or buggy page loading... I think Google throwing its weight around to force publishers to use it is an abusive use of power. I also think it's an unnecessary standard since it's nothing more than simple well wittten HTML and CSS.
Yes, we should make less shitty (meaning bloated) web pages that are rendered server side especially for mobile clients-- but that doesn't mean that if we don't we should be second class citizens.
More and more Googles search results are being materially affected by this choice. That is to say, AMP pages with no or little significance to my query are pushed to the top; while, relevant ones are not to be found. I find this primarily true with historical content or localized content where the host/author/org doesn't spend time updating things that aren't broken. Further, the companies prone to adopting AMP are doing as many things as they can simply to generate more traffic (i.e. click bait). So it's a race to the top for advertisers/media companies and a race to the bottom for quality results.
I will resume using google IFF they allow me to permanently opt out of AMP otherwise I will begin the slow arduous migration off all Google services.
Google trying to be the source of content instead of the guide to content will be its downfall from the top. I'm not saying they'll go out of business just that they'll someday be made less relevant from it.
What choice do you have? Reject traffic from Google? Every time I have been to an AMP-enabled page it's been an awful experience and unwanted. But you don't "search" for something you "Google" it.
Publishers typically aren't where people go to buy things. In fact, I imagine Google views them as part of COGS in a sense since they are what create display inventory.
So if Google has the leverage to reduce the cost and increase user satisfaction while simultaneously exerting more control on the display ecosystem, it seems like a smart business move to do so.
AMP links are given priority in search.
They are a bad reminder of the early days of the mobile internet when lots of websites would automatically redirect you to a terrible 'mobile version'. I certainly want better mobile sites, but not in the form of these AMP pages.
Here's the patch that adds it to the list of search providers: https://sr.ht/h4bZ.patch
When power is too concentrated in one area, its never a good sign for the common good.
The speed improvements and mobile friendliness should be the only criteria that the Google ranking engine should use for boosting the SERP rankings of these articles using it, not simply the fact they use AMP. But objectively measuring the quality of these page vs other unoptimized sites - which I hope is currently what Google is doing. That way there is nothing monopolistic about it.
Considering how awful most news sites are JS/ad-wise Google is attempting to solve a problem the publishers themselves created. Sites like Forbes are notorious for loading mb's of ads and they have that ridiculous quotes splash page. It also does away with annoying pop up modals news sites love to use.
So if these sites rankings are getting hurt because of their failure to offer good caching, image optimization, reducing the size of JS assets, etc, etc, to offer a competitive experience with AMP pages then I see nothing wrong with that. The competition will be good for users.
As long as publishers are voluntarily using this because it improves their UX then I'm fine with it.
Ideally in the long run this is just a stop gag until these publishers learn how to optimize their own sites. Then they can move off the platform. I don't see it as a viable permanent solution given the compromises involved and nor should the publishers.
My only complaint is the URLs are prefixed with Google.com making it harder to share direct links. But otherwise the UX improvements are worth the tradeoffs - in the meantime at least. If it's still the default in 2-3 yrs and news sites haven't fixed their sites I might take issue with it.
Edit: I did some testing and it looks like Google puts AMP articles in a carousel at a higher prioritized position vs other news stories. They aren't mixed with other news sites... that's not cool.
https://medium.com/@pbakaus/why-amp-caches-exist-cd7938da245...
I find it works well, I don't think there's any abuse of power, and I think it's an entirely necessary standard.
1: I won't have a page that bounces around for 5 minutes as useless, non-content elements load.
2: I won't have to peer at a few lines of content through a window of toolbars and ads.
I posted a complaint here a while back and the response I got made me wonder what I was missing. Like I was the only one who didn't appreciate it.
Yeah, I get that it speeds things up. But, do they really have to prevent you from linking out to the publisher's full site? There is no legitimate reason to serve up the publisher's content and force me back to Google. Can't even share the underlying URL. They are essentially hiding sites, but displaying their content. It's a hijack and I'm not sure why publishers approve.
And, on a recent search, the SERP only showed AMP, without the site name. Had to click thru before I even knew which site it was. Don't know if that was a bug or something they are testing.
Way too much power.
A spark icon next to the search result that would take you to the AMP page if you want to just read something without navigating to a whole new website and the behavior of clicking to a search result is the same as before ––or vice versa, an icon would still take you to a website.
Christ, I tried to visit https://productforums.google.com/d/msg/webmasters/_O8kJMSDpO... from a Google SERP to link to their forums about this issue, and there's an unavoidable Google login prompt gating it...and I use 2FA. Why in the hell do I need to log in to view a forum thread?
Hopefully the push their product cycle up a year or two and deprecate AMP in the next few months.
The bounce rate, time on site, average page views of AMP pages is always worse than on the responsive version. And as we now have responsive webpages + an AMP version to maintain the overall project costs got higher. Additional the AMP pages are already falling behind as devs and management just hate them.
And outside of the news vertical we haven't seen any major positive traffic impact (and as stated above, the usage values of the AMP-traffic is crap.)
Also we spoke with some users and they all were confused of "what happened to our site...".
AMP is a horrible idea with an even worse implementation.
We have to maintain variations of article templates for our responsive website, AMP, Facebook Instant Articles and Apple News now. Product owners and editors think implementing these things is cheap and easy because of all the marketing but unless you have something like a basic wordpress setup, it's plenty of work to implement and adds a lot of things to maintain and requires developers to remember which subset of HTML AMP uses, what the JSON API for Apple News is like... at least Facebook Instant Articles use rss...
so no test needed to know it's garbage. everyone already knew.
b) deleting page(variations) big scale is always a traffic risk
c) deleting AMP it's already discussed (by literally everybody), so it will happen (soon...ish)
d) the one reason not to do it is currently market monitoring. even though there is currently no major traffic benefit doesn't mean there will not be one in the future. so it's just a question of when the pain of AMP gets greater than the market-surveillance / curiosity / traffic bet.
Basically everybody who currently has AMP pages is the experiment guinea pig for the whole industry.
My bet: Most of the AMP implementations won't survive 2018.
Beyond that, universal opt-out should be possible and stats on the percentage of users opting out should be published real-time.
As such, until this is addressed, I am against AMP.
"In the spirit of open source, we're working to help develop updates to the project to address some of publishers' and end users' concerns. Specifically, here are some features we're developing to address concerns that have been expressed about AMP: ... A way for end users who would prefer not to be redirected to the AMP version of content to opt out"
But no, Google wants to own your content and users. Only very naive person believes they do it in order to fast up the web. If they started punishing harshly slow websites with 10mb of js, believe me ,it would change over night.
I think possibly the only thing that it can't offer that way is hosting the content through the Google CDN.
I am worried by the attempts of several huge companies (Google & Facebook, mostly) to get more of the open internet under their control.
My guess is that some altruistic folks at Google see AMP as a way of offering the best of both worlds.
But most of us know that in big business, every good idea gets abused for short term profits.
As kludgy as that is, I've found it a worthwhile workaround until this is fixed.
Keep in mind, a huge reason why Google created AMP is because website bloat has gotten out of control. It's not uncommon for a simply Wordpress blog to be 4MB in size and have 70 requested objects to fetch.
I live in a geography that has LTE and web site are painfully slow to load on mobile devices. I can't even imagine what the Internet experience is like in parts of the world still on 2G or 3G.
If people would stop for a moment and question to themselves "do I really need to use 5 different JavaScript frameworks just to post to my simply personal blog", there's a good chance AMP would not need to exist.
This is not the problem. You can easily use i.e. React and some related libs on mobile without slowing down the experience at all. Everything will be fast and responsive, loading times and the mobile site itself (if done right). The problem Google tries to address (and this is a real problem) are the cascaded ad networks on webpages which load hundreds of JS libs once a page is loaded. This is a huge problem and yes, it needs to be solved. Just go to any news site and open Chrome Inspector's Networking tab, then you'll be shocked about the millions of resources still being loaded. AMP is solving this by putting Google as the gatekeeper in front of all this networks. I am ok with this, those ad networks created the problem and I am fine if they now need to deal with Google's monopoly but I am not fine with being restricted in using JS in general because you can do it right, even on mobile.
Hasn't Facebook proven this to be incorrect.
Facebook mobile app was originally just HTML5 & JavaScript. The experience was so slow, they ditched it and instead built a native iOS & Android app. [1]
[1] https://techcrunch.com/2012/12/13/facebook-android-faster/
- On iOS, the FB App had to make do with a really slow JS engine at the time. IIRC Safari's JS performance was x5 compared to JS performance in apps' web views? This has more to do with how iOS treats apps, rather than how fast web pages in Safari are or were.
- The FB apps were okayish at the time, given that they were web based. If you manage to get your web app to that level, your site is ok. Now add to that the performance gains and browser optimizations of the last 4 years and you get a system that flies. Native apps are still faster and respond quicker to touch, but you cannot hold that against JS web apps.
It's certainly a large part of the problem. All this unnecessary offloading of processing to the client has gotten way out of hand. Why does a simple Wordpress blog (or any blog for that matter) that is essentially serving read-only pages need React in the first place? I have yet to see a blog that needs to be designed as an SPA.
This is _not_ a solution and google should not be doing anything with this.
No other site has gotten away with this. The last time I can recall someone attempting something similar was Digg (remember them?) with the "Digg bar" which added a toolbar linking back to Digg for all of the internet, and well, what happened to them?
Now, I'm visiting https://news.google.com/news/amp?caurl=htt%3A%2F%2Fwww.nbcne.... in order to get content from NBC News, while http://www.nbcnews.com works just fine. The writers of the article I'm reading are (ostensibly) hired by NBC news, not news.google.com, and there's no way to get to the same article on www.nbcnews.com unless I do something really awkward, like go back to Google and hunt and peck (I'm on my mobile phone, remember?) to type in "site:www.nbcnews.com article name".
I have hate for the UI of AMP itself (they broke scrolling down to get to the URL bar somehow), but that's also a distraction from the fundamental contract that AMP breaks.
Google would (rightly) get pissed if I made my own search page which "rebranded" Google search results to have my advertisement and then present the Google search results as coming from me; I hate them for doing the same thing to news publishers.
Cached from: nbcnews.com/some-article
Would you feel better about it?
The entire idea is insane. Google is just another company on the internet, and should be treated like any other.
AMP is a curated subset of web functionality designed to load quickly and be safely cacheable. Like SVG, it's an open attempt to solve deficiencies in the platform. It's been sponsored by Google and adopted by a lot of their properties, but it's unfair to call it "Google's news product."
What other servers are serving AMP pages, (edit: and would benefit from this "cached from <other site>" URL bar display logic) other than Google's news product?
But all of those URLs display correctly.
We're talking about having browsers add special-case logic in which some URLs on one particular special domain (news.google.com) belonging to one private company (Google) are treated and displayed differently than everything else on the internet.
> If they then also got rid of the requirement of loading the AMP JS from a CDN Google runs, they'd actually have something resembling an open standard
Sure, if this turned into an actual Open standard, and we were talking about extending browser display logic to any server on the internet that served an AMP page belonging to some other site, that would make sense.
But having browsers bless one company's subdomain with special rules that apply only to it is about as anti-open web as you can get.
I totally agree with you on that. They could easily get rid of their cache domain for serving AMP, or people could build browser extensions and other projects avoiding it while still using AMP, but only because all the publishers behind it already serve AMP if you ask for it. Which is why I made the point that it is not just Google serving it, which I clearly should have explained better.
I have mixed feelings about it myself, as it isn't always obvious you're seeing content from website.com not google.
It's annoying that its location isn't standardized.
I also dispute your qualitative opinion that nbcnews.com works "just fine". If I load their top story currently from AMP it loads in about half a second. If I visit it from nbcnews.com it renders in about seven seconds and doesn't finish loading for about 90 seconds, and then when it does I get a big popover survey/ad thing with a dismiss button that's too small to touch. The mobile experience on this site is far from fine.
It's not.
The web has bloated out of control - and while I'm not a fan-boy, I at least think AMP encourages the right things and is a progressive step forward in the right direction.
I _like_ viewing AMP pages from an end-user perspective. And I don't think they're terribly onerous from a publisher/dev perspective.
https://medium.com/@pbakaus/why-amp-caches-exist-cd7938da245...
At the risk of getting off topic, the reincarnated Digg is actually pretty good.
Lots of users don't operate that way. Caring about the URL is increasingly going in the direction of caring about the IP address.
I can share the link by tapping the "Share" option on the dropdown menu in my phone's browser. Works great.
Google's AMP policy has been aggressive and heavy-handed. You can appreciate the technology and Google's desire to make the web faster and disagree with how they are implementing it.
That would be a huge driver... if nobody with over 1mb of html+css+js would be in the top 5 results, period.
Instead, they created a way to hijack the mobile web and become the de facto content presenter for any publisher who doesn't want to be punished by Google.
https://moz.com/blog/how-website-speed-actually-impacts-sear...
b) Google has become really smart nowadays. You could theoretically game everything in this world. They execute the javascript and run the page, they already know how to detect banners, interstatials etc. They also have manual team giving out bans.
Citation?
The six years is the age of the speed PageRank signal, according to the grandparent post.
"Hasn't improved things," I had assumed 'the web is getting slower' was common knowledge, but here's an example of the family of articles you can quickly find on the subject: http://www.webperformancetoday.com/2015/07/08/news-sites-tak...
Here's a fast loading, well designed webpage: http://myfreeweather.com/
yet when I search for "weather", all of the results are slow, terribly designed sites. The above site is nowhere to be found. The same goes for other "common" sites like lyrics, etc.
Yes, the problem that AMP is trying to solve is real, they are just going about it in the opposite way that they should be.
Edit: In a way, AMP feels like a scheme by Google to force content providers to enforce the solution to a problem that Google created. They're trying to speed up the web with their right hand while slowing it down with their left.
This is the same logic behind monopolies being bad. Nobody thought AT&T was bad for providing phone service to everyone in America; that was unquestionably great. What was bad was the way that nobody else could provide potentially-better phone services. Nobody thought Microsoft was bad for giving people a web browser in the IE 4 days; what was bad was abusing their OS monopoly to gain a web browser monopoly, because IE 5 and 6 started implementing MS-specific technology.
There are lots of ways to implement the benefits of AMP without the vendor lock-in Google is pushing. It's certainly technically much easier for Google to implement it in the way they're currently doing so, but that's a short-term and short-sighted gain.
Fuck Google and their eagerness to govern the World Wide Web.
Instead, google built an entirely new presentation method itself. This engineering effort can not be ignored and it was not on accident that this happened. They are quite literally stealing the traffic of users who implement AMP.
I'm not a web dev, but I understand there were also requirements about deterministically sizing elements, as having things jump around the page is really disruptive to a mobile user. I thought the presentation method stuff was to help prevent presentation issues, including dark patterns.
Is there a way to use static or dynamic analysis to prevent that sort of thing?
https://developers.google.com/speed/pagespeed/
https://developers.google.com/web/fundamentals/performance/
It didn't work.
And given that the solution to Google "stealing" a site's AMP traffic is that site just stops supporting AMP, the "stealing" argument doesn't hold a lot of water. If I'm a small publisher, Google caches taking page hits on popular topics instead of my server is a boon, not a hindrance.
Also, not supporting AMP is not a casual decision for some companies. My blog doesn't earn me revenue so i can happily tell google to pound sand before i support AMP. Can revenue-driven publishers due the same and sacrifice their SEO like that? I doubt it.
> Google caches taking page hits on popular topics instead of my server is a boon, not a hindrance
I simply cannot disagree with this more. Your most popular posts/topics are what generally drive the viewership and discovery of your site. I want those viewers. With AMP, they are looking at google, with a google URL, and a nice big "X" to close the window, never to see my site again. I don't see how this can be defensed at all. It is the exact opposite of what you are aiming for as a publisher, big or small.
You seem to be assuming there's a category of user who is casual enough that they'll page away after reading the one amp story, yet if they'd been on your content-originating site instead, they'd be like "Oh, now that I've read that, I should go click these links and read other things from this source!"
I'm not sure why we think those users exist.
After 5 minutes of diverting from my main task and try to debug what is wrong with this, I gave up and just removed the AMP URL prefix to head for the actual Reddit website (not sure how a non-poweruser would figure this out). There was simply no other way to reach the information I needed from the Google Results page which did not let me leave the AMP page.
Either Reddit was broken at the moment or something with AMP or something with my mobile client. But the web is supposed to "just work" and Google is seemingly breaking that with AMP. I am certain it helps some people reach to content easier with less data costs but if only it "just worked".
What if I don't want to use Google's AMP cache and rather my own CDN? What if I don't want this useless AMP banner at the top of my AMPed pages which takes 25% of the screen estate for nothing? What if I can build fast mobile sites without following the AMP spec?
Then it's harder for google to make _more_ money out of you. It's all about growth, and since they won search, they are desperately trying to grasp something.
> So while Google means well here, Prince says, AMP hasn't been as open as publishers were perhaps hoping it would be. You still have to give your content over to Google to take advantage, which is suboptimal for publishers.
> This is where Cloudflare swoops back into the picture. By working with Google as the first AMP partner, Cloudflare is contributing to making AMP "a really open standard," Prince says. And this announcement of loading mobile AMP pages seems subtle, but it's the first time that these lightning-quick pages are served out of Cloudflare's system, and not Google's. It's something publishers have been asking for.
If it were possible to just host the AMP content using another CDN not blessed by Google it would have been trivial for these publishers--almost all of whom certainly are using CDNs such as Akamai--to host their own content. It is only by being an "AMP partner" that this seems to have been possible. Do you have any evidence on the other side of this? I ask because from my perspective I can't "charitably" get to your interpretation given the reading I did on this subject.
> In the AMP ecosystem, the platform that links to content may freely choose which AMP Cache (if any) to use. It is an inversion of the typical model where content delivery is the responsibility of the publisher.
Yeah, that's certainly one way to look at it. Yet in my book, the "AMP 'format'" (emph. mine), above all, ensures the continued assimilation of the open web, and with it most of ad revenue collected there, into the huge moloch that is Google (and its AdWords and Analytics infrastructure). I think it's a disgusting technology to adopt, and none of its supposed benefits are worth the drawback that you're giving away control over the end-to-end communication with your actual users.
I wish they'd just push to solve the actual problem, instead of using this as a chance to push people into their system. The issue they are trying to solve is absolutely real, but adding more layers and complexity to prevent layers and complexity is the opposite approach that they should be taking.
I don't pretend to know half of the metrics they use to rank a site, but IME, it doesn't seem like speed is at all relevant.
It's more like if you had two sites with identical traffic and identical content relevancy the faster site would rank higher... which makes sense.
If your site is incredibly popular, it's logical to think that people are finding it useful and therefore it should rank higher. That's less true than it used to be, but it's still valid as one of the primary ranking metrics.
I've seen too many of the former to believe Google is trying to push the later.
For bloated [anything involves computers]? No. That's on us.
EDIT Also I'd add further that at some point, this "free" and compulsory AMP cache will start inserting google ads directly into pages and Google will pay publishers a small percentage of what those slots are worth.
Google is thus trying to keep people in their "feed" and reduce the cost of their ad inventory by (in theory) reducing publisher payouts over time as a result of this leverage.
Really can't be in favor of it until those issues are fixed.
It really is only about getting yet another way to collect data on users and push ads down their throats.
Have you used it? Even on a Nexus 5x running on fast wifi, the difference between loading a Washington Post site from AMP and from washingtonpost.com is tangible.
AMP should be supported by CDNs and toggleable in the browsers though.
My guess would be that you have a content blocker, ad blocker, anonymizing proxy, DNS server with ad-blocking, or something in your setup that's breaking it, because it's not broken natively.
But because they have a completely different scroll weight the feel wrong. I can't easily share them, and the stupid bar at the top of the page takes up 15-20% of my screen.
They're obnoxious to interact with. If they fixed just two of those issues (make the bar tiny, don't mess with scroll feel) I'd be a lot happier. As it is I find myself actively avoiding AMP links in Google, but as the become more prevalent I wonder if I'll have to switch to some other search engine on iOS.
Google has fixed it so the site name header finally goes away when scrolling.
Well, that's an improvement at least.
I'd still like to push for an open, standards based approach to tackling the issue of content delivery under resource constraints.
You enable amp, like maybe you started using png over just gifs - and then Google takes your search hits hostage by rewriting the url, adding a banner - and forcing you to keep the amp version if it turned out to fit you and your users or not.
The amp spec looks friendly and harmless - a good use of html5's flexibility. On the surface the only odd bit is the reliance of js to get the "new" image tags to work (with resulting reduced flexibility wrt Web user agents, like w3m).
And suddenly Google controls your page design for everyone that finds your site through Google!
This is not open, there is no source, because AMP is a hosted service.
Instead, we have a one-size-fits-all that they control utterly. No option to do something that works just as well, via different means (your own image compression, optimized http2 support, etc).
Kill it with fire.
I could even just ignore this problem if there was a way for me to say "I have a 10Mbps 4G connection, please show me the actual site and not this broken half-implementation of it." Even then, it's sketchy.
From there, we get years of unoptimized, bloated websites made by people drawing pictures with HTML editors. They are exclusively focused on visual presentation and ignore any mechanics under the hood. Not everyone, but most. Finally Google can't take it anymore and creates AMP as an angry middle finger to these people. ("I drink your milkshake!")
IMO the right solution is to use speed as an increasingly more important ranking signal. Push crummy bloated websites to the bottom where they belong. I read the article but didn't see Google address this rather obvious idea.
One look at the source code for most popular sites shows this isn't true – and that makes sense because when you look at the average sluggish site the bloat is mostly JavaScript rather than the HTML source.
What's actually happening is that a bunch of people are working hard on something which is important to them but not the user: advertising and analytics, followed by “social” sharing. Since those numbers are associated with revenue, they're directly seen as important whereas concerns about page-weight are more subtle and often an inadequate check on bloat until it gets really bad.
Although I reject the idea that popular websites are representative of the web in general, let's investigate that anyway. Currently on the HN homepage:
1. Netflix blog post scores 73/100 and 85/100 on Google PageSpeed Insights.
2. Flickr post gets 67/100 and 83/100 on PageSpeed.
3. Google's own post gets 61/100 and 79/100 -- oops!
4. gatech.edu gets 66/100 and 82/100.
All bad, decided to stop there. Even many/most popular pages are bad (careful reading shows that I didn't say all) . This jives with what I've seen as someone who looks at Google PageSpeed Insights A LOT.
> average sluggish site the bloat is mostly JavaScript rather than the HTML source
Someone "drawing pictures with HTML editors" as I said is still going to add JavaScript, images, css, etc. They'll also specifically add tons of unoptimized images that aren't even losslessly optimized, let alone put through manual lossy optimizations. I bet the average webmaster can't even define lossless and lossy.
FWIW I think AMP is just awful. In contrast, Google PageSpeed Insights is amazing. I adore the PageSpeed website and recommend it wholeheartedly. It's been a huge help to me.
The solution to this mess is competition, not centralization. Make speed a major ranking signal and let the ecosystem say goodbye to those who can't hang.
Yes, I think the ease of publishing has led to a lot of people publishing who don't know what they're doing. I have an issue with our "webmaster" inserting full-resolution >4mb photos into our site pages to display at 200x400 boxes. I've told them several times that they need to keep image sizes down, but the person is never consistent. I wish I could disable caching on that user's PC so they could see how horrible our initial page loads are.
I try not to browse our website because I want to fix the bad pieces and it's futile because what I improve is eventually undone when new content is rotated in. I'm just the systems guy, and our website is run by marketing.
Great. Except that that information might be deliberately a part of the image.
These things should be opt-in.
The mobile Internet has become a far more frustrating place for me since Google introduced AMP. I just want to be able to turn it off.
Some of the concerns really should be addressed though: a clickable and copyable link could be handled with a widget at the bottom of the page, for instance.
For now. I do have a bad feeling that Google will keep pushing towards this.
That's not really an option, unless you're trying to go after the Bing/DuckDuckGo market.
Google own the web and people have no choice. Monopoly.
You may be against some principles, but it's an absolute life-saver sometimes.
Google is presuming to know what I want and it is irritating.
This way, google "saves" those sites by essentially stealing content, since from now on, visitors won't even hit your site.
A slow connection combined with huge websites are practically unusable.
>carefully crafted pages
Yes, this is the ideal solution - people adopt saner (and smaller) web development. But that is uncontrollable and, frankly, I don't see it happening.
What's really annoying is that your problem could be solved without causing all of mine.
He's the thing: I CAN'T OPT OUT. If I don't like it or don't want it my only option is to ditch Google.
Google gets to make this happen because they own the users, and there's very little to be done about it.
The only countermeasure I can think of is if lots of publishers were to boycott AMP en masse. But publishers have been unable to reduce web bloat any other way, so what would their upside be?
Or edit the URL to remove the beginning from "http" to "/amp/s".
Or View Source and go to the link in "link rel='canonical'".
I wonder why Google is taking a fixed reduction of image quality reduction rather than considering a dynamic image quality reduction approach like JPEGMini[1] and Kraken.io[2] took?
The latter ones will take visual perceptions into consideration hence they are usually able to squeeze out more bytes savings in the end.
[2]: https://kraken.io
It's their datacenter using fewer ops on more content to do what they initially set out to do--organize the world's information.
Normalized images associated with a reduction in front-end presentation content can train the IRL bots orders of magnitude more quickly.
Even w/o AMP you need to have fast downloading images.
Even w/o AMP you must use a CDN.
So don't call it AMP. Call it: "SEO optimized and for when users are not on Wi-Fi or for huge scale/load". You can include the lighting bolt or not.
Wha, wha.
More specifically, how do they not get sued into oblivion for copyright infringement? They are after all redistributing content they are not licensed to redistribute.