Hacker News Reader

Comment by lightswitch05 | Hacker News Reader

I block AMP and its related domains in my aggressive blocking hosts list[1]. I've found many AMP related sites are purely for marketing, or 'news' articles that are thinly veiled ads. I haven't missed it at all. I also don't use Google, so perhaps that it part of it, but I applaud your decision to remove AMP. The web isn't meant to be centralized in this way.

[1] https://github.com/lightswitch05/hosts/blob/master/tracking-...

View on HN

I block AMP pages too. Unfortunately, Google artificially slows down AMP pages so that they literally take 8 seconds to load if you block the AMP JavaScript. (Check the inline CSS.)

Are you sure that isn't just a timeout function in case AMP fails to load?

edit: Dug up the code.

    <style>
        body {animation:-amp-start 8s steps(1,end) 0s 1 normal both}
        @keyframes -amp-start{from{visibility:hidden} to{visibility:visible}}
    </style>
    <noscript>
        <style>
            body {animation:none}
        </style>
    </noscript>

The timeout function is turned off if JS isn't available, so JS being disabled shouldn't be a problem.

I'm guessing this is actually to delay page paint so it doesn't display when half-loaded.

If they don't allow you to fix this fallback, it's a punishment

In fairness, blocking the external half of the code while not blocking the inline part of the code is on you. You could just as easily block/disable the <style> tag that adds this in addition to the AMP JS.

Blocking inline CSS is more difficult than blocking external resources.

parent said

> block the AMP JavaScript

not,

> JS being disabled

Then the noscript tag wouldn't fire here. But that's just shooting yourself in the foot. A page won't function with half its code running.

The JavaScript should create the fade style, then it will only happen if js is running.

I'm pretty sure the JS actually stops the fade. The inline CSS will be executed very early on in the page, before any assets are loaded.

Though it seems to me if the page is fast enough anyway (as amp pages claim to be), then this trick shouldn't be necessary anyway.

I think you might have missed the point of my comment. If you block AMP scripts, you will definitely encounter broken sites. The point I was trying to make are that those broken sites are mostly junk anyways. Overloaded with ads, tracking, and other manipulative content geared at turning me into the product. I haven't missed those sites any. However, I recognize that I'm not the average user, which is why these blocks are in my aggressive list. I initially put the blocks into my regular block list which is then consumed by Steven Black's hosts [1]. Very quickly a ticket was opened to whitelist AMP [2]. Funny enough, the user requesting that AMP be white listed posted screen shots of broken advertisements disguised as 'news' articles. To make everyone happy I moved it to my aggressive list which isn't included in Steven's project.

Anyways, long story short, I don't like AMP and don't mind the occasional broken site. But it's definitely not for everyone.

[1] https://github.com/StevenBlack/hosts

[2] https://github.com/StevenBlack/hosts/issues/657

AMP is shooting users in the foot. They are content-based pages with no reason for making users wait for 8 seconds if JS isn't loaded. See also:

https://developer.mozilla.org/en-US/docs/Glossary/Graceful_d...

>They are content-based pages with no reason for making users wait for 8 seconds if JS isn't loaded.

I think you should read my parent comment a little bit closer.

@SquareWheel - there is no reply link on your comment, so I'm replying here. I read your comment and I understand it.

There is no reason to load any JavaScript on a page that only contains some text and images. If the goal is to speed up loading, then blocking unnecessary JS shouldn't break the page. It's clear that page speed is not Google's primary goal with AMP.

Clicking the permalink often brings up reply for lower nested comments.

>There is no reason to load any JavaScript on a page that only contains some text and images.

While I've not read through all of Amp's JS to know what it's for, I will say I've used JS to specifically speed up static pages before.

One example is the Filament Group's loadCSS script[0]. This allows for cross-platform asynchronous CSS loading.

Font loading is also another tricky subject. Linking non-blocking font assets while minimizing FOIT and FOUT is still not a solved problem. Smashing Magazine just had a 50 minute video presentation[1] on this problem. JS loaders are a common approach.

So I disagree with you that page speed is not the primary goal here, simply because I've run into these same kinds of problems myself and can relate. Google also has the advantage that their JS will almost always be cached by end-users.

[0] https://github.com/filamentgroup/loadCSS

[1] https://www.smashingmagazine.com/2018/07/smashingconf-videos...

> So I disagree with you that page speed is not the primary goal here

I think you're missing the bigger picture behind it. Google is making a power grab to appify the WWW on their own domain, and they are coercing publishers to implement it by giving lower search engine rankings to sites that don't go along with the scheme. It's an abuse of their position. It goes against the fundamental nature of the WWW and the basic ideas of decentralized technology.

Sorry, but that's a Gish Gallop argument. It's completely unrelated to what we've been discussing, and frankly those points have been argued over so many times already I see no benefit in repeating the exercise.

With adblock, most pages are missing most of their JavaScript.

Not sure why you are being down voted. You aren't wrong.

Please read the site guidelines, which ask you not to post comments about voting on comments.

https://news.ycombinator.com/newsguidelines.html

Reply on news.ycombinator.com