高速化 – HTML5Experts.jp https://html5experts.jp 日本に、もっとエキスパートを。 Sat, 07 Jul 2018 03:14:05 +0000 ja hourly 1 https://wordpress.org/?v=4.7.19 HTML5 Experts.jpはなぜこんなにパフォーマンスが悪いのか…全てお見せします！ーWebパフォーマンス改善企画（改善編） /yoshikawa_t/14608/ Wed, 22 Apr 2015 00:00:46 +0000 /?p=14608 Webパフォーマンス改善企画（改善編）は、実際の改善内容とその結果をお伝えします！パフォーマンス分析を行った解析編は、こちらからご覧ください。本記事はHTML5 Experts.jpがいかにして速くなったのかを包み隠さずお伝えします！

今回の前提条件と改善ポイント

実際の改善を行う前にいくつか前提条件を説明しなければいけません。まず動作環境ですが、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版ソーシャルボタン

PC版ソーシャルボタン

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

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

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

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

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

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

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の遅延（ウォーターフォール図）*青い部分が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の改善（ウォーターフォール図）

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版）

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

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

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

改善目標

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

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

PC版のTotal Time（折れ線グラフ） *Chrome、Firefox、IE

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:青

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):青

モバイル版の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):オレンジ

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

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

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

補足事項

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

]]> HTML5 Experts.jpはなぜこんなにパフォーマンスが悪いのか…全てお見せします！ーWebパフォーマンス改善企画（解析編） /yusuke-naka/13671/ Tue, 21 Apr 2015 00:41:59 +0000 /?p=13671 　HTML5 Experts.jp編集部の企画会議で、ある日、編集部員からこんな発言がー。「HTML5 Experts.jpのサイトってなんとなく遅くないですか？レスポンスとか」そうすると、執筆者の方からもそのような話を聞くことがあるなど、パフォーマンスの話題は盛り上がり、「よし、Webサイトのパフォーマンス改善をやろう！」ということになりました。（かなり中身省略してますが）この連載では、HTML5 Experts.jpのパフォーマンス改善の模様を包み隠さずレポートします！

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

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

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

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

ーあっさりOKが！

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

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

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

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

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

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

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

仲：なるほどー。

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

「UXとWebパフォーマンス、そののっぴきならない関係 – 竹洞陽一郎ロングインタビュー」

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

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

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

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

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

トップページ

sc1

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

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

sc2

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

端末 利用ブラウザ、端末等 回線
PC1 Chrome 31.0.1650.63 LAN（ブロードバンド回線）
PC2 Firefo 14.0.1 LAN（ブロードバンド回線）
PC3 Internet Explorer 9 LAN（ブロードバンド回線）
Android1 Sony SO-04D（Android 4.0.4の標準ブラウザ） 3G回線
iPhone1 iPhone6（Mobile Safari） LAN（ブロードバンド回線）
iPhone2 iPhone6（Mobile Safari） 3G回線
iPhone3 iPhone6S（Mobile Safari） 3G回線

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

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

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

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

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

Chrome_hx1

見ての通り、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回線なので回線状況によりけりですが。

iphone63g1

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

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

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

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

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

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

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

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

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

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

仲：あ……。

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

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

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

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

などがありますね。

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

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

竹洞：さすが！（笑）。

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

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

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

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

sns1

sns2

sns3

sns4

sns5

sns6

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

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

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

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

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

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

sc4

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

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

connection_view_chrome

画像を見ると、黒い帯の途中赤い帯が入っていますよね。黒い帯は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回線を用いてアクセスした結果です。各オブジェクトのタイムラインのグラフにオレンジ色の帯が見えますよね。

sc8

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

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

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

Internet Explorerは優秀なやつ

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

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

sc5

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

仲：2秒…。

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

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

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

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

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

Distribution_Chrome

Chromeの結果

Distribution_FF

FireFoxの結果

Distribution_IE

Internet Explorerの結果

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

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

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

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

sc6

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

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

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

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

sc7

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

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

竹洞：改善目標としては、全体的にばらつきをなくして品質を一定にすることと、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パフォーマンス改善企画（改善編）

]]> イベント生中継！ html5j パフォーマンス部 第一回勉強会の模様をライブでお届けします /yusuke-naka/6410/ Thu, 08 May 2014 09:58:13 +0000 /?p=6410 連載： イベントレポート (16)

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

はじめに

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

photo1

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

開会の挨拶＆5jcupの告知

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

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

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

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

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

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

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

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

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

Webサイト品質管理

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

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

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

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

IMG_8744

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

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

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

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

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

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

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

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

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

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

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

IMG_8779

JavaScriptのコンパイラの動き

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

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

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

JavaScriptコード最適化の観点

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

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

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

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

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

JavaScript関数の最適化

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

IMG_8792

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

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

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

IMG_8794

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

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

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

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

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

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

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

少なくする（数）

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

軽くする（量）

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

近くする（距離）

  • CDNを利用する

IMG_8822

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

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

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

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

※ これが繰り返されます

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

http://goo.gl/zA4ZvQ

ID : tech , PASS : tech-lab

DNSプリフェッチ

IMG_8843 IMG_8849

リソース読み込み順序

OKパターン IMG_8850

NGパターン IMG_8851

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パフォーマンス部では、第２回から第１１回まで予定がすでに決まっています。

IMG_8870

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

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

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

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

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

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

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

]]> モバイル対応Webアプリケーションのキャッシュ戦略 /kyo_ago/2466/ Tue, 24 Sep 2013 00:00:40 +0000 /?p=2466 dtl_thm_017 近年、モバイルブラウザ上でアプリケーションを作るにあたり、JavaScriptでも不安定な回線上で動作する設計が求められるようになってきました。

ここでは、「オフラインファースト」をはじめとする、モバイルなどの回線が不安定な状況を想定したWebアプリケーション設計に関して、キャッシュ方法やよく使われるAPIなどを紹介したいと思います。

「オフラインファースト」とは2012年ごろから提唱されていた、「回線がオフラインになることを前提にアプリケーションの設計を行う思想」のことで、オフライン前提に設計することにより回線状況によらないサービス提供や、効率的な通信をベースにした高速な動作を目指すものです。

それではここからはキャッシュ方法とそれぞれ向いているコンテンツの紹介を行います。

読み込みデータのキャッシュ

ApplicationCacheやlocalStorage、オンメモリキャッシュなどを使って、「サーバから取得したデータをローカルに保持する」ものです。

これは一般に「クライアントサイドキャッシュ」と呼ばれるもので、ネットワークがオンラインの時に読み込んだデータをオフライン時に使用します。

サーバと連動しないコンテンツに向いており、実際のコンテンツ以外でもテンプレートファイルなどの「動的なコンテンツの静的な部分」にも使用されます。

読み込みデータのマージ

これは「読み込みデータのキャッシュ」と大きくは変わりませんが、「読み込みデータのキャッシュ」がオンラインになった際に毎回キャッシュを読みなおすのに比べて、「読み込みデータのマージ」はオンラインになった際にサーバ上で更新があった内容のみダウンロードを行います。

更新があった内容のみダウンロードを行うため、帯域の使用量が少なくなる利点がありますが、サーバとクライアントでデータの更新タイミングを管理する必要があるため、「読み込みキャッシュ」に比べて実装が複雑になります。

「多数の画像ファイルの内、更新があったもののみを再取得する」など、やりとりするデータ量が多いコンテンツに使用されます。

書き込みデータのキャッシュ

書き込み時に回線状況を確認して、オフラインの場合オンラインになるまでデータの送信を遅延させる方法です。

また、オフラインだった時だけではなく、サーバへの通信に失敗した場合、常にデータを再送する形で実装されることもあります。

実装方法としては独自に定義した通信用のコードを使用するほかに、XMLHttpRequestを乗っ取る方法や、使用しているライブラリ（jQuery）などのajaxメソッドをラッピングする方法などがあります。

「投稿」や「保存」などのサーバへの更新処理に使われますが、ゲーム等のタイミングが重要な通信や、「購入」等のサーバ側との連動が、重要な通信では使用されません。

書き込みデータのマージ

これは「読み込みデータのマージ」に書き込みが行われることを想定されたものですが、「書き込みの時系列を保持するか」、「同じデータを同時に編集していた場合にどう整合性を保つか」等によって実装難易度は大きく変わります。
（時系列を保持せず、同時編集時は常に最後の修正が反映されれば良い場合、書き込みデータのキャッシュ実装と大きな差はありません）

これに関してはサーバ側の実装も大きく関わってくるためクライアント側だけで設計するのは難しいですが、もしクライアント側だけで実装したい場合にはGoogle Drive Realtime APIなどの外部サービスの使用も検討してみてください。

オフライン動作

これは単純なデータのキャッシュではなく「ブラウザがオフラインの状態でも動作させる」方法になります。

現状、ブラウザ上でオフライン時にコンテンツを提供するには、基本的にApplicationCacheを使用します。

サーバ側の処理が重要な場合オフライン動作の必要性は高くありませんが、クライアントサイドで完結する要素が多いモバイル向けのツールやアプリケーションなどでは必要性が高くなります。

ここからは実際にキャッシュを実装する際によく使用される機能について紹介します。

Web Storage（localStorage、sessionStorage）

IE8以降の主要なブラウザで使用できる同期型の保存領域です。

多くのブラウザは5MB程度のデータを保持することが可能です。

実装も容易なためよく使われますが、同期型で実装されているためパフォーマンス的な問題も指摘されています。

ローカルストレージに簡単な解決策はない | Mozilla Developer Street (modest)では具体的な問題点や代替案が書かれています。

Cookie

古くから実装されており、サポートブラウザも広いことから、長い間クライアントキャッシュの保存領域としても使用されてきました。

ただ、Cookieに保存した内容はサーバへも送信されてしまうことから、Cookieをキャッシュとして使用する場合、以後の通信すべてで不要なデータをサーバに送ることになるため、大きなデータをキャッシュすることには向いていません。

location.hash

URLの # 以降に文字列を設定し、クライアントキャッシュとして使用する方法です。

サーバサイドへも送信されず、古いブラウザでも動作可能ですが、「ブラウザの履歴に残る」、「URLを共有した際にキャッシュも共有される」、「ブックマーク等にキャッシュも保存される」、「#を使った画面遷移時にキャッシュが破棄される」といった問題があるため、キャッシュとして使用する場合は注意が必要です。

ブラウザキャッシュ

JavaScriptから直接操作するAPIは提供されていませんが、ブラウザキャッシュもクライアントサイドでは重要なキャッシュになります。

具体的には「非表示のimg要素を作成し、img.srcへ画像のURLを設定して先読みさせる」、「見えないiframeで次に読み込むページを先読みする」といった方法で使用されます。

Web SQL Database

ブラウザ内に内蔵されたSQLiteに対して、JavaScriptからAPI経由でSQLを発行することでデータの保存、取得を行うのがWeb SQL Database APIです。

もともとWebKit系のブラウザで実装されており、W3Cでも標準仕様として提案されていましたが、SQLiteへの依存などの問題によりW3C上では廃案になりました。
（ブラウザ上のデータベースに関して – JavaScriptで遊ぶよ – g:javascriptでは廃案になった経緯等がまとめられています）

ただ、モバイル環境では使える環境が多いため、モバイル環境に限ったウェブアプリケーションなどでは使用されることもあります。

Indexed Database（Indexed DB）

標準仕様としての策定が中止されたWeb SQL Databaseに代わり登場したクライアントサイドDBです。

Web SQL DatabaseがあくまでもSQLiteの仕様に準拠しているのに比べて、Indexed DatabaseはJavaScriptからの使用に特化しておりシンプルなObjectやFile objectなどをそのまま格納できます。

Chrome、Firefox、IE10でサポートされるなど、デスクトップブラウザではサポートが広まっていますが、Mobile Safari、Android標準ブラウザでのサポートが行われていないためモバイル環境での使用は広まっていません。

Filesystem API

ブラウザ上にディレクトリなどのFilesystemを操作するAPIを提供するのが、Filesystem APIです。

DOMFileSystem objectやDirectoryEntry objectなどを使って、File objectを階層構造で管理することができます。

このAPIはinput[type=”file”]やD&Dで渡されたファイルを処理する際に使用する「File API」とは違うAPIであることに注意してください。
（Filesystem APIでも単一のファイルを操作する際はFile APIで提供される機能を使用しますが、File APIはあくまでもFilesystem APIから独立した仕様です）

主にChromeで実装されていますが、Chrome以外のブラウザでは実装が進んでいないため、一般的なウェブ環境ではあまり使用されていません。

Firefox に FileSystem API が無いのはなぜか？ | Mozilla Developer Street (modest)ではMozillaのFileSystem APIに対するスタンスが書かれています。

ApplicationCache

ApplicationCacheはcache manifestと呼ばれるキャッシュ対象のURLを記述したテキストファイルをhtmlから参照することで、記述されているURLの内容をローカルキャッシュとして使用する仕様です。

ApplicationCacheには以下の様な機能が含まれます。

  • ブラウザがオフラインでも、事前にキャッシュした内容を表示する
  • ネットワーク通信なしに、cache manifestに書かれたURLのファイルにアクセスする
  • ブラウザがオフライン時のみ、代替内容を表示する
  • JavaScriptからキャッシュの取得、更新イベントを受け取る

現在、ブラウザがオフライン時でもコンテンツを提供する場合ApplicationCacheが主に使用されますが、ApplicationCacheは「設計に失敗したAPI」と呼ばれるほど使い勝手が悪く、さまざまな問題を抱えています。

ApplicationCacheの問題点

ApplicationCacheに関しての紹介で「さまざまな問題を抱えています」と書きましたが、ここではそのうちの主なものについていくつか紹介したいと思います。

読み込み元htmlがキャッシュされる

ApplicationCacheを使用する場合、仕様上ApplicationCacheを使用しているhtmlもキャッシュされてしまうため、動的なコンテンツを出力してもすぐに反映されません。

そのため、ApplicationCacheを使用する場合は基本的に1枚の静的なhtmlを用意し、動的な部分はすべてJavaScriptを使用して構築することになります。

これはWebサイト構築の当初から想定している場合は問題ありませんが、サーバサイドで動的にコンテンツを生成している既存のWebサイトに対して、あとからApplicationCacheを導入する場合には大きな障害になります。

キャッシュのクリアが困難

ブラウザによってはApplicationCacheをクリアするUIを提供していないものもあり、開発中も含めて一度キャッシュされたApplicationCacheをクリアするのが困難な場合があります。

特にiOSの場合、アプリが独自に使用しているUIWebViewのApplicationCacheをクリアするには、アプリを削除して入れなおす以外の方法がありません。
（アプリが独自のUIを提供している場合を除く）

JavaScriptからキャッシュを操作することができない

JavaScriptからApplicationCacheに関しては「キャッシュ状態の確認」、「サーバ上のデータ確認」、「キャッシュの破棄」を行うことができます。

ただし、キャッシュ操作は全キャッシュに対しての操作のみで、個別のファイルに対しての操作は提供されていません。

そのため、「高速化のために出来るだけキャッシュするファイルを多くしたいが、キャッシュするファイルが多いとキャッシュの更新に時間がかかる」という状況になります。

キャッシュの更新は自動的に行われるため基本的にブラウザ側で操作を行う必要はありませんが、逆に「一部のキャッシュのみ更新したい」、「更新順に優先度を付けたい」、「指定したキャッシュが更新されたらJavaScriptからアクセスしたい」と言った内容は実現できません。

それでも使われるApplicationCache

問題点の多いApplicationCacheですが、現状ブラウザがオフライン時にコンテンツを提供するためにはもっとも現実的な方法であるため、問題点があることを前提で使用されている状況です。

もしApplicationCacheを導入する場合、以下の点に注意してください。

最初に導入するか決断する

ApplicationCacheは仕様的にシングルページアプリケーション（1枚のhtmlをベースにJavaScriptでコンテンツを構築する形式）を想定しており、サーバサイドで毎回htmlを組み立てて出力する形式は想定されていません。

サーバサイドで毎回htmlを組み立てて出力するコンテンツの場合でもiframeを経由するなどして活用することは可能です。しかし、iframe内のApplicationCacheに対する状態管理とiframeと、本体間のキャッシュデータをやりとりするコードが必要になるため、実装は複雑になります。

最悪の事態を想定する

ApplicationCacheは使い方によっては完全にサーバから独立して動く事が可能ですが、場合によってはサーバからの変更を一切受け付けなくなってしまう状態に陥る場合があります。

もしサイト上でApplicationCacheを使用する場合、常にネットワーク上からダウンロードするJavaScriptを読み込ませておき、最悪の場合でもJavaScriptからリダイレクトの指示を出せるようにしておくことをおすすめします。

ここまでキャッシュの設計やAPIに関して紹介してきましたが、ユーザから見た場合キャッシュとは「最良の通信やパフォーマンスが提供されない場合の代替手段」であり、本来存在しないことが求められる技術でもあります。

そのため、もしキャッシュを使用する場合、「ユーザの意図に反した動作にならないか」、「最良の状態でないことをユーザが理解できるか」といったことを意識して使用してください。

]]> モバイルブラウザでもサクサクに動作する最適化6つのノウハウ /sou/2413/ Thu, 19 Sep 2013 22:00:56 +0000 /?p=2413 連載： パフォーマンスチューニング (6)

「Webサイト・アプリ高速化テクニック徹底解説」第8回は、モバイルブラウザに向けた最適化について紹介します。 モバイル端末はPCに比べ、CPUやネットワークなどの性能面で劣ることからボトルネックの影響が出やすく、またゲーム開発など突き詰めたチューニングを行う場面では、特殊なノウハウも必要になります。

しかしきちんと最適化を行えば、その効果もその分著しく、比較的低スペックな端末や3G回線であっても、サクサク軽量なサービス提供が可能です。今回の記事では、その勘所をお伝えしたいと思います。

1. ボトルネックを取り除く

html5experts_image_Mobile

まずはやってしまいがちなボトルネックの事例について、挙げていきたいと思います。前述のようにモバイル端末では、その性能からPCよりも顕著に、未最適化箇所が体感に影響を及ぼします。

仕事がらそこそこの数のアプリケーションを見てきましたが、モバイル向けに特化したチューニングができていないのではなく、一般に求められる最適化がなされておらず、それがボトルネックとなって遅いといった事例をよく目にします。

以下では、特にモバイルで問題となる一般的な最適化項目を挙げてみました。個々の詳細な解説については、本連載シリーズの中でより詳細にレポートしていきます。ぜひ、目を通してみてください。

よくありがちな例としては、

  • JavaScriptファイルの取り扱いが最適化されておらず、不要なブロッキングが発生している
  • 適切なレスポンスヘッダが設定されておらず、ブラウザキャッシュが機能していない（もしくはConditional GETのリクエストを飛ばしている）
  • 過剰な数のHTTPリクエストが発生している

といったものがあります。

JavaScriptファイルの取り扱いに注意する

まず影響が大きいのは、JavaScriptファイルの取り扱いです。
script要素はブラウザの他の処理をブロックします。HTML文中にscript要素があると、ブラウザはパース処理など他の仕事を停止し、script要素の評価を優先して実行します。
普段は様々な仕事が並列で走っているのですが、script要素だけは特別扱いで、これはブラウザにとって最も重い仕事のひとつとなります。もちろん、モバイル端末においても顕著に影響を与えます。

script要素の数を減らすか、非同期化しましょう。
defer、async属性を用いることで、上記のブロッキングがなくなります。
非同期化を行わない（行えない）場合はブロッキングの影響を最小限に抑えるよう配慮します。
具体的にはファイル結合を行い、script要素の数を減らし、またbody要素の最下部に置くなど、ブラウザの処理をできるだけ阻害しないようにします

ブラウザキャッシュを有効に機能させる

また、ブラウザキャッシュも重要です。
画像、CSSファイルなどの全アセットがキャッシュに入り、DOMContentLoadedまでにHTTPリクエストが全く発生しない状況では体感速度が大幅に向上します。サクッとファーストビューが表示されるなど、明らかに体感が変わります。 「HTTPリクエストが全く発生しない」ことが重要です。Conditional GET（304）を見かけた場合もきっちり摘み取りましょう。

またサーバ側で画像合成を行うなど、動的なアセットを持つ場合にレスポンスヘッダの付け忘れが起こりやすいようです。 こういった動的なアセットはファーストビューに含まれることも多く、キャッシュの可否で体感速度が変わってきます。 反対に毎回動的に生成するようなものは、もしファーストビューなど重要な箇所に含まれないようなものは遅延ロードに回してやるのもよいでしょう。

例: cache validator（この場合はLast-Modified）が設定されているので正しくキャッシュされる。
キャッシュ可能

例: cache validator に相当するヘッダがなく、キャッシュ不可として扱われる。
キャッシュ不可

HTTPのリクエスト数を削減する

モバイル端末では、PCよりも顕著にHTTPのリクエスト数が性能面に現れます。

理想はファーストビューの表示までに20本未満程度だと思います。
30本以上のリクエスト数を見ると、多いなと感じます。これらにはリクエスト本数を削減するにはスプライトシートを使う、base64 encodeで文字列化して埋め込む、遅延ロードを行う等々、その時々に応じた方法があります。

上記に挙げたボトルネックはどれもGoogle Page Speed等のツールを用いたチェックが可能です。
特殊なノウハウではなく、検出もしやすく改善もしやすいので、ぜひ活用＆対応してみましょう。

2. チューニングの為の知識と準備

大まかな流れを掴む

JavaScriptヘビーなアプリケーションなど通常の最適化だけでは十分に軽量化できないものがあります。
そのような場合は、より突っ込んだ測定と最適化のチューニング作業が必要です。

モバイルでのチューニング作業は、ざっくり例えると買い物に近い感覚です。
まずコンテンツの表示にかけてよい時間、つまり予算を定め、DOMContentLoadedまでの所要時間やJavaScriptの処理時間といったパートごとのコスト計測を行い、予算内にそれらが収まるよう、値切ったり（高速化）、予算外に回したり（遅延評価）といったやりくりを行う、といったノリです。

まず予算を決めます。
予算を決めるには、そのコンテンツやアプリケーションがユーザの目から見て使えるようになったと思えるポイント、待ち時間が終わったと感覚的に思えるポイントを定めます。
これはコンテンツによって様々です。ファーストビューが表示されるまでの場合もあれば、メインアプリケーション部分をユーザが操作可能になるまでの場合、アニメーションが再生を開始するまでの場合など、そのアプリケーションの特性によって決まります。
ここまでに要する時間をもって、予算として定めます。

経験則的には、アセットがブラウザキャッシュに収まった状態で、この感覚的待ち時間が大体800ms以下に収まるとサクサクである、読み込みが軽量であると利用者にも感じてもらえることが多いようです。
大体の予算感の参考にしてください。

さて、次に計測を行うのですが、 計測にあたってはターゲット環境の選定が重要になります。
これは端末、OS、ブラウザによって実効性能や動作特徴が変わるので、結果として高速化のために解決するべき問題が環境にひも付いて変わるためです。
ここでは端末、OS、ブラウザ、回線種別の組み合わせを指して「環境」と呼んでいます。特に端末とブラウザの違いについて、下記で見ていきましょう。

ターゲット端末を定める

モバイルで発生する大半の問題は実はCPUやGPU、もしくはネットワーク性能の向上で簡単に解決できてしまいます。

端末性能は日々向上を見せており、今日の課題は明日の課題となり得ないことがあります。
端末の買い換えサイクルは2年程度とよく言われますが、実際にベンチマークを取ると2年前の端末と現在の端末では5～8倍近い性能差が発生します（さらに極端な例もあります）。
本当に解決すべき問題を見定めるためには、その時の状況に即したターゲット端末の選定が重要になります。

本原稿の執筆時点は、低スペック端末が世間から消えるか消えないかのちょうど過渡期です。
シェアを広げつつある性能の良い端末に向けて体験も豊かに補強しつつ、多少年数の経った低スペック端末でも円滑にサービスが動作するような、両方取りのチューニングが求められている時期だと思います。

今回は低スペック端末向けのチューニングも視野に入れましょう。
低スペック端末の代表格としては、例えばiPhone 4があります。iPhone 4はディスプレイサイズに比べてCPU/GPUの性能が十分と言えない、問題を見つけやすいチューニング向きの端末です。
iPhone 4は発売から年数も経過していますが、iOS7がカバーしていることもあり、まだサポートが必要だと思います。
また比較的新しい端末であっても、例えばGalaxy S3など一昨年に発売されたものでも、CPU/GPUの負荷軽減処理が効果的にはたらく低スペック端末に近い挙動のものがあります。
やはりまだ、高速化には端末性能を考慮した作り込みが必要となる、低スペック端末への配慮が必要な時期だと言えるでしょう。

ブラウザ間の差異について

モバイルブラウザは様々な種類が存在しますが、ここではシェアの高いMobile SafariとAndroid Browser、Chrome for Androidといったブラウザに絞って話を進めます。

Mobile SafariとAndroid BrowserはOSのバージョンによっても挙動に違いがあるため、選定時には気をつけてください。

まずブラウザキャッシュの取り扱いは各ブラウザで異なり、体感や最適化に影響を与えます。

Mobile Safariはオンメモリのキャッシュしか持たず、このためOSの都合で頻繁なキャッシュアウトが発生しやすく、また本体やブラウザの再起動など、プロセスの寿命に伴ってキャッシュが破棄されます。

キャッシュ領域のサイズ自体は100MB前後だと言われていますが、状況によってブレがあり、確定した値を持っていません。
ひとつのサイトを訪れ継続して操作を行う場合はキャッシュ効果を期待できますが、サイトを再訪した時など、時間を置いて訪れた際は、以前のキャッシュはもうないものと思った方がよいでしょう。

Android 2.2や2.3といった2系のAndroid Browserでは、キャッシュ領域が8MBとそもそも小さく、キャッシュ効果自体があまり期待できません。
吉報としてはAndroid2系のシェアが下がりつつあることでしょうか。

Android 4系のAndroid BrowserやChrome for Androidになると、85MBのファイルキャッシュ（Persistent Cache）を持つため、比較的良好な効果が期待できます。
max-ageやETagといったキャッシュ寿命の設定も、この辺りから効果を持ち始めます。

このようにモバイル端末では、キャッシュの取り扱いに諸々問題があります。
より詳しい説明が Guy’s Podのエントリに掲載されているため、興味のある方は目を通されるとよいでしょう。

ほかにもHTTPの同時接続数やJavaScriptの実行パフォーマンスなど細かな点が変わります。
例えばiOS5とiOS6では、局所的なJavaScriptの実行パフォーマンスの違いからアニメーション描画に差異があり、体感的な差異をもたらすといったことが実際にありました。
また、iOS7がリリースされたため、既にiOS5の性能劣化はあまり重要な問題とは言えなくなりました。
このように細かなチューニングや性能測定を行う際はOSバージョン、ブラウザによる性能変化に注意し、その時に適切なものを選ぶよう注意が必要です。

計測に際して

計測を行う場合はざっくり、以下の三つのパートから計測を開始することが多いでしょうか。
尚、計測を行う際はMobile SafariのWeb Inspectorなど、結果に影響を与えるデバッガ類を走らせないよう注意が必要です。

  • DOMContentLoadedまでの所要時間を計る
  • JavaScriptのメインルーチンが呼び出されるまでの所要時間を計る
  • 感覚的待ち時間に該当する関数の実行完了までの所要時間を計る

それぞれの計測区結果を基に、さらに絞り込み問題の検出と改善を進めます。
上記それぞれの所要時間に応じた具体的なチューニング方法を次に解説します。

3. DOMContentLoadedまでを高速化する

意外と重くなりがちなのが、DOMContentLoadedまでの所要時間です。
経験則ですが、divやul、liなどHTMLタグの入れ子を深めると、その部分の処理が重くなる傾向があります。
疑わしい部分はコメントアウトして計測してみる、といった方法で特定を行います。
特に低スペック端末が影響を受けやすく、複雑なHTMLで組まれたメニュー部分を排除すると80ms近くDOMContentLoadedが改善した例もあります。

対応としてはHTMLの記述を見直すか、対象箇所を遅延評価にくくり出すのがよいでしょう。 遅延評価の方法はいくつかあり、XHRで取得する、または<script type=”text/htmlfragment”> のような評価されないscript要素で囲み、後でinnerHTMLに放り込むといった方法があります（文字列をHTMLとして評価する場合は、XSSなどセキュリティ面に十分気をつけてください）。

このようにファーストプライオリティに含まれないもの、例えばファーストビューに無関係な画像やHTMLブロックを遅延評価に追い出す方法は効果的でよく用いられます。

例えば、画像の遅延ロードがあります。
img要素のsrc属性を一旦data-src属性に記述しておき、優先すべき処理が終わってから、JavaScriptでdata-srcを拾って画像を改めて読み込むといったことを行います。
重要でない仕事を後ろにずらすことで端末はその貴重なCPU、ネットワークといったリソースを重要な仕事に集中して利用することができます。
このような遅延評価の手法、考え方はモバイルでは有効でチューニング作業全般においてよく登場します。

4. メインルーチン実行までを高速化する

この場合はJavaScriptの読み込みにボトルネックが残っているか、読み込まれたJavaScriptの初期実行で時間を食っているケースを疑います。

各種JavaScriptライブラリも遅延要因になることがあります。
これを計測するには、大変ベタな方法ですが、script要素内にライブラリのJavaScriptコードを貼り付け、前後でDate.nowを取ると計測できます。

var t = Date.now(); // ここにライブラリなど、評価したいJavaScriptコードを挿入する // (function() { .... }) alert(Date.now() - t);

比較的重めのライブラリの例としてはjQueryがあります。
jQueryはiPhone 4で80ms前後、Galaxy S3で100-200msの時間を初期実行に要します。
これはファイルのダウンロードではなく上記のように純粋にJavaScriptの評価実行に基づいて発生する時間です。
（jQuery1.8.3カスタムビルドで最小時にiPhone4+iOS6.1で54-61ms、フルビルドで80ms前後、2.0.0b1で同じく80ms前後）

仮に手持ちの予算が800msであるとすると、この所要時間は安くない買い物になります。
またアプリケーションが依存するライブラリのコストは、遅延評価やチューニングといった緩和手段が取れず、必ず払うコストになります。

jQueryを例に挙げましたが、この場合はZepto.jsやtt.jsといったより軽量なライブラリに乗り換える手段があります。
もしAndroidとiOSに絞れるコンテンツであれば、ライブラリを使わないのもよいでしょう。
特にゲームやアニメーションを主体としたコンテンツではDOM操作の頻度も減るため、その分のライブラリを削ってゲームエンジンやデータの読み込みに予算を充てることが多くなります。
目的にあったライブラリ選択を行い、予算を節約しましょう。
またよく使うライブラリは、事前にコストを計測しておくとよいでしょう。

他にはCPUやGPUに過剰な負荷がかかっている、といった場合が考えられます。
特にDOMContentLoaded前後の時間帯は計算資源の空きが少なく、過剰なJIT処理の発生や重いアニメーションの再生を重ねると全体が遅延する、描画が一瞬固まるといったことなどがあります。
HTMLの読み込み直後はできるだけCPU、GPUに優しく、負荷の高い処理は遅延させると体感が高速化することがあります。

5. メインルーチン実行自体を高速化する

メインルーチンの実行自体に時間がかかる場合は、フレームワークやコンテンツ固有の特徴にひも付く問題が多くなります。
フレームワークやゲームエンジン個々の話になると、その利用者に限られた内容となってしまうため、ここでは割愛します。
ただ普段自分がよく使うライブラリ、フレームワークがモバイル端末できちんと動作するか実行性能を知り、できれば経験を重ねてチューニングに慣れておくと楽になります。
プロファイラのような各種ツール群もこの辺りから活躍が始まります。

ゲームのように大きなデータの扱いやタイミング制御の伴う画像等のアセットを扱う場合は、並列化、先読み処理といったテクニックもよく使われます。
例えば先読みであれば次のように行います。

function preload() { // 先読みを行う loadImage('path'); }

function playScene() { // 画像を必要とする処理を行う loadImage('path', function() { play(); }); }

function loadImage(src, onSuccess, onError) { var img = new Image(); if (onSuccess) { img.onload = onSuccess; } if (onError) { img.onerror = onError; } img.src = src; return img; }

並列化や先読みを行う場合、また少し複雑なアプリケーションになると非同期制御の問題がついて回ります。
筆者もいままで様々な非同期制御ライブラリを使ってきましたが、現在はuupaa氏作のFlow.js（紹介記事）に落ち着いています。
Flow.js の長所としては、単純シンプルがゆえに動作が軽量であることが挙げられ、特に速度面を求める場合は Flow.js は良い選択肢となるでしょう。
例えば Flow.js を使って複数画像の読み込み制御を行う場合は、次のようになります。

function playScene() { // 複数画像を必要とする処理を行う var paths = ['path-a', 'path-b', 'path-c']; var flow = new Flow(paths.length, function() { // 全ての画像の読み込みが終わると実行される play(); });

// 画像を読み込む
loadImage(paths[0], flow);
loadImage(paths[1], flow);
loadImage(paths[2], flow);

}

function loadImage(src, flow) { var img = new Image(); if (flow) { img.onload = function() { flow.pass(); } } img.src = src; return img; }

また連続した操作部分やサイト全体を、AJAX化するとサクサク感が増します。
ブラウザはページの初期化に際して様々な処理を行っており、新たなページに遷移するだけで相応のCPU負荷がかかります。
AJAX化することでこれを避けて、CPUに空きを作ってやることができ、ゲームなどの重いアニメーション、CPUを酷使するような仕事をファーストビュー領域内で行う場合などに有効です。

6. JavaScript全体の実行速度を向上させる

カリカリにチューニングを施す場面では、JavaScriptコード自体の最適化が求められます。

例えば三項演算子を使い、cond ? A : B と書くより (cond && A) || B と書いた方が高速です（ただしA≒false があり得るときに注意）。
配列に要素追加を行うのであれば、arary.push(value)ではなくarray[array.length] = valueと書いたほうが速い、オブジェクトのプロパティに2回以上アクセスする場合は変数に代入した方が速いなど、このようなTIPSがJavaScriptには数多く存在します。

塵も積もれば何とやらで、CPUリソースが貴重なモバイル端末、特にゲームやミドルウェアなどの突き詰めた性能が必要となる場面はこのようなJavaScriptコードの最適化が効果を発揮します。

これを行うにはJSXのようなJavaScriptの実効性能の最適化を特徴としたツールの導入が効果的です。
上記TIPS程度であれば人手でまかなえますが、 「関数の呼び出し実行自体が遅く、関数をインライン展開した方が高速」などプログラマの手で生産的にまかなえる範囲を超えたノウハウも存在し、生産的にコードを書きたいのであればアプローチを変える必要があります。
またJavaScriptエンジンが変わるとパフォーマンスの現れ方も変わるため、実行速度最適化の観点から考えるとプログラマが直接JavaScriptを書くのでなく、optimizerやaltJSなどを通じて最適化をかけることが望ましいといった結論に達します。

JavaScriptアプリケーション自体も複雑度が増してきており、本格的なアプリケーション開発においてエンジニアが直接JavaScriptを書く時代も終わりつつあるのかも知れません。
そろそろaltJSの時代だな、と思います。

最後に

以上、ざっくりとモバイルでの最適化手法をお伝えしてきました。

上手に最適化を施してやれば、通常のWebページ、Webアプリケーションはもとより、ゲームやアニメーションといった重量級のコンテンツでも、十分にサクサク快適に動作します。

そのために計測を行い、どこにコストを費やしているのか、問題を正確に把握するアプローチが大切です。
「重い」と言われた場合、軽量化を求められた場合はどの端末で、どういった操作を行った時に重いのか、改善を必要としているのか、まず環境の特定から入り測定を行いましょう。

時々「ページの体感が重いから、画像を含むアセット量を500KB以下に定める」といったアプローチも聞きますが、それでは問題の一部しか解決できず、サクサクな体感に至らないケースがままあります。
HTMLの読み込みコスト、JavaScriptによるブロッキング、フレームワークやゲームエンジンに紐付いた実行遅延、、CPUやネットワーク性能に限りがあるモバイル環境下では様々な要因が絡んで「もっさり」が発生します。
サクサク化への効果的なアプローチと問題解決に、本稿がお役に立てることを願っています。

]]> DOM操作の最適化によるJavaScriptチューニング（後編） /yoshikawa_t/1932/ Sun, 08 Sep 2013 22:00:47 +0000 /?p=1932 連載： パフォーマンスチューニング (5)

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

CodeIQとの連動企画！

この記事で学べるJavaScriptチューニングのテクニックを、実際にCodeIQの問題で試すことができます。もう既に自信がある方は腕試しに、もしくは理解度チェックのための復習として是非ご活用ください！こちらから問題にチャレンジ！

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

アニメーション

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

スタイル情報の取得

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

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

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

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

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

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

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

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

要素の取得

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

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

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

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

まとめ

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

]]> DOM操作の最適化によるJavaScriptチューニング（前編） /yoshikawa_t/1888/ Wed, 04 Sep 2013 22:00:03 +0000 /?p=1888 連載： パフォーマンスチューニング (4)

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

CodeIQとの連動企画！

この記事で学べるJavaScriptチューニングのテクニックを、実際にCodeIQの問題で試すことができます。もう既に自信がある方は腕試しに、もしくは理解度チェックのための復習として是非ご活用ください！こちらから問題にチャレンジ！

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

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

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

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

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

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

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

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

なぜDOM操作は遅いのか？

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

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

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

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

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

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

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

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

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

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

innerHTMLとDOM操作メソッド

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

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

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

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

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

次回の内容について

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

]]>