自分のウェブサイトをスマホで開く。速く読み込まれる。画像はきれいに見える。メニューは反応する。すべて完璧だ。満足してブラウザを閉じ、一日を続ける。
問題は、ルーターから2メートルの場所に座っていることだ。スマホは200Mbps、レイテンシ5ミリ秒のネットワークに接続されている。それはユーザーの体験ではない。自分に嘘をついているデザイナーの体験だ。
WiFiが隠す現実
平均的なユーザーは家にいない。バスの中にいる。信号が20枚の壁に跳ね返るショッピングモールにいる。4Gがかろうじて届く地方にいる。200メートルごとに基地局を切り替えながら通りを歩いている。
それは5ミリ秒ではなく100から300ミリ秒のレイテンシを意味する。200Mbpsではなく2から5Mbpsの帯域幅。警告なしに切断と再接続を繰り返す接続。WiFiで0.5秒で読み込まれる400KBの画像が、低信号のモバイルデータでは4秒かかる。
10年以上銀行のインターフェースをデザインしてきた。モバイルバンキングでは平均的なユーザーが1日に11回残高を確認する。1日11回、決して理想的でない条件でアプリが読み込まれなければならない。残高画面が3秒以上かかると、ユーザーは接続が遅いとは思わない。アプリが遅いと思う。アプリが遅ければ、アプリは信頼できない。アプリが信頼できなければ、銀行が信頼できない。
本当のテスト方法
本当のテストは不快だ。家を出る。スマホのWiFiをオフにする。通りでモバイルデータでサイトを開く。読み込み中に歩く。建物に入る。地下に降りる。エレベーターが上がっている間にフォームを完了しようとする。
これをやったことがなければ、驚くだろう。JavaScriptがまだ読み込み中なので最初のタップに反応しないボタン。永遠に感じるほど長い間、灰色の四角形として表示される画像。ダウンロードが完了するまでテキストを見えなくするウェブフォント。2MBのバンドルのパースでプロセッサが忙しいためにカクつくCSSトランジション。
Chrome DevToolsには低速3Gと4Gをシミュレートするスロットリングオプションがある。何もないよりはましだが、同じではない。シミュレーションは帯域幅を均一に減少させる。実際のモバイル接続は変動する。ユーザーがエレベーターに入ると、1秒で10Mbpsから500Kbpsになる。その変動こそが体験を壊す。
今日できること
サイトのすべての画像はPNGやJPGの代わりにWebPまたはAVIF形式を使うべきだ。違いは劇的で、PNGで400KBの画像がWebPでは同じ視覚品質で80KBになる。モバイルデータでの読み込みが1秒か5秒かの違いだ。
ウェブフォントもまた見えない問題だ。Google Fontsから読み込むフォントごとにHTTPリクエストと20KBから100KBのダウンロードが追加される。WiFiでは気づかない。3Gではフォントがダウンロードされる間、ページのテキストが2、3秒間見えなくなる。解決策はfont-display: swapを使い、ウェブフォントが読み込まれる間にシステムフォントでテキストを表示することだ。
JavaScriptはモバイルパフォーマンスの最大の敵だ。ダウンロードサイズではなく、パース時間のためだ。500KBのJavaScriptファイルは最新のiPhoneでパースに200ミリ秒かかる。3年前のミッドレンジスマホでは2秒かかる。ページは存在するが何にも反応しない2秒間。
このブログをまさにこの理由でフレームワークなしで構築した。バニラPHP、HTML、CSS。Reactなし。メガバイトのJavaScriptバンドルなし。処理する不要なものがないため、3Gでも1秒以内にページが読み込まれる。
究極のテスト
家にある最も古いスマホでサイトを開く。2年前に引き出しにしまったやつだ。WiFiをオフにする。モバイルデータを使う。サイト全体を閲覧する。記事を読む。3つのリンクをクリックする。メニューを使ってみる。
そのデバイスとその接続で体験が許容範囲なら、サイトは問題ない。そうでなければ、やるべき仕事がある。その仕事はルーターの横に座って発見できるものではない。
本当のUXはFigmaの中にはない。27インチのモニターの中にもない。200Mbpsのネットワークの中にもない。銀行の列に立ち、信号バー2本と3年前のスマホを持った誰かのポケットの中にある。
そこでテストしていないなら、テストしていない。演技しているだけだ。