ウェブでできることが増えていくにつれて、誰もがパフォーマンスという同じ問題に直面するようになっています。 ウェブサイトで実行できる機能はかつてないほどに多くなりました。 そのため多くのサイトでは、さまざまなネットワーク条件や端末に対して、高いレベルのパフォーマンスを実現することに苦慮しています。
パフォーマンスの問題は多岐にわたります。 条件が非常に良ければ、わずかな遅延が発生するのみで、ユーザーへの影響も小さくて済みます。 しかし最悪の場合には、サイトに完全にアクセスできなくなったり、ユーザー入力に反応しなくなったり、あるいはその両方になることもあります。
ユーザーを引きつけておくために必要とされるパフォーマンス
ユーザーには自分が作成したものを有意義に利用してほしいと思うものです。 それがブログであれば、投稿を読んでもらいたいと思います。 オンラインストアであれば、商品を購入してもらいたいと思います。 ソーシャル ネットワークであれば、ユーザー同士が対話してほしいと思います。
パフォーマンスがオンライン ベンチャーの成功に及ぼす影響は非常に大きくなっています。 パフォーマンスの低いサイトと比較してパフォーマンスの高いサイトがどのようにユーザーの注意を引き、ユーザーを引きつけておくことができるかを示すいくつかの事例があります。
- Pinterest では、ユーザーが体感している待ち時間を 40% 削減した結果、検索エンジンのトラフィックとサインアップ数が 15% 増加しました。
- COOK では平均ページ読み込み時間を 850 ミリ秒短縮したところ、コンバージョン数が 7% 増加し、直帰率が 7% 減少し、セッション当たりの閲覧ページ数が 10% 増加しました。
パフォーマンスが悪かったことが原因で、ビジネス目標に悪い影響が及んだいくつかの事例があります。
- 自社サイトの読み込みにかかる時間が 1 秒増えるごとに BBC はユーザーが 10% ずつ減少することを発見しました。
- ページの読み込みにかかる時間が 3 秒を超えると、DoubleClick by Google は 53% のユーザーがモバイルサイトの訪問をあきらめることを発見しました。
上記の引用元の DoubleClick by Google の研究では、5 秒以内に読み込めるサイトは読み込みにその 4 倍近い 19 秒かかるサイトに比べて、セッション時間が 70％ 長く、直帰率は 35％ 低く、広告視認度が 25% 高いことが判明しました。 自社サイトのパフォーマンスを競合他社と比較する方法の概要については、Speed Scorecard ツールをご覧ください。
コンバージョン数を増やすために必要とされるパフォーマンス
ユーザーを引きつけておくことは、コンバージョン数を増やすために欠かせません。 サイトの読み込み速度が遅いと収益に悪い影響が及び、その逆もまた成り立ちます。 ビジネスの収益性を上げる（または下げる）上でパフォーマンスがどのような役割を果たしているかを示すいくつかの例があります。
- Mobify の場合、ホームページの読み込み速度が 100 ミリ秒速くなるごとに、セッションベースのコンバージョン数が 1.11% 増加し、結果として年平均で約 4,200 万円の増収となりました。 また、注文会計のページの読み込み速度を100 ミリ秒速くしたところ、セッションベースのコンバージョンが 1.55% 増加し、結果として年平均で約 5,830 万円の増収となりました。
- DoubleClick によれば、読み込み時間が 5 秒以内であるサイトの発行者は、読み込みに 19 秒かかるサイトに比べて 2 倍もの広告収入を上げていることが分かっています。
- AutoAnything はページの読み込み時間を半分に短縮したところ、売上が 12-13% 増加する結果となりました。
ウェブを使ったビジネスを経営する場合は、パフォーマンスが非常に重要です。 すばやく操作することができ、ユーザーの入力への応答性に優れているサイトであるなら、それだけでも十分にメリットがあります。 パフォーマンスがどのように収益に影響を与え得るかについては、Impact Calculator ツールでご確認ください。
ユーザー エクスペリエンスのために必要とされるパフォーマンス
ある URL にアクセスしようとするとき、そのために取ることのできる方法はいくつもあります。 接続品質や使用する端末など、いくつもの条件によって、ユーザー エクスペリエンスはまったく異なるものとなり得ます。
サイトの読み込みを開始すると、コンテンツが表示されるまでユーザーが待機する時間があります。 コンテンツが表示されないうちは、ユーザー エクスペリエンスというものはありません。 ユーザー エクスペリエンスがないこの状態は、高速接続ではほんの一瞬です。 しかし、低速接続では、ユーザーは待つことを余儀なくされます。 ページ リソースのダウンロードが少しずつしか行われず非常にゆっくりとしている場合はなおのこと、ユーザーの利用に支障が出ることもあります。
パフォーマンスは心地よいユーザー エクスペリエンスの土台をなすものです。 サイトから送信されるコードが多いと、ブラウザはそのコードをダウンロードするために、ユーザーのデータプランのデータ容量を何メガバイトも消費します。 モバイル端末の CPU パワーやメモリは限られています。 サイズが小さくても最適化されていないコードが送られてくると、こうした端末ではコードの処理が手に負えなくなることもよくあります。 そのため、パフォーマンスが低下して端末は反応しなくなってしまいます。 また人の常として、ユーザーはパフォーマンスの悪いアプリケーションの処理を待ちきれずに、途中であきらめてしまうのです。 自分のサイトのパフォーマンスを評価する方法について詳しく知り、パフォーマンスを向上するために何かしたいと思っておられるなら、How to Think About Speed Tools をご覧ください。
ユーザーのために必要とされるパフォーマンス
パフォーマンスの悪いサイトやアプリケーションは、その利用者に実際に費用をかけさることにもなりかねません。
モバイル ユーザーが世界中のインターネット利用者の大半を占めるようになるにつれて、そのユーザーの多くがモバイル LTE、4G、3G、さらには 2G のネットワークからウェブにアクセスするということを念頭におくことは重要です。 Calibre の作者である Ben Schwarz が 現実世界におけるパフォーマンスの研究で指摘しているように、プリペイド データプランの利用料金が安価になってきたことによって、かつてはインターネットに手が届かなかった地域でインターネットへのアクセスがより手頃に利用できるようになっています。 モバイル端末とインターネット アクセスはもはや贅沢品ではないのです。 これらは、ますます相互に接続されていく世界を行き巡り行動するために必要なありふれたツールです。
総ページサイズは少なくとも 2011 年以来着実に増加しており、引き続きその傾向が見られます。 標準的なページから送信されるデータが増えるにつれて、ユーザーは従量制のデータプランをより頻繁に補充しなければならなくなり、それには費用がかかります。
ユーザーがお金を節約できるようにすることに加えて、高速で軽量なユーザー エクスペリエンスを提供することは、危機的な状況にあるユーザーのためにも非常に重要です。 病院、クリニック、および電話緊急相談センターなどの公的機関には、危機的な状態にある人に対して、その人が必要とする重要かつ具体的な情報を提供するオンライン リソースがあります。 ストレスを伴う状況で重要な情報を効果的に提供するためにデザインは非常に重要ですが、その情報を高速に提供することの重要性を過小評価することはできません。
それをわたしたちがするのです。
どうすればよいか
下に挙げられている事柄を見るとできそうにないと感じてしまうかもしれませんが、サイトのパフォーマンスを改善するためにこれらのことを_すべて_実行する必要はありません。 ここはあくまでスタート地点なので、圧倒されないでください。パフォーマンスを改善するためにあなたがすることは_すべて_ユーザーのためになります。
送信するリソースに気を配る
高性能なアプリケーションを構築する効果的な方法は、ユーザーに_どんな_リソースを送信するかをチェックすることです。 Chrome DevTools の[ネットワーク] パネルには特定のページで使用されるすべてのリソースがみごとに要約されていますが、これまでパフォーマンスのことなど考えてこなかった人にしてみれば、いったいどこから始めればよいのかと戸惑ってしまうかもしれません。 そのためのいくつかの提案があります。
- UI のビルドに Bootstrap や Foundation を使用している場合は、それらが必要か自問してください。 これらの抽象化を使用すると、サイト固有の CSS を描画する前に、ブラウザがダウンロードし解析してページに適用しなければならない CSS のヒープが増えてしまいます。 Flexbox と Grid は、比較的少ないコードで単純なレイアウトと複雑なレイアウトの両方を作成する点で優れています。 CSS はレンダリング ブロック リソースなので、CSS フレームワークのオーバーヘッドはレンダリングをかなり遅くする可能性があります。 できるだけ不要なオーバーヘッドを除去することで、レンダリングを高速化できます。
- JavaScript ライブラリは便利ですが、必ずしも必要ではありません。 例として jQuery を考えてみましょう。
querySelectorやquerySelectorAllなどのメソッドのおかげで、要素選択は大幅に簡略化されました。addEventListenerを使用することで、イベント バインディングも簡単に行えます。classList、setAttribute、およびgetAttributeによって、クラスと要素属性の処理が簡単になりました。 ライブラリを使用する必要がある場合は、サイズの小さい代わりになるものを探しましょう。 例えば、Zepto を jQuery の代わりに、Preact を React の代わりに使用することができ、そうしたほうがそれぞれサイズは小さくなります。 - JavaScript を多用しているサイトも多いため、すべてのウェブサイトをシングル ページ アプリケーション（SPA）にする必要はありません。 JavaScript は、ダウンロードするだけでなく、構文解析し、コンパイルし、実行する必要があるため、サイズに応じて考えると、ウェブで提供するリソースとしては JavaScript が最も費用がかかります。 例えば、フロント エンド アーキテクチャが最適化されているニュースサイトやブログサイトは、従来のマルチページ エクスペリエンスのようによくスムーズに機能します。 HTTP キャッシングが適正に設定されていたり、サービス ワーカーを使用している場合は特にそう言えます。
リソースを送信する方法に気を配る
効率的な配信は、高速なユーザー エクスペリエンスを達成するために不可欠です。
- HTTP/2 に移行します。 HTTP/2 では、同時要求数の制限やヘッダー圧縮がないといった HTTP/1.1 につきもののパフォーマンス上の多くの問題が解消されています。
- リソースのヒントを使用して、先にリソースをダウンロードするようにします。
rel=preloadはそのようなリソースのヒントで、ブラウザがリソースの必要を認識する前に、重要なリソースを事前にフェッチしておくことができます。 この方法は、賢く利用すると、ページ レンダリングや操作可能になるまでの時間の短縮に顕著なプラスの効果があります。rel=preconnectは、もう 1 つのリソースのヒントで、サードパーティ ドメインでホストされているリソースのための新しい接続を開くための待ち時間をマスクすることができます。 - 最近のほとんどのサイトは_たくさん_の JavaScript と CSS を送信します。 HTTP/1 環境では、スタイルやスクリプトをまとめて大きなバンドルにするのが一般的でした。 それは、大量のリクエストをやりとりすることがパフォーマンスの低下につながっていたからです。 しかし、今や HTTP/2 が登場して、複数の同時リクエストを安価にやりとりできるようになると、こうしたことはもはや問題ではなくなりました。 webpack でのコード分割の使用を考慮して、ダウンロードされるスクリプトの量を現在のページやビューで必要とされる分だけに制限します。 CSS を小さなテンプレートまたはコンポーネント固有のファイルに分割して、使用する可能性があるリソースだけを含めます。
送信するデータの量に気を配る
送信するデータの_量_を制限するためのいくつかの提案があります。
- テキスト資産を縮小する。 縮小するとは、テキストベースのリソースに含まれる不要なホワイトスペースやコメントや他のコンテンツを除去することを意味します。 そうすることで、機能性に影響を与えることなく、ユーザーに送信するデータ量を大幅に削減することができます。 JavaScript で uglify 化を使って、変数名やメソッド名を短くしてさらにデータ量を節約します。 SVG はテキストベースの画像フォーマットなので、SVGO を使って最適化することができます。
- リソースを圧縮するようにサーバーを構成します。 圧縮すると、ユーザーに送信するデータ量、_特に_テキスト資産を大幅に削減することができます。 GZIP が一般によく使われていますが、Brotli 圧縮のほうがさらに高機能です。 しかし、圧縮がパフォーマンスを向上させる万能薬では_ない_ことに注意してください。 暗黙的に圧縮されているいくつかのファイル フォーマット（JPEG、PNG、GIF、WOFF など）は、既に圧縮済みなので圧縮しても効果はありません。
- 画像を最適化して、サイトから送信される画像データのサイズをできるだけ小さくします。 ウェブの平均的なページ当たりのペイロードの大部分を画像が占めるため、画像の最適化はパフォーマンスを飛躍的に改善するうってつけの方法です。
- 時間があれば、別の画像フォーマットを使用することを検討します。 WebP はかなり広範にブラウザをサポートしており、JPEG や PNG よりも少ないデータで高い表示品質を維持しています。 JPEG XR はまた別の代替フォーマットで、IE と Edge でサポートされていて、同じくらいデータを節約できます。
- 画像をレスポンシブに配信します。
端末とその画面は多岐にわたるため、表示する画面に最適な画像を送信することにより、パフォーマンスを改善できる非常に大きな余地があります。
一番単純な事例では、
<img>要素にsrcset属性を追加して複数の画像を指定し、その中からブラウザが表示する画像を選択するようにできます。 複雑なケースでは、<picture>を使用して、ブラウザが最適なフォーマット（WebP over JPEG や PNG など）を選択できるようにしたり、画面サイズによってまったく異なる画像処理が行われるようにしたりすることができます。 - アニメーション GIF ではなくビデオを使用します。 アニメーション GIF は_データサイズの大きいファイル_です。 それに比べて同等品質のビデオはデータサイズが_かなり_小さく、ほとんどの場合 80％ 程度小さくなります。 サイトがアニメーション GIF を多用しているのであれば、読み込みパフォーマンスの向上にはこの方法が最も効果があります。
- クライアント ヒントは、現在のネットワーク条件と端末特性に基づいてリソースの配信を調整するのに役立ちます。
DPR、WidthおよびViewport-Widthといったヘッダーは、サーバーサイド コードを使用して端末に最適な画像を配信し、かつ 送信するマークアップを少なくするのに役立ちます。Save-Dataヘッダーは、特に動作が軽いアプリケーションが配信されることを希望するユーザーの要望に応えるのに役立ちます。 NetworkInformationAPI は、ユーザーのネットワーク接続に関する情報を提供します。 この情報を使用して、低速ネットワークを利用するユーザーのアプリケーション体験を調整することができます。
パフォーマンスの向上に関する総合的なガイドについては、読み込み時間とアプリケーションの応答性の両方を向上させることに焦点を当てた RAIL パフォーマンス モデルに関する記事を参照してください。 Google による PRPL パターン ガイドも、最新のシングル ページ アプリケーションのパフォーマンスを向上させるのに役立つ優れた記事です。
パフォーマンスとサイトの高速化についてさらに詳しくは、Google のパフォーマンスに関する資料から、さまざまなトピックのガイド情報をご覧ください。 Google では定期的に新しいガイドの追加と既存のガイドの更新を行っていますので、定期的に情報を確認することをお勧めします。
本資料の推敲と発行のために貴重な意見を寄せてくれた Addy Osmani、Jeff Posnick、Matt Gaunt、Philip Walton、Vinamrata Singal、Daniel An、Pete LePage の各氏に深く感謝いたします。