3 ms·

Yeah... no. That's just baseless FUD. They _are_ indeed planning to get rid of AMP cache URLs, but they'll be doing it through open W3C standards anyone can us

Yeah... no. That's just baseless FUD. They _are_ indeed planning to get rid of AMP cache URLs, but they'll be doing it through open W3C standards anyone can use, not through special-casing their own domains: https://amphtml.wordpress.com/2018/05/08/a-first-look-at-using-web-packaging-to-improve-amp-urls/ https://amphtml.wordpress.com/2018/05/08/a-first-look-at-usi...

krn 8y ago
No, this Chrome update is about hiding the "amp." subdomain from the original URL. What Google wants to achieve, is to make it impossible for the average user to tell when the entire website is being served from Google Cache.
- Ajedi32 8y ago
  Google cache links aren't served from `amp.yoursite.com`, they're served from `cdn.ampproject.org`. If you're visiting `amp.yoursite.com`, then the site _isn't_ being served from the Google cache. Also "this Chrome update is about hiding the "amp." subdomain on the original site from the viewer" is patently false since this update _doesn't_ hide `amp.`; only `m.` and `www.`.
  - krn 8y ago
    > Google cache links aren't served from `amp.yoursite.com` That's not where things are going, according to your own source from the previous comment: > Our approach uses one component of the emerging Web Packaging technologies—technologies that also support a range of other use cases. This component allows a publisher to sign an HTTP exchange (a request/response pair), which then allows a caching server to do the work of actually delivering that exchange to a browser. When the browser loads this “Signed Exchange”, it can show the original publisher’s web origin in the browser address bar because it can prove similar integrity and authenticity properties as a regular HTTPS connection. So, the content will be served from Google Cache with the original publisher's URL in the address bar. > this update _doesn't_ hide `amp.`; only `m.` and `www.` It's Google, who decides what and when it wants to add to its browser's list of "trivial subdomains". Especially, when the websites with "amp." subdomains will become common.
    - Ajedi32 8y ago
      Yes, once the Web Package Standard is finalized and implemented then AMP pages will indeed use the normal `amp.` URLs. But at that point, what would be your concern with hiding `amp.`? That's no worse than hiding `m.`; it's just another subdomain which serves a different version of the same content. Heck, sites could serve their amp pages on `m.` domains if they wanted to; the actual subdomain they decide to use is irrelevant.
      - krn 8y ago
        Seeing "amp." in the URL meant that it's not a "full version" of the site. Google wants to remove the separation for the end user, so that all publishers would serve their content through Google Cache. And that's a big concern to me, since it means, the entire web will be served from a single company's database.
        Ajedi32 8y ago
        > Seeing "amp." in the URL meant that it's not a "full version" of the site. Yes, but once again that's no different from `m.`. > And that's a big concern to me, since it means, the entire web will be served from a single company's database. Are we talking about before or after the Web Package Standard is implemented here? If before, then your concerns about the URL aren't applicable because `amp.` links aren't served from the Google cache (only `cdn.ampproject.org` links). If after, then the content isn't "served from a single company's database" anymore; it's served using a decentralized and open standard for cross-origin server push.
        krn 8y ago
        > If after, then the content isn't "served from a single company's database" anymore; it's served using a decentralized and open standard for cross-origin server push. Does this mean that Google will no longer rank higher those, who implement AMP and serve through Google Cache, than those who don't?
        8y ago
  - nintendo1889 8y ago
    Another very real problem is not being able to share the real url rather than an amp link. Is ampproject Google's website? On amp.google.com I can find the original url for sharing purposes, whereas on ampproject.org urls I can't.

krn 8y ago

No, this Chrome update is about hiding the "amp." subdomain from the original URL. What Google wants to achieve, is to make it impossible for the average user to tell when the entire website is being served from Google Cache.

Ajedi32 8y ago
Google cache links aren't served from `amp.yoursite.com`, they're served from `cdn.ampproject.org`. If you're visiting `amp.yoursite.com`, then the site _isn't_ being served from the Google cache. Also "this Chrome update is about hiding the "amp." subdomain on the original site from the viewer" is patently false since this update _doesn't_ hide `amp.`; only `m.` and `www.`.
- krn 8y ago
  > Google cache links aren't served from `amp.yoursite.com` That's not where things are going, according to your own source from the previous comment: > Our approach uses one component of the emerging Web Packaging technologies—technologies that also support a range of other use cases. This component allows a publisher to sign an HTTP exchange (a request/response pair), which then allows a caching server to do the work of actually delivering that exchange to a browser. When the browser loads this “Signed Exchange”, it can show the original publisher’s web origin in the browser address bar because it can prove similar integrity and authenticity properties as a regular HTTPS connection. So, the content will be served from Google Cache with the original publisher's URL in the address bar. > this update _doesn't_ hide `amp.`; only `m.` and `www.` It's Google, who decides what and when it wants to add to its browser's list of "trivial subdomains". Especially, when the websites with "amp." subdomains will become common.
  - Ajedi32 8y ago
    Yes, once the Web Package Standard is finalized and implemented then AMP pages will indeed use the normal `amp.` URLs. But at that point, what would be your concern with hiding `amp.`? That's no worse than hiding `m.`; it's just another subdomain which serves a different version of the same content. Heck, sites could serve their amp pages on `m.` domains if they wanted to; the actual subdomain they decide to use is irrelevant.
    - krn 8y ago
      Seeing "amp." in the URL meant that it's not a "full version" of the site. Google wants to remove the separation for the end user, so that all publishers would serve their content through Google Cache. And that's a big concern to me, since it means, the entire web will be served from a single company's database.
      - Ajedi32 8y ago
        > Seeing "amp." in the URL meant that it's not a "full version" of the site. Yes, but once again that's no different from `m.`. > And that's a big concern to me, since it means, the entire web will be served from a single company's database. Are we talking about before or after the Web Package Standard is implemented here? If before, then your concerns about the URL aren't applicable because `amp.` links aren't served from the Google cache (only `cdn.ampproject.org` links). If after, then the content isn't "served from a single company's database" anymore; it's served using a decentralized and open standard for cross-origin server push.
        krn 8y ago
        > If after, then the content isn't "served from a single company's database" anymore; it's served using a decentralized and open standard for cross-origin server push. Does this mean that Google will no longer rank higher those, who implement AMP and serve through Google Cache, than those who don't?
        8y ago
- nintendo1889 8y ago
  Another very real problem is not being able to share the real url rather than an amp link. Is ampproject Google's website? On amp.google.com I can find the original url for sharing purposes, whereas on ampproject.org urls I can't.