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.
Of course, we could argue till the cows come home about what "good" judgement is :)
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.
Depends what you mean by technically superior. In terms of benchmarks, AMP pages are lightning fast. Isn't that the only metric that matters?
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.
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.
The technical work has been done for years. The problem is that currently the only decision which matters is Google's and they're treating performance concerns as a way to use other people's content to bolster their own brand. The only two ways that seems possible to change are either convincing Google to reverse that policy or getting more people to use non-Google search engines, which seems unlikely given the huge quality lead they have over Bing, DDG, etc.
What is the precise element of AMP you are trying to beat?
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.
What can we do about this situation?
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.
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...
"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).
I run an adblocker and use reading mode frequently. I do not usually suffer any issues with ads even without AMP. It is solving a problem I do not have and creating more problems in the process.
What Google should be doing is encouraging the right designs, instead of pushing their own walled-garden design.
If Google ranked load-time/page-bloat much heavier in their algorithm, and started punishing bad pages, then sites would adjust.
I currently see very little action from Google in this direction.
1. i.e. the top n results will have rel=dns-prefetch tags hoisted into the search result, the top result (or visible/hover/etc.) will have the first rel=preload html/style/script tags hoisted.
Firefox on mobile supports extensions, so you can use UBlock Origin / UMatrix. Also the built-in reader mode makes most sites a much better experience.
Unfortunately this isn't true on iOS as far as I can tell.
True, but it doesn't improve page load times.
Actually I see these on an AMP page too.
I have no idea what a sustainable solution would look like. Something similar to the Brave browser that was actually agreed upon by site owners and users alike, where site owners would turn off all of the BS for people that paid cash?
Of course, that doesn't touch the problem of people using crazy over-the-top, poorly optimized front-end stacks for things that could easily be accomplished with a regular web server and a smattering of Ajax.
I'm trying to figure out how to make JS blocking available to normal end users. Why should users have to put up with the current shitty situation when a simple, technical solution is available that doesn't involve Google or anyone else whose intentions are not aligned with users' intentions? The main challenge is fixing the UI so that it can be used by the least computer literate users.
Instead of AMP a better solution could be to add buttons to browser to disable JS/CSS/Web Fonts (the most useless innovation)/Cookies and let the user decide what they want to see.
My companies entire site JS, React and many other modules included, is 220kb over the wire (gzipped).
Site bloat is a thing but it's due to bad developer practice not frameworks or libraries
The single worst offender though for bloat are 3rd party ad networks - Google included/especially. The site often has minimal control over what is put in ad slots.
Start pushing against google to improve their standards for ad payloads and you'll see a massive improvement.
Railing against ads themselves however is, sadly, not too helpful
The only realistic way that I see forward are the ad networks (and this includes Google) setting lower maximum payload sizes for ads. Obviously sites can push back on quality and size but it's a hard metric to track consistently given how ad networks serve things.
The fact is: ad-based model just puts the burden on those most susceptible to advertising. It's similar enough to funding schools through state lotteries in that the money comes from somewhere or the results go underfunded, and if you accept state-run lotteries or anything that looks even slightly like today's ad-based internet, you are talking about a funding source that is deeply and fundamentally unethical.
See also: mobile. You have to totally gameify things to get micropayments to work.
I mean, if you want that for websites, sure... but if you think clickbait is bad now...
On the other hand, micropayment would freeze out poor people.
That's not something that is going to be fixed by changing library.
Try clicking any of the god-awful clickbait AMP pages shared on Facebook, for example.
The web has become bloated, where people use heavy JS frameworks like React to make their blog and then load 5MB of ad JS to load 10MB autoplaying videos. I dream of a day when static site generators like Hugo and Jekyll are the norm. Let's flex our muscles and make that happen and show the world that AMP is good but openness is better.