Ruan Yifeng: Web パフォーマンス管理の詳細説明_html/css_WEB-ITnose

パフォーマンスの悪い Web ページに遭遇したことがありますか?

この種の Web ページは、応答が非常に遅く、多くの CPU とメモリを消費し、閲覧中に頻繁にフリーズし、ページのアニメーション効果がスムーズではありません。

あなたの反応はどうなりますか？私の推測では、ほとんどのユーザーはこのページを閉じて、代わりに他のサイトにアクセスするでしょう。開発者としては、このような状況は絶対に見たくないです。どうすればパフォーマンスを向上できるでしょうか?

この記事では、パフォーマンスの問題の原因とその解決策について詳しく紹介します。

1. Web ページ生成のプロセス

Web ページのパフォーマンスが良くない理由を理解するには、Web ページがどのように生成されるかを理解する必要があります。

Webページを生成するプロセスは大きく5つのステップに分けることができます。

1. HTML コードが DOM に変換されます
2. CSS コードが CSSOM (CSS Object Model) に変換されます
3. DOM と CSSOM を組み合わせてレンダリング ツリー (各ノードの視覚情報を含む) を生成します
4. レイアウト (レイアウト) をすぐに生成しますすべてのレンダリング ツリーのすべてのノードは平面合成されます
5. 画面上にレイアウトを描画します

この 5 つのステップのうち、1 番目から 3 番目のステップは非常に速く、4 番目と 5 番目のステップが最も時間がかかります。

「レイアウトの生成」（フロー）と「描画」（ペイント）の２つのステップを総称して「レンダリング」と呼びます。

2. リフローと再描画

Web ページが生成されると、少なくとも 1 回はレンダリングされます。ユーザーの訪問中、再レンダリングが継続されます。

次の 3 つの状況では、Web ページが再レンダリングされます。

1. DOMを変更する
2. スタイルシートを変更する
3. ユーザーイベント(マウスホバー、ページスクロール、入力ボックスへのテキスト入力、ウィンドウサイズの変更など)

再レンダリングには再生成が必要レイアウトと再描画。前者を「リフロー」、後者を「リペイント」と呼びます。

「再描画」には必ずしも「再配置」が必要ではないことに注意してください。たとえば、Web ページ要素の色を変更すると、レイアウトは変更されていないため「再描画」がトリガーされるだけで、「再配置」はトリガーされません。ただし、「再配置」を行うと必ず「再描画」が発生します。たとえば、Web ページの要素の位置を変更すると、レイアウトが変更されるため、「再配置」と「再描画」が同時に発生します。

3. パフォーマンスへの影響

リフローと再描画は継続的にトリガーされるため、これは避けられません。ただし、これらは非常にリソースを大量に消費するため、Web ページのパフォーマンス低下の根本原因となります。

Webページのパフォーマンスを向上させるということは、「リフロー」と「再描画」の頻度とコストを削減し、再レンダリングのトリガーをできるだけ少なくすることを意味します。

前述したように、DOM の変更とスタイルの変更は再レンダリングをトリガーします。ただし、ブラウザはすでに非常に賢く、複数の再レンダリングを避けるために、すべての変更をまとめてキューに入れ、一度に実行しようとします。

div.style.color = 'blue';div.style.marginTop = '30px';

上記のコードでは、div 要素に 2 つのスタイル変更がありますが、ブラウザーがトリガーするリフローと再描画は 1 回だけです。

うまく書かれていないと、2回のリフローと再描画が発生します。

div.style.color = 'blue';var margin = parseInt (div.style.marginTop);div.style.marginTop = (margin + 10) + 'px';

上記のコードで div 要素の背景色を設定した後、2 行目でブラウザに要素の位置を与える必要があるため、ブラウザはすぐにリフローする必要があります。

一般的に、スタイルの書き込み操作の後に、以下の属性の読み取り操作があると、ブラウザーはすぐに再レンダリングを引き起こします。

1. offsetTop/offsetLeft/offsetWidth/offsetHeight
2. scrollTop/scrollLeft/scrollWidth/scrollHeight
3. clientTop/clientLeft/clientWidth/clientHeight
4. getComputedStyle ()

したがって、パフォーマンスの観点から、読み取りを分離しないようにしてください操作とwrites 操作は 1 つのステートメントに配置されます。

// baddiv.style.left = div.offsetLeft + 10 + "px";div.style.top = div.offsetTop + 10 + "px";// goodvar left = div.offsetLeft;var top  = div.offsetTop;div.style.left = left + 10 + "px";div.style.top = top + 10 + "px";

一般的なルールは次のとおりです:

1. スタイル シートが単純であればあるほど、リフローと再描画が速くなります。
2. リフローおよび再ペイントされる DOM 要素のレベルが高くなるほど、コストも高くなります。
3. table 要素のリフローと再描画のコストは div 要素のコストよりも高くなります

4. パフォーマンスを向上させるための 9 つのヒント

ブラウザーの再レンダリングの頻度とコストを削減できるトリックがいくつかあります。

1つ目は前節でも触れましたが、DOMの複数の読み取り操作（または複数の書き込み操作）をまとめて行う必要があります。 2 つの読み取り操作の間に書き込み操作を追加しないでください。

第二に、再配置によって特定のスタイルが得られた場合、その結果をキャッシュするのが最善です。これにより、次回ブラウザを使用するときにブラウザをリフローする必要がなくなります。

3つ目は、スタイルを一つ一つ変更するのではなく、classやcsstext属性を変更することで一気にスタイルを変更します。

リーリー

　　第四条，尽量使用离线 DOM，而不是真实的网面 DOM，来改变元素样式。比如，操作 Document Fragment 对象，完成后再把这个对象加入 DOM。再比如，使用 cloneNode () 方法，在克隆的节点上进行操作，然后再用克隆的节点替换原始节点。

　　第五条，先将元素设为 display: none （需要 1 次重排和重绘），然后对这个节点进行 100 次操作，最后再恢复显示（需要 1 次重排和重绘）。这样一来，你就用两次重新渲染，取代了可能高达 100 次的重新渲染。

　　第六条，position 属性为 absolute 或 fixed 的元素，重排的开销会比较小，因为不用考虑它对其他元素的影响。

　　第七条，只在必要的时候，才将元素的 display 属性为可见，因为不可见的元素不影响重排和重绘。另外，visibility : hidden 的元素只对重排有影响，不影响重绘。

　　第八条，使用虚拟 DOM 的脚本库，比如 React 等。

　　第九条，使用 window.requestAnimationFrame ()、window.requestIdleCallback () 这两个方法调节重新渲染（详见后文）。

　　五、刷新率

　　很多时候，密集的重新渲染是无法避免的，比如 scroll 事件的回调函数和网页动画。

　　网页动画的每一帧（frame）都是一次重新渲染。每秒低于 24 帧的动画，人眼就能感受到停顿。一般的网页动画，需要达到每秒 30 帧到 60 帧的频率，才能比较流畅。如果能达到每秒 70 帧甚至 80 帧，就会极其流畅。

　　大多数显示器的刷新频率是 60Hz，为了与系统一致，以及节省电力，浏览器会自动按照这个频率，刷新动画（如果可以做到的话）。

　　所以，如果网页动画能够做到每秒 60 帧，就会跟显示器同步刷新，达到最佳的视觉效果。这意味着，一秒之内进行 60 次重新渲染，每次重新渲染的时间不能超过 16.66 毫秒。

　　一秒之间能够完成多少次重新渲染，这个指标就被称为"刷新率"，英文为 FPS（frame per second）。60 次重新渲染，就是 60FPS。

　　六、开发者工具的 Timeline 面板

　　Chrome 浏览器开发者工具的 Timeline 面板，是查看"刷新率"的最佳工具。这一节介绍如何使用这个工具。

　　首先，按下 F12 打开"开发者工具"，切换到 Timeline 面板。

　　左上角有一个灰色的圆点，这是录制按钮，按下它会变成红色。然后，在网页上进行一些操作，再按一次按钮完成录制。

　　Timeline 面板提供两种查看方式：横条的是"事件模式"（Event Mode），显示重新渲染的各种事件所耗费的时间；竖条的是"帧模式"（Frame Mode），显示每一帧的时间耗费在哪里。

　　先看"事件模式"，你可以从中判断，性能问题发生在哪个环节，是 JavaScript 的执行，还是渲染？

　　不同的颜色表示不同的事件。

蓝色：网络通信和 HTML 解析

黄色：JavaScript 执行

紫色：样式计算和布局，即重排

绿色：重绘

　　哪种色块比较多，就说明性能耗费在那里。色块越长，问题越大。

　　帧模式（Frames mode）用来查看单个帧的耗时情况。每帧的色柱高度越低越好，表示耗时少。

　　你可以看到，帧模式有两条水平的参考线。

　　下面的一条是 60FPS，低于这条线，可以达到每秒 60 帧；上面的一条是 30FPS，低于这条线，可以达到每秒 30 次渲染。如果色柱都超过 30FPS，这个网页就有性能问题了。

　　此外，还可以查看某个区间的耗时情况。

　　或者点击每一帧，查看该帧的时间构成。

　　七、window.requestAnimationFrame ()

　　有一些 JavaScript 方法可以调节重新渲染，大幅提高网页性能。

　　其中最重要的，就是 window.requestAnimationFrame () 方法。它可以将某些代码放到下一次重新渲染时执行。

function doubleHeight (element) {  var currentHeight = element.clientHeight;  element.style.height = (currentHeight * 2) + 'px';}elements.forEach (doubleHeight);

　　上面的代码使用循环操作，将每个元素的高度都增加一倍。可是，每次循环都是，读操作后面跟着一个写操作。这会在短时间内触发大量的重新渲染，显然对于网页性能很不利。

　　我们可以使用window.requestAnimationFrame ()，让读操作和写操作分离，把所有的写操作放到下一次重新渲染。

function doubleHeight (element) {  var currentHeight = element.clientHeight;  window.requestAnimationFrame (function () {    element.style.height = (currentHeight * 2) + 'px';  });}elements.forEach (doubleHeight);

　　页面滚动事件（scroll）的监听函数，就很适合用 window.requestAnimationFrame () ，推迟到下一次重新渲染。

$(window) .on ('scroll', function() {   window.requestAnimationFrame (scrollHandler);});

　　当然，最适用的场合还是网页动画。下面是一个旋转动画的例子，元素每一帧旋转 1 度。

var rAF = window.requestAnimationFrame;var degrees = 0;function update () {  div.style.transform = "rotate (" + degrees + "deg)";  console.log ('updated to degrees ' + degrees);  degrees = degrees + 1;  rAF (update);}rAF (update);

　　八、window.requestIdleCallback ()

　　还有一个函数 window.requestIdleCallback ()，也可以用来调节重新渲染。

　　它指定只有当一帧的末尾有空闲时间，才会执行回调函数。

requestIdleCallback (fn);

　　上面代码中，只有当前帧的运行时间小于 16.66ms 时，函数 fn 才会执行。否则，就推迟到下一帧，如果下一帧也没有空闲时间，就推迟到下下一帧，以此类推。

　　它还可以接受第二个参数，表示指定的毫秒数。如果在指定的这段时间之内，每一帧都没有空闲时间，那么函数 fn 将会强制执行。

requestIdleCallback (fn, 5000);

　　上面的代码表示，函数 fn 最迟会在 5000 毫秒之后执行。

　　函数 fn 可以接受一个 deadline 对象作为参数。

requestIdleCallback (function someHeavyComputation (deadline) {  while(deadline.timeRemaining () > 0) {    doWorkIfNeeded ();  }  if(thereIsMoreWorkToDo) {    requestIdleCallback (someHeavyComputation);  }});

　　上面代码中，回调函数 someHeavyComputation 的参数是一个 deadline 对象。

　　deadline 对象有一个方法和一个属性：timeRemaining () 和 didTimeout。

　　（1）timeRemaining () 方法

　　timeRemaining () 方法返回当前帧还剩余的毫秒。这个方法只能读，不能写，而且会动态更新。因此可以不断检查这个属性，如果还有剩余时间的话，就不断执行某些任务。一旦这个属性等于0，就把任务分配到下一轮requestIdleCallback。

　　前面的示例代码之中，只要当前帧还有空闲时间，就不断调用 doWorkIfNeeded 方法。一旦没有空闲时间，但是任务还没有全执行，就分配到下一轮requestIdleCallback。

　　（2）didTimeout 属性

　　deadline 对象的 didTimeout 属性会返回一个布尔值，表示指定的时间是否过期。这意味着，如果回调函数由于指定时间过期而触发，那么你会得到两个结果。

timeRemaining 方法返回0

didTimeout 属性等于 true

　　因此，如果回调函数执行了，无非是两种原因：当前帧有空闲时间，或者指定时间到了。

function myNonEssentialWork (deadline) {  while ((deadline.timeRemaining () > 0 || deadline.didTimeout) && tasks.length > 0)    doWorkIfNeeded ();  if (tasks.length > 0)    requestIdleCallback (myNonEssentialWork);}requestIdleCallback (myNonEssentialWork, 5000);

　　上面代码确保了，doWorkIfNeeded 函数一定会在将来某个比较空闲的时间（或者在指定时间过期后）得到反复执行。

　　requestIdleCallback 是一个很新的函数，刚刚引入标准，目前只有 Chrome 支持。

　　九、参考链接

1. Domenico De Felice, How browsers work
2. Stoyan Stefanov， Rendering: repaint, reflow/relayout, restyle
3. Addy Osmani, Improving Web App Performance With the Chrome DevTools Timeline and Profiles
4. Tom Wiltzius, Jank Busting for Better Rendering Performance
5. Paul Lewis, Using requestIdleCallback