知覚されるパフォーマンスは、ユーザーから見てウェブサイトがどれくらい速く感じられるかを表します。ユーザーがパフォーマンスをどのように知覚するかは、具体的な統計値と同じくらい、あるいはどんな具体的な統計値よりも重要ですが、それは主観的で簡単に計測できるものではありません。知覚されるパフォーマンスはユーザーの視点であり、計測される値ではありません。
この記事は、ユーザーの知覚と、主観的な要素を計測するために使える具体的なツールに目を通し、知覚されるパフォーマンスの簡潔な紹介を提供します。
| 前提条件: | 基本的なコンピューターリテラシー、基本的なソフトウェアのインストール、クライアントサイドのウェブ技術の基本的な知識 |
|---|---|
| 目的: |
ウェブパフォーマンスに対するユーザーの知覚について基本的な理解を獲得すること |
パフォーマンスはユーザーの知覚に関連します。ウェブサイトの読み込みや描画がどれくらい速く感じられるかは、そのサイトが実際にどのくらい速く読み込まれ描画されるか以上にユーザーの体験に大きなインパクトを与えます。ある操作に（遅延やメインスレッドの無効状態によって）長い時間がかかる場合であっても、待っている間にローディングスピナーや一連の便利なヒント・ティップス（あるいはジョーク、その他適切なものであれば何でも）を表示することでユーザーのエンゲージを維持することが可能です。そのようなアプローチはただ何も表示しないよりずっと良いことです。何も表示しないことはより長い時間を感じさせ、ユーザーはそれが壊れていると思って待つのを諦めるかもしれません。
サイトがどのくらい速く読み込まれるか、ユーザーのインタラクションにどのくらい良く反応すかの知覚はきわめて重要です。それは定量化することが難しい一方、実際のダウンロード時間以上に重要です。サイトにはそれ以上高速化することができない領域があるかもしれません。しかし、他のセクションで議論した統計値がそれ以上改善できない場合でも、サイトをより速く感じさせることは可能です。
ユーザーがどう感じるかを計測するたった一つの統計値 (unicorn metric) はありませんが、統計値は改善（または悪化）を判断するために有用です。関連する計測値には、First Meaningful Paint (FMP)、Largetst contentful paint (LCP)、Time to interactive (TTI)、render start、DOM interactive、Speed Index があります。
First paint はブラウザーから報告され、ページの変更が始まる時間をミリ秒単位で提供します。しかし、この変更はシンプルな背景色の更新や、より気付きづらい小さなものである可能性があります。それは変更の完了を意味しておらず、目に見えるものが何も描画されていない時間を報告することもあります。First Contentful Paint (FCP) はブラウザーが最初に意味のある何か、テキスト、フォアグラウンド・バックグラウンドの画像、またはキャンバスや SVG を描画した時間を報告します。読み込みの経験のまさに始まりを補足します。しかし、それはただ単なるコンテンツであるため、意味のあるコンテンツ、あるいはユーザーが消費できるコンテンツであることを意味していません。First Meaningful Paint (FMP) は実際に意味のあるコンテンツがスクリーンに映し出された時間です。それは、ユーザーが知覚する読み込みの経験としてより適切な統計値ですが、まだ理想的とは言えません。Largest contentful paint (LCP) は、ビューポートの中で最も大きい目に見えるコンテンツの要素が描画される時間を報告する、Largest Contentful Paint API の中で定義された統計値です。
Speed index も知覚されるパフォーマンスの概算として使用されます。それは目に見えるスクリーン上にピクセルが描画される平均時間を計測します。それはジッターも、どのコンテンツがユーザーによってより重要であるかも考慮しません。そのため完全な統計値ではありません。
これらの統計値は最初の読み込みと描画に関わります。ユーザーがサイトとインタラクションを始めた後もサイトが速いと感じさせることは重要です。このために、time to interactive は良い統計値です。それは読み込みプロセスにおける最後の long task が終わり、ユーザーに UI が利用可能になる時間を表します。
UI の欠落や質の悪い反応はどちらも知覚されるパフォーマンスに悪い影響を与えます。タスクに長い時間がかかる場合であっても、それをより速く見せる方法はあります。知覚されるパフォーマンスを改善するいくつかのティップスがあります。
ネットワークを理解すること、ブラウザがどのように動作するか、ユーザーが知覚する時間など、こういったものはユーザーのインタラクションを改善する方法を理解するために役立ちます。しかし、速さの知覚を改善するために、人間の心がどのように働くかと言った全てを理解する必要はありません。
それがどのくらい速い、または遅いと感じられるかは、ユーザーが能動的に待つか、受動的に待つかに大きく影響されます。待つことには能動と受動のフェーズがあります。ユーザが活動しているとき、マウスを動かしたり、考えたり、楽しんだりしているとき、ユーザーは能動的なフェーズにいます。受動的なフェーズは、ユーザーがモノクロのスクリーンを見つめるように受動的に待つ時に起こります。受動と能動の時間が客観的に同じとき、ユーザーは受動的に待つ時間が長かったと感じるでしょう。読み込み、描画、または反応の時間が客観的にそれ以上小さくできない場合、待つことを受動から能動的に待つ時間に変えることでより速く感じさせることができます。
いくつか従うべきヒントとコツがあります。より深く知りたい場合、これらのヒントのいくつかには別途完全な記事があります。
コンテンツ、または少なくともページの一部をコンテンツが読み込み中であることと併せてできるだけ速く表示することは、知覚されるパフォーマンスを改善するためにきわめて重要です。たとえば、ページの描画は CSS と Java Script の読み込みとパース処理にブロックされるため、最初の読み込みに必要とされる CSS と JS の量を最小化することは知覚されるパフォーマンスに大きな影響を持つでしょう。バイトとしてのサイズが同じだったとしても、ページの描画をブロックしないことは読み込みをより速く感じさせます。
知覚されるパフォーマンスを改善するヒントとコツを以下に示します。
知覚されるパフォーマンスを改善するために、最初のページ読み込みを最小化しましょう。すなわち、最初に、実際に表示するものすべて、ただし本当に使うものだけをダウンロードしましょう。それから残りをダウンロードしましょう。すべてのアセットを最後までダウンロードしたときにはアセットの総量は改善されていません。実際にはコードを追加する必要があるかもしれません。しかし、直ちに必要ではないアセットをユーザーに気づかれない形で後からダウンロードすることによって、ユーザーはダウンロードが速くなったように感じます。
アセットを最小化するには最初の読み込みとコンテンツのインタラクティブな機能を分割する必要があります。その結果、目に見えるテキスト、スタイル、画像などの必要なコンテンツが最初に読み込まれます。
最初のページ読み込みで使用されない、あるいは目に見えない画像やスクリプトは読み込みしないようにしましょう。それらは読み込みを遅らせて、ページが使用可能になってから読み込むか、必要になった時に読み込みましょう。最初のページ読み込みの後で、追加のアセットやリソースを読み込むことは知覚されるパフォーマンスを改善します。最初のリクエストで必要なデータを読み込み、必要に応じて徐々に必要な部分やデータを読み込むことは帯域が限られている場合やスペックの低いハードウェアの問題を緩和することにも役立ちます。
さらに、読み込むアセットを最適化する必要があります。画像と動画は最適なフォーマットで、圧縮され、適切なサイズで提供されるべきです。
画像やサードバーティーの広告のような、コンテンツを押し下げたり他の場所にジャンプさせたりするアセットは、ページがまだ読み込み中であるように感じさせ、知覚されるパフォーマンスを悪化させます。ユーザーのインタラクションに起因することなくリフローするコンテンツは特に悪いと言えます。他と比べて読み込みが遅く、かつ他のコンテンツがスクリーンに描画された後に要素が読み込まれるアセットは、レイアウト上にそれらのためのスペースを残すよう事前に計画しましょう。そうすることでコンテンツは、とくにサイトがインタラクション可能になった後で、ジャンプやリサイズしなくなります。
フォントの使用はユーザーの体験を良くすることも悪くすることもあります。適切なフォントを選ぶことは芸術的であり、ユーザーの体験を劇的に良くすることもできます。フォントは、特に使用するフォントをインポートしなければいけないという点でユーザーの体験を悪化させることがあります。インポートするフォントが最適化されていない場合や馬鹿げた Comic Sans が使用されている場合はそうです。スタイリングされていないテキストのチラつきや該当するテキストが見つからないことはどちらもパフォーマンスを悪化させます。
同じサイズとウェイトのフォールバックフォントを用意しておきましょう。そうすることでフォントの読み込みによるページの変化に気付かれにくくなります。
目に見えるインタラクティブな要素は常にインタラクティブで反応できるようにしましょう。入力の要素が目に見える場合、ユーザーは遅延なしにそれらとインタラクションできるべきです。ユーザーは反応に 50 ミリ秒より長い時間がかかる場合、それが遅れていると感じます。コンテンツの再描画が 16.67 ミリ秒（または 60 frames per second）より遅いか、不規則な間隔で再描画されるとページが壊れているように感じます。
CSS で入力用のモーダルを表示したり、可能な場合は JS で先行入力・自動補完を追加するなど、先行入力や漸進的な拡張を使いましょう。
キーの押し上げを待たずにキーの押し下げでコンテンツをリクエストすることにより、知覚されるコンテンツの読み込みを 200 ミリ秒減らすことができます。キーの押し上げに合わせて興味深く、ただし目立ちすぎない 200 ミリ秒のアニメーションを追加することで知覚される読み込みをさらに 200 ミリ秒減らすことができます。実際に 400 ミリ秒の時間を削減したわけではありませんが、ユーザーは、自分がコンテンツを待っていると感じるまでは待っているとは感じないものです。
ダウンロード、描画、待ち時間を能動的なフェーズに変え、受動的に待つ時間を減らすことにより、客観的な測定値が同じであったとしても、ユーザーはコンテンツのダウンロード、描画、反応がより速くなったように感じます。これで速度向上のために何をするべきかわかりました。次はいくつかの統計値を確認し、これらのイベントをどのように測定できるか学びましょう。
{{PreviousMenuNext("Learn/Performance/what_is_web_performance", "Learn/Performance/Measuring_performance", "Learn/Performance")}}