4 ms·

Google already has your IP; it's their page. Preloading resources from it's own CDN doesn't tell them anything they don't already know. Preloading resources fro

by ddmd1 9y ago

Google already has your IP; it's their page. Preloading resources from it's own CDN doesn't tell them anything they don't already know. Preloading resources from someone else's domain would.

ocdtrekkie 9y ago
They could CDN people's non-AMP static content for this purpose though. It's not like their search engine isn't caching a lot of it already anyways.
- ddmd1 9y ago
  That's true. I don't see any reason why they couldn't cache non-amp content with a combination of checking for speed benchmarks and schema markup. When you think about it that way, it seems like they are more concerned with controlling the user experience than they are with speed improvements.
- jsnell 9y ago
  Just how do you imagine they'd "CDN people's non-AMP content"? There's no mechanism by which they could tell the browser to load nytimes.com but to replace the URLs of random resources with different ones. They'd need to host the actual page on Google.com. And after solving all the problems that doing this introduces, you've pretty much got AMP already.
  - ocdtrekkie 9y ago
    The same way they're trying to fix this problem with AMP: https://github.com/WICG/webpackage https://github.com/WICG/webpackage (see also: https://amphtml.wordpress.com/2018/01/09/improving-urls-for-amp-pages/ https://amphtml.wordpress.com/2018/01/09/improving-urls-for-...) Even if you can't package up and ship all of your traditional site to Google's CDN, you could do most of the burdensome/heavy bits. But then Google doesn't get to control your website and define the way it's allowed to look, which is what AMP is really for.
    - jsnell 9y ago
      So it was not possible when AMP launched, is not possible now, and might or might not be possible sometime in the future after some specs are finished, but only in some browsers. Doesn't sound very practical, to be honest... I also can't imagine the amount of shit Google would have taken if they'd started just randomly doing that kind of thing for existing web pages. Instead they introduced a totally new mechanism (i.e. AMP) where the caching was a core concept from the start. > Even if you can't package up and ship all of your traditional site to Google's CDN, you could do most of the burdensome/heavy bits. But then Google doesn't get to control your website and define the way it's allowed to look, which is what AMP is really for. But "heavy/burdensome bits" are exactly the things that matter the least for this use case. Ideally they would not exist at all. If they do, they should not be speculatively prefetched. It'd also mean that these pages are now tied to Google's CDN, no matter what. Have a user click through the link from some other source than a Google search result? They'll still end up loading the resources from them. Is that really what you want?
JoshMnem 9y ago
Google doesn't have a list of everything you do online unless you're loading resources from their servers after you leave their site. AMP always loads from Google. If you block those 3rd party scripts, AMP pages literally take 8 seconds to load.
- gorhill 9y ago
  > If you block those 3rd party scripts, AMP pages literally take 8 seconds to load. The pages load fast, they are just styled to not be visible until after 8 seconds. For example, using the site used in the article, you can block 3rd-party scripts and bypass the AMP CSS using the following cosmetic filter in uBlock: scientias.nl##body:style(animation: none !important;) With an extension such as uMatrix or NoScript, blocking first-party scripts will cause `noscript` tags to be rendered, and one of these tags disable the CSS animation, causing the page to appear immediately. When I found out about this, I tried to find the reasons for this artificial "delay" in the AMP documentation: I can't find any valid reasons for the artificial delay. The net result unfortunately is that most users wanting to block `ampproject.org` out of privacy concerns are going to feel the need to whitelist `ampproject.org` to "un-break" a site making use of it.

by ddmd1 9y ago

Google already has your IP; it's their page. Preloading resources from it's own CDN doesn't tell them anything they don't already know. Preloading resources from someone else's domain would.

ocdtrekkie 9y ago

They could CDN people's non-AMP static content for this purpose though. It's not like their search engine isn't caching a lot of it already anyways.

ddmd1 9y ago
That's true. I don't see any reason why they couldn't cache non-amp content with a combination of checking for speed benchmarks and schema markup. When you think about it that way, it seems like they are more concerned with controlling the user experience than they are with speed improvements.
jsnell 9y ago
Just how do you imagine they'd "CDN people's non-AMP content"? There's no mechanism by which they could tell the browser to load nytimes.com but to replace the URLs of random resources with different ones. They'd need to host the actual page on Google.com. And after solving all the problems that doing this introduces, you've pretty much got AMP already.
- ocdtrekkie 9y ago
  The same way they're trying to fix this problem with AMP: https://github.com/WICG/webpackage https://github.com/WICG/webpackage (see also: https://amphtml.wordpress.com/2018/01/09/improving-urls-for-amp-pages/ https://amphtml.wordpress.com/2018/01/09/improving-urls-for-...) Even if you can't package up and ship all of your traditional site to Google's CDN, you could do most of the burdensome/heavy bits. But then Google doesn't get to control your website and define the way it's allowed to look, which is what AMP is really for.
  - jsnell 9y ago
    So it was not possible when AMP launched, is not possible now, and might or might not be possible sometime in the future after some specs are finished, but only in some browsers. Doesn't sound very practical, to be honest... I also can't imagine the amount of shit Google would have taken if they'd started just randomly doing that kind of thing for existing web pages. Instead they introduced a totally new mechanism (i.e. AMP) where the caching was a core concept from the start. > Even if you can't package up and ship all of your traditional site to Google's CDN, you could do most of the burdensome/heavy bits. But then Google doesn't get to control your website and define the way it's allowed to look, which is what AMP is really for. But "heavy/burdensome bits" are exactly the things that matter the least for this use case. Ideally they would not exist at all. If they do, they should not be speculatively prefetched. It'd also mean that these pages are now tied to Google's CDN, no matter what. Have a user click through the link from some other source than a Google search result? They'll still end up loading the resources from them. Is that really what you want?

JoshMnem 9y ago

Google doesn't have a list of everything you do online unless you're loading resources from their servers after you leave their site. AMP always loads from Google. If you block those 3rd party scripts, AMP pages literally take 8 seconds to load.

gorhill 9y ago
> If you block those 3rd party scripts, AMP pages literally take 8 seconds to load. The pages load fast, they are just styled to not be visible until after 8 seconds. For example, using the site used in the article, you can block 3rd-party scripts and bypass the AMP CSS using the following cosmetic filter in uBlock: scientias.nl##body:style(animation: none !important;) With an extension such as uMatrix or NoScript, blocking first-party scripts will cause `noscript` tags to be rendered, and one of these tags disable the CSS animation, causing the page to appear immediately. When I found out about this, I tried to find the reasons for this artificial "delay" in the AMP documentation: I can't find any valid reasons for the artificial delay. The net result unfortunately is that most users wanting to block `ampproject.org` out of privacy concerns are going to feel the need to whitelist `ampproject.org` to "un-break" a site making use of it.