この記事はより速いウェブアプリケーションを構築するための価値あるガイドラインを与える。記事は様々なソースからのガイドラインの集合である。
This article gives valuable guidance for building faster web applications. The article is a collection of guidelines from various sources.
ケーススタディ: JavaScriptパフォーマンスを改善するための秘訣とこつ
この記事の秘訣とこつはサンプルアプリケーションを作る時の開発者経験から集められた。
Tips & tricks in this article were collected from the developer experiences when creating an example application.
概要
ソース: Efficient JavaScript - ECMAScript
最初に大枠とパフォーマンスに影響するスタックの主な構成要素を理解すること。ブラウザのソースコードに触れることなくJavaScriptで何が最適化できて何ができないかを理解することが最も重要である。この研究のいい開始点は、始めに(図で表された)JavaScriptパフォーマンススタックを見てみることである。
First understand the big picture and the major component of the stack affecting the performance. It is of utmost importance to understand what can and cannot be optimized in JavaScript without touching the browser codebase. A good starting point for this study is to first take a look at the JavaScript Performance Stack (depicted in the figure).
戦いを選ぶこと。最も大きな改善をもたらす部分を最初に最適化することが一般にはよいアプローチである。
Pick your battles. It is generally a good approach to first optimize those parts which give you the biggest improvements.
現実のウェブアプリケーションのパフォーマンスで要となる役割を演じる相互に関係した多くの構成要素がある。レイアウトやレンダリング、HTMLパース、整列、DOM、CSSフォーマット、JavaScript -- ご存知のようにJavaScriptはパフォーマンス方程式の一部にすぎない。
There are many interrelated components that play an instrumental role in the real-life web application performance such as those responsible for layout, rendering, parsing HTML, marshaling, DOM, CSS formatting, JavaScript -- as you see, JavaScript is only one part of the performance equation.
もっとも高価な演算はレイアウトのリフロート再描画である傾向がある。JavaScript開発として、ブラウザのレイアウトや描画アルゴリズムを最適化することはできないけれでも、不必要にこれらの高価な演算の引き金となることを避けることで、パフォーマンスに間接的に影響することはできる。IE8の現実の例はレイアウトとレンダリングタスクはIE８上でほとんどの時間をとっていることを示している。(ウェブキャストの-20:00分を参照)
The most expensive operations tend to be reflowing the layout and repainting. Although you as a JavaScript developer cannot optimize browser layout or painting algorithms you can still implicitly affect the performance of these expensive operations by trying to avoid triggering there expensive operations unnecessarily. A real-life example of IE8 tells us that layout and rendering tasks takes most time on IE8 (see webcast at -20:00 mins)
以下は、JavaScriptパフォーマンスが遅いことの共通の理由のいくつかの例である。JavaScript開発者としてあなたはそれらを容易に直し、すぐにウェブアプリケーションをよりよく動くようにできる:
Below are some examples of common reasons for slow JavaScript performance that you as a JavaScript developer can easily fix and make your web application to perform better instantly:
DOM access
DOMとのインタラクションは通常、標準的なJavaScriptコードより遅い。DOMとのインタラクションは通常避けられないが、最小限にするよう試みること。例えば、文字列でHTMLを動的に生成してinnerHTMLに設定することは、通常、DOMメソッドでHTMLを生成するより速い。
Interaction with the DOM is usually slower than normal JavaScript code. Interaction with the DOM is usually inevitable, but try to minimize it. For instance, dynamically creating HTML with strings and setting the innerHTML is usually faster than creating HTML with DOM methods.
eval
可能な時はいつでも、evalメソッドを避けること。スクリプト評価にはかなりのオーバーヘッドが含まれる。
Whenever possible, avoid the eval method because significant overhead is involved in script evaluation.
with
with文を使うと追加のスコープオブジェクトが生成される。それは変数アクセスを遅くして、曖昧さを生む。
Using with statements creates additional scope objects that slow variable access and create ambiguities.
for-in loops
配列全体を横断するにはfor-inループの代わりに伝統的な {{{1}}}を使うこと。不幸にもほとんどのJavaScript環境のfor-inループの実装は遅い。
Traverse arrays use the traditional {{{1}}}instead of for-in loops. Unfortunately, most JavaScript environments have a slow implementation of for-in loops.
