How to fight back against Google AMP as a web user and a web developer • Hacker News Board

Re: How to fight back against Google AMP as a web user and a web developer

#521

Post by saagarjha » Fri, Dec 06, 2019, 3:57 PM UTC

lern_too_spel wrote: post #520

saagarjha wrote: post #436

Earlier quoted context omitted.

If they’re just HTML pages, why would I use AMP?

Because, as you have repeatedly shown you already know, AMP pages are a constrained HTML that supports safe prerendering. Why ask a question you already know the answer to?

> AMP pages are a constrained HTML that supports safe prerendering

Then they're not HTML, are they? As other commenters have pointed out, nobody is using the constrained set of AMP as their main page, precisely because it's not "just HTML". (And specifically, Google controls which subset of HTML this is.)

Re: How to fight back against Google AMP as a web user and a web developer

#522

Post by stephenr » Fri, Dec 06, 2019, 4:13 PM UTC

shawnz wrote: post #515

nothrabannosir wrote: post #493

Earlier quoted context omitted.

AMP is an example of the bad faith exercising of that monopoly. Bad faith because we judge it by the negative press: there is considerable push back and controversy, yet it remains. That alone separates it from other factors like “actual page speed”, which is also used but which everyone agrees with, which is why it’s considered good faith. No need to judge it based on its technical merit: a significant amount of peo…

Yes it's true that they forced AMP despite some people not wanting it (and I think you are greatly overestimating the fraction of customers that actually care about this either way). But you know what they say, ask customers what they want and they'll say a faster horse. I don't think there's anything wrong or immoral about going against the current wishes of your customers to further the long term wishes of your cus…

It's cute that you think people either searching on Google, or people/organisations with organic results shown on Google are their "customers".

I mean it's also naive, and wrong, but it's cute too.

Re: How to fight back against Google AMP as a web user and a web developer

#523

Post by privateSFacct » Fri, Dec 06, 2019, 4:14 PM UTC

tobr wrote: post #358

yellowapple wrote: post #351

Earlier quoted context omitted.

> they will look how to load it with ads and tracking, which very conveniently is supported on amp, just as they do in their regular sites. Yes OP did.

No, this doesn’t say anything about sync vs async.

The parent / op literally says they will load AMP with ads and trackers "just as they do in their regular sites."

So we are very clear, regular HTML websites allow sync javascript and cross site / full dom access etc by trackers and ad platforms. Sync is preferred for a few reasons by ad providers. Lots of regular sites have sync javascript.

On AMP, total javascript size is limited, dom interactions are limited (ie, you can repaint the screen repeatedly with the flyover crap etc) and sync is prohibited and the script generally runs in a sandboxed iframe with a separate web worker.

So I'm not putting words in anyone's mouth, I quotes them exactly, and am pointing out that despite their false claim that you can run same things in AMP you do on regular site - you cannot.

People claiming that AMP is only faster because of preload, that publishers can abuse the user as much as they do with full HTML, that javascript works just as it does on their regular site are lying.

Is AMP perfect? No - folks will always be able to abuse things, but it cuts down on a bunch of common and egregious abuses.

I wonder if part of the issue is some folks here browse with ad-block or other extensions and so don't really experience the web as publishers intend it - because the differences between AMP and non AMP sites is glaring (ignoring the preload question).

Re: How to fight back against Google AMP as a web user and a web developer

#524

Post by stephenr » Fri, Dec 06, 2019, 4:15 PM UTC

lern_too_spel wrote: post #518

saagarjha wrote: post #498

Earlier quoted context omitted.

As has been mentioned before, what Apple, Facebook, and RSS aggregators are doing is quite different than what Google is: they're not purporting to be search engines.

And how is that any different? The end result is they're forcing publishers to use their format.

If you don't want Apple News formatted content, don't use the Apple News client.

The web is supposed to be an open standard.

If Google wants to go off and make Google Web a thing, where it only allows Chrome to view content hosted by some variation of *.google.com, thats their choice, but that isn't "the web".

Re: How to fight back against Google AMP as a web user and a web developer

#525

Post by neop1x » Fri, Dec 06, 2019, 4:18 PM UTC

wor3q wrote: post #490

kccqzy wrote: post #327

Earlier quoted context omitted.

> They load massively faster than normal sites, especially on poor mobile connections where main sites sometimes hang indefinitely trying to load javascript, ads, etc. Have you tried the normal mobile websites with an adblocker?

I'm from Poland, a country which has one of the highest percentages of adblocker users. Most pages adapted to it by either doing nasty tricks to bypass them, or just slapping an unclosable popup telling you to disable your adblocker...

I've seen a few such websites. Hit back button and never visited them again.

Re: How to fight back against Google AMP as a web user and a web developer

#526

Post by privateSFacct » Fri, Dec 06, 2019, 4:18 PM UTC

JohnFen wrote: post #427

privateSFacct wrote: post #324

For those interested in security - AMP basically forces the iframe javascript sandbox security model. https://www.html5rocks.com/en/tutorials/security/sandboxed-i... Even reputable web pages tend to have a metric TON of non-sandboxed javascript from third parties. If you care about your security this is a risk. If you stick with AMP - this is - by spec - prohibited. Something to think about as you browse the web gobb…

> For those interested in security - AMP basically forces the iframe javascript sandbox security model. AMP is the wrong way to address this. Using a good browser is the right way.

My parents use IE, my friends use Safari - both have high market share - are these good browsers? Should users of these browsers be forced to fight through flyover ads that autoplay audio, repainting pages that jump around like crazy, huge sets of third party javascript with total access to their page / session?

Re: How to fight back against Google AMP as a web user and a web developer

#527

Post by neop1x » Fri, Dec 06, 2019, 4:22 PM UTC

ogre_codes wrote: post #221

I'm not a fan of Google's proprietary web, but it's worth pointing out that this is largely a response to the increasingly shitty way publishers treat their users. Just reading basic articles on the web has become a painful exercise in dodging "Subscribe" faux-pop-ups; trying to scan text while your vision is bombarded with unrelated video; and user-hostile scroll capture effects. For much the same reasons Google AMP…

Why using proprietary Apple News when there are so many news aggregators and even RSS readers? Isn't it just laziness?

Re: How to fight back against Google AMP as a web user and a web developer

#528

Post by onreact » Fri, Dec 06, 2019, 4:27 PM UTC

Also make sure to sign the AMP letter: http://ampletter.org/

Re: How to fight back against Google AMP as a web user and a web developer

#529

Post by gregable » Fri, Dec 06, 2019, 5:34 PM UTC

squiggleblaz wrote: post #486

esrauch wrote: post #414

Earlier quoted context omitted.

I think that's a bit unnecessarily tin-foil-hat. If they didn't put in the 8 second css rule it would just show blank for those users right? So adding that rule is making it work at all instead which doesn't sound like "there to punish them".

Why is there an eight second delay instead of, say, an 0.8 second delay? Or no delay at all? I mean, if the goal is to make the page display only once it's fully loaded, and the point of amp is to make pages load quickly, eight seconds seems gratuitous. Even slow sites load within eight seconds. (I don't deliberately use any Google products, so I'm completely unfamiliar with amp.)

Reasonable question.

Until the javascript has loaded (a single cacheable javascript file: https://cdn.ampproject.org/v0.js ), the browser can't lay out the resources on the page (images for example).

If the browser rendered the page before layout, it would likely look pretty bad. Then when the javascript arrived, the document would layout again moving elements around. This is typically referred to as the "Flash of Unstyled Content" (https://en.wikipedia.org/wiki/Flash_of_unstyled_content) and is considered by some to be a negative user experience. Many web pages outside AMP take a similar approach to hiding the content until the layout has completed.

The 8 second CSS animation is only present as an "escape hatch" in case the javascript never loads. The specific value was chosen as a time that probably indicates the javascript will never load. Note that if javascript is disabled entirely, the page is rendered immediately via the tag. There has been a discussion around changing the 8 second time to something shorter ( https://github.com/ampproject/amphtml/issues/22543 ), though it could probably be renewed.

Re: How to fight back against Google AMP as a web user and a web developer

#530

Post by gregable » Fri, Dec 06, 2019, 5:37 PM UTC

JoshMnem wrote: post #450

gregable wrote: post #441

Earlier quoted context omitted.

The behavior you describe occurs if the useragent blocks the URL https://cdn.ampproject.org/v0.js which does not have anything to do with ads or analytics. Certainly an ad blocker can be used to block any URL, but I don't know of any that block this one by default. If there are any, let me know and I'm happy to file issues to get that fixed! If a user chooses to block this particular resource which the page needs to…

People who block JS by default but who don't want to completely turn off JavaScript encounter that 8-second delay. (I'm using "ad-blocker" loosely -- it refers to any kind of tool that blocks ads and tracking. On my computer, it's blocked at the hosts level in addition to an add-on.) Some people don't want to load resources from Google's servers, and they shouldn't be punished for it. That JS file isn't needed for AM…

Without the Javascript file, the images will not load. AMP loads images using a custom element which has performance benefits such as lazy loading of images until they are close to the visible viewport and guaranteeing a stable layout that will not cause the elements on the page to jump around. The downside is that until Javascript is loaded, these images are not available to the browser.