Hacker News Reader

Comment by dmethvin | Hacker News Reader

AMP is just a set of conventions and limitations that, when followed, make for a fast site. Anyone can make a fast site if they follow similar rules. Most sites don't do that because either the developers want to use something that's "nicer" to code but a lot bigger, or because the marketing department insists on loading 12 different tracking and analytics progams--when they probably only use one or two.

View on HN

AMP is google flexing its control over the web.

If Google wanted to highlight fast/penalise slow sites, they could simply measure the load time of a site when they index it.

But that would only achieve their stated goals, it wouldn’t achieve their actual goals.

It feels like AMP is Google nailing its own coffin to me. It probably felt like a winning move when Bell and AT&T made people buy their own products to use telephone systems, but it led directly to their disruption by the DOJ. Even though some poeple at Google probably realize that, it won’t matter if they cash out beforehand, if working on a project gets them promoted, and if institutional inertia is in control.

Google is hurtling toward an antitrust case they won’t win, and it will really be all their fault.

They could also just have mandated serving AMP with some random HTTP header and the client would cached a whitelist of the AMP scripts if got that header, nothing in the AMP design needs to have an AMP server, it's an arbitrary limitation from Google to control the web.

Throwaway Google search engineer here. People here really do care about making the web faster and moving metrics, both because that is how the company is set up to reward employees but also because they believe it makes the product better. Google has been penalizing slow sites forever. It stopped moving the needle (I suspect because it isn’t marketable). Amp on the other hand really is working, metrics show a faster, smoother experience, and user studies have been positive. That’s why Google is doubling down so much with it. Not because they have goals to control content providers or wall off the web, but because it makes a dramatic difference on the whole.

So if the "only" goal of AMP is to make things faster, why isn't the carousel based purely on "your result must load in < X ms"? If a company can "force" other companies to adopt AMP, it can surely "force" them to improve load times on their own.

Also, if speed is their goal, why does the mandatory AMP 'boilerplate' include a CSS-driven 8 second delay before content is shown, that is removed if the client loads the AMP JS?

Oh right. I know the answer. It's to give the impression that blocking third-party resources (such as AMP JS) via e.g. a content blocker, won't make the site faster. Which as we know, is a load of shit.

You might have the best of intentions and donate your entire salary to homeless blind children - that doesn't mean for a second that I believe google's actual goals with AMP are anything less than exerting more control over the web for their own purposes.

> "they believe it makes the product better."

You should stop and do some serious research on why people don't like AMP. You're talking about the Web like it's a Google "product." You're hijacking the Web in a way that will eventually destroy it.

Publishers don't want their content restricted and hosted on Google's servers on Google's domain, but they are getting their arms twisted by reduced rankings if they don't implement it. They also don't fully understand the long term implications of what they are doing.

No, they couldn't. That is browser and transport-dependent. There are some things even Google cannot do ....

I didn't say, "they could guarantee the time it takes to load for every user on every connection on every browser".

I said "they could simply measure the load time of a site when they index it." Their indexer, running from their servers could be their "reference point" for this content.

Sure, but one of those conventions and limitations is that the page is hosted by google. It's not something you can deploy on your own server. It's not as if it's just some list of recommendations that make sites faster - you're signing up to a Google service, and you're at their mercy from then on.

>It's not something you can deploy on your own server.

But you can. Often it doesn't matter because you aren't a globally distributed cache, but if you are cloudflare[1] (or apparently Microsoft[2]), you can and do.

[1]: https://amp.cloudflare.com/

[2]: https://github.com/ampproject/amphtml/blob/master/caches.jso...

(author here)

It's not just conventions and limitations.

For example, you can't use an img tag on an AMP page. That's invalid AMP. You have to use an amp-img tag, which is rendered client side with js.

Another example is with forms. It forces you to include the amp-form js.

If it were just best practise, I'd be far happier to go along with it. Kind of the point here is that we were already using best practise, because the site was super fast.

Images rendered client side WITH JAVASCRIPT???? If my employee did AMP site for our company he'd immediately lose his job, no questions asked.

This allows AMP to skip preloading images below the fold on viewports of arbitrary size. If you fired somebody for doing something you don't understand without asking for an explanation, that's your problem.

Agree, I prefer to open amp site because most of time it simply load faster.

I prefer to just use a content blocker to prevent the crap that slows down most sites from loading.

Fun fact, blocking the amp JS makes amp pages artificially slow because they hide everything in css by default.

AMP as a solution to slow websites is like a chainsaw as a solution to an itchy foot.

How is it working at Google? AMP breaks sites and makes it look like they're hosted elsewhere.

It makes sites take multiple minutes to display after they redirect to the original version.

Did you read the article (or even the headline)? Specifically the part about the site being faster before AMP?

Impossible. For a site loaded from a SERP, the page will be preloaded if it is AMP. If you are creating an AMP page to be accessed directly (like the author), you fundamentally don't understand the problem that AMP solves and are using it wrong. PEBKAC.

Which is in disagreement with the OP's statement:

AMP is just a set of conventions and limitations that, when followed, make for a fast site.

AMP is more than that. AMP is the CDN that allows Google.com to preload your web page, and sits as an intermediary between you and your users.

It is a disagreement with OP's statement. Neither OP nor article author understand the problem that AMP solves.

Also, AMP is not a CDN. A CDN is a component of an AMP preloading implementation.

Anyone can run an AMP cache. Bing also serves AMP pages.

I dont want google to preload ANYTHING for me. Thanks.

If you go to the seminars held by Google, they suggest that in an ideal world your original pages would be AMP rather than having them separate.

True, that's what the article says. It's about control over users and data, not performance or UX.

It's about control of preloaded content, specifically. If you don't care about your content being easily preloaded from the SERP page, then sure, no need to use AMP. And if, as a user, you don't care about quick access to preloaded content (because e.g. you're on a low-latency connection), feel free to scroll down from the top-stories carousel.

Preloading is a waste of data on mobile. If you're on a metered connection then this costs more. Ranking sites by performance would already ensure a fast UX for users.

Also position on the SERP page is a major indicator of relevancy. Biasing results because they use AMP is unfair and inaccurate.

Reply on news.ycombinator.com