> 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).
Re:Web fundamentals – performance
by ksk on Monday February 15, 2016 @02:35PM
(#11105372)
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.
Re:Web fundamentals – performance
by chain18 on Monday February 15, 2016 @05:58PM
(#11106704)
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?
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.
> 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...
Today's modern web seems like a race to re-implement an OS on top of an existing OS, badly.
Web fundamentals – test in something other than Chrome on a MacBook Pro.