Google AMP Cache, AMP Lite, and the Need for Speed(developers.googleblog.com)
developers.googleblog.com
Google AMP Cache, AMP Lite, and the Need for Speed
https://developers.googleblog.com/2017/01/google-amp-cache-amp-lite-and-need-for.html
246 comments
AMP is horrible and I wish European Union or someone would hit hard on google. They are essentially forcing websites to format the sites in exactly the way Google wants, then they steal the content. All these google SEO guidelines inevitable end up helping google becoming even more powerful abusing their almost monopoly in search engine market.
When power is too concentrated in one area, its never a good sign for the common good.
When power is too concentrated in one area, its never a good sign for the common good.
Google has long increased the rankings of sites that load quickly and are optimized for mobile. For good reason.
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.
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.
They are not stealing content - the user is served a page on a publisher site and/or CDN and the publisher gets their ads, analytics etc
Furthermore, all the traffic is clearly attributed to publisher, and <amp-analytics> lets you measure that.
https://medium.com/@pbakaus/why-amp-caches-exist-cd7938da245...
https://medium.com/@pbakaus/why-amp-caches-exist-cd7938da245...
I switched my default search engine on my phone from Google to DuckDuckGo because I got sick of the growing number AMP links, which I also don't like for all the same reasons you listed.
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.
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.
AMP annoys my too, but it hadn't occurred to me to switch to DuckDuckGo. Good idea, just made the change.
It's definitely not perfect but I've found DuckDuckGo to work reasonably well for the kind of quick searches I tend to do from my phone. Plus if it's giving you bad results you can tack on !g to the query and it'll give you the google results instead.
It sure would be awesome if Chrome on Android had it available as an option. But, it's Google.
If you trust APKs from random strangers on the internet, here's my custom Chromium for Android build with DDG support: https://sr.ht/dIQO.apk
Here's the patch that adds it to the list of search providers: https://sr.ht/h4bZ.patch
Here's the patch that adds it to the list of search providers: https://sr.ht/h4bZ.patch
Thanks, I tried some Chromium based browsers on the Play Store, but they all have unreliable or even non working Chrome Sync. I'd go full FF, if scrolling on Android wasn't so jerky compared to Chrome.
Changed my iPad search engine to Bing
AMP is devastating blow to Publishers because not only does it marks Google's intent to steal away traffic, but also punish publishers for not allowing that to happen.
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.
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.
It is in essence Google following FB in what they did with Instant Articles. Users start in their ecosystem and they don't see any value in them leaving their ecosystem unless they are going to buy something.
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.
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.
Hang on, I'm not a big AMP fan but it does not steal publishers traffic at all.
It does siphon traffic by serving it from google.com, and adding a frame to the top that when clicked will take you back to Google.com. When you swipe left or right, it takes you to other AMP links from different results.
AMP links are given priority in search.
AMP links are given priority in search.
If I recall, the page is actually served from a google.com domain.
It is, but for good reasons - https://medium.com/@pbakaus/why-amp-caches-exist-cd7938da245...
I completely agree. The fact that this cannot be disabled (like preferring a desktop site over a mobile one) is really annoying. Google is meddling too much in the website, they need to back off.
if you use https://encrypted.google.com there's no AMP
When I visit that in mobile safari, it prompts me to install some Google app. It's like they're seriously trying to piss people off.
Man, this and a bucket of chicken.
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.
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.
Conversely, I love AMP.
I find it works well, I don't think there's any abuse of power, and I think it's an entirely necessary standard.
I find it works well, I don't think there's any abuse of power, and I think it's an entirely necessary standard.
Same. An AMP link tells me two things:
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.
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.
Reader view in mobile safari solves these things client-side. There are others. It's a rendering decision which should be left to the client vs forcing a decision on users in a way which breaks some configurations for people (since there's no way to disable AMP).
Most people, myself included, are not on iOS. It's not solved for most people.
For what it's worth, FireFox has a similar reader view on Android and desktop.
I hate the scrolling on mobile (iOS). I don't know what they tried to do, it feels like a JavaScript smooth scrolling on top of native smooth scrolling.
In mobile Safari you can tap the area right above the address bar to scroll all the way back to the top of the page. But not on AMP pages.
I believe that for some reason, possibly because of the way the pages are set up with the top bar that shows you the URL of the real page (since the AMP page is hosted on google.com and breaks the normal function of the URL bar), they use an element with CSS `overflow: scroll` to hold the main page content. There's a trick to making those elements have momentum scrolling, but it has different acceleration settings than the normal iOS Safari page scrolling, so it feels slightly off. See: https://css-tricks.com/snippets/css/momentum-scrolling-on-io...
This ones really annoying and made me switch to DDG !g.
Agreed that whatever they do to scrolling is awful. On my phone (android, firefox mobile) I can't use Google News anymore because I can scroll down, but can't scroll back up.
The worst part is that you can't choose to load the non-amp version. On iOS, since AMP links to Reddit are 100% broken, I need to URL hack in mobile safari to remove the AMP bullshit to even load the page.
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.
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.
I often think if this would make people like you happier:
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.
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.
add me as one of the duckduckgo users because of AMP hatred.
[deleted]
I implemented AMP on my own project and we implemented it at some clients ... all regret it.
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.
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.
Absolutely agree. I work in publishing, our readers are confused by the changed design of the site (Who the hell knows about AMP or Instant Articles besides people in the industry? The average reader doesn't care).
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...
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...
Question: Why do you not then just switch off the AMP support and stick with responsive pages? It sounds like you just generated an A/B test with some pretty easy-to-interpret results.
a) for deleting amp you need to implement some ping logic https://developers.google.com/amp/cache/update-ping#remove-a...
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.
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.
because nobody used amp because they assumed it was a good idea. it's 100% because google gives better seo position if you use it.
so no test needed to know it's garbage. everyone already knew.
so no test needed to know it's garbage. everyone already knew.
Did you consider that higher time on site may be a false indicator? It could be your users being forced to sit and wait for complete page loads. Or time spent trying to find the real next page link.
There is zero reason for AMP to be hijacking URLs or embedding any additional elements into a page that are detectable by the average user.
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.
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.
Sounds like Cloudflare is working on it [1].
"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"
[1] https://blog.cloudflare.com/accelerated-mobile/
"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"
[1] https://blog.cloudflare.com/accelerated-mobile/
Indeed. We have pagespeed, use it as a higher signal.
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.
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.
UX is still horrendous.
Same here. In addition, the reasoning in the article doesn't sound sincere. If Google really cared about site speed, they would already promote fast pages more in their search results. They said they would, but it seems the boost is almost negligible.
I am worried by the attempts of several huge companies (Google & Facebook, mostly) to get more of the open internet under their control.
I am worried by the attempts of several huge companies (Google & Facebook, mostly) to get more of the open internet under their control.
Would you rather see a fast site with rubbish content, or a slow site with good content?
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.
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.
Why is there any relation to the quality of the content?
The OP said Google aren't doing enough to promote fast sites. My point was that quality is more important than speed.
Quality is orthogonal.
Google can't offer the full amp experience where pages load instantly without controlling the domain. Otheriwse, none of the optimization they outline in the blog post would be possible since it is the proxy that performs them.
That's kind of the point though. Instead of controlling other sites, they should be promoting sites that do the right thing.
That's not entirely true. mod_pagespeed (https://modpagespeed.com/), a plugin from Google for Apache and Nginx, does a whole bunch of the stuff google is offering through AMP, and it's theoretically capable of doing almost everything there. It optimises content on the fly, and stores cached versions of them on the drive for later hosting, etc. etc.
I think possibly the only thing that it can't offer that way is hosting the content through the Google CDN.
I think possibly the only thing that it can't offer that way is hosting the content through the Google CDN.
On ios safari, holding down the refresh button in the url bar gives you the option to request the desktop site.
As kludgy as that is, I've found it a worthwhile workaround until this is fixed.
As kludgy as that is, I've found it a worthwhile workaround until this is fixed.
It also sucks if you want to interact with the page, since, inanely, you can't click through to the real page.
The silliest part is that clicking the x in the AMP bar doesn't redirect you to the real page... it just takes you back to your search results.
Content providers have the option of offering a link that goes to their main content. However, it's not standardized how that's set up (in WaPo, for example, it's under the top-left menu as "Progressive Web App (BETA)" ).
What can you do on the real page that you can't do on the AMP version?
Looking at this from the users perspective, the URL is becoming less noticeable anyway. On mobile you don't have the screen real estate for it. And I don't see the average user complaining about the sub-second loading times. If anything, this is a step in the right direction.
Hey, just like they did with G+...and look how that went. Something something making the same mistakes over and over again.
There's a lot of hate going on in this thread towards Google ... maybe unfairly.
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.
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.
You have a valid point about page bloat, but its a distraction and a poor excuse for hijacking the entire web. My hate for AMP is because Google is using its might to break a fundamental contract for how the web works - the URL bar shows what site you're on, and content is coming from that domain.
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.
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.
You don't seem to understand the technology or the argument you made. The URL bar says google.com because google.com is serving the content you are reading. In other words, it exactly honors the "fundamental contract" you find so important.
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.
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.
And what happens if you load the AMP version from their server, which IMHO is the fairer comparison when discussing complaints about the Google cache of it? AMP as a "document standard" on top of HTML would IMHO already solve a lot.
It's not really a fairer comparison, because their non-AMP view is what they currently think is appropriate to serve.
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.
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.
Google could easily "motivate" them to provide AMP pages (as they have successfully done) without adding their own caching layer, which the complaints above mostly seemed to be about.
This post explains very well the #1 benefit of AMP caches (yes, there can be more than Google's, and Cloudflare has just released their own cache): pre-rendering:
https://medium.com/@pbakaus/why-amp-caches-exist-cd7938da245...
https://medium.com/@pbakaus/why-amp-caches-exist-cd7938da245...
If browsers detected AMP pages and treated the address bar accordingly:
Cached from: nbcnews.com/some-article
Would you feel better about it?
Cached from: nbcnews.com/some-article
Would you feel better about it?
Under no circumstances should web browsers be hard-coding special favors to paper over deficiencies in the user experience of Google's news product.
The entire idea is insane. Google is just another company on the internet, and should be treated like any other.
The entire idea is insane. Google is just another company on the internet, and should be treated like any other.
SVG was Adobe's open implementation of the ideas of behind Macromedia Flash. It solved a real pain (the lack of vector support on the Web) and has been implemented by all the browsers. Does this upset you? Most of the progress of the web platform is sponsored by companies like Adobe and Google.
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."
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."
SVGs are displayed whether or not they're hosted on Adobe's servers.
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?
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?
All the publishers Google copies the AMP from? Google could just redirect mobile users to that if they wanted, as can every other site linking to a page. 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...
> All the publishers Google copies the AMP from?
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.
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.
> 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 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 would love that.. beyond that, a link that says "go to <website.com>" for that article, or some such, that would help too.
I have mixed feelings about it myself, as it isn't always obvious you're seeing content from website.com not google.
I have mixed feelings about it myself, as it isn't always obvious you're seeing content from website.com not google.
That link is often provided by the content providers (check bottom of page or under a dropdown menu).
It's annoying that its location isn't standardized.
It's annoying that its location isn't standardized.
That would be far worse.
I just browsed to the first NBC news article I could find and at the bottom of the article was a big button saying "View full experience" which took me to the normal NBC website. I'm not sure I see the big deal?
> 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?
At the risk of getting off topic, the reincarnated Digg is actually pretty good.
At the risk of getting off topic, the reincarnated Digg is actually pretty good.
Why do you need to get to the same article on www.nbcnews.com ?
So I can share a real link. Remove google's huge amp toolbar. Scroll normally. Have a correctly rendered page. Because I want content from the source, not google.
That seems an arbitrary desire based on an older-model of web surfing that still gets around a site by physically selecting and deleting pieces of the URL.
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.
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.
If google thinks page bloat and loading speed are a problem, they could have come up with a set of recommendations (likely most of the ones in AMP) and use PageRank to promote websites that adhere to those standards.
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.
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.
In case your not aware, since 2010 Google has in fact PageRanked higher faster web sites.
https://moz.com/blog/how-website-speed-actually-impacts-sear...
https://moz.com/blog/how-website-speed-actually-impacts-sear...
Which is exactly the point. Use it as a stronger signal and case closed. Web will change the way they want. Always. Right now they want to change it to their walled garden.
If they've been using it for six years, and it hasn't improved things, what makes you think using it as a stronger signal will (a) actually improve things, (b) not make it trivial to game SEO?
a) It would improve things because website owners, seo's or whatever you want to call them, always listen everything Google says. I'm in the industry. One tweet from Matt Cutts and they are already changing the brand name if Matt tells them so. That is the way industry works. Everyone knows site speed is a weak signal. Google could impose harsh penalties but they don't.
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.
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.
> they've been using it for six years, and it hasn't improved things
Citation?
Citation?
On the six years or on the "hasn't improved things?"
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...
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...
I'm not sure that they prioritize it enough. I've used this example elsewhere here but...
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.
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.
> 5 different JavaScript frameworks
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.
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.
> This is not the problem.
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.
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.
Not sure why you're being downvoted. You're right. I'm not a fan of React and ilk myself, but they aren't the problem. Ad delivery technology is the problem, and Google itself is a huge part of that since they own so much of the ad industry.
>> "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."
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/
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/
That article is four years old. Facebook's app architecture has changed significantly since then, as has the speed at which JS can execute.
Two more reasons why this comparison is not on point:
- 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.
- 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.
That seems irrelevant here -- Facebook is a web app that needs you to log in, and displays user-specific info in a very dynamic way. It's not the kind of thing that could ever be cached, whether by Amp or any other generic CDN.
That article's no longer relevant, and in any case the existence of a bad implementation does not mean that a good implementation is not possible.
No, fastlite and a dozen other facebook apps have proven this incorrect. The official facebook app is slower, more bloated and battery draining than the mobile version ever was.
Would this theoretically be solved by some HTTP 2 stuff?
It's not Google's responsibility to fix the bloat.
If something is painful, let it be painful; when they start losing visitors, they'll see something is off.
This is _not_ a solution and google should not be doing anything with this.
This is _not_ a solution and google should not be doing anything with this.
Sure, but Google can offer tooling and best practices to push people in a certain way, like they do with everything. The best way to encourage people to move to new technology on their own is to change the search algorithms to provide positive incentives to implement those changes. Look at SSL. A lot of people don't care about encryption, but they care about SEO improvements more.
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.
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.
They could easily heavily penalize any website delivering over 1mb of html + css + js, and have a bonus for being under 500/100/50kb total as part of their pagerank.
That would be a huge driver... if nobody with over 1mb of html+css+js would be in the top 5 results, period.
That would be a huge driver... if nobody with over 1mb of html+css+js would be in the top 5 results, period.
What you've described would be a pretty game-able SEO algorithm.
So is every Google's guideline, yet most fail to game them. Google is smart. And good people will follow the guidelines instead of testing if something can be gamed, majority of industry is afraid of Google and its guidelines.
Anecdotally, client-side bloat is mostly going to be ad tech -- not React & company. Since Google and Facebook have such a tight grip over ad tech these days, maybe a better fix than AMP would be encouraging server-side, rather than client-side, ad delivery.
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.
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.
If the issue were really about page speed, google could penalize the rankings of slow sites. No need to shovel a broken, self-hosted version of the site onto me.
well then they could have announced that they were going to aggressively penalize sites that were too bloated and SEO would take of the rest.
I think HN crowd doesn't fully appreciate the benefits of AMP to people having slow connections. In third world countries still on 2G networks AMP has been an absolute boon. Additionally, lot of these users have limited data packs so they're better served by pages which are light in data consumption. This is true even for a lot of low income neighborhoods in the US. Making AMP opt-in would defeat the purpose as a lot of the target users would be unaware/unable to opt-in.
I think you are missing the disagreements with AMP entirely. Google, with less effort, could have released a series of requirements for a page to be considered "AMP"ed: (examples) 0 blocking script requests, less than 500KB in total page load, page loads in under 1s, etc. Once your pages meet these requirements, they gain the AMP moniker.
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.
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.
What you're describing has already been done.
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.
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.
A few disagreements with your analysis: AMP was given a wide spread announcement that generated an unusual amount of press. It was impossible to ignore. If page speed was such an important (and viable) solution, google could simply have announced they would more heavily favor sites that performed well.
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.
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.
What stops you from providing links to additional content on your site on the amp-enabled page?
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.
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.
It didn't work because Google didn't create it as a strong signal. Make it matter and the majority of sites will change the next time. One Tweet from Matt Cutts and everyone's already re-doing sites for SEO purposes. Set clear guidelines and rest will follow. But Google wants to build its own news portal to compete with FB.
> Instead, google built an entirely new presentation method itself.
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?
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?
The google search spider literally loads webpages in a specialized browser to analyze them, a little instrumentation or even a brute-force comparison would let them detect bad behavior (and monitor load times).
It's a huge benefit with long-term negative consequences. It's the same reason the HN/EFF crowd is opposed to things like T-Mobile's "Binge On" program, where video traffic from certain providers doesn't count against your bandwidth: it's unquestionably great for an individual end user wanting to access that site, but it sets up a system where certain incumbent providers have structural advantages against newcomers—i.e., it violates net neutrality. In the future, that same end user is likely to consider getting content from another site, and be dissuaded because Binge On (or AMP) doesn't apply. A provider-neutral solution wouldn't get in the way of competition and growth.
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.
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.
I'd settle for being able to opt-out, but as it stands, no such global setting exists, or is far too hidden.
I think HN and much of the tech crowd also forget how unreliable internet connections can be. I don't know what it's like in silicon valley, but here my 4G connection will drop out several times on my short commute to work and webapps generally don't cope with it well, or at all.
They could just use Opera Mini, or have Google fix their Web Compression Proxy so it actually compresses HTTPS, and if you opt in then it's all good, and have it prompt users on slow connections to enable it like how Opera 12 prompted you to enable Opera Turbo.
It should be opt-in then. The UX is lackluster.
That's the same argument as giving up privacy for security.
Fuck Google and their eagerness to govern the World Wide Web.
Fuck Google and their eagerness to govern the World Wide Web.
The most annoying thing about AMP is that there is no way to get the original link easily. I don't necessarily mind reading the AMP version, but if I bookmark or share the link I want to be able to use the original and not Google's copy. Whose to say the AMP link will work as long as the original copy? And what if I explicitly want to use the result as an entryway into the site because I might be looking for other similar articles on the site or need other aspects of the full site experience? AMP seems like it could be maybe be a good thing, but the lack of a method to get a link to the original article exposes AMP, IMO, as the traffic and power grab that it really is.
I strongly agree with this. The other day I was searching something on my phone and stumbled upon the result in Reddit, which was using AMP. I clicked the result, the AMP UI was loaded but the content area had an ever-spinning loading icon. It was frustrating, I thought maybe it was my ad-blocker on iOS, so I disabled it and tried it in Safari's Incognito mode. No luck...
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".
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".
I have a bad feeling. Google is creating a proprietary version of the mobile Internet, a layer between them and us. Looking at the specs, it's open but paired with the AMP cache and Google's ranking algorithm which already clearly prefers AMPed pages it doesn't feel like a free choice.
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?
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?
Cloudflare just launched their own amp cache. Nothing proprietary about this.
As far as I can tell, to do this they had to partner with Google, who are the arbiters of what is and is not AMP compatible. This is absolutely "proprietary" and honestly pisses me off even more than if it were only Google's servers in charge of this stuff as now they are screwing with the CDN market as well :/. An open standard is something anyone can implement and be compatible with, without permission.
I agree that having access to the original source is valuable. For that reason I went to Cloudflare's original post (as opposed to the Business Insider article you've linked to). Their original post (https://blog.cloudflare.com/accelerated-mobile/) links to the AMP cache guidelines on the AMP GitHub repo. The guidelines start like this:
> 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.
> 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.
You may take from the story what you wish, but afaik, the collaboration you're referring to was informal engineering discussion, not required permission. I can't charitably get to your interpretation from the blog posts or public comments by those at CF.
http://www.businessinsider.com/cloudflare-adopts-google-amp-...
> 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.
> 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.
I think the amp partner term is silly. If akamai wanted to, they could host their own cache. There is no evidence that Google is doing anything but encouraging cdns to do so.
> 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.
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.
"At Google we believe in designing products with speed as a core principle. The Accelerated Mobile Pages (AMP) format helps ensure that content reliably loads fast [...]"
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.
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.
"Instead of helping sites to solve the problem, we'll take care of it for them! And no need to worry about vendor lock-in, we're 'not evil', remember?"
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 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 think they have been trying to push people in that direction. They penalize you for having slow load times and too small of touch zones among a variety of other ux factors. But the progress has been slow.
Have they? I'm not arguing, I'm genuinely curious because I guess I don't ever see that happening. Whenever I search for something that has a bunch of results, like weather, I end up with 30s loading, JS-filled, nightmare sites that are slow, bulky and don't show the information in a clean format. Yet there are good, simple sites like http://myfreeweather.com/ that are ~8 pages into the results.
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.
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 part of the algorithm, but it's not enough to offset the fact that a bloated site like weather.com gets astronomical amounts of traffic from all sources (direct, paid, organic).
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.
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 guess I see it as chicken and egg problem: Is the site popular because it's one of the top results? or is it the top result because it's popular?
I've seen too many of the former to believe Google is trying to push the later.
I've seen too many of the former to believe Google is trying to push the later.
[deleted]
i agree, but i don't think google is 100% to blame. The web-designers etc. have failed to provide fast, mobile optimised pages that perform the same optimisation that google now produces. Google is just taking advantage of the neglect for providing a mobile-friendly, bandwith-adapting web experience.
For AMP? Hell they are.
For bloated [anything involves computers]? No. That's on us.
For bloated [anything involves computers]? No. That's on us.
To me AMP feels like embrace and extend for the whole mobile web. I find them caching things this way both pointless and dangerous. I find it hard to believe that publishers so readily lifted up their skirt for Google controlling their content... however I suppose search engine rankings are everything now.
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.
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.
This is in essence what happened with FB Instant Articles. Many publishers are hurting from it because their CPMs dropped and they didn't get people on their properties. They didn't really have a choice in the matter though. Some, like BuzzFeed have adapted their models to thrive in this new reality.
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.
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.
AMP is breaking the web, and while it offers great speed, I think the consequences of breaking and hijacking all urls greatly outweighs the advantages.
Really can't be in favor of it until those issues are fixed.
Really can't be in favor of it until those issues are fixed.
AMP offers no more or less speed than standard HTML. Even on a slow connection, the majority of that slowness is due to the last mile, not because it takes a long time to get data from Europe to Australia.
It really is only about getting yet another way to collect data on users and push ads down their throats.
It really is only about getting yet another way to collect data on users and push ads down their throats.
AMP addresses the last-mile concern by constraining the content of the page to mitigate both low-bandwidth connections and low-power rendering agents.
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.
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.
This is absolutely the fault of the publisher, not of anyone else. If the people running that site wanted to offer a slim and fast experience, they could absolutely do so without including additional Javascript from god-knows-where and whatever other “features” AMP requires.
Contrarian view: I love AMP and I find myself clicking AMP links far more often because I can get the information I want much faster. And this is on LTE.
AMP should be supported by CDNs and toggleable in the browsers though.
AMP should be supported by CDNs and toggleable in the browsers though.
The problem AMP is trying to solve is very real. Google is just trying to solve it in a way that gives them more power, rather than trying to fix the root problem.
I thought I'm the only one. It's really fast and easy to use. I don't understand all the hate here.
Site operators are mad that they can't ruin our experience as thoroughly any more.
I'm against AMP simply because it doesn't work with Safari on iOS. In fact, I switched to DuckDuckGo as a default search engine because less accurate search is still better than a list of accurate results that simply don't open.
Can you detail the issues you've had with AMP pages? I use Safari on iOS 10.2 daily and have never noticed an issue loading AMP pages.
They load fine (and FAST) for me, that's never been an issue.
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.
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.
Anyone know why they do those two things? Why not just deliver a normal web page that scrolls normally?
Apple chooses to use accelerated scroll for iframes in mobile safari for some reason. The inner iframe is needed in AMP for security reasons since the experience on google includes third party iframes as part of the rendering of the article.
Google has fixed it so the site name header finally goes away when scrolling.
Google has fixed it so the site name header finally goes away when scrolling.
> Google has fixed it so the site name header finally goes away when scrolling.
Well, that's an improvement at least.
Well, that's an improvement at least.
AMP adds an additional horizontal bar on the page, under the native address bar, clobbering valuable screen real estate on a mobile browser. Why anyone thought this was a good implementation and ready for prime time is beyond me.
They don't load. Ever. 100% of the AMP links I've tapped in Safari on 10.2 just show the AMP header with a blank page beneath it. I don't have an ad blocker installed on my phone, or anything else that should be screwing with it to the best of my knowledge.
I'm on iOS 10.2 also. Searching for something like "site:reddit.com casserole" gives a couple of AMP results. Clicking them just shows google loading circle thingy indefinitely, the page never opens.
I just did this on my iPhone, and it worked instantly. In fact I've never seen an AMP page that doesn't load...
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.
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.
I also confirm this works fine for me on Safari and iOS 10.2 (iPhone SE, not that I think it matters).
It doesn't work for me, and never has. Also on Safari and iOS 10.2.
I have the exact same issue on iPhone 7 iOS 10.2
I'm real close to doing the same. I can't believe they shipped something with such a terrible user experience on so many high profile devices.
I've been critical of AMP in some previous posts, but an AMP like infrastructure has the impressive advantage of trying out such optimizations and solutions, without a large affect on the users.
I'd still like to push for an open, standards based approach to tackling the issue of content delivery under resource constraints.
I'd still like to push for an open, standards based approach to tackling the issue of content delivery under resource constraints.
Cloudflare just launched its own AMP viewer and cache: https://blog.cloudflare.com/accelerated-mobile/
AMP is open - https://github.com/ampproject/amphtml
If I can't host it, it's not open, end of story.
With AMP, it's always by google.
This is not open, there is no source, because AMP is a hosted service.
This is not open, there is no source, because AMP is a hosted service.
[deleted]
That's what's so insidious.
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!
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!
Here's an open version of AMP in the works: https://wicg.github.io/ContentPerformancePolicy/
I tried to share an AMP article from Gizmodo with my wife the other day. I just texted her the link that I copied from my Firefox Mobile browser. She said it was broken. And sure enough, it was broken. What a pain, the url only works for me?
Edit: wording
I absolutely hate AMP. I don't understand it at all. In fact, I completely ignore the benefits – this is simply due to the UX. Any link I see with AMP in it makes me want to not tap on it on my phone. It's seriously a horrible experience on iPhone. The entire navigation is uncanny valley territory. I don't have a detailed reason why, but I know that when trying to use the browser I'm frustrated and want to leave. This feels like a poor move.
It'd be far more useful if they benchmarked rendering speed for pages (game-able, obviously, but so is everything), and just favored faster ones. AMP could be one of many systems then, instead of taking as much control as possible.
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.
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 definitely agree with the overall feeling on HN – AMP is probably one of the worst things to happen to the open web.
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.
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.
I think the root issue here is that most websites are now designed by people who don't even know HTML. ("You had one job!")
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.
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.
> From there, we get years of unoptimized, bloated websites made by people drawing pictures with HTML editors.
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.
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.
> One look at the source code for most popular sites shows this isn't true
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.
https://developers.google.com/speed/pagespeed/insights/
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.
https://developers.google.com/speed/pagespeed/insights/
> I think the root issue here is that most websites are now designed by people who don't even know HTML. ("You had one job!")
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.
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.
"We remove image data that is invisible to users, such as thumbnail and geolocation metadata. For JPEG images, we also reduce quality and color samples if they are higher than necessary."
Great. Except that that information might be deliberately a part of the image.
These things should be opt-in.
Great. Except that that information might be deliberately a part of the image.
These things should be opt-in.
I would love it if all AMP sites were opt-in. I understand the target audience and I agree that making the web a faster place is important. However, there are tradeoffs that come with AMP, and I personally have an amazingly fast and unlimited LTE connection. I don't need AMP, so all I get is the downsides with none of the positives.
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.
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.
They are. You don't have to publish an AMP version.
That's what I thought as well. If you're publishing special images and JS then don't include AMP metadata.
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.
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.
Except with Google's stranglehold on Google Search Engine results, not publishing an AMP version means you will probably rank below a similiar AMP-"enhanced" version from a competitor.
That's not really an option, unless you're trying to go after the Bing/DuckDuckGo market.
That's not really an option, unless you're trying to go after the Bing/DuckDuckGo market.
What about me as a user? I have NO WAY to control it, I just get it shoved down my throat. I don't like it and don't want it, but get no choice in the matter.
And no one is forcing you to work, don't ever whine about your salary. It's voluntary agreement.
Google own the web and people have no choice. Monopoly.
Google own the web and people have no choice. Monopoly.
> You don't have to publish an AMP version.
For now. I do have a bad feeling that Google will keep pushing towards this.
For now. I do have a bad feeling that Google will keep pushing towards this.
To everyone who's against AMP - try opening any article on an extremely slow 2G connection when you're travelling and try the same with AMP. The difference is night and day.
You may be against some principles, but it's an absolute life-saver sometimes.
You may be against some principles, but it's an absolute life-saver sometimes.
Hacker News loads very fast without AMP. Daring Fireball loads very fast without AMP. Lots of sites do. That's up to the people making the sites to fix.
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.
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.
You're not claiming the solution to the slow web is that every website should look like HN or Daring Fireball, are you?
I dislike AMP because sometimes it just fails to load, it screws with scrolling, blocks off part of the screen, and causes me extra effort when I want to share URLs.
What's really annoying is that your problem could be solved without causing all of mine.
What's really annoying is that your problem could be solved without causing all of mine.
This has absolutely nothing to do with AMP. May I remind you that slow Internet connections are not a new phenomenon. Try browsing the web on a 9600 baud modem. The means for solving this problem (content negotiation, carefully crafted pages, CSS media selectors) have existed since the dawn of the web, and AMP is a terrible solution that carries the collateral damage of obscuring the URL/source of the original resource and hijacking the presentation of the page.
Slow internet connections have existed for quite a while, indeed. But websites were smaller back then - they didn't load a 300 kB JS file just to hide a few elements.
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.
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.
Nonsense. Let it be bloated. Let people wait and pay.
They won't go back, and that would be the point.
This way, google "saves" those sites by essentially stealing content, since from now on, visitors won't even hit your site.
This way, google "saves" those sites by essentially stealing content, since from now on, visitors won't even hit your site.
Just having a cookie-based opt-out would be fine. I don't want AMP but I won't presume to know what other Internet users want.
Google is presuming to know what I want and it is irritating.
Google is presuming to know what I want and it is irritating.
The publisher can trivially create a light website which loads just as quickly as the AMP version.
I tried opening sites with AMP, and some of them didn't even load. 1000/300 AC 5ghz wifi. What is page speed when sites don't load? My guess is even on 2G that's not an added bonus..
Nobody is particularly against having a site that loads quickly. The problem is AMP is a double-edged sword and its implementation siphons traffic from sites and hurts publishers.
And don't forget: at least 99% of users will be completely unaware of AMP. They'll use it by default because lots of Google search results use AMP.
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?
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?
Me personally, I dislike AMP but would be fine with some way to copy the goddamned URL of the page I'm on. The way it currently stands, AMP sort of breaks how one intuitively expects browsers to work.
Is there a way to block AMP and load the real page instead?
yes, use https://encrypted.google.com
Or Request Desktop Site from your browser.
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'".
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'".
no
Surprised to see so many people hate AMP.
I understand why developer/publisher may hate AMP because of development effort/stealing content...
But as a reader I am inclined to click the link with the lightening bolt icon and I don't recall to see many broken page.
Google should focus on making their own shit load faster instead of digging their nails into other websites. Google Groups for example is terrible.
We used to have RSS, a standard that allowed to read articles easily and efficiently, and it died with the help of google when it killed google reader. And now they have created this new "standard" in their own garden and expect people to go and play it in exchange of better positioning.
I think I'll take the suggestion I've seen here and I'll use duckduckgo
They couldn't put AdSense on RSS feeds.
I hate AMP! Please check this thread:
https://productforums.google.com/forum/?utm_medium=email&utm...
Hilariously, when I try to visit that on mobile, it wants me to log into my Google account, with no way to not do that.
AMP was originally a more interesting project called PageSpeed that was open to anyone running webserver(s). I helped the Goog guys work on it by dint of having founded a premium adexchange company. It was great. AMP? Somewhat less great.
Actually, they're separate. PageSpeed is still here:
https://developers.google.com/speed/pagespeed/insights/
https://developers.google.com/speed/pagespeed/insights/
From what I read, majority of the focus of page bytes reduction to optimize fro mobile experiences is on lowering JPEG image quality (AMP Lite) and/or fixate it to 85% for AMP.
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.
[1]: https://www.jpegmini.com
[2]: https://kraken.io
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.
[1]: https://www.jpegmini.com
[2]: https://kraken.io
Is there a standard way to get to the original page from the AMP page? I've ended up on too many AMP pages with no way to get to the original link.
Yes, if you have the option to "Request Desktop Site" in your browser, that will redirect you to the non-mobile site. Another way that works for me is to remove the first
"https://www.google.com/amp/" from the url. This should direct you to the mobile version of the site.
To all people who are defending AMP with 2g arguments, i never have 2g, 3g is the minimum. I don't like it. Make it opt-out please :)
No one here seems to have mentioned Google's back-end wins from cached smaller, standardized code and images.
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.
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 a no javascript version for SEO.
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.
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.
[deleted]
[deleted]
Absolutely hate AMP and the inability to opt out of it.
Yep. Google Results are better but I switched to DDG because of AMP too. Crappy implementation that does not let me get the URL to share a link.
You can share the AMP link.
How does Google do this legally at all? Can I just download and redistribute any and all content I find on the net, and then present it as if it's the original?
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.
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.
What the what? I thought AMP was designed specifically to be performant and light?
What about announcing AMP Null, a way to disable this abomination?
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.