Hacker News Reader

Comment by _m8fo | Hacker News Reader

I don't see the point of AMP. Why not just give certain sites a little icon/preference if they're faster than XXXms? Glad to see this letter says as much.

View on HN

Because they did that, for years, and next to nobody changed anything.

Fast websites stayed fast, and slow websites stayed slow. They also gave out tons of free "speed test" tools to make it easy for developers to test their speed, and improve it. They even made apache and nginx plugins that would auto-optimize assets as it served them! And still basically nobody used them.

Plus it's not just about "faster than XXXms". What is that time measured to? Time to text on the screen? Can they game it by lazy-loading images, then videos, then ads, then 6mb of other javascript and social networking stuff and a comment system and...?

You could try a "size limit", but then you penalize asset heavy sites (like high-resolution image sharing sites, or video sites).

So their solution was to make a very restrictive system where you are forced to do things "the right way" (for at least one definition of "right"), and to pump that up in the search results.

Plugins were made for common blogging and news platforms, and now a portion of the web loads significantly faster for many, and I think that's a win.

It's not perfect, but it's at least the first thing that I've seen google try in this area that is actually working.

Obviously there is benefit to Google as a company in that now results that are served through their AMP system are faster than those of some of their competitors, and AMP gives them a nice easy way to pull some structured information from an article for things like the carousel or other non-search offerings, but I genuinely don't believe that was the main motivator, seeing as Google has years of examples of failed attempts to "fix" this problem (though maybe I'm just not cynical enough!).

Why does anyone have to change anything? If a site decides to allocate resources towards content vs. speed is that so bad?

Google wants you to search more, visit more pages, so it can show more ads. So it needs a faster Web.

yeah. this is why i abandonded Google a couple years ago. it became clear to me that they werent trying to provide me with search results that satisfied my curiosity, everything was tailored to draw me in and keep me searching. it wont send you to a page that is rich with content, itll send you to one stub article after another.

i think its kinda hilarious how there is this fixation with load speeds amongst web devs. most people i know are far more concerned with everything other than the load time.

Uh, there definitely isn’t any fixation with load speeds amongst web devs. If there were, the web wouldn’t be a complete disaster and there wouldn’t be any need for AMP. Users care about load speeds. Web devs care about getting their sites to work when their core i7 workstations are connected to the corporate intranet, and getting paid.

But they could do the best of both worlds if they wanted. The launch of AMP was coupled with the "carousel" that appears at the top of search result pages. Only AMP pages are eligible to appear in that carousel. Why not keep the carousel, but prioritise by overall load time?

I believe they kind of do.

IIRC they treat AMP pages the same as any other in terms of ranking, but since AMP is super fast, it gets a natural boost.

(obviously AMP gets other benefits like the lightning bolt badge and inclusion in the carousel)

Is that not a contradiction in terms? Placement in the carousel means you are placed above all other search results, that's in no way being treated the same as others in terms of ranking.

Ah I misunderstood what you said.

I believe that some of the data in the carousel is pulled from the way that AMP is structured, however I'm not 100% sure.

FWIW, they did let performance factor, slightly, into ranking, but there was never a "fast" icon (one was rumored, but never shipped). An icon like that would've easily motivated folks, no need for AMP to be involved.

That being said, there are technical reasons why this hasn't happened yet. The good news is that some web standards (ex: https://wicg.github.io/feature-policy/) are being worked on that would (hopefully) allow Google to verify performance of sites without relying on AMP.

This would give Google no excuse to give AMP content special treatment, and would hopefully relegate AMP to what it should've been since day one: a framework for performance, but one that wasn't required or bolstered by any Google-colored carrots.

Feature policy won't help anyone measure site's performance unless your performance metric is "amount of features used".

Not by itself, but it does provide a portion of what is needed. Specifically:

> The developer may want to use the policy to assert a promise to a client or an embedder about the use—or lack of thereof—of certain features and APIs. For example, to enable certain types of "fast path" optimizations in the browser, or to assert a promise about conformance with some requirements set by other embedders - e.g. various social networks, search engines, and so on.

You're right that there's more to it though.

Frankly, I'm okay with slow sites staying slow. Google's initial attempt was to lead the horse to water. The horses that choose not to drink, I can choose not to, uh, ride. (If that maintains the metaphor)

The caveat comes in when no alternative exists, and when the access to some information of service on very constrained connections (such as you'd see in remote third-world regions with poor Internet access) meets some reasonable definition of vital, but I've not seen where AMP is playing a significant part in that.

>Fast websites stayed fast, and slow websites stayed slow.

Website did ridiculous things for SEO when Google was the main traffic-driver on the web. Ridiculous. If Google sufficiently penalized bloat in ranking most websites would remove the bloat. But it never was a significant enough factor.

Fuck that, it's really obvious this is another Google attempt at getting as much traffic to themselves as possible.

For example, Reddit loads extremely fast, and AMP pages are absolute shit, I don't know why they decided to use it.

And I'd rather view the website as intended (minus the ads, sorry), than in a shitty cut down version that takes 3 seconds less to load.

Didn't Google get itself into this mess by claiming years ago that slow ads don't affect ranking? And then also giving speed small weight in ranking?

Here's a post from 2012 that talks about downgrading rank for sites that have too many ads.

https://search.googleblog.com/2012/01/page-layout-algorithm-...

That link is not so much about speed as it is about low quality content. I cannot find supporting link now, but as I remember SEO sites echoed info from Google many years ago that including reasonable ads won't damage ranking even if it slows the page down somewhat.

And because google is the police of the internet, they had to do something about criminally slow webpages.

As I understand it, a round-trip request on a mobile network can be very expensive [0]. One of the ways that AMP enables sites to load instantly-upon-click is by starting those requests in the background. (Then, when the user clicks, it's just a matter of bringing the IFRAME into view - no network involved.)

Loading a traditional site can have side effects (e.g. reporting a view to an advertiser's analytics). By using the AMP validator, Google Search knows it's safe to preload and prerender an article, without triggering side-effects like analytics.

So it's more than just loading faster than some threshold; it needs to be safe to cache and prerender the content. The AMP validator is what asserts these are both safe.

(Note, I don't work on AMP and don't represent Google - this is my personal understanding.)

[0] Ilya Grigorik's time-to-glass talk https://www.youtube.com/watch?v=Il4swGfTOSM

I have a very low datacap, I don't want a website to preload anything, I'd rather have a slow load.

Preload is treated as a browser hint. Presumably, your browser knows you're on a capped network.

https://medium.com/reloading/preload-prefetch-and-priorities...

That would be preloading assets, not the preloading of entire AMP sites as the GP describes.

Best practices can reduce page load time from ~10s down to ~1s and then preloading can reduce it to maybe ~20ms. Google's "preloading or nothing" attitude and the refusal to discuss tradeoffs between market power and speed really isn't helpful.

Well, if one were to buy into the hypothesis that AMP is a way for Google to monopolize content, that would be the reason. At least in search results provided by Google's search.

AMP pre-loads content, and no third party site can do that, so it's probably impossible to be as fast as AMP.

The narrative of wanting to monopolize user traffic doesn't make much sense in light of the recent announcement around URLs.

downvoters: this is 100% true. AMP has some nice standards on how to make a fast page but at the end of the day, google's re-hosting your page in a place where it can fetch in advance while obeying the same-origin policy, and clicking a result is the moral equivalent of unsetting a "display: hidden" attribute on the page.

AMP only works today because it's re-hosted inside the origin (google.com), so much that in order to fix this in the future, they'll have to rush out a new web standard and implement it in chrome (and hope other browsers do the same:) https://amphtml.wordpress.com/2018/01/09/improving-urls-for-...

I'm not sure why you think it doesn't make much sense. Google can do things that benefit multiple parties including themselves.

I think a lot of this is in reaction to FB's Instant Articles and wanting to gain further leverage over publishers. If you can commoditize publishers' content and control the format, and you supply the users and the monetization via ads, you can make the publishers do whatever you want because the alternative is for them to lose money, which they can't afford to do.

In many ways, this is a very defensive play by Google. It also happens to provide a better user experience in some ways, which is awesome, and also helps further Google's goals of controlling ad formats and more importantly the data that is collected on publisher sites that lets them monetize their data in ways they may not be able to with AMP pages.

it's not just about speed, it's about quality as well. AMP has more restrictions than just that the site is fast: amp pages have to have all the image sizes defined and the content loaded in the initial load - no fast page loads followed by spinners or lazy-loaded content, or page blocks that jump around as loads. It's a better user experience all around, not just a faster page.

Reply on news.ycombinator.com