Rendering: repaint, reflow/relayout, restyle

December 17th, 2009. Tagged: CSS, JavaScript, performance

2010 update:
Lo, the Web Performance Advent Calendar hath moved

Dec 17 This post is part of the 2009 performance advent calendar experiment. Stay tuned for the articles to come.

UPDATE: Ukraine translation here.

Nice 5 "R" words in the title, eh? Let's talk about rendering - a phase that comes in the Life of Page 2.0 after, and sometimes during, the waterfall of downloading components.

So how does the browser go about displaying your page on the screen, given a chunk of HTML, CSS and possibly JavaScript.

The rendering process

Different browsers work differently, but the following diagram gives a general idea of what happens, more or less consistently across browsers, once they've downloaded the code for your page.

Rendering process in the browser

  • The browser parses out the HTML source code (tag soup) and constructs a DOM tree - a data representation where every HTML tag has a corresponding node in the tree and the text chunks between tags get a text node representation too. The root node in the DOM tree is the documentElement (the <html> tag)
  • The browser parses the CSS code, makes sense of it given the bunch of hacks that could be there and the number of -moz, -webkit and other extensions it doesn't understand and will bravely ignore. The styling information cascades: the basic rules are in the User Agent stylesheets (the browser defaults), then there could be user stylesheets, author (as in author of the page) stylesheets - external, imported, inline, and finally styles that are coded into the style attributes of the HTML tags
  • Then comes the interesting part - constructing a render tree. The render tree is sort of like the DOM tree, but doesn't match it exactly. The render tree knows about styles, so if you're hiding a div with display: none, it won't be represented in the render tree. Same for the other invisible elements, like head and everything in it. On the other hand, there might be DOM elements that are represented with more than one node in the render tree - like text nodes for example where every line in a <p> needs a render node. A node in the render tree is called a frame, or a box (as in a CSS box, according to the box model). Each of these nodes has the CSS box properties - width, height, border, margin, etc
  • Once the render tree is constructed, the browser can paint (draw) the render tree nodes on the screen

The forest and the trees

Let's take an example.

HTML source:

  <title>Beautiful page</title>
    Once upon a time there was 
    a looong paragraph...
  <div style="display: none">
    Secret message
  <div><img src="..." /></div>

The DOM tree that represents this HTML document basically has one node for each tag and one text node for each piece of text between nodes (for simplicity let's ignore the fact that whitespace is text nodes too) :

documentElement (html)
            [text node]
            [text node]

The render tree would be the visual part of the DOM tree. It is missing some stuff - the head and the hidden div, but it has additional nodes (aka frames, aka boxes) for the lines of text.

root (RenderView)
            line 1
	    line 2
	    line 3

The root node of the render tree is the frame (the box) that contains all other elements. You can think of it as being the inner part of the browser window, as this is the restricted area where the page could spread. Technically WebKit calls the root node RenderView and it corresponds to the CSS initial containing block, which is basically the viewport rectangle from the top of the page (0, 0) to (window.innerWidth, window.innerHeight)

Figuring out what and how exactly to display on the screen involves a recursive walk down (a flow) through the render tree.

Repaints and reflows

There's always at least one initial page layout together with a paint (unless, of course you prefer your pages blank :) ). After that, changing the input information which was used to construct the render tree may result in one or both of these:

  1. parts of the render tree (or the whole tree) will need to be revalidated and the node dimensions recalculated. This is called a reflow, or layout, or layouting. (or "relayout" which I made up so I have more "R"s in the title, sorry, my bad). Note that there's at least one reflow - the initial layout of the page
  2. parts of the screen will need to be updated, either because of changes in geometric properties of a node or because of stylistic change, such as changing the background color. This screen update is called a repaint, or a redraw.

Repaints and reflows can be expensive, they can hurt the user experience, and make the UI appear sluggish.

What triggers a reflow or a repaint

Anything that changes input information used to construct the rendering tree can cause a repaint or a reflow, for example:

  • Adding, removing, updating DOM nodes
  • Hiding a DOM node with display: none (reflow and repaint) or visibility: hidden (repaint only, because no geometry changes)
  • Moving, animating a DOM node on the page
  • Adding a stylesheet, tweaking style properties
  • User action such as resizing the window, changing the font size, or (oh, OMG, no!) scrolling

Let's see a few examples:

var bstyle =; // cache
bstyle.padding = "20px"; // reflow, repaint
bstyle.border = "10px solid red"; // another reflow and a repaint
bstyle.color = "blue"; // repaint only, no dimensions changed
bstyle.backgroundColor = "#fad"; // repaint
bstyle.fontSize = "2em"; // reflow, repaint
// new DOM element - reflow, repaint

Some reflows may be more expensive than others. Think of the render tree - if you fiddle with a node way down the tree that is a direct descendant of the body, then you're probably not invalidating a lot of other nodes. But what about when you animate and expand a div at the top of the page which then pushes down the rest of the page - that sounds expensive.

Browsers are smart

Since the reflows and repaints associated with render tree changes are expensive, the browsers aim at reducing the negative effects. One strategy is to simply not do the work. Or not right now, at least. The browser will setup a queue of the changes your scripts require and perform them in batches. This way several changes that each require a reflow will be combined and only one reflow will be computed. Browsers can add to the queued changes and then flush the queue once a certain amount of time passes or a certain number of changes is reached.

But sometimes the script may prevent the browser from optimizing the reflows, and cause it to flush the queue and perform all batched changes. This happens when you request style information, such as

  1. offsetTop, offsetLeft, offsetWidth, offsetHeight
  2. scrollTop/Left/Width/Height
  3. clientTop/Left/Width/Height
  4. getComputedStyle(), or currentStyle in IE

All of these above are essentially requesting style information about a node, and any time you do it, the browser has to give you the most up-to-date value. In order to do so, it needs to apply all scheduled changes, flush the queue, bite the bullet and do the reflow.

For example, it's a bad idea to set and get styles in a quick succession (in a loop), like:

// no-no! = el.offsetLeft + 10 + "px";

Minimizing repaints and reflows

The strategy to reduce the negative effects of reflows/repaints on the user experience is to simply have fewer reflows and repaints and fewer requests for style information, so the browser can optimize reflows. How to go about that?

  • Don't change individual styles, one by one. Best for sanity and maintainability is to change the class names not the styles. But that assumes static styles. If the styles are dynamic, edit the cssText property as opposed to touching the element and its style property for every little change.
    // bad
    var left = 10,
        top = 10; = left + "px";  = top  + "px";
    // better 
    el.className += " theclassname";
    // or when top and left are calculated dynamically...
    // better += "; left: " + left + "px; top: " + top + "px;";
  • Batch DOM changes and perform them "offline". Offline means not in the live DOM tree. You can:
    • use a documentFragment to hold temp changes,
    • clone the node you're about to update, work on the copy, then swap the original with the updated clone
    • hide the element with display: none (1 reflow, repaint), add 100 changes, restore the display (another reflow, repaint). This way you trade 2 reflows for potentially a hundred
  • Don't ask for computed styles excessively. If you need to work with a computed value, take it once, cache to a local var and work with the local copy. Revisiting the no-no example from above:
    // no-no!
    for(big; loop; here) { = el.offsetLeft + 10 + "px";  = el.offsetTop  + 10 + "px";
    // better
    var left = el.offsetLeft,
        top  = el.offsetTop
        esty =;
    for(big; loop; here) {
        left += 10;
        top  += 10;
        esty.left = left + "px";  = top  + "px";
  • In general, think about the render tree and how much of it will need revalidation after your change. For example using absolute positioning makes that element a child of the body in the render tree, so it won't affect too many other nodes when you animate it for example. Some of the other nodes may be in the area that needs repainting when you place your element on top of them, but they will not require reflow.


Only about a year ago, there was nothing that can provide any visibility into what's going on in the browser in terms of painting and rendering (not that I am aware of, it's of course absolutely possible that MS had a wicked dev tool no one knew about, buried somewhere in MSDN :P ). Now things are different and this is very, very cool.

First, MozAfterPaint event landed in Firefox nightlies, so things like this extension by Kyle Scholz showed up. mozAfterPaint is cool, but only tells you about repaints.

DynaTrace Ajax and most recently Google's SpeedTracer (notice two "trace"s :) ) are just excellent tools for digging into reflows and repaints - the first is for IE, the second for WebKit.

Some time last year Douglas Crockford mentioned that we're probably doing some really stupid things in CSS we don't know about. And I can definitely relate to that. I was involved in a project for a bit where increasing the browser font size (in IE6) was causing the CPU go up to 100% and stay like this for 10-15 minutes before finally repainting the page.

Well, the tools are now here, we don't have excuses any more for doing silly things in CSS.

Except, maybe, speaking of tools..., wouldn't it be cool if the Firebug-like tools showed the render tree in addition to the DOM tree?

A final example

Let's just take a quick look at the tools and demonstrate the difference between restyle (render tree change that doesn't affect the geometry) and reflow (which affects the layout), together with a repaint.

Let's compare two ways of doing the same thing. First, we change some styles (not touching layout) and after every change, we check for a style property, totally unrelated to the one just changed.

bodystyle.color = 'red';
tmp = computed.backgroundColor;
bodystyle.color = 'white';
tmp = computed.backgroundImage;
bodystyle.color = 'green';
tmp = computed.backgroundAttachment;

Then the same thing, but we're touching style properties for information only after all the changes:

bodystyle.color = 'yellow';
bodystyle.color = 'pink';
bodystyle.color = 'blue';
tmp = computed.backgroundColor;
tmp = computed.backgroundImage;
tmp = computed.backgroundAttachment;

In both cases, these are the definitions of the variables used:

var bodystyle =;
var computed;
if (document.body.currentStyle) {
  computed = document.body.currentStyle;
} else {
  computed = document.defaultView.getComputedStyle(document.body, '');

Now, the two example style changes will be executed on click on the document. The test page is actually here - restyle.html (click "dude"). Let's call this restyle test.

The second test is just like the first, but this time we'll also change layout information:

// touch styles every time
bodystyle.color = 'red';
bodystyle.padding = '1px';
tmp = computed.backgroundColor;
bodystyle.color = 'white';
bodystyle.padding = '2px';
tmp = computed.backgroundImage;
bodystyle.color = 'green';
bodystyle.padding = '3px';
tmp = computed.backgroundAttachment;
// touch at the end
bodystyle.color = 'yellow';
bodystyle.padding = '4px';
bodystyle.color = 'pink';
bodystyle.padding = '5px';
bodystyle.color = 'blue';
bodystyle.padding = '6px';
tmp = computed.backgroundColor;
tmp = computed.backgroundImage;
tmp = computed.backgroundAttachment;

This test changes the layout so let's called it "relayout test", the source is here.

Here's what type of visualization you get in DynaTrace for the restyle test.


Basically the page loaded, then I clicked once to execute the first scenario (requests for style info every time, at about 2sec), then clicked again to execute the second scenario (requests for styles delayed till the end, at about 4sec)

The tool shows how the page loaded and the IE logo shows onload. Then the mouse cursor is over the rendering activity following the click. Zooming into the interesting area (how cool is that!) there's a more detailed view:


You can clearly see the blue bar of JavaScript activity and the following green bar of rendering activity. Now, this is a simple example, but still notice the length of the bars - how much more time is spent rendering than executing JavaScript. Often in Ajax/Rich apps, JavaScript is not the bottleneck, it's the DOM access and manipulation and the rendering part.

OK, now running the "relayout test", the one that changes the geometry of the body. This time check out this "PurePaths" view. It's a timeline plus more information about each item in the timeline. I've highlighted the first click, which is a JavaScript activity producing a scheduled layout task.


Again, zooming into the interesting part, you can see how now in addition to the "drawing" bar, there's a new one before that - the "calculating flow layout", because in this test we had a reflow in addition to the repaint.


Now let's test the same page in Chrome and look at the SpeedTracer results.

This is the first "restyle" test zoomed into the interesting part (heck, I think I can definitely get cused to all that zooming :) ) and this is an overview of what happened.


Overall there's a click and there's a paint. But in the first click, there's also 50% time spent recalculating styles. Why is that? Well, this is because we asked for style information with every change.

Expanding the events and showing hidden lines (the gray lines were hidden by Speedtracer because they are not slow) we can see exactly what happened - after the first click, styles were calculated three times. After the second - only once.


Now let's run the "relayout test". The overall list of events looks the same:


But the detailed view shows how the first click caused three reflows (because it asked for computed style info) and the second click caused only one reflow. This is just excellent visibility into what's going on.


A few minor differences in the tools - SpeedTracer didn't show when the layout task was scheduled and added to the queue, DynaTrace did. And then DynaTrace didn't show the details of the difference between "restyle" and "reflow/layout", like SpeedTracer did. Maybe simply IE doesn't make a difference between the two? DynaTrace also didn't show three reflows instead of one in the different change-end-touch vs. change-then-touch tests, maybe that's how IE works?

Running these simple examples hundreds of times also confirms that for IE it doesn't matter if you request style information as you change it.

Here's some more data points after running the tests with enough repetitions:

  • In Chrome not touching computed styles while modifying styles is 2.5 times faster when you change styles (restyle test) and 4.42 times faster when you change styles and layout (relayout test)
  • In Firefox - 1.87 times faster to refrain from asking computed styles in restyle test and 1.64 times faster in the relayout test
  • In IE6 and IE8, it doesn't matter

Across all browsers though changing styles only takes half the time it takes to change styles and layout. (Now that I wrote it, I should've compared changing styles only vs. changing layout only). Except in IE6 where changing layout is 4 times more expensive then changing only styles.

Parting words

Thanks very much for working through this long post. Have fun with the tracers and watch out for those reflows! In summary, let me go over the different terminology once again.

  • render tree - the visual part of the DOM tree
  • nodes in the render tree are called frames or boxes
  • recalculating parts of the render tree is called reflow (in Mozilla), and called layout in every other browser, it seems
  • Updating the screen with the results of the recalculated render tree is called repaint, or redraw (in IE/DynaTrace)
  • SpeedTracer introduces the notion of "style recalculation" (styles without geometry changes) vs. "layout"

And some more reading if you find this topic fascinating. Note that these reads, especially the first three, are more in depth, closer to the browser, as opposed to closer to the developer which I tried to do here.

Tell your friends about this post: Facebook, Twitter, Google+

83 Responses

  1. Excellent post! It’s really helpful to move forward using these tools.

    Thanks again!

  2. Good post, reflow and repaints are most of time forgotten when optimizing websites. This just shows how easily debug these cases.


  3. Hi Stoyan

    The reflow bookmarklet made by Lindsay Simon should be mentionned. It helps evaluating the performance cost of reflows :

  4. Another great article, Stoyan. I’ll mention that the pain of layout varies by browser and by what is changed. For example, in IE, changing padding takes 4x longer than changing font-size. But your advice (grouping style changes together, doing them offline, etc.), address this. Great advice. Can you add it to YSlow?

  5. Great article and great series, Stoyan! I was initially confused by this line in the What Triggers a Reflow or Repaint section:

    “Think of the render tree – if you fiddle with a node way down the tree that is a direct descendant of the body, then you’re probably not invalidating a lot of other nodes.”

    Thinking you were referring to a node that is very deep into the tree, not one that is toward the end of the tree at or near the root level. My initial interpretation didn’t make much sense :) The key here is to understand that invalidating a node’s layout affects the layout of the node’s ancestors as well as its next direct sibling (I suspect at a minimum). In the case of the change to a header element, the next sibling is invalidated which then invalidates *its* next sibling and so on. Not so for an element later in the tree.

    I’m super excited about the new tools, and look forward to testing a few things:
    1. whether modifying cssText incurs a reflow even if you set/modify a property that would typically only trigger a repaint (e.g. += ‘;color:#f00′;) — I suspect yes

    2. does IE reflow when modifying elements styled with display: none (counter to your point in Minimizing repaints and reflows; the dynaTrace blog suggests it does)

    3. is there a performance benefit to modifying cssText from a stylesheet rule vs updating specific style properties on that rule directly. And whether any change to any stylesheet rule will incur a full page reflow — I suspect yes

  6. Stoyan,

    great post and love your article series. Some comments from my side. If you understand you correctly you say that hidden elements are not part of the rendering tree. However we noticed that they can also cause reflows, so they are part of the rendering tree then. I am talking about IE here. What do you think?

    Some words also on your dynaTrace traces (so much trace here :) ) dynaTrace is hooking the IE API and we are also hooking the CSS layout methods. If they do not show up, they are not called, however they are there (and used).

    I also checked the touch() sample regarding the number of drawing action. In dynaTrace there are four such actions. In the middle pane of the PurePath you can see them. However they are aggregated by default. However this seems to be only the case when you execute it for the first time. Which is … strange. I will check on that with our developers to get more details out what IE is really doing here.

    - Alois

  7. Repaint, reflow/relayout, restyle…

    前两天看到这么一篇文章《Rendering: repaint, reflow/relayout, restyle》,讲了一些有关浏览器渲染的原理和页面优化原则,个人感觉很有用,这里总结下。

    1. 解析HTML代…

  8. Hi!

    What an interesting post! That’s very nice.
    I have a question about what you said on “changing a node offline” :

    “hide the element with display: none (1 reflow, repaint), add 100 changes, restore the display (another reflow, repaint). This way you trade 2 reflows for potentially a hundred”

    What if we hide this element with visibility:hidden? If it causes only a repaint, it should be even faster, no?
    Maybe it’s not enough for the node to be “offline” and this trick doesn’t work at all…


  9. Thanks, Lionel! Visibility hidden will keep the element in the tree, so for example if you change padding (geometry change) it affects the other nodes so in needs reflow+repaint.

    BTW, turns out display:none still triggers reflow in IE (as per the comments from dynatrace and Luke and this follow-up post), so best way to go offline seems to be with a clone of the node you want to update or a document fragment

  10. Olivvv, thanks, that’s a good link. There on that page I found another even more interesting link about layout in Mozilla:

    It contains some more detailed diagrams of what I pictured in the post.

  11. @Alois, @Luke – that’s disappointing about display: none in IE.

    I did some more tests to look into some of Luke’s questions here:

  12. Thanks V1, Stoimen, Steve!

    BTW, everybody – check Steve’s slides from Web 2 expo for some reflow comparisons in browsers.

  13. And I want to publicly thank Steve for sending me email with typos to fix in this post! :)

  14. Great article! I’ve enjoyed it a lot. :D

  15. [...] профилировании производительности, очень рекомендую статью Стояна Стефанова на эту тему. Метки: css, firebug, float, html, repaint, web inspector, [...]

  16. [...] new game show: "Will it reflow?"by Stoyan Stefanov Intrigued by Luke Smith‘s comment and also Alois Reitbauer‘s comment on the previous post about rendering I did some more [...]

  17. [...] Rendering: repaint, reflow/relayout, restyle (Stoyan Stefanov) [...]

  18. Hi there. I have found and read this article by following a link at Sergey Chikuyonok’s blog. I can only thank you for the work done here and for further enhancing my understanding of how modern web browsers work.

  19. On the topic of Facebook… this guy made a website with awesome Facebook statuses… a few of em are surprisingly creative lol

  20. [...] Reflow and repainting issues were next on the performance menu, which in essence means that you shouldn’t touch the DOM too much and instead create long HTML strings and inject them into hidden elements before showing them. [...]

  21. [...] Reflow and repainting issues were next on the performance menu, which in essence means that you shouldn’t touch the DOM too much and instead create long HTML strings and inject them into hidden elements before showing them. [...]

  22. Hi Stoyan,

    Many thanks for this interesting article and your recent JavaScript patterns book – the section on DOM patterns brought me here.

    Hopefully this is a straight forward question for you to answer….my understanding is that the browser is going to process my JavaScript function and not repaint or reflow until it is complete (unless, see below). After my function is finished, it will make whatever changes to the display it needs to based on what my script did to the DOM. The caveat here is if my script makes the browser reflow/repaint internally by asking for computed style information….?

    The reason I ask is that I often see comments on blogs suggesting that every time I add an element to a live DOM node, that causes a reflow. If I had to add 10 divs into the DOM, and I added them one at a time using document.appendChild() would the browser not optimise this and only take account of the changes my script had made to the DOM after the script had finished ? Maybe this is an over simplistic example – but would this not be just as fast as using a doc fragment – since the browser is going to batch my DOM changes anyway ? So document.appendChild() called 10 times in a script does not cause 10 reflows at all – but only the one after my script completes… ?

    Many thanks,

  23. Hey Steven, thanks for your kind words!

    The browsers will optimize and batch changes, true. But you’re still better off batching yourself. Most of the times there won’t be any difference, but you never know what else might happen that will require the browser to flush the queue of batched changes and redraw/repaint. Imagine some timeout kicks in, or a window resize, or an ad/widget decides to do something.

  24. Hi Stoyan,

    You’re welcome – i enjoy the book, and often use it as a reference. After reading Doug Crockford’s book i thought there was a gap in the market for a patterns book specifically for JavaScript. Most people turn to the Gang of Four book when it comes to patterns, but i found that without strong typing some of them are pointless or just don’t work , so your book is interesting in that explores patterns that work in JavaScript and make use of prototypes, first class functions and closures. I think it is also nice for younger programmers who will use JavaScript a lot in the careers to have a patterns book tailored for JavaScript.

    To go back to the topic above…I had (again perhaps mistakenly or over simplistically) thought that the browser basically operated in an event loop. A single thread takes events off the queue (JavaScript functions), runs them to completion, then updates the UI if need be. So it follows that any function using a document fragment to update the DOM is going to affect the UI (since the last thing it does it put the fragment into the live DOM) and after the function completes, the thread stops running javascript and updates the UI. So. the window resize, or the timeout would both be events stuck on the queue waiting for my function to finish. How does using a document fragment help us if this is the situation ? Of course, maybe it is not the situation at all, in which case I am more than happy to be corrected :)

  25. [...] content of the CSS, so forget it. Plus it checks for current styles in a timeout meaning it will flush the reflow queue and can be potentially slow. The slower the CSS to arrive, the more reflows. So, really, forget [...]

  26. [...] Stoyan comes in with the explanation and then Dmitri with the codesearch link that shows what calls can affect things: ELEMENT clientHeight, clientLeft, clientTop, clientWidth, focus(), getBoundingClientRect(), getClientRects(), innerText, offsetHeight, offsetLeft, offsetParent, offsetTop, offsetWidth, outerText, scrollByLines(), scrollByPages(), scrollHeight, scrollIntoView(), scrollIntoViewIfNeeded(), scrollLeft, scrollTop, scrollWidth [...]

  27. [...] browser has to flush the queue and perform all DOM affecting activities before each read. Thanks to Stoyan for explaining this and helping us to write horrifically performant javascript like the following [...]

  28. When there’s only a single style change which is better? Using cssText or individual style property?

    document.getElementById(‘myid’).style.cssText += “;color:#999;”; OR
    document.getElementById(‘myid’).style.color = “#999″;

  29. [...] DOM Performance” that’s listed below. He alludes to Stoyan Stefanov’s brilliant reflow/relayout article, which is the end-all-be-all discussion on the [...]

  30. [...] Reflow, Repaint … zeker eens checken [...]

  31. [...] Detailed explanation on reflow and repaint [...]

  32. [...] nahm Bezug auf einen Artikel von Tony Gentilcore, welcher sich z.T. wieder auf Grundlagen von Stoyan Stefanov bezog (die Grafik ist wirklich toll für das [...]

  33. [...] általa is hivatkozott Rendering: repaint, reflow/relayout, restyle cikk pedig mélyrehatóan és részletekre kiterjedően veszi végig, mi a különbség a repaint [...]

  34. [...] Reflow/Repaint por Stoyan Stefanov [...]

  35. [...] Simplesmente especificar o tamanho correto da imagem no width e height do HTML ou CSS faz com que o browser já reserve o espaço para a imagem mesmo antes de seu download acabar. Quando ela chega, o navegador não precisa abrir espaço e empurrar os outros elementos, dando a sensação de que a página está sendo carregada mais rapidamente. Além disso, ao evitar o reposicionamento de elementos, evita-se reflows e repaints desnecessários. [...]

  36. [...] sendo carregada mais rapidamente. Além disso, ao evitar o reposicionamento de elementos, evita-se reflows e repaints [...]

  37. fondos de pantalla…

    [...]Rendering: repaint, reflow/relayout, restyle / Stoyan’s[...]…

  38. Great article!

    If I understand correctly
    Reflow affects the layout
    Restyle does not affect the layout ?

    When you say geometry change, you mean layout change ?

  39. [...] users are allowed to hide-and-show or drag-and-drop images over the viewport triggering several repaint, reflow and restyle on these DOM [...]

  40. [...] Reflow/Repaint por Stoyan Stefanov [...]

  41. [...] For more detail on how this works under the hood, refer to this blog post. [...]

  42. [...] #15 – Especifique o tamanho das imagens Fácil de implementar, essa prática tem um grande impacto visual para o usuário. Quando não especificamos o tamanho da imagem, o navegador não reserva um espaço na página para ela. O efeito é que, quando a imagem chega, ela é posicionada em seu lugar empurrando o restante do conteúdo. Isso dá a sensação de que os elementos da página estão se movendo e que ela ainda não está carregada. É uma péssima prática de usabilidade e dá a sensação de mais lerdeza. Simplesmente especificar o tamanho correto da imagem no width e height do HTML ou CSS faz com que o browser já reserve o espaço para a imagem mesmo antes de seu download acabar. Quando ela chega, o navegador não precisa abrir espaço e empurrar os outros elementos, dando a sensação de que a página está sendo carregada mais rapidamente. Além disso, ao evitar o reposicionamento de elementos, evita-se reflows e repaints desnecessários. [...]

  43. [...] [...]

  44. [...] For more detail on how this works under the hood, refer to this blog post. [...]

  45. [...] [...]

  46. [...] before animating them to their new position (see pageslider.js described below). More information here. Here is a code [...]

  47. [...] 要了解更多幕后发生的事情方面的细节内容,请参见这篇博文. [...]

  48. [...] Rendering: repaint, reflow/relayout, restyle: [...]

  49. [...] Rendering: repaint, reflow/relayout, restyle: [...]

  50. [...] Rendering: repaint, reflow/relayout, restyle: [...]

  51. [...] Rendering: repaint, reflow/relayout, restyle: [...]

  52. [...] Rendering: repaint, reflow/relayout, restyle: [...]

  53. [...] Rendering: repaint, reflow/relayout, restyle: [...]

  54. [...] Rendering: repaint, reflow/relayout, restyle: [...]

  55. Great post!

  56. [...] Rendering: repaint, reflow/relayout, restyle [...]

  57. [...] Rendering: repaint, reflow/relayout, restyle [...]

  58. No doubt there has been progress on the front of improving attitudes toward aging.
    Of course, in the end you need to understand that there is no
    Fountain of Youth. For example, Light – Stim has introduced its hand-held Professional
    Anti-Aging Light treatment with the use of LED light therapy.

  59. [...] 很显然接下来的问题是页面内容失效和强制进行重绘是由什么引起的。要全面回答这个问题并不容易,因为引起强制进行重绘的有大量不太容易区分的情况。其中最常见的原因是通过操纵CSS样式或者引起重新进行页面布局来改变DOM的特性。Tony Gentilcore写了一篇很不错的讨论引起页面重新布局的原因的博文,Stoyan Stefanov有一篇更近详尽地讨论浏览器绘制过程的文章(但这篇文章仅仅止于绘制过程,并没有涉及奇特的组合部分的内容)。 [...]

  60. [...] 进一步深入Layout,那上文中必须更新的必要条件是什么? 在 Stoyan Stefanov 的 Rendering: repaint, reflow/relayout, restyle 一文中已做比较详细的解答,可移步了解~ [...]

  61. [...] 进一步深入Layout,那上文中必须更新的必要条件是什么? 在 Stoyan Stefanov 的 Rendering: repaint, reflow/relayout, restyle 一文中已做比较详细的解答,可移步了解~ [...]

  62. Hi Stefanov
    The Article about The rendering process took my thinking in a newer way , thanks a lot for that -).
    while reading i got struck up at a particular point which didn’t have much explanation
    var el = document.getElementById(“element”);

    var left = el.offsetLeft,
    top = el.offsetTop

    when i am reading the offsetLeft or offsetTop for the el , will it cause re flow , it just a reading process .
    i am confused , please help me


  63. 革靴 ラルフローレン ゴルフ 店舗

  64. […] Rendering: repaint, reflow/relayout, restyle […]

  65. […] Rendering: repaint, reflow/relayout, restyle […]

  66. […] read how browser works and browser rendering process, I still have confusion about browser parse process when encounter <script> tag, which the […]

  67. […] Rendering: repaint, reflow/relayout, restyle: […]

  68. […] Rendering: repaint, reflow/relayout, restyle […]

  69. […] Rendering: repaint, reflow/relayout, restyle: […]

  70. […] 要了解更多幕后发生的事情方面的细节内容,请参见这篇博文. […]

  71. […] 进一步深入Layout,那上文中必须更新的必要条件是什么? 在 Stoyan Stefanov 的 Rendering: repaint, reflow/relayout, restyle 一文中已做比较详细的解答,可移步了解~ […]

  72. I am not sure wherte you’re getting your info, but great topic.
    I needs to spend some time learning much more or understanding more.

    Thanks for wonderful info I was looking for this information for my mission.

  73. […] […]

  74. […] Rendering: repaint, reflow/relayout, restyle: […]

  75. […] Rendering: repaint, reflow/relayout, restyle: […]

  76. I really love your site.. Pleasant colors & theme.

    Did you develop this site yourself? Please reply back as I’m trying to create my own website and would like to know where you got this from or just what the theme
    is named. Kudos!

  77. […] 进一步深入Layout,那上文中必须更新的必要条件是什么? 在 Stoyan Stefanov 的 Rendering: repaint, reflow/relayout, restyle 一文中已做比较详细的解答,可移步了解~ […]

  78. I have read so many ρosts regarsing the bloɡger lovers but this paragraph
    is really a fastidious paragraph, keep it up.

  79. They are also trained as custodians of economic damages, civil wrongs, non-economic damages that might be leveled
    towards an individual’s rights, reputation, and even properties.
    Why the same accident keeps occurring can be due to many reasons.
    This is because it has a lot of advantages over the other types.

  80. Right here is the rigbt webpage for anybody who reeally wants to
    find out about this topic. You realize so much its almost hard to argue with
    you (not that I really will need to…HaHa). You definitely put a fresh
    spin on a topic which has been discussed for a long time.
    Excellent stuff, just excellent!

  81. […] 要了解更多幕后发生的事情方面的细节内容,请参见这篇博文. […]

  82. Its not my first time to pay a quick visit this web site, i am visiting this
    website dailly and take fastidious data from here everyday.

  83. […] Stefanov wrote about reflow problem at his blog here, but in this case trying to force a reflow on element doesn’t […]

Leave a Reply