The bloat of AMP(lolware.net)
lolware.net
The bloat of AMP
https://lolware.net/2017/07/04/amp-bloat.html
113 comments
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.
> 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 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".
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!
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.
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.
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.
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...)
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...)
> 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++?
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. 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 (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. 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.
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.
> 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)
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)
[deleted]
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.
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.
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. 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".
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, 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.
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.
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, 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. 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.
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?
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?
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.
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 (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.
Solving different problems on THEIR platforms.
AMP is just imposing a non-solution to a non-problem on web users.
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.
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.
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...
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...
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.
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.
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.
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.
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.
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.
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? 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.
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?
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.
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. 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.
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.
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.
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.
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?
"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.
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.
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/
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.
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!
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.
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.
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.
[deleted]
>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...
>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.
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.
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.
[deleted]
[deleted]
> 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.
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.
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".
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
A good point.
RE that tweet, I assume the values there are in milliseconds. I hate it when people don't label their axes.
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.
> 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.
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.
> 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.
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.
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.
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.
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.
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.
> 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.
>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...
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.
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.
> 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.
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.
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
[1] https://news.ycombinator.com/item?id=14694451
It's not about the load on your servers.
It's about the CDN being optimized for my (or any other user's) region...
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’ve tested the AMP and regular versions of a The Guardian article page, and the AMP version is more than 4 times smaller in terms of transferred KBs, coming in at about 300 KB. Yes, JavaScript represents more than half of that size, and there are 16 separate script files, but in comparison to the regular page, it’s a significant improvement.
Note: I’ve tested with an ad/tracking blocker.
Note: I’ve tested with an ad/tracking blocker.
That 150KB js needs to be executed in the browser, most of which could be simple HTML and CSS.
I was implying that AMP leads to a reduction of JS in practice. Of course, if you have a very simple blog which loads very little JS to begin with, AMP could make things “worse.” But these types of blogs are an exception—unfortunately.
The funny thing is that that Guardian article page is probably less then 10Kb in content to begin with. It's all the cruft on the page that makes it large, and AMP is also cruft, just less of it.
The main content does indeed load after disabling JavaScript. The page size is about 60 KB in that case.
> I mean, I still can't make Get Cryptolocker[0] show up on Google.
Hmm, I wonder if that's something to do with the fact that you're literally distributing malware...
Surely there are legal issues here too?
[0] getcryptolocker[.]com/get/
Edit: According to the about page, it isn't really cryptolocker, but VirusTotal still isn't happy about it: https://virustotal.com/en/file/0a2816af8a0580b0f58cb4ee1f102... I'm sure that in itself will hurt rankings.
Hmm, I wonder if that's something to do with the fact that you're literally distributing malware...
Surely there are legal issues here too?
[0] getcryptolocker[.]com/get/
Edit: According to the about page, it isn't really cryptolocker, but VirusTotal still isn't happy about it: https://virustotal.com/en/file/0a2816af8a0580b0f58cb4ee1f102... I'm sure that in itself will hurt rankings.
> Edit: According to the about page, it isn't really cryptolocker, but VirusTotal still isn't happy about it ….
Since you've obviously followed this up, for the benefit of those of us who don't want to follow the link, could you explain what it is?
Since you've obviously followed this up, for the benefit of those of us who don't want to follow the link, could you explain what it is?
I have no idea, I haven't tried running it.
Author here. It's a page I built for phishing susceptibility testing. There's another entire blog posting in the fact that I get about a 70% success rate emailing people from .ru domains asking them to visit that site and run the executable.
It is 100% benign.
It is 100% benign.
AMP plugins are (supposedly) designed to be the fastest/lightweight/user-friendly implementation of a specific functionality.
Yes, if all you consider by "bloat" is how many kilobytes of javascript you have on the page, AMP is not doing well. This is a crucial mistake in this post. In reality "bloat" is more than that. It also refers to whether there's active javascript slowing the browser down, whether resources are cached etc.
The purpose of having these small plugins that enable functionality is that they are all individually cached by your browser for a good amount of time. Any Google user would have them cached as they are all using the same reference that any other AMP page would. This is unlike other "bloat" where resources are fragmented and come from any number of sources that users probably haven't hit before. In addition these JS resources wouldn't have been written for a specific experience - which AMP is
Yes, if all you consider by "bloat" is how many kilobytes of javascript you have on the page, AMP is not doing well. This is a crucial mistake in this post. In reality "bloat" is more than that. It also refers to whether there's active javascript slowing the browser down, whether resources are cached etc.
The purpose of having these small plugins that enable functionality is that they are all individually cached by your browser for a good amount of time. Any Google user would have them cached as they are all using the same reference that any other AMP page would. This is unlike other "bloat" where resources are fragmented and come from any number of sources that users probably haven't hit before. In addition these JS resources wouldn't have been written for a specific experience - which AMP is
The problem is, though, that the moment such wide variety of rich-media plugins is available, AMP stops working for bloat prevention - people will bloat up their AMP pages with superfluous media and JS. Bloat is not a web protocol problem - it's a problem of people being incentivized to add it.
> this image will helpfully render with three dots in the middle to show you it's full of AMP goodness or something.
It will render with three dots to let the browser know it is still loading. once it has finished, the dots disappear.
It will render with three dots to let the browser know it is still loading. once it has finished, the dots disappear.
Google decided to name something "AMP" to confuse people who've used AMP to refer to Apache, MySQL and PHP for ages? Thanks, Google!
you also have to remember these javascript files are then cached and used for ALL amp pages across the board and only gets invalidated once a week. there is also a stale-while-revalidate mechanism in amp if service workers are available so users never experience the delay of fetching new javascript binaries
I haven't used AMP, but my impression with all of Google CDN JavaScript files for AMP is the end user has to download them just once per version (which I agree will lead to a bloated first load experience) but on subsequent requests throughout the AMP network they'll be loaded from cache. Similar to how Google recommends you load jQuery through their CDN since millions of people already have it in cache.
And then you have to waste your battery on running 100s of kbs of JS to show static HTML.
No thanks.
No thanks.
But you'd rather go to the non AMP version which is 10x as bloated?
It seems like the vision in your head is: AMP vs. Perfectly optimised site. In reality it's publishers who have built their main site over several years with massive bloat and are unable for whatever reason to optimise.
It seems like the vision in your head is: AMP vs. Perfectly optimised site. In reality it's publishers who have built their main site over several years with massive bloat and are unable for whatever reason to optimise.
What google could do instead, if they really cared, is incentivise simple javascriptless static HTML. They won't do this though, because it makes tracking for ads harder.
This seems to be the main recurring argument against AMP.
It isn't a comparison between AMP and the current web, it's a comparison between AMP and this utopian case where the entire web is simple javascriptless static HTML.
It's like the ascii ribbon against HTML email...
It isn't a comparison between AMP and the current web, it's a comparison between AMP and this utopian case where the entire web is simple javascriptless static HTML.
It's like the ascii ribbon against HTML email...
The diffence is that google has the power to improve the web and instead they warp it for their own profit while saying they're improving it.
No one doing the ASCII ribbon thing could change what the majority of mail users saw when they opened their mail clients.
No one doing the ASCII ribbon thing could change what the majority of mail users saw when they opened their mail clients.
The problem is that what you call "improving the web" isn't necessarily what other users would call "improving the web".
What do you mean by improving the web?
What do you mean by improving the web?
Breaking down a few of the concerns in this article:
> Google's v0.js, which is compulsory on every AMP page, is currently 217Kb of Javascript.
It is only 67KB gzipped, so it's not as bad as suggested, but this is an area for improvement.
However, the file size doesn't directly translate to the implied latency, which is really what we care about. There are several reasons why this is much better than your average <5KB javascript files:
- The file loads with an async tag, so does not block rendering.
- The file uses a stale-while-revalidate header with 30-days, which means that any user who views any amp page on the web once a month will never wait for this file after the very first page load. That's most users.
- If the page is loaded from the AMP cache, which is probably the common case, the file has a 1 year expiration.
- The javascript uses a foreign fetch service worker to implement the same 1-year effective expiration on the non-AMP cache page views, for browsers that support it.
> Google's default analytics.js is 30Kb. The AMP compliant edition of amp-analytics-0.1.js - is 80KB.
All of the same responses as above apply here too. It's actually only 27KB on the wire, uses stale-while-revalidate and foreign-fetch service workers, etc.
However, this is also not a completely fair comparison. amp-analytics doesn't implement Google Analytics, it implements every common analytics vendor on the web and has a configuration system for novel vendors. Most pages have half a dozen vendor's scripts running on them each with their own javascript payload and running code. This produces a single analytics event runtime and dispatches events to all of the vendors you want to run.
Another advantage here is that it's not a new origin to connect to. Even if it's not cached, the DNS and HTTPS connections will be shared with v0.js and any of the other extensions. Depending on your connection, this will almost certainly reduce latency more than the added bandwidth.
> you can still embed bloatey ads
True, however what is less obvious is that those ads cannot block the main thread for loading the page, so they can't cause issues with scroll or displaying content. In fact, the ads don't actually load until right before they should be in the viewport. The ads also cannot reflow the layout of the page, making content move around as the page loads.
> you could dynamically build a page using a mustache template
True, but you cannot do so using custom javascript on the client which often blocks the rendering thread. This is a direct mapping from json to html.
> The other is to append #development=1 to a URL. Unfortunately, if you try that here, your browser will crap out with errors about CORS and a CSP violation.
The issue here is that the validation must operate on the original source of the document. By the time javascript runs, the browser has modified the DOM to the point where the original string is simply unavailable. So the #development=1 trick works by refetching the document using an XHR which only works in certain CORS environments. I'm not sure how else to do this. If you want to validate docs often, I recommend the chrome extension instead (https://chrome.google.com/webstore/detail/amp-validator/nmof...). There are ports for other major browsers.
> Paraphrasing: you can still load animations, large images, videos, etc.
True, but you also don't have to. All of the code for loading these things has been optimized so that while it still may take a while to load those embedded objects, they won't slow down the rest of the document, which is the main advantage. They also won't cause re-layout events causing content to jump around while the page is loading.
As a test, open up the network panel on chrome devtools, simulate a mobile phone with a smaller viewport, and hard refresh the page. You'll notice that the 9MB image included as a demo doesn't even get fetched. It's only when you scroll down halfway on the document that this image starts loading. This is what the amp-img component is accomplishing.
The author appears to want fewer html features supported which is understandable, but it's not clear that this opinion is widely shared.
> this image will helpfully render with three dots in the middle to show you it's full of AMP goodness or something.
It's a loading indicator, the dots disappear when loading is complete. This is admittedly an odd effect with an animated gif, since the loading is still happening after the first frame has completely loaded.
> Google's v0.js, which is compulsory on every AMP page, is currently 217Kb of Javascript.
It is only 67KB gzipped, so it's not as bad as suggested, but this is an area for improvement.
However, the file size doesn't directly translate to the implied latency, which is really what we care about. There are several reasons why this is much better than your average <5KB javascript files:
- The file loads with an async tag, so does not block rendering.
- The file uses a stale-while-revalidate header with 30-days, which means that any user who views any amp page on the web once a month will never wait for this file after the very first page load. That's most users.
- If the page is loaded from the AMP cache, which is probably the common case, the file has a 1 year expiration.
- The javascript uses a foreign fetch service worker to implement the same 1-year effective expiration on the non-AMP cache page views, for browsers that support it.
> Google's default analytics.js is 30Kb. The AMP compliant edition of amp-analytics-0.1.js - is 80KB.
All of the same responses as above apply here too. It's actually only 27KB on the wire, uses stale-while-revalidate and foreign-fetch service workers, etc.
However, this is also not a completely fair comparison. amp-analytics doesn't implement Google Analytics, it implements every common analytics vendor on the web and has a configuration system for novel vendors. Most pages have half a dozen vendor's scripts running on them each with their own javascript payload and running code. This produces a single analytics event runtime and dispatches events to all of the vendors you want to run.
Another advantage here is that it's not a new origin to connect to. Even if it's not cached, the DNS and HTTPS connections will be shared with v0.js and any of the other extensions. Depending on your connection, this will almost certainly reduce latency more than the added bandwidth.
> you can still embed bloatey ads
True, however what is less obvious is that those ads cannot block the main thread for loading the page, so they can't cause issues with scroll or displaying content. In fact, the ads don't actually load until right before they should be in the viewport. The ads also cannot reflow the layout of the page, making content move around as the page loads.
> you could dynamically build a page using a mustache template
True, but you cannot do so using custom javascript on the client which often blocks the rendering thread. This is a direct mapping from json to html.
> The other is to append #development=1 to a URL. Unfortunately, if you try that here, your browser will crap out with errors about CORS and a CSP violation.
The issue here is that the validation must operate on the original source of the document. By the time javascript runs, the browser has modified the DOM to the point where the original string is simply unavailable. So the #development=1 trick works by refetching the document using an XHR which only works in certain CORS environments. I'm not sure how else to do this. If you want to validate docs often, I recommend the chrome extension instead (https://chrome.google.com/webstore/detail/amp-validator/nmof...). There are ports for other major browsers.
> Paraphrasing: you can still load animations, large images, videos, etc.
True, but you also don't have to. All of the code for loading these things has been optimized so that while it still may take a while to load those embedded objects, they won't slow down the rest of the document, which is the main advantage. They also won't cause re-layout events causing content to jump around while the page is loading.
As a test, open up the network panel on chrome devtools, simulate a mobile phone with a smaller viewport, and hard refresh the page. You'll notice that the 9MB image included as a demo doesn't even get fetched. It's only when you scroll down halfway on the document that this image starts loading. This is what the amp-img component is accomplishing.
The author appears to want fewer html features supported which is understandable, but it's not clear that this opinion is widely shared.
> this image will helpfully render with three dots in the middle to show you it's full of AMP goodness or something.
It's a loading indicator, the dots disappear when loading is complete. This is admittedly an odd effect with an animated gif, since the loading is still happening after the first frame has completely loaded.
Hi Greg,
Thanks for your response here. I think we'll just have to agree to disagree on a number of points, but there's a few I would like to comment on:
If the 30 day stale-while-revalidate really invalidates those two headers, and I'm not knee-deep in browser support enough to really know, can someone at Pagespeed please consider this a bug?
The issue has come up a number of times on various forums over the years in relation to the vanilla analytics.js, and the answer that's usually accepted is "just self host the Javascript". I'm calling it now - people will start doing this with AMP scripts if Pagespeed doesn't change the warning, regardless of the consequences.
[0] https://www.ampproject.org/docs/tutorials/create/preview_and...
Thanks for your response here. I think we'll just have to agree to disagree on a number of points, but there's a few I would like to comment on:
If the page is loaded from the AMP cache, which is probably the common case, the file has a 1 year expiration.
If the 30 day stale-while-revalidate really invalidates those two headers, and I'm not knee-deep in browser support enough to really know, can someone at Pagespeed please consider this a bug?
The issue has come up a number of times on various forums over the years in relation to the vanilla analytics.js, and the answer that's usually accepted is "just self host the Javascript". I'm calling it now - people will start doing this with AMP scripts if Pagespeed doesn't change the warning, regardless of the consequences.
trick works by refetching the document using an XHR which only works in certain CORS environments. I'm not sure how else to do this.
[0] https://www.ampproject.org/docs/tutorials/create/preview_and...
> Looking at the headers via curl, I see "expires" with the current date and time (ie, it's already expired), a max-age tag of 50 minutes. I'm not seeing one year anywhere.
Take a look at the version of the doc which is served from the AMP cache: https://cdn.ampproject.org/c/s/lolware.net/2017/07/04/amp-bl...
I like to think of PageSpeed Insights like the output of a good linter. No linter is or can be perfect. The issues reported are good things to consider and are correct for the majority of times that they trigger, but not in all cases. This is one of those cases.
> CORS
The best fix here might be a more useful response in the dev console. Plenty of sites, especially on dev servers, don't have any CORS headers at all, so this does work in those cases. I'd still recommend one of the other validation methods which work fine with any CORS setup.
Take a look at the version of the doc which is served from the AMP cache: https://cdn.ampproject.org/c/s/lolware.net/2017/07/04/amp-bl...
I like to think of PageSpeed Insights like the output of a good linter. No linter is or can be perfect. The issues reported are good things to consider and are correct for the majority of times that they trigger, but not in all cases. This is one of those cases.
> CORS
The best fix here might be a more useful response in the dev console. Plenty of sites, especially on dev servers, don't have any CORS headers at all, so this does work in those cases. I'd still recommend one of the other validation methods which work fine with any CORS setup.
The site uses AMP. My block AMP since it's a cross-domain request.
After a while some inline script must be running into a timeout because the content suddenly shows up.
Completely disabling javascript makes the site display faster.
After a while some inline script must be running into a timeout because the content suddenly shows up.
Completely disabling javascript makes the site display faster.
less whining, more gifs of talented cats.
[deleted]
If there was an option to disable AMP in Chrome, I'd flip it to off immediately. The longer this option is MIA, the more likely Firebox will become my default browser (again!)
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