The following is a guest post from Enterprise Architect Matt Ringel, Senior Enterprise Architect Joseph Morrissey and Enterprise Architect Manuel Alvarez.
There are many factors that affect your site performance and one of the less discussed ones is the Rendering Engine. There are a lot of smart people developing browsers, why should you care about how your page renders? The reason is simple: the rendering engine is using rules to paint your site and if you do not follow them, it will penalize you by slowing you down.
The Rendering Engine is a component of the browser in charge of displaying the requested content. The most common rendering engines, Gecko (Mozilla), WebKit (Safari), old versions of Chrome, and newer versions of Opera) and Trident (IE), follow a similar flow:
Figure 1 Rendering engine flow
At a high level, as soon as the HTML has been retrieved it is sent in chunks to the Rendering Engine. The Rendering Engine will parse the HTML and create the DOM, every element of the HTML will have a corresponding entry in the DOM. Styling information from the CSS along with the visual attributes defined for the elements in the HTML are combined to create the render tree. The render tree is then parsed and the exact coordinates/location of each element in the window is calculated. The render tree is traversed and each element is then painted onto the screen.
The process is not as straightforward as it seems. The Rendering Engine follows defined rules to support the dynamic and evolving nature of websites; for example, an script adding stylesheets causes the page to re-flow as coordinates might need to be adjusted. Another example is that if a <SCRIPT> tag is encountered, parsing of the HTML may pause while the script executed. If the script is external, then parsing pauses until the script is pulled from the network.
Matt Ringel and Joseph Morrissey discussed these rules at the Boston Web Performance Meetup in August and they have summarized them here for you:
The One Rule of Rendering
Anything that introduces uncertainty into how the page should be rendered will block rendering until it's resolved.
Rule #1: Scripts Block Parsing
- Consequence: The render chain blocks because there's uncertainty in how the page is rendered.
- Result: If you have a large amount of JS to parse, the browser will sit there parsing it all without putting a pixel to the screen.
- Conclusion: Don't do that. Use async/defer where you can.
Rule #2: Style Sheets Block Rendering
- Posit: Anything that can force a re-flow of content (font changes, different margins for certain elements, etc.) will introduce uncertainty.
- Consequence: Browsers will block rendering a Web page until all external style sheets have been downloaded². (cf. The One Rule).
- Result: If you have style sheets interspersed with content or inline in your document, rendering will stop until they're integrated with the DOM.
- Conclusion: Pare down the amount of CSS you have to what you're using, and put it all in the <head> of the document.
Rule #3: Less Caching, More Problems.
- Posit: The fastest load time is when the browser already has the data.
- Consequence: Origin hits cost time and is distance-based.
- Result: Non-cacheable content creates high variability in page load time.
- Conclusion: Cache browser-side if possible and consider using a CDN.
During the Boston Web Performance Meetup event, our speakers took a look at the top five rendering issues affecting e-Commerce sites by using these rules. You can watch their findings or download the presentation here.
² CSS "print" styles or non-matching media selectors will not block because they're not immediately applicable