Front-End Performance

JavaScript Memory Leaks

Accidental Global Variables

• Global variables cannot have their memory released (when they are not set to null or reassigned).

// 브라우저의 경우 글로벌 객체는 window다.
function foo(arg) {
  bar = 'this is a hidden global variable';
}
 
function foo() {
  this.variable = 'potential accidental global';
}
 
// Foo가 호출되면, this는 글로벌 객체인 윈도우를 가리키게 된다.
foo();
 
// use strict 엄격한 모드로 선언해서 실수를 방지한다.

Forgotten Timers or Callbacks

var someResource = getData();
setInterval(function() {
    var node = document.getElementById('Node');
    if(node) {
        // Do stuff with node and someResource.
        node.innerHTML = JSON.stringify(someResource));
    }
}, 1000);
 
 
// 이 element는 onClick에서 참조됨
// 과거 특정 브라우저 (IE6)가 순환 참조를 잘 관리하지 못했기 때문에 이 부분은 특히 중요
var element = document.getElementById('button');
 
function onClick(event) {
    element.innerHtml = 'text';
}
 
element.addEventListener('click', onClick);
 
// 객체를 없애기전에 이러한 observer를 명시적으로 제거하는 것은 좋은 관례
element.removeEventListener('click', onClick);
element.parentNode.removeChild(element);

References Outside the DOM

//
var elements = {
  button: document.getElementById('button'),
  image: document.getElementById('image'),
  text: document.getElementById('text'),
};
 
function doStuff() {
  image.src = 'http://some.url/image';
  button.click();
  console.log(text.innerHTML);
}
 
function removeButton() {
  document.body.removeChild(document.getElementById('button'));
 
  // 이 시점에서도 여전히 elements에서 button의 참조를 가지고 있다.
  // 이 경우 button element는 여전히 메모리에 있으며, GC에 의해 해제 될 수 없다.
}

Front-End Performance Optimization

Rendering Optimization - Reducing Reflow and Repaint

Reflow (Layout)

// reflow 발생 예제
function reflow() {
  document.getElementById('content').style.width = '600px';
}

Typical cases where Reflow occurs are as follows.

Repaint (Paint)

Performing only Reflow does not reflect the changes on the actual screen. Just like the rendering process described above, a process to draw the Render Tree back onto the screen is required. Ultimately, the Paint step is performed again, and this is called Repaint.

However, Repaint does not always require Reflow to occur first. When style properties that do not affect the layout, such as background-color or visibility, are changed, there is no need to perform Reflow, so only Repaint is performed.

Reducing Reflow and Repaint

The performance optimization covered in this post is simply about introducing ways to reduce Reflow and Repaint operations. The content below only covers what has been researched so far. In addition, since this is theoretical content and excerpted material rather than something actually tested, it needs verification. The content below will be continuously updated.

Use display: none instead of visibility: invisible for unused nodes

Avoid using properties that trigger Reflow and Repaint

Typical properties that trigger Reflow

Typical properties that trigger Repaint

• CSS Trigger
• Reflow & Repaint

There are also properties such as transform and opacity that trigger neither Reflow nor Repaint. Therefore, using transform instead of left, right, width, height, and using opacity instead of visibility/display, helps improve performance.

Reducing the number of affected nodes

Another approach is to change the element to absolute or fixed when the animation starts and restore it to its original state when the animation ends, which also helps reduce Reflow and Repaint operations.

Reducing frames

Ways to avoid or minimize reflow

• When you want a style change based on a class change, add it to a node located as far down in the DOM structure as possible.

• Add the class to the node at the very bottom of the DOM tree

• For elements with animation, specify position: fixed or position: absolute whenever possible

  • Animations that implement positional movement (changing width or height values, etc.) cause reflow to occur repeatedly within a short period of time. So it is best not to use them, but if you must, apply the position: absolute or position: fixed property to the animated element. Since it does not affect other elements, reflow occurs only for that element rather than the entire page.

• When you need to make style changes through JS, handle them all at once whenever possible

// style을 여러번 호출(7.7ms), 클래스를 통하여 스타일 변화(5.3ms)
var div = document.getElementsByTagName('div');
for (var i = 0; i < div.length; i++) {
  div[i].style.height = '80px';
  div[i].style.backgroundColor = '#00f';
  div[i].style.display = 'inline-block';
  div[i].style.overflow = 'hidden';
  div[i].style.fontSize = '40px';
  div[i].style.color = '#fff';
}
 
var div = document.getElementsByTagName('div');
for (var i = 0; i < div.length; i++) {
  div[i].className = 'block';
}

• Avoid inline styles as much as possible
  • Inline Style: a short, single-line style specified and used directly inside a tag. Used mixed with HTML

<p style="color:#ff0a00">이 문장은 인라인 스타일이 적용되었습니다.</p>

• You should avoid table layouts.
  • When you use a table layout, the width is calculated according to the table values, so rendering becomes slower. Therefore, it is better not to use table layouts except when absolutely necessary. If you do use one, using the CSS property table-layout: fixed can make rendering a bit faster.

10×10 테이블
table-layout: fixed 미 적용
table-layout: fixed 적용
table-layout: fixed 미 적용(0.6ms) < table-layout: fixed 적용(0.4ms)
 
100×100 테이블
table-layout: fixed 미 적용
table-layout: fixed 적용
table-layout:fixed 미 적용(35.4ms) < table-layout:fixed 적용(27.1ms)

• It is good to trim CSS descendant selectors down to only what is necessary.
  • This is relevant not so much to reflow itself, but to the CSS Recalculation that reflow triggers. CSS rules are evaluated from right to left. This process continues until there are no more matching rules or a non-matching rule is found. Therefore, using unnecessary selectors can degrade performance.

<div class="reflow_box">
  <ul class="reflow_list">
    <li>
      <button type="button" class="btn">버튼</button>
    </li>
 
    <li></li>
    <li>
      <button type="button" class="btn">버튼</button>
    </li>
 
    <li></li>
  </ul>
</div>
 
/_ 잘못된 예 _/ .reflow_box .reflow_list li .btn{ display:block; } /_ 올바른 예
_/ .reflow_list .btn { display:block; }

• In the case of IE, avoid JS expressions in CSS.
  • The reason CSS expressions are so costly is that the expression is recalculated every time the entire document or part of the document is Reflowed.
  • This ultimately means that when a reflow occurs due to a change such as an animation, the expression may be recalculated thousands or tens of thousands of times per second depending on the case.

.expression {
  width: expression(
    document.documentElement.clientWidth > 0 ? '1000px': 'auto'
  );
}

• Minimizing Reflow using caching

.expression { width: expression(document.documentElement.clientWidth > 0 ? '1000px' : 'auto'); }
function collect() {
    var elem = document.getElementById('container');
    var cw = elem.style.width;
 
    return parseInt(cw, 10) * parseInt(cw + document.documentElement.clientWidth, 10);
    return false;
}

• Minimizing DOM usage
  • When adding nodes using a document fragment (document.createDocumentFragment), a node clone (elem.cloneNode), or a character array ([]), you can reduce cost by minimizing DOM access, as shown in the code below.

1. The basic way to add an element.

function notReflow() {
  var elem = document.getElementById('container');
 
  for (var i = 0; i < 10; i++) {
    var a = document.createElement('a');
    a.href = '#';
    a.appendChild(document.createTextNode('test' + i));
    elem.appendChild(a);
  }
 
  return false;
}

2. Adding elements using a document fragment

function notReflow() {
  var frag = document.createDocumentFragment();
 
  for (var i = 0; i < 10; i++) {
    var a = document.createElement('a');
    a.href = '#';
    a.appendChild(document.createTextNode('test' + i));
    frag.appendChild(a);
  }
 
  document.getElementById('container').appendChild(frag);
 
  return false;
}

3. Adding elements using a node clone

function notReflow() {
  var elem = document.getElementById('container');
  var clone = elem.cloneNode(true);
 
  for (var i = 0; i < 10; i++) {
    var a = document.createElement('a');
    a.href = '#';
    a.appendChild(document.createTextNode('test' + i));
    clone.appendChild(a);
  }
 
  elem.appendChild(clone);
 
  return false;
}

4. Adding elements using a character array

function notReflow() {
  var h = [];
  for (var i = 0; i < 10; i++) {
    h.push('test' + i + '');
  }
  document.getElementById('container').innerHTML = h;
  return false;
}

Test results by situation:

First situation: 153ms Second situation: 136ms Third situation: 129ms Fourth situation: 127ms

• Except for the first situation, the remaining situations did not show a large difference in performance, but the character array approach using innerHTML, an element property, produced a somewhat faster result than the methods using object members (fragment, clone).

References

• https://mohwaproject.tistory.com/entry/ReflowLayout-%EA%B3%BC-Repaint-%EA%B3%BC%EC%A0%95-%EB%B0%8F-%EC%B5%9C%EC%A0%81%ED%99%94
• https://wit.nts-corp.com/2017/06/05/4571
• https://mohwaproject.tistory.com/entry/DOM-%EC%82%AC%EC%9A%A9-%EC%B5%9C%EC%86%8C%ED%99%94-%ED%95%98%EA%B8%B0

Coding techniques that improve front-end performance

• Use an object/Map instead of an array
  • Reference site

• Use an IF statement instead of handling exceptions first
  • Reference site

• Use as few loops as possible
  • Reference site

• Use a basic loop
  • Reference site

• Use built-in DOM methods
  • Reference site

References

• https://gloriajun.github.io/frontend/2018/10/23/frontend-reflow-repaint.html
• https://junwoo45.github.io/2019-10-05-frontend-performance/
• https://www.slideshare.net/NHNFORWARD/2018-130108045
• https://ideveloper2.dev/blog/2019-05-18--front-end-%EC%84%B1%EB%8A%A5%EC%B5%9C%EC%A0%81%ED%99%94-%EA%B8%B0%EB%B3%B8/
• https://ui.toast.com/fe-guide/ko_PERFORMANCE/#%EB%A0%88%EC%9D%B4%EC%95%84%EC%9B%83%EA%B3%BC-%EB%A6%AC%ED%8E%98%EC%9D%B8%ED%8A%B8
• https://boxfoxs.tistory.com/408
• http://bit.ly/2SQXLzY
• https://github.com/wonism/TIL/blob/master/front-end/browser/reflow-repaint.md
• https://gist.github.com/faressoft/36cdd64faae21ed22948b458e6bf04d5

Improving Canvas Performance

Pre-render with an offscreen canvas

Batch drawing operations into a single call

Avoid unnecessary canvas state changes

Render only the changed part of the canvas state

Compose the canvas in layers for complex scenes

Avoid shadow blur effects

Learn the various ways to clear the canvas

Avoid floating-point coordinates

Optimize using RequestAnimationFrame

Creating the DOM (Document Object Model) and CSSOM (CSS Object Model)

• https://kuimoani.tistory.com/entry/HTML5-Canvas-%EC%84%B1%EB%8A%A5-%ED%96%A5%EC%83%81

The Rendering Process

Creating the DOM (Document Object Model) and CSSOM (CSS Object Model)

• A visualization of the DOM (left) and CSSOM (right) (source: http://bit.ly/3137pmh)

You can find the detailed process of how each document (HTML, CSS) is parsed and how the DOM Tree is formed in Google's developer documentation.

To add a bit more TMI here, the rendering engine is built to display content as quickly as possible for a better user experience. Therefore, even before all HTML parsing is finished, it performs the subsequent steps to output some content that can be shown to the user in advance.

Creating the Render Tree

• Render Tree diagram (source: http://bit.ly/2Okn0fG)

So while you can understand that style information is set on each element here, you might question the statement that it consists only of the nodes actually rendered on the screen, thinking "Aren't all elements rendered on the screen?"

To get to the point: yes, they are not. As a simple example, a node with the display: none property set does not occupy any space on the screen, so it is excluded from the process of building the Render Tree. To give a bit more of a tip here, visibility: invisible behaves similarly to display: none, but since it occupies space and only makes the element invisible, it is included in the Render Tree.

Layout

• Computation of elements relative to the Viewport (source: http://bit.ly/3137pmh)

Here, the Viewport refers to the area and size of the browser in which graphics are displayed. The viewport varies depending on the display size for mobile and the browser window size for PC. And since the size and position of each element drawn on the screen are often computed relatively using %, vh, vw, etc., the calculation must be redone every time the viewport size changes.

Paint

At this point, the more complex the styles that need to be processed, the more time the Paint step takes. As a simple example, a plain solid background-color paints quickly, whereas gradients and shadow effects take comparatively longer to paint.