日本の新聞サイトから学ぶパフォーマンスの現在

パフォーマンスはすべてに関わる課題

パフォーマンスは利用者体験を向上するだけでなく、ビジネスにもプラスになります。コンテンツと同様、パフォーマンスはデザイン、エンジニアリング、ビジネスすべてに関わる重要な課題です。それを裏付ける事例をたくさん見つけることができます。

• 表示に 3 秒待たせることで 40% の利用者が離脱してしまう（Gomez）
• 表示速度を 68% 改善したことで、コンバージョン率が 7% 向上した（Ancestory.com）
• 4 秒遅くなったことでページビューが 11% 低下。20秒遅くなると 44% 低下した（Telegraph）
• サイトパフォーマンスを向上することで、ユーザープロフィールのインプレッションとスクロール率が上がった（Instagram）
• ショッピングサイトではパフォーマンスが 2 秒改善することで、離脱率が半分にまで減った（Radware）

SEO にも影響するので、Google はモバイルフレンドリーテストというツールまで用意しています。たくさんの事例やツールがあるにも関わらず、Web サイトは未だに完全に読み込みが終了した後の見た目で良し悪しの判断がつけられることがあります。

新聞サイトの現在

日本はたくさんの方が高速回線を利用していますし、3G 回線を見るのもまれになってきました。こうした恵まれた環境にいるからこそ、「多少重くても大丈夫」と思いがちですが、本当は誰も待ちたくないわけです。今の状況を把握するために、私たちが情報源として利用している新聞サイトのパフォーマンスを調べてみました。調査をしたのは以下の 8 サイトです。

• 読売新聞
• 朝日新聞
• 毎日新聞
• 日経新聞
• 中日新聞
• 東京新聞
• 西日本新聞
• 産経ニュース

今回の調査は Chrome DevTools を利用した簡易的なもの。結果は 3 回ほど計測した数値を平均したものですが、どの環境でもまったく同じ数値が出せるとは限らないので、大まかな目安として見てください。広告表示をオン / オフにしての調査は国内メディアサイトの調査で使った Ghostery を利用しています。

平均ファイルサイズ

• スマートフォン用サイトを別途運用しているだけあり、ファイルサイズの削減ができているところが多い
• 中日新聞のみレスポンシブ Web サイトで、他はスマートフォン向けサイトを用意している（URL も別々）
• 毎日新聞はスマートフォン版のほうがパソコン版より重くなっている
• 全国紙と地方紙でファイルサイズが二分化
• 産経ニュースはアプリに力を入れているためか、Web サイトはスマートフォンに最適化されていない

広告・トラッキングによる影響

• 全国紙だと 5, 6 種類の広告系トラッキングコードが埋め込まれている
• リクエスト数の多さがファイルサイズの大きさに影響しているとは言えない。広告の種類やビデオを埋め込んでいるかによる
• ファイルサイズが半分くらいまで落ちるサイトは、20 以上のトラッキングコードが埋め込まれている。その大半は広告用のコード
• 読売、西日本、産経のように、広告・トラッキングをオフにするとファイルサイズよりリクエスト数が大きく変わるケースがある

平均リクエスト数

• 日経新聞、西日本新聞のスマホサイトではページをスクロールしたら徐々に読み込みをするといった工夫がされている
• ファイルサイズでは全国紙・地方紙が二分化していたがリクエスト数に関しては、大きな違いはない
• スマートフォンサイトでは、リクエスト数を減らすための施策（技術面、コンテンツの量）がされているところが多い

表示までの平均時間

• パソコン、スマートフォンいずれも安定した 4G 回線で観覧したと想定して計測
• ファイルサイズだけでなくリクエスト数も表示速度に影響しているのが分かる
• ファイルサイズ、リクエスト数を小さくしているスマホ版日経新聞の表示スピードは他に比べて高速なのが分かる
• ファイルサイズもリクエスト数も平均的な中日新聞だが、表示速度は良いとは言えない

デザイン寄りのパフォーマンスの考え方

パフォーマンスは技術課題と思われがちです。確かにパフォーマンスの向上には画像の最適化、CSS や JavaScript の最小化などエンジニア寄りの話が多くなりますが、それだけですべて解決するわけではありません。パフォーマンスを上げやすくするためにデザインを工夫することはできますし、表示されるコンテンツの量や演出の仕方を変えることでパフォーマンスが改善しやすくなります。「あとは、エンジニアがうまくやってくれるだろう」という任せ方ではパフォーマンスの向上には限界があるわけです。

Facebook アプリの例。ちょっとしたアニメーションが付いているのも注目。

少し表示速度が遅いサイトやアプリでも、あたかも早く読み込まれているような演出を加えることができます。例えば Skeleton Screen のように、プレースホルダーのようなものを先に見せるのも手段です。プログレスバーやスピナーを使うのも手段ですが、待たされているという心理を和らげるために Skeleton Screen は有効です。

また、利用者に「早く進めている、操作できている」と思わせるための工夫もあります。フィッツの法則によれば、たくさんの選択肢を与えると、利用者が決めたり、行動するための時間も増えてしまいます。選択肢を減らすための編集はもちろんですが、画面を流し読みしやすくするための工夫や、操作のためにあちこち動かなくて済むための設計も必要になります。

まとめ

今回は新聞サイトを例にとってパフォーマンスの現在を見ましたが、他のジャンルでも似たような傾向ですし、さらに酷い場合もあります。パフォーマンスはアクセシビリティと似たような誤解をもたれていることがあります。サイトやアプリを構築した後に専門家が『調整』すれば、対応できると思われがちですが、実際はそれだけではうまくいきません。あらかじめ考慮されているものとそうでないものは大きな違いがあります。

デザイナーの仕事が利用者体験を向上することであれば、パフォーマンスという課題に取り組まなければいけませんし、デザイナーから提案できるパフォーマンス改善があるわけです。読み込みが時間が長くても見た目に拘りたいと思いながら作っていても、いざ自分が利用者になったときは 3 秒待たされるだけでイラッとしている人はいると思います。日本の Web サイトやアプリのパフォーマンス向上の仕事はまだまだたくさんありますし、デザイナーによる積極的な参加が求められています。