Hacker News Reader

Comment by kuschku | Hacker News Reader

Prerendering isn't necessary here either.

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.

View on HN

"2x latency" can be pretty slow on noisy cellular networks. Especially with TCP exponential backoff, latency can be a second or more. That's where prerendering really shines.

(There's a reason why AMP, "Accelerated Mobile Pages," rolled out on mobile devices and not desktop.)

Ironically, mobile users are also more likely to be on a plan with a low data cap, so prerendering might not be in the user's best interest.

There is the Opera Mini way of pre-rendering though.

But that requires that you trust Opera to not do something naughty.

That's why you want to transmit all above the fold content before the exponential backoff really kicks in.

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)

> Prerendering is only useful for sites where either large amounts of data need to be transmitted, or parsing and rendering is slow.

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

You aren’t prerendering in the same way google is. They pretender in the browser, so zero latency when you click on an amp link.

Reply on news.ycombinator.com