Confirm
336
edits
Changes
no edit summary
Section listed first have a higher priority. This means that for example fixing over-invalidation and responsiveness will lead to vastly improved checker-boarding thus should be performed first when possible.
== 1. Over-invalidation ==
'''What does it mean''': Over-invalidation means that we're repainting content that isn't changing. This leads to higher CPU usage & bandwidth.
'''Verification Steps''':
* In the Developer menu turn on 'Flash repainted area'.
* Perform all common interactions with the app. Look for areas of the page that are flashing but where the content hasn't changed. Here are some example* Examples:
{|
|[[File:Invalidation_demo1.gif|center|frame|Good: GIF invalidates every frame, links invalidates on mouse over because of style change. Static content is not repainted]]
|[[File:Invalidation_demo3.gif|center|frame|Bad: Clicking repaints the whole page.]]
|}
* Common issues: Please add any common issues to this list. Currently empty.
== 2. Reflows ==
'''What does it mean''': Reflowing the page is the process of deciding where all the DOM elements will be positioned the page. Any changes to the page that has the potential of effecting the flow of the page will have to reflow the page again. The larger the DOM the longer this can potentially take.
Reflowing is expected as the page/app is being loaded. Once the page is ready, app author should carefully consider what interactions should make changes that can affects the flow of the document. If changes to the page are required they should happen in the '''same frame/refresh tick''' as all changes will be validated at the same time.
'''Sync reflow''' is when the position information (like scrollLeft/scrollTop/clientWidth/clientHeight) of a DOM node is queried when there are pending changes made to the flow of the document. This will prevent reflow from being delayed to the next refresh tick, block all current execution and reflow the document.
Sometimes reflows can be avoided by using CSS transforms that don't affect the flow of the page.
'''Verification Steps''':
* In the Developer menu -> Developer HUD, turn on the 'Reflow' counter.
* Perform all common interactions with the app. Perform reflows only when necessarily i.e. the structure of the app must change.
'''More information''': http://paulrouget.com/e/fxoshud/
== 3. Event loop responsiveness ==
'''What does it mean''': See http://paulrouget.com/e/fxoshud/ for an excellent description. Keeping the event loop delay is important to having a smooth and responsive app.
'''Verification Steps''':
* In the Developer menu -> Developer HUD, turn on the 'Jank' counter.
* Perform all common interactions with the app. Track the 'Jank' number for each of the interaction. When that number is above 10ms your app is at risking of dropping frames. Once that number is 100ms painting will fall behind and input will be delayed. 500ms+ indicate that this interaction will be noticeable jerky
