• Too general
• Let's focus on this definition...

• Calculation of element's position and size
• Many different layout models
• Messy and hidden inside of the CSS2 specification
  • http://www.w3.org/TR/CSS2/visudet.html
• New layout models that are very clear and easy to understand.
  • Flexbox (http://www.w3.org/TR/css3-flexbox/)
  • Multi-column (http://www.w3.org/TR/css3-multicol/)
  • Grid (http://www.w3.org/TR/css3-grid-layout/)

• Most average web sites have huge numbers of nodes to layout
• Yahoo.co.jp had 2153 nodes (text and elements) (And that's optimized!)

• Normal Flow
  • position: static
  • position: relative
• Floating (float: left/right)
• Absolute
  • position: absolute
  • position: fixed

• The simplest
• Create boxes for containers (like div)
• Flow the boxes vertically, one box per row
• Flow content (line-boxes) horizontally inside boxes

• Move from normal position by x,y
• All relative layouts first do a static layout

• Positions elements on the left or right side of another float element or the current block container
• Very difficult to plan and understand
• Can be slow or fast

• Positions elements relative to the current containing block, in CSS units, to an exact location
• Messy if not managed properly
• Layout is fast

• A subclass of regular absolute
• Always positions relative to the viewport (screen)
• Layout is very fast

• Fixed > absolute > static > relative > float
• Float can be faster or slower
• As you go deep in the DOM tree, static, relative and float get slower

Which of the above properties cause a lot of calculations do happen in the background?

All of them

These properties all calculate their own size (padding edge or border edge).

All of their children's sizes are also be calculated.

• If you know the value won't change, cache it and use it
• If you access them in the middle of changing other properties, it is possible to force a reflow

• A common thing to do since the DHTML days

        var element, body = document.body;
        for (var i = 0; i < 500; i++) {
          element = document.createElement('div');
          body.appendChild(element);
          element.style.width = element.style.height = '40px';
        }
      

• There are a couple things you should not do here

        var element, body = document.body;
        var fragment = document.createDocumentFragment();
        for (var i = 0; i < 500; i++) {
          element = document.createElement('div');
          element.style.width = element.style.height = '40px';
          fragment.appendChild(element);
        }
        body.appendChild(fragment);
      

• Edit all properties before calling appendChild
• Use a DocumentFragment (http://dom.spec.whatwg.org/#interface-documentfragment)

• They used to be way faster than anything else
• With recent optimizations in browsers, they are roughly the same speed as the normal appendChild
• Elements inside a DocumentFragment have no layout box
  • Almost all values in CSS are uninitialized or 0
    • Try it out with window.getComputedStyle!
  • Impossible to make a reflow or paint happen

There are many articles on the Internet saying that it is faster to remove the group of nodes you are about to edit from the DOM tree (removeChild), edit all the nodes (avoiding reflow), and re-insert them back in to the same place in the DOM tree.

• This used to be true and still is in some cases
• It is now false in all situations that I have personally tested that use GPU mode for rendering
  • Like transform: translate3d(x,y,z)
  • Now-a-days, the browser will get slower due to a paint that occurs from re-adding the nodes

• Fixed > absolute > static > relative > float
• Remember JavaScript properties can be slow just by accessing them
• Cache computed values if possible
• Edit element properties before adding them
• Use DocumentFragment
• Do not use the Remove/Re-add Rule in GPU mode

• After layout, browsers need to draw elements to the screen
• Chrome/WebKit calls this painting
• Calculates what elements are visible now and draw them

• Viewing (loading) the page the first time
• Scrolling the page
• Hiding an element and re-showing it again in GPU mode
• Changing visual properties of an element
• Possibily when a decendant (or possibly ancestor) element changes

• In Chrome, open up the developer tools
• Switch to the Timeline panel
• Hit the record button at the bottom
• Play with your web site
• Return to the developer tools and hit the record button again to stop recording
• Look at the data!

Let's see what happens when we try out the Remove/Re-add Rule!

• Painting is difficult to optimize
• Check the developer tools timeline feature
• Avoid shadow related CSS

• Taking painted elements and mixing them in the correct order on the screen
• Mostly a GPU thing
• Looks at information like z-index, transform's Z properties, opacity and layout layers

• After a paint
• After position-related properties change on an element

• A method to render everything to the screen
• Usage of 3D APIs (OpenGL, DirectX, etc) for everything
• In GPU mode, browsers translate a web page in to a 3D scene!

• Using a 3D related CSS property
• Using HTML Canvas in a modern browser
• Depending on platform and browser flags, always
• In the future, probably always!

• Every element is at least a single rectangle with a texture applied to it (CSS style)
• It should always be used if possible
• Unless you hit some of GPU mode's weaknesses...

The Remove/Re-add Rule and GPU mode with transform: translate3d instead of left and top!

Without the Remove/Re-add Rule with translate3d!

• Use GPU mode if possible
• Imagine all objects are textures in memory
• Test for devices that have bugs in GPU mode
• Do not use the Remove/Re-add Rule in GPU mode
• Remember that textures are destroyed when their element is removed from the DOM

• An element for drawing
• Provides 2D and 3D API's (Canvas and WebGL)
• Useful for games and interesting web sites

• A simple implementation would directly draw pixels as you do commands
• Drawing pixels is slow
• Instead amazing technologies exist to speed things up

• GPU mode
• Canvases exist as a texture in the GPU
• Canvas commands get translated in to some 3D command to be run on the GPU

• Imagine fillRect(x, y, w, h) being a rect polygon filled with the current fillStyle colour and/or pattern texture
• Transforming paths and images is very fast
• Drawing paths is not awesomely fast
• drawImage is awesomely fast

• Chrome optimization for Canvas called deferred 2d Canvas
• Takes GPU commands from accelerated Canvas and waits to execute them
• Executes them when that canvas is used
• Many optimizations like merging drawing commands together possible
• Transparent to the developer!

• No reason not to use drawImage
• Literally copying pixels directly in the GPU. Can't get any faster

Use fillStyle and bezierCurveTo each frame to draw all 500 hearts

Cache all 500 hearts as individual Canvases and drawImage them

• Modern Canvas is actually 3D
• Uses GPU mode
• Transforming paths and images is very fast
• Drawing paths is not as fast as drawImage
• Always use drawImage
• Browsers are getting smarter and faster every day

• What about the infamous requestAnimationFrame?
• You should use it in real world projects!
• Allows you to render only when the browser will actually render to the screen
• setTimeout will render faster than what is actually displayed
• Optimized so that render/drawing related operations run faster than in normal execution

• Overview of how to make many parts of the browser faster
• How to make layout a bit faster, especially in JavaScript
• Overview of what painting is and how to debug it for speed
• Overview of what compositing and GPU mode is and how to work with it
• How to use HTML Canvas (2D) a faster