回答編集履歴
1
typo修正、章構成の変更
test
CHANGED
|
@@ -8,15 +8,15 @@
|
|
|
8
8
|
|
|
9
9
|
「参照だから操作ではない」は受け取り方次第で変わる曖昧なものですが、そこは問題ではないと思います。
|
|
10
10
|
|
|
11
|
-
uroboros さんが「操作ではない」と思うならそうなのでしょうが、問題は「それがDOM操作なのか」ではなく、「遅いDOM APIなのか」ではないでしょうか。
|
|
11
|
+
uroboros さんが「操作ではない」と思うならそうなのでしょうが、問題は「それがDOM操作なのか」ではなく、「**遅いDOM APIなのか**」ではないでしょうか。
|
|
12
12
|
|
|
13
13
|
|
|
14
14
|
|
|
15
|
-
###
|
|
15
|
+
### リフローとリペイント
|
|
16
16
|
|
|
17
17
|
|
|
18
18
|
|
|
19
|
-
DOM APIが遅いといわれる所以はいくつかありますが、代表的な問題として「リフロー/リペイントが複数回発生するか否か」があります(注意: Geckoでは「リフロー」ですが、Webkitでは「レイアウト」と呼ぶそうです)。
|
|
19
|
+
DOM APIが遅いといわれる所以はいくつかありますが、代表的な問題として「**リフロー/リペイント**が複数回発生するか否か」があります(注意: Geckoでは「リフロー」ですが、Webkitでは「レイアウト」と呼ぶそうです)。
|
|
20
20
|
|
|
21
21
|
|
|
22
22
|
|
|
@@ -32,15 +32,29 @@
|
|
|
32
32
|
|
|
33
33
|
例えば、`appendChild` で何度も要素ノードを挿入するよりも `createDocumentFragment` で一つにした要素ノード群を1回で `appendChild` する方がコストが低くなります。
|
|
34
34
|
|
|
35
|
-
また、`element.style.color = 'black', element.style.backgroundColor = '#fee';` のように複数回styleを
|
|
35
|
+
また、`element.style.color = 'black', element.style.backgroundColor = '#fee';` のように複数回styleを変更するよりも `element.classList.add('hoge')` で1回でスタイルを変更する方がコストが低くなります。
|
|
36
36
|
|
|
37
37
|
|
|
38
38
|
|
|
39
|
+
### 複雑なDOMノードを生成する
|
|
40
|
+
|
|
41
|
+
|
|
42
|
+
|
|
39
|
-
|
|
43
|
+
要素ノードの下に要素ノードが入るような複雑なDOMノードを生成するDOM操作も遅いといえます。
|
|
40
44
|
|
|
41
45
|
DOM APIでは `createElement`, `setAttribute` 等で何回も関数呼び出しが発生し、処理を小分けにすることになるので積み重なると結構なコストになります。
|
|
42
46
|
|
|
43
|
-
雛形となるDOMノードを生成し、`cloneNode` で複製したり、template要素
|
|
47
|
+
雛形となるDOMノードを生成し、`cloneNode` で複製したり、template要素を利用する事である程度はコストを軽減する事が可能です。
|
|
48
|
+
|
|
49
|
+
|
|
50
|
+
|
|
51
|
+
- [Node.cloneNode - Web API インターフェイス | MDN](https://developer.mozilla.org/ja/docs/Web/API/Node.cloneNode)
|
|
52
|
+
|
|
53
|
+
- [HTML で利用可能になった Template タグ: クライアントサイドのテンプレートの標準化 - HTML5 Rocks](https://www.html5rocks.com/ja/tutorials/webcomponents/template/)
|
|
54
|
+
|
|
55
|
+
|
|
56
|
+
|
|
57
|
+
### DOM 参照系API
|
|
44
58
|
|
|
45
59
|
|
|
46
60
|
|