"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."