> 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.
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 :)
> 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.
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.