Web fundamentals – performance | Hacker News Reader

Web fundamentals – performance

developers.google.com

Please note they say "debounce" your scroll handlers but they demonstrate a requestAnimationFrame based solution.

Do not confuse this with _.debounce().

In the context lodash/underscore I believe the correct approach is _.throttle the 'scroll', and _.debounce the 'resize' handlers.

https://developers.google.com/web/fundamentals/performance/r... and https://developers.google.com/web/fundamentals/performance/r... are very Chrome-specific advice. A different rendering pipeline will not suffer from these performance gotchas. IMHO, the distinction between "painting" and "compositing", where painting is hugely more expensive, is an artifact of browsers' dependence on suboptimally-performing GPU-assisted (as opposed to GPU-accelerated) vector graphics pipelines [1].

> Want a definitive list of which CSS properties trigger layout, paint, or composite? Check out CSS Triggers.

More overly-Chrome-specific advice. This list of properties varies from browser to browser, and a browser that has off-main-thread layout and/or a unified vector graphics pipeline will not have these gotchas.

> In any case, whether you choose Flexbox or not, you should still try and avoid triggering layout altogether during high pressure points of your application!

Chrome-specific advice again (although, to be fair, this applies to all popular browsers right now). This doesn't apply if your layout is off the main thread.

> If you really want to see JIT in action you should check out IRHydra2 by Vyacheslav Egorov. It shows the intermediate state of JavaScript code when Chrome’s JavaScript engine, V8, is optimizing it.

It's strange to advocate using this and later on to suggest avoiding microbenchmarking JavaScript. In any case, using IRHydra will tune your application to V8, which is a constantly shifting target and is well known for having lots of slow paths that don't necessarily apply to other engines (try/catch leading to a deoptimization being perhaps the most well-known example).

[1]: http://developer.download.nvidia.com/devzone/devcenter/gameg...

Well to defend Google a bit, all performance advice is implementation specific. Whether it be knowing how CPU pipelines and cache lines work or knowing the internals of the JS engine. Heck, anytime you have a design that leaves design decisions to implementors, you're leaving performance on the table.

Today's modern web seems like a race to re-implement an OS on top of an existing OS, badly.

Can we drop EOT formats in font stacks already? IE was the reason for EOT, but all currently supported versions of IE support WOFF.

i've already ditched EOT and the performance improvement is quite significant

I'm a bit surprised. Despite saving a couple of bytes of CSS, where should a performance improvement come from?

EOT are heavy muthafukkas. also, you save a lot by loading WOFF only, what's pretty obvious

Browsers should load only the WOFF file if it is supported though right? Which means if you link to a EOT on a WOFF supporting browser it shouldn't make a difference?

Oddly enough, this website's scrolling behaves horribly on my iPad.

Web fundamentals – test in something other than Chrome on a MacBook Pro.

Reply on news.ycombinator.com