Hacker News Reader

Comment by leeoniya | Hacker News Reader

also, YouTube's embedded player is 1.17MB js minified (~411KB gzipped) [1]

this is why we simply self-host our mp4s w/ <video> tags.

Gmail and AdWords UIs are equally terrible/bloated perf-wise. the plain html version of gmail [2] is still by far the best. for a company that built V8, Closure Compiler, Chrome Devtools, PageSpeed Insights, Lighthouse, etc. they really do a shit job on their own properties. Gmail went from the best in performant webapps when it first popularized Ajax to the worst example of one in 2017.

it's as if Google can't find good frontend engineering talent, i don't get it :/

AMP is not a solution for slow pages, even if it's billed as such to clueless content producers. AMP is a content lock-in and user tracking strategy with the promise of boosted visibility/rank. nothing more.

[1] https://www.youtube.com/yts/jsbin/player-vfleyMpxV/en_US/bas...

[2] https://mail.google.com/mail/u/0/h/1pq68r75kzvdr/?v%3Dlui

View on HN

> also, YouTube's embedded player is 1.17MB js minified (~411KB gzipped) [1] this is why we simply self-host our mp4s w/ <video> tags.

I find that as a user this is an often not ideal. For starters I probably have the JS cached. And the videos almost always going to play faster and more smoothly from google CDN versus some homebrew solution.

> For starters I probably have the JS cached.

Caching is not an excuse for giant JS files, they still need to be executed by my browser.

> And the videos almost always going to play faster and more smoothly from google CDN versus some homebrew solution.

That is indeed usually true.

> For starters I probably have the JS cached.

this is one of those fallacies that people keep repeating and actually believe as truth. if you look at the headers of the youtube player file i linked, you'll see that anyone who had it cached prior to Wed, 28 Jun 2017 18:12:45 GMT is out of luck as well as myself when i request in > 48 hours. i dunno how often it changes, but it's safe to say "very frequently".

    date:Wed, 28 Jun 2017 18:23:58 GMT
    expires:Thu, 06 Jul 2017 18:23:58 GMT
    last-modified:Wed, 28 Jun 2017 18:12:45 GMT

also relevant: https://twitter.com/HenriHelvetica/status/877924754195324928

A good point.

RE that tweet, I assume the values there are in milliseconds. I hate it when people don't label their axes.

Isn't it cached from any website I visit that uses it though? Almost for sure by the time I land on this particular page I've picked up the JS like some virus.

> And the videos almost always going to play faster and more smoothly from google CDN versus some homebrew solution.

Speaking of this, why do all of those annoying autoplaying videos on every major news site always take ages to load? Every YouTube video starts playing instantly, but when I click a link to any news site I literally have to sit there waiting over 5 seconds for the video to start playing so that I can pause it again (because otherwise it will start playing after I've already started to scroll down), even though I have a reasonably fast connection.

because 90% of the time they load from some third party and the other overlapping 90% is that they're universally coded like shit.

They have to load the preload ad player followed by the ad followed by the video player that adds tracking to the auto playing video.

The homebrew solution can also be a CDN, just not Google's own.

Also, this greatly depends on the audience size: 30 users / hour might not need a CDN at all.

The CDN isn't just about volume, it's about location and bandwidth. It doesn't matter how many users you have, if the user is in Uganda and your server is in California, the video will never load immediately.

And even then, how would you create a homebrew CDN?

Sure, you could buy bandwidth, storage and processing capacity in multiple DC providers around the world and build, deploy and maintain your own solutions, at which point you're essentially becoming a small CDN with significantly higher costs as you don't have the efficiencies of scale and 100's (or 1000's) of multiple customers.

> The CDN isn't just about volume, it's about location and bandwidth. It doesn't matter how many users you have, if the user is in Uganda and your server is in California, the video will never load immediately.

But isn't it true that as long as you can send >1s of video in 1s, it doesn't matter? I.e. latency doesn't matter much in video streaming, and bandwidth doesn't need a CDN for the 30 users / hour case?

Also, latency probably doesn't matter for 99% of sites, which are already so bloated with JavaScript and other pointless content that processing time dwarfs the connection delay.

It matters, latency means buffering to start a video, plus rebuffering every time you move to a different point in the video.

> Also, latency probably doesn't matter for 99% of sites, which are already so bloated with JavaScript and other pointless content that processing time dwarfs the connection delay.

Indeed, but then CDNs also dramatically reduce the cost. It is far cheaper to serve an user in Jakarta from a server in Jakarta than from London. And even cheaper if the server is sitting in the ISP's core network in Jakarta.

The Internet as we know today couldn't exist without CDNs.

It doesn't matter how few users you have if they're on the other side of the world from your server.

> it's as if Google can't find good frontend engineering talent, i don't get it :/

They can. Addy Osmani, Paul Irish, the PWA people, etc. They just don't seem to employ them to actually make user-facing products.

> They just don't seem to employ them to actually make user-facing products.

it's fine if the high-level public-speaking folks aren't doing this, but the problem is that no one seems to be doing it.

anyone can open up the DevTools network panel during a Gmail load, then look at the timings, payloads and generated DOM to see that it's almost entirely absolute shit by Google's own standards, even in Chrome on a fast desktop; they still use MochiKit ffs. there are at least several hundred engineers here on HN that can rewrite the Gmail UI to be "blazing fast" without gutting features and would still work great even on old phones still running Android 4.4.4 (with latest Chrome).

obviously Google knows all of this, they just don't care because there's no measurable ROI in a faster free Gmail compared to getting people to host their juicy AMP content on Google's servers. "It's what the users want" is a half-truth optimized for maximum PR value; a bit like "Don't be evil".

Almost all the complaints on technical site performance I get from tools such as PageSpeed Insights and WebpageTest are indeed about Google's stuff, not mine, and as far as I can tell entirely unnecessarily.

Eg leaving at least some of their own static site-furniture graphics not fully minimised and not cacheable? Likewise the CSS. I keep removing Google stuff from my properties because it outweighs my stuff by typically 10:1, again entirely unnecessarily AFAIK!

And Inbox is even worse. It's fine on a modern beefy desktop but brings my slightly anemic ye olde Linux box to a standstill, whereas GMail is still basically fine.

Addy, Dominic, Eric, the Pauls, etc are (mostly) dev outreach for the Chrome team, which is why they're so well known. There are a LOT of talented frontend devs in Google; you just don't see them much externally.

That being said, there is also a toxic stance from many Google engineers (and management) that JS is a "lesser" language, and that feeling often translates to the devs that work in it.

> There are a LOT of talented frontend devs in Google...many Google engineers (and management) that JS is a "lesser" language

And exactly what language do these fine folks do their frontend development in, Go, C++?

Google sure spends a lot of resources on this lesser language for how few engineers want to work with it.

> And exactly what language do these fine folks do their frontend development in, Go, C++?

For a very long time, GWT (Java compiled to JS) was the preferred approach. Then development moved to the Closure compiler (JS following very Java-like patterns), and only very recently is ES6 style code taking off.

Much of the code you see still carries the legacy of GWT/Closure (and there is so much there that porting would be an insane task). It's a slow process. But, for example, YouTube is switching over to Polymer (https://youtube.googleblog.com/2017/05/a-sneak-peek-at-youtu...).

> Google sure spends a lot of resources on this lesser language for how few engineers want to work with it.

Google is a massive company, with many different (often conflicting) initiatives. Chrome spends a lot of effort on JavaScript; but Chrome engineers are (for the most part) not the ones that are writing Google's frontend code.

> For a very long time, GWT (Java compiled to JS) was the preferred approach.

fine, but this is entirely irrelevant. the problem is that no one was optimizing for the deliverable (HTML, JS, CSS). the GWT folks could have easily written an excellent compiler so it didnt spew a bunch of unoptimized and bloated trash.

> YouTube is switching over to Polymer

which requires a massive slow polyfill in all but latest Chrome and results in a shit experience for all others (if i recall a related thread correctly [1]).

[1] https://www.reddit.com/r/javascript/comments/68vehl/youtubes...

> fine but this is entirely irrelevant. the problem is that no one was optimizing for the deliverable (JavaScript). the GWT folks could have easily written an excellent compiler so it didnt generate a bunch of slow trash.

Compilers can only optimize so much. GWT/Closure do a very good job of it, too. https://www.peterbe.com/plog/advanced-closure-compiler-vs-ug...

Much of the "slow trash" is already optimized to death - it just dies under the weight of insane complexity (e.g. features), browser support, and overly-generic (IMO) support libraries

> which requires a massive slow polyfill in all but latest Chrome and results in a shit experience for all others (if i recall a related thread correctly).

Tangential: I'm not sure which version of Polymer they're using - but 1.0+ removes the need for most of the polyfilling.

> Compilers can only optimize so much. GWT/Closure do a very good job of it, too.

Closure certainly does; I use it every day. If Gmail is an example of how GWT optimizes things, then I'm afraid you're factually wrong.

> Tangential: I'm not sure which version of Polymer they're using - but 1.0+ removes the need for most of the polyfilling.

that thread is just 2 months old (i linked to it above)

It's a long time ago but from what I remember of the one GWT project I did ( a pretty big one though ), there wasn't any match to window.onload event, this made various optimizations difficult to do in GWT.

Guys that made the Closure compiler must take JS seriously.

Gmail in particular is still written using GWT, AFAIK, hence the strange HTML, etc. Its current frontend is probably an unsexy maintenance project, with little or no new development; most new features and dev efforts are likely in the "inbox" project, etc.

> Guys that made the Closure compiler must take JS seriously.

Indeed; Arv is a TC39 member.

> Gmail in particular is still written using GWT, AFAIK, hence the strange HTML, etc. Its current frontend is probably an unsexy maintenance project, with little or no new development; most new features and dev efforts are likely in the "inbox" project, etc.

IIRC, Inbox is also GWT, so that they could cross-compile for the native platforms (https://gmail.googleblog.com/2014/11/going-under-hood-of-inb...)

>this is why we simply self-host our mp4s w/ <video> tags.

So that I get way worse performance on trying to stream your videos than with YouTube's CDN?

Seriously, anything besides YouTube (from Vimeo to Comedy Central, CNN, any site that self-hosts) is exceptionally sluggish...

our traffic levels (as 85% of all sites) are low enough where the experience is significantly better to self-host without involving third party HTTPS connections or dependencies.

if we had an uptick in traffic, we would use a CDN to host the vids as long as the CDN didnt require that we swallow a 1MB js player for the pleasure of doing so.

A CDN isn't only for helping you handle large amounts of traffic. It also makes sure the content is close to the user so they get a better experience.

true, but the need for a CDN isnt a foregone conclusion. it entirely depends on your traffic. a CDN also exposes your users' privacy via third-party cookies [1].

[1] https://news.ycombinator.com/item?id=14694451

> It also makes sure the content is close to the user so they get a better experience.

The way most websites fuck that experience up with superfluous JS and media content makes this point moot, IMO. Being able to deliver JS 200ms faster doesn't help when you're serving megabytes of it.

It's not about the load on your servers.

It's about the CDN being optimized for my (or any other user's) region...

for major outlets with a truly global traffic pattern, sure. the vast majority of sites get 90% of their traffic from predictable regions. for instance, 99% of our traffic is from US and Canada.

I wish they did some more optimization on Gmail, and especially Inbox. The desktop UI is painfully slow to load, to the point that I mostly use it on mobile now..

Google Drive does not open anymore on my computer, seriously, while Google Spreadsheets (if I load them with a direct link) run smoothly.

AMP is a content lock-in strategy with the promise of boosted rank

Open, not locked in, anyone can parse and cache it and it has to be publicly available (versus Apple News and Facebook Instant Articles that are pushed to those services), ridiculously straightforward and obvious. Oh, and there is no boosted rank.

So aside from the entirety of your statement, you're entirely correct.

People can have rational discussions about whether AMP is worthwhile or not (for instance, Google hosting the canonical script seems dubious) -- or whether some other subset of HTML would be ideal given the endless bloat that allows publishers to abuse fly-by users. However the rhetoric on here regarding AMP is so over the top of flag waving nonsense that it simply doesn't fit on a site where presumably we're a little more enlightened.

Nobody else wants to parse or host it because HTML works just fine. We don't need a new version from Google that so far only helps with search result visibility while losing flexibility and increasing the amount of effort publishers need to effectively maintain 2 copies of their site. This is a regression back to the days of WAP mobile sites.

It also does lock-in the users into Google's experience rather than actually visiting the site, which is a big issue, including problems like further centralizing traffic and data to a single company.

Google could easily penalize search results based on speed with a strict cutoff and the entire web would become faster within weeks. Also the largest ad server on the web is Google's own doubleclick which is one of the slowest. There are many better ways to improve performance and UX without AMP.

Nobody else wants to parse it because HTML is a perfectly well functioning and accepted system

Apple and Facebook, two of the largest content (re)publishers, have their own competing formats, and Bing currently spiders and parses AMP content as well. But thinking more holistically, many others simply pushed their content into apps, abandoning the web wholesale. Because while we can talk about how "well functioning" the web is, a virtually universal observation is that native apps that just wrap a web browser are sloggy garbage, and a big reason is that the HTML stack has grown so enormously flexible it becomes its own enemy.

We don't need a new version from Google that so far only helps with google rankings

I'm a charitable sort of person, so when someone like Google comes out with something I assess why they did it without presuming the worst. In this case we see silos appearing from Apple and Facebook, not to mention the appification of content, so Google looks for a way to keep the web compelling. And it is. When I see an AMP page there are a number of user-centric benefits that make it a draw as a link, not just speed but also best behaviors.

I mean, many of the complaints on here about AMP seem just surreal. For instance if you open the carousel (an option for trending topics like Trump) and swipe, it brings you to the next story in the carousel. This outrages some that you aren't locked in the gutter of a given site, which is just bizarre and anti-user.

>Apple and Facebook, two of the largest content consumers, have their own competing formats

Solving different problems on THEIR platforms.

AMP is just imposing a non-solution to a non-problem on web users.

It isn't imposing, and as a user who frequently travels to emerging markets, it is a problem, and as a user, I see this as a solution, I usually prefer sites with the AMP logo because my general impression is that they load far faster.

Maybe you're just not the target user for this, or even for the Internet. And to be honest, pretty much nobody reading HackerNews is the target user for this.

So slow page load speed is a non problem and speeding up delivering content is not a solution? Whether you like it or not, if you search on Google, you are using THEIR platform and you are THEIR user. What they have determined is that their users want to consume content faster than what is traditionally available on the web. So you'd rather wait 3 seconds to see your ebay listing than half a second? For the open web, javascript bloat and google is taking over the world reasons. That suits you fine but not the majority of users on Google. Why would Google be implementing a technology that is BAD for their users?

> Why would Google be implementing a technology that is BAD for their users?

Because it is GOOD for Google.

This is about consolidating more time and data on their systems. You never leave a Google server with AMP. UX is secondary benefit used as marketing to force this on sites along with search rankings.

Also Google owns Doubleclick which is the biggest and slowest ad server on the planet.

>So slow page load speed is a non problem

Yes, it's not a problem: it's a symptom.

Bloated pages is the actual problem - for which there is an existing well known solution: reduce the crap on your pages.

No new single company standard, no furthering Google's market capture, and no hiding links, is needed to achieve that.

>Why would Google be implementing a technology that is BAD for their users?

Gee, I wonder, why would ever a company do that. Except, for profit, and market capture, and reducing competition, and all that...

You really should get an AOL subscription. If you ask nicely they just might let you use the 1994 edition which did pretty much all that you describe. And then we got the web.

Exactly the level of discourse that HN is capable of having regarding AMP. Congratulations.

The greatest lie in this discussion is the farcical notion that it's "AMP vs the Full Web", as if those are the only options. It's facile sophistry, but if it's anti-AMP it's all good here.

> but if it's anti-AMP it's all good here.

And if it's pro-AMP then it's good for you.

Really, AMP is a step back and something that solves entirely the wrong problem, and coincidentally continues the trend of Google pulling ever more content into its own eco-system to get to the point where you hopefully will not leave Google any more during the course of a browsing session.

If you feel that's good then I really don't know what arguments would make you see that this is the opposite of where we should be headed, all this vertical integration on the web serves nobody except for the few largest players. If the frog doesn't jump out of the pot while it still can then that's a point against the frog.

And if it's pro-AMP then it's good for you.

As a user, I like AMP. I don't work for Google and have zero investment in whether AMP succeeds or fails. But I'm capable of rationally discussing it without ridiculous FUD or pejorative noise, which so many of you aren't.

If you feel that's good then I really don't know what arguments would make you see

Of course. Allude to the greater knowledge that the ignorant fool just doesn't get. 2 for 2 now.

> But I'm capable of rationally discussing it without ridiculous FUD or pejorative noise, which so many of you aren't.

Well, since you are commenting across many threads in the same vein I don't see what gives you the moral high ground on this.

You as a user like AMP, but what's good for you as a user may very well be detrimental to the web and your personal temporary inconvenience need not have taken a backseat to 'the greater good' if Google had simply increased the penalty for web bloat.

That's what I'm getting at when I say that AMP is solving the wrong problem, or if it is solving the right problem that it is solving it in the wrong way.

This is just Google replacing one kind of bloat with another and we need neither. It is also a fantastic example of how a near monopoly position can be abused to extend your grip on other markets.

Whether you work for Google or not doesn't interest me one bit, what I wonder about is if you do not remember the past where we had all these systems that wouldn't talk to each other and where a few very large players dictated what the rest of us should do.

Google is outright coercing content owners to support AMP 'or else' and that's just not the web that I want to see. Giving Google a free pass here means that other players will take it as a sign that the time is ripe for the next land-grab and then we will all - including you - suffer.

My web properties will never support AMP, they're not bloated to begin with and whatever penalties Google assigns to them are proof positive that this never was about bloat.

> But thinking more holistically, many others simply pushed their content into apps, abandoning the web wholesale

What are you talking about? No they haven't, all major publishers continue to develop and grow their websites with some reaching into other social platforms to distribute further. Nobody has moved to an app, if anything apps have decreased in importance across the mobile universe. And if you're trying to talk about complex webapps then they were never a target for AMP anyway.

If all you really care about is user benefits, then as I described Google already had plenty of options that would be faster and easier without forking the web.

What are you talking about?

Virtually every major publisher has an app that they try to herd users into. As do many if not most social news sites. Was your question satirical, or have you just been asleep for a decade?

Given the nonsensical beginning to your comment, the rest just seems like farce.

Another big anti-AMP person is John Gruber and your comment reminded me of him -- He'll effortlessly go from advocating why iOS apps aren't anti-web, because they're still hand-wavy using web services or something, and then go on a diatribe about AMP. It's quite a delightful bit of mental flexibility.

Having an app available is not "abandoning the web" - which is what you claimed. I've worked with all the major publishers and their biggest focus is always their own websites.

And if you can't even finish a comment that replies to exactly what you wrote then what are you doing talking about the "level of discourse" on HN?

Abandoning meaning not basing their electronic presence on it. No one wants to be just a website, except for maybe Metacritic. Everyone wants to be an app.

what are you even doing talking about the "level of discourse" on HN?

A recurring set of alternative facts rise to the top of every discussion on AMP, and my post that questioned it sits at -5. It seems laughable to now demand that I rise above -- I just find it funny.

> No one wants to be just a website, except for maybe Metacritic. Everyone wants to be an app.

No major publisher wants to be an app. It's reasonable to have one available for the few users who want it but that's it. Apps don't have enough usage, have lower ad rates and take far more work to maintain for very few, if any, advantages.

The apps hype cycle has played out, most users spend 80%+ time on just 5 major apps, which are email, messaging and social platforms which link to content using in-app browsers, so if anything the websites are even more important than before. And any complex service like Yelp or ecommerce was never a use-case for AMP pages anyway so that doesn't apply here.

No major publisher wants to be an app

Every action says that this is a very wrong assumption. In an era of OS-provided ad and tracking blockers, the desire to appify is greater than ever. Now we have Android Instant Apps and the almost certain appearance of the iOS alternative.

and social platforms which link to content using in-app browsers

Facebook once opened links in an external browser. Then they actually wrapped Webkit and started coddling it in a built-in browser. And now they're heavily favoring content that is pushed as Instant Article content. There are only so many times that a user can be attacked from malicious websites before the people who send you there start to get wise.

It's not an assumption, I work with all the major publishers and their executives. Apps are secondary efforts at best and do not approach anywhere near the amount of engagement of their websites.

IA is Facebook's attempt at keeping people on their own platform, similar to AMP's primary focus, and it also does not have as much uptake as it might seem. Other than that, a browser is a browser and opening a publications website is the vast majority of traffic, and consequently where the vast majority of effort is dedicated.

Surely you can see the less attractive aspects of Google's AMP cache?

They inject a carousel, push the organics down. Then you have to publish AMP to make it into the carousel.

At which point Google takes over your page. Adding a big amp banner with a [x] button that doesn't do what users expect. Inserting a pagination widget that scrolls to competing content, breaking the back button, etc. Is it a coincidence that all of that drives more pageviews of Google's site? Is it really your page if you don't control it?

They inject a carousel, push the organics down.

Why do we always have to talk about the carousel? It is only relevant for news/trending topics. For that the whole "organics" are upended regardless.

Is it a coincidence that all of that drives more pageviews of Google's site?

I really, really don't think Google cares about "pageviews". But yes, it may make users think "these results are quick and convenient, so maybe I won't use Facebook as much for trending topics".

>I really, really don't think Google cares about "pageviews".

If you followed what they did over time with Wikipedia content and links, for example, you might feel differently. Or Froogle, or KG, Google Flights, or this recent change: https://mobile.twitter.com/jeremys/status/876978936177082368... , etc.

The investor pressure on Google to sustain year over year click growth, that exceeds overall web growth...is tremendous.

Driving more pageviews is one of a very few levers they have to do that, since they have exhausted many others. Once you push all organics off the fold, there's not much else you can do.

Edit: We talk about the carousel, because it perhaps best telegraphs the true intent of AMP. Everyone told me to shut up about Froogle too, because it was free for advertisers.

If you followed what they did over time with Wikipedia content and links

Search has evolved past a list of links. Every vendor in the space is doing exactly the same thing -- becoming a knowledge engine versus a keyword corpus. Yes, Google wants to create a useful product. Nothing particularly nefarious about that.

Driving more pageviews is one of a very few levers they have to do that, since they have exhausted many others.

When has Google published pageviews? Google publishes revenue and income, and userbases for a few properties and products. They don't publish or gloat about pageviews, and it is entirely irrelevant if they serve you a page from a cache or not. But yes, they probably worry that as the web gets more user hostile, users might choose silos like Facebook Instant Article, where Facebook ads might be more likely, but in that case we're talking about user likes and dislikes which is tough to argue against.

We talk about the carousel, because it perhaps best telegraphs the true intent of AMP

Is this not FUD? Reading the tea leaves and discerning the future. Personally I find Android Instant Apps a dramatically bigger threat to the vague idea of the web.

>When has Google published pageviews?

Didn't say they did. They have, though, clearly done things to keep people on their properties vs straying off to the organics. Which is the same thing as pageviews.

Why else, for example, would hitting the back button 2 stories deep into a carousel AMP article not go back one article...but go all the way back to Google?

They don't publish their CTR for search pages either. You think that means they don't track goals for it internally?

Edit: Regarding this...

"Is this not FUD? Reading the tea leaves and discerning the future. Personally I find Android Instant Apps a dramatically bigger threat to the vague idea of the web."

Phrased as if I said AMP was their sole strategy. Of course they have multiple ideas to placate the investors that are used to double digit percentage YOY click growth. One does tend to focus on search since that's where the vast majority of their revenue is.

As for tea leaves, sustaining the same growth of stock price almost requires anti consumer and anti partner behavior.

Why else, for example, would hitting the back button 2 stories deep into a carousel AMP article not go back one article...but go all the way back to Google?

Given that it doesn't do this, at all, I'm not sure how to respond. Yes, if you open a story in the carousel and then swipe to the next story via the machinations of the carousel, then clicking back goes back to "google". But if you follow "organic" links it goes to a rote web experience.

Phrased as if I said AMP was their sole strategy

No, it's phrased as if you said exactly what you said, and needs no strawman. Whether you hit a Google cache or a host site means exactly squat. Google's core intention, it seems, is simply to try to provide a good experience for the user which is indeed a long term income strategy.

>Given that it doesn't do this, at all

It does though. On a mobile, go to google and search "Trump ". Click a carousel article. You're now on somebody's "AMP Cached Page", right? Let's say it's WaPo. Now right swipe, and you'll go to a competitor's site...say Fox News. Now click back. You'll go back to Google instead of WaPo. And, I did specifically say this was with a "Carousel AMP Article". You're not really being fair by saying "doesn't do this". It absolutely does.

The point though. It isn't that this one choice to hijack the back button is the whole strategy.

It's indicative of a larger strategy to use UI patterns that keep people on Google properties and off of other people's. Which is kind of an odd way for a search engine to work.

It's one of many. Here's a new one from today: https://mobile.twitter.com/jeremys/status/876978936177082368...

It's almost as if...well, "The goals of the advertising business model do not always correspond to providing quality search to users".

It does though.

But it doesn't. You said two levels deep, but what you just described isn't at all. AMP is the container with the list of articles, and back logically and rightfully exits the container. If you clicked a link in one of those stories, it uses entirely normal web behavior. But yes, swiping, a function added by amp, in a container provided by amp, using the list provided by amp, is a lateral move not a depth move.

It isn't that this one choice to hijack the back button

The carousel is an entirely unique construction to provide news, exactly like a hundred other options that use similar paradigms. This, and the "hijack the back button" thing invariably gets dragged into every AMP discussion, as if Google trying to provide a news service is undermining some random blog link.

What I described does happen. You're saying something else doesn't happen...something I never claimed. That's a weird way to argue a point.

You get that the carousel existed before AMP, and didn't do any of this, right? No other page cache takes over the page like this. Digg died an early death, in part, by trying to do something similar. Taking over other people's pages...in their case an iframe.

What about the [x] button on the AMP banner being a back button to Google? Is that not odd? Don't most users expect an [x] on a banner to kill the banner and leave you on the page? Like the EU cookie warnings?

It's true that Google doesn't explicitly boost AMP pages. But it does boost all of the attributes that AMP enforces on a page (reduced page size, loading speed, etc). So it's an implicit signal boost rather than explicit. You may think that that's fine and there's nothing wrong with that, but no doubt Google see this as a way keeping users within the Google system as much as possible while they browse.

I'm personally on the fence regarding the whole situation. On one hand, I like less bloat, on the other I don't want a 3rd party involved more than is required in delivering a news article to me.

"It's true that Google doesn't explicitly boost AMP pages. But it does boost all of the attributes that AMP enforces on a page (reduced page size, loading speed, etc)."

So Google is guilty of making things that users want?

"Google see this as a way keeping users within the Google system as much as possible while they browse."

Well, isn't giving users what they want a way to keep them inside your system?

I don't see the point in your comment, are you saying that Google should not be optimizing for what users want?

>So Google is guilty of making things that users want?

Well, I'm a user and I don't want this.

I want Google to not invent a new format for web pages, and instead help make the actual web faster.

"Well, I'm a user and I don't want this."

You (and myself, and anyone reading HN) are not the target user for this, nor are you representative of the typical internet user.

Remember, India has more internet users than the US has people.

And you can just not click on AMP sites if you don't want them.

Indian users are the worst example for this, given the regular 2G connections. Hundreds of KB of JS is not helping this, especially not on low-end mobile devices.

It is helping this when you consider all the JS is cached because they've visited an AMP page before.

No, they are not, that's a misconception. Many low end devices simply lack the capacity to efficiently cache this many things, so they are going to re-download it once it's purged.

For the downvoters: https://danluu.com/web-bloat/

Many low end devices simply lack the capacity to efficiently cache this many things

Very low-end devices still have an outrageous amount of memory and storage compared to the scopes we're talking about. In the actual anecdotes of people in India expressing their good user experience with AMP, actual results seem to differ.

But as a North American with a GS8 and a very fast LTE connection, I still love getting AMP results. Just confining to best practices is alone worth it.

Oh I see. So low end devices in india which are predominantly android smart phones do not have the capacity to cache 500kb of frequently used JS?

Reducing the overall page size of a given page doesn't help

Optimizing rendering for content first and images loaded as required doesn't help

Serving pages from a super fast global CDN doesn't help

And prefetching content behind the scenes also doesn't help

I think you should take these to Google because it seems like they've totally goofed this AMP thing!

All those 500KB JS adds up, and the memory on those devices are shared with the fb, twitter, whatever bloatware apps.

And yes, amp is a horrible idea. Block ad networks instead.

"All those 500KB JS adds up, and the memory on those devices are shared with the fb, twitter, whatever bloatware apps."

No, those are pushed out of memory.

"And yes, amp is a horrible idea. Block ad networks instead."

Well, just don't access any ad-funded content. You can't have the cake and eat it too.

>You (and myself, and anyone reading HN) are not the target user for this, nor are you representative of the typical internet user.

Yes, but the typical internet user has never heard of AMP and wants it even less...

>Remember, India has more internet users than the US has people.

Which can always use simple lightweight html pages instead of AMP with its JS cruft?

"Yes, but the typical internet user has never heard of AMP and wants it even less..."

But they might have seen the icon, and realized it means "it loads fast!", and they want it.

Users want faster pages, we can agree on that, correct?

They don't know what AMP is, and don't care about it.

"Which can always use simple lightweight html pages instead of AMP with its JS cruft?"

You can, but no publishers seem to want to do so. But you can. AMP is optional.

> But they might have seen the icon, and realized it means "it loads fast!", and they want it.

Imagine your country's water sources are filthy and crappy. Your tap water literally stinks - all of that because of unrestricted commercial development. Now imagine that to solve this problem, your government created a certificate mark (Aqua Model Premium, complete with a cool icon), which can be issued to bottle water companies who meet a set of water quality criteria.

People want clean drinking water, they might have seen the AMP icon, so they'll go and buy the water bottles from government-certified companies, right?

(Oh, and let's not forget the criteria are written in such way that the bottle companies can literally shit in the bottle, as long as they use government-certified shit dispensers for that.)

Or how about the government starts issuing penalties to water delivery companies and to those who pollute rivers, until the tap water again meets the AMP criteria?

It's not a perfect analogy (Google is not a government, but it kind of owns most of the web as we know it), but it's more-less how I see this situation. Google already penalizes some bloat; they could push this much further (especially for mobile searches) instead of creating a new pseudo-standard.

The point being, as a solution for bloat, AMP is at best a workaround. But as this article proves, it's not even an effective workaround - AMP pages are free to include all the usual resource-heavy crap, just through a new set of "AMP-optimized" JS libraries.

Reply on news.ycombinator.com