Google Developers Web

  • Bytes → characters → tokens → nodes → object model.
  • Conversion: The browser reads the raw bytes of HTML off the disk or network, and translates them to individual characters based on specified encoding of the file (for example, UTF-8).
  • Tokenizing: The browser converts strings of characters into distinct tokens — as specified by the W3C HTML5 standard; for example, “<html>”, “<body>” — and other strings within angle brackets. Each token has a special meaning and its own set of rules.
  • Lexing: The emitted tokens are converted into “objects,” which define their properties and rules.
  • DOM construction: Because the HTML markup defines relationships between different tags (some tags are contained within other tags) the created objects are linked in a tree data structure that also captures the parent-child relationships defined in the original markup: the HTML object is a parent of the body object, the body is a parent of the paragraph object, and so on.
  • The final output of this entire process is the Document Object Model (DOM) of our simple page, which the browser uses for all further processing of the page.
  • DOM and CSSOM are independent data structures.
  • The CSSOM and DOM trees are combined into a render tree, which is then used to compute the layout of each visible element and serves as an input to the paint process that renders the pixels to screen.
  • Render tree contains only the nodes required to render the page. Some nodes are not visible (for example, script tags, meta tags, and so on), and are omitted since they are not reflected in the rendered output. Some nodes are hidden via CSS and are also omitted from the render tree.
  • With the render tree in place, we can proceed to the “layout” stage. Layout computes the exact position and size of each object within the viewport of the device. The output of the layout process is a “box model,” which precisely captures the exact position and size of each element within the viewport: all of the relative measurements are converted to absolute pixels on the screen.
  • Now that we know which nodes are visible, and their computed styles and geometry, we can pass this information to the final stage, which converts each node in the render tree to actual pixels on the screen. This step is often referred to as “painting” or “rasterizing.”
  • 1)Process HTML markup and build the DOM tree. 2)Process CSS markup and build the CSSOM tree. 3)Combine the DOM and CSSOM into a render tree. 4)Run layout on the render tree to compute geometry of each node. 5)Paint the individual nodes to the screen.
  • FOUC:Flash of Unstyled Content
  • The browser blocks rendering until it has both the DOM and the CSSOM.
  • CSS is a render blocking resource. Get it to the client as soon and as quickly as possible to optimize the time to first render.
  • Note that “render blocking” only refers to whether the browser has to hold the initial rendering of the page on that resource. In either case, the browser still downloads the CSS asset, albeit with a lower priority for non-blocking resources.
  • JavaScript execution blocks on the CSSOM. What if the browser hasn’t finished downloading and building the CSSOM when we want to run our script? The answer is simple and not very good for performance: the browser delays script execution and DOM construction until it has finished downloading and constructing the CSSOM.
  • JavaScript blocks DOM construction unless explicitly declared as async.
  • When the HTML parser encounters a script tag, it pauses its process of constructing the DOM and yields control to the JavaScript engine; after the JavaScript engine finishes running, the browser then picks up where it left off and resumes DOM construction.
  • In the case of an external JavaScript file the browser must pause to wait for the script to be fetched from disk, cache, or a remote server, which can add tens to thousands of milliseconds of delay to the critical rendering path.
  • Adding the async keyword to the script tag tells the browser not to block DOM construction while it waits for the script to become available, which can significantly improve performance.
  • The Critical Request Chain is a concept from the Critical Rendering Path (CRP) optimization strategy.
  • Minimizing the number of critical resources: eliminating them, deferring their download, marking them as async, and so on.
  • Optimizing the number of critical bytes to reduce the download time (number of roundtrips).
  • Optimizing the order in which the remaining critical resources are loaded: downloading all critical assets as early as possible to shorten the critical path length.
  • DevTools conveniently reports the time for the DOMContentLoaded event at the bottom (216ms), which also corresponds to the blue vertical line. The gap between the end of the HTML download and the blue vertical line (DOMContentLoaded) is the time it takes the browser to build the DOM tree — in this case, just a few milliseconds.
  • When we talk about the critical rendering path we are typically talking about the HTML markup, CSS, and JavaScript. Images do not block the initial render of the page — although we should also try to get the images painted as soon as possible.
  • The load event (also known as onload), is blocked on the image. Recall that the onload event marks the point at which all resources that the page requires have been downloaded and processed; at this point, the loading spinner can stop spinning in the browser.
  • Adding external CSS and JavaScript files adds two extra requests to our waterfall, all of which the browser dispatches at about the same time.
  • We need both the DOM and CSSOM to build the render tree.
  • Because the page also contains a parser blocking JavaScript file, the domContentLoaded event is blocked until the CSS file is downloaded and parsed: because the JavaScript might query the CSSOM, we must block the CSS file until it downloads before we can execute JavaScript.
  • It doesn’t matter if the JavaScript is inlined or external, because as soon as the browser hits the script tag it blocks and waits until the CSSOM is constructed.
  • Avoid CSS imports:The imported CSS resources are discovered only after the CSS stylesheet with the @import rule itself is received and parsed.
  • In DevTools, click the Main Menu then select More tools > Remote devices.
  • Clicks are translated into taps, firing proper touch events on the device.
  • To simulate a pinch gesture, hold Shift while dragging.
  • Screencasts only display page content. Transparent portions of the screencast represent device interfaces, such as the Chrome omnibox, the Android status bar, or the Android keyboard.
  • Screencasts negatively affect frame rates. Disable screencasting while measuring scrolls or animations to get a more accurate picture of your page’s performance.
  • If your Android device screen locks, the content of your screencast disappears.
  • Suppose that your site uses a third-party JavaScript library that only works on the whitelisted domain chrome.devtools. So, you create an entry in your hosts file on your development machine to map this domain to localhost (i.e. 127.0.0.1 chrome.devtools). After setting up custom domain mapping and port forwarding, you’ll be able to view the site on your Android device at the URL chrome.devtools.
  • To map a custom domain you must run a proxy server on your development machine.
One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.