
Web fundamentals – performance - dreampeppers99
https://developers.google.com/web/fundamentals/performance/?hl=en
======
PhrosTT
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.

------
pcwalton
[https://developers.google.com/web/fundamentals/performance/r...](https://developers.google.com/web/fundamentals/performance/rendering/simplify-
paint-complexity-and-reduce-paint-areas?hl=en) and
[https://developers.google.com/web/fundamentals/performance/r...](https://developers.google.com/web/fundamentals/performance/rendering/stick-
to-compositor-only-properties-and-manage-layer-count?hl=en) 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...](http://developer.download.nvidia.com/devzone/devcenter/gamegraphics/files/opengl/gpupathrender.pdf)

~~~
ksk
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.

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

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

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

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

~~~
chain18
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?

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

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

