HTML5 Experts.jp編集部の企画会議で、ある日、編集部員からこんな発言がー。「HTML5 Experts.jpのサイトってなんとなく遅くないですか？レスポンスとか」そうすると、執筆者の方からもそのような話を聞くことがあるなど、パフォーマンスの話題は盛り上がり、「よし、Webサイトのパフォーマンス改善をやろう！」ということになりました。（かなり中身省略してますが）この連載では、HTML5 Experts.jpのパフォーマンス改善の模様を包み隠さずレポートします！

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パフォーマンス改善企画（改善編）