Live data from Hacker News

AMP pages displaying your own domain

webmasters.googleblog.com

61–70 of 340 posts

Re: AMP pages displaying your own domain

#61
post #48

Earlier quoted context omitted.

Users like pages that load instantly, which AMP is a requirement for (via preloading).

AMP pages loaded through Google search with hot cache load slower than some of the websites I've developed when loaded with cold cache. It's absurdly slow, uses tons of unnecessary JS, and it is a privacy nightmare because now I can't just use server-side GDPR and ePrivacy guideline compliant analytics anymore, but either have to give up analytics entirely, or have to use privacy-obliterating Google Analytics. And if…

> AMP pages loaded through Google search with hot cache load slower than some of the websites I've developed when loaded with cold cache.

On a mobile device in India? Nonsense. Your page load time is dominated by latency, which the AMP user doesn't see because it is preloaded from near caches.

> uses tons of unnecessary JS,

Which of the JS is unnecessary? The JS to load images allows AMP not to preload images below the fold, which is absolutely necessary for speed and for being friendly to data plans.

> now I can't just use server-side GDPR and ePrivacy guideline compliant analytics anymore

Explain. You still get first party tracking that gets fired when the user clicks to your page and can get user consent via data-consent-notification-id.

> And if a user ever loads the page with JS disabled

In that case, it's the SERP's fault for showing the AMP page instead of the non-AMP page. In the normal JavaScript-enabled scenario, the SERP would be stupid to show your non-AMP page.

Re: AMP pages displaying your own domain

#63
post #34

Earlier quoted context omitted.

Brussels sprouts are good for you. AMP is more like medical experiments performed on you during an alien abduction.

It's solely the search engine boost you get from AMP that bothers me. Because of the money involved many sites have no choice but to implement AMP and stay competitive. If it weren't for that, it would just be another technology and the fact that it only works in few circumstances would probably make many sites not bother with it. The UX downsides would probably see many sites actively avoid it. The fact that it has…

Have you noticed ranking improvements? We've done AMP on some sites and not others and we saw no difference in ranking.

Sure, having a very quickly opened page is nice, but on the other hand, features are limited. That might or might not work well, depending on what kind of content you have, what engagement you're looking for.

Re: AMP pages displaying your own domain

#64

Earlier quoted context omitted.

The browser displays the URL from the origin that digitally signed the unmodified content. A browser already doesn't show you what server delivered the content. That would be your wifi AP, cell phone tower, or ISP node. The internet has already long established that we can trust content without trusting intermediaries. There are two elements that are important: integrity and privacy. The content integrity is protecte…

Google can't tell if a link has been clicked if JavaScript is off and the `ping` attribute is removed, so AMP removes privacy there. By forcing web publishers to host their content on a Google cache, they lose their server-side logging and the ability to determine how they set up they way they serve their own sites. Also, why do you artificially slow page loads on AMP pages to 8 seconds when JavaScript is disabled? T…

The linker (google in this case) could rewrite the link to use a redirector if they choose. If Javascript is off, AMP and thus Signed Exchanges are disabled on Google search results anyway.

You misunderstand the 8 second CSS animation in the AMP boilerplate. Here's the code (simplified):

  
    body { animation:-amp-start 8s steps(1,end) 0s 1 normal both}
    @keyframes -amp-start{from{visibility:hidden}to{visibility:visible}}
  
  
    
      body{animation:none}
    
  
See the noscript section: if javascript is disabled, the CSS displays the body immediately. If Javascript is enabled, but for some reason the AMP javascript fails to load, after 8 seconds, the page is displayed anyway. The page is probably somewhat broken without the javascript loading, but the 8s is a fallback, not code to slow down non-javascript browsers.

Re: AMP pages displaying your own domain

#66
post #9

Earlier quoted context omitted.

I wonder if any webmasters are self aware that their users like amp

Users like pages that load quickly, which amp is not a requirement for. Amp is designed to tighten googles grip on the web, nothing more.

as long as google is using their grip on the web to drag crappy websites kicking and screaming into having acceptable load times, i'm okay with it.

yeah, there's a few sites out there that are faster than amp. but most of them are not, and before amp the trend was certainly not to make anything lighter or faster.

Re: AMP pages displaying your own domain

#67

Remember the talk about how the Chrome team was going to "rethink" the navbar, and what domain and site identity really mean? And people were a little worried about this? Turns out people were right to be suspicious. This is hot garbage. You can no longer ask a user "What URL does your navbar say you're at?". It is no longer a source of truth. They will actively be lied to.

there was no need to be suspicious. google wasn't being sneaky about it, they have been actively talking about, promoting, and openly developing this feature for at least a year.

Re: AMP pages displaying your own domain

#68

Semi-related, I think Web Packages and Signed Exchanges could have some usefulness outside of Google's caches. One of their spec examples was for verifiable web page archives. Another idea it could be used for a wifi "drop box" (drop station?) when there's no internet connection around. That isn't uncommon at some popular spots up river into the woods in the US. The idea is that as people enter the area, they can upd…

In general, this sounds like an interesting use case.

One thing to note is that the specification currently limits the lifetime of a signed exchange to 7 days. It's possible that by exploring some of these use cases, especially offline, the spec could be improved with respect to some of these constraints.

Re: AMP pages displaying your own domain

#69

Earlier quoted context omitted.

Google can't tell if a link has been clicked if JavaScript is off and the `ping` attribute is removed, so AMP removes privacy there. By forcing web publishers to host their content on a Google cache, they lose their server-side logging and the ability to determine how they set up they way they serve their own sites. Also, why do you artificially slow page loads on AMP pages to 8 seconds when JavaScript is disabled? T…

The linker (google in this case) could rewrite the link to use a redirector if they choose. If Javascript is off, AMP and thus Signed Exchanges are disabled on Google search results anyway. You misunderstand the 8 second CSS animation in the AMP boilerplate. Here's the code (simplified): body { animation:-amp-start 8s steps(1,end) 0s 1 normal both} @keyframes -amp-start{from{visibility:hidden}to{visibility:visible}}…

There are legitimate (privacy/speed) reasons to not load AMP's JavaScript while still not turning of JavaScript entirely. Google does have the capability to know when you're on an AMP page, because the JS loads from ampproject.org, which is registered by Google.

An 8-second delay seems like an intentional "bug" to coerce users to turn on JavaScript (and advertising).

Re: AMP pages displaying your own domain

#70
post #48

Earlier quoted context omitted.

AMP pages loaded through Google search with hot cache load slower than some of the websites I've developed when loaded with cold cache. It's absurdly slow, uses tons of unnecessary JS, and it is a privacy nightmare because now I can't just use server-side GDPR and ePrivacy guideline compliant analytics anymore, but either have to give up analytics entirely, or have to use privacy-obliterating Google Analytics. And if…

> AMP pages loaded through Google search with hot cache load slower than some of the websites I've developed when loaded with cold cache. On a mobile device in India? Nonsense. Your page load time is dominated by latency, which the AMP user doesn't see because it is preloaded from near caches. > uses tons of unnecessary JS, Which of the JS is unnecessary? The JS to load images allows AMP not to preload images below t…

> On a mobile device in India? Nonsense. Your page load time is dominated by latency, which the AMP user doesn't see because it is preloaded from near caches.

My test device is a Huawei Ideos X3 on a 56kbit/s throttled 3G connection. The same effect also applies with a Pixel 1 on the same connection, or either of the devices on a modern 3.9G LTE connection. (Tested on O2 net in Germany, works reliably better than AMP even and especially while on a train — if you've ever tried using O2 on the intercity train between Hamburg and Münster you know that every third world country has better internet than, I've seen 8kbps with 13 seconds latency there)

> Which of the JS is unnecessary? The JS to load images allows AMP not to preload images below the fold, which is absolutely necessary for speed and for being friendly to data plans.

AMP uses megabytes of JS for that purpose, I do the same in under 1kiB (even including an intersection observer polyfill). And my CSS is much much smaller as well. Part of why I get a 100/100 in all pagespeed and lighthouse tests, including when simulating mobile connections, while AMP pages get only 60/100.

> Explain. You still get first party tracking that gets fired when the user clicks to your page and can get user consent via data-consent-notification-id.

I want JS-free analytics that do not require tracking or any consent (GDPR allows collecting some information without consent, same with the yet unreleased ePrivacy directive with which AMP is not compliant anyway).

Post reply on HN