So AMP is not even faster than other mobile pages without the google CDN? A pity so many prefer something like AMP to generally stripping down their sites. Get rid of JS unless absolutely necessary, compress/remove images, remove all this ad and bloat, and your page, whatever category it fits in, will load blazyingly fast. What happened to good old sole HTML and CSS, served statically or server-generated for lightning speed?
Google AMP is bad for e-commerce
71–80 of 159 posts
Re: Google AMP is bad for e-commerce
#72Breaking down a few of the concerns in this article:
> With AMP [chat applications] cannot be used
True currently. There are no chat application amp extensions, yet. This could change in the future. Vendors interested in implementing one for AMP should get involved at http://github.com/ampproject/amphtml
> AMP does not have any markup specific to checkouts
Most web pages move from shopping cart to payment by changing URLs. This would work just fine with an AMP page. There is in fact at least one vendor who has integrated payments with AMP already: https://www.ampproject.org/docs/reference/components/amp-acc...
Also take a look at https://ampbyexample.com/advanced/payments_in_amp/
> AMP does not allow for use of forms
See https://www.ampproject.org/docs/reference/components/amp-for...
> They really do not support a logged in state, or user preferences. Things like recommended products, or recently viewed products will not work with an AMP page. None of the personalization aspects like “Hi, Lesley” are done with AMP.
See the (perhaps poorly named) https://www.ampproject.org/docs/reference/components/amp-lis... This supports loading content specific to the user, even on a cached amp document.
> if search and filtering are a large part of your site’s mobile navigation, AMP will be useless.
This is exactly what amp-bind was built for: https://ampbyexample.com/components/amp-bind/
> Google Analytics is not supported on AMP
Google Analytics is fully supported in AMP. Here's the Google Analytics support page: https://developers.google.com/analytics/devguides/collection...
> If you use a different suite of tracking such as Piwik or kissmetrics, they will not work with AMP.
There is a large list of analytics vendors that have direct support here: https://www.ampproject.org/docs/guides/analytics/analytics-v...
Other vendors can be added with a small amount of configuration. Here's a guide for Piwik, for example: https://www.elftronix.com/guide-to-using-piwik-analytics-wit...
Alternatively, vendors can submit a configuration to the AMP project which is just a few lines of JSON, then the vendor will be supported more directly.
> Ad Revenue is Decreased
The link is to a single article from a year ago. There are many studies pointing to the opposite effect as well.
> A/B testing is not supported
See https://www.ampproject.org/docs/reference/components/amp-exp...
> Performance
I'm not sure what URLs the author used, but I tried to find a similar overstock recliner page that might be the right one. I found:
https://www.overstock.com/Home-Garden/Recliners/Leather,/mat...
The author tries to use a google.com/amp URL, but these redirect when not coming from a search click. Much easier is to take the CDN amp URL, which is served the same way:
https://cdn.ampproject.org/c/s/www.overstock.com/Home-Garden...
I loaded both of these in Chrome, simulated a mobile device, network tab, and throttling with Fast 3G. Here were my results:
* non-AMP: 42 requests, 1.1 MB transferred, Finish: 10.3s, DomContentLoad: 3.38s, Load: 9.52s
* AMP: 35 requests, 408 KB transferred, Finish 5.87s, DomContentLoaded 1.28s, Load: 5.88s
The AMP page is 60% smaller and hits the load event in 40% less time. However "loaded" is a funny term in the world of javascript driven websites and needs to be looked at more carefully.
I suspect that the author's referenced tool is reporting "fully loaded time" as the time that the last network event ended. AMP pages intentionally delay loading images below the fold to prioritize visible content. This results in some images loading later without impacting the user experience. For example, as I scrolled in the AMP page, the "Finish" time would move ahead to a new time as new images were loaded. With events like analytics triggers, looking at the time the last network event finished is typically a misleading metric and won't work correctly with most amp documents.
If you load filmstrips in Chrome's Performance Tab, you can see this more clearly. Filmstrips display what the page looked like at snapshots in time after loading starts. For my quick test with network throttling, the non-AMP page takes a little over 6s to finish reaching it's final state and the AMP page takes about 2.2s. So AMP here is nearly 3x faster as the user would perceive it on similar connection speed.
Re: Google AMP is bad for e-commerce
#73The author seems to completely misunderstand the point of AMP. It was never designed or created for dynamic, interactive content, especially e-commerce. This is like complaining that a hammer is bad for driving screws.
Doesn't eBay use AMP? The issue is how you use it. I believe eBay uses it for the entry product page, and then any subsequent hit goes to the website itself.
Re: Google AMP is bad for e-commerce
#74So AMP is not even faster than other mobile pages without the google CDN? A pity so many prefer something like AMP to generally stripping down their sites. Get rid of JS unless absolutely necessary, compress/remove images, remove all this ad and bloat, and your page, whatever category it fits in, will load blazyingly fast. What happened to good old sole HTML and CSS, served statically or server-generated for lightnin…
It's not only not faster but it's often slower — AMP puts 100KB of render-blocking JavaScript into the critical path. If you can render a page with less than that, you're likely to beat it, which I see regularly on iOS.
Re: Google AMP is bad for e-commerce
#75Earlier quoted context omitted.
Regardless of profit, if Google just made the AMP spec and didn't incentivize publishers to use it, well, no one would use it.
Not saying that's true, but if it is, wouldn't that mean AMP is not a desired product? I fully support a "faster page spec" that search engines incentivize, just like I support a ranking boost for using HTTPS. But AMP isn't that; AMP is incentivizing the payment of tribute data to Google under the veneer of a faster page spec, to steer the rhetoric more favorably for the company.
I want it as a consumer.
If AMP went away tomorrow I would just browsing on my phone. Ad blockers are not good enough, and I refuse to fight popups and scroll blockers and blah blah blah in 2017.
Re: Google AMP is bad for e-commerce
#76AMP is fine. AMP Cache is embrace, extended and break the web in fairly fundamental ways.
Cloudflare provides AMP cache. If you don't want to use Google CDN.
Cloudflare's AMP cache is even worse. If someone goes to a website behind/rehosted on Cloudflares AMP that has a link from that site to a third party site (say, yours or mine) that third party site will be spidered and also rehosted on Cloudflare AMP.
Then when someone goes to the intentionally Cloudflare AMP site and clicks through to your site your actual domain never gets the hit. Instead all traffic remains within Cloudflare and you never see it.
Additionally, after 2 months of trying to contact anyone at Cloudflare about this exact situation happening with the most popular page on my domain (saw the cloudflare AMP bot in the logs) I still can't get a real person. Their support is attrocious.
Re: Google AMP is bad for e-commerce
#77Earlier quoted context omitted.
Regardless of profit, if Google just made the AMP spec and didn't incentivize publishers to use it, well, no one would use it.
Not saying that's true, but if it is, wouldn't that mean AMP is not a desired product? I fully support a "faster page spec" that search engines incentivize, just like I support a ranking boost for using HTTPS. But AMP isn't that; AMP is incentivizing the payment of tribute data to Google under the veneer of a faster page spec, to steer the rhetoric more favorably for the company.
It's desired by the (non-paying) users, but not necessarily by web publishers. Here the desires of said users and Google align: they both want to see a search result quickly.
Re: Google AMP is bad for e-commerce
#78Earlier quoted context omitted.
As the otherwise pretty wrong article correctly states: There is no such ranking boost.
Not even for Google News purposes? That's 90% of the AMP links I see.
Was talking about Google Search. Don't know about News. But the original article was about e-commerce.
Re: Google AMP is bad for e-commerce
#79Earlier quoted context omitted.
As the otherwise pretty wrong article correctly states: There is no such ranking boost.
There is no AMP carousel at the top of the page? Are you sure? This is the ranking boost mentioned: http://i.imgur.com/KsSmYH8.png "Top stories" relevant to the search are shown, even if they’d otherwise be on page 10 or worse of the actual search. Any AMP page can end up there, but only AMP pages. This is a ranking boost.
The carousel ranks in position one if it is determined to be the best result. It can rank way below. https://www.google.com/search?q=facebook is a good way to see that.
Original article was about e-commerce. The Top Stories carousel is not relevant to e-commerce since it only contains news articles.
Re: Google AMP is bad for e-commerce
#80Earlier quoted context omitted.
Personally I don't think the idea behind AMP is bad. But the implementation is dangerous as it artificially fragments the web. I guess fewer would oppose AMP if google made some machine verifiable guidelines for "light" webpages that would earn them this "icon". Linked from the "fat" page by some "link" meta tag.
>if google made some machine verifiable guidelines for "light" webpages that would earn them this "icon". Linked from the "fat" page by some "link" meta tag. That is exactly what AMP is; with the exception (a huge one, I know) that Google also then caches the page on their server and serves it from a google.com host.
So, that's not what AMP is. There's a reason google don't drop the incredibly unpopular hijacking of content, and it's not to do with edge caching, but control.