Or we can simply deliver what the user needs and not include every analytics tracker under the sun, scrolljacking, or shove dozens of images and links in their face to improve "engagement".
"Delivering what the user needs" means performance, too; prerendering simply can't be beat.
The best solution will provide a way to prerender pages without AMP, without iframes, and without violating users' privacy. I claim that Web Packaging is a step in that direction, and even a further step toward re-decentralizing the web.
Shouldn't we be asking ourselves why the hell it takes so long to download and render news articles? Those are generally the kind of pages I see available through AMP. AMP does indeed try to ameliorate that issue, but in totally the wrong way(and without really solving it). Seriously now, the web was designed with the specific purpose of displaying pages of content, and now we should prerender these pages for performance reasons? Something's really wrong here if the answer is to prerender pages as a blanket solution rather than applying applying other performance solutions on a per-need basis.
What are all these sites doing that is so taxing that we need prerendering? How about just delivering text, minimal styling, and some scripts to help lazy-load and download optimized images? Virtually all the sites I see are delivering through AMP could easily do just that. Instead, their sites are littered with trash including multiple versions of jQuery, code that doesn't even execute on the given page but on others, ads galore, custom GA scripts, Mixpanel, Bootstrap, videos, etc. All trash, and poorly implemented trash at that.
Web Packaging IS better, I'll grant you that. I propose that, before we go down that road, our industry take good long look at itself. If all this other optimization that we're doing when we bundle and ship our code isn't working, then we're failing right out of the gate, and we don't need to add another optimization as fuel to the dumpster fire.
Usually you can get the above the fold content rendered in 2x latency + 10ms. That's around 3 to 5 frames.
Prerendering is only useful for sites where either large amounts of data need to be transmitted, or parsing and rendering is slow.
If parsing and rendering is too slow for realtime usage, we need to fix that - not try to circumvent it.
You can get a full JVM up, an entire major codebase parsed, JITedd, profiled, optimized, JITed again, running, and finishing in 40ms.
Yet we're seeing several seconds to parse some JS + HTML + CSS?
That's the true bottleneck.
(There's a reason why AMP, "Accelerated Mobile Pages," rolled out on mobile devices and not desktop.)
But that requires that you trust Opera to not do something naughty.
And prerendering is horrible on mobile networks — data caps are already insanely low, and this is reducing their usabile amount even further.
Personally, I test my websites and apps on a Moto G (2014) on a 2G network throttled to 64kbps, using the worst network available in Germany — and on an emulator giving the phone the entire power of an i7-6700, 16GB ram, and a 100Mbps line — and prerendering provides no meaningful performance benefit in either case.
(I'm currently still trying to improve performance on https://quasseldroid.info/, but it's as much as I've got for now)
Agreed. Many of my leads for https://www.prerender.cloud/ end up not using the service after we discover the root cause of slowness was due to an initial, slow, render-blocking XHR request, or in some cases infinite loops that eventually get cut off.
AMP seems to allow sidestepping root cause performance issues by creating a pure version just for Google - it's a growth hack - "don't bother refactoring your app (which would require overcoming organizational inertia), just make a streamlined version for us."
It'd be awesome if we could, but without the motivation of preferential placement in search results for pages that follow a specific set of rules, publishers will include as many advertising and tracking platforms as they possibly can.
Personally I'm just wondering where the legitimate demand for this (slightly faster page loading) is coming from: Consumers or ad/data networks?
well the issue is that website don't do that
>Consumers or ad/data networks
both ?
> both ?
They are competing objectives, so which has the bias is indicative of business priorities.
Google is never going to do that drastically though .. better the result people are looking for even if the page is slow than something fast but barely related.
I am not sure what else they could do in that regard, and the ecosystem has been moving towards more and more bloat since pretty much the beginning.
I am all hears for other solutions to page speed, especially since AMP is tailored to a specific use case, I just don't know exactly what would be enough of an incentive.