Hacker News Reader

Comment by untog | Hacker News Reader

Dumb, dumb, dumb, dumb.

The reason to use AMP is SEO. If you want literally any benefit other than SEO, just improve the performance on your own mobile site. Then you won't have to jump through weird hoops and come up with entirely new "magic carpet" user flows, because you'll actually control your own content on your own site.

The talk attached to this Medium piece was given at "TechSEO Boost", but the article itself dances around ever using the term. So we're left to wonder why AirBnb is very worried about being able to link users to their native app, while they apparently don't care at all about whether users are using their web site. It's because of SEO.

> the Accelerated Mobile Pages (AMP) project, which has some powerful backers including Google

> It would be fair to say that Google has been a very vocal supporter of the initiative from day one.

These are really weird ways of describing a Google-owned, Google-pushed initiative.

View on HN

In a large enough organization, improving site performance is hard, as you have to win political battles against your marketing / bizdev teams, denying them the analytics packages they want in the name of performance.

"We could do that, but then we'd lose the special AMP placement on Google SERPs" is a much more compelling argument, and preferable to starting a proxy war between the CMO and the CTO.

Google has done a hell of a job flexing their Search muscles to encourage the behavior they want, here. All the while somehow open-washing the project so that SEO-types make the ridiculous statements you quoted, implying that AMP isn't a Google owned-and-run project.

On an engineering level, I respect AMP. From an anti-competitive / social engineering perspective, it's absolutely terrifying.

AMP has a whole suite of technical limitations that are unrelated to the problem being solved. For example they limit pages to 50k (pre-gzip) of unlined CSS rather than allowing stylesheets to be linked. This is not how sites are generally built, and at least for me, meant rebuilding large parts of my build process.

Google engineers seem to have a hard time differentiating between a platform and a framework. PWAs and suffer from the exact same problem. They’re great if you build a greenfield product to their exact specs, but difficult to use otherwise.

>'how sites are built'

I take a look at the average mobile web page and thank Google that AMP brings sone restrictions.

Then why pretend that it’s still just a web page? Google might as well drop the charade and push an proprietary binary format.

Because becoming essentially Chrome only is the antithesis of their core business model of getting as many eyeballs as possible. Not particularly good for the web either.

From a technical standpoint it wouldn't surprise me if people start proposing binary formats that beat text/plain + gzip in size and speed.

>From a technical standpoint it wouldn't surprise me if people start proposing binary formats that beat text/plain + gzip in size and speed.

Webassembly

protocol buffer ?

> Google might as well drop the charade and push an proprietary binary format.

That's exactly what they are doing with Instant Apps, they just try different strategies to control the web more at the same time.

> AMP has a whole suite of technical limitations that are unrelated to the problem being solved. For example they limit pages to 50k (pre-gzip) of unlined CSS rather than allowing stylesheets to be linked.

How is limiting size and server round-trips of CSS not related to the problem being solved by AMP?

Because that's a problem that should be solved with HTTP2 push, not with inlining.

Why can AMP pages not use that? This seems like an orthogonal issue.

They can, but instead they do it the wrong way.

Why is it absolutely terrifying or anticompetitive? Microsoft implements its own AMP cache and has decided to use similar presentation for its AMP results. Baidu and Yahoo! Japan, both dominant in their own markets, also implement AMP caches.

Could you elaborate on this, I'm interested? It is Google's AMP spec or their own version?

The AMP spec, as written, allows anyone to host an AMP cache and serve AMP pages. Google’s is the biggest and the one you reach through Google search so people tend to assume it’s the only one, but Cloudflare runs one as well, along with the ones mentioned in the parent comment.

For more details, you can read the (very readable) AMP docs: https://www.ampproject.org/docs/guides/how_cached

I've done a previous comment on HN asking someone for a link to the spec for the AMP cache, but there is none. How can you claim it's a open technology (pointing at Google, not Itaxpica or any others on HN) when there is no way (except reverse-engineer) to figure out how the cache works?

The spec is on github: https://github.com/ampproject/amphtml/tree/master/spec and the code itself is one level up (github.com/ampproject/amphtml)

Here’s the section on guidelines for implementing an AMP cache: https://github.com/ampproject/amphtml/blob/master/spec/amp-c...

Yes - if you have ad networks to deal with.

Airbnb really doesn’t.

The "SEO" benefit comes at a big price. You give up the reddest part of your page's heatmap to a 3rd party with often conflicting objectives.

There's many downsides, but, for example...Google carousel results inject JavaScript that allows the end customer to left or right swipe right to a competitor...if you choose the AMP path.

I'm not clear on why Google doesn't give control of the top banner to publishers.

Doesn’t implementing AMP give you both the SEO benefit and the performance benefit?

Unless it's AMP for email, which is more like a set of rich features for Gmail recipients

> The reason to use AMP is SEO. If you want literally any benefit other than SEO, just improve the performance on your own mobile site.

It's a growth hack to get better organic search traffic, with user experience performance improvements a secondary concern.

My point is that you wouldn't know it from the article. It makes it sound like you should implement AMP for user experience and fast loading, despite then going on to detail the ways in which it compromises user experience.

When a big company like Airbnb jumps on a technology bandwagon people notice, and write-ups like this influence the choices other organisations make. They could at least just be upfront about the reasons why they're doing it.

The reason Airbnb is not likely to be upfront about why they're doing it, is it's very unlikely that Airbnb wants to admit they're probably being paid for it or getting some other form of special consideration for writing this.

The search benefit isn't even a long-term one: Either AMP will go away for some reason at some point, or, if the status quo is maintained, everyone will be forced to use AMP by Google's search monopoly, rendering it a null benefit to your rankings as everyone else transitions to it.

> The search benefit isn't even a long-term one: Either AMP will go away for some reason at some point, or, if the status quo is maintained, everyone will be forced to use AMP by Google's search monopoly, rendering it a null benefit to your rankings as everyone else transitions to it.

Maybe in the long term, but meanwhile they get the benefits for being early adopters. If AMP fails, they will simply roll back.

I think Airbnb should throw away everything they've done to date and hire all the Hacker News commenters to run their strategy instead.

> it's very unlikely that Airbnb wants to admit they're probably being paid for it or getting some other form of special consideration for writing this.

It doesn't look like anyone from Airbnb wrote this. But you're right, that's a good strategy - instead of the accommodation and experiences thing, they should implement AMP and get paid by Google for it. That's how business works: https://i.imgur.com/Vd6gI7X.jpg?1h

Congratulations Brian and Gil on implementing this!

Unless you're the 1% of websites you probably should implement AMP if you want fast loading (from search or news aggregators at least) because nothing is going to beat cached content loaded inline.

Reply on news.ycombinator.com