6 ms·

> However, as a non-principled web consumer, I think AMP pages are 10x better than the ad-filled, slow as molasses, jump-around-as-JavaSript-loads, video autopl

> However, as a non-principled web consumer, I think AMP pages are 10x better than the ad-filled, slow as molasses, jump-around-as-JavaSript-loads, video autoplaying, 'stories you might like' suggested bullshit, auto-loading 20MB heaps of steaming garbage that current news sites are. You don't need AMP to get rid of them though. We can appreciate that Google encouraged developers to get rid of bloat AND to opt-in for AMP, but that doesn't make AMP technically superior. I think we should give a critique of ourselves and ask why did we wait for a corporation G to push us to get rid of the bloat we created?

sillysaurus3 9y ago
We can appreciate that Google encouraged developers to get rid of bloat AND to opt-in for AMP, but that doesn't make AMP technically superior. Depends what you mean by technically superior. In terms of benchmarks, AMP pages are lightning fast. Isn't that the only metric that matters?
- redial 9y ago
  On that same metric good old plain HTML is faster.
  - sillysaurus3 9y ago
    Well, sure. But HN is one of the few major websites that uses plain old HTML. At other websites, developers have very little leverage. The people pushing for bloated websites are managers / executives, not devs. Hence, bloat. What can we do about this situation?
    - accountyaccount 9y ago
      > At other websites, developers have very little leverage. The people pushing for bloated websites are managers / executives, not devs. Hence, bloat. I found that AMP helps a lot in that marketing/exec teams see Google pushing AMP and think they need AMP. My company built AMP equivalents, and honestly I wish we could ditch our entire React site for AMP. Instead of an exec demanding a feature, we can now say "AMP doesn't support it." No matter how many times we've set performance budgets, management absolutely tears the budgets down the second we need to implement some flashy new feature (which for some reason is the perceived solution to every sales slump). A group of us has tried to use data against this at least a handful of times, but memories seem to be short lived. Of course we need organizational change, but after pushing a stone up the hill over and over again you essentially just say "fuck it" and let it crush you. Bottom-up corporate change is a fool's errand.
- boramalper 9y ago
  I meant that you could achieve the same by reducing the bloat, applying the best practises etc. To be fair, Google has been encouraging people to do so through the PageSpeed suite for quite a long time... What I found unfair about AMP is Google preloading your AMP-enabled webpage. So that even if your not-AMP-enabled page is equally efficient, an AMP-enabled page would feel faster because Google preloads it in the background. And then there is the fact that Google hosts your own content under their domain, and all other points raised in the article.
  - sillysaurus3 9y ago
    Right, but users don't care about the reasons why it's faster. They just know it's faster. Hence they use AMP, and AMP gains traction. We can say it's unfair, but that's life. If we want to defeat AMP, we have to beat it at its own game. That requires us to come up with an alternative that's equal or faster than AMP. And clearly we've failed as developers to push for non-bloated solutions. It might be possible to create our own version of AMP -- to take the best ideas from AMP and integrate it into some centralized system that isn't controlled by Google. It'd be tough, but the alternative is to let AMP steamroll us. A few rebellious developers aren't going to make much difference in terms of total AMP adoption. Even if the AMP alternative was just a standard way of stripping bloat from websites, that might get us 50% of the way toward beating AMP.
    - enos_feedler 9y ago
      Isn't AMP itself just a standard way of stripping bloat from websites? You could take the AMP library, include it in your web page and do anything you want with it. What is the precise element of AMP you are trying to beat?
      - sillysaurus3 9y ago
        I think people are uncomfortable with the idea of Google controlling every aspect of your website down to the presentation. It'd be better for this to be centralized and standardized independently of Google's tendrils. Part of what makes AMP fast is the preloading, so any AMP competitor would need to tackle that problem. You'd also need to demonstrate that websites rank better if they use your solution. And they should, if Google plays fair. If not, then at least this would be a public demo of that fact.
- nailer 9y ago
  AMP pages hosted at a fast CDN under your own domain name would be technically as good as AMP pages hosted on Google's CDN
- JoshMnem 9y ago
  > In terms of benchmarks, AMP pages are lightning fast. But apparently not faster than doing it yourself. "Pinboard founder Maciej Cegłowski already recreated the Google AMP demo page without the Google AMP JavaScript and, unsurprisingly, it's faster than Google's version."[1] [1] https://www.theregister.co.uk/2017/05/19/open_source_insider_google_amp_bad_bad_bad/ https://www.theregister.co.uk/2017/05/19/open_source_insider...
s73ver 9y ago
Because most of these pages are also corporate owned, and they believed that doing that stuff increased revenues.
- type0 9y ago
  Exactly, and Alex is probably not the only one who thinks that way: "I initially enabled AMP on my site for one reason only – ranking well in Google search results." This reminds me about a friend of mine, his father used to run a restaurant and he enabled "donations" to the mob to get a "better ranking" (or not to suffer worse ranking as it were).
seanwilson 9y ago
> You don't need AMP to get rid of them though. We can appreciate that Google encouraged developers to get rid of bloat AND to opt-in for AMP, but that doesn't make AMP technically superior. I think we should give a critique of ourselves and ask why did we wait for a corporation G to push us to get rid of the bloat we created? AMP (or something like it) makes it easier to push recommended practices to upper management and your team though. A site is either an AMP site or it isn't; you can't selectively ignore some of the recommended practices. If you're not using AMP, you've got to convince your team to follow the recommendations and get management to schedule time for it. For example, it's probably a tough sell to refactor an existing page to remove blocking JavaScript unless you can prove it's going to lead to a big speedup and so on for all recommendations. I'm not saying that it's impossible to do this, just that something opinionated like AMP helps everyone follow recommended practices with less friction. It's similar to having a compiler that gives an error for a recommended practice vs it being in your coding style guide that you have to manually enforce.
- sixstringtheory 9y ago
  While your point is valid, it's a sad state of affairs when engineers and their managers can't even be trusted to make good decisions for themselves, and have to outsource their judgement to Google under the guise of having your hands tied. The irony, it would seem, is that you're actually tying your own hands in other ways. Of course, we could argue till the cows come home about what "good" judgement is :)
  - seanwilson 9y ago
    > While your point is valid, it's a sad state of affairs when engineers and their managers can't even be trusted to make good decisions for themselves, and have to outsource their judgement to Google under the guise of having your hands tied. The irony, it would seem, is that you're actually tying your own hands in other ways. Well, when you've got your project managers, marketing people, coders etc. all trying to optimise for different things, each group doesn't understand each other and team member expertise differs I don't think it's that weird that issues like blocking JavaScript, encoding image sizes in HTML etc. aren't top priority. For website speed, anything that makes it easier to know what the right thing to do is without debate is going to help. Even within a team of experienced web developers it isn't obvious what the best approach is because there's so many options.
prawn 9y ago
I think it's because these bad little decisions make the publisher incrementally more money, and so their managers push for bloat. Eventually they end up squeezing more and more out of the audience subset that hasn't cracked and turned to an alternative.

sillysaurus3 9y ago

We can appreciate that Google encouraged developers to get rid of bloat AND to opt-in for AMP, but that doesn't make AMP technically superior. Depends what you mean by technically superior. In terms of benchmarks, AMP pages are lightning fast. Isn't that the only metric that matters?

redial 9y ago
On that same metric good old plain HTML is faster.
- sillysaurus3 9y ago
  Well, sure. But HN is one of the few major websites that uses plain old HTML. At other websites, developers have very little leverage. The people pushing for bloated websites are managers / executives, not devs. Hence, bloat. What can we do about this situation?
  - accountyaccount 9y ago
    > At other websites, developers have very little leverage. The people pushing for bloated websites are managers / executives, not devs. Hence, bloat. I found that AMP helps a lot in that marketing/exec teams see Google pushing AMP and think they need AMP. My company built AMP equivalents, and honestly I wish we could ditch our entire React site for AMP. Instead of an exec demanding a feature, we can now say "AMP doesn't support it." No matter how many times we've set performance budgets, management absolutely tears the budgets down the second we need to implement some flashy new feature (which for some reason is the perceived solution to every sales slump). A group of us has tried to use data against this at least a handful of times, but memories seem to be short lived. Of course we need organizational change, but after pushing a stone up the hill over and over again you essentially just say "fuck it" and let it crush you. Bottom-up corporate change is a fool's errand.
boramalper 9y ago
I meant that you could achieve the same by reducing the bloat, applying the best practises etc. To be fair, Google has been encouraging people to do so through the PageSpeed suite for quite a long time... What I found unfair about AMP is Google preloading your AMP-enabled webpage. So that even if your not-AMP-enabled page is equally efficient, an AMP-enabled page would feel faster because Google preloads it in the background. And then there is the fact that Google hosts your own content under their domain, and all other points raised in the article.
- sillysaurus3 9y ago
  Right, but users don't care about the reasons why it's faster. They just know it's faster. Hence they use AMP, and AMP gains traction. We can say it's unfair, but that's life. If we want to defeat AMP, we have to beat it at its own game. That requires us to come up with an alternative that's equal or faster than AMP. And clearly we've failed as developers to push for non-bloated solutions. It might be possible to create our own version of AMP -- to take the best ideas from AMP and integrate it into some centralized system that isn't controlled by Google. It'd be tough, but the alternative is to let AMP steamroll us. A few rebellious developers aren't going to make much difference in terms of total AMP adoption. Even if the AMP alternative was just a standard way of stripping bloat from websites, that might get us 50% of the way toward beating AMP.
  - enos_feedler 9y ago
    Isn't AMP itself just a standard way of stripping bloat from websites? You could take the AMP library, include it in your web page and do anything you want with it. What is the precise element of AMP you are trying to beat?
    - sillysaurus3 9y ago
      I think people are uncomfortable with the idea of Google controlling every aspect of your website down to the presentation. It'd be better for this to be centralized and standardized independently of Google's tendrils. Part of what makes AMP fast is the preloading, so any AMP competitor would need to tackle that problem. You'd also need to demonstrate that websites rank better if they use your solution. And they should, if Google plays fair. If not, then at least this would be a public demo of that fact.
nailer 9y ago
AMP pages hosted at a fast CDN under your own domain name would be technically as good as AMP pages hosted on Google's CDN
JoshMnem 9y ago
> In terms of benchmarks, AMP pages are lightning fast. But apparently not faster than doing it yourself. "Pinboard founder Maciej Cegłowski already recreated the Google AMP demo page without the Google AMP JavaScript and, unsurprisingly, it's faster than Google's version."[1] [1] https://www.theregister.co.uk/2017/05/19/open_source_insider_google_amp_bad_bad_bad/ https://www.theregister.co.uk/2017/05/19/open_source_insider...

s73ver 9y ago

Because most of these pages are also corporate owned, and they believed that doing that stuff increased revenues.

type0 9y ago
Exactly, and Alex is probably not the only one who thinks that way: "I initially enabled AMP on my site for one reason only – ranking well in Google search results." This reminds me about a friend of mine, his father used to run a restaurant and he enabled "donations" to the mob to get a "better ranking" (or not to suffer worse ranking as it were).

seanwilson 9y ago

> You don't need AMP to get rid of them though. We can appreciate that Google encouraged developers to get rid of bloat AND to opt-in for AMP, but that doesn't make AMP technically superior. I think we should give a critique of ourselves and ask why did we wait for a corporation G to push us to get rid of the bloat we created? AMP (or something like it) makes it easier to push recommended practices to upper management and your team though. A site is either an AMP site or it isn't; you can't selectively ignore some of the recommended practices. If you're not using AMP, you've got to convince your team to follow the recommendations and get management to schedule time for it. For example, it's probably a tough sell to refactor an existing page to remove blocking JavaScript unless you can prove it's going to lead to a big speedup and so on for all recommendations. I'm not saying that it's impossible to do this, just that something opinionated like AMP helps everyone follow recommended practices with less friction. It's similar to having a compiler that gives an error for a recommended practice vs it being in your coding style guide that you have to manually enforce.

sixstringtheory 9y ago
While your point is valid, it's a sad state of affairs when engineers and their managers can't even be trusted to make good decisions for themselves, and have to outsource their judgement to Google under the guise of having your hands tied. The irony, it would seem, is that you're actually tying your own hands in other ways. Of course, we could argue till the cows come home about what "good" judgement is :)
- seanwilson 9y ago
  > While your point is valid, it's a sad state of affairs when engineers and their managers can't even be trusted to make good decisions for themselves, and have to outsource their judgement to Google under the guise of having your hands tied. The irony, it would seem, is that you're actually tying your own hands in other ways. Well, when you've got your project managers, marketing people, coders etc. all trying to optimise for different things, each group doesn't understand each other and team member expertise differs I don't think it's that weird that issues like blocking JavaScript, encoding image sizes in HTML etc. aren't top priority. For website speed, anything that makes it easier to know what the right thing to do is without debate is going to help. Even within a team of experienced web developers it isn't obvious what the best approach is because there's so many options.

prawn 9y ago

I think it's because these bad little decisions make the publisher incrementally more money, and so their managers push for bloat. Eventually they end up squeezing more and more out of the audience subset that hasn't cracked and turned to an alternative.