事前作業

サイト監査のパフォーマンス指標を収集する前に、いくつかのチェックを行うことで、簡単に修正できる点や重点的に取り組むべき領域を特定できます。

有効性チェック: アーキテクチャとコード

技術的負債を解消する

可能な限り、パフォーマンスを測定する前に、単純なバグを修正し、不要なアセットとコードを削除します。ただし、問題と修正の前後を記録しておく必要があります。これらの改善は、監査作業の一部として行うことができます。

サイトのアーキテクチャとアセット
未使用の古いページ、コンテンツ、その他のアセットなど、コード リポジトリやサイトから簡単に削除できるものはありますか?孤立したページ、冗長なテンプレート、未使用の画像、未使用のコードとライブラリがないか確認します。

ランタイム エラー
ブラウザ コンソールで報告されたエラーを確認します。エラーは発生していないはずです。

Linting
HTML、CSS、JavaScript のコードにエラーがないか。ワークフローに lint チェックを組み込むことで、コードの品質を維持し、回帰を回避できます。HTMLHint、StyleLint、ESLint をおすすめします。これらは、コードエディタのプラグインとして使用することも、ワークフロー プロセスや Travis などの継続的インテグレーション ツール内でコマンドラインから実行することもできます。

無効なリンクと画像
ビルド時とランタイム時に無効なリンクをテストするためのツールは多数あります。たとえば、Chrome 拡張機能(こちらがおすすめ)や、Broken Link Checker などの Node ツールがあります。

プラグイン
Flash や Silverlight などのプラグインはセキュリティ上のリスクとなる可能性があり、サポートが非推奨となっています。また、モバイルでは動作しません。Lighthouse を使用してプラグインを確認する。

さまざまなデバイスとコンテキストでテストする

実際のユーザーに、実際のデバイス、複数のブラウザ、さまざまな接続環境でサイトをテストしてもらうことに勝るものはありません。

これらのチェックの一部は比較的、主観的なものですが、認識されるパフォーマンスに影響する問題を特定できます。たとえば、無効なリンクは時間の無駄であり、「反応がない」と感じられます。判読しにくいテキストは 読むのに時間がかかります

クロスデバイス テスト
さまざまなビューポートとウィンドウ サイズを試します。少なくとも 1 台のモバイル デバイスと 1 台のデスクトップ デバイスを使用します。可能であれば、画面の小さい低スペックのモバイル デバイスでサイトを試してください。テキストは読みやすいですか?壊れている画像はありますか?ズームはできますか?タップ ターゲットは十分な大きさですか?動作が遅いですか? 反応しない機能はありますか?結果のスクリーンショットまたは動画を撮影します。

クロス プラットフォーム テスト
どのプラットフォームを対象としていますか?ユーザーが現在使用しているブラウザとオペレーティング システム、および将来使用するブラウザとオペレーティング システムでテストする必要があります。

接続性
複数のターゲット ネットワーク タイプでテスト: 接続済み、Wi-Fi、モバイル。ブラウザツールを使用して、さまざまなネットワーク条件をエミュレートできます。

デバイス
ユーザーと同じデバイスでサイトを試してみましょう。次の写真は、2 つの異なるスマートフォンで同じページを表示したものです。

高スペックのスマートフォンと低スペックのスマートフォンで動作するブログ投稿ページ

大画面では、テキストは小さいですが、読み取ることができます。小さい画面では、ブラウザはレイアウトを正しくレンダリングしますが、テキストはズームインしても読めません。ディスプレイがぼやけており、「色合い」が不自然で、白が白に見えないため、コンテンツが読みにくくなっています。

このようなシンプルな発見は、不明瞭なパフォーマンス データよりもはるかに重要です。

UI と UX を試す

ユーザー補助、ユーザビリティ、読みやすさ
サイトのコンテンツと機能をすべてのユーザーが利用できるようにするには、ユーザーの多様性を理解する必要があります。Lighthouse などのツールは、特定のユーザー補助の問題をテストしますが、実際のテストに勝るものはありません。さまざまな状況(屋外の日光の下や電車内など)で、データの読み取り、操作、入力を試します。友人、家族、同僚など、さまざまな人にサイトを試してもらいましょう。Mac の VoiceOver や Windows の NVDA などのスクリーン リーダーを使用して、コンテンツを消費してみてください。

ユーザー補助の実装と確認について詳しくは、Udacity のユーザー補助に関するコースと、ウェブの基礎の記事ユーザー補助の確認方法をご覧ください。

ユーザー補助の監査の記録を保持します。すべてのユーザーにとってメリットとなる簡単な改善を行える可能性があります。

UI と UX の根本的な問題
期待どおりに動作しないインタラクション、小さなウィンドウやビューポートでオーバーフローする要素、小さすぎるタップ ターゲット、読み取れないコンテンツ、ぎこちないスクロールなど。サイトで複数のページを開き、ナビゲーションとすべてのコア機能を試します。記録を保管します。

画像、音声、動画
コンテンツのオーバーフロー、不適切なアスペクト比、不適切な切り抜き、品質の問題をテストします。

主観的な UI テスト
これらはすべてが関連しているわけではありませんが、簡単な変更でリファクタリングが容易になります。

  • サイトを開いたときに、「ここで何ができるか」がすぐにわかりますか?
  • コンテンツを閲覧したり、リンクをたどったりしたくなりますか?
  • 視覚的な階層や経路はありますか?それとも、すべてが同じビジュアル ウェイトになっていますか?
  • レイアウトが乱雑になっていないか?
  • フォントが多すぎないか。
  • 削除できる画像やその他のコンテンツはありますか?
  • コンテンツのデザインは、インターフェースのデザインと同じくらい重要です。サイトのテキストと画像のコンテンツは、モバイルとパソコンのコンテキストに適していますか?削除できるものはありますか?モバイル向けに作成する。