4 ms·

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 t

by 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?
        Ajedi32 8y ago
        Yes. https://amphtml.wordpress.com/2018/03/08/standardizing-lessons-learned-from-amp/ https://amphtml.wordpress.com/2018/03/08/standardizing-lesso... > Based on what we learned from AMP, 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. This content will need to follow a set of future web standards and meet a set of objective performance and user experience criteria to be eligible. Furthermore, once the Web Package Standard is finalized, the "Google Cache" won't exist anymore, at least not in the same way it does now. The Web Package Standard allows any web page which supports origin signed responses to be served via cross-origin server push from any server that supports HTTP/2. So Google will probably still cache and push pages via their own infrastructure when you visit those pages from your Google search results, but the actual content being served will be fully controlled by the original publisher and behave exactly as if your browser received the page directly from the publisher's server.
- 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.

by krn 8y ago

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?
        Ajedi32 8y ago
        Yes. https://amphtml.wordpress.com/2018/03/08/standardizing-lessons-learned-from-amp/ https://amphtml.wordpress.com/2018/03/08/standardizing-lesso... > Based on what we learned from AMP, 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. This content will need to follow a set of future web standards and meet a set of objective performance and user experience criteria to be eligible. Furthermore, once the Web Package Standard is finalized, the "Google Cache" won't exist anymore, at least not in the same way it does now. The Web Package Standard allows any web page which supports origin signed responses to be served via cross-origin server push from any server that supports HTTP/2. So Google will probably still cache and push pages via their own infrastructure when you visit those pages from your Google search results, but the actual content being served will be fully controlled by the original publisher and behave exactly as if your browser received the page directly from the publisher's server.
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.