TPACという大きなイベントも終了し、またホリデーシーズンに入ったこともあり、12月のW3Cはとても静か…と思いきや、結構な数の仕様に更新ありました。

また、先月ちょっとだけ取り上げたShared Workersの今後について議論されるなど、思ったよりも動きのある12月でした。

Shared Workers復活！？

先月の記事にて、WebApps WGのF2FにてShared Workersが削除されることを取り上げました。これはShared Workersの実装が乏しく、2つ以上の実装という勧告への要件を満たせないという懸念を受けてのアクションです。

• Refactoring SharedWorkers out of Web Workers W3C spec

しかし12月に入り、FirefoxがShared Workersを有効にしました（Firefox 29より利用可能となります）。

• mozilla-central: changeset 159853 — Bug 924089 – Enable SharedWorker by default

これを受け、Shared Workersを削除する必要があるのかといった議論が、WebApps WGのメーリングリストで交わされています。議論の中で実はPrestoも実装していたという話も出てきて、こないだの話はなんだったのだろう感が否めません。

とはいえ、この議論が出てきたのはその実装状況が不明だった、テストスイートによる検証がなされていなかったなど、現状把握を誰も行っていなかったことに起因します。メーリングリストでは、その後各ベンダーの担当者にWeb Workersのテストスイートを実行するよう要請したことで、実装状況と相互運用性の状況がわかりつつあります。

• Webapps/Interop/WebWorkers – W3C Wiki

議論を追うとテストケース自体への問題も指摘されており、Shared Workersが削除されるというよりもWeb Workers自体の問題に移行しているようです。

なお、Web Workersについてはいくつか機能追加の要望もあり、Level 2仕様への希望も出ました。CanvasのImageDataをWorkersで扱うインターフェースなどはすでにWHATWG HTMLで提案中ですが、synchronous message channelsなど別の機能も求められているようです。

冬休みに入ったためか議論が止まってしまい、今後は以前不透明です。とはいえ、実装が増えたことはShared Workersについて明るいニュースだったのではないでしょうか。

CSSOM Viewが更新 ― devicePixelRatio、スムーズスクロール機能が追加

2013年12月17日付けで、CSS WGから新しいCSSOM Viewの草案が公開されました。

• CSSOM View Module

CSSOM ViewはCSS関連のオブジェクトモデルのうち、ブラウザやシステムに関わるプロパティを定義する仕様です。古くからあるclientWidthやgetBoundingClientRect()、比較的最近ではmatchMedia()などが定義されています。

今回の草案の見どころは、window.devicePixelRatioとスムーズスクロール関連の機能が定義されたことでしょうか。window.devicePixelRatioプロパティはAppleが高解像度モードのためにWebKitに導入した独自拡張で、Retina Displayをはじめ高密度ディスプレイへの対応をする際に使われています（ちなみにこのプロパティ、iPhone 4で初めてRetina Displayが登場するよりもずっと前の2006年に実装されています）。他のベンダーも追従し、最近ではIE11でも実装されました。

今回のCSSOM Viewではブラウザのズームとピンチズームの概念も導入され、さらにdevicePixelRatioがブラウザズームの影響を受けると定義されました。これはGecko, Blink, Tridentの挙動に沿ったものですがWebKitの実装はそうではなく、Appleはこの定義に反対しています（WebKitではブラウザのズームにも、画面解像度の変更においてもdevicePixelRatioの値が変化しません）。

スムーズスクロール機能は現在、JavaScriptライブラリやスニペットを使って実装されていますが、タイマーを使ってちまちまscrollTo()をするものであまり効率が良い感じがしません。 今回の草案では新たにscroll-behaviorプロパティというCSSプロパティが定義されました。scroll-behavior: smoothと指定すれば、対応する実装がネイティブのスムーズスクロールを利用するよう支持できます。

ほかにも、新たなメソッドmoveTo()、moveBy()、resizeTo()、resizeBy()の導入や、resizeイベントとscrollイベントが定義されたりなど盛りだくさんです。

続CSSOM View ― PPK氏によるDPR調査など

ブラウザの互換性調査などで有名なPeter-Paul Koch氏が、devicePixelRatioやズーム、screen関連のDOMプロパティについてコメントを寄せました。デスクトップのページズームはdevicePixelRatioに影響させるすべきでないなど、今の流れと正反対の意見を唱えており、ちょっとした議論になりました。

• [css-om] Issues with width and resolution media queries

CSSOM Viewはもともとあまり互換性のなかったデスクトップブラウザ間の挙動を、なんとか合わせるために策定が始まりました。しかしviewportやデバイスピクセル比などモバイルからもたらされた概念が関わり、さらにはブラウザのバグなどもあり混沌としています。今回の議論は、そういった概念の整理に加え、現在出回っているモバイルブラウザの挙動と、プラットフォームとしてどうあるべきかという仕様の方向が異なっていることも背景にありそうです。

なお、デバイスピクセル比については、ほかにもresolution媒体特性が返す小数点の位がとる幅について議論されています。

仕様の断片化にどう対処するか

Jens O. Meiert氏がHTML WG、CSS WG、WHATWGに、仕様の断片化についてアドバイスをしていました。

• CSS, HTML, and the Problem of Spec Fragmentation · Jens O. Meiert

CSSはモジュール化というアプローチで策定されていますが、氏は以前より機能が増えすぎていることを問題視していました。また、CSSモジュールだけではなく、WHATWG仕様の一部やHTML仕様、SVGでもセレクタやプロパティが定義されてることに触れ、見通しの悪さも指摘しています。

HTMLについても、WHATWG HTMLとW3CのHTML5、それにHTML 5.1と細かなバリエーションがあります。氏は触れていませんが、拡張仕様やHTML仕様が参照するいくつかのDOM仕様も含めると、HTML関連仕様も数がかなり多くなりそうです。

Meiert氏は、実装する方においては都合がよいかもしれないが、開発者は複数の仕様の違いに戸惑うことを問題視しています。仕様の断片化についてはW3Cの勧告プロセスにあるのではないかと思いますが、たしかに仕様の分割が頻繁で、どの機能がどこにあるのかがわからなくなることしばしばと思います。

Custom Elementsのメソッド名が変更

いろんな「今年注目すべきWeb技術」的エントリで、ここ数年取り上げら続けているWeb Componentsですが、そのいち仕様であるCustom ElementsについてAppleよりコメントが寄せられました。Custom Elements仕様はWeb Componentsの独自の要素を定義するための仕組みを用意します。要素を定義するためのメソッドはこれまでdocument.register()という名前でしたが、registerという単語1語の名前が汎用的すぎるといったコメントが寄せられました。

• [custom elements] Improving the name of document.register()

こういった名前に関する指摘は自転車小屋の議論に陥りやすく、W3Cで過去に起こった同様の議論でもあまりいい解決を見たことがありません。しかしながら、今回はApple, Mozilla, Googleなどベンダーの開発者からのフィードバックもあり、それなりに思慮深い話になった感じがします。

結果として、仕様はdocument.registerElement()を使うことになりました。Chromeの実装も変更されています。

その他12月に公開されたWeb標準

• 12月3日付けで、CSS ShapesがCSS WGよりLast Callとして公開されました。大きな変更はTPACでのF2Fにて決定された構文の変更が仕様書に反映されたことでしょうか。
• 12月3日付けで、High Resolution Time Level 2の草案がWeb Performance WGより初公開にしてLast Callというすっとんだかたちで公開されました。Level 2での機能追加は今のところWeb Workersでのサポートとなっています。
• 12月5日付けで、CSS Object Modelの草案がCSS WGより公開されました。カスケードされた後のスタイルや利用されるスタイルといったスタイルを取得するインターフェースや、CSSOMとしてセーフな値にするCSS.excape()メソッドなどが新たに定義されています。
• 12月10日付けで、DOM Parsing and SerializationがWebApps WGよりLast Callとして公開されました。innerHTMLやinsertAdjacentHTML()を定義する仕様です。
• 12月12日付けで、Performance Timeline、User Timingが勧告されました。
• 12月17日付けで、Pointer LockがWebApps WGより勧告候補として公開されました。
• 12月17日付けで、Input Method Editor APIの草案がWebApps WGより公開されました。IMEの候補ウインドウを描画するAPIが削除されたほか、Microsoftが提案したイベントやインターフェースが追加されました。

注目ニュースピックアップ

プログレッシブ・エンハンスメントはもう過去の話なのか?

この14日間はプログレッシブ・エンハンスメントについて多くの議論が行われた。

事の発端はDaniel Mall氏が始めたSigh, JavaScriptという様々なWebサイトで、JavaScriptをオフにした際の状態をキャプチャしてリストするというTumblr。
それに対して、Ember.jsのメンテナーであるTom Dale氏がProgressive Enhancement: Zed’s Dead, Babyと題した記事で「プログレッシブ・エンハンスメントはもう終わったアプローチである」と宣言した。
そのTom Dale氏の記事に、Jake Archibald氏がProgressive enhancement is fasterにて反論。 そして、Daniel Mall氏も“Progressive Enhancement. Still Alive & Kickin’.でSign, JavaScriptを始めた理由を説明した。 これらの反論に対して、Tom Dale氏はMaybe Progressive Enhancement is the Wrong Termにてプログレッシブ・エンハンスメントという言葉の意味は範囲を再確認している。 技術者的な視点だけではなく、デザイナからの視点でもこのトピックに対して様々な記事があがったりと、プログレッシブ・エンハンスメントそのものに対する興味関心の高さが分かるすばらしい議論となった。

効果的なドキュメンテーションの作り方について – Steve Losh

原題: Teach, Don’t Tell

Steve Losh氏によるテクニカル文書、主にプログラミング言語やライブラリなどのドキュメンテーションの書き方について、7つのアンチパターンを通して、よりよいドキュメントを書くために覚えておきたいことをまとめている。
自分でオープンソースとしてライブラリなどを公開している方はもちろん、会社やチームのガイドラインを作成している人にも、勉強会などでプレゼンをする人にもおすすめできるすばらしいアドバイス。

Eloquent JavaScript 第二版 – Marijn Haverbeke

原題: Eloquent JavaScript second edition

JavaScriptを学ぶ上で読んでおくべき書籍は?という質問には確実に名を連ねてくるのがMarijn Haverbeke氏による「Eloquent JavaScript」。解説だけではなく、実際に手を動かすエクササイズがあったりと、当時としては画期的な書籍で、さらにクリエイティブ・コモンライセンスでオンライン版は無料で公開されている。
2007年に執筆されたこの本は、現在第二版に向けて執筆を始めている。筆者はその執筆のためにクラウド・ファンディングをしているので、興味がある方はぜひファンドに協力してみてはいかがだろう。

すばらしいデザインは常にすばらしいスタイルである – MISC Magazine

原題: Great Design Always Means Great Style

Don Norman氏によるよいデザイン、よいスタイルについてのこの記事では、そもそもデザインにおけるスタイルとは単純な見た目のファッションではなく、パーソナリティのようなものではないかと説明。パーソナリティとは車でいうところのポルシェやBMV、メルセデス・ベンツのようなブランドに抱くイメージを分かりやすい例として紹介している。
氏は記事を以下のように締めくくっている。 『すばらしいデザインとは常にすばらしいスタイルを意味する。正直で、理路整然としていて、一貫性があるものだ。』

リソース・プライオリティ – W3C

原題: Resource Priorities

パフォーマンスは今ではインフラ担当の人間だけの問題ではなく、もちろんフロントエンド開発者だけの問題でもなく、全員の問題だ。
その全員にはもちろんW3Cも含まれる。
Resource Prioritiesという仕様はまだドラフト段階ではあるが、画像やスクリプト、ビデオやオーディオに対して、lazyloadやpostponeという属性を追加できるようにするものだ。
これらの属性はJavaScriptを使ってすでに解決されつつある問題ではあるが、仕様として存在する意義は大きい。

海外トレンドコラム

ECMAScript 6のArrowファンクションについて – NCZOnline

原題: Understanding ECMAScript 6 arrow functions

ECMAScript 6で追加される予定のArrowファンクションについてNicolas Zakas氏による解説。
Arrowファンクションはその名前の通り、関数のシンタックスを => このような矢印を使って置き換えることができるようになる。
ただそれだけではなく、newができない、thisのバインディングが違うなどの点が異なる。

テスト駆動開発とはなにか、そしてどんなものなのか

原題: 30 Days of TDD: Day One – What is TDD and Why Should I Use It?

テスト駆動開発にについて、30日間連続で書き続けるチャレンジの1日目。第一回目は、そもそもテスト駆動開発とはどんなものか、そして、その開発ワークフローをどうして利用するべきなのかを解説。

ドメイン・シャーディングをもう一度振り返ってみよう – High Performance Web Sites

原題: Domain Sharding revisited

パフォーマンスにおいて、SPDYやHTTP 2.0の時代が来るとアンチパターンになると言われている。だが、ドメイン・シャーディングというテクニックについて、スティーブ・サウダー氏は、そうとも言えないのではないかと話し、大抵のウェブサイトにおいては次の時代でも活用できるとしている。

レスポンシブ・イメージ会議メモ – Shane Hudson Dot Net

原題: Responsive Images Meeting Notes

9/10にパリで開かれたレスポンシブ・イメージに関する会議のメモ。若干散文的ではあるが、会議で話された内容について大事なポイントをおさえているので、非常に参考になる。先日、webkitにてsrcsetが実装されたが、レスポンシブな環境における画像の取り扱いについて、まだまだ課題は多い。今後も目が話せないトピックだ。

いまさら聞けないHTTP

原題: Know Your HTTP Well

もう本当にいまさら聞けないHTTPにまつわる話を、仕様やヘッダ、メディアタイプ(今後追加される様子)、メソッド、ステータスコードなどのように区分し、それぞれ詳しく解説している。あっという間に1000スターという人気のほどなので、いまさら聞けないのは私だけではなかったようです。

Mutation Observersの使い方 – Dev.Opera

原題: Getting to know mutation observers

JavaScriptが多く利用されるプロダクトの制作を行っているとあるDOMノードツリーが変わったタイミングを知りたいということはよくある。
この記事で紹介をしているDOMレベル4仕様で定義されたMutation Observersは、これまで抱えてきた問題を解決してくれる。これまで利用してきたMutationEventとの違いを踏まえて、利用方法を解説。

CoffeeScriptに未来はあるのか?

原題: Does CoffeeScript Have a Future?

CoffeeScriptはどんな役割を持った言語なのか、JavaScriptに変換される言語としてはよく使われる言語ではあるが、もしかするとJavaScriptそのものの変化にしたがって、もう必要がなくなるかも知れない。CoffeeScriptを愛してやまない著者のゆらぎを感じる非常にすばらしい記事。

クローズアップ“ビデオ/スライド”

WebGLの基礎と応用 – Steven Wittens

原題: Making WebGL Dance

前回の本連載にてピックアップしたActo.netのSteve Wittens氏による、WebGLのイントロダクションビデオ。非常にベーシックな三角形から描画し、アンチエイリアスなどから始め、徐々に3Dの世界へ導いていく。数学的なアプローチは難しい部分も多いが、最終的なアウトプットを見ると、チャレンジする価値があると思わせるプレゼンテーション。

ジャンク・バスターズ: Google Chromeにおけるレンダリングパフォーマンスについて – Nat Duca & Tom Wiltzius

原題: Jank Busters – Chrome Rendering Performance

GoogleのNat Duca氏とTom Wiltzius氏によるJank Bustersシリーズのアップデート版。これまで両氏は何回か同じトピックでプレゼンテーションを行ってきているが、最新版にアップデートされたもの。アニメーションだけではなく、レンダリングプロセスを最適化するために知っておいたほうがよいことばかりをコンパクトに解説している。

一歩先行く“コード”

animo.js

jQuery依存が気にならない、ことはないが、Dan Eden氏作のanimation.cssをベースに、連続したアニメーションを行うのに非常にシンプルなシンタックスで可能にしている。

JavaScriptでJPEG画像を壊してみよう

原題: Image Glitch Experiment

正直なところ何の役に立つのかはわからないが、JavaScriptを使ってJPEG画像を破壊するツール。こういった実験的な実装は見ていて楽しいが、作るとより楽しいはず。

Paul Irishおすすめ。フロントエンド開発者のためのフィード

原題: Frontend Feeds

私自身にとって、貴重な情報源であるGoogleのPaul Irish氏がまとめたフロントエンドデベロッパのためのフィード。
以前にも彼はこの形式でフィードを共有していたが、今回はGitHub。Paulチョイスだけあって、非常にクオリティが高いのでおすすめ。

海外で話題の“ツール”

Custom Element: モダンなWebアプリのためのWeb Componentsギャラリー

原題: Custom Elements – A Web Components Gallery for Modern Web Apps

まだまだ登録数は少ないが、Web ComponentsをGitHubのリポジトリから登録でき、検索可能にするギャラリーサイト。
今後はコンポーネント数が増え、欠かすことができないツールになりえるかもしれない。

★次回の「斉藤祐也の海外WEBテク定点観測」は、9月30日にお届け予定です。★

連載「Webサイト・アプリ高速化テクニック徹底解説」の第5回は、前回の「DOM操作の最適化によるJavaScriptチューニング（前編）」に続く後編です。後編では、createElement()などのDOM操作メソッドを使ったさまざまなテクニックや、パフォーマンスを劣化させるよくあるパターンについて詳しく解説します。

DOM操作の最適化によるJavaScriptチューニング（後編）

前回は、DOM操作が遅い原因と仕組みについて簡単に説明し、チューニングのサンプルをいくつか解説しました。その中で、innerHTMLを利用したコードをサンプルにあげていますが、innerHTMLを利用する場合、いくつかの点で注意が必要です。

• HTMLの文字列を扱うため単純な子要素の追加ができない（子要素をすべて書き換えることになる）
• 追加する要素が多くなると、文字列連結のコストやHTMLをパースするコストが膨れ上がる
• HTMLを直接扱うため、きちんとエスケープしないとクロスサイトスクリプティングの脆弱性を作りこむ可能性がある

以上の点から、特に理由がなければinnerHTMLよりもDOM操作メソッドを使ったほうが良いでしょう。今回は、DOM操作メソッドを使ったさまざまなテクニックや、パフォーマンスを劣化させるよくあるパターンを紹介し、そのチューニング方法を見ていきます。

また、前回の記事のinnerHTMLを使ったサンプルでは、上に挙げたような複数の要因でパフォーマンスに影響与えていることから、レイアウト・レンダリングの遅さのみを理由とするには、あまり適切ではありませんでした（チューニング自体には問題はありませんので心配しないでください）。折を見て改訂したいと思います。ご指摘して頂いた方々、ありがとうございました。 本連載では、より良い情報を皆さんに届けるため、ご指摘や疑問点などがあれば是非フィードバックを頂ければと思います。フィードバックを受け、できるかぎり記事を更新していきたいと思います。

DOM操作メソッドを使ったテクニック

createElement()やappendChild()などのDOM操作メソッドを使った方法では、単純にinnerHTMLによるコードを置き換えるだけでなく、さまざまなテクニックがあります。ここでは、DOM操作メソッドを使う際に覚えておいた方がよいテクニックをいくつか紹介します。

複数の要素をまとめて追加する

複数の要素を追加する場合、構造によってはそのままでは一度に追加できないことがあります。例えば、次のサンプルのようにul要素にli要素を追加していくようなケースです。

:javascript:
// サンプル1: ul要素にli要素を追加していく（低速）
var ul = document.querySelector('#output');
for ( var i = 0; i < data.length; i++ ) {
  var li = document.createElement('li');
  li.textContent = data[i];

  // ループのたびにli要素を追加
  ul.appendChild(li);
}

このサンプルでは、ループのたびにli要素を追加していますので、DOMツリーへ更新が何度も発生します。こういった場合には、DocumentFragmentを利用して複数のli要素をまとめて追加することができます。次のコードは、DocumentFragmentを利用して書き換えたコードです。

:javascript:
// サンプル1: ul要素にli要素をまとめて追加（高速）
var ul = document.querySelector('#output'),
    fragment = document.createDocumentFragment();

for ( var i = 0; i < data.length; i++ ) {
  var li = document.createElement('li');
  li.textContent = data[i];

  // いったんDocumentFragmentに追加する
  fragment.appendChild(li);
}

// 最後にDocumentFragmentをul要素に追加する
ul.appendChild(fragment);

DocumentFragmentは、従来のDOMツリーとは分離された独立した小さなDOMツリーです。createDocumentFragment()メソッドを使って作成します。DocumentFragmentに追加された要素は、そのままでは見た目に影響を与えないため、まずはDocumentFragmentにli要素を追加していきます。そして、最後にul要素にそのDocumentFragmentを追加し、反映します。こうすることで、元のDOMツリーへの更新が1回だけで済みます。

繰り返し同じような要素を追加する（テンプレート化）

同じような要素を繰り返し追加する場合、要素をまた一から作成していくのは面倒です。また、要素が多くなってくるとパフォーマンス的にもあまり良くありません。例えば、ボタンが押されるたびに、次のような構造を持つli要素を追加していくことを考えてみましょう。

:html:
<li>
  <artcile class="item">
    <h1 class="title">アイテム</h1>
    <p class="detail">詳細</p>
  </artcile>
</li>

これを素直にDOM操作メソッド使って構築すると次のようにボタンが押されるたびに毎回要素を生成して構築する形になります。

:javascript:
// ボタンがクリックされる度に複雑な要素を追加
button.addEventListener('click', function(){

  // 各要素を生成
  var li = document.createElement('li'),
      article = document.createElement('article'),
      h1 = document.createElement('h1'),
      p = document.createElement('p');

  // 各要素のプロパティを設定し、組み立てる（省略）

  ul.appendChild(li);
}, false);

サンプルでは、コードが多い部分を省略していますが、多くのDOM操作をしています。このような場合、構築される要素をテンプレート化して、それをcloneNode()を使ってコピーするようにすれば、DOM操作の数を減らすことができます。cloneNode()を利用すると次のようなコードになります。

:javascript:
// テンプレートとしてli要素を構築
var template = document.createElement('li'),
    article = document.createElement('article'),
    h1 = document.createElement('h1'),
    p = document.createElement('p');

// 各要素のプロパティを設定し、組み立てる（省略）

// ボタンがクリックされる度にテンプレートから要素を追加
button.addEventListener('click', function(){

  // テンプレートから要素をコピー
  var li = template.cloneNode(true);

  // 一部書き換えて追加
  li.querySelector('.title').textContent = 'アイテム';
  li.querySelector('.detail').textContent = 'アイテムの詳細'
  ul.appendChild(li);
}, false);

こうすると、ボタン押すたびにテンプレートからコピーするだけなので効率的です。構築する要素が複雑になればなるほど、cloneNode()を利用する方が高速になります。cloneNode()の引数は、子要素を一緒にコピーするかどうかなので、trueを指定しておきます。また、cloneNode()ではイベントリスナーをコピーすることはできませんので注意してください。

複数の要素をまとめて置き換える

既に表示されているインターフェースに対して最新の情報を反映するような場合があるかと思います。その際に、表示するデータが細かいとDOM操作も細かくなってしまうことがあります。例えば、次のようなHTMLの各p要素の内容を書き換えることを考えてください。

:html:
<div class="results">
  <p>結果1</p>
  <p>結果2</p>
  <p>結果3</p>
</div>

これを単純に書き換える場合は、次のようなコードになりがちです。

:javascript: 
var elements = document.querySelectorAll('.results p');
elements[0].textContent = '結果a';
elements[1].textContent = '結果b';
elements[2].textContent = '結果c';

この場合、3つのp要素を順に書き換えているので、DOMツリーへの更新が3回発生してしまいます。このような場合、replaceChild()を使って一度に置き換えることができます。

:javascript:
var origin = document.querySelector('.results'),
    clone = origin.cloneNode(true);

// コピーした要素を更新する
var elements = clone.querySelectorAll('p');
elements[0].textContent = '結果a';
elements[1].textContent = '結果b';
elements[2].textContent = '結果c';

// 元の要素とコピーした要素を入れ替える
origin.parentNode.replaceChild(clone, origin);

この方法であれば、DOMツリーへの更新は1回で済みます。また、先ほどのサンプルと同様にcloneNode()がイベントハンドラーをコピーできないことに注意しましょう。

パフォーマンスを劣化させるよくあるパターン

ここからは、パフォーマンスを劣化させるよくあるパターンや、そのチューニング方法を紹介します。

複数のスタイルの書き換え

ある要素のスタイルを複数書き換える場合に、ついやってしまいがちなのが次のコードです。

:javascript:
// 複数のスタイルの書き換え（低速）
element.style.background = 'gray';
element.style.border = '1px solid black';

この場合も、レイアウトが複数発生する可能性があるので、次のように記述しましょう。

:javascript:
// 複数のスタイルの書き換え（高速）
// style属性で一度にすべて指定する
element.setAttribute('style', 'background: gray; border: 1px solid gray;');

setAttribute()を使ってsytle属性を使って一度に複数のスタイルを指定しています。また、あらかじめ指定するスタイルがある程度決っているなら、可読性やメンテナンスを考えてclass属性を使っても良いでしょう。

:javascript:
// classを指定して複数のスタイルを適用する
element.className = 'hoge';

アニメーション

ある要素の位置やサイズを動かしてアニメーションさせるような場合、スタイルでposition: absoluteやpositon: fixedを指定しておくと良いでしょう。これは、レイアウト・レンダリングの範囲を最少化するためです。position: absoluteなどを指定すると他の要素との位置関係やサイズ計算から切り離されるため、その要素に対する変更が他の要素に影響しなくなります。そのため、レイアウト・レンダリングのコストが小さくなり、パフォーマンスが向上します。アニメーションのチューニングについては、また別の記事で触れますので楽しみにしていてください。

スタイル情報の取得

多くのDOM操作によるスタイル情報の取得の中でも、次に挙げるプロパティ、メソッドについては特に注意が必要です。

• getComputedStyle()
• offset*系のプロパティ
• client*系のプロパティ
• scroll*系のプロパティ

（offset*系のプロパティとは、offsetという単語を含むoffsetTop、offsetLeft、offsetHeight、offsetWidthなどのプロパティです）

これらのプロパティ、メソッドは、現時点での最新の情報を返そうとするため、それまでに実行したDOM操作があれば、すぐさまレイアウト・レンダリングを実行します。本来であればブラウザが自動的に最適化し、非同期に実行しているものを強制的に実行してしまうため大きなボトルネックになります。例えば、あるブロックを単純に右に動かすだけのコードを見てみましょう。

:javascript:
// あるブロックを右に動かす
setInterval(function(){
  block.style.left = block.offsetLeft + 1 + 'px';
}, 1000 / 60 );

ここでは、あるブロックのoffsetLeftを取得し、1を加えてスタイルのleftに代入しています。leftの値を更新した後に、またすぐにoffsetLeftを参照しているので、その時点でレイアウト・レンダリングが発生し、遅くなります。そのため、offsetLeftの値をキャッシュしておき、以降はそれを利用するように変更しましょう。

:javascript:
// あるブロックを右に動かす
// offsetLeftの値を一度キャッシュして以降は使いまわす
var left = block.offsetLeft;
setInterval(function(){
  left++;
  block.style.left = left + 'px';
}, 1000 / 60 );

このように、上記であげたプロパティ、メソッドは、多くのDOM操作をしているような箇所では特にボトルネックになりやすいので注意しましょう。（サンプルでは、JavaScriptを使っていますが、もちろんCSSで記述しても良いでしょう。）

要素の取得

それほど気にするほどの差ではありませんが、要素を取得する際にquerySelector()やquerySelectorAll()よりも、getElementById()やgetElementsByTagName()、getElementsByClassName()を利用した方が若干速くなります。

:javascript:
// div要素をすべて取得
var elements = document.querySelectorAll('div');

// querySelectorAll()よりも若干速い
var elements = document.getElementsByTagName('div');

その他の違いにも、getElementsByTagName()などは、結果として返るリスト（NodeList）が常に現在のDOMツリーを反映したものになるのに対して、querySelectorAll()などは取得した時点のものになります。例えば、これらのメソッドで要素を取得した後に、要素が追加された場合、getElementsByTagName()で取得したリストではリストにその要素が自動的に追加されますが、querySelectorAll()ではリストに変化はありません。そういった違いも覚えておくと良いでしょう。

まとめ

ここまで前編、後編にわたってDOM操作の最適化について解説しました。いくつかのサンプルやパターンを交えて、チューニング方法を紹介してきましたが、もちろんこれ以外にもたくさんのテクニックがあります。細かいテクニックをあげていくときりがありませんが、重要なのはDOM操作自体の回数を減らすことと、DOMツリーへの更新とレイアウトやレンダリングなどの範囲、回数を減らすことです。それさえ覚えておけば、自分でいろいろなコードに応用できるかと思います。自分自身で考えてチューニングしていきましょう。

連載「Webサイト・アプリ高速化テクニック徹底解説」の第4回は、JavaScriptのチューニングのうち、ボトルネックになりやすいDOM操作の最適化について解説します。前編・後編にわたって、DOM操作が遅くなる原因と仕組み、その解決策について詳しく解説します。

DOM操作の最適化によるJavaScriptチューニング（前編）

DOM（Document Object Model）とは、HTMLをアプリケーション（ここではJavaScript）から利用するためのAPIです。JavaScriptによるユーザーインターフェースの構築やレスポンスの表示など、インタラクティブな部分はほとんどがDOM操作によるものでしょう。このように、非常に利用頻度の高いDOM操作ですが、同時に性能的にボトルネックになりやすい箇所でもあります。これらのDOM操作の最適化について、今回から前編・後編にわたって詳しく解説していきます。

DOM操作は書き方によってスピードに数十倍の差が出る

DOM操作は、書き方によって非常にパフォーマンスに差が出ます。例えば、次のようなコードを見てみましょう。id属性に”output”と指定された要素に、data配列の中身を単純にリスト表示するだけのものです。

:javascript:
// サンプル1: パフォーマンスが悪い
var ul = document.querySelector('#output');
for ( var i = 0; i < data.length; i++ ) {
  ul.innerHTML += '<li>' + data[i] + '</li>';
}

これは、非常にパフォーマンスが悪い例です。これを次のように書き換えるだけで、環境にもよりますが速度は数十倍にもなります。

:javascript:
// サンプル2: サンプル1に比べてパフォーマンスが良い
var ul = document.querySelector('#output');
var html = '';
for ( var i = 0; i < data.length; i++ ) {
  html += '<li>' + data[i] + '</li>';
}
ul.innerHTML = html;

このように、ボトルネックとなっているDOM操作をチューニングすれば、パフォーマンスが大きく改善する可能性があります。ここからは、DOM操作が遅くなる原因と仕組みを解説しながら、対応策を見ていきます。

なぜDOM操作は遅いのか？

DOM操作はなぜ遅いのでしょうか。それには、大きく2つの理由があります。1つ目は、DOMの実装方法によるものと、2つ目は、DOM操作によるレンダリングのコストが非常に高いということが挙げられます。この2つの理由と対応方法を覚えておけば、さまざまなコードに応用できます。それぞれ見ていきましょう。

ブラウザの実装による遅さ

元々DOMは、特定のプログラミング言語を対象としたものではなく、別々の言語から汎用的にアクセスできるような仕様になっています。そのため、多くのブラウザでは、HTMLのレイアウトや描画を担当するレンダリングエンジンと、JavaScriptを担当するスクリプトエンジンに分かれています。このようにスクリプト部分をモジュール化することによってDOM操作に別のプラグラミング言語を使うことも容易になっています。しかしながら、そのデメリットとして、JavaScriptからDOM操作を行うということは、モジュール間をブリッジするコストが発生することにもなります。そのため、DOM操作自体がプリミティブな操作に比べて非常に低速になっています。そういった観点から、HTMLの要素の単純なプロパティ参照なども含めて、極力DOM操作を減らすようにすることが重要です。

レイアウト・レンダリングによる遅さ

DOM操作の結果は、実際のHTMLに反映される際に、ブラウザでさまざまな処理が起こります。例えば、要素が追加された場合には、それによって発生する各要素の大きさや位置といったレイアウトを他の影響する要素を含めて、すべて再計算しなければなりません。また、レイアウトの再計算が終わったあとには、それらを画面にレンダリングする必要もあります。そして、これらの処理は非常にコストが高いものです。そのため、DOM操作によってレイアウトやレンダリングに影響がある範囲、回数をなるべく減らす必要があります。

例えば、冒頭に示したサンプル1のコードでは、次のようにli要素をループが回るたびに追加しているため、レイアウトとレンダリングが何回も発生して非常に遅くなってしまう可能性があります（レイアウトやレンダリングは非同期で処理されるため、実際にはブラウザがある程度、自動的に最適化してくれます）。

:javascript:
// 複数回、レイアウト、レンダリングされる可能性がある
for ( var i = 0; i < data.length; i++ ) {
  ul.innerHTML += '<li>' + data[i] + '</li>';
}

innerHTMLを利用しているため、少なくてもHTMLのパースはループのたびに発生します。また、古いブラウザでは文字列の連結自体が問題になることもあります。このコードを、レイアウトとレンダリングが1回になるように書き換えると次のようになります。（その他にも、innerHTMLを「+=」演算子で余分に参照していることや、innerHTMLの中身を毎回すべて書き換えていることも遅さの原因になっていますが、次のコードではそれらも改善しています。）

:javascript:
// 変数にHTMLを格納しておき最後に1回だけ書き換える
var html = '';
for ( var i = 0; i < data.length; i++ ) {
  html += '<li>' + data[i] + '</li>';
}
ul.innerHTML = html;

最終的に、結果が表示されれば良いので、li要素のHTMLは、いったん別の変数に格納しておき、最後に1回だけinnerHTMLへ代入しています。これによって、DOM操作の回数もレンダリングの回数も以前のコードに比べて1回で済みます。

innerHTMLとDOM操作メソッド

ここまでのサンプルでは、innerHTMLを使ってDOM操作を記述していますが、createElement()やappendChild()などのDOM操作メソッドを使う方法もあります。次のサンプルは、サンプル2をDOM操作メソッドを利用して記述した例です。

:javascript:
// サンプル3: createElement()を使った例
var ul = document.querySelector('#output');
var fragment = document.createDocumentFragment();
for ( var i = 0; i < data.length; i++ ) {
  var li = document.createElement('li');
  li.textContent = data[i];
  fragment.appendChild(li);
}
ul.appendChild(fragment);

innerHTMLとDOM操作メソッドは、それぞれ良い点がありますが、基本的にはDOM操作メソッドを使っていくほうがクロスサイトスクリプティングの脆弱性を作りこみにくいので安全です（innerHTMLは、文字列をパースするためユーザーの入力値を使う場合はエスケープする必要があります）。これらのDOM操作メソッドを利用する方法は、次回で詳しく取り上げていきます。

innerHTMLとDOM操作メソッドのスピード

innerHTMLとcreateElement()などのDOM操作メソッドは、どちらが速いかといった形でよく比較されることが多いですが、パフォーマンスという観点からはそれほど気にしなくても良いでしょう。モダンな環境では、お互いの速度差はそれほど大きくありませんし、ブラウザは常にバージョンアップされていますのでベンチマークの結果はすぐに変わります。特定の環境に特化したチューニングを行うのでなければ、細かい速度差を気にするよりは、機能の違いで使い分けていきましょう（ちなみに、現在はIE、FirefoxはinnerHTMLの方が若干速く、Chrome、SafariはDOM操作メソッドの方が若干速くなっています）。

次回の内容について

今回は、DOM操作が遅くなる理由と、その対処方法について簡単に解説しました。次回は、createElement()によるDOM操作と、チューニングのためのさまざまなTipsを紹介していく予定です。お楽しみに！