Hacker News Reader

Comment by nbpname | Hacker News Reader

This feature is really cool, however the ratio of parse-time and compile-time improvement is not always meaningful to end users. I would be curious to see the absolute & relative load-time gains.

When I was benchmarking Firefox on the same feature [1], back in November 2017, I noticed that reddit loads very little JavaScript that any improvement on it does not matter.

Also, I wish that the benchmark website domains were not truncated, such as "http://www.", and better distinguish websites such as "http://reddit." (for http://reddit.musicplayer.io) as opposed to "http://www.reddit." (for http://www.reddit.com).

[1] https://blog.mozilla.org/javascript/2017/12/12/javascript-st...

View on HN

Websites are built to fit within the existing constraints of the web platform. It's important to look beyond what sites are doing today and instead look at what they cannot do. It's basically this story for web performance [1]. Here you're suggesting profiling and optimizing website designs that 'survive' and make it production but you're failing to observe designs and sites that don't make ship because of performance issues and you're just trying to optimize against cases where the designs survive.

In general parse-time and compile-time is meaningful enough that large websites are spending a considerable amount of effort and energy playing 'code golf' to keep JS size down otherwise engagement will suffer.

[1] https://medium.com/@penguinpress/an-excerpt-from-how-not-to-...

They mention near the end of the article that it improved overall page loads (time to interactive) on Android 1-2%

Fairly small, but all improvement is obviously welcome.

I'd argue that as long as it doesn't increase CPU load, those 1-2% are very worth it on mobile. It's potentially 2% battery saved.

Only if your phone is spending all its time parsing javascript, and maybe 1% (being generous) of its CPU time is spent doing that for a JS heavy page. So 1% of 1%. Really not much at all.

1-2% on a large scale is pretty significant. If each request on average takes, say, a second, and is then reduced by 1-2%, that'd be 990ms. 10ms saved per request.

Let's say that on average, 5 uncached pages are opened per day per chrome-mobile user. I don't feel like looking up the total amount of Chrome-mobile users, let's estimate that at 500 million.

5 page loads * 500,000,000 users * 10 ms = 25000000000ms per day saved, that's 289 days of page loading saved on a global scale per day.

I don't personally think measuring the improvement in terms of time is very interesting, it's very hard to interpret, but each ms of loading takes up a certain percentage of your battery, the amount of electricity saved daily on a global scale because of an improvement of 1-2% is fairly significant.

Facebook.com, LinkedIn.com, and Google Sheets ship ~1MB of JS compressed for their main pages, which is 5-10 MB of JS uncompressed. So JS parsing time ends up taking hundreds of milliseconds on initial load.

And of course, people want to build even richer experiences (live streaming, 360 media, etc) so there is a lot of appetite for loading more code in the same amount of time.

Reply on news.ycombinator.com