#layout thrashing

[dragoni]

What forces layout/reflow. The comprehensive list.

jank jank jank. What if?

JavaScript had native debounce and throttle functions

browsers automagically handled known jank JS and CSS

remove functions that are performance killers, i.e. getComputedStyle

JavaScript Triggers

All of the below properties or methods, when requested/called in JavaScript, will trigger the browser to synchronously calculate the style and layout*. This is also called reflow or layout thrashing, and is common performance bottleneck.

CSS Triggers

CSS Triggers is a related resource and all about what operations are required to happen in the browser lifecycle as a result of setting/changing a given CSS value. It's a great resource. The above list, however, are all about what forces the purple/green/darkgreen circles synchronously from JavaScript.

More on forced layout

Avoiding layout thrashing — Web Fundamentals

Fixing Layout thrashing in the real world | Matt Andrews

Timeline demo: Diagnosing forced synchronous layouts - Google Chrome

Preventing 'layout thrashing' | Wilson Page

wilsonpage/fastdom

Rendering: repaint, reflow/relayout, restyle / Stoyan

We spent a week making Trello boards load extremely fast. Here’s how we did it. - Fog Creek Blog

Minimizing browser reflow  |  PageSpeed Insights  |  Google Developers

Optimizing Web Content in UIWebViews and Websites on iOS

Accelerated Rendering in Chrome

web performance for the curious

Jank Free

[dragoni]

Rendering without lumpy bits - Jake Archibald - Front-Trends 2013

Slides: speakerdeck.com/jaffathecake/rendering-without-lumps Twitter: twitter.com/jaffathecake

Avoid fixed background images

No magic rules around layers. You just have to try it and test it. What works on the desktop may not work on mobile, i.e translateZ(0)

Learn how the GPU works

[dragoni]

What causes the browser to layout?

When developers realize this problem exists, they rightly want to know all the properties and functions in the DOM APIs that can cause layout. There are a quite a few. I assembled a list in 2010 for WebKit, which I have included below. A harder question to answer, however, is what changes in an element’s style cause its layout to be invalidated. Answering that one often requires trial, error and good tools like the two I mentioned earlier.

Element

clientHeight

clientLeft

clientTop

clientWidth

focus

getBoundingClientRect

getClientRects

innerText

offsetHeight

offsetLeft

offsetParent

offsetTop

offsetWidth

outerText

scrollByLines

scrollByPages

scrollHeight

scrollIntoView

scrollIntoViewIfNeeded

scrollLeft

scrollTop

scrollWidth

MouseEvent

layerX

layerY

offsetX

offsetY

Window

getComputedStyle

scrollBy

scrollTo

scrollX

scrollY

Frame, Document & Image

height

width

Keep in mind that I only list HTML-related objects. I have intentionally ignored WebKit prefixed APIs and SVG objects, but many of those can cause layout as well. One surprising entry isElement.innerText. Maybe I can explain that one in another post. [Update: innerText vs textContent]

[dragoni]

To Do: Jank Busting, Layout Thrashing, Reflow and Performance

Sunday reading

On Layout & Web Performance

Rendering: repaint, reflow/relayout, restyle

innerText vs textContent

Adventures in Jank Busting: Parallax, performance, and the new Flickr Home Page

Video

Rendering without lumpy bits - Jake Archibald - Front-Trends 2013

[dragoni]

Going to give FastDom a spin

Layout Thrashing is when JavaScript violently writes, then reads, from the DOM, multiple times causing document reflows.

FastDom is a small library I wrote to provide a common interface for batching of DOM read/write work. It massively speeds up DOM work using similarrequestAnimationFrame techniques described above.

Implications of using FastDom

By using FastDom you are making all DOM tasks asynchronous, that means you can't always make assumptions as to what state the DOM will be in. Work that was previously sync, may not have completed now it is async.

To work around this I like to use an event system to be more explicit about when work has finished, and responding only when I know DOM work I'm dependent on is complete.

Also we are increasing the amount of code we have to write to effectively get the same amount of work done. Personally I think this is a small price to pay for a dramatic increase in performance.

h/t Hacker News