5 ms·

(Author here.) Clearly AMP should be replaced, but I argue in the article that prerendering offers better performance even than bare HTML pages with no JavaScri

(Author here.) Clearly AMP should be replaced, but I argue in the article that prerendering offers better performance even than bare HTML pages with no JavaScript. "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.

kuschku 9y ago
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.
- jotto 9y ago
  > 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/ 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."
  - ec109685 9y ago
    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.
- dfabulich 9y ago
  "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.)
  - yorwba 9y ago
    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.
    - digi_owl 9y ago
      There is the Opera Mini way of pre-rendering though. But that requires that you trust Opera to not do something naughty.
  - kuschku 9y ago
    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/ https://quasseldroid.info/, but it's as much as I've got for now)
ravenstine 9y ago
I would certainly prefer some solution that's not centralized or controlled by a giant advertising firm, but prerendering just isn't needed for most webpages. Especially the kind of webpages that are delivering through AMP. 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.
deleted 9y ago
[deleted]

kuschku 9y ago

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.

jotto 9y ago
> 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/ 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."
- ec109685 9y ago
  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.
dfabulich 9y ago
"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.)
- yorwba 9y ago
  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.
  - digi_owl 9y ago
    There is the Opera Mini way of pre-rendering though. But that requires that you trust Opera to not do something naughty.
- kuschku 9y ago
  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/ https://quasseldroid.info/, but it's as much as I've got for now)

ravenstine 9y ago

I would certainly prefer some solution that's not centralized or controlled by a giant advertising firm, but prerendering just isn't needed for most webpages. Especially the kind of webpages that are delivering through AMP. 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.

deleted 9y ago

[deleted]