Standardizing lessons learned from AMP
amphtml.wordpress.com
Standardizing lessons learned from AMP
1–10 of 95 posts
Re: Standardizing lessons learned from AMP
#2”we now feel ready to take the next step and work to support more instant-loading content not based on AMP technology in areas of Google Search designed for this, like the Top Stories carousel”
Seems encouraging. Any step away from a walled garden is good.
Re: Standardizing lessons learned from AMP
#3From the point of view of a user concerned with Google's influence, this seems like a good move.
From the point of view of a SRE who would have to help configure a server side implementation of web packaging, having yet another http request/response type to build and maintain seems like a bloody nightmare. And OCSP with the signature when Chrome themselves have disabled its use? It also requires custom behavior from the client, all-but-guaranteeing it won't be broadly honored.
And ultimately, I'm confused about how this replaces, or supplements AMP.
Re: Standardizing lessons learned from AMP
#4From the point of view of a user concerned with Google's influence, this seems like a good move. From the point of view of a SRE who would have to help configure a server side implementation of web packaging, having yet another http request/response type to build and maintain seems like a bloody nightmare. And OCSP with the signature when Chrome themselves have disabled its use? It also requires custom behavior from…
I don't believe it's intended to really replace AMP. It sounds like Google is establishing a set of performance guidelines (as many have been encouraging them to do). If you want to meet those guidelines, one way is to use AMP which I expect they'll continue to maintain and build on. If you don't like AMP for whatever reason, you can use whatever solution you want to meet the same guidelines.
Re: Standardizing lessons learned from AMP
#5I'm wondering what happens if web packaging really takes off. Could mirror sites basically do what ipfs does, but without inventing a new protocol? Or do Cloudflare and other content networks already do everything website owners want?
Re: Standardizing lessons learned from AMP
#6A lot if big words disguised as good intentions.
There’s nothing fast, instant, or open about AMP.
The latest article debunking those myths: https://ferdychristant.com/amp-the-missing-controversy-3b424...
Google’s fully opaque process around AMP for email (yes, it’s a thing): https://github.com/ampproject/amphtml/issues/13597 and https://github.com/ampproject/amphtml/issues/13600
Re: Standardizing lessons learned from AMP
#7From the point of view of a user concerned with Google's influence, this seems like a good move. From the point of view of a SRE who would have to help configure a server side implementation of web packaging, having yet another http request/response type to build and maintain seems like a bloody nightmare. And OCSP with the signature when Chrome themselves have disabled its use? It also requires custom behavior from…
> And OCSP with the signature when Chrome themselves have disabled its use?
It's not the first (or probably last) time that Big G's said "Do as we say, not as we do."
Heck, the blog post is hosted on WordPress instead of Google's own Blogger.
Re: Standardizing lessons learned from AMP
#8A lot if big words disguised as good intentions. There’s nothing fast, instant, or open about AMP. The latest article debunking those myths: https://ferdychristant.com/amp-the-missing-controversy-3b424... Google’s fully opaque process around AMP for email (yes, it’s a thing): https://github.com/ampproject/amphtml/issues/13597 and https://github.com/ampproject/amphtml/issues/13600
The fact that Malte is still trying to call the AMP project "well-lit" is really what throws a lot of question on this blog post. AMP is not a "well-lit" project.
Why not hand AMP itself over to standards groups as well as all of the other things mentioned here? What about the proprietary GMail implementation of AMP4Email? Or the fact that none of the justifications for AMP given in this (or The Verge interview[0]) hold up as reasons for AMP4Email.
[0] https://www.theverge.com/2018/3/8/17095078/google-amp-accele...
Re: Standardizing lessons learned from AMP
#9From the point of view of a user concerned with Google's influence, this seems like a good move. From the point of view of a SRE who would have to help configure a server side implementation of web packaging, having yet another http request/response type to build and maintain seems like a bloody nightmare. And OCSP with the signature when Chrome themselves have disabled its use? It also requires custom behavior from…
I don't believe it's intended to really replace AMP. It sounds like Google is establishing a set of performance guidelines (as many have been encouraging them to do). If you want to meet those guidelines, one way is to use AMP which I expect they'll continue to maintain and build on. If you don't like AMP for whatever reason, you can use whatever solution you want to meet the same guidelines.
Google has had performance guidelines for seveal years now: https://developers.google.com/speed/
Funnily enough, Google’s own AMP fails those guidelines when not preloaded and pre-rendered from Google’s own CDN: https://ferdychristant.com/amp-the-missing-controversy-3b424...
Google will continue doing what it does: caching and preloading whatever content it prefers (select publishers, select advertisers) and penalize everyone else even if they follow all of Google’s guidelines to a T.
Web Packages, no matter how well you disguise them as a web standard, will not solve that.
Re: Standardizing lessons learned from AMP
#10A lot if big words disguised as good intentions. There’s nothing fast, instant, or open about AMP. The latest article debunking those myths: https://ferdychristant.com/amp-the-missing-controversy-3b424... Google’s fully opaque process around AMP for email (yes, it’s a thing): https://github.com/ampproject/amphtml/issues/13597 and https://github.com/ampproject/amphtml/issues/13600
Hello, Google’s AMP team. I see you’ve been busy downvoting my comment ;)
Too bad you spend most of your time running away from uncomfortable questions and defending your overlord’s increasingly dubious and morally questionable practices.