Hacker News Reader

Comment by noelsusman | Hacker News Reader

Of course AMP has other motives than simply making the web faster for mobile, but it also does make the web faster for mobile. I guarantee the AMP version of that paper's mobile website provided a significantly better user experience than the normal version. That is why AMP has been successful, and it's why I will continue to click on AMP links whenever available.

Is giving Google that much control ideal? Of course not, but from a user perspective it's a hell of a lot better than the alternative.

View on HN

> but it also does make the web faster for mobile.

AMP probably help making some previously bad-written amd bloated websites less slow, but it doesn't make them fast either.

HN is a fast website. The old reddit was a reasonably fast website. The new reddit (with AMP) is slower on my phone than the old one. It's still faster than the worst websites I browse on mobile, but it's far from being the fastest, and it's one of the slowest I actually use on my phone (simply because I usually don't browse websites that are too slow).

AMP isn't about speed.

> it also does make the web faster

this is true

> That is why AMP has been successful

This is not. If google removes ranking incentive, people will forget about AMP the next day

>> That is why AMP has been successful

>This is not. If google removes ranking incentive, people will forget about AMP the next day

Google giving ranking incentive to sites that are faster seems like the exact sort of thing they should be doing.

> Google giving ranking incentive to sites that are faster seems like the exact sort of thing they should be doing.

Yes. It should give ranking incentive based on actual speed, not AMP support.

Google already incorporates site speed into their rankings, separate from AMP.

However, if you want to get into Google's mobile carousel above the normal search results, you have to serve AMP pages and let Google cache them.

Except that it's now giving a huge boost to websites that use a specific technology to be fast; instead of just boosting all fast websites like it used to. Sites can be fast even if they don't use AMP.

Heck, sites can be faster if they don't use AMP. Sure, most sites aren't, but it's certainly doable. AMP, aside from Google caching your site on the SRP, doesn't really do anything crazy when it comes to site performance.

> Google giving ranking incentive to sites that are faster seems like the exact sort of thing they should be doing.

Really? I thought Google's purpose was to find information in the web, not to give me fast links. If I am looking for an article, I want that article, not a different but faster one. If I am looking for a piece of information, I want the best fit, not the second or third best but faster fit.

Information delivered slowly is less useful than information delivered quickly[1]. If there are 5 takes on an AP-wire article I want google to give me a fast site over a bloated slow site. The finer points of how they get to a fast site don't particularly matter to me.

[1] One of the nicer features of HN is that it is snappy and responsive - ime the polar opposite of many non-AMP news sites.

> If there are 5 takes on an AP-wire article I want google to give me a fast site over a bloated slow site.

I'd want Google to give me the accurate, well-researched site. When the difference between "fast" and "slow" is a matter of seconds (or often milliseconds), I'm not sure why better information delivered a few seconds later should be ranked lower.

Slower sites should be ranked lower for the same reason a dictionary that isn't alphabetized is less useful than one that is and both are less useful than dictionary.com. I'd rather have Webster than Oxford if Oxford will take twice as long and I'd rather not have urbandictionary.com over either -- hence a weighting.

Moreover that even if google could give me the canonical result[0] to my query its likely I will need to visit and view several sites to get the information I am searching for - information I will obtain faster when the sites are faster.

[0]Any ranking will be probabilistic and in all likelihood for common topics there will be multiple candidates within the expected error - why is it so great a sin to order them by accessibility?

> find information in the web

This has not been true for more than a decade. The primary use case of the Internet today is to connect users with service providers of all stripes, and not just information repositories.

For most of these, the quality of service is more correlated with their "speed".

But speed results in better ranking, and that's what amp provides.

No, AMP provides space on a top carousel of results.

It may also do that, sure. But you're telling me it does not provide speed improvements?

> it also does make the web faster

No, it is not. Optimized plain old webpages are faster.

If Google wants to promote faster pages then amp should not be promoted in the search results.

It is about capturing traffic, injecting tracking and ads.

Install a content blocker, and the original site sans bullshit is the best experience.

Ironically the amp page is artificially slow when blocking amp’s JS because they force an 8 second delay - via required boilerplate css - before content is visible.

Source for your second paragraph: https://news.ycombinator.com/item?id=16730905

That's out of date now, though; despite still being part of the required boilerplate CSS for AMP pages, I can't find that delay in any of the https://amp.dev/ pages (the ampbyexample.com replacement demo site).

This is really shady.

It's a little more complex than that:

If you disable all js, there is no delay. If you specifically block amp js, there is a delay. There could certainly be a shady reason for this, but the justification makes sense: one of the goals of AMP is to have, basically, a single, correct, initial paint. That's why images are statically sized and amp sticks placeholders there until the real images load. The js delay exists to allow the site to fetch the js and use it to correctly render the initial paint, even on a slow/flaky connection where the js takes a bit to fetch.

The delay is css based not js based, so why would blocking all js affect it?

If you tell the browser to disable execution of all <script> tags, it will instead evaluate the <noscript> tag which contains some additional CSS that disables the animation.

Ah, I didn't realise/remember it has a noscript block, it's been a while since I dug into the issue originally.

Sites which optimize their pages via https://www.npmjs.com/package/@ampproject/toolbox-optimizer have the initial layout performed server-side instead of by javascript, and thus the CSS Flash-of-unstyled-content protection is removed. amp.dev runs this optimization, along with lots of other sites.

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

  <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 amp-boilerplate>
      body{animation:none}
    </style>
  </noscript>

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. When the AMP Javascript loads (a single js file, one request, typically already in the users cache), the javascript displays the page immediately. The page is probably somewhat broken without the javascript loading, but the 8s is a fallback, not code to slow down non-javascript browsers.

The only two cases where the 8s is relevant are: the network connection is so bad that the javascript file fails to load within 8s and the useragent has explicitly blocked the one javascript file on the page, without blocking javascript overall.

This will hit a lot of people on the web today that have given up on a blanket block on JS (because a lot of pure text content simply fails to render without JS, yaaaaay) but do have a blanket blacklist on JS assets and whitelist requests on a need basis.

As intended. We desperately need some anticompetitive scrutiny on google.

Unfortunately... https://www.opensecrets.org/orgs/summary.php?id=d000067823

The 8-second delay is there to punish users who block JavaScript that is loaded from Google's servers (with ad-blockers) but still have JavaScript enabled.

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".

It's the other way around -- AMP pages show a blank page for 8 seconds for people with ad-blockers because of that CSS rule.

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 load, then the page still loads after 8s.

Similarly, if the site owner chooses, they can run the AMP Toolbox optimizer (https://www.npmjs.com/package/@ampproject/toolbox-optimizer) which lays out the page server-side and removes this CSS flash for most documents. Some documents can't be laid out until the viewport size is known.

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 AMP pages to load. People don't need to load JS to read text and view images. I don't think there is any reasonable argument to have any users hit an 8-second delay.

Without the Javascript file, the images will not load. AMP loads images using a custom element <amp-img> 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.

Not seeing images is better than not seeing the page at all. People who block content know that things sometimes don't load. There is no reason to block loading of the pages for 8 seconds.

You're probably not their target audience anyway (read ad money stream) so they don't really care if you have to wait on content or don't see it at all. Google et. al. just see you as a parasite on the system.

It seems like the AMP delay is there to punish people who block that JavaScript loading from Google's servers. I can't think of another reason why there would be an 8-second delay for any user of a technology that (dubiously) is supposed to be about speed.

Couldn't this be solved by the adblockers by injecting some JS to change this?

I solve it with a browser extension that redirects AMP to HTML, but that solution might not last forever.

One problem is that Google wants AMP to replace HTML. I've already seen AMP pages in the Google search results (on desktop), and at least one large website so far appears to be built entirely in AMP.[1]

Google already sends desktop users to Wikipedia's mobile site from some of their listings, so I wouldn't be surprised if Google eventually starts to send desktop users to AMP pages. Google benefits when people visit AMP sites, because Google will be able to spoof the domains and serve the content themselves, giving them increased control over publishers.

[1] independent.co.uk, but they removed the CSS that delays page loading.

there's a good reason for that because if you don't google can track you everywhere by IP, or at least have a reasonable guess that it's you or someone in your house.

The AmpProject is without question controlled by Google, so I reject your claim that it "does not have anything to do with ads or analytics".

The company is an advertising company. If 90+% of your revenue comes from one thing, that's what you are. Anything else is a gimmick.

That tech fanboys continue to ignore or refute this fact about Google just shows how much Kool aid they've consumed, I assume by skipping the drinking part and going straight to Kool Aid baths and Kool aid enemas.

Blocking third party resources on a site is not a "bug" that needs to be "fixed".

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 <noscript> 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.

Does it really make the web faster for mobile? I've had the exact opposite experience with it. It's made sites run much slower, broken things like dark themes, and make advertisements more intrusive. For example, I used to think the game guide/news site polygon was a horrible slow mess until I learned about amp, I was accessing it via google search, and once I excised the amp portion of the url the site became snappy and usable. The same exact thing happened to me two nights ago with SoundOnSound as well.

> a lot better than the alternative

There are more alternatives. IIRC the goal in 56k days was to make the page load inside 10 seconds. People managed.

It was probably 5 seconds, to maximize conversion. Thankfully, I haven't had to think about it for 10+ years.

HTTP/2, HTTP/3, 5G, faster mobile phones, will all make AMP inconsequential and unnecessary, unless your primary audience lives in rural areas or are not able to adopt such technologies.

Applications used to fit on a floppy disk. Websites used to be a few K in size. AMP might be successful (if it's even considered successful), but only for a short while. I avoid AMP links when I can, since I don't want the jank, stripped down experience of a site. If I really want a great experience on publishing sites, I just turn on Reader Mode.

And of course, it's preposterous that Google gives preferences to AMP pages on search rankings. It's just as if Amazon prioritizes its own products in its search rankings (not saying it does or doesn't).

Reply on news.ycombinator.com