This small presentation tries to synthesise the behaviour of a web browser's rendering engine as simply as possible. It also proposes a few tricks we've used internally to cope with very resource-demanding webapps.
3. CONTEXT
TECHNOLOGIES
• Rich HTML5/JS Applications
expected to behave like a
native app.
• Basic access to native
features
• Low resources, high-end
display
Joshfire
4. CONTEXT
OBJECTIVES
• High expectations of UX quality
• Heavy content : lengthy videos
or images lists, overall rich UIs
• Animations and multidirectional
nested scrolling
• Cost effectiveness.
Joshfire
5. CONTEXT
VALIDITY
• Most of the concepts described in this presentation
are heavily platform dependent
• Rendering engines do implement the same
specifications but in different forms, and future
evolutions may invalidate this document.
• The current (early 2013) implementations of iOS,
Android, BB10, Microsoft... devices' default web
engines all fit this document
Joshfire
7. WEBAPPS
RUNTIME
• A Native Webview runs the HTML5 App
• Alongside are plugins : camera, sensors, etc.
• The Webview is entirely opaque to the native
runtime
o No (native) memory handling / garbage collection
o
No pre-rendering / dynamic loading / caching of
table cells, list views or scroll views
o
Sparse critical error handling
Joshfire
8. WEBAPPS
RENDERING
• The one Webview's engine renders the whole
app
o We're talking UI here, it is fairly easy to defer
big calculations to native components.
• Its size in memory and its resource consumption
are "unitary"
• It can use the device's processor, RAM and
GPU to achieve its rendering process
• Decreasing the Webview’s (hence, the app)
resource consumption can only be done by
altering the JS / CSS / HTML code which
determines what is rendered and how.
Joshfire
10. RENDERING
WHAT IS IT ?
• The process of
JS
HTML
load, parse
transforming the document
into what we see on our
CSS
Alter
DOM Tree
screen.
• Input : DOM (nodes, CSS)
• Output : Bitmaps to be
Render Tree
& Render Layer Tree
drawn on the browsers'
Rendered Bitmap
canvas
Joshfire
11. RENDERING
THE RENDER TREE
• Ordered tree of visual elements (“renderers”) representing the
DOM elements
• Enables painting the contents in their correct order
• DOM Nodes spawn one or more renderers under certain
conditions only : display mode, visibility...
• Their ordering depends on their box-model settings, sizing rules,
etc.
• Controlling the size and depth of the render tree allows control of
the rendering performances
Joshfire
12. RENDERING
THE RENDER TREE
Check these options in
Chrome&Co. to visualize
the content rectangles
• Each renderer has children renderers
• Each renderer draws a rectangle defined by its computed CSS
properties and its children’s ones.
Joshfire
13. RENDERING
LAYERS !
• The browser then draws a
•
•
•
grid of rectangles.
Controlled-size layers —
hence keeping several
smaller objects in memory
The renderer's rectangles
are split among these
"master" layers/rectangles
These rectangles are then
printed as bitmaps on the
screen, asynchronously.
Note : These layers or tiles are drawn by the GPU
Joshfire
Html content that spans on
the whole page.
Note that the grey element
is split and drawn among 4
tiles
15. RECAP
DOM Tree
• Initially, and whenever the drawing loop ticks :!
o The DOM nodes that have changed spawn
Render Tree
and modify renderers accordingly, creating or
completing the rendering tree!
o Renderers calculate their respective
Render Layer Tree (Grid
and layers)
rectangles and their contents!
o These rectangles are projected onto cells of
GPU
a grid!
o Each cell of the grid is drawn as a bitmap on
the screen by the GPU
Joshfire
17. OPTIM
HARDWARE ACCELERATION
• Tiling may produce weird
•
•
visual effects
o They are drawn on a single
thread, asynchronously.
o Heavier tiles may be
drawn visually significantly
after lighter tiles
To avoid this, we grant large
elements their own "master"
layers !
This is what "accelerating" an
element refers to.
Joshfire
The “accelerated” node is
drawn as one solid
rectangle and is not split
18. OPTIM
USING ACCELERATION
• Some renderers in the render
•
•
tree can be sent "on top"
This happens when an element
undergoes one of several
transformations — such as a
rotation or the application of a
perspective.
These transformations make the
target element and its children
being drawn as a solid, singular
object.
Joshfire
This sample code works for
Safari IOS 5 elements.
The triggers are enginedependent.
-webkit
-transform:
translateZ(0);
!
-webkit
-perspective: 1000;
!
-webkit
-backface
-visibility:
hidden;
19. OPTIM
ACCELERATE ALL THE THINGS ?
• Accelerating key elements can solve most of the
visual quirks linked to the tiling effect
• It also has significant visual drawbacks
o
o
Accelerated fonts are drawn as images and not the
product of vectorial operations, which cancels antialiasing
Most graphics suffer from the transformation that's
applied to the bitmap, resulting in general
blurriness.
blurriness
Joshfire
20. OPTIM
CRASHES. CRASHES EVERYWHERE.
• Each "master layer" (i.e.
•
•
•
accelerated elements and grid tiles
— called "Compositing Layer")
draws resources from the GPU
Limited amount of available
memory
Large quantity of accelerated
items tend to overflow the GPUs'
buffers, causing the device to
crash the application
Accelerating only key elements is
a necessity.
Joshfire
Mo
Mo
Mo
Mo
21. OPTIM
REDRAWS
changes, only the
• When the DOM the modified DOM renderers
associated with
are called
accelerated
• However,their content elements tend to wholly
repaint if
is updated
oThis is due to the fact that the accelerated
element ends up as a "whole" bitmap
Often-changing elements should be
accelerated with caution, they can trigger the
repainting of bigger elements that didn't
need it.
Use chrome's devtools to identify you layers'
behaviour
Regular <div>
Modified
<p>lipsum</p>
o
o
!
that
• Ensuringtick is redraws are notofuselessly heavy
at each
a relevant part optimisation
Joshfire
Accelerated <div>
Modified
<p>lipsum</p>
22. OPTIM
OTHER FACTORS
• Some properties are naturally GPU-heavy
box-shadow, background-size, text-shadow, reflections,
etc.
o Image shims and server preprocessing can make a
significant difference in rendering at the cost of overall
memory or network transit
Using transitions to create sliding or fading effect also
triggers acceleration
o Avoid redraws during animations
o Animate only the strict minimum visually ; hide out of
bound items, detach unimportant nodes, temporarily
disable shadows/other effects
o
•
Joshfire
23. OPTIM
BALANCE
• As usual with most things, it's all about balance
• A limited amount of elements should be accelerated to
maximise user experience improvements.
oAccurately select and accelerate elements that are
expected to be tiled or blinking.
oDetach irrelevant elements from the rendering tree ; use
visibility: hidden; to preserve the layout if needed
oDraw a background in a separate, accelerated element :
fewer redraws and no tiling on one of the visually most
important but technically lightweight element.
!
• If these easily applicable (though less easily identifiable)
methods fail, it's time to approach different angles.
Joshfire
25. STEP BACK
UMA
mobile
• MostAndroidsdevices (iPhones
and
included) do not
provide dedicated GPU
memory
Heavy Code
!
!
• Unified Memory Architecture
• A pool of memory both GPU
and CPU can access
of the
• Heavy solicitationprocessing
memory via CPU
while ( 1 )
!
{
Infinite movie posters list
scrolling
console.log('derp');
}
(calculations, main routine) will
decrease available memory for
the GPU
• ... and vice versa.
Joshfire
SHARED MEMORY
26. STANDARD CHECKLIST
• Free up memory
o
Check for memory leaks (which is another
presentation altogether)
o Unload unnecessary collections / templates / etc.
o Chunks of data can be swapped with localstorage
(slow)
!
• Flatten the DOM
o
Minimize pure-layout nodes
o CSS3 — when applicable — enhances pure css
layouting abilities at minimal cost
o Minimize <a>'s, use data-url="" and events instead
Joshfire
27. DETACHING DOM FRAGMENTS
• DOM subtrees can be kept in memory without being
attached to the main tree
• In this state they stay loaded in memory and parsed
but are excluded from the rendering at every step
• Detaching / Attaching subtrees to the DOM is fairly
fast, as opposed to parsing / loading
• This can be especially effective for scrollview
children...
Joshfire
28. IMITATING TABLEVIEWS
• Long and rich lists are often the core problem in terms
of performance
• It is often necessary to control the quantity of items
•
•
displayed at once ; the way native SDKs manage table
cells.
Progressively detach / attach elements depending on
the position in the scroll view
Preserve the height of the scrollview with a leading
<div> which can be resized
!
• Quite effective when lines are reasonably light
Joshfire
29. RENDERING ON CANVASES
• Dense, graphical areas can be rendered onto <canvas> elements
o
Reduces the number of nodes drastically
o
should act as a bitmap once fully drawn
o
Can abstract large rows/columns of images
• Loses any sense of structure ; no more DOM
o
Can impede basic and essential features
• Support still edgy on some devices
!
• Very efficient for dense graphical areas. Can become expensive
in development time.
Joshfire
