site/developers/the-rendering-critical-path/index.md - website - Git at Google

 ---
 breadcrumbs:
 - - /developers
   - For Developers
 page_name: the-rendering-critical-path
 title: The Rendering Critical Path
 ---

 author: wiltzius@

 [TOC]

 ### Rendering Architecture in Brief

 To understand the symptoms and potential causes of jank, it's important to have
 a basic understanding of the browser's rendering pipeline. This article will
 briefly describe that pipeline assuming knowledge of the web platform but no
 knowledge of how the rendering engine works, with links to relevant design docs
 for more info.

 This article is adapted from a similar section in [Using Frame Viewer to Bust
 Jank](/developers/how-tos/trace-event-profiling-tool/using-frameviewer). It goes
 into greater detail, but doesn't cover any examples. See that document for a
 more illustrated version of this process, which annotates a trace of an example
 style modification.

 We'll focus on how the page is rendered *after* page load -- that is, how the
 browser handles screen updates in response to user input and JavaScript changes
 to the DOM. Rendering when loading a page is slightly different, as compromises
 to visual completeness are often made in order to get some content to appear
 faster; this is out of scope for this document which will focus on *interactive*
 rendering performance.

 Much more detail about the specifics of how rendering inside of Blink works
 (i.e. the style, layout, and Blink paint systems), as well as a (somewhat dated)
 discussion of how it might evolve, can be found in the [Rendering Pipeline
 doc](https://docs.google.com/a/chromium.org/document/d/1wYNK2q_8vQuhVSWyUHZMVPGELzI0CYJ07gTPWP1V1us/edit#heading=h.6cdy1o585rsa).
 This document is intended to be more descriptive, higher-level, and include the
 related input and compositing systems.

 ### The Critical Rendering Path

 After loading, the page changes in response to two inputs: user interaction
 mediated by the user agent (default pressed button styles, scrolling,
 pinch/zooming, etc) and updates to the DOM made by JavaScript. From there, a
 cascade of effects through several rendering sub-systems eventually produces new
 pixels on the user’s screen.

 The main subsystems are:

     Input handling \[technically not related to graphics per se, but
     nevertheless critical for many interactions\]

     Parsing, which turns a chunk of HTML into DOM nodes

     Style, which resolves CSS onto the DOM

     Layout, which figures out where DOM elements end up relative to one another

     Paint setup, sometimes referred to as recording, which converts styled DOM
     elements into a display list (SkPicture) of drawing commands to paint later,
     on a per-layer basis

     Painting, which converts the SkPicture of drawing commands into pixels in a
     bitmap somewhere (either in system memory or on the GPU if using Ganesh)

     Compositing, which assembles all layers into a final screen image

     and, less obviously, the presentation infrastructure responsible for
     actually pushing a new frame to the OS (i.e. the browser UI and its
     compositor, the GPU process which actually communicates with the GL driver,
     etc).

 As an example, updating the innerHTML of a DOM element that’s visible on-screen
 will trigger work in every one of the systems above. In bad cases any one of
 them can cost tens of milliseconds (or more), meaning every one of them can be
 considered a liability for staying within frame budget -- that is, any one of
 these stages can be responsible for dropping frames and causing jank.

 ### Browser Thread Architecture

 The browser has multiple threads, and because of the dependencies implied in the
 above pipeline which thread an operation runs on matters a lot when it comes to
 identifying performance bottlenecks. Style, layout, and some paint setup
 operations run on the renderer’s main thread, which is the same place that
 JavaScript runs. Parsing of new HTML from the network gets in own thread (in
 most cases), as does compositing and painting; however parsing of e.g. innerHTML
 is currently performed synchronously on the main thread.

 Keep in mind that JavaScript is single threaded and does not yield by default,
 which means that JavaScript events, style, and layout operations will block one
 another. That means if e.g. the style system is running, Javascript can’t
 receive new events. More obviously, it also means that other JavaScript events
 (such as a timer firing, or an XHR success callback, etc) will block JS events
 that may be very timely -- like touch events. NB this essentially means
 applications responding to touch input must consider the JavaScript main thread
 the application’s UI thread, and not block it for more than a few milliseconds.

 The ordering of these events is often unfortunate, since currently Blink has a
 simple FIFO queue for all event types. The [Blink Scheduler
 project](https://docs.google.com/a/chromium.org/document/d/11N2WTV3M0IkZ-kQlKWlBcwkOkKTCuLXGVNylK5E2zvc/edit)
 is seeking to add a better notion of priorities to this event queue. The
 scheduler will never be able to actually shorten non-yielding events, though, so
 is only part of the solution.

 It's worth noting here that scrolling is “special” in that it happens outside of
 the main JavaScript context, and scroll positions are asynchronously reported
 back to the main thread and updated in the DOM. This prevents janky scrolling
 even if the page executes a lot of JavaScript, but it can get in the way if the
 page is well-behaved and wants to respond to scrolling.

 It's also worth noting that the pipeline above isn’t strictly hierarchically
 ordered -- that is, sometimes you can update style without needing to re-lay-out
 anything and without needing to repaint anything. A key example is CSS
 transforms, which don’t alter layout and hence can skip directly from style
 resolution (e.g. changing the transform offset) to compositing if the necessary
 content is already painted. The below sections note which stages are optional.
 Different types of screen updates require exercising different stages in the
 pipeline. One way to keep animations inexpensive is to avoid stages of this
 pipeline altogether. The following sections cover a few common examples.

 Lastly, note that user interactions that the browser handles, rather than the
 application, are largely unexceptional: clicking a button changes its style
 (adding pseudo-classes) and those style changes need to be resolved and later
 stages of the pipeline run (e.g. the depressed button state needs to be painted,
 and then the page needs to be re-composited with that new painted content).

 ### Scrolling

 Updating the viewport's scroll position has been designed to be as cheap as
 possible, relying heavily on the compositing step and its associated GPU
 machinery.

 In the simple case, when the user tries to scroll a page events flow through the
 browser as follows:

 1.  Input events are delivered to the browser process's UI thread
 2.  The browser's gesture detector processing the input stream decides
             that the user is attempting to scroll the page content
 3.  Input events are sent directly from the browser UI thread to the
             compositor thread in the Renderer process (notably bypassing the
             Renderer's main thread, where JavaScript and Blink live)
     1.  Optionally, if there are touch event or mousewheel handlers
                 registered on the part of the page being scrolled these events
                 are added to Blink's event queue and the compositor will block
                 further work on this frame until it receives an acknowledgment
                 that those events have run and have not been preventDefault'd
 4.  The compositor updates layer positions relative to the viewport
     1.  Optionally, if newly exposed parts of the page have not been
                 painted in previous frames, the compositor paints them.
         1.  Optionally, if newly exposed parts of the page have not been
                     *recorded* in previous frames, the compositor asks Blink to
                     record new sections of DOM
 5.  The compositor issues GL commands to the GPU process to recomposite
             painted textures on the GPU with the updated layer positions in step
             4
 6.  The compositor asynchronously sends a message to the Renderer's main
             thread with updated scroll position information.
     1.  Optionally at this point updated JavaScript onScroll events can
                 be fired by Blink

 This flow skips a lot of detail, which is covered in the [Accelerated
 Compositing design
 doc](/developers/design-documents/gpu-accelerated-compositing-in-chrome) if
 you're curious.

 Important notes:

 *   In the common case, only compositing and the GPU infrastructure are
             exercised in producing a new frame during scrolling; all other steps
             are skipped.
 *   Registering touch event handlers (see step 3.1) add those JavaScript
             touch event handlers as a synchronous step on the critical scrolling
             path.
 *   The compositor will almost always still produce frames even if its
             waiting on Blink for new content (e.g. for touch event handler
             acknowledgments in step 3.1, or for new recordings of DOM content in
             4.1.1). Instead of the content it's trying to produce, it'll put up
             either old content that's already been painted in previous frames
             *or* if there's no such content available it'll put up a
             checkerboard pattern.

 ### Modifying Style of Existing DOM

 Modifying the style of existing DOM elements from JavaScript (whether in
 response to input or not) will exercise most of the rendering pipeline, although
 it'll skip parsing. Depending on the styles modified, it may also skip layout
 and painting. Paul Irish and Paul Lewis have written a [good article on
 html5rocks](http://www.html5rocks.com/en/tutorials/speed/high-performance-animations/)
 covering which styles affect which pipeline stages.

 Here's an outline of how modifying style propagates through the browser:

 1.  JavaScript runs, modifying some style (setting inline style,
             modifying a class list, etc). This may happen in a
             requestAnimationFrame callback, in an input event, in a timer
             callback, or anywhere else.
 2.  When the compositor next asks Blink to paint part of the document,
             Blink will optionally recalculate style on any part of the DOM that
             it may need to paint.
     *   This style recalculation is theoretically scoped to only the
                 part of the DOM tree whose style is dirty, but in practice often
                 includes the entire document (the Dev Tools timeline will show
                 how many DOM nodes were operated on in each recalc style event).
 3.  Optionally, if the style recalculation has dirtied the layout of any
             elements that may need to be painted, layout is run on the relevant
             DOM subtree(s).
     *   Notice the "may" in that sentence, since before layout is run
                 and final element positions are known it isn't possible to tell
                 what will be where. In practice, layouts often occur on the
                 entire document. The Dev Tools timeline will show the root of
                 the tree under operation for each layout event.
 4.  Optionally, if any composited layer properties have changed (new
             composited layers, or new transforms or opacity of existing
             composited layers) the main-thread copy of the compositor layer tree
             is updated.
 5.  Now whatever part of the document the compositor requested be
             painted can actually be painted, but note that this doesn't actually
             fill in pixels -- Blink here paints into a display list (currently
             an SkPicture).
     *   This is step 6 in the overview of main subsystems above, often
                 called SkPicture recording.
 6.  New SkPictures and the updated compositor layer tree are transferred
             from the main thread to the compositor thread (the so-called
             "commit")
 7.  The compositor prioritizes all content tiles and decides if any
             tiles need to be re-rastered (i.e. actually painted) to put up this
             new content
 8.  The compositor then paints these tiles
     1.  With software painting, this is done on a software raster worker
                 thread
     2.  With Ganesh aka GPU rasterization, this is done on the
                 compositor thread itself, converting the display list into GL
                 commands
 9.  The compositor then generates the GL commands to produce a new frame
             and hands this frame's information to its parent compositor in the
             browser
 10. The browser compositor issues the GL commands for a new frame
             including the browser UI and the child compositor's content

 Important notes:

 *   It's possible to trigger style recalculation or layout outside of
             the rendering pipeline by reading back CSS properties that are
             lazily computed. In the worst case script can enter a write / read
             loop where it sets a style, reads a property that forces synchronous
             layout or style recalculation, and then repeats this process. We
             call this layout thrashing; Wilson Page has written a [good article
             on the
             subject](http://wilsonpage.co.uk/preventing-layout-thrashing/).

 This flow summarizes a lot of detail, again covered in the [Accelerated
 Compositing design
 doc](/developers/design-documents/gpu-accelerated-compositing-in-chrome).

 ### Adding new DOM

 Adding new DOM or replacing a DOM subtree requires parsing the new DOM. Whether
 this parsing happens synchronously on the main thread or asynchronously
 off-thread depends on how the DOM is inserted. An incomplete listing:

 *   XHR responses are currently processed on the main thread;
             crbug.com/402261 tracks work to make it asynchronous
 *   Setting the srcdoc of an iframe is asynchronous, see
             crbug.com/308321 for the work that made this possible
 *   data: URLs are always asynchronously parsed;
             https://codereview.chromium.org/210253003 for the work that made
             this possible
 *   During page load, most parsing is done asynchronously using the
             threaded parser

 After parsing, rendering proceeds roughly as above in "modifying style of
 existing DOM"
	---
	breadcrumbs:
	- - /developers
	- For Developers
	page_name: the-rendering-critical-path
	title: The Rendering Critical Path
	---

	author: wiltzius@

	[TOC]

	### Rendering Architecture in Brief

	To understand the symptoms and potential causes of jank, it's important to have
	a basic understanding of the browser's rendering pipeline. This article will
	briefly describe that pipeline assuming knowledge of the web platform but no
	knowledge of how the rendering engine works, with links to relevant design docs
	for more info.

	This article is adapted from a similar section in [Using Frame Viewer to Bust
	Jank](/developers/how-tos/trace-event-profiling-tool/using-frameviewer). It goes
	into greater detail, but doesn't cover any examples. See that document for a
	more illustrated version of this process, which annotates a trace of an example
	style modification.

	We'll focus on how the page is rendered after page load -- that is, how the
	browser handles screen updates in response to user input and JavaScript changes
	to the DOM. Rendering when loading a page is slightly different, as compromises
	to visual completeness are often made in order to get some content to appear
	faster; this is out of scope for this document which will focus on interactive
	rendering performance.

	Much more detail about the specifics of how rendering inside of Blink works
	(i.e. the style, layout, and Blink paint systems), as well as a (somewhat dated)
	discussion of how it might evolve, can be found in the [Rendering Pipeline
	doc](https://docs.google.com/a/chromium.org/document/d/1wYNK2q_8vQuhVSWyUHZMVPGELzI0CYJ07gTPWP1V1us/edit#heading=h.6cdy1o585rsa).
	This document is intended to be more descriptive, higher-level, and include the
	related input and compositing systems.

	### The Critical Rendering Path

	After loading, the page changes in response to two inputs: user interaction
	mediated by the user agent (default pressed button styles, scrolling,
	pinch/zooming, etc) and updates to the DOM made by JavaScript. From there, a
	cascade of effects through several rendering sub-systems eventually produces new
	pixels on the user’s screen.

	The main subsystems are:

	Input handling \[technically not related to graphics per se, but
	nevertheless critical for many interactions\]

	Parsing, which turns a chunk of HTML into DOM nodes

	Style, which resolves CSS onto the DOM

	Layout, which figures out where DOM elements end up relative to one another

	Paint setup, sometimes referred to as recording, which converts styled DOM
	elements into a display list (SkPicture) of drawing commands to paint later,
	on a per-layer basis

	Painting, which converts the SkPicture of drawing commands into pixels in a
	bitmap somewhere (either in system memory or on the GPU if using Ganesh)

	Compositing, which assembles all layers into a final screen image

	and, less obviously, the presentation infrastructure responsible for
	actually pushing a new frame to the OS (i.e. the browser UI and its
	compositor, the GPU process which actually communicates with the GL driver,
	etc).

	As an example, updating the innerHTML of a DOM element that’s visible on-screen
	will trigger work in every one of the systems above. In bad cases any one of
	them can cost tens of milliseconds (or more), meaning every one of them can be
	considered a liability for staying within frame budget -- that is, any one of
	these stages can be responsible for dropping frames and causing jank.

	### Browser Thread Architecture

	The browser has multiple threads, and because of the dependencies implied in the
	above pipeline which thread an operation runs on matters a lot when it comes to
	identifying performance bottlenecks. Style, layout, and some paint setup
	operations run on the renderer’s main thread, which is the same place that
	JavaScript runs. Parsing of new HTML from the network gets in own thread (in
	most cases), as does compositing and painting; however parsing of e.g. innerHTML
	is currently performed synchronously on the main thread.

	Keep in mind that JavaScript is single threaded and does not yield by default,
	which means that JavaScript events, style, and layout operations will block one
	another. That means if e.g. the style system is running, Javascript can’t
	receive new events. More obviously, it also means that other JavaScript events
	(such as a timer firing, or an XHR success callback, etc) will block JS events
	that may be very timely -- like touch events. NB this essentially means
	applications responding to touch input must consider the JavaScript main thread
	the application’s UI thread, and not block it for more than a few milliseconds.

	The ordering of these events is often unfortunate, since currently Blink has a
	simple FIFO queue for all event types. The [Blink Scheduler
	project](https://docs.google.com/a/chromium.org/document/d/11N2WTV3M0IkZ-kQlKWlBcwkOkKTCuLXGVNylK5E2zvc/edit)
	is seeking to add a better notion of priorities to this event queue. The
	scheduler will never be able to actually shorten non-yielding events, though, so
	is only part of the solution.

	It's worth noting here that scrolling is “special” in that it happens outside of
	the main JavaScript context, and scroll positions are asynchronously reported
	back to the main thread and updated in the DOM. This prevents janky scrolling
	even if the page executes a lot of JavaScript, but it can get in the way if the
	page is well-behaved and wants to respond to scrolling.

	It's also worth noting that the pipeline above isn’t strictly hierarchically
	ordered -- that is, sometimes you can update style without needing to re-lay-out
	anything and without needing to repaint anything. A key example is CSS
	transforms, which don’t alter layout and hence can skip directly from style
	resolution (e.g. changing the transform offset) to compositing if the necessary
	content is already painted. The below sections note which stages are optional.
	Different types of screen updates require exercising different stages in the
	pipeline. One way to keep animations inexpensive is to avoid stages of this
	pipeline altogether. The following sections cover a few common examples.

	Lastly, note that user interactions that the browser handles, rather than the
	application, are largely unexceptional: clicking a button changes its style
	(adding pseudo-classes) and those style changes need to be resolved and later
	stages of the pipeline run (e.g. the depressed button state needs to be painted,
	and then the page needs to be re-composited with that new painted content).

	### Scrolling

	Updating the viewport's scroll position has been designed to be as cheap as
	possible, relying heavily on the compositing step and its associated GPU
	machinery.

	In the simple case, when the user tries to scroll a page events flow through the
	browser as follows:

	1. Input events are delivered to the browser process's UI thread
	2. The browser's gesture detector processing the input stream decides
	that the user is attempting to scroll the page content
	3. Input events are sent directly from the browser UI thread to the
	compositor thread in the Renderer process (notably bypassing the
	Renderer's main thread, where JavaScript and Blink live)
	1. Optionally, if there are touch event or mousewheel handlers
	registered on the part of the page being scrolled these events
	are added to Blink's event queue and the compositor will block
	further work on this frame until it receives an acknowledgment
	that those events have run and have not been preventDefault'd
	4. The compositor updates layer positions relative to the viewport
	1. Optionally, if newly exposed parts of the page have not been
	painted in previous frames, the compositor paints them.
	1. Optionally, if newly exposed parts of the page have not been
	recorded in previous frames, the compositor asks Blink to
	record new sections of DOM
	5. The compositor issues GL commands to the GPU process to recomposite
	painted textures on the GPU with the updated layer positions in step
	4
	6. The compositor asynchronously sends a message to the Renderer's main
	thread with updated scroll position information.
	1. Optionally at this point updated JavaScript onScroll events can
	be fired by Blink

	This flow skips a lot of detail, which is covered in the [Accelerated
	Compositing design
	doc](/developers/design-documents/gpu-accelerated-compositing-in-chrome) if
	you're curious.

	Important notes:

	* In the common case, only compositing and the GPU infrastructure are
	exercised in producing a new frame during scrolling; all other steps
	are skipped.
	* Registering touch event handlers (see step 3.1) add those JavaScript
	touch event handlers as a synchronous step on the critical scrolling
	path.
	* The compositor will almost always still produce frames even if its
	waiting on Blink for new content (e.g. for touch event handler
	acknowledgments in step 3.1, or for new recordings of DOM content in
	4.1.1). Instead of the content it's trying to produce, it'll put up
	either old content that's already been painted in previous frames
	or if there's no such content available it'll put up a
	checkerboard pattern.

	### Modifying Style of Existing DOM

	Modifying the style of existing DOM elements from JavaScript (whether in
	response to input or not) will exercise most of the rendering pipeline, although
	it'll skip parsing. Depending on the styles modified, it may also skip layout
	and painting. Paul Irish and Paul Lewis have written a [good article on
	html5rocks](http://www.html5rocks.com/en/tutorials/speed/high-performance-animations/)
	covering which styles affect which pipeline stages.

	Here's an outline of how modifying style propagates through the browser:

	1. JavaScript runs, modifying some style (setting inline style,
	modifying a class list, etc). This may happen in a
	requestAnimationFrame callback, in an input event, in a timer
	callback, or anywhere else.
	2. When the compositor next asks Blink to paint part of the document,
	Blink will optionally recalculate style on any part of the DOM that
	it may need to paint.
	* This style recalculation is theoretically scoped to only the
	part of the DOM tree whose style is dirty, but in practice often
	includes the entire document (the Dev Tools timeline will show
	how many DOM nodes were operated on in each recalc style event).
	3. Optionally, if the style recalculation has dirtied the layout of any
	elements that may need to be painted, layout is run on the relevant
	DOM subtree(s).
	* Notice the "may" in that sentence, since before layout is run
	and final element positions are known it isn't possible to tell
	what will be where. In practice, layouts often occur on the
	entire document. The Dev Tools timeline will show the root of
	the tree under operation for each layout event.
	4. Optionally, if any composited layer properties have changed (new
	composited layers, or new transforms or opacity of existing
	composited layers) the main-thread copy of the compositor layer tree
	is updated.
	5. Now whatever part of the document the compositor requested be
	painted can actually be painted, but note that this doesn't actually
	fill in pixels -- Blink here paints into a display list (currently
	an SkPicture).
	* This is step 6 in the overview of main subsystems above, often
	called SkPicture recording.
	6. New SkPictures and the updated compositor layer tree are transferred
	from the main thread to the compositor thread (the so-called
	"commit")
	7. The compositor prioritizes all content tiles and decides if any
	tiles need to be re-rastered (i.e. actually painted) to put up this
	new content
	8. The compositor then paints these tiles
	1. With software painting, this is done on a software raster worker
	thread
	2. With Ganesh aka GPU rasterization, this is done on the
	compositor thread itself, converting the display list into GL
	commands
	9. The compositor then generates the GL commands to produce a new frame
	and hands this frame's information to its parent compositor in the
	browser
	10. The browser compositor issues the GL commands for a new frame
	including the browser UI and the child compositor's content

	Important notes:

	* It's possible to trigger style recalculation or layout outside of
	the rendering pipeline by reading back CSS properties that are
	lazily computed. In the worst case script can enter a write / read
	loop where it sets a style, reads a property that forces synchronous
	layout or style recalculation, and then repeats this process. We
	call this layout thrashing; Wilson Page has written a [good article
	on the
	subject](http://wilsonpage.co.uk/preventing-layout-thrashing/).

	This flow summarizes a lot of detail, again covered in the [Accelerated
	Compositing design
	doc](/developers/design-documents/gpu-accelerated-compositing-in-chrome).

	### Adding new DOM

	Adding new DOM or replacing a DOM subtree requires parsing the new DOM. Whether
	this parsing happens synchronously on the main thread or asynchronously
	off-thread depends on how the DOM is inserted. An incomplete listing:

	* XHR responses are currently processed on the main thread;
	crbug.com/402261 tracks work to make it asynchronous
	* Setting the srcdoc of an iframe is asynchronous, see
	crbug.com/308321 for the work that made this possible
	* data: URLs are always asynchronously parsed;
	https://codereview.chromium.org/210253003 for the work that made
	this possible
	* During page load, most parsing is done asynchronously using the
	threaded parser

	After parsing, rendering proceeds roughly as above in "modifying style of
	existing DOM"