preface

According to W3C specifications, we usually write HTML, CSS, JS in layers; And CSS is usually at the top, HTML is written later, JS is written last. I’m sure this is the default way readers start writing, but have you ever wondered why they’re arranged this way?

Keep the following conclusions in mind and let’s take our time:

  • CSS: CSS does not prevent DOM tree parsing, but it does prevent DOM tree rendering.
  • JS: JS prevents DOM tree parsing and rendering.

Why is CSS at the top?

CSS loading does not block parsing of the DOM tree, but CSS loading blocks rendering of the DOM tree, and CSS loading blocks execution of subsequent JS statements.

Personal guess: CSS is likely to modify the DOM (don’t forget the context), so CSS loading blocks DOM tree rendering. CSS is placed at the top to prevent users from seeing the default HTML styles and creating a poor user experience.

Why is JS at the bottom?

JS prevents DOM tree parsing and rendering (because JS can manipulate DOM). In general, JS is much bigger than CSS and HTML. If the HTML is not displayed until the JS is fully loaded, the user will have a slightly longer blank screen (see the blank screen in SPA development).

But there are several cases of script loading:

  • By default, only the current script is executed before the page is rendered or other scripts are executed later.
  • You can use the defer attribute to have the script download and execute after the page has loaded, usually in sequence.
  • The async property allows the script to load while rendering the page. Once the script is loaded, the page rendering is stopped and the script is executed, perhaps not in order.

About rearranging and redrawing

rearrangement

  • Rearrangement (reflux, reflow) : RenderTree is changed. RenderTree is changed. RenderTree is changed, and renderTree is created again. This process is called rearrangement. Therefore: rearrangement must lead to redrawing.

    Rearrangement is also called backflow, which is interesting to see online: Backflow is like throwing a rock into a river (a dom change), causing ripples and ripples in the surrounding water, hence the term backflow.

    Triggers if one of the conditions is met:

    1. Page first render
    2. The browser window size changed. Procedure
    3. Element size or position changes (position, margin, border, width, height, etc. Change)
    4. Element content changes (text or image content changes, etc.)
    5. Element font size changes (because layout changes)
    6. Add or remove visible DOM elements or display triggers
    7. Set offsetWidth and offsetHeight
    8. Get properties like offsetWidth and offsetHeight (if the render queue is not empty, this will be explained later)

      Set the width and height property to trigger the rearrangement, which is understood to change the size of the element. Getting these attributes triggers reordering because of the browser’s rendering queue mechanism. When we modify the geometric properties of the elements, which leads to the browser to trigger the rearrangement or redrawn, it will put the action in the render queue, wait until the queue operations to a certain quantity or by a certain time interval, the browser will batch to perform these operations, when we went to get these data, the browser to ensure we get data is the latest, The render queue is cleared.

Note: If you determine the width and height of a DOM and then trigger a rearrangement within the DOM, only a local rearrangement will occur, otherwise a global rearrangement will occur.

redraw

  • Repaint: The process of rerendering that is triggered by changes in THE CSS style, color, font, etc. of DOM nodes that do not change the layout is called repaint. What has changed is part of cssTree, which has a relatively small impact on randerTree, so it has less impact on browser performance compared to rearrangement.

    However, table and its internal elements are special, and it may require multiple calculations to determine the attribute value of its nodes in the rendering tree, which takes twice as long as the same element, so avoid using table layout as much as possible.

    Triggers if the following conditions are met:

    1. When the style of an element on a page changes without affecting its position in the document flow (e.g., color, background-color, visibility, etc.)

      Visibility only triggers redraw because elements whose visibility is hidden are not visible, but their position does not disappear.

The browser’s render queue

When we modify the geometry of an element, causing the browser to trigger a rearrangement or redraw. It puts the action into the render queue, and when the number of actions in the queue reaches a certain number of times, the browser executes them in batches. When we fetch this data, the browser clears the render queue to make sure we are getting the latest data.

Optimization Suggestions

  • To avoid frequent style manipulation, it is best to either rewrite style (cssText) at once or change class at once to avoid frequent DOM manipulation.
  • Elements that need to be rearranged multiple times (such as elements in complex animations) use absolute positioning to keep them out of the document flow, which would otherwise cause frequent rearrangements of parent elements and subsequent elements.
  • Use transition and Transform as much as possible for animations.
  • Don’t hand over to JavaScript what you can do with CSS

    Because DOM and JavaScript are implemented separately, every time you manipulate the DOM through JS, you need to connect the JS and DOM first.

Form caton

Based on the above knowledge, we can analyze that too many elements on the page will trigger reflow if their positions change or their values change. We will not inevitably link to the table more data will be stuck reasons:

  • Scroll: Changed the position of elements to trigger reflow.
  • Multiple selection: Multiple selection actually changes the value of the checkbox, triggering reflow.

Too many elements are operated on, which is the reason for the lag. When we use the table in Element at ordinary times, it is not difficult to find that the lag will actually occur when the data exceeds 500. The solution is not to show so many elements at all, the user only needs the elements in the visual range, we define the height of the table, the height of each row to calculate how much data to show to the user, and render through the scrollthrottling listener. If readers are interested, they can search == and virtually scroll == to learn more.