Missed the action at the 2018 Chrome Dev Summit? Catch up with our playlist on the Google Chrome Developers channel on YouTube. Watch now.

パフォーマンスが重要なのはなぜか

ウェブでできることが増えていくにつれて、誰もがパフォーマンスという同じ問題に直面するようになっています。 ウェブサイトで実行できる機能はかつてないほどに多くなりました。 そのため多くのサイトでは、さまざまなネットワーク条件や端末に対して、高いレベルのパフォーマンスを実現することに苦慮しています。

パフォーマンスの問題は多岐にわたります。 条件が非常に良ければ、わずかな遅延が発生するのみで、ユーザーへの影響も小さくて済みます。 しかし最悪の場合には、サイトに完全にアクセスできなくなったり、ユーザー入力に反応しなくなったり、あるいはその両方になることもあります。

ユーザーを引きつけておくために必要とされるパフォーマンス

ユーザーには自分が作成したものを有意義に利用してほしいと思うものです。 それがブログであれば、投稿を読んでもらいたいと思います。 オンラインストアであれば、商品を購入してもらいたいと思います。 ソーシャル ネットワークであれば、ユーザー同士が対話してほしいと思います。

パフォーマンスがオンライン ベンチャーの成功に及ぼす影響は非常に大きくなっています。 パフォーマンスの低いサイトと比較してパフォーマンスの高いサイトがどのようにユーザーの注意を引き、ユーザーを引きつけておくことができるかを示すいくつかの事例があります。

パフォーマンスが悪かったことが原因で、ビジネス目標に悪い影響が及んだいくつかの事例があります。

上記の引用元の DoubleClick by Google の研究では、5 秒以内に読み込めるサイトは読み込みにその 4 倍近い 19 秒かかるサイトに比べて、セッション時間が 70% 長く、直帰率は 35% 低く、広告視認度が 25% 高いことが判明しました。 自社サイトのパフォーマンスを競合他社と比較する方法の概要については、Speed Scorecard ツールをご覧ください

人気のある 4 つのニュース報道サイトのパフォーマンスを比較した Speed Scorecard ツールのスクリーンショット。
図 1。 Speed Scorecard で、米国の 4G ネットワーク ユーザーから送信される Chrome UX レポートのデータを使用して、競合する 4 つのサイトのパフォーマンスを比較。

コンバージョン数を増やすために必要とされるパフォーマンス

ユーザーを引きつけておくことは、コンバージョン数を増やすために欠かせません。 サイトの読み込み速度が遅いと収益に悪い影響が及び、その逆もまた成り立ちます。 ビジネスの収益性を上げる(または下げる)上でパフォーマンスがどのような役割を果たしているかを示すいくつかの例があります。

ウェブを使ったビジネスを経営する場合は、パフォーマンスが非常に重要です。 すばやく操作することができ、ユーザーの入力への応答性に優れているサイトであるなら、それだけでも十分にメリットがあります。 パフォーマンスがどのように収益に影響を与え得るかについては、Impact Calculator ツールでご確認ください。

Impact Calculator のスクリーンショット。パフォーマンスが改善された場合に、サイトがどれだけ収益を上げることができるかを予測するツール。
図 2。 Impact Calculator を使用することで、サイトのパフォーマンスを向上させることによって得られる収益を見積もることができます。

ユーザー エクスペリエンスのために必要とされるパフォーマンス

ある URL にアクセスしようとするとき、そのために取ることのできる方法はいくつもあります。 接続品質や使用する端末など、いくつもの条件によって、ユーザー エクスペリエンスはまったく異なるものとなり得ます。

あるページ読み込みの 2 枚のフィルムストリップ リールの比較。
 最初のリールは低速接続でページ読み込みを示しており、2 番目のリールは同じページを高速接続で読み込んだ場合を示している。
図 3。 非常に低速な接続(上)と高速接続(下)でページを読み込んだ場合の比較。

サイトの読み込みを開始すると、コンテンツが表示されるまでユーザーが待機する時間があります。 コンテンツが表示されないうちは、ユーザー エクスペリエンスというものはありません。 ユーザー エクスペリエンスがないこの状態は、高速接続ではほんの一瞬です。 しかし、低速接続では、ユーザーは待つことを余儀なくされます。 ページ リソースのダウンロードが少しずつしか行われず非常にゆっくりとしている場合はなおのこと、ユーザーの利用に支障が出ることもあります。

パフォーマンスは心地よいユーザー エクスペリエンスの土台をなすものです。 サイトから送信されるコードが多いと、ブラウザはそのコードをダウンロードするために、ユーザーのデータプランのデータ容量を何メガバイトも消費します。 モバイル端末の CPU パワーやメモリは限られています。 サイズが小さくても最適化されていないコードが送られてくると、こうした端末ではコードの処理が手に負えなくなることもよくあります。 そのため、パフォーマンスが低下して端末は反応しなくなってしまいます。 また人の常として、ユーザーはパフォーマンスの悪いアプリケーションの処理を待ちきれずに、途中であきらめてしまうのです。 自分のサイトのパフォーマンスを評価する方法について詳しく知り、パフォーマンスを向上するために何かしたいと思っておられるなら、How to Think About Speed Tools をご覧ください。

Lighthouse で表示されるページ パフォーマンスの概要
図 4Lighthouse で表示されるページ パフォーマンスの概要

ユーザーのために必要とされるパフォーマンス

パフォーマンスの悪いサイトやアプリケーションは、その利用者に実際に費用をかけさることにもなりかねません。

モバイル ユーザーが世界中のインターネット利用者の大半を占めるようになるにつれて、そのユーザーの多くがモバイル LTE、4G、3G、さらには 2G のネットワークからウェブにアクセスするということを念頭におくことは重要です。 Calibre の作者である Ben Schwarz が 現実世界におけるパフォーマンスの研究で指摘しているように、プリペイド データプランの利用料金が安価になってきたことによって、かつてはインターネットに手が届かなかった地域でインターネットへのアクセスがより手頃に利用できるようになっています。 モバイル端末とインターネット アクセスはもはや贅沢品ではないのです。 これらは、ますます相互に接続されていく世界を行き巡り行動するために必要なありふれたツールです。

総ページサイズは少なくとも 2011 年以来着実に増加しており、引き続きその傾向が見られます。 標準的なページから送信されるデータが増えるにつれて、ユーザーは従量制のデータプランをより頻繁に補充しなければならなくなり、それには費用がかかります。

ユーザーがお金を節約できるようにすることに加えて、高速で軽量なユーザー エクスペリエンスを提供することは、危機的な状況にあるユーザーのためにも非常に重要です。 病院、クリニック、および電話緊急相談センターなどの公的機関には、危機的な状態にある人に対して、その人が必要とする重要かつ具体的な情報を提供するオンライン リソースがあります。 ストレスを伴う状況で重要な情報を効果的に提供するためにデザインは非常に重要ですが、その情報を高速に提供することの重要性を過小評価することはできません。

それをわたしたちがするのです。

どうすればよいか

下に挙げられている事柄を見るとできそうにないと感じてしまうかもしれませんが、サイトのパフォーマンスを改善するためにこれらのことを_すべて_実行する必要はありません。 ここはあくまでスタート地点なので、圧倒されないでください。パフォーマンスを改善するためにあなたがすることは_すべて_ユーザーのためになります。

送信するリソースに気を配る

高性能なアプリケーションを構築する効果的な方法は、ユーザーに_どんな_リソースを送信するかをチェックすることです。 Chrome DevTools の[ネットワーク] パネルには特定のページで使用されるすべてのリソースがみごとに要約されていますが、これまでパフォーマンスのことなど考えてこなかった人にしてみれば、いったいどこから始めればよいのかと戸惑ってしまうかもしれません。 そのためのいくつかの提案があります。

  • UI のビルドに Bootstrap や Foundation を使用している場合は、それらが必要か自問してください。 これらの抽象化を使用すると、サイト固有の CSS を描画する前に、ブラウザがダウンロードし解析してページに適用しなければならない CSS のヒープが増えてしまいます。 FlexboxGrid は、比較的少ないコードで単純なレイアウトと複雑なレイアウトの両方を作成する点で優れています。 CSS はレンダリング ブロック リソースなので、CSS フレームワークのオーバーヘッドはレンダリングをかなり遅くする可能性があります。 できるだけ不要なオーバーヘッドを除去することで、レンダリングを高速化できます。
  • JavaScript ライブラリは便利ですが、必ずしも必要ではありません。 例として jQuery を考えてみましょう。 querySelectorquerySelectorAll などのメソッドのおかげで、要素選択は大幅に簡略化されました。 addEventListener を使用することで、イベント バインディングも簡単に行えます。 classListsetAttribute、および getAttribute によって、クラスと要素属性の処理が簡単になりました。 ライブラリを使用する必要がある場合は、サイズの小さい代わりになるものを探しましょう。 例えば、Zepto を jQuery の代わりに、Preact を React の代わりに使用することができ、そうしたほうがそれぞれサイズは小さくなります。
  • JavaScript を多用しているサイトも多いため、すべてのウェブサイトをシングル ページ アプリケーション(SPA)にする必要はありません。 JavaScript は、ダウンロードするだけでなく、構文解析し、コンパイルし、実行する必要があるため、サイズに応じて考えると、ウェブで提供するリソースとしては JavaScript が最も費用がかかります。 例えば、フロント エンド アーキテクチャが最適化されているニュースサイトやブログサイトは、従来のマルチページ エクスペリエンスのようによくスムーズに機能します。 HTTP キャッシングが適正に設定されていたり、サービス ワーカーを使用している場合は特にそう言えます。

リソースを送信する方法に気を配る

効率的な配信は、高速なユーザー エクスペリエンスを達成するために不可欠です。

送信するデータの量に気を配る

送信するデータの_量_を制限するためのいくつかの提案があります。

パフォーマンスの向上に関する総合的なガイドについては、読み込み時間とアプリケーションの応答性の両方を向上させることに焦点を当てた RAIL パフォーマンス モデルに関する記事を参照してください。 Google による PRPL パターン ガイドも、最新のシングル ページ アプリケーションのパフォーマンスを向上させるのに役立つ優れた記事です。

パフォーマンスとサイトの高速化についてさらに詳しくは、Google のパフォーマンスに関する資料から、さまざまなトピックのガイド情報をご覧ください。 Google では定期的に新しいガイドの追加と既存のガイドの更新を行っていますので、定期的に情報を確認することをお勧めします。

本資料の推敲と発行のために貴重な意見を寄せてくれた Addy OsmaniJeff PosnickMatt GauntPhilip WaltonVinamrata SingalDaniel AnPete LePage の各氏に深く感謝いたします。

フィードバック

Was this page helpful?