ChromeやNode.jsで利用されているJavaScriptエンジン「V8」に、8年の歴史の中でも大きな変化が訪れました。8月3日にリリースされたバージョン6.1で、数年かけて進めてきたJavaScriptコンパイラーが世代交代を終えました。詳しい話は、V8のブログでも語られていますが、ここでは大きなトピックであるコンパイラーの世代交代についてお話します。

なお、この動きについては、昨年に開かれたカンファレンス「BlinkOn 6」でも語られており、Google I/O 2017でも、Seth Thompsonによるセッション「V8, Advanced JavaScript, & the next performance frontier」によって紹介されています。本記事では、これらの発表内容を補足してご紹介します。

V8のミッションとは？

Chromeで使われているJavaScriptエンジン「V8」ですが、そのミッションはとてもシンプルです。

「Speed up real-world performance for modern JavaScript, and enable developers to build a faster future web.(実世界での要求にあわせてモダンなJavaScriptのパフォーマンスを向上させること。そして、今後の変化していくWebに早く追従し、開発者がそれらをビルドできるようにすること)」

V8のパフォーマンス改善につきまとう2つのトレードオフ

V8とはなんでしょう？JIT(just-in-time compile)で動作させることができるJavaScriptのエンジンです。ブラウザがJavaScriptを受け取ると、ブラウザはそのコードをトランスレートして実行したり。また、コードを翻訳してコンピューターが理解できるネイティブコードにコンパイルしてから実行します。

ただ、そこにはいくつかのトレードオフが存在します。

1. コンパイルして生成されたネイティブコードは、実行されるピーク時の速度が早い一方で、コードの量が多いほど、最初に実行されるまでに遅延が発生する。一方で、トランスレーターを使った場合は、実行されるまでの遅延は小さいけど、実行時の速度が遅い。
2. JavaScriptエンジンは、パフォーマンスを良くしようとするとメモリの消費量が多くなる。一方で、省メモリを進めようとするとパフォーマンスは悪化する。

例えば、以下のような一行のfunctionを呼び出すコードについて考えてみましょう。

このコードでは、 function foo() は一度しか呼び出されていませんよね。このケースでは、実行されるまでの速さ（Fast Startup）を重視し、実行時のパフォーマンス（Peak Perf）は重要視しません。

しかし、以下のケース。

1万回も function foo() を呼び出しています。このケースでは、Fast Startupが遅れてでも、Peak Perfを重視する必要がでてきます。 foo() はネイティブコードにコンパイルされていなくてはいけません。そしてそれがデスクトップ型のコンピューターであれば、メモリも潤沢なので、大量のメモリ消費を犠牲にネイティブコードをさらに幾度に渡り最適化させます。

ただ、これはあくまでデスクトップ型コンピューターの場合。同じ1万回 foo() を呼び出すコードであっても、モバイルの場合は同じアプローチにはなりません。Androidデバイスはモバイルなので、デスクトップと同じようにメモリを扱うことはできません。

ネイティブのコードへコンパイルはされますが、メモリの消費量は抑えられるよう最適化は制限されます。

別のパターンについても考えてみましょう。それが以下のコード。

これはNode上で実行されているコードです。一度起動されたら、ずっと利用されるわけですから、当然、Fast Startupを犠牲にしてPeak Perfを改善しようとしますね。しかし…

IoTデバイス上で動作するとなると、同じ状況とは言えません。サーバー用マシンとは異なり、メモリ消費は抑えなくてはいけません。Peak Perfを上げるようにはしますが、それはメモリ消費が少なくて済むようなアプローチで進めます。

同じ一行のfunction呼び出しであっても、その最適化方法は無数にあり、コンテキストやデバイスの状況に強く依存するのです。そしてそれは、Fast Startupなのか、あるいはPeak Perfに最適化していくのか、メモリを富豪的に扱うのか、それとも小さくなるよう努力するのか、解決しなくてはいけません。

8年前のリリース時点から全てが変わろうとしているV8

V8エンジンは、ここまでに説明したあらゆる状況で最適化できるようにしたり、また新しいパターンのJavaScript（asm.js, WebAssembly等）に対応できるよう、2〜3年かけて実行パイプラインを作り変えました。

過去の変遷を見てみると。

2008年のリリース時点の段階では、シンプルなコードジェネレーターがあって、そこからやや最適化を行ったマシンコードが生成されるだけでした。あらゆるJavaScriptのコードは、この仕組を使って実行されます。

ただ、最適化には計算が必要なため、コードを実行できる状態にするまでに多くの時間を要します。大量のJavaScriptコードを扱う場合は、Startup Time短縮するために最適化の処理をスキップすることが求められます。

2010年にコンパイラ「Crankshaft」が追加されます。計算コストの高い最適化処理を分離し、Crankshaftにその責務が委譲されました。コードの生成だけであれば、Full-codegenは最小のコストでマシンコードを吐き出すため高速なため、Startup Timeが最適化されます。そして、CrankShaftを使ってコンパイルすれば、計算コストを犠牲にPeak Perfにとって最適なマシンコードが生成されます。

実行時に、CrankShaftが吐き出したコードを、Full-codegenが吐き出したコードへ置き換えることで最適化を図ります。

2015年。Crankshaftには限界が来ます。JavaScriptの仕様そのものが大きく変化する時代になりましたが、Crankshaftはその設計上、JavaScriptの機能をサポートしきれず、また新しいパターンのJavaScript（asm.js, WebAssembly等）にも十分に対応できませんでした。当時のフロントエンドエンジニアなら、V8のECMAScript標準への対応の遅れに苛立ちを感じたはずです。

V8開発チームは、それを改善しようと新たなコンパイラ「TurboFan」を追加します。

2016年。「Ignition」と呼ばれる仕組みを追加しました。Ignitionには、ソースコードをいきなりマシンコードにするのではなく、バイトコード(マシンコードほどハードウェアに依存しない「中間コード」と呼ばれるもの)を生成するコンパイラーと、それを実行するインタプリターが内包されています。

そして、TurboFanはバイトコードを扱う形へと作り変えられました。そして現在、最新のVersionである5.9では、この2つの仕組みは既に使われていません。内部にコードこそ存在していますが、バイトコードの生成と解釈するインタープリターIgnitionと、PeakPerfを改善するための処理をするコンパイラーTurboFanだけで動作しているという状況です。

そして、これからまもなくリリースされる6.0では、コードとして完全にV8から削除されます。

「Ignition Interpreter」とは？

中間コードを生成して実行するインタプリター。メモリ消費が小さく動く、Fast Startupも最適という特徴があります。

• モバイルなどのメモリの小さな環境で動かすのに最適。
• Startup Timeに最適化すべきコードの実行に向いている。
• TurboFanと組み合わせることで、実行速度を最適化できる。

「TurboFan」とは？

主として、最適化を行うことを目的としたコンパイラー。

• 使われ方としては、拡張的な感じ。ただ、あらゆる新しいJavaScript機能に対応していき、その場合も活用される。
• WebAssemblyのバックエンドでもある。
• 最近はtry/catch/finallyとか、ES2015+の最適化が可能になった。

まとめ

V8について、メモリ管理向けガーベジコレクター「Orinoco」など、さまざまな技術要素が進化し、語り尽くせないほどのトピックがあるのですが、それはまた別の機会にお話しましょう。TurboFanへの完全移行、実態としてすでにほとんど終わった状況といっても過言ではありませんが、8年前とは全く異なる、Web・JavaScriptの変化に追従する大きな変化です。今後も楽しみですね。

こんにちは、ふろしきです。HTML5 Conference 2016の当日は、38度近くの熱があり、発表時はろれつが回ってませんでした。しかし、伝えたいことは伝えられたと思っています。その内容とは…

「この1年でWebのパフォーマンスの技術にどんな動きがあったのか」

というダイジェスト。ここで話した3つのテーマについて、本記事でもご紹介。

1. レイアウト処理を減らす

HTML5がバスワードするよりもずっと前から、CSSでアニメーションさせることはごくごくあたりまえ。JSが扱えないデザイナーであっても手軽にアニメーションできる良い世界になりました。しかしそこに、モバイルが出現したことで、JSだけで満足という人たちもCSSの機能を活用しなくてはいけなくなりました。

モバイルのUIによくありがちなのが、あるコンポーネントの形状を変化させるようなアニメーションや、スワイプ操作のような指の位置に応じてコンポーネントを動かすもの。それを描画するとなると、CPUはあまりにも非力で、GPUの力を借りることが求められています。CSSはGPUと相性がよいため、JSからCSSの機能を呼び出して効率的にGPUを活用するということが求められています。

そのアプローチについては、HTML5 Experts.jpでも「モバイルWebのUIを速くする基本テクニックがわかる──Google I/O 2016 High Performance Web UI」で紹介していますので、本記事では簡単にだけ説明。

GPUでできることは、極めてシンプル。ある四角形の描画結果を、どの位置に表示させるのか、拡大縮小させるのか、回転させるのか、といった変更加えるだけ。それだけでいいというのであれば、CPUを介さず、GPUのみで描画処理を完結させることができます。

これをブラウザで行う場合は、ある特定のDOMとその配下にあるDOMの描画結果をGPU側に転送し、GPU側にどういう描画を行わせるのか指示を送ることで、高速に処理させます。その間、操作はすべてCSSのプロパティを使って行うことになります。

CSSも、従来の left や top といった、レイアウトを操作するようなものではなく、 transform プロパティ経由で指定。 JS上で、以下のように指定することで、CPUによるレイアウト処理を避けつつ、GPUで描画の位置のみを変えるというもの。

// ある要素の横の位置を移動
elem.style.transform = `translateX(#{position}%)`;

この方法は一昔前には泥臭いとされ、バッドプラクティスと考えられていました。しかしそれも、最近は will-change というCSSプロパティが正式に標準化の流れに入ったことで、考えが改められています。GPU上に描画結果を保存させるのはバッテリー消費が大きいため、開始時に will-change: transform; で有効にし、終了時には will-change: none; で解除する、という流れになります。

簡単な例をあげると、以下の通りです。

// スワイプ時、指の位置にあわせてコンポーネントを左右に動かす。
class MovableComponent {
  constructor(elem) {
    this.elem = elem; // 動かす対象のコンポーネントのDOM
  }
  // ある要素の横の位置移動を開始
  function begin(beginX) {
    this.x = beginX; // 開始位置をセット
    this.elem.style.willChange = 'transform'; // GPU側に描画結果を置く
  }
  // 位置を変更(指の位置がかわるごとに呼び出される)
  move(currentX) {
    this.x = currentX; // 現在の位置をセット
  }
  // 描画(requestAnimationFrameで毎回呼び出される)
  render() {
    this.elem.style.transform = `translateX(#{this.x}px)`;
  }
  // 横移動の完了
  end() {
    this.elem.style.willChange = 'none'; // 解除
  }
}

2. スクロールイベントを減らす

ブラウザのscrollイベントが、スクロールの滑らかさを落としてしまう。とはいえ、「どれだけスクロールされたのか？」というのに応じて何かしらのJSの処理を動かしたくなるという需要はなくならず、できるかぎりパフォーマンスを上げようという努力はされてきました。

2015年の4月にChromium Blogにポストされた「Chromium Blog News and developments from the open source browser project 」は有名な話です。Chromeではブラウザ上で動作するタスクに優先度を与え、JSの処理やブラウザ側の内部で行われる処理のうち、スクリーン上への描画が関わるタスクを優先的に扱うようにすることで、スクロールの滑らかさを損なわないようにしようという取り組み。確かに、ユーザーの体感としてパフォーマンスは上がったようにみえるでしょう。

しかしこの問題、その本質は、イベント自体が無駄に多く呼び出されてしまっているというところが大きかったりします。したがって、ユーザーワールド側でも、scrollイベントを毎回素直に実行するのではなく、頻度を落として実行するThrottlingという方法が一般的になっています。

これらはパフォーマンスを改善する上で、たしかに有効ではあります。ただ、デベロッパーが本当にやりたいことに目をむけ、そこにより特化した機能をブラウザ側が持てば、もっと良い解決につながるのは間違いありません。ハードウェアが貧弱で、スレッドの扱いに制約の多いブラウザでは、そこに踏み込んだアプローチが求められています。

scrollイベントの利用ケースで、かなり多いもののひとつに「画像の遅延読み込み」があげられます。例えば、ATF(Above The Fold : Webページアクセス直後にスクリーン内に映り込む領域)の表示を速くしたい！それこそ、headタグ内の大量のCSSファイルやトップの巨大な画像ファイルに帯域を譲らないことには高速化が困難ということになれば、ATF外にある画像ファイルは後から読み込んだほうがいい、ということになります。もちろん、サーバーの負荷を下げるという用途でも活用されるでしょう。

それを解決する方法として、Web標準「Resource Priorities」にて、lazyloadというプロパティをHTMLのタグに追加しようという流れが生じ、IE11にも実装されたのですが、「そもそもそういう用途で使われるようなプロパティは追加されるべきなのか？」「本来JSであったり、より低レイヤーなアプローチで解決すべきでは？」という意見もあり、削除されてしまいました。

あれから2年が経ち、lazyloadは理想的な形で実現できるようになりました。それが「Intersection Observer」です。

Intersection Observerは、スクロール時に特定のDOMがスクリーン上に現れるタイミングでイベントを発火させてくれます。したがって、scrollイベントよりも軽量な上、scrollイベントの多くのユースケースを巻き取ることができます。そもそもDOMの位置を取得する、scrollTop、offset、getBoundingClientRect、といったプロパティやメソッドは、本記事の1章でもあげたような、レイアウト処理というヘビーな処理を呼び出しのタイミングで必要とする場合がある。それも無くなるとなれば、一石二鳥でlazyloadのような類の処理を最適化できるというわけです。

以下、使い方の例。jQuery.lazyloadのようなものを実装するとしたら、以下のようになります。

// 遅延読み込みをさせる専用のObserverを生成
let imageLazyLoader = new IntersectionObserver((changes) => {
  // イベント発火のタイミングで、遅延読み込みさせる
  changes.forEach((change) => {
    let image = change.target;
    image.src = image.getAttribute('data-original');
  });
}, {
  rootMargin: "120% 0" // 読み込みを開始するタイミング
});
// 遅延読み込みさせたいimg要素を取り出し、Observeさせる
let images = Array.from(document.querySelectorAll('img.lazyload'));
images.forEach((image) => {
  imageLazyLoader.observe(image);
});

3. タスクキューの待ちを減らす

最後に、タスクの最適化の話です。ここの話については、ピクシブのブログのエントリー「JSがブラウザを固めてつらいので、新しいAPI「requestIdleCallback」を使うことにした」でも取り上げてますので、ざっくりと背景と概要を。

元々は、2016年頃にMicrosoft側が「setImmediateをちゃんと実装しよう！」と。Microsoftのプラットフォームにおいて、多くのユーザーがsetImmediateを利用しているということを、W3C Web Performance WGのMLで問題提議し、 setTimeout(fn,0) を使ってタスクを遅延実行させるバッドプラクティスを緩和しようという提案から始まった話です。こうした悩みは「requestAnimationFrameで解決されるものだ！」という意見もあったのですが、現実問題としてはそうはうまくいかないというのは、フロントエンドをやっているエンジニアなら感じられたはずです。

そもそもこの問題はどこから生じたのか？一昔前のビデオカードが、１つのスレッドでしか描画を扱えないという制約があった。そういった背景もあり、現在のブラウザもまた、ブラウザの内部の処理からJSで実装したユーザーワールドの処理に至るまで、その多くのUIスレッドと呼ばれる単一のスレッドだけで処理しざる得ない状況となった。その恩恵というべきか、JSはこれだけ単一スレッドで処理実行させることに進化したのですが！JSでやることが多くなってしまった今、本記事の2章でも語られたような「タスクの優先度」に手を加えないことには、解決出来ない問題も多くなったのです。

こうした中ででてきたのが、requestIdleCallbackという機能です。

2章にもでてきた、Chromeのスクロールパフォーマンスを改善した、パフォーマンス周りを専門としているGoogleのエンジニアRoss McIlroyら。彼らが、Microsoftがだした「setImmediateを全ブラウザでちゃんと実装しようぜ！」という案をはねのけて提案したのがこのrequestIdleCallback。

scrollイベントの改善で、彼らはあくまでブラウザ側のタスクの優先度に対して手を加えたわけですが、ここにきてデベロッパーが作ったJSの処理。ユーザーワールドで実行されるものについても、優先度のようなものを与えて、タスクが実行されるタイミングをうまく制御しようという提案をしたのでした。scrollイベントで培ったノウハウを広げようとしたんだろうなぁと、私は推測してます。

requestIdleCallbackはどういうものか？scrollイベントの一件では、緊急度の高いブラウザ内のタスクを、あらゆるタスクよりも優先して速く実行するというものでした。一方でrequestIdleCallbackは、ユーザー側の体験としてパフォーマンスが低いという状況を生み出しがちな、緊急度が低いユーザーワールドのタスクを、あらゆるタスクよりも低く実行するというもの。ブラウザ側だけじゃ限界があるから、デベロッパー側でもなんとかする術というのを提供したといったところです。

その仕組はとてもシンプルで、処理されることを待っているタスクがあれば絶対に実行しない。無ければそのタイミングで実行しようというもの。

サンプルは以下の通り。

var hd = requestIdleCallback( => {
  // タスクキューが空になってから実行されるタスク
},{
  timeout: 10000 // 何msであきらめるか。
});

最後に

CPUからGPUに処理を移したいというお話から、それでもどうしようもないシングルスレッド問題を、いかにして効率的に運用するのかというお話まで。GPUがデベロッパーを幸せにしたり、不幸にされたからどうにかしようとしたり、という感じで、GPUとブラウザのパフォーマンス問題は切っても切り離せないようですね。

ちなみに、この記事を書いている今、TPACというイベントが開かれ、パフォーマンスに関する議論も行われています。そこでは様々な議論が繰り広げられているのですが「Measuring and improving scroll latency (~30m; rbyers)」というスクロールをもっと良くしようよという話や、「Paint metrics」といったレイアウト処理のさらに先の描画系の発展的な話であったり、「Long Tasks API」みたいな、requestIdleCallbackとか以前にタスクの処理時間長くね？ってところをなんとか変えていこうよという議論もあったりします。

個人的に注目しているのは、以前からデベロッパーの間で薄っすら思われていた、SPAの時にブラウザのナビゲーション計測系のAPIが役に立たないのだけどどうするの？って問題に注目しているところです。SPAと一言でいっても、Ruby on RailsのTurbo Linksのようなものもあり、ブラウザの持つページ遷移機能が活用されないケースがある中で、パフォーマンス計測はどうあるべきなのか。「ナビゲーションの開始」と断定することが困難であり、それゆえに画面の切り替わりにどの程度の時間がかかったのかわからないこの問題を、今後どう扱うのかが議論されるようです。

一通り終わったなぁ、パフォーマンス周りの機能整備、なんて思ったのですが、よくよく考えたら実態にそこまで即した感じでもないんですよね。今後も様子を見ておきたいと思います。それでは！

私はHTML5 Experts.jpで、過去2年ほどGoogle I/Oの情報を発信し、Web技術の変化についてお伝えしてきました。振り返るとGoogleは、2014年にモバイルWebの提唱と技術要素の拡大を図り、2015年からは「RAIL（モバイルWebが目指すべきパフォーマンス指標）」や「Progressive Web Apps（アプリのように振る舞うWeb）」といった、モバイルとの親和性が高いWebを作り出すための”考え方”を推し進めました。今年2016年は、さらにそれを踏み込んでいったという感じがします。

今回のI/Oで取り上げるのもそのひとつ。毎度お馴染みGoogle Developer AdvocateのPaul Lewis氏による 「High performance web user interfaces」です。彼は、モバイルにおいて、時にアプリのように振る舞うことが求められる昨今のWeb、すなわち「Progressive Web Apps」について、UIで起こりがちなパフォーマンス問題と、その改善方法について紹介しています。

※ この講演、動画無しでは説明が難しかったり、前提知識も多かったりするので、私でかなりアレンジ・要約して紹介しています。より詳細に内容を知りたい場合は、ソースをみることをオススメします！

Webは時として、モバイルアプリのような体験が求められる

モバイルにおいて、ホームスクリーンは重要な場所だ。人々はホームスクリーンから、目的を達成するためのアプリを起動する。Webは、Add to Homescreenを使うことで、ホームスクリーンからWebサイトへアクセスすることができるようになった。

するとどうなるか。このホームスクリーンをよくみてほしい。どれがWebで、どれがネイティブアプリなのかは見分けがつかないだろう。Google Mapsなんかはネイティブにみえるけれど、他はまったく想像がつかない。しかしこれらが、Google Mapsと同様にネイティブアプリにみえるなら、Webはネイティブアプリのように振る舞うことが求められている。

パフォーマンスモデル、インタラクションモデルの2つによって、Webはモバイルネイティブアプリのような振る舞いをえることができる。Progressive Web Appsを実現することができる。今日はこの2つのモデルのうち、パフォーマンスモデルの話をしたい。

昨年は、Paul IrishやIlya Grigorikなどの私のチームのメンバーが、「RAIL」というパフォーマンスモデルについて話した。RAILとは、Responseは0.1秒、Animationは16ミリ秒、Idleは50ミリ秒、Loadは1秒で動作すべきというもの。ただ、それを聞いた人々は、たまに勘違いをする。この4つの要素は、どれも全て、最も重要なこととして語ってしまうのだ。それは間違っている。

例えば、Webサイトにおいて、タップした時に求められるのは、4つの要素のうちLoadが重要になる。Idleが重要になることはそこまでない。そして、ホームスクリーンからタップして起動されるProgressive Web Appsでは、ResponseやAnimationが重要になる。Webサイトをつくるのと、Progressive Web Appsをつくるのでは、求められることが違う。

さて、このようにパフォーマンス面で求められることが異なるProgressive Web Apps。そこに、3つのコンポーネントがある。Side Navigation、Swipeable Cards、Expand an Collapse。これらを実現するセオリーを紹介しよう。

1. Side Navigation

まずは、このコンポーネント。メニューボタンをタップすると左からスライドインするバー。これは、2つのElementによって構成される。半透明の黒い背景と、サイドメニューを表示する領域だ。

このサイドメニューの部分のCSSは非表示の時、CSSにpointer-events: none;を指定する。そして、表示されたタイミングでpointer-events: auto;を指定する。

そしてここからが大事な話。左から右、あるいは右から左に移動させる際に、transformを使う。ブラウザがDOMの位置を変更する際に、CPUを使ったレイアウト変更してはいけない。GPUの力を借りて、描画位置を変更することで、最適なパフォーマンスを得ることができる。

例えば、一昔前。サイドメニューが左に消えている時にCSSは

.side-nav {
  position:       fixed;
  left:           -102%; /* DOMのレイアウト位置を左にずらしてメニューを隠す */
  top:            0;
  width:          100%;
  height:         100%;
  over-flow:      hidden;
  pointer-events: none;
}

と、left: -102%で隠す。これは一般的な方法だった。しかし、描画を高速に処理できるGPUの恩恵を受けたいなら、transformを使って以下のように記述する。

.side-nav {
  position:       fixed;
  left:           0;                 /* DOMのレイアウト位置は常に0のまま */
  top:            0;
  width:          100%;
  height:         100%;
  over-flow:      hidden;
  pointer-events: none;
  transform:      translateX(-102%); /* 描画の位置を左にずらすことでメニューを隠す */
  will-change:    none;              /* <- これは何！？ */
}

サイドメニューのDOMのレイアウト位置としては、x位置のleftもy位置のtopも、0のまま。横幅widthも縦幅heightも、100%ということで、全面を覆っているという扱いになる。しかし、transform: translateX(-102%);で描画の位置自体を、左に寄せている。

そして、ここで登場するのがwill-chanage: none；だ。

一昔前にtransform: translateZ(0);をCSSプロパティに指定して、パフォーマンスを改善するというハックが出回ったのをご存知だろうか。このCSSが指定されると、描画には必然的にGPUの力が必要になるため、強制的にGPUに描画を依頼することになる。GPUの恩恵を受けるために活用されたこのバッドノウハウは、will-chanage: transform；という新しいCSSプロパティをWeb標準として追加することによって、同様のことを実現できるようにした。(※注:実態はブラウザ対応の問題もあり、今もtransform: translateZ(0);を使うのが一般的)

ただ、transform: translateZ(0);やwill-chanage: transform；といったCSS指定は、常時ビデオカード上のRAMメモリーに描画結果をテクスチャーとして保存することになる。モバイル環境では、バッテリー消費などに悪影響を及ぼすことになる。動作するタイミングだけwill-chanage: transform；を指定し、動作しない時は無効化will-chanage: none；するといい。これが、バッテリー消費パフォーマンスと描画速度パフォーマンスのトレードオフ問題に対する、落とし所だ。

黒背景については、will-change: opacity;というプロパティがあり、transformと同様の方法で、高いパフォーマンスで描画させることができる。(※ JSの実装については、「2. Swipeable Cards」にノウハウが似ているので割愛)

2. Swipeable Cards

CSSを使ったパフォーマンス改善のテクニックの他に、注意しなくてはいけないのが、スワイプ操作時のコンポーネントの移動処理。ユーザーからの指の位置状況を入力し、それをスクリーン上に反映しなくてはいけない。この際、有用なのが「ゲームループ」のノウハウだ。

描画のイベントは常に、1/60秒ごとに発生する。対してスワイプのイベントは、常に一定には発生しない。描画のタイミングにはあわせてくれないのだ。

そこで、スワイプにより発生するイベントについては、変数に位置情報だけを記録する。そして、描画時のイベントでは、記録された位置情報を元に、CSSを通じて描画位置変更をおこなう。

スワイプの開始時・移動時・終了時は以下の通り。this.startX、this.currentX、this.targetXといった変数に、現在の位置や、移動すべき位置を記録している。

/**
 * スワイプ開始
 */
onStart(evt) {

  // スワイプの開始位置を記録する
  this.startX = evt.pageX || evt.touches[0].pageX;
  this.currentX = this.startX;

  // cardの移動が開始されたことを記録する
  this.draggingCard = true;

  // will-change: transform; を有効にする
  this.target.style.willChange= ‘transform’;

  // カード上の要素にイベントを伝播させないように
  evt.preventDefault();

  // アニメーションを開始する
  requestAnimationFrame(this.update);
}

/**
 * スワイプ移動時
 */
onMove(evt) {

  // スワイプの現在地点を記録する
  this.currentX = evt.pageX || evt.touches[0].pageX;

}

/**
 * スワイプ終了時
 */
onEnd(evt) {

  // cardを削除すべきかどうか判定する
  let translateX = this.currentX - this.startX;
  const threshold = this.cardWidth * 0.35;
  if( Math.abs(translateX) > threshold ) {

    // cardの移動先をスクリーンの外へ(※cardは削除)
    this.targetX = (translateX > 0) ? this.cardWidth : -this.cardWidth;

  } else {

    // cardの移動先を最初の位置へ(※cardは削除されない)
    this.targetX = 0;

  }

  // cardの移動が終了されたことを記録する
  this.draggingCard = false;
}

描画のタイミングにrequestAnimationFrameから呼び出されるコールバックで、先ほどの位置情報を元に反映していく。

/**
 * 描画内容の変更
 */
update(evt) {

  // 次の描画タイミングでも自身を呼び出す
  requestAnimationFrame(this.update);

  // スワイプ中の場合
  if( this.draggingCard ) {

    // 現在の位置を描画させる
    this.translateX = this.currentX - this.startX;

  // スワイプが完了している場合
  } else {

    // カードを削除するかしないかに応じて指定の場所に能動的に移動する
    this.translateX += (this.targetX-this.translateX)/4;

  }

  // CSSプロパティを経由してGPUに変更を伝える
  this.target.style.transform = `translateX(${this.translateX}px)`;
}

(※ この後の処理については、「3. Expand and Collapse」にノウハウが似ているので割愛。)

3. Expand and Collapse

タップすると、領域が広がり全体化されるUIコンポーネント。CSSではどうするのか？もちろん、ここまで説明してきた「transform」を活用する！では、JSについてはどうか？実は、「2. Swipeable Cards」とは異なり、スワイプ操作でなくタップによって、自動的にアニメーションする。この点で、より効率的な実装が求められる。

まず、アニメーションについて、動作中の状態はJS上で持たない。動作前後の状態だけを、CSSプロパティを通じてGPUに指示する。

// 変化量を計算する
invert.x = first.left - last.left;
invert.y = first.top - last.top;
invert.sx = first.width / last.width;
invert.sy = first.height / last.height;

// 変化後の状態をCSSプロパティを通じてGPUに指示
card.style.transformOrigin = ‘0 0’;
card.style.transform =
    `translate(${invert.x}px, ${invert.y}px)
      scale(${invert.sx}, ${invert.sy})`;

そのままでは、タップした要素は一瞬にして全体化されてしまう。どのようにして何ミリ秒もかけて徐々に広げていくか？その方法は、CSSで指定する。JSではない。原理的には、従来よく使われているCSSアニメーションだ。

.cards {
  transition: transform 0.2s cubic-bezier(0,0,0.3.1); // アニメーションさせる
}

ここまで、Progressive Web Applsのパフォーマンス改善の話をしてきたが、「Google DevelopersのRendering peformance」が役に参考になる。一読するといいだろう。

Progressive Web Appsのパフォーマンス改善。要はこう言いたかった

いかがでしたでしょうか？文字数の制限やコンテキストの高さもあり、多くのエンジニアに伝わるようかなりアレンジしてみましたが、ご理解いただけましたでしょうか？

Paul Lewis氏が言いたかったことは単純な話です。先ほどのGoogle Developersの記事にもありますが、Progressive Web AppsにおけるAnimationやReactionの課題は、いかにしてブラウザのレンダリング処理における「レイアウト」を減らすか、という話です。この講演は、そのTIPS集といえます。

今日のノウハウ、特に新しいというわけでもなく2年前には既に実践されていたことです。実際のところ多くの現場では、OnsenUIやIonicのようなUIライブラリを活用することになり、このあたりの話を意識することはないのでしょう。ただ、Webのサービスを作っているフロントエンドエンジニアにとっては、ライブラリの有無に関係なく知っておくべき知識のように思えます。サイドメニューについては、Webサイトであっても鉄板のUIコンポーネントなので、Progressive Web Appsか否かはもはや関係ないノウハウだったに違いありません。

Webがモバイルに順応していくことは、今後もさらに求められていきます。これは、フレームワークやライブラリに限った話ではなく、トータルにみたWeb、フロントエンドへの要求に変化を与えるに違いません。

今後も、モバイルとWebの関わりに、目が離せませんね。

最近、モバイルではネイティブ一強という状況にみえます。Webはあまり注目されません。今後も同じ状況が続くのでしょうか？そのことについて、Google I/O 2015のセッション「The Next Generation Mobile Web」が参考になります。補足を加えつつ翻訳してみましたので、どうぞご覧ください。

But What About Mobile

Webはパワフルな技術だ！これからも、ビジネスをもっと盛り上げていく。2014年、Eコマースは低く見積もっても1.5兆ドルの規模になった。そんな中、モバイルは何を変えたのか？ユーザにどんなインパクトを与えたのか？

モバイルは経済のシフト、デスクトップが担っていた領域の変化だ。パフォーマンスが求められるような動作も、従来のPCとは違い、バッテリーで動いているデバイス上で実現しなくてはいけない。必要とされる機能も完全に変わってしまった。プッシュ通知はモバイルのポテンシャルを高める上で重要なのだが、Webにそれはできなかった。結果、ネイティブの方が当然良く見えるわけだ。

しかし、我々は全てをネイティブアプリに置き換えるべきなのだろうか？ネイティブにはいいところがあるけれど、Webもまた負けないいいところがあるはずだ。

みなさんは、Chrome Dev Toolsがどれだけの人に使われているのかご存知だろうか？Androidは400万人/週だが、Dev Toolsは2,500万人/週に使われている。そして、素晴らしいことに、今もなお増加し続けている。全ての人が巨大で複雑なWebサイトを作っているわけじゃないし、中にはあまり上手くWebサイトを作れていない人もいる。けど、少なくともDev Toolsを使っているみなさんは十分にスキルが高い。今からするこの話は、そんなWebを愛する2,500万人のあなたたちに伝えたい。

Reach

Webサイトはツリー型だ。例えば以下の図だと、ノードにあたるのがPinterest.comみたいなサイトで、あなたたちのサイトはその葉にあたる。URLからURLへ、ノードから葉へ飛ぶ。異なるサイトであっても、リンクからリンクへ飛ぶことはそんなに難しいことじゃない。サイトの奥地へだって行ける。

人間が使うモバイルアプリは平均12から20と言われている。しかし一方で、アクセスされるWebサイトは、一ヶ月あたり100ドメイン以上だ。それはWebが、リンクを使って簡単にアクセスできるからだ。USにおいて、85%のリテーラーはモバイル上のトラフィックがWeb経由でやってくる。これがWebの持つパワーなのだ。

Performance

では、これらのリーチに対して、Webページはどの程度のパフォーマンスが必要なのか？ページの読み込み時間か？いや、それでは十分とは言えない。実際にはもっと様々なメトリクスがある。スクロールだってサクサク動かなくちゃいけないし、アニメーションも60fpsで動かすべきだ。ただ、どんなパフォーマンスをどれぐらい速くすれば十分なのかは、なかなかわからない。

その答えとして「RAIL」というコンセプト挙げている。Reaction、Animation、Idle、Loadの略称だ。RAILでカギとなっている考え方は「When is performance ‘Good Enough’? When the user can’t perceive it.(十分な速さとは、ユーザがそれを気にしないことだ)」だ。そしてそれを実現するために、60fpsを意味する16.67ミリ秒、100ミリ秒、1秒という時間に注目している。

RAILのR、Reaction Timeは、例えば画面にタップするなどのアクションに対して、100ミリ秒未満でリアクションすることを求めている。そうでないと、ユーザはそのアプリが、壊れているだとか遅いだとか感じるだろう。100ミリ秒未満で、ボタンの色を変えたりインジケーターを回したりすれば、フリーズしたようには見えない。

RAILのA、Animation Time。アニメーションは、16.67ミリ秒未満で動作することを求めている。RAILのI、Idle Timeについて。JavaScriptなどでデコードなどの重い処理を行うと、UIが固まってしまう。処理をチャンクを使うなどして分けて、Idleを作り出さなくてはいけない。その期間は50ミリ未満が望ましいだろう。そうすることで、RのReaction Timeの100ミリ秒未満は守られるだろう。

RAILのLは、みなさんもよく知っているLoad Timeだ。これは1秒未満が望ましい。ただ、これに関しては、Service Workerを使えば、読み込み時に動作中であることをユーザに伝えることができる。

Chrome開発チームには現在、約200人程度のエンジニアがいる。そしてその多くは、パフォーマンスを改善するために働いている。モバイルを良くしようと、様々な取り組みを行っている。その全てを深く語るには、時間が足りなさ過ぎている。一つだけ紹介すると、例えば「スケジューラー」。これはパフォーマンスを劇的に変えたと思っている。タスクの優先度が変わったことで、スクロールのパフォーマンスが大きく改善されたのだ。

パフォーマンス改善は、とても難しいことにみえるかもしれない。しかし臆することはない。博士号なんか取得していなくても、ちゃんとできる。Chrome Dev Toolを使って、サードパーティスクリプトであったり、リソースのパフォーマンスを計測して、問題を探るのだ。そして、RAILをゴールとして、パフォーマンス改善を行っていけばよいだろう。

Engagement

モバイルWebに欠けていたのは、エンゲージメントだ。しかし今、Webにはエンゲージメントを助けるたくさんの機能がある。ただ同時にそれは、セキュリティ面に大きな課題を抱えている。

例えば、background sync(Service Worker)なんかは、Webページを閉じていても簡単にコンテンツの読み込みや送信ができてしまう。あなたが一ヶ月に100のサイトへアクセスするとして、その全てでbackground syncが有効になることは望まないだろう。質の悪いWebページにアクセスしようものなら、Background syncが裏で動き続け、バッテリはどんどん消耗されるなんてこともある。バッテリー効率の悪いネットワーク処理を、ガンガン動かすことが可能だからだ。

誰しも、初対面の相手は簡単には信頼しない。Webサイトオーナーとユーザーとの関係は、ゆっくりと築かれる。ネイティブはアプリのコピーがWebほど簡単ではない。ストアがいて、その開発元も明かされているからだ。しかしWebはオープンだ。パーミッション機能は慎重に作られていなくてはいけない。ユーザに確認して、パーミッションをWebサイト側へ与えることで、初めてリスクの高い機能は使えるようにしている。

さて、これらの機能のうち、有益なものを2つ紹介しよう。

一つ目が「Add to homescreen」だ。例えば興味をもったWebサイトがあったとする。そこに手軽にアクセスしたい。そういう時に、ホームスクリーン上へアイコンを配置しておき、ネイティブアプリのように手軽にアクセスできるようにしておくと、簡単にWebサイトへ飛べる。

実は、古くからそのような機能がブラウザについているのだけれど、設定メニューの中に隠れていたため、手軽では使えなかった。しかし今は、それができるAPIを提供している。これをWebサイト上から呼び出せば、以前より手軽になるだろう。

モバイルWebでユーザ体験を高める場合、ネイティブアプリのような、オフライン対応も重要になる。以前は、「App Cache」がその役割を担っていた。しかしそれは、始めること自体は簡単なのだけれど、メンテナンスにやっかいな問題を抱えている。失敗すると、Webサイトは簡単に動かなってしまう。これを改善し、柔軟なコントロールが行えるようにしたのが「Service Worker」だ。

Service Workerはオフラインで動くスクリプトで、Webサイトにアクセスするとまずそこに問い合わせが行われる。Service Workerは何をすべきか判断し、必要であればネットワークを通じてリソースを取得し、キャッシュへ置くことができる。その振る舞いから、クライアントサイドのJavaScriptプロキシなんて呼ばれていたりする。

Google I/OのWebサイトなんかが良い例だ。Service Workerを使って、必要な全てのリソースをキャッシュに読み込んでいる。Gulpに「sw-precache」というプラグインがある。それを使えば、簡単にService Workerのインテグレーションを、あなたの現場のワークフローへ組み込めるだろう。

Service Workerは、Webページが複数のタブが開かれていても、その全てと通信できる。また逆に、一つも開かれていなくても内部で生存している。それはランダムに起き上がって動くようなことはせず、基本的にはイベント駆動だ。ネットワークなどのイベントを検知して、スクリプトはストレージ内からメモリ上へ移される。だいたい50ミリ秒程度だろうか。その後、Service Workerの処理が実行される。

モバイルであれば、ネイティブアプリのようにプッシュ通知を扱いたい考える事は必然であろう。Anish AcharyaはTechCrunchで「Notification Are The Next Platform(次のプラットフォームは通知だ)」と語っている。通知機能は、エンゲージメントを改革するのだ。

人々がアプリに長く時間を使うのは、人々が通知を受け取るからだ。モバイルの画面を見て、通知を受け取っているのを見て、そこでアプリを使う決断をする。ニュースサイト「The Guardian」はネイティブアプリを提供しているのだが、彼らは事件が起きた時に、そのニュースをプッシュ通知を通じて伝えると、40%のユーザがそこからやってきたそうだ。これはとても多い人数だ。

そんなプッシュ通知だが、今はブラウザから実行できるようになっている。一つの例として、The Guardianのある記事へアクセスした時に、その記事の更新をプッシュ通知を受け取ってみる。

通知の許可を、Webサイト上で行うことができる。

その後、Chromeを閉じ、ユーザは作業を再開する。そして、記事が更新されると・・・この通り！プッシュ通知が飛んでくる。これは他のネイティブアプリと、同じように扱われている。

じつは、今サンプルとして紹介したThe Guardianは、今後本当にプッシュ通知を対応させる予定だ。SNSのFacebookや、商品を扱っているebayやticketmasterでも対応する予定だ。今後も増えていくことだろう。

最後に

いかがでしたか？

Reach、Performance、Engagementは非常に重要であり、これらが効果を上げれば、モバイルWebは上手くいく、というのがGoogleらの答えなようです。

「Web vs ネイティブ」という議論は散々行われてきましたが、彼らはそういう見方をしていないようですね。モバイルの本質を考え、そこからWebの立ち位置を明確化してきたように見えます。

よくよく考えてみたら、モバイルのホームスクリーンはブラウザのブックマーク機能と、そのユースケースに大きな違いはありません。そして、最近のプッシュ通知もまた、アプリの状態を表示するものというよりも、エンゲージメントの高い情報を目立つ所にリスト化しているだけのようにみえます。それはWebのサービスにおいて、メールの通知によって補っていた機能です。いまさら、驚くようなことでもありません。従来デスクトップでもやっていたことを、モバイルのユーザビリティに合わせてきたと捉えられます。

この考え方が、一日でも速く現場にも浸透してほしいですね。そのためにも、「Windows XPの悲劇の再来」にも見えるAndroidのフラグメント化が、一日でもはやく改善してくれることを祈っています。

こんにちは、川田です。今日からHTML5 Experts.jpでは「エンタープライズ開発特集」を始めます。第一弾の今回は、HTML5とエンタープライズITについてのオーバービューを語ります。サーバサイドのお話はわりとよく見ますが、フロントエンドにフォーカスしているというのは珍しいようにも思えますね。

IT自体が幅広い分野のビジネスや製品に変わりつつある昨今、「エンタープライズITの話をするぞ！」と言うと、いろんな方面の人からこう問われます。

「そもそも、エンタープライズって何？」

エンタープライズ、正式には「エンタープライズシステム」になりますが、直訳すれば「企業向けシステム」。一言で言うなら「企業のビジネスを支えるための仕組み」を意味します。企業の業務の効率化を進めたり、経営戦略や問題解決を進めるためのワークプロセス(仕事の進め方)と道具(アプリやインフラ)のことです。

エンタープライズのエンジニアの仕事は、技術的な観点から、経営を良くする方法を提案したり、業務の進め方を設計したり、そのために必要な道具(アプリやインフラ)も調達したり、なければ自分たちで開発したり。サーバからクライアントまで、必要なら机の配置の一つまでデザインする(ネットワークも！)。ぶっちゃけ、ITじゃない方が合理的なら、IT化しないなんてのも提案する。スーパーのレジだって「効率化とかどうでもいいから最安値で作って」と言われたら、ソロバンを薦めてしまうという。それが私たちの仕事です。「SCM」とか「CRM」というキーワードで検索すると、そのニュアンスが伝わるかもしれません。

さて、ここで定義したエンタープライズ（システム）において常に関心が高いテーマとしては、「1.システムの運用」「2.業務の効率化」「3.アーキテクチャ」が挙げられると思います。これらの観点から、「HTML5」という技術要素が、これから先の企業のITをどのように良くしていけるのかをみてみましょう。

1. 「システムの運用」はどう変わるのか？

古今東西、エンタープライズは、システムをできる限りいじらずに、長く運用させることがビジネスとして成立する市場です。欧米においても、古いものは企業と政府に最後まで残り続ける傾向にあるというのが、共通の認識になっています。日本ではInternet Explorer（以下、IE）が高い影響力を持っており、多くの企業がIEの特定のバージョンをサポート期間ギリギリまで使い倒すという方法に走りがちです。しかし、今それが変わることを求められています。

マイクロソフトのサポートは基本は最低10年というルールですが、IEにおいてはもはやそのルールは全く通用しません。昨年、Windows8.1発売時にWindows 8版IE10のサポート期間が短縮化され、そして今年の7月にはとうとう、2016年1月12日以降、最新のバージョン以外はサポート対象外とするというアナウンスを行いました。これは、Google Chromeと同じアップデートのポリシーで、システムはこれからIEの最新バージョンがリリースされる都度、IEのバージョンを上げ続けることが求められています。現時点では、約1.5年周期ぐらいになりそうです。

マイクロソフトは、エンタープライズもコンシューマーも、どちらであってもIEが常に最新のバージョンで運用されるよう改善を進めてきています。その成果として、現在の最新のIEはHTML5に準拠し、高い相互運用性を確保しました。これはつまり、バージョン間の動作の違いが非常に小さいということを意味します。彼らとしては、ブラウザの「バージョンアップ」が、従来の「サービスパック適用」や「セキュリティアップデート」程度のものとして扱われればという狙いがあるようです。

Windows XPのSP2は、元々Vistaになる予定の全く別ものなOSと言われていたのですが、それが運用の中でうまく適用できたというのであれば、これはほんの些細な問題なのかもしれません。運用の進め方さえうまく定着すれば、業務システムのクライアント部分は、OSやミドル、ハードウェアのライフサイクルから開放され、セキュリティ・信頼性・パフォーマンスが最適化された状態で、長期に渡り利用することが可能となります。これはエンタープライズITにとって、HTML5がもたらす大きな価値の一つと言えるでしょう。

最新のIEへの移行、HTML5化を進めるには、以下の機能・ツールが有用です。欧米ではユーザー企業だけで音頭を取って進めていけるため、そのモチベーションは非常にシンプルです。しかし、日本はSIerがシステム開発の中心にいるため、調整にはかなり苦戦するかもしれません。2016年1月までと非常に期間は短いのですが、ユーザー企業・SIerの両方が一丸となりこの取り組みを進め、ユーザー企業のシステム費用の最適化と成長に貢献できればよいですね。

• modern.IE：IEのマルチバージョンテストや、問題点を検出するツール。無償のものが多い。何千台も端末がある場合、段階的に最新バージョンのIEへ移行を進めていくにあたり、このツールが有用になる。
• Enterprise Mode：IE11以上で、暫定的にIE7/8の動作をエミュレートさせる機能。最新のIEに移行した後も、古いIE特化のアプリを動かすことができる。
• Compat Inspector：IE8以下の依存性の高い作り込みを検出するツール。Enterprise Modeも長くはサポートされる保証がないため、最新のIEへ移行した後、このツールを活用して改修を進め、Enterprise Modeをなくしていくことが求められる。

2. 「業務の効率化」はどう変わるのか？

近年、デスクトップPC以外のコンピュータのポテンシャルが注目を集めています。ノートPCにタブレット、スマートフォンにウェアラブルと、デスクトップPCにはない機能、ワークフローのモデルを持ったコンピューターを活用することで、従来の業務をより効率的に変えていこうという考え方が、欧米で広がりをみせています。最近のアンケート結果を見ていると、日本でもモバイルの業務活用に抵抗感がなくなりつつあるようですので、恐らくこれから広がっていくことでしょう。

例えば、ホワイトカラーの場合、マネージャーの決裁をリアルタイム化させるという用途が有名です。スマートフォンに決裁イベントの発生を通知させ、内容を表示し、タッチで完了させるというワークフローを実現させるというものです。部下にも使えるものだと、スケジューラとの連携です。これからミーティングが始まるということを、移動時間も含めて計算し、事前に通知するという仕組みです。このような、様々な種類のデバイスを連動させた業務の設計方法を「モビリティ」と呼びます。

モビリティは、単純にWebアプリをタブレットやスマートフォンで見えるようにするだけでは意味がありません。コンピューターが持つ特性に合わせて、設計することが求められます。例えば、先ほどの決裁のシステムにおいて、「通知」という機能がなかったらどうなるでしょうか？タッチ操作に最適化されていなかったらどうなるでしょうか？

使いにくくて、結局デスクトップ型やノートPC型のコンピュータを使うようになるのがオチです。UXへの理解がないことには、導入がうまくいかないのがモビリティなので、モバイルの活用とUXは、多くの場合セットとして扱われているはずです。業務系のUXは、Webのサービスのようにリピーターを増やすためのものではなく、毎日使う道具を効率化させることに意味があり、このあたりの評価軸の違いにも注目すべきでしょう。

また、スマートフォンやタブレットといった道具側にも工夫が必要です。企業向けとして利用する場合、セキュリティの考え方、開発効率にも意識しなくてはいけません。セキュリティについては「MEAP(Mobile Enterprise Application Platform)」が、「IBM Worklight」「SAP Mobile Platform」「Oracle ADF Mobile」などなど、数えきれない程の製品によって、実用化もコモディティ化も進んでいます。一方で開発効率については、HTML5によるハイブリッドアプリケーション開発が注目を集め、これを実装するための「Apache Cordova」がMEAP製品の間でも独占的シェアを得ています。HTML5自体、そもそもモバイルから注目を集め出したわけで、そこまで想像に難くないはずです。

3. 「アーキテクチャ」はどう変わるのか？

最後に、統合化を目指したアーキテクチャについてです。ここでのアーキテクチャとは、個別のシステムにおけるものではなく、全体最適化の観点におけるアーキテクチャです。一つの業務をこなすのに、いくつものログインを繰り返す煩わしさ、複数のシステムに同じ情報を投入しなくてはいけない状況など、連携できていない状況の改善という意味です。

以下3つのポイントが、これからのアーキテクチャを決定付けているように思えます。

• 業務ロジックがAPIを持ち始めている：出足はやや遅れましたが、私の感覚として日本の企業でもパッケージの活用が進んでいるように見えます。パッケージ製品は、SAP NetWeaverやSalesforce APIsといったAPIを持つのがもはや当たり前で、標準としてはODataが広がっています。インフラもAWSのAPIがデファクト標準化しつつあり、認証基盤ですらもSAMLやOAuth(OpenID Connect)のような標準のAPIへとシフトしています。OneAPIやBONDIみたいなモバイル向けアプリ開発の世界観も気になるところです。スクラッチ開発においても、ライブラリ/フレームワークも豊富になり、REST(like)を中心としてAPIの実装コストも落ちていくことでしょう。
• APIを活用する製品が増えている：IBM CognosやOracle BIなどのBIツールや、Apache Camelのようなルーティングエンジン、Backbone.jsやAngularJSといったJavaScriptフレームワークでさえもREST(like)に対応するのが当たり前という状況です。サーバでAPIを繋げるApigeeや、クライアントでAPIを繋げるIFTTTなんかも面白い傾向です。例えスクラッチ開発であっても、アプリは標準的なAPIで繋げた方が、長期的に見てできる事の幅が広がっている時代に突入しています。
• 開発ツールがモバイルファースト化している：モバイルはネットワーク環境が不安定であることが前提であり、サーバサイドとは疎結合にしてクライアントで処理をすることが求められています。こうした中、マイクロソフトの「Mobile-first, Cloud-first Development」、IBMの「Mobile First」と、各製品ベンダの開発ツールがどんどんモバイルファースト前提に変わっています。個人的には、Oracle BI Mobileみたいな、完成された製品でさえもモバイル前提なことに、未来を感じさせられます。

このような状況を鑑みると、世の中のアプリケーションはC/Sモデルへと回帰しているように見えます。クライアントは多くの場合、やはりHTML5のエコシステムの恩恵を受けたくなるはずです。本メディアでも過去に取り上げたような、佐川夫美雄氏の考えるWebベースのリッチアプリケーション開発もその一つと言えます。現在はまだ、APIの集約はBIツールなどを活用してサーバサイドで行うのが一般的なようですが、これから先は、徐々にクライアント側へと移っていくことも想像に難くないはずです。

「あの企業みたいに、こういう経営情報を可視化したい！」「こういうコスト削減を目指したい！」となった時に、「世の中の道具が全く何も使えない！」なんてことにならないためにも、少しずつでよいので世の中の流れに乗っていけるといいですね。素直に新しいベンダ製品を活用していたら、勝手にこんな作りになるわけですが、いかんせんOSSによるコスト最適化、マルチベンダ化、大量のレガシー資産などの要因が邪魔して、そうも簡単にいかないというのが厄介なところでしょう。

さてさて、今回「UX」に「MEAP/ハイブリッドアプリ開発」に「業界標準フォーマット」に「ツール/フレームワーク」と、フロントエンドに関わるいろんなキーワードが出てきましたが、これらをより深堀りしたものが、本メディアにて「エンタープライズ特集」として取り上げられます。企業のビジネスを技術面から良くする、ヒントを与えてくれるに違いありません。

どうぞ、お楽しみに！

こんにちは、川田です。Googleはここ最近、デスクトップ向けWebに対して、ほとんどの関心を失っているように見えます。HTML5ブームも過ぎて、やることがなくなってしまったのでしょうか？……いえいえ、そうでもありません。昨今の待ったなしで進む技術革新の中で、彼らは「ある問題」と戦っているようです。

Webは「モバイル」中心の時代へ移っていく

Google Inc. First Quarter 2014 Results

すでにご存知の方も多いと思いますが、GoogleのビジネスモデルはWebに強く依存しています。2014年1Qの決算で、Googleは全売上の約68%が自社のWeb系サービスの広告収入であり、約22%はAdsenseなどの他のWebサイト向けの広告であると報告しました。Webに依存したビジネスが実に9割を占め、1日に約120億円の収入をWebから得ています。もっと簡単に言えば、Webだけで、タイの国民全員の給料分ぐらい稼いじゃってます。当然、Webの進化をやめてしまうなんてことは、考えにくいでしょう。

彼らにとって、利用者がどこからWebにアクセスするのかは、とても重要な情報となります。むしろ、Googleに限らず、Webでサービスを提供している全ての人にとっても重要なことでしょう。人々は普段、どんなコンピュータを使っているのか？どのようなデバイスからインターネットにアクセスするのか？そのことが、私たちのビジネスにとって大きな意味を持ちます。

そしてここ最近、Googlerがいろいろな発表の場でよく口にしているのが「モバイル」というキーワードです。これから先、Webの利用者はモバイルからやってくると、Googleは考えているようです。そのことを証明するかのように、現場の開発者からマーケティング・経営者まで一丸となって、これからやって来るモバイルの時代に向けた取り組みをアピールしています。

“AndroidとChrome、2つの巨大なオープンプラットフォームについて。スマートフォンは2013年4Qに、3.15億台の出荷があった。Androidは毎年利用者が倍増しており、現在は10億ものアクティブユーザがいる。将来的にはAndroidを、50億人にリーチしたいと考えている。” —— Google 経営者 Sundar Pichai (Google I/O 2014 – 2014.06.25)

“2014年1月に、ChromeのレンダリングエンジンであるBlinkをどう変えていこうかという話し合いをした。結果としては『モバイルが大事』ということになった。デスクトップよりもモバイルの方が売れているし使われる。しかし開発者の立場から見ると、残念ながらWebよりネイティブの方が多いという状況だ。我々はHTML5の問題点をヒアリングし、改善を進めている。” —— Google Chrome開発者 及川卓也 (HTML5 Night – 2014.06.14)

“アメリカの成人の34%にとって、主要のインターネットアクセスはスマートフォンだ。モバイルのトラフィックは増加しており、来年にも過半数のユーザがモバイルでインターネットを利用することになる。” —— Google Webコンテンツ開発者 Paul Lewis (Google I/O 2014 – 2014.06.26)

モバイルであることが前提の、Webとパフォーマンス

モバイルは、Web開発者/制作者にとっては厄介な存在です。動作環境が増えるのですから、デザインにコーディング、動作テストと、やらなくてはいけない作業も増えてしまいます。Googleは、その手間をできる限り省き、コンテンツ制作に専念できるようにしようと考えています。その成果の一つが、「Material Design(マテリアル・デザイン)」です。

UXの向上を図る上で、デザインは重要です。ただ、デザインだけではどうにもなりません。「パフォーマンス」も欠かすことのできない重要な要素なのです。Google I/Oでは、多くのエンジニアが「Polymer」「Material Design」「Android」など、宝物のような名前がついたキーワードに目を奪われました。実際にメディアでも、これらのキーワードが大きく取り上げられています。しかし、冷静に見るとそれなりの数の「パフォーマンス」をテーマとしたセッションが開かれています。パフォーマンス改善はすごく地味だけど、すごく重要な取り組みと彼らは認識しているのです。

Googleでは「PageSpeed Insights」と呼ばれるサービスを提供しています。イベントに参加していると、割と頻繁に目に入りました。Paul Lewis氏のセッション「Mobile Web performance auditing」では、その活用方法についてかなり具体的なアイデアと共に紹介しています。その内容を見てみましょう。

「PageSpeed Insights」とは、Webに公開しているページのURLを与えると、そのページの問題点、改善方法を提案してくれるGoogleのサービスです。競合するものとして、マイクロソフトの「modern.IE site scan」が挙げられますが、こちらはWebコンテンツのポータビリティを評価する方向に力を入れています。パフォーマンス改善という観点では、Google側の方がより尖っているという印象です。タブが「Mobile」が最初になっている点からも、彼らの作るツールがモバイルファーストの思考で動いているというのを感じとれます。

さっそく、私がはてなで運営しているブログをPageSpeed Insightsで評価してみたところ、Mobile-60点/Desktop-28点/UX-99点という結果でした。Paul Lewis氏いわく、それでは全然ダメとのこと。PageSpeed Insightsでのスコアは、大体目安として、Mobile-85点以上/Desktop-90点以上/UX-100点が望ましいそうです。いくつか日本のブログサービスでテストしてみたのですが、この条件が満足できているのを見つけることができませんでした。それどころか、Google自身が提供しているサービス「Blog Spot」ですら、この条件を満足できていません。そこまで頑張らなきゃいけないのかと、その必要性に疑いの目を持ってしまいます。

ところが、Paul Lewis氏いわく、200ミリ秒の遅延が0.3%の機会損失に繋がると。パフォーマンスの改善が、そのまま収益に結びつくのだと強く主張しています。Webは速ければ速いほど、価値を発揮するのです。もちろん、それを実現するにはそれなりにコンピュータ科学の知識を必要とするわけですが、私たちエンジニアによる純粋な技術による改善で、利用者の増加に貢献できることが残されているというのは、大変喜ばしいことでしょう。

パフォーマンスの問題について、Paul Lewis氏は「Page Speed」と「Runtime」の2つの観点から、その対策方法について紹介がありました。この2つを軸に、他のGoogle I/Oのセッションの内容も交えながらその考え方について見つめてみましょう。

Page Speedはどのように改善するのか？

Page Speedの改善とは何か？単純に言えば「Webページの表示を3秒以下に抑えよう」ということです。そのための方法として、Paul Lewis氏は以下の方法を提案しています。

1. リソースを最適化せよ(Optimize resources.)

Webページを構成するデータのうち、平均63%が画像ファイルです。最適化が必要となります。画像ファイルの圧縮を改善すると、データ量は大きく削減されます。CSS/JavaScriptについても、不要なスペースなどを削って圧縮(Minify)するとよいでしょう。

(補足：のちに説明がありますが、これらはプリプロセッサーの活用を習慣付けるとよいでしょう。人間の手でやっていてはキリがないので、徹底的に自動化させてしまうことです。)

2. リクエスト数を減らせ(Reduce the number of requests.)

リクエストはWebページの表示をブロックさせることがあります。リクエスト数が減るとそれだけ表示が速くなことを意味します。

(補足：SPDYやHTTP2.0が関わってくると、リクエスト数だけでなく、コネクション数も重要になってきたりしますね。いずれにせよ、少ないことはよいことです)

3. リダイレクトをやめろ(Avoid redirects.)

リダイレクトにはDNSの名前解決、TCPコネクションの接続など、Webページの表示までに要する時間が長くなります。パフォーマンスを意識するなら、リダイレクトさせてはいけません。

(補足：モバイルの場合、よくあるのは「m.〜〜」というURLにリダイレクトされるケースです。当然ですが、その処理を行うためにWebページ読み込みのパフォーマンスは劣化することになります。日本の場合は、モバイル網のDNSサーバのパフォーマンスが問題となることも少なくありません)

4. レンダリングの順序に優先度をつけろ(Prioritize for the critical rendering path.)

Webページ全てを読み込んだ時間よりも、見えている領域の読み込み完了(Visually Complete)に、利用者は関心を示します。そこに優先度を高く持っていくべきです。

(※補足：実際に、W3CのWeb-perf WGでも、Resource Prioritiesという仕様の検討が進められていますね。jQueryだと、LazyLoadプラグインがあり、画像ファイルの読み込み順序をコントロールすることができます)

一連の作業は、GruntやGulpが助けてくれます。利用してみるとよいでしょう。

Runtimeはどのように改善するのか？

Runtimeの改善とは何か？単純に言えば「Webページを60FPSで動かそう」ということです。一般的なディスプレイ(スクリーン)は約1/60秒周期で内容が更新されるため、アニメーションなどの処理はその特性に合わせていくことで、滑らかな動きを実現することができます。そのための方法として、Paul Lewis氏、Paul Irish氏は以下の方法を提案しています。

1. 変形や透過によるアニメーションは制限しろ(Restrict animations to transforms and opacity.)

処理コストの高い描画計算処理は控えるべきです。DOMの形状が変わるとLayout処理のコストは増大するし、透過処理などはPaint処理をコスト増大させます。このような「Expensive Animations」は、約1/60秒以下での処理に収まらないことがあり、注意する必要があります。

2. requestAnimationFrameを使え(Use requestAnimationFrame.)

画面のリフレッシュレートに合わせて、アニメーション処理は実行させるようにしましょう。例えば、setIntervalなどを利用し、16ms周期でコールバックさせ擬似的にリフレッシュレートを合わせようとすると、タイミングがズレて無駄が起きます。画面のリフレッシュレートに合わせるには、requestAnimationFrameと呼ばれるAPIを利用する必要があります。

3. レイアウトの値を読み込んでから書き出せ(Read layout values, then write.)

レイアウト(DOM)の値は変数のように扱ってはいけません。横幅などの取得が必要であれば、最初に取り出してキャッシュしておきましょう。読→書→読→書を繰り返すと、無駄なLayout処理が何度も発生するという「Layout Thrashing」という現象が起きます。読→読→書→書が理想です。

4. メモリ効率の高いJavaScriptを(Write fast, memory-efficiant Javascript.)

メモリを消費するようなJavaScriptの記述方法は、Garbage Collection処理が発生し、1/60秒以内での処理が完結しなくなることがあります。JavaScriptの書き方に、工夫が必要です。

モバイルChromeの解析は、「chrome://inspect/」でできます。お試し下さい。

難しくなってきている、なんて思いませんか？

これまではデスクトップPCが一つあればなんとかなっていたWeb開発も、作るための環境と動かすための環境が分離されて、どんどん複雑になってきているなぁという感触を得ています。プレゼンの時も、わざわざカメラを切り替えてモバイルのスクリーンを表示したりなんかしてて「エレガントさに欠るなぁ」「面倒くさいことやってるなぁ」なんて思ったりもしました。もっと言えば、デモしている姿を見てて「モバイル、めちゃくちゃ使いにくそうに扱ってますよね！」「本当はPCでやりたいとか思っていませんか？」なんてことも、率直な印象として感じました。

こういう不満を感じられることは、本当の本当に幸せに思えたりもします。Googleが悪いとかAppleが悪いとかMicrosoftが悪いとかじゃなく、IT業界全体として、まだまだ発展途上にいると感じさせられるのです。これからもっとよくしようと、動き出せるきっかけがいくらでもあるように思えるのです。もっともっと、進化しますよ！

みなさんはどう思いますか？私はWebの未来に、夢を見過ぎでしょうか？

いよいよHTMLドキュメントのダウンロードと、画面上への表示です。この動作の仕組みから、TATの「終了」がいつなのかを追ってみましょう。「終了」についてはかなり奥が深く、Web標準でもそのプロセスを「The End」として定義はしていますが、それだけでは語りきれない難しさがあります。

4. TCP接続、5. HTTPリクエスト/レスポンス

名前解決で得られたIPアドレスを使って、HTMLドキュメントが置かれたサーバへ「4. TCP接続」します。いわゆる、3ウェイハンドシェークというものです。サーバとの接続交渉が終わると、HTTPリクエストをサーバへ送信し、HTTPレスポンスを受け取ります。

HTTPレスポンスの結果からリダイレクトであることが発覚した場合、「2. キャッシュ確認」からやり直しです。この、リダイレクト動作にかかった時間もNavigation Timingでは取得でき、「redirectStart」「redirectEnd」の各プロパティを通じて取得することができます。

HTTPレスポンスから得られたデータは、いったん蓄積され、この後のDOMの生成で利用されることになります。

6. DOM生成

さて、ここからがブラウザの一番の見せ場、サーバから受信したHTMLドキュメントからDOMを生成し、描画を行うフェーズです。

HTML5のスペック「8.2章 Parsing HTML documents」に内部的な動作が定義されており、これに従い計測値が取得されます。このフェーズで意識すべきなのが、「①. HTMLドキュメント自体の読み込みを行っている段階(domLoading)」と「②. HTMLドキュメントの読み込みが完了し非同期に取得できる画像などのリソースを読み込んでいる段階(domInteractive)」の、2段階のステージです。

1段回目、domLoadingの段階。HTMLドキュメントの読み込みには、8KBというマジックナンバーが隠されています。これは、ブラウザがHTMLドキュメントの内容をパースする際に、一括で読み込みを行う単位と考えると良いでしょう。ブラウザはサーバから受信したHTMLドキュメントを、8KBずつ逐次パースし、DOM Contentを作っていきます。

JavaScript/CSSのような即時で反映する必要があるファイルの参照があった場合、HTMLドキュメントの受信は継続しますが、HTMLパース処理は停止し、JavaScript/CSSのコンパイルと実行を優先します。

DOM Contentの生成が終わった状態を、HTML5のスペックでは「interactive」と定義しています。JavaScriptにて「DOMContentLoadedイベント」を登録していた場合は、このタイミングで発火します。

7. リソース読み込み

ここからは、2段階目の説明に入ります。HTMLドキュメントが全て読み込まれ、画像などの非同期で読み込めるリソースを読み込んでいる段階です。先ほども説明しましたが、Web標準ではこの段階のことをinteractive(対話可能)と呼んでおり、名前の通り、画像の読み込み完了を待たずしてユーザからの入力を受付けることができます。

実は、ブラウザはHTMLドキュメントを読み込みつつリアルタイムに画面上へ表示する(ChromeはHTMLドキュメントのダウンロード完了時に表示する)という実装なため、「6. DOM生成」の段階でも既に入力可能だったりします。どちらをTATの開始と呼ぶべきか、非常に悩ましいところです。

画像の読み込みが完了し、Webページが完成したタイミングで「complete」という状態に推移します。completeへ推移すると、JavaScriptのloadイベントが発火します。ここで再び、ブラウザはJavaScriptの処理を動かすために、入力をブロックさせたりします。場合によっては、この段階でユーザからの入力を受け付けるために必要な、初期化処理を行なったりもします。例えば、jQueryの有名なプラグインであるDatePickerなんかは、loadイベント内で設定することが多く、ここに来るまでフォーカスを当ててもカレンダが表示されません。interactiveなんて言われていますが、実際にはloadイベントを実行するまではTATの終了とは言えないような気もしますね。ここまでくると、もはや終了の概念そのものをどう定義すべきかが、だんだんわからなくなってきました。

loadイベントの処理が完了すると、Navigation Timingで計測できる全ての処理が完了です。

なお、ここまでの過程で、JavaScriptやCSS、画像などの外部ファイルの読み込みを行っていますが、これら単独リソースごとの性能計測は、Web標準として少し扱いが異なります。詳しくは、「Resource Timing」を参照すると良いでしょう。

何をもってTATとするか？

ブラウザの仕組みについて一通り紹介したところで、TATを構成する要素が以下に分類できることが理解頂けたでしょう。この中のどこかに開始を作り、どこかに終了を作れば、あなたの求めるTATになるはずです！

開始候補、終了候補、なんて言葉を使ってみましたが、ここまでくるともはや、TATを取得することに意味があるのか？なんて思われても仕方ありません。実際のところ本当にその通りで、TATだけをピンポイントで取得しても、あまり役に立たなかったりします。

Navigation Timingはそもそも、ナビゲーションの動作の中から、性能のボトルネックを探すためのものです。生きた計測値を得るためのものです。ブラウザはナビゲーションを開始すると、様々なキャッシュを駆使して最小限で動作することを追求し、そして終了に向けて、DOM生成やリソースの取得、JavaScriptの初期実行を行い、最大限のポテンシャルを発揮しようとします。こうしたブラウザのメカニズムの中から、ボトルネックを探さなくてはいけないのですから、Navigation TimingはWebページの特性に合わせて、有用な情報を拾えるようにしなくてはいけません。

リソースの取得については「Resource Timing」、JavaScriptの性能に影響を与えるような処理に対しては、「High Resolution Time」のnow()なんかを利用して、計測を行うことが求められるでしょう。

パフォーマンスの改善は、まさに総合競技です。JavaScriptやCSS単独の高速化手法だけ知っててもダメだし、DBのパラメータチューニングだけできてもダメです。JavaやASP.NETやRuby On Railsも、全体から見ればほんの一部でしかありません。DNSやWebサーバ、APミドルなどのインフラも重要な構成要素ですし、私のようにイントラ向けのシステム開発を行なっている方はネットワーク装置の一台まで面倒を見ていることもあるでしょう。最近はクラウドも絡んできたりして、バックプレーンを共有する他社のWebアプリが性能に影響を与えるなんてのも聞いたことがあります。複雑化が進んでおり、ますます全体を見る目が求められているように思えます。

ところが、パフォーマンスの問題にぶつかると、どうしても自分の専門分野で見てしまい、DBだけを良くしようとしたり、JavaScriptだけを高速化しようと先走ってしまうことがあります。

Navigation Timingを入り口にして、生の測定値に基づき分析し、ブレークダウンしてみて下さい。きっとそれは、改善の近道となり、費用対効果の高い手段を見つけるヒントとなるでしょう。そしてWebアプリは、最高のパフォーマンスを得ることができるはずです。

• Navigation Timingだからできる、Webアプリを俯瞰したパフォーマンス計測(1/3)
• Navigation Timingだからできる、Webアプリを俯瞰したパフォーマンス計測(2/3)

前回の記事でもお伝えしたとおり、ブラウザのメカニズムが、TATの計測を複雑にしています。その事情について、まずTATの「開始」をどこにするかについて考え、紐解いてみましょう。Web標準で定義するところのブラウザの動作について、少しだけデフォルメさせた処理モデルを使って、全体の流れを解説します。以下の図の赤字はtimingオブジェクト配下にあるプロパティ、数字が振ってある矢印は処理の流れです。

0. ナビゲーション開始

Webページの読み込み動作を、「ナビゲーション」と呼びます。ブラウザは、ネットワーク上のHTMLドキュメントにアクセスすると、Webページを構成する様々な情報を削除(アンロード)します。そして、新しくHTMLドキュメントを読み込み、DOMを構成し、JavaScriptやCSS、画像などのリソースを取得しながらWebページの描画を進めていきます。この一連の動作が、ナビゲーションです。

近年は、「SPA(Single-page Application)」と呼ばれるアーキテクチャがあり、DOM操作により画面遷移を擬似的に表現する手法もありますが、この仕組みではナビゲーションを開始できません。あくまで、JavaScript APIやプラグインの力を借りず、ブラウザの機能を使ってWebページを遷移させることで、ナビゲーションは開始されます。

ナビゲーションは、ハイパーリンクのクリックもあれば、Formを使ってサブミットすることでも発生します。戻る/進むボタンやリロードボタンを押下した際も、同様です。こうした、様々なナビゲーションを発生させるアクションは、ブラウザのキャッシュの動作、ナビゲーション全体の動作への影響が大きいため、Navigation Timingを扱う際に理解することが求められます。

Web標準では、こうしたナビゲーションの種類を「PerformanceNavigation」として以下のように分類しています。まずは、この定義を中心としてその違いを把握してみましょう。

• TYPE_NAVIGATE : ハイパーリンクのクリック、ブックマーク等。
• TYPE_RELOAD : ブラウザのリロードボタン押下。
• TYPE_BACK_FORWARD : ブラウザの戻る/進むボタン押下。
• TYPE_RESERVED : 未定義のWebページ読み込みアクション。

「TYPE_NAVIGATE」は、ハイパーリンクをクリックした際や、フォームをサブミットした際に発生する、一般的なナビゲーション動作です。ナビゲーションバーへURLを入力しEnterキーを押下した際、ブックマークを開いた際もこの動作であり、基本はこのアクションが選択されると想定すべきでしょう。後に説明する、「RFC 2616」のHTTP Cacheが最大限に活用されるのも、このナビゲーション動作です。

「TYPE_BACK_FORWARD」は、基本的には「戻る/進む」ボタンを押下した際に発生します。Web標準で言うところの「履歴移動(History Traversal)」により発生したナビゲーションです。ただ、「フラグメント識別子(Fragment Identifier)」を利用したURLを扱った場合、ナビゲーションを伴わないWebページ内の移動を行うことがあります。また、Webページが一定の条件を満足すると、ナビゲーション発生時に、前のWebページ全体をそのままキャッシュさせることで、戻るボタンのパフォーマンスを改善しようとします。このような動作を行なった場合、戻るボタンを押下してもナビゲーションは発生しません。

「TYPE_RELOAD」は、「リロードボタン(再読み込み)」を押下した際に発生します。ブラウザによってCtrl/Shiftとリロードボタンを同時押しすることで、HTTP Cacheの一切を破棄しWebページの再読み込みを行う「スーパーリロード(強制再読み込み)」と呼ばれる機能があります。Navigation Timingではこれを区別することなく「TYPE_RELOAD」として扱いますが、実際のキャッシュの動作は大きく異なるものとなるため、明確に区別する必要があります。

「TYPE_RESERVED」については未定義であり、ブラウザでWebページを扱っている範囲では、あまり意識する必要はありません。

1. アンロード

ナビゲーションが開始され、標準的なブラウザはまず「1. アンロード」という処理を行います。ブラウザは、今表示しているWebページのリソースを破棄し、次のWebページを表示する準備をするわけです。DOMの情報を持つDOM Contentや、JavaScriptの機能の初期化を行います。

Web標準では、この処理を「unloadイベント」として捕捉でき、Navigation Timingを利用してイベント発生前後の時間を取得することができます。ただ、このタイミングは常に一定しているとは限りません。^{(※ 注１)}表面的には、アンロードはこのタイミングで発生しているように見せてはいますが、実装ではブラウザのレンダリングエンジンによってバラツキがあり、この処理の負荷が、この後説明するDOM読み込みのタイミングに大きな影響を与えることがあります。

また、「戻る/進む」ボタンを押下した場合の動作も独特です。先ほども少し説明しましたが、Webページは一定の条件を満足すると、アンロードを行わずメモリ上にWebページをまるごとキャッシュさせます。この動作は、例えばIE11だとデベロッパーセンター、FirefoxだとMDNのドキュメントに仕組みが掲載されており、ブラウザごとにやや異なる思想を持っていることも把握できるはずです。HTML5の「pageshow/pagehide」イベントで捕捉でき、ある程度の制御が可能なわけですが、基本的にこの動作、ナビゲーションが発生しないのですから、Navigation Timingのプロパティの値も更新されません。

2. キャッシュ確認

標準的なブラウザがアンロードを終わらせると、「2. キャッシュ確認」を行います。Webページの表示に必要なHTMLドキュメントを、キャッシュの中から探すわけです。キャッシュと言っても、ブラウザのみで有効性判断ができるものあれば、サーバに問い合わせを行わないと判断できないものもります。ここでチェックされるのは、あくまで前者のみです。HTML5の「AppCache」や、「RFC 2616(13.5)」で定義されたHTTPヘッダのプロパティ「Expires(14.2)」「Cache-Control max-age(14.9)」によるHTTP Cacheなんかは古くから活用されているため、ご存知の方も多いでしょう。

AppCacheは、常にこの段階で読み込みが行われます。しかし、HTTP Cache(Expires)により得られるゆるいキャッシュは、TYPE_NAVIGATEの場合のみ、ブラウザ内のキャッシュを利用します。この仕様は動作チェックの際に問題となることがあり、誤ってリロードボタンを押下してテストしようものなら、テスト担当者は一日を無駄に過ごすことになります。(※ アドレスバーにフォーカスを当ててEnterキーを押下、がキャッシュのテストの鉄則です！)

Chromeだけは、やや動作が例外的です。Chromeは、HTMLドキュメント内から参照されるJS/CSS/画像ファイルのようなリソースでも無い限り、HTTP Cacheによるブラウザ内のキャッシュを利用してくれません。XHR(XMLHTTPRequest)についても同様で、Chromeだけは必ずサーバへのアクセスを伴います。そもそも、Webページはサーバサイドのプログラムで動的に生成するのが殆どなので、HTMLドキュメントのキャッシュは期待できないものと見なすべきでしょう。

3. 名前解決

標準的なブラウザは、有効なキャッシュを発見できなかった場合、HTMLドキュメントが置かれているサーバの場所を特定するため「3. 名前解決」を行います。

名前解決については、Linux/OS X/iOS上のブラウザについては、基本的にDNS名として扱い名前解決を行います。しかし、Windows OS上のブラウザは、微妙に同じ動作にはなりません。Windows OS上のブラウザは、ドメイン名をフルコンピュータ名というやや特殊な概念として扱い、NetBIOS(WINS)名とDNS名の2つの名前の概念を扱うハイブリッドな名前解決を行います。

これは、ブラウザの仕様というより、OSの持つTCP/IPモジュールの仕様の違いです。IEとFirefox/Chromeとで異なるAPIをコールしていますが、どちらも最終的には同じWinSock2の名前解決のメカニズムを利用します。名前解決を行うリゾルバにも、OSによる動作の違いがありますが、DNSを使っている限り、機能面において、ブラウザからはあまり意識する必要がありません。

インターネット向けでは、各プロバイダが提供するDNSサーバの性能が関わってくることもあります。DNSもやはり、キャッシュが要です。DNSを構成する各ノードのキャッシュの動作次第で、性能は大きく変化します。TTL設定のチューニング、DNS Prefetchを活用して対策してみると良いでしょう。

キャッシュだらけ！

ナビゲーションの動作のうち、どこをTATの開始とすべきか？もうお分かりと思いますが、キャッシュだらけで、前提条件から疑いにかからなくてはいけません！Webページ自体の(アンロード絡み)のキャッシュ、HTML5 AppCacheやRFC 2616によるブラウザ側のキャッシュ、名前解決絡みのキャッシュと、まだWebサーバにアクセスしていないというのに、これだけのキャッシュが絡んでいます。

最初にご紹介した「navigationStart」は、こうした前の画面の動作を含んだ計測値です。アンロードや、この後説明するリダイレクトを含めるとなると、開始をどこに置くのかというのもまた難しくなってきます。

TATの本当に難しさはここだけではありません。TATの「終了」の扱い、これも難しかったりします。ブラウザのメカニズムを掘り下げて追ってみましょう。

「Navigation Timingだからできる、Webアプリを俯瞰したパフォーマンス計測(3/3)」に続きます。(※5/9公開予定)

• Navigation Timingだからできる、Webアプリを俯瞰したパフォーマンス計測(1/3)
• Navigation Timingだからできる、Webアプリを俯瞰したパフォーマンス計測(3/3)

こんにちは、html5jパフォーマンス部、スタッフの川田です。5月8日ですが、私たちのコミュニティ主催で勉強会を開催することになりました！！

そして、残念なお知らせです。募集した直後に、席が埋まってしまいました！せっかく、これだけ多くの方にパフォーマンスへ興味を持っていただいたのに、このままじゃもったいない！

なので本記事では、この勉強会で語られない、別の切り口からパフォーマンスについて語ってみようかと思います。内容は、私が技術評論社「Software Design 2014年5〜7月号」にて連載しております、「Web標準技術で行う、Webアプリのパフォーマンス改善」で扱っているテーマの一部を、Web向けに書き直したものです。

Webアプリのパフォーマンス計測は簡単なのか？

パフォーマンスは、メモリを節約するものからCPUコストを下げるものまで、様々な種類があります。本記事では「ターンアラウンドタイム(TAT)」という指標値について考えてみましょう。

TATとは、アプリケーションの応答速度を表す指標の一つです。厳密には、あるアプリケーション・サーバに対して、ユーザが何かしらの操作・入力を行ってから、アプリが反応し終わり、ユーザが再び入力を受け付けることができるような状態になるまでの時間、と定義されています。Webページが遷移する時間を、定量的に評価できる指標値ということになります。

このTATという考え方、そんなにマニアックなものというものでもなく、レスポンスタイムやスループット、アベイラビリティなどと同様に、古くから存在する非機能要求の項目です。IPAの情報処理試験でもよく見かける、有名なキーワードに思えるでしょう。ところが、これをWebを検索しても、なかなかしっくりくる計測手段が見つかりません！この問題、特にWebに限定した話というものでもないはずです。GUIレベルでの性能計測は、昔からある悩みの一つで、アナログにストップウォッチの力を借りるなんてことも割とよく聞く話です。筆者もIE6全盛のWebアプリ開発で、同じ悩みを抱えたことがあります。

今回、そんなTATをめぐる悩みに対して、ちょっとしたヒントをご紹介します。ブラウザの仕組みを探り、WebアプリのTATとは何かを探り、そして標準的な手段の中からその計測方法について探ってみましょう。「そもそも、そんな指標で評価することに価値があるのか！？」なんて議論も生じていたりするのですが、その点は一番最後に触れるとして、今回はTATという切り口からWebページの性能について考えてみます。

TATの計測で、Webサーバのログはアテになるのか？

SPDYなどの新しいプロトコルのことは一旦忘れて、シンプルなHTTP1.Xを前提に考えてみて下さい。HTTP1.Xは、HTMLドキュメント取得し、HTMLドキュメント内で参照されている必要なJavaScript/CSS/画像などの外部リソースを、逐次取得し表示していくという仕組みです。サーバサイドで動的にHTMLを生成するようなアプリだと、画面を遷移する都度、最低でもHTMLドキュメント程度はサーバ側から取得することになります。

この動きに注目し、計測で非常によく利用されるのが、Webサーバログの「リクエスト処理時間(Time taken to process the request)」です。Apache HTTP Serverのアクセスログのフォーマットオプション「%D」あたりは有名でしょう。このオプションは、HTTPリクエストを受け付けた瞬間から、サーバで処理が行われ、データを出力し終わるまでの時間を、マイクロ秒単位で計測する機能です。TomcatやJBossのようなJavaミドル、MicrosoftのIIS(Internet Information Services)でも、リクエスト処理時間をミリ秒で計測できる機能を実装しており、大抵のWebアプリでは活用できるコモディティ化した機能と言えます。

リクエスト処理時間は、実際にサーバ上の問題を発見するのに価値が高い計測値です。運用時には、キャパシティプランニングの目安や、障害発生時の解析に活用されたりします。また、お客様と品質保証の明確な基準を決める「SLA(Service-Level Agreement)」でも、アクセスの何％を保障するかという「パーセンタイル」を配慮した形で活用することがあります。どこにでも目にするこの計測値、一見すると使い道が広く、万能な値に見えるでしょう。

ところが残念なことに、リクエスト処理時間は、キャッシュされていないごく一部のファイル/プログラム単位の性能しか評価できません。サーバがどの程度のリクエストを捌けるのかを判断する「スループット(＝処理能力)」の指標値として扱うには高い価値を発揮しますが、TATの指標値として扱うには、対象が局所的で、不足が大きすぎます。サーバから見ると性能は高いのに、クライアントで見ると画面はいつになっても白いまま！なんてことになりかねません。

では、TATを計測するにはどうすればよいのでしょうか？画面を表示する際のもっさり感の原因は、どのように探ればよいのでしょうか？このあたり、最近のWeb標準がかなり力を入れています。2012年12月にW3C勧告となった「Navigation Timing(ver.1)」がまさにその代表的なスペックです。

Navigation Timingを含むWebのパフォーマンスに関する仕様は、2010年にW3Cで設立された「Web Performance Working Group(WebPerf WG)」で議論され、IE9+、Firefox、Chromeなどのブラウザにその成果が反映されています。Facebookのザッカーバーグ氏がHTML5に失望し、同社のアプリをネイティブに書き換えるという有名な事件がありますが、そんな彼らも同WGの設立直後すぐに反応し、WGの議論に参加しています。2013年には「Web vs ネイティブ」という議論が盛り上がりましたが、WebPerf WGの取り組みは、現在のWebが抱える性能という問題を見つめていく上で、注目すべき重要なポイントと言えるでしょう。

Navigation Timingの使い方、TATの計測方法

Navigation Timingでは、ハイパーリンクをクリックした瞬間からWebページが利用できるようになるまでを、ブラウザの内部的な動作である「処理モデル(Processing Model)」として定義し、その経過時間を取得することができます。

ブラウザ自体にも「開発者ツール」として計測のためのツールが備わっていますが、ブラウザごとに考え方も違うし、活用できる場も開発時のみと非常に限定的です。Navigation TimingはWeb標準なので、ブラウザに依存しない共通の考え方で計測値を扱え、また運用時にもJavaScript上で生のデータを収集することができる点で、開発者ツールより高いポテンシャルを得ています。

実際のJavaScriptの仕様を見ながら確認してみましょう。

windowオブジェクト配下にある「performance」は、パフォーマンス関連のJavaScript APIにアクセスするための入り口となるオブジェクトです。そのさらに下に、WebPerf WGの成果である様々なスペックの実装が分類別で並んでいます。そのうちのひとつである「timing」の配下には、ハイパーリンクをクリックしてから応答するまでの間に発生する、様々な動作発生時のタイムスタンプを取得できるプロパティが並んでいます。

TATを取得しコンソールに表示させる、シンプルなコードを確認し、使い方を掴んでみましょう。

/* timingオブジェクトの取得 */
var timing = ( window.performance || {} ).timing;
/* TATの計測 */
timing && window.addEventListener( "load", function() {
    setTimeout( function() {
        var tat = timing.loadEventEnd - timing.navigationStart;
        console.log( "TAT = " + tat );
    },1);
},false);

「timing.navigationStart」はハイパーリンクがクリックされた直後の時間、「timing.loadEventEnd」はWebページが表示されJavaScriptのloadイベントの処理が完了した直後の時間が取得できるプロパティです。サンプルでは、この2つの単純な差分を、仮にTATとしてみました。setTimeoutで実行時間を遅延させているのは、loadEventEndがloadイベント中だと未計測の状態「0」を返してしまうという問題への対策です。

このサンプルで得られる計測値が、TATとして「ほぼ正解」の値ということになります。ただ、ほぼ正解であって、完全な正解とは言えません。このあたりの理由については、ブラウザの内部のメカニズムによるところが大きかったりします。具体的には何が原因なのか、これから見ていきましょう。

• Navigation Timingだからできる、Webアプリを俯瞰したパフォーマンス計測(2/3)
• Navigation Timingだからできる、Webアプリを俯瞰したパフォーマンス計測(3/3)

※ 修正 2014.5.11：矢倉 眞隆さんからのご指摘により、サンプルのwindow.performanceのベンダプレフィクスは削除しました。IE9+を含む近年のブラウザでは、3年近く前にベンダプレフィクスが消えており、無意味であると判断できたためです。