今回は、Webパフォーマンスに関する特集の一環として、株式会社Spelldata CEO、html5j パフォーマンス部 部長などを歴任されている竹洞陽一郎さん（エキスパートNo.54）にお話を伺ってきました。

竹洞さんはWebパフォーマンスについて10年以上従事しており、現在でも年間200サイト以上を計測・分析・評価しているという、その道のエキスパート。テクノロジーの知識はもちろんのこと、アカデミックな話題から業界動向まで幅広く押さえていらっしゃる竹洞さんに、「竹洞さんにしか語れないパフォーマンスの話」を聞いてきました。

「ADN」や「パフォーマンス・バジェット」など、Webパフォーマンス業界の最新動向の話も盛りだくさん！めちゃくちゃ面白くて歯ごたえのあるインタビューに仕上がったと思います。
どうぞお楽しみください。

「Webパフォーマンス大事」ってわかってる人は2割しかいない

白石 改めて伺いたいんですが、Webパフォーマンスはなぜ重要なのでしょう？

竹洞 根本的な話から言うと、Webサイトがある、ってことは伝えたいメッセージがあるわけですよね。 そして、多くのサイトは複数のページにまたがっているわけですが、それは伝えたいメッセージが複数ある、もしくは複数に分けているということ。 Webサイトを高速に表示するということは、それらのメッセージを高速に伝えるということにつながるわけです。

ですが、UX業界で著名なロバート・ヤコブソンによると、1秒以上のインタラプトが入ると人間は思考を中断されてしまうといいます。このインタラプトは、可能な限り避けなくてはなりません。 それによって、ユーザーを「フロー状態」に導くことを作り手としては目標にすべきであり、それがパフォーマンスを重視する理由となります。

白石 そうしたフロー状態にユーザーを導くことが、営利企業にとってはビジネス上も大きなアドバンテージになるということですね。 ただ例えば、「パフォーマンスを向上させるとKPI達成につながりやすい」、もしくは端的に「儲かる」といったことを表すデータなどがあれば、多くの企業がパフォーマンスの優先順位を上げると思うのですが、そうしたデータはあるのでしょうか？

竹洞 GoogleやYahoo!が出しているデータはあるのですが、あらゆる業界をおしなべて平均化してしまっているので、正直それほど使えるデータだとは思っていません。 業界によって、業務上のKPIって全然違ってきますからね。

となると、業界や企業ごとの事例になってくるのですが、そういう点でまとまったデータは今のところ存在しません。モデルもできていない。 例えばAmazonだと0.1秒パフォーマンスを改善すると売上が1%上がる、といったデータが示されたこともありますが、これも「Amazonだから（特別なんだろう）」の一言で済まそうと思えば済まされてしまう。

私が担当している仕事でなら、具体例はいくらでも挙げられるんですけどね。あるメディアは、表示に6秒かかっていたところを3秒にしたことでPVが倍になったり、売上が3倍になった会社もあります。

白石 それはすごいですね。ちなみにパフォーマンスがそこまで重要である、という認識は、日本で今どれくらい浸透しているとお考えですか？

竹洞 うーん、エンジニア界隈にはそれなりに浸透しているとは思うのですが、全体でいうと2割くらいの浸透度じゃないですかね…。そして、「浸透していない」というのは、「パフォーマンスの重要性に確信が持てなくて投資に至らない」というレベルではありません。単純に「知らない」ということが多いです。パフォーマンスについて考えたこともない、という。

白石 なるほど…。もう少し「パフォーマンス大事」という認識を広めたいところではありますね。この記事が多少なりともそのお役に立つといいんですけど。

あなたが統計を学ぶべき理由

白石 では、パフォーマンスが大事だという前提に立って、パフォーマンスの問題を解決しようとしたら、まずは原因の調査からですよね。具体的に言えば測定という話になりますが、竹洞さんは統計に関する知識を学ぶべき、と普段からおっしゃってますよね。これはなぜですか？ツールが生成するグラフやアドバイスに従うだけではいけないんでしょうか？

竹洞 まずですね、パフォーマンスの原因を調べるにあたっては、「先入観を持たない」ことが重要なんです。私の経験から言うと、パフォーマンスの問題を抱えたお客様は、まず「データベースが原因だと思う」と必ずおっしゃいます。でも、ちゃんと調べてみると違ってみたりする。統計学を学ぶと、こういう「バイアス」との付き合い方も学びますので、先入観を持って事に当たることが少なくなります。

白石 なるほど。

竹洞 あと、統計を学ばずにデータに当たると、「データに騙されちゃう」ということが往々にしてあるんですね。「データは何も語らない。語るのは人間である。」という言葉があるんですが、データを解釈して行動に繋げるのは人間なのです。統計について学んでおくと、そこで誤った判断をする可能性を下げることができる。

また、そもそもデータが正しいのか、という問題もある。正しくないデータに基づいても、有意な判断は下せないわけです。ただここで一つ重要なのは、「真の値」を知ることなんてそもそもできないわけですよ。いろんなゆらぎもありますから、一意に定まるわけがない。絶対ズレている。だからその、神様しか知り得ない「真の値」から、得られたデータがどれだけズレているのかを推測し、それも含めて判断が必要になるわけです。

ちなみに、こういう「ズレの推測」も含めてデータを扱うことを「推測統計」、一方、得られたデータをただ（グラフなどに）記述して扱うことを「記述統計」と言います。

白石 推測統計まで行うことが望ましいってことですね。

竹洞 そうです。とはいえ、まずそもそものデータを信頼度高く取るに越したことはない。そのために、近代統計学の確立者で、実験計画法という手法を編み出したロナルド・フィッシャーは、「3つの原則」を打ち出しています。その原則とは、以下の3つです。

• 反復…長期間に渡り、繰り返し採取する。
• ランダム…単純無作為抽出を行い、計測を行った値同士が影響を及ぼさないようにする
• 層別…変数を局所化し、影響を見たい変数だけ可変にする

こういう知識があるのとないのとでは、データやグラフに対するスタンスが全然違ってきます。「バイアスを排除して、先入観を持たない」「正確性の高いデータに基づき、精度の高い判断を行う」といったスタンスを身につけるためにも、統計をきちんと学ぶことはお勧めしています。

なぜGoogle Analyticsでパフォーマンスを測ってはいけないか？

白石 竹洞さんは、Google Analyticsとかでは、パフォーマンスを正確に計測できない、と以前からおっしゃっていますね。その理由を教えていただけますか？

竹洞 まず、GAで「遅い」という問題に気付けたとしても、原因追求ができないんです。原因となりうる要因が多すぎるし、絞り込むこともできない。 もう一つは、欠損値が多いことです。遅いということはそもそもGAのスクリプトが読み込まれていないことも多い。そういうのが全てデータから抜けてしまうんですね。

白石 なるほど。遅いなーと思ってリロードしたり、途中で離脱したりしちゃうと、そもそもそれがデータから漏れてしまうんだ。

竹洞 そうです。その影響は実は大きくて、データにバイアスがかかってしまうんですよ。本来注目すべき「遅い」データが見えなくなってしまう。 その状態でデータを眺めると、問題が隠蔽されてしまう。こうなると、アメリカの鉄道と同じです。

白石 どういうことですか？

竹洞 アメリカの鉄道が廃れた理由って、遅延やサービスの低品質に利用客も慣れてしまい、不満が上がってこなかったことにあると言われているんです。 で、不満が上がってこないから、企業は「顧客は満足している」と判断し、更にコストカットなどを進めてしまう。その結果、鉄道が衰退してしまった。

白石 なるほど…。GAで欠損値が出るだろう、というのは想像できていたことではありますが、それが経営判断を誤る一因にまでなりうるということですね。 では、パフォーマンスを測定するにあたって、良いサービスはありますか？

竹洞 たくさんありますよ。例えばcatchpointやdynatraceとか。こういったサービスは、実際のユーザー群に近い環境を国ごとに構築していて、継続的にデータを収集してくれます。こうしたサービスで得たデータと、GAで得られるパフォーマンスデータって実際にかなり開きが出てくるので、面白いですよ。

Webページの遅延原因の80%を占めるのは…？

白石 では、もう少し具体的に、パフォーマンスボトルネックの原因や改善方法についてお話を伺っていきたいと思います。Webサービスのネットワーク遅延の原因は、フロントエンド、ネットワーク、バックエンドに分かれると思いますが、バックエンドの話は原因も多岐に渡りそうですし、時間もないので、今回はフロントエンドとネットワークに絞ってお話を聞かせてください。

まずはフロントエンドからいきましょうか。

竹洞 はい、ではまずは前回の座談会でもお話したとおり、Webページの遅延原因の80%はサードパーティから読み込むリソースにあります。

白石 それって、例えばCDN (Contents Delivery Network) からjQueryのJavaScriptファイルを読み込むとか、ソーシャルボタンとか、広告とかいろいろありますよね。

竹洞 はい。で、あえて言うならやはり広告とかですかね。広告のパフォーマンスを見てみると、サーバーのDBがボトルネックになってるんだろうなあ…とは推測しています。そうなると、こちらでは手が出しようがないんですよね。広告を配信している企業に直接改善を要求するしかない。

白石 なるほどー。じゃあ、パフォーマンスの観点から言うと、やはり広告はボトルネックになりやすいと。ほか、「いいね！」ボタンとかのソーシャルボタンや、CDNで配信されてる静的なリソースとかはどうなんでしょう？

竹洞 ソーシャルボタンも遅いですよ。ソーシャルボタンのスクリプトって、キャッシュの時間も15分くらいと短いものが多いので、ネットワークアクセスが増加する一因にもなりますしね。CDNについては…いろいろあるので、あとでじっくり語らせてください(笑)。

ちなみに、アメリカだとサードパーティのスクリプトと言えども、速いんですよ。遅いと（ユーザー企業に）呼び出されるから(笑)。

白石 そうなんですか！アメリカだとユーザー企業の意識も高いんですかねえ。逆に言うと、日本の企業はそこまでパフォーマンスに対する意識が高まってなくて、結局遅いサイトが多数を占めるようになってしまってる、ってことなんでしょうか。

竹洞 そういうことです。あとはフロントエンドで言うと、画像じゃなくてもいいものを画像にしてる、ってのがすごく多いです。ちょっと秘密の資料お見せしますけど、ほら。これ全部画像ですよ。誰でも知ってるような企業のサイトなんですが…。

白石 CSSとかでできそうなものばっかり…

竹洞 そうなんです。HTML5やCSS3のおかげで、Webのポテンシャルってすごく広がりましたけど、そもそもそのポテンシャルが全然理解されてないんです。残念ながら。

ミニファイは不要？目からウロコのパフォーマンス改善術あれこれ

白石 では次は、ネットワークのパフォーマンスについてのお話を聞かせていただければと思います。ネットワークのパフォーマンスって、転送量、転送速度、転送距離の話に分けられると思います。

まずは転送量の話からいきましょうか。ここは、例えばJavaScriptやCSSのミニファイや結合、画像の最適化など、すでに読者に馴染みのある話も多そうなので割愛してもいいでしょうか？

竹洞 あ、一つだけいいですか？実際のところ、実はスクリプトのミニファイとかって、あんまり必要ないんです。

白石 ええっ！そうなんですか？そこを頑張ってるエンジニアたち、ぼくも含めていっぱいいると思うんですけど。

竹洞 もちろんやらないよりはやったほうがいいですけど、パフォーマンス全体から言うと、あまり効果のある施策ではありません。そこに開発コストを投じるべきかどうかは疑問ですね。

それよりもやはりネットワークアクセスの回数、もっと厳密に言えばTCPの3ウェイハンドシェイクの回数の方が重要。で、そこを改善すべくHTTP/2などのプロトコルが登場したわけです（筆者注: HTTP/2は、1本のTCP接続内で複数のHTTPメッセージのやり取りを可能にする）。

ちなみに私としては、HTTP/1.1とHTTP/2は、Webサーバのリソース特性や配信対象地域などを分析した上で、適切に使い分けてほしいですね。

白石 え、そうなんですか？全部HTTP/2にすればいいのかと思ってました。

竹洞 近所のスーパーに車で行くか、自転車で行くかってなると、自転車のほうが速い場合も多いわけじゃないですか。それと同じで、条件によっては、実はHTTP/1.1の方が速い場合も存在します。

白石 具体的にはどんな条件でしょう？

竹洞 ネットワーク距離、リソース配信サーバ数、オブジェクト数、転送容量などですね。ネットワーク距離の観点では、HTTP/1.1は近いほど、HTTP/2は遠いほど有利です。リソース配信サーバ数の観点では、HTTP/1.1は多いほど、HTTP/2は少ないほど有利です。単純にオブジェクト数だけを考えると、HTTP1.1は少ないほど、HTTP/2は多いほど有利です。

白石 じゃあ、例えば先ほどから話に上がってるサードパーティのスクリプトなんかは、ドメインもバラバラだし、アクセスはほとんど1回こっきりだし、HTTP/1.1が活きてくる分野かもしれませんね。

CDNは遅い？？？？？？そして「ADN」ってなんだ？

白石 あと、先ほど「後で語る」とおっしゃっていた、CDN (Contents Delivery Network)についてもお話いただきましょうか。

竹洞 CDNについては、実際のところを知ると、皆さん驚かれると思いますよ。実は、CDNはもう速くないんです。

白石 えっ…！そうなんですか？ちょっと意味がよくわからない。

竹洞 ネットワークに対する投資額の規模を表した図としては、こういうものがよく使われます。上がファーストマイル、事業者に最も近い部分で、サーバーやクラウドに代表されるレイヤーです。一方一番下がラストマイル。ユーザーに最も近い部分ですね。

この図を見てわかる通り、ラストマイルとファーストマイルには多くの投資が行われてきました。エンドユーザーに近い部分のネットワークは、相当高速化されてきている。

以前はCDNは、ラストマイルを高速化するためのサービスとして有力でした。ただ、業界全体でラストマイルに多くの投資が行われた結果、CDNの有用性そのものが薄れてしまいました。なので、CDNに置くよりも自前で配信したほうが速いという状態が一般的になっているのです。

白石 そうなんですか。CDNが速くないなんて…。

竹洞 なので、CDNのベンダーは速度じゃなくてロバストネス、堅牢性をウリ文句に変えるところも出てきています。ただそれは、第一世代のCDNと言われていたサービスの話です。

Fastlyに代表される第2世代のCDNは、POPs (Points of Presense:CDNのサーバーを物理的に配置する位置)を最適化するというアプローチで、大きくこの分野を前進させました。

そして今、この分野は第三世代に入ろうとしています。Instart Logic社なんかはその代表で、私もエヴァンジェリストを務めていますが、自身を「Application Delivery Network」と呼んでいますね。

白石 それは、具体的にはどう違うんですか？

竹洞 ひとことで言うと、非常にインテリジェントなのです。まずサーバー側では、機械学習を用いて基地局ごとに最適な経路を割り出すので、非常に動的な最適化が行える。

また、クライアントとサーバーがコミュニケーションしながら、リソース取得の最適化を図ります。具体的には、クライアント側に「ナノバイザー」と呼ばれるJavaScriptのエージェントを走らせます。ブラウザ側の仮想マシンと言ってもいい。そのナノバイザーが、サーバーと様々な情報を常にやり取りしながら、リソースの最適な取得方法を探るわけです。

白石 なるほど。そういうことをするには、クライアントとサーバー間でステートフルなコネクションが必要になりそうですが、そこはどうしてるんですか？WebSocket？HTTP/2？

竹洞 HTTP/2です。HTTP/2をフル活用して、初めて実現するアーキテクチャですね。他にも、サーバ側でJavaScriptコードを分析して必要な関数のみをクライアントに送るといったアグレッシブな転送量削減や、サードパーティ製スクリプトを自分のドメインから配信してHTTP/2の恩恵を最大限受けることも可能です。

白石 それはすごい。

竹洞 モバイル向けのライブラリとかもあるのですが、本当に高速ですよ。速度のためにTCPの代わりにUDPを使用していて、そうなるとパケットのエラー検知と再送制御が必要になるわけですが、一定のパケット数ごとに誤り検知のためのチェックサムを付与して、ライブラリ内でエラー制御することで解決しています。

白石 機械学習やHTTP/2といった、基盤技術の進化をフル活用して、コンテンツの配信をこれまでにないレベルで最適化するというわけですね…。面白い。

「パフォーマンス・バジェット」というパラダイムシフト

竹洞 あと、パフォーマンス業界の最新動向という点でいくと、アメリカでは「パフォーマンス・バジェット」という考え方が浸透してきています。

白石 なんですかそれは？初めて聞く単語ですが。

竹洞 パフォーマンスの目標を立てると、使えるリソースの量は限られてくるわけです。例えば、前回の座談会でもお話した「モバイルで3秒以内に表示を開始するためには、リソースを200kb以内に抑えるべき」といったように。で、そのリソースをどう割り振るかをサイトの設計段階から計画しておくという考え方です。（筆者注: パフォーマンスバジェットについては、ミツエーリンクスさんのブログに詳しい紹介があります）

白石 その考え方は面白いですね！全然知りませんでした。そして、そういう概念が出てくるくらい、海外ではパフォーマンスの重要性が浸透しているということなんですねえ…。パフォーマンスを「リソースの量」という点で定量化することで、リソースのサイズやフェッチのタイミング、開発コストの投下量など、いろんなものをコントロールできるようになりそうです。

うちみたいなスタートアップ企業（TechFeedというサービスの運営企業）とかだと、機能実装が優先になっちゃって、パフォーマンスという項目がどうしても優先順位上がらないんですが、そういう状況の改善にも役立つかもしれませんね。

竹洞 そうですね、パフォーマンス・バジェットの考え方は、スタートアップにも有効だと思います。計測サービスにお金を払い続けるのが厳しい…という事業規模の企業にも有用かな、と。

白石 え、それどういうことでしょう？

竹洞 優秀な計測サービスって、やはりそれなりに高額なんですよね。規模の小さい企業だと、サービスを運営しながらずっと使っていくのは厳しい。 ただそれでもパフォーマンスを担保したいという場合、パフォーマンス・バジェットを見積もるために、最初だけ計測サービスを使用するということができるわけです。あとはそのバジェット内でリソースをやりくりするよう注意していけば、一定のパフォーマンスが担保された状態になります。

白石 なるほど。まずそもそも、パフォーマンス・バジェットを見積もるには、ある程度の計測と実績値が必要だと。そのために計測サービスに最初だけ課金するということですね。一旦見積もったバジェットを守りさえすれば、パフォーマンスが担保された状態になる、というのもロジカルでスッキリしますね。

品質保証（Quality Assurance）は今後重要なキャリアになる！

白石 では、お時間もかなりオーバーしてしまいましたが、最後に読者に向けて伝えたいこととかありますか？

竹洞 そうですねえ、私はパフォーマンスも含め、Webサイトの品質保証というところにずっと注力しているわけですが、今後このQA (Quality Assurance)という分野は非常に重要になると思っているのです。例えば、2019年に民法が改正されて、システム開発の受注側が品質保証の責任を負わなくちゃいけなくなります。現在の「瑕疵担保期間」という単語は条文から消えて、品質保証を行って納入しないと「重過失」という扱いになって、永遠に瑕疵責任を負うことになるんです。つまり、品質を満たすまで、タダ働きになるってことです。

白石 それはすごい変化ですね…。開発や制作を受託している企業にとっては大問題だ。

竹洞 こういうこともあるので、今後はQAのスキルが非常に求められてくるのは間違いありません。現在日本にはQAという職種がほとんどない状態ですが、だからこそQAを行えるエンジニアは非常に希少価値があると思います。それができるようになれば、今後のキャリアを考える上でも非常な強みになるのではないでしょうか。

白石 うーん、最後まで大変示唆に富む発言、感謝です。本日は大変勉強になりました。貴重なお時間を割いてインタビューに答えていただき、どうもありがとうございました！

今回は、HTML5 Experts.jpでWebパフォーマンスに関する特集を行うにあたって、エキスパートの皆様による誌上座談会を開催してみました。

通常であれば数時間語っても尽きないような話を、1時間強でみっちり聞いてきました。 Webパフォーマンスの改善について、初心者から上級者まで楽しめる、有用な記事になっているかと思いますのでどうぞお楽しみください。

エキスパート紹介

白石 皆様、本日はお集まりいただいてありがとうございました！まずは簡単に自己紹介をお願いできますでしょうか？

竹洞 株式会社SpellDataのCEOを務めている、竹洞です。Webパフォーマンスには10年間くらい関わっており、年間200サイトくらいの計測に携わっています。 今度から、Instart Logicのエヴァンジェリストも務めることになりました。Instart Logicは、Application Delivery Networkを標榜する、いわばCDNの第三世代とも言えるものです。

白石 Contents DeliveryじゃなくてApplication Deliveryなんですね。その用語は、Instart Logicが独自で使っている用語なのか、それとも広く使われようとしている用語なんでしょうか？

竹洞 業界では広まりつつある用語ですね。具体的には仮想化技術と機械学習と組み合わせて、アプリケーションのリソース配信をこれまでにないレベルで最適化しようとするものです。

白石 なるほど、コンテンツデリバリーの業界は、そんなふうな進化が起こっているんですね…全然知りませんでした。次は川田さん、お願いします。

川田 川田です。ピクシブ株式会社の執行役員で、Chief Culture Officer (CCO:最高文化責任者) を務めています。 ここ最近は少しエンジニアリングから離れていますが、以前はWebパフォーマンス関連の記事を執筆したり、W3Cのメーリングリストで発言したりしていました。

最近だと、さくらインターネットさんと組んでImageFluxという画像変換のクラウドサービスを提供開始しました。弊社のサービスは、画像についてはユーザー様の要求レベルが極めて高いのです。

そこで得たノウハウを、モバイル時代のサービスの課題、それこそ、低速なネットワーク、多様なスクリーンサイズといった、画像の変換ニーズにあわせる形で他のサービス提供者のみなさんにも使ってもらえるようにしてます。

矢倉 ピクセルグリッドという会社でフロントエンドエンジニアを務めている矢倉です。Webの標準化にも関心がありまして、いろいろと関わっています。 パフォーマンスについては、レンダリングやスクロールと言った、クライアントサイドでの最適化に関心があります。

Webパフォーマンスについて、まず思うこと

白石 ではまずは、Webパフォーマンスについて思うところをざっくり語っていただけますでしょうか？

竹洞 そうですね、まず総じて言えるのは、Webページのパフォーマンスに悪影響を及ぼしているのは主にサードパーティ（が配信するリソース）だということです。この1年で200以上のWebサイトを見てきましたが、その80%以上で、ページ内のソーシャルボタンや広告など、サードパーティによって配信されるリソースがパフォーマンス悪化の主な原因になっていました。

またちなみに、モバイルネットワークについては、この1年でdocomoさんがだいぶ頑張ったので、ボトルネックがかなり解消されました。最近だと、SoftBankさんの遅延が少し目立ってきている印象です。

白石 なるほど、サードパーティが80%…ちなみに、広告がパフォーマンスのボトルネックになっているとして、それをどうやって改善するんですか？手を付けられない部分なのでは？

竹洞 広告配信側の企業との交渉ですね。

白石 なるほど(笑)

竹洞 とはいえ海外の企業だと、そういう交渉に応じて改善してくれるところはまずありませんが、国内だと改善してくれる場合はありますね。

白石 でも、広告のパフォーマンスが悪いというのは配信側にとっても問題なんじゃないでしょうか？

竹洞 そのはずなんですが、今のところあまりそこに気を払っている業者は少ないです。ただ、海外のアドテク大手である「Criteo」と「SteelHouse」が裁判で争った結果、いろいろな問題のある証拠が出てきたこともあり、アドテク業界そのものがいろいろと見直される時期に来ているのは間違いない。そういう流れの中、広告のパフォーマンスなどについても注目が集まるようになるかもしれません。

川田 アド周りの問題を除くと、フロントエンドのパフォーマンスにおいては、ページのリフローがほとんどと言えるんじゃないかなと思ってます。

矢倉 確かに、動きの少ないサイトとかだと、リフローが主な要因なのは間違いないですね。ただ、JavaScriptを多用したインタラクティブなWebアプリとかだと、そもそも「速い、遅い」の定義をどこに置くかというところから問題になってくると思ってます。

インタラクティブになればなるほど、操作にかける時間や回数が多くなるので、その反応速度なども見るのが重要になるんじゃないかと。、そうなると、リフローもそうですが、画面のペイント処理も問題になることが多いですね。たとえば、動きのある要素が別のレイヤーに分けられておらず、画面全体が再描画されちゃう、そういうことが多いかなあと。

白石 ではそろそろ、具体的なパフォーマンス改善テクニックについて、詳しくお聞きしていきたいと思います。本媒体（HTML5 Experts.jp）はフロントエンドエンジニアが主な読者なのと、インタビュー時間も限られていますので、今回はバックエンドのパフォーマンス改善は取り上げず、フロントエンドとネットワークに絞ってお話をお聞きしたいと思います。

フロントエンドのパフォーマンス改善テクニック

白石 では、フロントエンドのパフォーマンス改善テクニックについてお聞きします。ここについては、以下のような項目についてお聞きしようかと思います。

• リフロー
• ペイント
• スクロール
• DOM

先ほどリフローのお話が出ていましたが、リフローに関してパフォーマンスを改善するというのは、具体的にどのようなことなのでしょうか？

川田 単純に言うと、リフローを発生させないか、発生してしまったとしてもそのコストを減らすということに尽きると思います。

白石 なるほど。それは、widthやheightと言った、レイアウトに影響のあるプロパティの操作を最小限に抑えるとか、でしょうか。

矢倉 そうですね。最近だと、CSS ContainmentっていうCSSプロパティもあります。これは、リフローなどのレイアウト変更や、描画の範囲を制限するためのプロパティです。 （筆者注: 現在はChromeのみ実装で、実装された際の紹介エントリが詳しい）

川田 あとこれは以前からあるテクニックですが、リフローを発生させることなく要素の見た目を変化させるためにtransform:scale()などを使用したり、transform:translateZ()を指定して合成レイヤーを生成したり、でしょうか。 ここらへんは、GPUをいかにうまく活用するか、という話と重なるところがありますね。

白石 GPUの活用、という点で言うと他にもありますか？

川田 will-changeプロパティとかでしょうか。結局、「いかにGPUに載せるか」って話になるんですよね。あと、GPUの活用を始めたブラウザは（意外にも）Internet Explorerだった記憶があります。 （筆者注: will-changeについてはこちらが詳しい）

矢倉 ちょっと違う話ですが、Windows Vistaの動作要件にそれなりの性能を持つGPUが求められていたこともあり、ラップトップでもGPUが普及したという話を聞きました。現在ブラウザでGPUが一般的に使われるようになった遠因とも言えるかもしれませんね。OSとしては、評判良くなかったですが…。

白石 他には、ペイント処理を改善するとしたら、border-radiusやbox-shadowなど、負荷が高いと言われているCSSプロパティの使用をなるべく控える、といったところでしょうか。 （筆者注: border-radiusとbox-shadowを併用すると遅くなる、というのは有名な話です）

白石 スクロールについてはいかがでしょう？

矢倉 スクロールや初期ロードについては、ユーザーとのインタラクションを阻害して、体験を損ねてしまう「ジャンク」と呼ばれる処理をいかにうまく避けるかが重要になってきます。 そのためのAPIはいくつかあります。

例えば Passive EventListenerは、イベントハンドラ内で preventDefault() が呼ばれないことをブラウザに伝える機能を addEventListener()に加えたものですが、これを使用すれば、ブラウザはイベントハンドラの戻りを待たずにスクロール処理を進められます。 （筆者注: JxckさんのPassive Event Listeners によるスクロールの改善という記事が参考になります）。

川田 また、スクロール中に走る処理を throttleする（筆者注: 一定期間内に発生した処理をまとめ、一度の処理としてしまう）とかもやりますね。

矢倉 ほかパララックスなページなどで、scrollイベントに引っ掛けて何かするという処理は多いですが、結局のところ「特定のDOMが出現したら何かの処理を行う」ということでまかなえることが多い。そんな話があって登場したIntersectionObserverというAPIを使うと、要素が画面内に入ったことや、要素同士が交差したことを検知できます。

（筆者注: こちらもJxckさんの記事が参考になります: Intersection Observer を用いた要素出現検出の最適化）。

白石 すごく勉強になります、ありがとうございます。ほか、最初に挙げていたトピックとしてはDOMに関する最適化が挙げられますが、ここは何かありますでしょうか？

川田基本的な話としては、Forced Synchronous Layoutを避けるというのがありますね。

白石 ふぉーすどしんく…？なんですか？

川田 Forced Synchronous Layoutっていうのは、例えば要素の幅（width）や高さ（height）、位置など、「レイアウト処理を行ってみないと決まらない」タイプの値をJavaScriptから参照したりすると発生する強制レイアウト処理のことです。できる限りそういう値を参照するのは避けなくてはなりません。

白石 なるほど。ただ経験から言うと、そういうプロパティを参照したくなることって割としょっちゅうあるのではないでしょうか？

矢倉 はい、なので、そういう処理を可能な限り減らすようにコードを書く努力が必要になります。例えば、一度取得した値を変数にキャッシュして使いまわす、とかですね。どのコードの負荷が高いのかを見極めて、意識したプログラミングが重要ですね。

白石 ここまでで、たくさんのJavaScript APIが紹介されていましたね。requestAnimationFrame()、IntersectionObserver、Passive EventListenerとか。他にもありますか？

川田 例えば、requestIdleCallback()とかですかね。これはそれほど優先度の高くない処理を、ブラウザがアイドル状態な時に実行するというものです。 ちなみにこのAPIは、「setImmediate()が必要かどうか」という議論の中から生まれたものです。ただ、少し用途は違うんですよね。

白石 setImmediate()は、ただ単に処理をイベントループの末尾に回したいだけですもんね。

川田 ほかは計測系のAPIでしょうか。Navigation Timingとか、Resource Timingとか。こうしたAPIを使えば、JavaScriptからパフォーマンス計測が行えるので、最適化に役立てられます。

ネットワーク関連処理の改善

白石 ではここからは、ネットワーク関連のパフォーマンス・チューニングについて語っていただきたいと思います。まずは転送量の削減についてですが、基本的な項目としては、例えばソースコードのminifyと結合などが挙げられるかと思います。

他には画像の最適化なども含まれると思います。imageminなどを使ってサイズを減らしたり、webpに変換するなども挙げられますよね。

矢倉 ほか、レスポンシブイメージのテクニックも重要ですね。img要素のsrcset属性や、picture要素とかで、不必要に大きな画像を送らないようにすると。 ただ、最近はスマートフォンの画面のピクセル密度が3倍、4倍とかになっています。そんな端末に合わせて、ばか正直に高解像度の画像を書いてしまうと、転送量も非常に大きくなってしまう。 そうならないようきれいなものを提供したい画像を優先度つけて選ぶとか、あとは可能な限りSVG…ベクター画像を用いるようにも心がけるべきですね。

白石 ベクターといえば、アイコンフォント（筆者注: アイコンをWebフォントとして作成して利用する）もよく使われるテクニックですよね。

矢倉 ただ、最近はアイコンフォントは良くないプラクティスとして認識されつつあります。

白石 え、そうなんですか。

矢倉 テキストコンテンツなので、Webフォントファイルが読み込まれた際にリフローが起こることや、Webフォントのファイルががダウンロードされるまでにタイムラグが大きいことが問題です。 あと、iOS Safariのコンテンツブロッカーには、Webフォントをブロックするものもあるんです。そうなると、アイコンが全く表示されないことになってしまう。

そういうこともあって、SVGスプライトなどをを使うのが望ましいという流れになっています。

白石 そうなんですね…ちなみにWebフォントのダウンロードについてですが、CDNで共有されているものがクライアントのブラウザ上にキャッシュされていることを期待してしまうのですが、実際のところどうなんでしょう？

竹洞 いや、あまり期待できないですね。

白石 ええっ！？

竹洞 基本的には自分のサーバーで配信するのが一番速いです。

白石 そうなんですか！？それは…割とショックです。むしろ「CDNが使えなかったら自分のサーバーからフェッチする」みたいなコードの書き方をしていました。 サードパーティのライブラリも、わざわざファイル結合やモジュールバンドルの対象から外して、CDNから読むようにしていたり。。

竹洞 冒頭で申し上げた「遅延原因の80%がサードパーティ」というのは、そこにCDNも含まれるんです。自前で配信するのが結局一番速い。

白石 なるほど。ではこの流れで竹洞さんに、ネットワーク関係の最適化のお話をもう少し伺いたいと思いますが、DNSに関してはいかがでしょう？

竹洞 DNSに関しては、世界的に遅延している状態です。どのサーバーもパンパンで。Bindのセキュリティ問題などもありますし、DNSは現在大きく問題になっています。 あと、皆さんTTL短すぎなんですよね。5分から10分とかに設定している。

白石 じゃあ、ちょっと長いコンテンツを読んだりしているうちに、DNSのキャッシュ切れちゃってたりすることもあるわけですね。 なんでそんなに短くしてしまうのでしょう？

竹洞 それはやはり、何か問題が生じた時に切り替えられないのが怖いからでしょうね。TTLをみんなが1時間とかに設定するだけで、DNSトラフィックの問題は大きく改善するのですが、難しい問題です。

白石 DNSの話から思い出したのですが、DNSの先行読み込みとか、HTMLで指定できるようになってますよね、たしか。

川田 はい、 <link rel="dns-prefetch" href="<origin>">という形式で指定できますね。あと、<link rel="prefetch" href="<URL>">というのもあって、DNSに限らず、任意のリソースをプリフェッチできます。

（筆者注: DNSプリフェッチでウェブページの読み込み速度をスピードアップ、Link prefetching FAQ）

矢倉 あと、プリロードという仕組みもあります。<link rel="preload" href="/styles/other.css" as="style"> のように指定して、リソースの先読みを行えます。

（筆者注: 仕様書によると、prefetchとpreloadの違いは、前者が必ずしも先読みされるわけではなく、低い優先度で先読みされるのに対し、後者は強制的、高い優先度で先読みされる）

矢倉 使うといいと思うのが、CSSファイルに書かれているWebフォントや画像でしょうか。ほとんどの場合、それらのファイルは読み込まれるのがわかっているので、それらをプリロードすると、CSSファイルの読み込みを待たずにダウンロードできます。

白石 他にお聞きしたいことがあるとすると、Service Workerのオフラインキャッシュとかです。これはどんどん使っていくべきでしょうか？

矢倉 自分自身まだ使ったことがないので、あまり語れませんが…Progressive Web Appsの文脈で、App Shellという、アプリの「ガワ」をService Workerにキャッシュさせて、最初の描画（First Paint）を速めようという話がありますね。

川田 ただ、キャッシュの更新方法についてもきちんと設計しないと酷いことになりますよね。Webアプリケーションにおけるデプロイを、Service Worker側でどのように扱うのかという問題。サーバー上のリソースが更新されたときに、ブラウザ側へどのように反映するのか。複雑化は避けられないですよね。

白石 確かに。それもあって、ぼくらも自分たちのサービスでは、Service Workerのキャッシュを利用するコードまでは用意したのですが、結局有効化してないです。

最後に、竹洞先生からひとこと

白石 では、だいぶお時間もかかってしまったので、まだまだお聞きしたいことはあるのですが、そろそろ締めに入りたいと思います。最後に、読者の皆様に伝えておきたいこととかありますか？

竹洞 じゃあ、最後に一つだけ。サーバの転送量削減についての目安ですが…。

白石 はい、お願いします。

竹洞 モバイルだと、全体で200kbを超えるページは、配信に3秒以上かかってしまいます。転送量削減については、これを目安にするのはいいのではないかと思います。

白石 えっ、200kbですか？クライアントにキャッシュされているリソースがあることは期待していいんですか？

竹洞 いえ、キャッシュなしで。先ほどもありましたが、モバイルだと、あんまりキャッシュが期待できないので。

ほか全員: (マジか…つらい…)

竹洞 頑張ってくださいね（ニッコリ）

最近、モバイルではネイティブ一強という状況にみえます。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は、WordPress上で動作しており、改善内容はプラグインの導入やPHPのコード修正が主になっています。ただ、そういったWordPressの泥臭いチューニングは本題ではないので、細かく解説するのではなく大まかな改善内容とその方針を説明したいと思います。また、改善内容に関しても費用対効果がある程度高いものを優先しているため、まだまだ改善できるというところも、あえてそのままにしているところもあります。

今回の改善内容は、前回の分析結果から以下のようになっています。その分析内容などについては解析編をご確認ください。以下の改善ポイントとその順番に沿って解説していきます。（順番は、改善内容の導入のしやすさや影響の大きさなどを考慮して実際に実施した順序になっています）

改善ポイント

1. ソーシャルメディア系サービス（シェアボタンなど）のパフォーマンスを改善する
2. 実際の表示サイズより大きな画像は適正なサイズに変更する
3. マークアップを改善する（書き方やJSのミニファイ等）
4. WordPressのキャッシュを導入する
5. Keep Aliveが全ての環境で効いているか、設定時間は適切かを確認し、コンテンツダウンロード時間を最適化する

ソーシャルメディア系サービスのパフォーマンスを改善する

まず最初に着手したのは、ソーシャルメディア系のガジェットなどです。HTML5 Experts.jpでは、トップページにはTwitterのタイムラインとFacebookのウィジット、記事ページには、各種シェアボタンとFacebookのコメントを埋め込んでいました。これらのソーシャル系のガジェットは、多数のリソースを読み込んだり、スクリプトによるメインスレッドのブロッキングなどでユーザーの体感スピードを劣化される主たるものです。まずは、不要なガジェットの整理ということで、ほぼ利用がなく効果が不明なTwitterのタイムライン、Facebookのウィジット、Facebookのコメントは完全に削除することにしました。これだけで、トップページからはソーシャル系のガジェットが完全になくなることになります。次に記事ページのソーシャルボタンですが、ソーシャルボタンのスクリプトを読み込まないように自作することにしました。現在（改善後）のソーシャルボタンは次のようになっているはずです。

PC版ソーシャルボタン

モバイル版のソーシャルボタン

これらのソーシャルボタンでは、例えばTwitterのツイートなどを直接リンクで指定しており、onclickで小さいウィンドウが開くように変更しています。そのため、APIを利用しなければ実現できないFacebookの「いいね」と、Google+の「+1ボタン」は、いずれもシェアボタンに変更しています。各ボタンのカウント数については、サーバー側でキャッシュして表示する「SNS Count Cache」というプラグインを導入して利用しています。

ソーシャルメディア系のガジェットの改善は非常に効果が大きく、以下のようにPC版の記事ページでは、ページの読み込み時間が5秒近辺だったものが、2.5秒のほどに劇的に改善しています。また、バラツキがあった計測時間が小さい範囲に収まるように収束しています。

PC版記事ページの読み込み時間（折れ線グラフ）

PC版記事ページの読み込み時間（スキャッタプロット）

実際の表示サイズより大きな画像は適正なサイズに変更する

次は画像サイズの縮小です。HTML5 Experts.jpでは既に画像の最適化を行う「EWWW Image Optimizer」プラグインを導入済みでしたが、画像のサイズ自体はあまりケアしていませんでした。そのため、記事によっては原寸サイズの画像を貼り付けているものもあり、ダウンロード容量が非常に多いページもありました（WordPressの場合、画像を挿入する際にサイズを選択できます）。また、お恥ずかしながら、アイキャッチ画像を設定している記事については、記事一覧でサムネイルに原寸サイズの画像が表示されるというバグも見つかりました。そこで、以下のように対応することに決めました。

• 画像の最大サイズをPC版記事ページの横幅に合わせ640pxとする
• 画像の最大サイズより大きな画像がアップロードされた場合、強制的にリサイズする
• 記事一覧で、適切なサイズのサムネイル画像を表示するように変更

画像の最大サイズ

記事一覧のサムネイル画像

まず初めに、画像の最大サイズを変更します。WordPressでは画像のサイズを設定画面で変更することができ、デフォルトでは「大サイズ」の設定値は1024×1024に設定されている部分を640×640に変更します。しかし、これだけでは編集者が誤ってフルサイズの画像を挿入することができてしまうため、それより大きい画像がアップロードされた場合に強制的に640×640にリサイズするようにします。これは、「Imsanity」というプラグインを導入することで解決しました。

次に、記事一覧で適切なサイズのサムネイル画像を表示するように変更します。PC版の場合、サムネイル画像の表示サイズは幅207pxとなっていたため、それに合わせて画像をアップロードする際に自動的に幅207pxのサムネイル画像を作成するように変更しました。同時に、記事一覧を出力する際にサイズを指定して画像を表示するようにコードを修正しています。（これらの詳細なコードは例示しませんが、add_image_size the_post_thumbnail wp_get_attachment_image_src 等のキーワードを調べていただければ見つかるかと思います）

ここでモバイル版について考慮されていないと気がついた方がいらっしゃるかもしれません。モバイル版のサムネイル画像のサイズは、幅93pxとなっていましたが、これをこのまま適用してしまうと高精細なディスプレイではぼやけてしまうため、そのままPC版と同じものを表示するようにしました。本来であれば、レスポンシブイメージを採用するのが理想だと思いますが、この時点ではリソースの問題から断念しています。

最後に、既存の画像ファイルに対して、これらの変更を反映する必要があります。最大サイズの変更と新たなサムネイル画像の表示サイズの追加については、「AJAX Thumbnail Rebuild」というプラグインを使ってバックグラウンドですべて処理しました。その後、「Imsanity」、「EWWW Image Optimizer」プラグインについても、既存の画像に対するオプション機能を使って再処理を実施しました。これで、すべての画像は適正なサイズに変更されたことになります。

マークアップを改善する（書き方やJSのミニファイ等）

ここで実施するのは、不要なスクリプトやスタイルを整理したり、ファイルの結合やミニファイなど、一般的なWebパフォーマンスのベストプラクティスに近いものです。しかしながら、WordPressではすべてのページでjQueryを読み込んでいたり、いろいろなプラグインがそれぞれファイルを読み込んでいたりと、かなり奔放な状況です。そのため、実際の作業はここが一番泥臭く、複雑なものになりました。改善内容は、主に以下のようなものです。

1. すべてのページで読み込んでいるスクリプト、スタイルを調査する
2. 不要なスクリプト、スタイルを削除する
3. スクリプト、スタイルの移動、結合とミニファイ（「Autoptimize」プラグイン）

まず、1番と2番ですが、初めにすべてのページで読み込んでいるスクリプト、スタイルを調べます。HTML5 Experts.jpの場合、主にトップページ、記事ページ、その他のページの3種類になります。その他のページにもいくつか種類がありますが、スクリプト・スタイル構成は似たようなものになるので、ここでは省略しています。また、上記3種類がそれぞれPC版、モバイル版とあるので計6種類ということになります。これらの各ページでは、HTMLソースコード内のべた書き（scriptタグなど）やWordPress上で読み込まれているリソース、実際にブラウザに表示されているページ上で読み込まれているファイルなどを調べます。（WordPress上では、wp_enqueue_scriptsをフックしてそれぞれのハンドル名を表示します）

その後に、どのプラグインが読み込んでいるのか、それらは本当に必要かどうかを判断します。プラグイン自体が不要であればプラグインを削除し、スクリプトやスタイルの読み込みのみを止めたいのであれば設定変更で対応可能か判断し、最終的にはWordPress上で個別の種類のページに対してスタイルを削除します。例えば、「Facebook」公式プラグインは、すべてのページでFacebookのスクリプトを読み込むようになっており、ソーシャルボタンを廃止した関係もあって完全に削除しています。その際にプラグインが提供していたOGP設定などは手動で追加しています。また、モバイル版のトップページではjQueryは不要のため、トップページでのみjQueryを読み込まないといった形になっています。（WordPress上では、wp_enqueue_scriptsをフックしてif文でそれぞれのページ上でwp_dequeue_scriptやwp_dequeue_styleなどでスクリプトやスタイルを読み込まないようにしています）

そして肝心の改善結果ですが、実は問題があり、ページのHTTPリクエストから最初のデータが返ってくるまでの時間（TTFB: Time To First Byte）が遅延するという事象が発生しました。これは、元々WordPressではDBアクセスなどがあり、時間がかかっていた箇所でしたが、加えて今回のAutoptimizeがファイルの結合、ミニファイを行うためにバッファを読み込んで処理している関係でさらにTTFBが伸びるという結果になりました。そのため、スクリプト・スタイルのファイル数とサイズが減ったにも関わらず、結果としてパフォーマンスは相殺され、逆にロード時間が若干長くなるという状態になりました。そのため、Autoptimizeを導入する場合は、基本的には後述するキャッシュを導入する必要があるという結論となりました。

TTFBの遅延（ウォーターフォール図）*青い部分がTTFB

WordPressのキャッシュを導入する

WordPressは、簡単にページを構成して表示できる反面、PHPの処理やDBアクセスが発生するため、TTFBが遅くなりがちです。そのため、HTML5 Experts.jpのような、ある程度表示内容が変わらないサイトの場合はキャッシュプラグインを導入するのが望ましいでしょう。今回、キャッシュプラグインには、ページキャッシュ、オブジェクトキャッシュ、DBキャッシュの3つが可能な「W3 Total Cache」と、WordPressのUIの日本語化のための翻訳ファイルをキャッシュする「MO Cache」を導入しました。いくつかあるキャッシュプラグインのうち、W3 Total Cacheを採用した理由は、現在PC版、モバイル版のテーマを「Multi Device Switcher」でブラウザ（UA）によって切り替えていますが、W3 Total CacheにはUser Agent Groupごとにキャッシュできる仕組みがあることです。

これにより、現在はアクセスのある記事ページなどは、キャッシュが1時間保持されるような設定になっています。キャッシュは記事が公開されるとクリアされ、再度アクセスがあるとキャッシュされるようになっています。そのため最初に記事にアクセスした人は若干遅いと感じることがあるかもしれません。また、ソーシャルボタンなどのカウント数も即時には反映されなくなっています。

キャッシュを導入した結果、なんと2〜3秒かかっていたTTFBが100ms前後にまで改善しました。体感速度でもかなり快適に表示されるように、非常に高い効果がありました。

TTFBの改善（ウォーターフォール図）

Keep Aliveが全ての環境で効いているか、設定時間は適切かを確認し、コンテンツダウンロード時間を最適化する

モバイルでKeep Aliveが効いていない問題については、結論からいうと、HTML5 Experts.jpで利用しているHTTPサーバーであるnginxの仕様が問題となっていました。元々、SafariにはKeep-Aliveが効いていると、ファイルがアップロードできないというバグ（該当のissueはこちら）があり、それに対応する形でnginx側はSafariに対してデフォルトでKeep-Aliveを無効にするという対策を取っています（keepalive_disableの設定）。HTML5 Experts.jpでは、ユーザーがファイルをアップロードするユースケースはないので、nginxの設定に”keepalive_disable none;”を指定してKeep-Aliveの無効を取り消しています。また同時に、Keep-Aliveのタイムアウトをデフォルトの75秒から20秒に変更しています。これは、現状の読み込み完了までの時間が20秒を超えることはほぼないためです。

その結果、モバイルでも同時接続数分のコネクション（別ドメインの接続を除く）を確保した以降は、Initial Connectionが消え、全体で2秒近く高速になりました。これを見ると、別ドメインへのアクセスを整理することによってもう少し効率化できそうではありますが、今回はここまでとしました。

モバイルのタイムライン（ウォーターフォール図） *Initial Connecctionはオレンジ色の部分

まとめ

これまで5つの改善ポイントについて、記事中の通り改善を実施してきました。これによってどのようにパフォーマンスが改善したのかを、この企画における全期間中のパフォーマンストレンドの推移でご覧いただきたいと思います。

全期間中のパフォーマンストレンドの推移（PC版）

全期間中のパフォーマンストレンドの推移（モバイル版）

いずれも大きく改善され、PC版では5秒台から2秒以下に、モバイル版では20秒前後で大きく揺れていたものが安定して8秒近辺に落ち着いています。これらの結果を受けて、解析編で掲げた改善目標が達成されているかどうかを、個別のデータで確認していきたいと思います。

改善目標

1. Total Time（サイトにアクセスした時点からブラウザ上でコンテンツ表示が完了するまでの時間）は2秒を切る
2. アクセスした際のTotal Timeに関する品質を一定にする（ばらつきをなくして一定にする）
3. 3G回線からのTotal Timeに関するアクセス品質をブロードバンド回線のそれに近づける

まずは、改善後のPC版の各ブラウザの計測結果を見ていきましょう。 次のグラフは、トップページの1日の計測結果です。（時間帯によってはネットワーク品質に揺れがあり、計測結果が多少上下します。）

PC版のTotal Time（折れ線グラフ） *Chrome:黄色、Firefox:青、IE:赤

それぞれの平均Total Timeは、Chromeが1.59秒、Firefoxが1.657秒、IEが1.125秒という結果となりました。当初目標の「Total Timeは2秒を切る」という点では、余裕を持ってクリアしています。特にIEの場合、1秒を切るケースもあり非常に高速です。次に同じデータをスキャッタプロットで分布を見てみましょう。

PC版のTotal Time（スキャッタプロット） *Chrome:薄緑、Firefox:オレンジ、IE:青

スキャッタプロットで見ると、各点がきちんと下に寄っているのがわかります。はずれ値も少し見られますが、およそ95%の計測値が2.5秒以下の範囲に収まっています。そのため、「アクセスした際のTotal Timeに関する品質を一定にする」も達成していると言えるでしょう。

最後に改善後のモバイル版のトップページの計測結果を見ていきます。次の2つのグラフは、3G回線でのXperiaとiPhone6S、参考としてLAN環境でのiPhone6を加えたものです。

モバイル版のTotal Time（折れ線グラフ） *Xperia(3G):オレンジ、iPhone6S(3G):赤、iPhone6(LAN):青

モバイルの場合、ネットワーク品質の揺れ幅が大きくなりますが、平均ではXperiaが12.863秒、iPhone6Sが8.601秒となっています。参考値であるLAN環境のiPhone6が平均0.486秒であることを考えると、3G回線がパフォーマンスに大きく影響していることがわかります。これは、画像ファイルの数、ダウンロード容量が多いためで、ネットワークに遅延が発生すると大きく影響します。この時の画像ファイル数は38で、サイト全体の容量は400KB程度になっています。これは、HTML5 Experts.jpのメディアの特性を考えると、ある程度はやむ得ないと思いますが、もう少し減らせるように工夫すべきかもしれません。救いとしては、遅延の原因が画像ファイルにあるので、ファーストビューへの影響は比較的少なく、体感速度は数値よりも早く感じるという点でしょうか。

モバイル版のTotal Time（スキャッタプロット） *Xperia(3G):薄緑、iPhone6S(3G):オレンジ、iPhone6(LAN):オレンジ

スキャッタプロットのほうを見ると、3G回線のために値の範囲が広がっていますが、概ね下に寄っているように見えるので許容範囲内であると言えるかと思います。しかしながら、前述の問題から「3G回線からのTotal Timeに関するアクセス品質をブロードバンド回線のそれに近づける」については、大きく改善してはいるものの課題が残っているという結論としたいと思います。

皆さん、いかがでしたでしょうか。本記事で改善した結果は是非、皆さんの手で体感していただければと思います。HTML5 Experts.jpでは、これからもパフォーマンス改善を続けていきますので、HTML5 Experts.jpを今後とも宜しくお願いいたします。また、この企画に大変なご協力をいただいた株式会社Spelldataの竹洞陽一郎さんにこの場を借りて厚くお礼申し上げます。ありがとうございました！！

補足事項

本記事で扱っている計測結果は、改善実施直後の数値です。現在の数値とは異なることがあることをご了承ください。特に本記事の内容より以降に、HTTPS（SPDY対応）化を実施しており、Total Timeは全体的に伸びています。そのあたりの対応についても、別の機会で紹介できればと思います。

24時間365日計測してますか？

まずは、有識者の方にいろいろとアドバイスをもらったほうがいいよね、ということで、株式会社Spelldataの代表取締役社長でありWebパフォーマンスに精通する、エキスパートの竹洞陽一郎さんに今回の企画の頭出しをしました。

仲：そんなわけで、HTML5 Experts.jpのパフォーマンスになんとなく不満を抱く声があるため、それを改善したいと思ってるんですよ。そして、その模様を赤裸々に記事として公開するというなんともマゾな企画を考えているのですが…ご協力いただけますか？

竹洞：もちろんです。協力しますよ！

ーあっさりOKが！

仲：ありがとうございます！じゃあ、手始めに今のサイトの状態を見てもらいましょうか。

そうして、私はおもむろにPCを広げて、Webサイトをプロジェクターに写そうとしました…。

竹洞：ちょっと待って下さい！

竹洞さんから待ったが！！！

竹洞：そうやって場当たり的にやっても、Webパフォーマンスの改善は意味がありません。まずは、現状を見極めるためにしばらくデータ計測する必要があります。さらに言うと、24時間365日、つまりは定常的に計測していくことが、Webパフォーマンスの改善には何より重要なんです。

仲：定常的な計測が必要な理由って？

竹洞：Webパフォーマンスに影響を及ぼす要因には様々なモノがあります。HTMLの書き方やWebサイトの作りなどコンテンツ面の要因もあれば、サイトをホスティングしているサーバの要因、サイト閲覧者が利用しているインターネット回線の要因、サイト閲覧者の端末要因等…挙げたら切りがありません。そして、それはら、日々変化しています。その一瞬だけを切り取って、パフォーマンスがいいとか悪いとか言っても、それは本質ではないんです。

仲：なるほどー。

この辺りの詳しい解説は、竹洞さんのインタビュー記事をご覧ください！

竹洞：まずは短期間ではありますがデータを計測しますので、その計測データを基に、現状整理をしましょう。

それから、Webパフォーマンス改善にあたって１つ確認があります。必ずと言っていいほど皆さんが引っかかることなのですが、Webサイトの構築運用に関する様々なしがらみを徹底的に排除できますか？

仲：ーしがらみですか？うーん、HTML5 Experts.jpは、限りなく非営利で、限りなく中立に近いメディアを目指しています。しがらみは少ないほうだと思いますよ。大丈夫です！（この自信はあとであっけなく崩れ去る…）

こうして、竹洞さんのご好意で、Keynote Systems社が提供するSynthesis Monitoring(合成計測)サービスにて、サイトのデータ計測が始まりました。

まずは計測対象の選定です。HTML5 Experts.jpでは、トップページと個別の記事ページの２種類が主なアクセス先になるため、以下のとおり、その2つを測定することにしました。

トップページ

＊画像は記事執筆時にキャプチャしたものです

個別記事（竹洞さんのインタビュー記事）

それぞれのページの計測条件は以下のとおりです。尚、スマートフォンデバイスは、実機ではなくシミュレータを利用します。これは、ハードウェアのスペックを統一することで、ハードウェアの性能差による遅延等の要因を排除するためです。

ちなみに後日談…計測対象の個別記事ですが、計測のためのアクセスがかなりの頻度あるため、PVランキングでは常に1位を独占していました（笑）。また、Google Analyticsについても、計測開始前に除外設定しておかないと、正確なデータが得られなくなりますので、ご注意下さい。

計測して問題点を洗い出す

ファーストバイトダウンロードタイムの遅延問題

ということで、竹洞さんに一定期間サイトのパフォーマンスデータを計測してもらいました。その結果を見ながら、早速現在のHTML5 Experts.jpの問題点を洗い出します。

竹洞：これがある日の、ブロードバンド回線でChromeを用いてアクセスした時の計測結果です。

見ての通り、ID1のhtmlの取得にすごく時間がかかっていることがわかります。この水色は、ファーストバイトダウンロードタイム（Time To First Byte、以下、TTFB）といって、サーバへのイニシャル接続からコンテンツの１バイト目が到着するまでの時間になります。このHTMLのTTFBの遅延は、計測期間全体を通して見られる傾向です。まずは、ここを短縮させるために、原因の調査、対策を行う必要がありますね。

仲：確かに、サイトアクセス時やサイト内でリンクをクリックした時に、一瞬ブラウザが固まったようになることが多々あるんですよね。何か引っ掛かってるなーって感じで。原因はこれでしたか。

竹洞：TTFBに時間が掛かる一般的な要因については、次のサイトの情報が参考になります。Diagnosing Slow Web Servers with Time to First Byte

よくあるパターンとしては、動的にHTMLを生成する処理に時間がかかっている場合が多いのですが、それには例えばこんな要因が挙げられますね。心当たりはありますか？ちなみに、3と4については、サーバサイドでレンダリングされるコンテンツ以外（たとえば、JavaScript）にも遅延が出ているので、今回に限って言えば、直接的な要因とは考えにくいです。

1. Memory leaks（メモリ不足）
2. Too many processes/connections（CPU性能不足）
3. Inefficient SQL Queries（SQLが最適化されていない）
4. Slow database call（データベースアクセスに時間が掛かる）

仲：HTML5 Experts.jpはNTTコミュニケーションズのCloudnというパブリック・クラウド・サービスを利用しています。VMのプランとしてはv8プラン（仮想CPU８コア、メモリ16GB）を選んでいます。今現在、メモリとCPUの使用状況を見る限り、そこまで枯渇しているとは思えないですね。

竹洞：なるほど。とはいえ、サーバサイド（ネットワーク環境含めて）のどこかにボトルネックがあることは確かなので、設定などを細かく見ていくしかないですね。あとは、サーバ側でキャッシュを効かせるのも手ですね。サーバサイドの処理に時間がかかっているとすれば、WordPressなどでキャッシュを効かせると、静的コンテンツをダウンロードするのとほとんど変わらなくはずなので、間違いなく効果は出ますね。

仲：WordPressのキャッシュはパフォーマンス改善では鉄板ですね。とはいえ、HTML5 Experts.jpでは導入できてないわけですが…。検討します！

コンテンツダウンロード時間の遅延

竹洞：次に、このデータを見て下さい。これはある日の、iPhone6を用いて3G回線でアクセスした時の計測結果です。情報メディアなので画像が多いのは仕方ないと思うんですが、ダウンロードに時間がかかりすぎてますね。だいたい50ms以下で終わるぐらいじゃないと体感的には遅く感じてしまうかなと思います。jsファイルも然りですね。3G回線なので回線状況によりけりですが。

仲：ダウンロード時間の遅延要因として、サーバサイドで気をつけることって何かありますか？

竹洞：そうですねー。画像データとかはCDNサービス（コンテンツデリバリネットワークサービス）を用意してそこから配信していますか？

仲：いえ、CDNは今は使っていません。全て同じサーバから配信しています。

竹洞：であれば、サーバのディスクスペックが影響しているんじゃないでしょうか？ディスクからのデータの読み出し速度ですね。オススメは、SSD等の高速なディスクを用意することです。また、できれば、画像データ等は専用サーバから配信した方がよいです。ハードディスクアクセスの競合を避けられて、負荷分散にもなります。大規模アクセスサイトでは、一般的に使われる手法です。

仮にそれが厳しいようであれば、サーバをもっとスペックアップするという手立てもありますが、クラウドサービス全盛の時代で、ディスク性能なんて大体のクラウドサービスでは開示されていないですよね。なので、画像に関しては、以下の様な対策を打つのはどうでしょうか？

1. そもそも画像の数を減らす（テキスト＋CSSやSVGで置き換えられるものは極力外す）
2. 実際の表示サイズより大きな画像は適正なサイズに変更する
3. Expiresヘッダ、Cache-Controlヘッダを付与してブラウザ側でキャッシュを効かせる（これはそもそもサーバアクセスしないので、一番効果が有ります）

仲：なるほど、なるほど。うーん、実はCloudnにはCDNサービスもあるんですよね。それの利用も少し検討したんですが、1つ問題があってですねー。HTML5 Experts.jpはCMSとしてWordPressを利用しているのですが、管理画面はSSLアクセスにしています。そして、CloudnのCDNがSSLに対応していないんですよ…。弊社（私はNTTコミュニケーションズ社員です）としては、社外のCDNを利用するにも、機能改善を要望するにも部署が違ってちょっとすぐには…あ、聞かなかったことにして下さい（笑）。

竹洞：Webパフォーマンスを継続的に改善していく上で、重要なことが1つあるのですが、知ってますか？

仲：え、なんですか？？？

竹洞：それは、前回の打ち合わせ申し上げましたが、様々なしがらみを断ち切ることです。

仲：あ……。

竹洞：今回みたいに、使えるサービスに制約があったり、社内で部署をまたがって運営していていたりする場合の責任のなすりつけ合いとかも、ある意味しがらみですよね。その他よくある事例としては、

「ECサイトなのに下手にパフォーマンス計測すると、悪い点部分がお客さんにわかってしまって逆効果になりかねないので…」

「お金かかりますよね、パフォーマンス向上に伴う費用対効果を説明できないので無理ですねー」

「パフォーマンスが重要ってのはわかってるんですが、構築から運用までSierさんに任せてるんで、ちょっと無理ですね…」

などがありますね。

そもそも、日本は、欧米に比べて、ソフトウェア品質が悪いんですよ。Webに関して言えば、その品質の悪さはさらに悪化します。そして、テスト系のソリューションやサービスが売れない市場としても、その業界では有名な話なんですよね。もちろん、各社それぞれの事情があることは承知しているのですが、聞いているだけで暗くなります。なので、できる範囲で頑張ってくれるだけでも、簡単にすごく品質が向上すると思います。それによる効果は必ず現れてきますよ。いかがでしょうか？

仲：わ、わかりました！できる範囲で頑張ります！さすが、HTML5 Experts.jpだ！というところを見せてやりますよ。

竹洞：さすが！（笑）。

白石（編集長）：話を戻して、クライアント側でのキャッシュですが、画像データの名称を全てユニークにしてExpiresヘッダーの時間を1年以上とかに設定するかんじでしょうかね。ただ、これは運用が難しいですね。画像を後から差し替える際は都度ファイル名を変更するなどの、工夫が必要ですから。特にHTML5 Experts.jpは記事をエキスパートやコントリビューターの皆さんに書いてもらうかたちを取っているので、きちんと運用を回すのは苦労しそう。

仲：そうですね。1についても、感覚的には置き換えできそうなところは限られてますので、まずは2の対策を検討しましょう。WordPress側のキャッシュと組み合わせるとかなり効果が出るかもしれません。

パフォーマンスには悪でしかないソーシャルメディア系サービスの導入

竹洞：次のデータはこちらです。これらも先ほどと同様に、iPhone6で3G回線を用いてアクセスした結果ですが、何が言いたいかといいますと、ソーシャル系サービスのシェアボタンやコメント機能などを埋め込んでいるため、それらに関係するファイルのダウンロードに多くの時間をとられています、ということなんですね。

特に回線が貧弱な3G回線でのアクセスの場合、これらのせいで本来見たいはずのコンテンツがなかなか表示されずに、サイト訪問者をイライラさせることはざらにあります。もちろん、マークアップの仕方次第である程度は改善されますけど、抜本的な改善にはなりませんね。

仲：うーん、なるほど。とはいえ、ソーシャル系サービスでの拡散って、我々のような情報メディアには必須なんですよね。これを全部なくすのは痛いですよ、痛すぎます。

竹洞：全部なくしてください！と、本来は言いたいところですが（笑）、今は自作のソーシャルボタンを導入しているサイトも結構ありますから、ソーシャルボタンを載せつつ、パフォーマンスを改善する手立てはあると思いますよ。

仲：ありがとうございます！わかりました、改善を検討します。

パフォーマンスを考慮していないWeb制作

竹洞：次はこちら。これは、比較的パフォーマンスがよいInternet Explorerによるアクセス結果です。何が言いたいかといいますと、だいたい分かるかとは思いますが、JavaScriptやCSSの数が多すぎですね。CSSはリファクタリングしてまとめましょう。JavaScriptは、サイトの運営上、本当に必要なものだけに絞りこみましょう。HTML5 Experts.jpともあろうメディアがこれじゃダメですよ…。

仲：す、すみません…そのとおりですね。

竹洞：こちらも見てみて下さい。これはChromeでトップページにアクセスした際の、TCPコネクションの数を可視化したConnection Viewというものです。1コネクションを維持する時間はサーバ側のKeep Aliveの設定時間次第ですが、その時間内で最大セッション数に達するまで通信を行うことで、ダウンロード時間を最小にするための努力をします。

画像を見ると、黒い帯の途中赤い帯が入っていますよね。黒い帯は1つのTCPコネクションを示していて、その中で並列ダウンロードが行われているのですが、途中でまったく別のTCPコネクション（赤い帯）が入ってきているため、無駄なオーバーヘッドが発生しています。この部分含めて、恐らく、マークアップのやり方などを工夫すると、あと6本程度はコネクションを削減することができると思われます。

仲：ほー。これはわかりやすいですね。あの赤い帯は、HTML5 Experts Worksのウィジェットに関する通信ですね。

竹洞：とはいえ、HTML5 Experts.jpについてはWordPressでHTMLを動的生成していますよね。そのため、マークアップの最適化については限界があると思います。そこは、トレードオフで問題ありません。当たり前のことですが、パフォーマンス・チューニングでは、費用・品質・期間のトレードオフは重要です。

また、ChromeやFirefoxの場合は、SPDY（HTTP2になればIEも対応予定）を活用することで、このTCPコネクションによるオーバーヘッドを最小限に押さえることが可能です。その代わり、SPDYを入れることのデメリット（オーバーヘッド）も発生するため、ターゲットブラウザなどを考慮して慎重に判断して下さい。

仲：ありがとうございます！運用上、WordPressをやめて全てスタティックなWebサイトに変えるのは、HTML5 Experts.jpとしては現実的ではないですね。まずは、できる限り、マークアップの見直しを検討してみたいと思います。

モバイル環境でKeep Aliveが効いていない

竹洞：次にKeep Aliveについて確認していただきたいことがあります。こちらをご覧ください。これは、iPhone6で3G回線を用いてアクセスした結果です。各オブジェクトのタイムラインのグラフにオレンジ色の帯が見えますよね。

仲：そうですね。これ、たしか、PCからのアクセス結果にはありませんでした。

竹洞：はい、モバイルアクセス特有の結果です。これは、Initial Connectionが毎回走っていることを示しています。Initial Connectionとは、いわゆる、TCP/IPの3way handshakesを指しています。新しいオブジェクトをダウンロードする度に、毎回TCPコネクションのオーバーヘッドが発生していることになります。先ほど、Keep Aliveの設定時間次第という話をしましたが、そもそも効いていない可能性があるため、必ず確認をお願いします。

仲：なんと…。分かりました。確認します。

Internet Explorerは優秀なやつ

仲：前のお話でターゲットブラウザを考慮してというコメントがありましたが、ブラウザごとの差異を見ることって可能ですか？

竹洞：はい、可能です。これは、トップページの表示開始時間の変化を一定期間、折れ線グラフにしたものです。Internet Explorerは赤紫色、Firefoxはオレンジ色、Chromeは緑色の線でそれぞれ描かれています。回線はブロードバンド回線を利用しています。縦軸がTotal Timeになっていて、短いほど好成績です。

表示開始時間というのは、ブラウザ画面上でコンテンツが表示開始されるまでの時間です。この時間はユーザエクスペリエンスに影響してきます。ちなみに、人間がモノを認識するまでがだいたい200msと言われています。Microsoftは表示開始時間500msを推奨しています。感覚的にはテニスのサーブを打って打ち返してくるまでの時間ですね。決めの問題ですが、私の経験上、いきなり500msは無理としても、最低2秒は切ってほしいなと思います。

仲：2秒…。

竹洞：それから、グラフをみて分かる通り、Internet ExplorerやFirefoxが、Chromeに比べ健闘していることがわかります。こういうデータ計測を行うと、経験上、Internet Explorerが一番成績が良くなることが多いですね。

仲：こんなに差が出るんですかー。同じコンテンツなのに驚きました。それにしても、なぜChromeだけこんなに違うんですか？

竹洞：Chromeがなぜこんなに時間がかかっているかというと、前処理（ex DOM構築や、プリフェッチ、並列ダウンロードとか）が長いためだと思います。

仲：表示開始時間なので、テキストコンテンツだけでも先に表示されていればこれはこれはクリアできるんですよね？

竹洞：そうです、その通りです。ブラウザごとの差異もありますが、コンテンツの作り方次第では、高速化できる可能性もあります。繰り返しになりますが、2秒は最低でも切ってほしいですね。ちなみに、ブラウザ同士の比較であれば、正規分布にしてみてもいいです。これも先ほどの折れ線グラフと同じデータから生成しています。

Chromeの結果

FireFoxの結果

Internet Explorerの結果

比較すると、Chromeの裾野の広さは否めませんね。裾野が広いということは、それだけ表示開始時間にばらつきがあるということなので、品質の悪さにつながります。ちなみに、Internet Explorerのバージョンは9です。

白石（編集長）：9でこの違いですか！開発者目線だとどうしてもChromeやFirefoxを前提に考えちゃいますし、Internet Explorerよりも早いだろうという先入観で見ちゃうんですよね。Chromeも最初に出てきた頃は間違いなく最速でしたし、その後、ブラウザベンダ各社速度競争になって、気づいたらこういう結果になっていたということでしょうか。なんだか、IEが可愛そうになってきました、風評被害ですね（笑）。

全体的なトレンドを分析し改善目標を設定する

竹洞：これまで個別に改善ポイントを探ってきましたが、最後に改善目標を決めましょう。こちらのデータをご覧ください。これはトップページに関する全ての計測データを基にした、パフォーマンストレンドのデータです。

＊記事執筆時にシステムより全データを抜き出し打ち合わせ当時のデータのみ切り出しています

縦軸はWebサイトアクセスにかかるトータルタイム（サイトにアクセスした時点から、ブラウザ上でコンテンツ表示が完了するまでの時間）を表しています。時間がかかっている2本は3G回線からのアクセスになります。先ほど表示開始時間は2秒を切ってほしいというお願いをしましたが、こちらで2秒を切れるのであれば、尚良いです。

仲：最終的にパフォーマンストレンドが2秒を切れるように、改善を行うというというかんじになりますかね。

竹洞：そうですね。それがいいと思います。こちらもご覧ください。これは、先ほどのデータをスキャッタープロットという形で表したものです。縦軸はTotal Timeのデータ分布を表していて、どのくらいの位置にデータが集中しているのかを見ることができます。

本来は全ての計測値が下の方に寄っているべきなのですが、かなりばらついて、上の方にも出ているのがわかります。オレンジ色と水色は3G回線のデータです。前半上手くデータが取れていないため、最後のほうで一気にデータが増えていますが、3G回線による計測点が集まっている場所のレンジは、ブロードバンド回線によるそれに比べ、かなり幅が大きいように見えます。回線状況にも影響されるとは思いますが、結論としては、3G回線の品質が悪いということが言えますね。

仲：確かに、くっきりと違いが見えますね。

竹洞：改善目標としては、全体的にばらつきをなくして品質を一定にすることと、3G回線によるアクセス品質をブロードバンド回線にのそれに極力近づけるという、2つも加えてみてはいかがでしょうか？

仲：助言ありがとうございます！その3点を改善目標としては、改善を進めたいと思います。

まとめ

ということで、竹洞さんに助言をもらいつつ改善ポイントや改善目標を議論してきました。最後に、どのような改善を行うのかをまとめてみます。

改善目標

1. Total Time（サイトにアクセスした時点からブラウザ上でコンテンツ表示が完了するまでの時間）は2秒を切る

2. アクセスした際のTotal Timeに関する品質を一定にする（ばらつきをなくして一定にする）

3. 3G回線からのTotal Timeに関するアクセス品質をブロードバンド回線のそれに近づける

改善ポイント

1. WordPressのキャッシュを導入する

2. 実際の表示サイズより大きな画像は適正なサイズに変更する

3. Keep Aliveが全ての環境で効いているか、設定時間は適切かを確認し、コンテンツダウンロード時間を最適化する

4. ソーシャルメディア系サービス（シェアボタンなど）のパフォーマンスを改善する

5. マークアップを改善する（書き方やJSのミニファイ等）

以上です。次回の記事では、実際にどのように改善したのかをご紹介し、パフォーマンスがどう改善したのかをご報告します。

お楽しみに！！！！

HTML5 Experts.jpはなぜこんなにパフォーマンスが悪いのか…全てお見せします！ーWebパフォーマンス改善企画（改善編）

近年、ブラウザやブラウザランタイムは、PCやスマートフォンのみならず、テレビ、コンソールゲーム機などの組み込み機器にも導入されるようになりました。また、Raspberry Piに代表されるシングルボードコンピュータも流行り出し、ロースペックな環境で動作しなければならないWebアプリケーション開発の需要が高まろうとしています。

多くの組み込み機器に搭載されたブラウザは、近年よく使われるAPIやCSSをサポートしています。しかし、そのパフォーマンスはスマートフォンと比べて非常に貧弱です。スマートフォンでは当たり前のパフォーマンスが得られることはありません。

本記事では、組込機器のブラウザ事情を紹介し、その上で動作するWebアプリケーションの開発の課題、私の経験での苦労話、そして、それに立ち向かうためのTipsを紹介します。

組込機器とブラウザ

組込機器でWebアプリケーションを開発すると言われても、あまり馴染みがないかもしれません。しかし、すでに身近にブラウザを搭載した機器や、Webアプリケーションをパッケージ化して、ダウンロード・インストール型のWebランタイム環境を提供している機器があります。

もっとも身近な機器といえばテレビでしょう。近年発売されたテレビは、Hybridcastに対応していますが、このHybridcastのコンテンツは、HTML5対応ブラウザランタイム上で動作しており、そのコンテンツはHTML、CSS、JavaScript を使って作られています。

テレビメーカー各社は、スマートTVをよりスマートフォンなどのデバイスとの親和性を高めるために、Web開発者やスマートフォンアプリ開発者には馴染みがあるOSの採用を発表しています。たとえば、日本では販売されていませんが、SamsungはテレビOSにTizenを採用し、すでに一部の国で販売が開始されています。LGはwebOSを採用しており、すでに日本でも販売されています。また、ソニーはAndroidの採用を、パナソニックはFirefox OSの採用を発表済みです。

これらのOSの多くは、アプリをHTML5ベースで開発することができるようになっています。また、Androidも、WebView（アプリから利用できるWebブラウザのランタイム）を使うことで、Webベースのアプリを動かすことが可能になります。

ゲームコンソールもWebと密接に関わるようになっています。Nintendo Wii Uは、ゲームアプリをWebベースで開発できる環境を用意してます。利用者はそれがWebで作られていると意識することなく、そのゲームで遊ぶことができます。

そのほか、近年は、Raspberry Piに代表されるようなシングルボードコンピュータが流行っていますが、当然、こういったデバイスでも、OSにブラウザをインストールすることで、Webコンテンツを表示することが可能です。

このように、Webコンテンツが使われるステージは広がる一方、PC やスマートフォン向けのWebコンテンツと比べて、パフォーマンスはこれまで以上に意識する必要があります。

組込機器ブラウザの問題

テレビやゲームコンソールなどの機器のブラウザは、実は、Web開発者にはお馴染みのオープンソースのブラウザがベースになっています。すでに販売されている機器のブラウザは、WebKitやOpera Prestoがベースになっているものが多いのですが、今後は、Chromium（Blink）やGecko（Firefox）ベースのブラウザを搭載した機器も出てくることでしょう。組込機器といえども、使える機能や互換性の問題については、スマートフォンの状況に近いと言えます。

しかし、組込機器に特有の事情があります。まず、機器のライフサイクルが長いことです。スマートフォンのライフサイクルはおおむね2年程度でしょう。しかし、テレビやゲームコンソールは、そこまで早く買い換えられることはありません。それ以外の用途の組込機器であれば、さらにライフサイクルが長い場合も考えられるでしょう。

Webコンテンツを開発する上で、この機器のライフサイクルが大きく足を引っ張ることがあります。よほど致命的なバグがあれば、バグ改修のアップデートはあるかもしれませんが、基本的にブラウザが機能面でバージョンアップされることは稀です。やや新しい機器だとしても、何世代も前のブラウザだと考えたほうがよいでしょう。

次に大きな問題としては、貧弱なCPUと少ないメモリーです。スマートフォンでは瞬間的に終わるような処理でも、組込機器では時間がかかります。この場合は、もっと洗練されたアルゴリズムを考案する、または、処理を分割するなどの回避策が必要となります。

また、メモリーリークも注意が必要です。組込機器向けのアプリケーションは、メモリーが少ないため、スマートフォンでは問題にならなかったメモリーリークが顕在化しやすくなります。とりわけ、組込み機器向けアプリケーションでは、長時間利用するものも少なくありません。そういったケースにおいては、少しのメモリーリークですら、致命的です。

パフォーマンスとは

一般的にパフォーマンスといえば、起動を早く、処理を速く、アニメーションを滑らかにする、という文脈で語られることが多いといえるでしょう。しかし、組込機器向けアプリケーションでは、さらに、メモリー消費を少なく、CPU処理を少なく、そして、安定的に長時間動作し続ける、という視点が重要になります。

もちろん、すべてが実現できればそれに越したことはありませんが、残念ながら、貧弱なCPUと少ないメモリーでは、すべてを叶えることは物理的にも不可能です。端的に言ってしまえば、何を諦めて捨てるのか、が重要になります。とりわけ、アプリケーション開発の企画の段階で、こういった事情を考慮しておく必要があります。

とはいえ、このような制約がある中でも、アプリケーション開発において、ちょっとした配慮だけで、パフォーマンスが改善する場合があります。以降では、それらの具体的なテクニックについて、ご紹介しましょう。

ページのロード

Webアプリケーションを早く起動するために考慮しなければならないこととして、関連のファイルのダウンロードのデータ量と、ダウンロードするファイルの数が挙げられます。これらを減らすことで、アプリケーションの起動が早くなるだけでなく、ファイルロード時におけるメモリー消費も抑えられます。

ダウンロードするデータ量を減らす方法としては、HTML、CSS、JavaScriptの最小化が効果的です。この最小化は、よくファイル圧縮と言われることがありますが、Zipなどの圧縮アルゴリズムなどを使うものではありません。そのため、Webサーバーとブラウザとの間のHTTP通信に使われるデータ圧縮とは意味が違います。もちろん、HTTP通信における圧縮は最大限活用するほうがよいことは言うまでもありませんが、ここでは、HTML、CSS、JavaScriptの最小化にフォーカスします。

これらのテキストデータは、一般的に改行やインデントが数多く含まれますが、多くの場合、それはなくても構わないものです。とりわけ、JavaScriptはサイズが大きくなりがちですので、最小化の効果も大きいと言えます。さらに JavaScriptでは、構文を解析しながら変数名などを短い名前に変換するなどして、ファイルサイズを小さくするツールもあります。こういったツールを使うと、最小化の効果が増します。

ただし、こういったツールは JavaScript コードを変更します。そのため、はじめからそれを意識してコードを書かないと、最小化した後に動作しなくなる問題が起こりますので注意が必要です。筆者が個人的に好んでいるのは、Google Closure Compiler です。最小化のレベルを選択することも可能です。最小化のレベルを欲張らなければ、最小化を意識せずに書いたコードも問題なく動作する可能性が高くなります。

ダウンロードするファイルの数を減らす方法としては、CSSやJavaScriptをファイルとして分離せずに、HTMLの中に直接書いてしまうのが手っ取り早いでしょう。たとえば、Googleのトップページでは、ほとんどすべてが一つのHTMLの中に書き込まれています。また、CSSスプライトも効果的です。ただし、こういった対策は、コードの保守性を損ないますので、やり過ぎには注意が必要です。

ペイント領域とGPUメモリー

ブラウザ上に表示されたコンテンツに何かしらの変化があると、ブラウザはそれを再描画します。当然ながら、再描画する領域の面積は狭いほど良いわけですが、それを確認することは重要です。描画が行われるということは、メモリーの読み書きが発生することにほかなりません。しかし、組込機器の場合、そのメモリーの読み書きの速度がPCやスマートフォンと比べて遅い場合があります。ましてや、全画面を再描画する、というのは、相当にマシンに負荷をかけることになるため、組込機器においては、これまで以上に描画領域の面積を意識する必要があります。

Chromeであれば、デベロッパーツールから描画領域をリアルタイムに確認することができます。

実際にWebアプリケーションを開発しているときには、書き換えたコンテンツだけが再描画されると思いがちなのですが、描画領域をリアルタイムに見ていると、状況によっては、より広範囲な領域を再描画していることがよく分かります。いくつか例をご紹介しましょう。

下図は、img 要素を使って組み込まれたスマイリー画像をゆっくりと右に移動するアニメーションの一コマをキャプチャーしたものです。この例では、JavaScriptからsetTimeout()を何度も呼び出して、CSSのleftプロパティの値を徐々に増やしています。

この例では、移動のたびに画像の領域が何度も再描画されていることが分かります。一秒間に数十回も再描画するわけですから、それなりに負荷がかかっているはずです。

この移動アニメーションを、CSS TransisionsとCSS TransformsのtranslateX()を使って作りなおした結果は、下図のとおりです。

この結果は、CSSをうまく使うことで、GPUアクセラレーションが有効になり、移動対象となる画像がレイヤーとして処理されていることを表しています。移動の都度、再描画が発生せず、GPUによってレイヤーを移動することでアニメーションが実現されますので、非常に効率的です。

しかし、GPUアクセラレーションにも注意が必要です。組込機器では、GPUのメモリーがPCやスマートフォンと較べて少ない場合が多いと言えます。何でもかんでもGPUアクセラレーションの対象となるようコンテンツを作ってしまうと、かえって不効率になる場合もあります。必要最小限にとどめることも重要です。

次は、単に文字を書き換えるだけの簡単な例です。その代わり、かなりの頻度で文字が書き換えられます。HTMLとJavaScriptは次のとおりです。

<p>経過時間：<span id="t">0</span>ミリ秒。</p>

var el = document.querySelector("#t");
(function countUp(now) {
    el.textContent = Math.round(now);
    window.requestAnimationFrame(countUp);
})();

ご覧のとおり、この例では、書き換えたいのは数字の部分だけにも関わらず、行全体が再描画の対象になってしまっています。これを改善するために、少しだけHTMLとCSSの力を借ります。

<p>経過時間：<span id="outer"><span id="t">0</span></span>ミリ秒。</p>

#outer {
    display: inline-block;
    width: 100px;
    height: 20px;
    position: relative;
}
#t {
    display: inline-block;
    width: 100px;
    position: absolute;
    text-align: right;
}

このようにCSSを使って書き換えコンテンツの幅と高さを固定することで、ブラウザの再描画の領域を固定することができます。

最後に極端な例をご覧いただきましょう。次の例は、ロゴ画像が1秒おきに点滅するだけのシンプルな例です。

<body>
    <img id="logo" src="imgs/logo.png"> 
    <footer>...</footer>
</body>

var el = document.getElementById("logo");
var hidden = false;
window.setInterval(function() {
    hidden = !hidden;
    el.style.display =
        hidden ? "none" : "block";
}, 1000);

ご覧のとおり、再描画の領域が、ブラウザの表示領域全体に及んでしまっています。これは、画像を表示しているimg要素の表示が切り替わる都度、リフローが発生しているからです。実際には書き換える必要がない領域まで、再描画の対象になってしまい、非効率と言えます。これも、CSSの力を少し借りて解決します。

#logo {
    position: absolute;
}

今回は、CSSのpositionプロパティにabsoluteを指定することで、img要素を、ある意味、浮かせます。これによって、リフローが発生しなくなり、img要素だけが再描画の対象になります。

画像のロード

組込デバイスでは、大きな画像をロードする場合にも注意すべきことがあります。特に、img要素の画像のロードが完了したら、次の処理を行いたい場合です。この場合、恐らく次のようなコードを書くのではないでしょうか。

imgElement.onload = function() {
    // 何か次の処理
};

実は、画像が大きい場合、img要素で loadイベントが発生しても、その画像のレンダリング処理が終わっていないのです。HTML5 仕様ではこのように定義されています。

If the download was successful and the user agent was able to determine the image’s width and height, […] fire a simple event named load at the img element.

ダウンロードが成功し、ユーザーエージェントが画像の幅と高さを判定できたら、[…]img要素でloadという名前のシンプルなイベントを発出します。

つまり、loadイベントの発生はレンダリング完了を表しているわけではありません。組込機器では、loadイベントの発生のタイミングと、実際にレンダリングが完了したタイミングの差が大きく出る場合があります。仮に、loadイベント発生直後に重い処理を開始してしまうと、処理が重複してしまい、予期せぬ結果を招く可能性があります。

残念ながら、画像のレンダリングが完了したことを表すイベントは存在しません。そのため、不格好ですが、タイマーなどを使って、少しだけ連続する処理を遅らせるのが手っ取り早いでしょう。

imgElement.onload = function() {
    window.setTimeout(function() {
        // 何か次の処理
    }, 100);
};

何ミリ秒遅らせるべきかは、対象となるハードウェアのスペックに依存しますので、状況に合わせて微調整が必要となります。

ビデオのロード

HTML5にはvideo要素が導入され、マークアップだけでビデオを埋め込むことができるようになったのはご存知のとおりです。しかし、ビデオを簡単に組み込めるようになったとはいえ、ブラウザに大きな負荷をかけることを意識しなければいけません。とりわけ、ビデオ再生はメモリー消費が大きいため、複数のビデオを組み込む場合には注意が必要です。

video要素にはpreload属性が用意されています。これをうまく使いこなすことが重要となります。

もし、再生開始タイミングのパフォーマンスを気にするなら、preload属性の値をautoにします。

<video preload="auto">

たとえビデオが再生されなくても、バッファリング分のメモリーを消費してしまいます。もし複数のビデオを事前に用意したい場合は注意が必要です。確実にそのビデオが再生されると確信できる状況で使うのが良いでしょう。

もし、メモリー消費の低減を優先したいなら、preload属性の値をnoneにします。

<video preload="none">

この場合は、再生開始のタイミングがかなり遅れることは覚悟しておく必要があります。また、ビデオのサイズ（寸法）や、ビデオの長さの情報は、この時点で取得できません。

もし、どうしても事前にビデオの寸法と長さを知りたいなら、preload属性の値をmetadataにします。

<video preload="metadata">

次に、ビデオ再生の開始の命令を出してから、可能な限り早くビデオが再生できる方法について紹介します。実際にvideo要素を使って再生するビデオファイルは、主にH.264/AAC/MP4 形式が多いのではないでしょうか。MP4形式のコンテナでは、ビデオの長さや寸法などのメタ情報は、ファイルの先頭ではなく最後に格納されます。この場合、ブラウザは、ビデオ再生の直前に、Webサーバーに対して何度もHTTPリクエストを投げることになります。実際にChromeのデベロッパーツールでそれを確認することができます。

ご覧のとおり、再生開始前に3回もWebサーバーにリクエストを送っています。ブラウザはまずファイルの先頭を読み取りにいきます。しかし、そこにメタ情報がないとわかると、今度はファイルの末尾を取得するためにリクエストを送ります。メタ情報が取得できたら、ファイルの先頭に戻ってバッファリング分のビデオデータをダウンロードします。これでやっと、ビデオ再生の準備ができることになります。

MP4形式には、Fast Startという仕組みが用意されています。多くのビデオエンコードソフトには、MP4のオプションとしてFast Startを有効にするかどうかを指定することができます。Fast Startを有効にすると、メタ情報をファイルの末尾ではなく先頭に配置してくれます。こうすることで、ブラウザの読取り回数が1回で済み、再生開始のパフォーマンスが向上します。

メモリー消費

組込機器向けのブラウザ上で動作するアプリケーション開発において、メモリー消費の推移はとても重要です。PCやスマートフォンと比べ、組込機器ではブラウザに割り当てられるメモリーの容量が非常に少ない場合があるからです。PCやスマートフォンではまったく問題にならなかったにも関わらず、組込機器向けに移植すると、メモリー不足でブラウザから警告が表示されたり、場合によっては、ブラウザがクラッシュしてしまいます。また、長時間起動し続けなければならない状況においては、数時間後にメモリー不足に陥ることもあります。このようなシーンでは、少しのメモリーリークでも致命的な結果をもたらします。

組込機器向けWebアプリケーション開発においては、ChromeのデベロッパーツールのTimelineは欠かせません。これはPC上で確認します。組込機器向けのブラウザには、こういったツールが用意されることはないため、実際の状況を把握できるわけではありませんが、少なくとも、PC上でメモリーリークが発生している限り、当然ながら、実機でもメモリーリークが発生しているはずです。

ここで注目すべきポイントは、折れ線グラフで表示されたUsed JS Heap、Documents、Nodes、Listenersの推移です。上図では、Used JS Heap、Nodesの値が、ある時点で下がっていることが分かります。これはJavaScriptエンジンにてガベージコレクションが実行されたことを意味します。これを長時間モニタリングして、ガベージコレクションが実行されるたびに、当初の値に戻ることが理想です。ガベージコレクションが実行されたにも関わらず、これらの値が完全に元に戻らずに、少しずつ増えていく場合は、何かメモリーが開放されない要因があるはずです。

特に、HTML要素を生成と削除する繰り返す場合は、注意が必要です。removeChild()メソッドを使って要素を表すノードをドキュメントから削除しても、上記の折れ線グラフに表示されたNodesの数がガベージコレクション実行後でも減らない場合があります。恐らく、それは、循環参照が残っている可能性があります。また、addEventListener()メソッドやイベントハンドラプロパティを使って、イベントリスナーやイベントハンドラをセットしたにも関わらず、ノードを削除する際に、これらを解除し忘れた場合も該当します。これはChromeデベロッパーツールのListenersの数の推移を見れば把握できます。

ChromeデベロッパーツールのTimelineのUsed JS Heapについて、少し深く見てみましょう。下図は、とあるアプリケーションの Used JS Heapの推移をキャプチャしたものです。

このメモリー消費の推移では、少しずつ上昇しながら、ある時点で降下し、それを頻繁に繰り返しています。つまり、何度もガベージコレクションが発生していることを意味しています。これはよく「ノコギリ型」と言われます。

基本的にガベージコレクションの処理は重いため、その時点でのアニメーションなどを邪魔することがあります。そのため、あまり頻繁にガベージコレクションが発生するのはよくないと言われることがあります。一方、メモリーが少ない環境においては、ブラウザがクラッシュするくらいなら、頻繁にガベージコレクションが発生することで、メモリー消費のピークを抑えるほうがよい場合もあります。どちらがよいかは、状況次第です。

もし頻繁にガベージコレクションを発生させないようにしたいなら、必要な値はすべて変数として事前に用意しておき、それらをできる限り使いまわして、新たな変数を作らないようにします。これはDOMでも同じです。必要なDOMノードを事前に作っておき、それを使いまわします。その代わり、この方法は、実際にそういった変数やDOMノードを使わかなったとしても、メモリーをその分だけ消費してしまいます。

逆にガベージコレクションを早めに発生させたいなら、必要な都度、変数やDOMノードを生成し、不要になった時点で破棄することを繰り返します。パフォーマンスは悪くなりますが、メモリー消費のピークを抑えることができます。

ここでは具体的なテクニックの紹介は伝えきれませんでしたが、メモリーが少ない環境においては、Chromeデベロッパーツールなどのメモリー消費の推移は常に意識しなければいけません。

prototypeの活用

Webアプリケーションを作る際には、コンストラクタ関数を用意し、new演算子を使ってインスタンスを生成することが多いのではないでしょうか。ここでは、ECMAScriptのprototypeを活用するかしないかによって、メモリー消費が違ってくることを紹介します。まずは次のコンストラクタ関数をご覧ください。

var MyWallet = function(init_price) {
    this.price = init_price;
    this.earn = function(price) {
        this.price += price;
        if(this.price > 1000) {
            this.pay(this.price - 1000);
        }
    };
    this.pay = function(price) {
        this.price -= price;
    };
    this.look = function() {
        return this.price;
    };
};

上記のコードでは、コンストラクタ関数の中にメソッドを定義しています。では、次のコードをご覧ください。

var MyWallet = function(init_price) {
    this.price = init_price;
};
MyWallet.prototype.earn = function(price) {
    this.price += price;
    if(this.price > 1000) {
        this.pay(this.price - 1000);
    }
};
MyWallet.prototype.pay = function(price) {
    this.price -= price;
};
MyWallet.prototype.look = function() {
    return this.price;
};

今度は、メソッドをprototypeで定義しています。これら2つのコンストラクタは、prototypeを使っているか使っていないかの違いしかなく、事実上、同じ機能を提供します。

では、これらのコンストラクタからインスタンスを大量に生成して、消費メモリーを見てみましょう。いずれも、次のコードを実行します。

var list = [];
for( var i=0; i<100000; i++ ) {
    var w = new MyWallet(0);
    list.push(w);
}

結果に大きな違いを出すために、現実的ではありませんが、10万個のインスタンスを生成し、それを配列に格納します。この処理が終わった時点でのJS Heap Sizeは次のとおりとなります。

左側はprototypeを使わなかった場合の結果を、右側はprototypeを使った場合の結果を表しています。ご覧のとおり、消費メモリーに倍近い違いがでていることが分かります。

もし、大量にコンストラクタからインスタンスを生成するのであれば、積極的にprototypeを使うのが良いでしょう。

DOMアクセス

最後となりましたが、ここでは、DOMアクセスについて触れます。近年は、jQueryなどのJavaScriptライブラリを使って特定のDOM ノードにアクセスすることが多いのではないでしょうか。しかし、こういったJavaScriptライブラリは便利である反面、使わない機能もテンコ盛りです。しかし、使わなくても、それはブラウザではメモリーに展開されてしまい、無駄にメモリーを消費していることになります。もしJavaScriptライブラリを使うなら、機能を最小限に抑えた軽量なものを使うべき、ということは言うまでもありません。

ここでは、筆者がお気に入りのDOMアクセス用JavaScriptライブラリをご紹介しましょう。その名は、”Vanilla JS“です。

Vanilla JSは、機能を選択して必要な分だけダンロードできるようになっています。

すべての機能にチェックを入れても、gzipでたったの25バイト、展開したら、なんと0バイトです。

このサイトでは、他のJavaScriptライブラリとの速度の比較も掲載されています。

このグラフは、1秒間に、何回、ID指定でノードにアクセスできるかを計測したものです。もちろん、数が多いほどパフォーマンスが良いことを表します。ご覧のとおり、Vanilla JSの速度は、他のJavaScriptライブラリの速度を圧倒しています。

さて、皆さんはもうお気づきですね。Vanilla JSはジョークサイトです。何が言いたいかというと、DOMアクセスを速くしたいなら、JavaScriptライブラリに頼らずに、直接Web標準のDOMで規定されたメソッドを使った方が良いということです。

Web標準のDOMであれば、速度も速い、メモリー消費にも優しい、といいことずくめです。メソッドが長くてコードを書くのが面倒、便利なメソッドがない、というデメリットはありますが、少なくとも、CPUが遅い、メモリーが少ない、といったナイナイ尽くしの組込機器においては、そのデメリットを覆すほどのメリットがあるのです。

これは当然、組込機器にかぎらず、スマートフォンにも当てはまります。あらためて、Web標準のDOMに注目してみてはいかがでしょう。

まとめ

ここではCPUが遅い、メモリーが少ない環境でも、ちょっとした配慮でパフォーマンスの効果が出るトピックを紹介してきました。

近年、さまざまなJavaScriptライブラリ、プログラミング手法、アルゴリズムなどが登場しています。もちろん、そういう新たな知識は必要ですが、それらが登場した背景などは理解しておく必要があるでしょう。例えばそれが、メモリーが潤沢な環境を前提としていたとしたら、少なくとも、組込機器向けのWebアプリケーション開発では、ベストな解とはいえません。

カッコ悪いかもしれませんが、レガシーな手法も、こういった環境では役に立つのです。レガシーな手法は、メモリーが少ない時代に考えられたものも多く、今なお組込デバイスでは有効なのです。

今後、Web技術は、PCやスマートフォンを超えてさまざまなデバイスに浸透してくことでしょう。また、スマートフォンは、日本ではハイエンド機ばかりで、年々、そのスペックは劇的に向上しています。しかし、一方で、新興国ではローエンドで安価なスマートフォンが主流です。海外にサービスを広げる際には、こういったローエンドのスマートフォンを無視することはできません。まるで時代を逆行しているかのように見えますが、今後は、ますますローエンドな環境でのWebアプリケーション開発が求められるようになるでしょう。もし、そういう状況になったときに、この記事が役に立てれば幸いです。

関連資料

HTML5 Experts.jpが誇るエキスパートたちに、「UX」というテーマでインタビューするシリーズ第三弾です。

株式会社Spelldata CEO、そしてエキスパートNo.54の竹洞陽一郎さんに、「UXとWebパフォーマンス」について聞いてきました。UXとWebパフォーマンス、なんとなーく関連ありそうだなーくらいの気持ちでインタビューをお願いしたのですが、それらに密接な関連があるというだけではなく、マーケティング活動にも大きな影響があることなど、経営者ならではの視点からのお話も聞かせていただきました！

パフォーマンスに関する認識が甘いそこのアナタ、意識が変わること請け合いのインタビューです！ どうぞお楽しみください。

　▲左から、インタビュアー白石俊平編集長、HTML5 Experts.jpエキスパート竹洞陽一郎さん

パフォーマンス上の問題を抱えるサイトは99%！？

白石: 今日はよろしくお願いします。竹洞さんは先日、Webサイトの品質改善を行う株式会社Spelldataを立ち上げられ、10月にWebサイトも公開されたわけですが、Webサイトさすがに速いですね。

竹洞: ありがとうございます。装飾は一切抜いて、画像の数やアクセスするドメイン数を必要最低限に留めることで、高速化を心がけてます。

白石: ちなみに今ぼくが言ったみたいに、「御社のWebサイト、さすがに速いですね」とお客様からお褒めの言葉をいただくようなことって、ありますか？

竹洞:いやあ、ないですねえ。全然（笑）。

白石:ないですか？注目に値する速さな気がしますけども。

竹洞:Webサイトがポンポン表示されるなんて、世の中のほとんどの人にとっては当たり前のことなんですよ。

白石:えっ？？そうなんですか？でも…ポンポン表示されないWebサイトなんて、ザラにありますよね？

竹洞:はい。つまり、大多数の人はポンポン出ないWebサイトからは、すぐに離脱しちゃうんです。ってことは、そんなサイトは存在しないも同じ。

白石: な、なるほど。「ポンポン出るのが当たり前」っていうのは、裏を返すと、「ポンポン出ないWebサイトは存在しないも同じ」ってことですか。

竹洞:そうそう。「速くて当たり前でしょ」って感覚。IT業界以外の人に聞いて調査してみると、もっとショックですよ。ちょっとでも表示に時間かかると、容赦なく離脱します。年齢が上がる程に気が短いですね。あと、男性より女性（笑）。

一方、Webサイトをつくる企業やWeb制作会社は、自分のサイトに対して愛があるから、バイアスがかかって無視しちゃうんです。逆に速かったときの印象は記憶に残りやすく、遅いのはたまたまだ、って思っちゃうんですね。実際に自社のサイトが遅いという経験をしても、「PCの調子が悪いんだ」とか「電車の車内だしな」とか、他に原因を求めちゃう。この辺りのお話は、「錯覚の科学」という本が詳しいです。「人は見たいものだけ見えて、聞きたいことだけ聞こえる」そうです。

白石:なるほど。では、パフォーマンスに問題のあるWebサイトって、どれくらいの割合あるんでしょう。

竹洞:基本的に日本のWebサイトの99%はパフォーマンスに問題ある、と言ってもいいんじゃないですか。

白石:え、えええ！そんなにですか！99%！？

竹洞:日本のサイトはデスクトップサイトの場合は、トップページが表示し終えるのに平均で4、5秒かかるのはザラなんです。一方、アメリカはトップページを平均1秒以内を目標にしているというレベル。スマートフォンサイトについては、日本はトップページが表示し終えるまで30秒ぐらいかかるのに対して、アメリカの場合は平均5秒前後です。

白石:意識の差が大きいんですかねえ…。

竹洞:もちろん、日本にも意識高い企業はありますよ。例えば三菱電機さんなんかは、すごくパフォーマンスに気を使っています。正直、コーポレートサイトって、普段からエンドユーザーが見に来るようなものでもないじゃないですか。でも重要な「何か」があった時にはアクセスが殺到する。その時にサイトが見れなかったりすると、最もユーザーが情報を欲しがっている時に、情報を提供できないということになる。そういう時こそ、企業の姿勢や文化が見える。だから、普段からパフォーマンスを意識したサイト作りを行っていると言うんです。でも、なかなかこういう企業は、日本にはないですね。

白石:じゃあ、パフォーマンスに問題を抱えたサイトが実際にはたくさんある中で、企業はいつ、どういうきっかけでその問題に気づくのでしょうか？

竹洞:お客様からクレームがあった、っていうのが一番よくあるパターンですね。でも、日本の場合、お客様からクレームがあった場合は、相当数のお客様が既に見限っていることが多いです。パフォーマンスの遅いサイトは、ユーザ体験を損ねた結果、クレームとして跳ね返ってくるわけです。

UXとWebパフォーマンスの密接な関係

白石:なるほど。「遅い」とか「つながらない」とかって、よく考えるとだいぶネガティブな印象を受けますよね。

竹洞:そうなんです。で、今白石さんがおっしゃった「印象」って、UXを語る上ですごく大事です。 UXは「ISO9241-210:2010」で定義されていて、「製品、システムもしくはサービスの利用もしくは利用によって予測される人の認知と反応」だそうです。ですから「人の心(認知)に変化(反応)を引き起こす」、つまり「人の心がどう動いたか」だと私は考えています。ですから、UXはマーケティングという企業活動と非常に密接な関係があります。

白石:ぼく、恥ずかしながら最近まで知らなかったのですが、UXってマーケティングの文脈で語られることも一般的なんですよね。

竹洞:そうなんです。だから、サイトのUXに問題があるという企業は、マーケティング上の問題を抱えていると言ってもいい。パフォーマンスはその最たるものです。UXに大きな影響を及ぼす項目でありながら、一番問題が看過されやすい。

白石:竹洞さんの会社も、企業のマーケティング活動をトータルでサポートしてらっしゃるんですよね。

竹洞:そうです。Webサイトのパフォーマンス改善は、その活動の一部でしかない。結局のところ企業の提供するWebサイトって、マーケティング用、販売促進用のツールって言ってもいいと思うんです。 なのにWebサイトが遅いと、ユーザがサイトを見ないで帰ってしまう。これでは、興味を持ってくれたお客さんがそこにいるのに、チラシを渡そうとモタモタしているうちにお客さんが去って行ってしまうようなものです。

白石:なるほど…だから、パフォーマンスを含めたUXの改善が、売上にとっても無視できない影響をおよぼすというわけですね。

竹洞:ただ、UXを考える場合には、一旦Webから離れた方がいいんです。

白石: と、いうと？

竹洞:例えばとある名古屋市で複数店舗を展開している美容室ですが、顧客のペルソナを「37歳女性、2児の母」と明確に定めているそうなんです。そのペルソナに姓名まで付けてある。このペルソナに該当しない女性は、来店していただいかなくてよいとまで言い切っているんです。そして、この顧客のことを具体的に考えて、最高のサービスを提供しようとする。

すると、子供連れで来店できるように託児室を用意するということに繋がる。 それだけじゃありません。その美容室は、その「37歳、2児の母」のための美容サービスがワンストップで提供できるように差別化しています。だから、その美容室でネイルケアもできれば、エステも受けられる、大学と一緒になって研究開発した、37歳を中心とした年齢層向けの化粧品も買える…という具合にサービスを充実しています。

待合室も広いサロンになっていて、気軽に2〜3時間一人で過ごしたり、他の来店客と談笑を楽しんだり、店内で販売している子供服をショッピングできるスペースになっている。こうなると、美容室の概念と、そこでの顧客体験そのものが変わっちゃうんですよね。

白石:面白い！

竹洞:結局UXを改善するといっても、事業上のUSP(Unique Selling Proposition)が無いままに闇雲にやってはダメなんです。先の例のように、自社の差別化要因をしっかり考えないと。 「なぜ顧客は、他の企業ではなく、私の会社のサービスを使うべきなのか? 自社の商品を買うべきなのか？」という問いに答えられるようになることが大事。

ここをしっかり考えてあると、自然と販促ツールもしくは販売ツールであるWebサイトで伝えるべき価値が明確になり、その結果、Webの分野におけるUX改善において達成すべき目標も明確になります。

白石:なるほど。伝えるべきものがあってこその、Webサイトですもんね。

竹洞:ただ、Webサイトのパフォーマンスを上げないと、そもそもサイトを見てももらえません。見てもらえないなら、（Webサイトの）UXもへったくれもありません。

先程も申し上げたとおり、エンドユーザの意識としては、Webサイトはポンポン表示されて当たり前。だから遅いという理由で減点されこそすれ、速いからといって加点されるわけじゃないのです。こういう意味ではパフォーマンスの高速化というのは、「売れない理由をつぶす」ということだと言えます。パフォーマンスを上げることが売上アップに直接繋がるとは限りませんが、パフォーマンスが悪いと確実に売上に影響する。

パフォーマンスが上がると売上が上がる？

白石:先ほどから何度かご指摘されている、「パフォーマンスが悪いと、サイトそのものを見てもらえない」というのは、具体的にどれくらい見てもらえないものなんでしょう？「遅い！」といって去ってしまう人の割合は？

竹洞:一つの指標になるのは、Google Analytics（GA）が示す「直帰率」です。

ただGAの直帰率って、そもそもGAのスクリプト読み込みが成功したときしか計測できないんですよね。ユーザがサーバにアクセスして、HTMLが読み込まれて、ブラウザがGAのJavaScriptファイルを読み込んで実行する、この一連の動作が完了する前にユーザが離脱してしまった場合は、計測の数値としては「欠損」になってしまいます。

そこで必要になってくるのが、サーバのアクセスログとの突き合わせです。実際にやってみるとわかりますが、GAのデータと結構食い違いが出てきますよ。サーバログのアクセス数に比べて、GAのアクセス数が3〜4割少ないことが頻繁にあります。

白石:そんなに！それだけの人々が、サイトの遅さにあきれて離脱してしまっている可能性もあるということですか。

竹洞:全部がパフォーマンスのせいではないでしょうが、無視できない割合なのは間違いありません。だから、「サイトを高速化するとアクセス数が伸びる」というのは実は単純な理屈なんです。サイトを速くすれば、直帰率が下がる。

白石:なるほど…遅いサイトを我慢できなくなったのは、モバイルの普及も関係ありそうですね。PCだったら、遅いサイトを読み込んでいる間にほかのことをして時間を潰せますが、スマホだとそうはいきませんものね。

パフォーマンスを改善せよ！そして、UXを改善せよ！

白石:では、Webエンジニアが実際にパフォーマンス改善を行うために、どのようなことを心がければいいでしょうか？

竹洞:品質管理の概念を製造業から学んで、実験計画法に基づいて、自分が関与しているWebサイトのパフォーマンスの計測データ取得して、毎日見ることですね。

私は、成蹊大学名誉教授の中西寛子先生にお願いして、月1回「中西塾」という統計学の勉強会を開催していて、そこの管理人をやっています。中西先生が今月の回で仰っていたのですが、日本はデータの取り方について、世界に比べて教育が非常に遅れているそうです。

データの取り方には、1. 調査 2. 実験 3.観測の3つがあるそうで、欧米では明確に違いを分けているそうです。この中で、因果関係を説明できるのは、「実験」だけなんです。それは、実験者が実験計画に「介入」することが可能だからなんです。

しかし、日本でパフォーマンス計測で有名なのは、FirebugやChrome Developer Toolですよね。あれは、「観測」なんです。因果関係は証明できない。「何か関係がありそうだな」と当たりをつける程度なんです。 では、「実験」と「観測」の根本的な違いは何かというと、実験計画法の「局所管理化、ランダム化、反復」を満たしているかどうかです。

品質管理で、商品を1個だけ抜き出して、それが品質基準を満たしていたら、他の全商品が満たしていると言っていいかと問われれば、ダメに決まっています。でも、今のWebの業界って、それをやってるんですよ。時々、FirebugやChrome Developer Toolを使って計測してみて終わりという具合に。そもそも、インターネットの中は、毎日状況が変わっているという意識がないから、一度、高速化してしまえば、それでOKだと思っている人がほとんどだし。

Webサーバからインターネット回線やモバイル回線、そして端末のWebブラウザという一連の「生産ライン」を、HTML、CSS、JavaScript、画像といった「部品」が流れていって、Webブラウザ上で組み立てられた「完成品」がWebページで、その部品を配送する「インターネット」というベルトコンベアの状況が毎日変わっているんだから、毎日計測しないと、今のパフォーマンスはどうなっているってことを言えないんです。昨日速かったから、今日も速いわけじゃない。

例えば、デバイスからネットワークパフォーマンスを計測する「スピードテスト」みたいなアプリっていろいろあるじゃないですか。あれ、実はあんまり意味ないんですよね。

白石:え、そうなんですか。あれで計測してキャリアや端末を比較している記事とか、よく見かけますけども…。

竹洞:最近はネットワークも複雑系の極みで、パケットの経路も一意には定まりません。全部の通信が、一度、日本のIXを通って…というのは、昔のお話です。どこのサーバにアクセスするかによって、経路は様々です。あのテストで得られる結果って、「たまたまその時、そのアプリのテストサーバにアクセスする経路で、一度だけ」得られたパフォーマンスデータでしかないんです。

統計的に意味のあるデータにするためには、一定数以上のサンプルが必要。例えば、弊社製品の宣伝みたいで恐縮なんですが、うちだと「SpeedData」というサービスがあります。これは、Webサイトのパフォーマンスデータを24時間365日計測して得られたデータに、高度な統計的処理を施した上で、様々な形の可視化を行うことができます。

▲図:実際に計測していたデータをグラフで表示
白石:なるほどー。で、データを見て問題の切り分けを行うわけですね。

竹洞:はい。おおまかに言えば、パフォーマンスの問題は「フロントエンド」「バックエンド」そして中間をつなぐ「ネットワーク」のそれぞれに切り分けられます。それぞれについて、ちょっとしたTIPSをご紹介しますね。

ネットワークでは、実はDNSがボトルネックになることがよくあります。特にモバイルネットワークだと、日本ではNTTドコモ、KDDI、ソフトバンクの三社が抱えるDNSサーバに負荷が集中するという構造がある。しかし、その点を深く考えないWeb制作会社や運営会社は、何かあったときにサーバを切り替えやすいようにとか言って、DNSのTTLを5〜10分に設定します。

そうなると、スマートフォンでの名前解決のキャッシュが5〜10分で切れるわけですから、数百万台のスマートフォンからDNS LookupのDos攻撃を常に受けているようなものです。これに耐えているのは素晴らしいとしか言いようがありませんが、さすがにパフォーマンスが安定しません。

フロントエンドでいうと、ソーシャルボタンや広告などが足を引っ張ることがよくありますね。こうしたパーツはiframeで読み込まれることが多いですが、iframeのレンダリングそのものが遅い上に、iframeで読み込んだHTMLが別ドメインのリソースを参照していることもよくあります。

例えば、Facebookのいいね！ボタンだけでも4ドメイン以上参照していたりもする。TwitterやGoogle+、はてなブックマークボタンなどを入れると、参照するドメイン数が15を超えるのは普通です。しかも、サービス事業者側としてはできるだけ新しいリソースにアクセスして欲しいので、キャッシュの有効期限も短く設定されているのが普通。

こうなってくると、HTTPのリクエスト数も多いし、DNSも足を引っ張りますし、少ないドメイン数で構成されているWebページを前提としているSPDYとかもあんまり効果がありません。

バックエンドに問題があった場合は、一筋縄では行きませんよね。以前私が担当した仕事で、CDNのエッジサーバ上で動的にページを生成する仕組みを導入してフロント部分の高速化を行った所、今までTopページの速度が平均15秒ぐらいだったのが2〜3秒になって、その結果、アクセス数が殺到しちゃって、バックエンドのシステムが持たなくなっちゃった、なんてこともありました。その時は、バックエンドの修正コストが馬鹿にならなかったので、泣く泣く元に戻しましたけども（笑）。

白石:それは残念な事例ですね（笑）

竹洞:また、どうしてもパフォーマンス改善が難しいケースもあります。特に、サービスのコンセプトそのものが、パフォーマンスとのトレードオフになる場合などは悩ましいですね。例えば以前携わったお仕事で、「世界中のほぼ全てのホテルを検索できる」というのがウリのサービスがありました。バックエンドのパフォーマンスを上げたいけれども、元となるホテルの検索結果のデータを提供するアメリカやロンドンのAPIサーバの反応がよくなくて、どうしても限界がありました。

白石:それには、どう対処したんですか？

竹洞:結局パフォーマンスの問題は、UXの問題の一部でしかないというところがポイントです。実際の速度を変えられなくとも、UXは改善できる。その時は、検索の進捗状況をプログレスバーで見える化してユーザのストレスを軽減すると共に、そのサービスのウリである「世界中のほぼ全てのホテルを検索できる、聞いたことのない国でもホテルが予約できる」というメッセージが、ユーザの目に留まりやすいようにしたのです。

そのサービスのウリは、ユーザにとても価値のあるものでした。だからその価値を前面に打ち出した上で、その代わり検索には時間がかかるよ、とわかりやすく表現することで、速度面でのウィークポイントを補えると判断したのです。

白石:なるほど。サービスの価値をユーザに明確に認識してもらうことが、UXの改善につながったというわけですね。

竹洞:はい。それは結局のところ、インタビュー冒頭に申し上げた「UXとは結局、人の心がどう動いたか」であるという考えにも繋がるわけですね。サービスの価値を理解してもらうことが、ユーザの心を動かすのです。

白石:UX、パフォーマンス、マーケティングなど、いろいろなお話が聞けてとても価値のある、楽しい時間でした。どうも、ありがとうございました！

こんにちは、川田です。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)

この記事では、html5j パフォーマンス部 第一回勉強会の模様をライブでお届けします。勉強会に参加したくても参加できなかった方は必見です！

はじめに

html5jでは部活動という形で様々な分野の勉強会が活発に行われています。今回の勉強会を主催するパフォーマンス部もその一つで、昨年暮れに構想が持ち上がり、今回第一回目の勉強会開催となりました。今回の会場はDeNAさんの会議室です。

本日の勉強会はWebパフォーマンスの最前線でどのような事が行われているのか、３名のスペシャリストが余すことなくしゃべります！

開会の挨拶＆5jcupの告知

はじめに、html5j管理人の白石さんから、開会の挨拶と今絶賛開催中の5jcupの告知が行われました。

5jcupにはWebパフォーマンス部でも「Webパフォーマンス賞」という賞を提供しています。この賞は応募されたWeb作品のパフォーマンス計測を実際に行い、パフォーマンスへの配慮を怠っていないWebサイト、Webアプリケーションに対して賞を提供するというものです。イベントの最後に、Webパフォーマンス部部長の竹洞さんから、現在は「副賞なし」となっていますが、現在、副賞を用意する方向で検討しているとの追加コメントが有りました。興味がある方は是非応募してみましょう！　

Session 1.【総論】Webパフォーマンス事始め

html5jパフォーマンス部部長の竹洞さんのセッションです。竹洞さんは、元々は司法書士事務所で働いていて、そこからIT業界にキャリアチェンジし、VMwareやAKAMAI、Verizonを経て現在は、Keynoteという1995年に世界ではじめてパフォーマンス計測（クライアントはヤフー）を行った会社の日本代表をされています。

今回のセッションでは、欧米ではどのようなWebのパフォーマンス管理がなされているのか、国内企業のWebサイトのパフォーマンスの現状を紹介しつつ、Webパフォーマンスの最前線の手法や考え方について説明がありました。

日本のWeb・パフォーマンスサイトの現状

日本の主要なWebサイトのパフォーマンス計測結果が示されました。現在、アメリカの主要なWebサイトのトップページは読み込みが１秒きっており、それと比べれば、日本のサイトは軒並み遅いという現状が有ります。このスライドは日本のデスクトップサイトのパフォーマンス測定結果（正規分布図を箱ひげ図に変換）です。

パフォーマンスを見る際に統計学の観点で重要なことは、複数の測定データを用いて平均値からどの程度離れているか（偏差）を算出し比較することになります。平均値を単純に比較してはいけません。偏差が離れていれば離れているほどばらつきが多い（成績が悪い）といえ、逆に偏差が短いほどサイト品質が良いといえます。この偏差を基に標準偏差を算出し、正規分布図に落とし込み、複数のデータを重ねて見やすいように箱ひげ図に変換したものが、上記画像となります。グラフ左側のひげから右側の箱まで（全体の７５％）に本来は全てのデータが収まることが望ましいのですが、右側にひげとしてそれに収まりきれていない２５％のデータが出ているのがわかります。

※統計学の基礎知識含めて竹洞さんが詳しく説明していますので、もっと知りたい方はYoutube動画をご覧ください。

Webサイト品質管理

Webサイト品質管理の為のパフォーマンス計測は定常的に観測を行うことが大切です。FirefoxやChromeの計測ツールで図るのはもちろんOKですが、一時的なデータではなく、継続して計測しなければ、「遅い」というパフォーマンスの情報は見えてきません。先述した箱ひげ図の右側２５％のデータがどういう状況で発生するのか、どのようなパターンでこのデータが変化するのかを定常的な観測データから把握し、Webサイトのパフォーマンス問題を特定していくことが重要となります。

パフォーマンス計測の手法

大きく分けると以下３種類あります。日本ではServer-Side Monitoringが主流ですが、世界的にホットになっているのはReal User Monitoringとなります。しかしながら、どれか特定の方法で取得するのではなく、３種類全てを活用する必要があります。

• Server-Side Monitoring
• Synthesis Monitoring
• Real User Monitoring（RUM）

Server-Side Monitoringで測定したサーバサイドでのパフォーマンス値、Synthesis Monitoringで測定したISPでのパフォーマンス値、Real User Monitoringで測定したエンドユーザ側でのパフォーマンス値を適切な手法で計算することで、パフォーマンス問題の原因を特定することが可能になります。どれか一つに手法を絞るのではなく、それぞれの手法の特徴を理解し組み合わせることが重要となってきます。

尚、パフォーマンスデータの取り方については、統計学で「実験計画法」という手法が確立しています。実験計画法を利用するにあたっては３つの原則「局所管理化」、「反復」、「無作為化」があります。

また、「観測者効果」の問題も考慮する必要があります。Google Analyticsのコードを入れて安心してはいけません。それが測定結果にどのような影響を与えるのかを把握する必要があります。

竹洞さんのセッションはかなりのボリュームです。詳しく知りたい方はYoutube動画をご覧いただくか、後日公開される発表資料をご覧ください。

Session 2.【各論1】JavaScriptの高速化

続いては株式会社ディー・エヌ・エー坊野さんのセッションです。坊野さんはもともとWebブラウザの開発を行っていたということです。

今回のセッションでは、Webブラウザ開発者の視点から、どのようなJavaScriptを書けばWebブラウザが高速に実行できるのかという観点で様々なテクニックの解説がありました。また、本題に入る前に、DeNAがなぜHTML5にてアプリケーション開発に取り組むのか、具体的にはどのようなことをやっているのかについても簡単に説明がありました。

HTML5アプリケーション開発と最適化

HTML5でのアプリケーション開発は以下の様なことが一般的に言われます。

• コンパイル不要
• 遅い
• メモリ使用量が多い

しかし、最近のブラウザはJavaScriptのコードも機械語にコンパイルして実行するため、Javaなどと比較してなぜ遅いのか？率直な疑問が出てきます。

JavaScriptのコンパイラの動き

まず、JavaScriptのコンパイラの動きについてについて見ていきます。ブラウザにおけるJavaScriptの実行プロセスは以下のとおり。

1. JavaScriptコードを解析
2. 中間言語に変換
3. コードブロック解析
4. 機械語コードに変換
5. 実行
6. 実行結果を基にして最適化コードを作成し、実行

最近のJavaScriptコンパイラは複数回のコンパイルを行います。（上記プロセスだと5と6が該当）なぜか？静的解析だけではJavaScriptコードの最適化は困難なので、一度最適化なしのコードを実行、プロファイラを用いて最適化の可能性などについて判定を行い、その結果を用いて最適化されたコードを生成、再コンパイルしているのです。

JavaScriptコード最適化の観点

ブラウザ開発者からみたJavaScriptコード最適化の観点は、以下の通りとなります。JavaSciptコンパイラが出力する機械語コードを最適なものにするように、JavaScriptのコードを変えてあげればいいのです。また、JavaScriptコンパイラの出力のみにある余計なコードは全て最適化を阻害するものとなるため、極力排除する方がよいでしょう。

次に、具体的にどのようなものが最適化を阻害するオーバーヘッドになるかを見ていきます。

JavaScript APIのオーバーヘッド、例えばDate.now()・・・

HTML5 APIのオーバヘッド、例えばdocument.createElement(‘canvas’)・・・

これらの処理は複数の工程処理を行う必要があり、実行するにあたってはオーバヘッドになってしまいます。

JavaScript関数の最適化

最適化にあたっては、先ほどの観点にならってまず、同一のコードをJavaScript関数とC++関数で実行し速度を比較してみます。今回の例では、前者は183us〜828us（ブラウザにより差分有り）、後者は0.6usという実行結果の差ができました。次に、相違点を列挙し、コードを最適化するというプロセスを実施します。

Web開発者が最適化の美味しいとこどりをするには？

これまで説明してきたようなことをブラウザ開発者はやっていますが、Web開発者の皆さんは美味しいところだけうまく取り入れて下さい。 具体的に、最適化のやり方として「関数のインライン化」や「変数名の短縮」などはツールを活用すればできるため、オススメしません。おすすめの手法は以下の通りです。

• ソーシャルネットワークを活用して有識者に聞く（そのためにはわかりやすいコードを書こう）
• JavaやC++と比較しやすいコードを書く
• API Proxyを使う
• Assertionを用いて型チェックを行う

最後に、大事なことは「コンパイラの気持ちになってコードを書く！」ということ。

Session 3.【各論2】ブラウザにやさしいHTML/CSS

最後は、株式会社レイハウオリ 猪狩さんのセッションです。猪狩さんはWebサイトの開発、高速化、HTMLの構造化などをかなり突き詰めてやっていて、雑誌執筆などもされています。

Webの高速化を行うためにはブラウザの仕組みを理解する必要があります。下のサイトをみればだいたい把握できるそうですが、内容はかなり難しいということ。そのため今回は、高速化に繋がる部分を簡単に紹介するとともに、沢山のデモを交えた体感型のセッションとなりました。

http://www.html5rocks.com/ja/tutorials/internals/howbrowserswork/

ブラウザにモテるHTML/CSSとは

よく言われるWeb高速化の３原則に、「少なくする（数）」、「軽くする（量）」、「近くする（距離）」があります。 具体的には、以下のようになります。

少なくする（数）

• CSSスプライト
• ファイル結合

軽くする（量）

• 縮小化
• テキスト圧縮
• キャッシュ利用

近くする（距離）

• CDNを利用する

これら基本的なテクニックについて、もっと詳しい理解を得て応用力をつけ、有用に活用できるようにする必要があります。

Webページが表示されるまでを知ろう

Webページを表示するまでの大まかな流れは以下のとおりです。

1. HTTPリクエスト① – HTMLのみをリクエストする
2. DNSで名前解決 – ドメインからIPアドレスを調べる
3. TCP接続 – サーバに接続を行う
4. HTTPリクエスト② – HTMLのパース結果に基づき各リソースをリクエストする

※ これが繰り返されます

HTTPリクエスト②では、HTMLの中身をパースして個別のリソースをサイトの上位から順に取得していきます。 ダウンロードは並列で逐次的に行われます。最大並列数はブラウザによって異なります。

１ホストあたりの各ブラウザの同時接続数

IE6〜IE7は同時に２本なので他のブライザに比べかなり時間がかかります。

HTMLが読み込まれた後、表示されるまでのプロセスは以下のとおりです。HTMLのパース結果からDOM treeが作られて、それからRender treeが作られます。最後はそれを画面に描画します。

レンダリングプロセスの中でも、特定のCSSを利用するとLender Layerが生成され、その中でも特にGraphic Layerの動きに注目します。

CSSセレクタマッチングについても取り上げます。

JavaScriptの実行については以下のとおりです。

ブラウザとユーザの気持ちになる

ブラウザの視点に立ってみると、レンダリングプロセスを実行する上で重要となる点は以下の通りです。

• 見た目から表示したい -> 順序の最適化
• 時間がかること大変なことは、できるだけ避けたい -> リクエスト、サイズ、消費メモリの最小化
• いろんなこと一変にしたくない -> 消費メモリの分散化
• 他のブラウザいなくなれ（こっそりｗ）

ユーザーの気持ちはどうでしょうか？

• 早くコンテンツを見たい -> 順序の最適化
• 待ちたくない -> リクエスト、サイズ、消費メモリの最小化
• スムーズであって欲しい -> 消費メモリの分散化

それぞれに共通な「順序の最適化」、「リクエスト、サイズ、消費メモリの最小化」、「消費メモリの分散化」の観点で、それぞれの手法（アプローチ）をライブデモで紹介します。これは、低スペックな端末で見るとより効果がわかりやすいと思います。

デモで分かるブラウザにやさしいHTML/CSS

ライブデモはこちらのサイトにまとまっています。

http://goo.gl/zA4ZvQ

ID : tech , PASS : tech-lab

DNSプリフェッチ

リソース読み込み順序

OKパターン

NGパターン

JSアニメーションとCSSアニメーションの違い

原則として、JSアニメーションよりCSSアニメーションの方が高速なので、CSSアニメーションを利用するようにしましょう。 特にモバイルでは重要になってきます。 また、モバイルでのCSSアニメーションにおいては、アニメーションする要素はposition absoluteにしなければパフォーマンスで問題が出てきます。

※ライブデモの詳細はYoutube動画をご覧ください。

イマドキのHTML/CSS高速化って？

最後に、イマドキのHTML/CSS高速化ってどうなってるの？とよく聞かれるため、昔と変わってきたことに着目して幾つか取り上げます。

CSSスプライトはしない

メンテナンスコストの方がパフォーマンスにおけるメリットを上回るため仕様はおすすめしません。特にモバイルでは、回線の品質がまちまちまので、スプライトして画像をまとめるとそこがボトルネックになることもあるため、例えば、１ページの画像数が１０個いかであれば、分割しておいたほうがメリットが大きいのではないでしょうか。

＊比較デモがあるため興味がある方はYoutube動画をご覧ください。

CSSセレクタのパフォーマンスは気にしない？

最近はブラウザのCSS実行エンジンが早いので気にしません。よく使います。

可能な限りベクターでコーディング

デザインはCSSで極力再現しましょう。CSSでできない場合はSVG、それが難しいようであればPNGでやりましょう。Webフォントも良いアプローチです。

PCのみ、モバイルのみ、レスポンシブの区分けが大事

それぞれのターゲットによって設計方針は変えていくべきです。

パフォーマンス < メンテナンス

メンテナンス性を犠牲にしてパフォーマンスを追求するのはよくありません。

Webパフォーマンス部の今後の予定

Webパフォーマンス部では、第２回から第１１回まで予定がすでに決まっています。

日本企業が世界に進出するためにはWebサイトのパフォーマンスは大事です！ 今回の勉強会に参加できなかった方は、是非次回以降の勉強会に参加してみては如何でしょうか？

勉強会の動画配信はこちら

＊この勉強会は一見の価値有りです。参加できなかった方は是非一度全編通して見てみることをオススメします。

ライブライティングについて

この記事は、イベント開催中にライブライティングしたもので、改訂履歴は以下の通りとなります。

• 2014/5/9 18:40 – 最終版記事に更新完了
• 2014/5/8 22:00 – イベント終了（この時点では記事は書きかけ）
• 2014/5/8 19:00 – 記事公開

パフォーマンス部ロゴデザイン：Kaori Nishino (@kanishionori)