さまざまなユーザーやデバイスに対応したサイトを構築する際は、コンテンツだけでなく、レイアウトやグラフィック デザインも考慮してください。
ウェブでの読書方法
米国政府のライティング ガイドには、ウェブ上の文章にユーザーが求めることがまとめられています。
調査によると、ユーザーはウェブページを読まずにスキャンすることがわかっています。平均して、ユーザーがウェブページのコンテンツを読むのは 20 ～ 28% 程度です。画面からの読み取りは、紙からの読み取りよりもはるかに遅くなります。情報に簡単にアクセスでき、理解できなければ、ユーザーはあきらめてサイトを離れてしまいます。
モバイル向けに書く方法
目の前のテーマに集中し、ストーリーを最初に語ります。さまざまなデバイスやビューポートで機能する文章を作成するには、冒頭で要点を伝えるようにしてください。原則として、最初の 4 つの段落で、70 語程度で伝えるのが理想的です。
ユーザーがサイトに何を求めているかを考えます。何かを調べようとしているか。ユーザーが情報を求めてサイトにアクセスしている場合は、ユーザーの目標達成を支援する内容のテキストを掲載するようにしてください。能動態で記述し、アクションと解決策を提示します。
訪問者が求めるものだけを公開し、それ以外のものは公開しないようにします。
英国政府の調査でも、以下のことがわかっています。
つまり、専門知識のある読者に対しても、平易な言葉、短い単語、シンプルな文構造を使用します。特別な理由がない限り、会話調のトーンを維持します。ジャーナリズムの古いルールに、11 歳の賢い子供に話しかけるように書くというものがあります。
新興国のユーザー
簡潔な文章は、モバイル デバイスで読むユーザーにとって特に重要です。また、スクロールが多く、ディスプレイの品質が低く、画面のレスポンスが悪い可能性のある、ビューポートの小さい低価格のスマートフォン向けにコンテンツを作成する際には、簡潔な文章が不可欠です。
今後オンラインにアクセスする 10 億人のユーザーのほとんどは、安価なデバイスを使用するでしょう。長いコンテンツを読み解くためにデータ予算を費やしたくないでしょうし、母国語で読んでいるとは限りません。テキストを短くする: 短い文、最小限の句読点、5 行以下の段落、1 行の見出しを使用します。レスポンシブ テキスト（たとえば、小さなビューポートでは短い見出しを使用するなど）を検討しますが、デメリットに注意してください。
テキストを最小限に抑えることで、コンテンツのローカライズと国際化が容易になり、ソーシャル メディアで引用される可能性が高まります。
まとめ:
- シンプルにする
- 不要な要素を減らす
- 要点を簡潔に伝える
不要なコンテンツを削除する
バイトサイズで言うと、ウェブページは大きく、ますます大きくなっています。
レスポンシブ デザインの技術により、小さいビューポート向けに異なるコンテンツを配信することは可能ですが、まずはテキストや画像などのコンテンツを効率化することから始めるのが賢明です。
ウェブユーザーは、良い本を読んでリラックスするのではなく、現在の疑問の答えを探すために「身を乗り出して」行動することがよくあります。
Jackob Nielsen
ユーザーがサイトにアクセスする目的を把握する
ページ上のすべてのコンポーネントがユーザーの目標達成に役立っているか？
冗長なページ要素を削除する
HTTP Archive によると、HTML ファイルは平均的なウェブページの約 7 万件を占め、リクエスト数は 9 件を超えています。
多くの人気サイトでは、モバイルでも 1 ページあたり数千個の HTML 要素と数千行のコードが使用されています。HTML ファイルのサイズが大きすぎても、ページの読み込みが遅くなるわけではありませんが、HTML ペイロードが大きい場合は、コンテンツの肥大化の兆候である可能性があります。HTML ファイルが大きいほど、要素やテキスト コンテンツが多くなるか、その両方になります。
HTML の複雑さを軽減すると、ページの重さも軽減され、ローカライズと国際化が容易になり、レスポンシブ デザインの計画とデバッグが簡単になります。効率的な HTML の作成については、ハイ パフォーマンス HTML をご覧ください。
ユーザーがアプリの価値を実感するまでに実行するステップが 1 つ増えるごとに、ユーザーの 20% が離脱します
Gabor Cselle（Twitter）
コンテンツについても同様です。ユーザーが目的のコンテンツにできるだけ早くたどり着けるようにしましょう。
モバイル ユーザーからコンテンツを非表示にするだけではいけません。モバイル ユーザーがどの機能を必要としないかを推測することは、必ず誰かにとって不都合が生じるため、コンテンツの同等性を目指してください。リソースがある場合は、優先度の高いページ要素だけでも、さまざまなビューポート サイズに対応した同じコンテンツの代替バージョンを作成します。
コンテンツ管理とワークフローを検討します。レガシー システムがレガシー コンテンツの原因になっていないか確認します。
テキストを簡略化する
ウェブがモバイルに移行するにつれて、書き方を変える必要があります。簡潔にして、不要なものを減らし、要点を伝える。
重複する画像を削除する
画像は美しく、楽しく、有益なものですが、ページのスペースを占有し、ページの重さを増やし、ファイル リクエストの数を増やします。接続が遅くなるとレイテンシが悪化するため、ウェブがモバイル化するにつれて、画像ファイル リクエストの過剰な増加が問題になっています。
画像も電力を消費します。画面の次にバッテリーを消耗するのはラジオです。画像リクエストが増え、無線通信の使用量が増え、バッテリー切れが増えます。画像をレンダリングするだけでも電力を消費します。これは、サイズと数に比例します。スタンフォード大学のレポート「Who Killed My Battery?」をご覧ください。
可能であれば、画像を削除してください。
次の方法を参考にしてください。
- 画像をまったく使用しない、または画像を控えめに使用するデザインを検討してください。テキストのみでも美しくできる。「サイトの訪問者は何を達成しようとしているのか？」と自問自答します。画像は、そのプロセスに役立ちますか？」
- 以前は、見出しなどのテキストをグラフィックとして保存するのが一般的でした。このアプローチは、ビューポートのサイズ変更にうまく対応できず、ページの重さとレイテンシが増加します。テキストをグラフィックとして使用すると、検索エンジンでテキストを検出できなくなり、スクリーン リーダーなどの支援技術でテキストにアクセスできなくなります。可能な限り「実際の」テキストを使用する - Web フォントと CSS を使用すると、美しいタイポグラフィを実現できます。
- グラデーション、シャドウ、角丸、背景テクスチャには、画像ではなく CSS を使用します。これらの機能はすべての最新ブラウザでサポートされています。ただし、CSS は画像よりも優れている可能性がありますが、処理とレンダリングのペナルティが依然として発生する可能性があります。特にモバイルではその傾向が顕著です。
- 背景画像はモバイルではうまく機能しないことがほとんどです。メディアクエリを使用すると、小さなビューポートで背景画像が表示されないようにできます。
- スプラッシュ画面の画像は使用しないでください。
- UI アニメーションには CSS を使用します。
- グリフを理解し、必要に応じてウェブフォントを使用して、画像の代わりに Unicode の記号とアイコンを使用します。
- アイコン フォントを検討してください。アイコン フォントは、無限に拡大縮小できるベクター グラフィックであり、画像セット全体を 1 つのフォントでダウンロードできます。（ただし、これらの懸念事項に注意してください）。
<canvas>要素を使用すると、線、曲線、テキスト、その他の画像から JavaScript で画像を作成できます。- インライン SVG または Data URI 画像は、ページの重さを削減しませんが、リソース リクエストの数を減らすことでレイテンシを短縮できます。インライン SVG は、モバイルとパソコンのブラウザで優れたサポートが提供されており、最適化ツールを使用すると SVG のサイズを大幅に削減できます。同様に、データ URI も適切にサポートされています。どちらも CSS でインライン化できます。
- アニメーション GIF の代わりに
<video>の使用を検討してください。動画要素はモバイルのすべてのブラウザでサポートされています（Opera Mini を除く）。
さまざまなビューポート サイズで適切に動作するようにコンテンツを設計する
「小さな画面向けに作り直すのではなく、プロダクトを創造してください。優れたモバイル プロダクトは、移植されるのではなく、作成されるものです。」
モバイルの設計と開発、Brian Fling
優れたデザイナーは「モバイル向けに最適化」するのではなく、レスポンシブに考えて、さまざまなデバイスで動作するサイトを構築します。テキストやその他のページ コンテンツの構造は、クロスデバイスでの成功に不可欠です。
今後オンラインにアクセスする 10 億人のユーザーの多くは、ビューポートの小さい低価格のデバイスを使用しています。解像度の低い 3.5 インチまたは 4 インチの画面で読むのは大変です。
2 人が一緒に写っている写真はこちらです。
大きい画面では、テキストは小さいですが読めます。
小さい画面では、ブラウザでレイアウトは正しくレンダリングされますが、ズームインしてもテキストが読めません。ディスプレイがぼやけていて、白が白に見えない「色合い」が発生し、コンテンツが読みにくくなっています。
モバイル向けコンテンツをデザインする
さまざまなビューポートに対応したサイトを構築する際は、コンテンツだけでなく、レイアウトやグラフィック デザインも考慮し、プレースホルダ コンテンツではなく、実際のテキストと画像を使用して設計します。
「コンテンツはデザインに優先する。コンテンツのないデザインはデザインではなく、装飾です。」
Jeffrey Zeldman
- ユーザーはウェブページを F 字型に読む傾向があるため、最も重要なコンテンツを上部に配置します。
- ユーザーは目標を達成するためにサイトにアクセスします。その目標を達成するために必要なものを考え、それ以外のものはすべて削除します。視覚的およびテキスト的な装飾、古いコンテンツ、過剰なリンクなどの不要な要素を排除します。
- ソーシャル共有アイコンは、レイアウトを煩雑にし、コードがページの読み込みを遅くする可能性があるため、注意が必要です。
- コンテンツ用にレスポンシブ レイアウトを設計します。デバイスの固定サイズは使用しません。
テスト コンテンツ
- Chrome DevTools などのエミュレーション ツールを使用して、小さいビューポートでの読みやすさを確認します。
- 帯域幅が狭くレイテンシが高い条件でコンテンツをテストし、さまざまな接続シナリオでコンテンツを試します。
- 低価格のスマートフォンでコンテンツを読んだり操作したりしてみてください。
- 友人や同僚にアプリやサイトを試してもらう。
- シンプルなデバイス テストラボを構築します。Google の Mini Mobile Device Lab の GitHub リポジトリには、独自のラボを構築する手順が記載されています。OpenSTF は、複数の Android デバイスでウェブサイトをテストするためのシンプルなウェブ アプリケーションです。
OpenSTF の動作は次のとおりです。
モバイル デバイスは、コミュニケーション、ゲーム、メディア用のデバイスとしてだけでなく、コンテンツの消費や情報の取得にもますます利用されるようになっています。
そのため、さまざまなビューポートで適切に動作するコンテンツを計画し、クロスデバイスのレイアウト、インターフェース、インタラクションのデザインを検討する際にコンテンツを優先することがますます重要になっています。
データ費用を理解する
ウェブページはますます大きくなっています。
HTTP Archive によると、上位 100 万件のサイトの平均ページの重さは 2 MB を超えています。
ユーザーは、読み込みが遅い、または費用がかかると認識したサイトやアプリを避けるため、ページやアプリのコンポーネントの読み込みにかかる費用を把握することが重要です。
ページの重さを軽減すると、収益も増える可能性があります。YouTube の Chris Zacharias は、視聴ページのサイズを 1.2 MB から 250 KB に縮小したところ、次のことがわかったと述べています。
つまり、ページの重さを小さくすることで、まったく新しい市場を開拓できる可能性があります。
ページの重さを計算する
ページの重さを計算するためのツールは多数あります。Chrome DevTools の [ネットワーク パネル] には、すべてのリソースの合計バイトサイズが表示されます。このパネルを使用して、個々のアセットタイプの重みを確認できます。ブラウザのキャッシュから取得されたアイテムを確認することもできます。
![リソース サイズが表示されている Chrome DevTools の [Network] パネル。](https://web.developers.google.cn/static/articles/multi-device-content/image/chrome-devtools-network-p-305b505dd600f.png?hl=ja)
Firefox などのブラウザにも同様のツールがあります。
WebPagetest では、最初のページ読み込みと後続のページ読み込みをテストできます。スクリプト（サイトにログインするなど）を使用するか、RESTful API を使用して、テストを自動化できます。次の例（developers.google.com/web を読み込む）は、キャッシュ保存が成功し、後続のページ読み込みで追加のリソースが不要になったことを示しています。
WebPagetest では、MIME タイプ別のサイズとリクエストの内訳も確認できます。
ページの費用を計算する
多くのユーザーにとって、データはバイト数とパフォーマンスだけでなく、費用もかかります。
サイト What Does My Site Cost? を使用すると、サイトの読み込みにかかる実際の費用を概算できます。次のヒストグラムは、amazon.com を読み込むのにかかる費用（プリペイド データプランを使用）を示しています。
なお、この指標では収入に対する手頃さは考慮されていません。blog.jana.com のデータには、データの費用が示されています。
| 500MB データプランの 料金（米ドル） |
1 時間あたりの最低賃金（米ドル） |
500 MB のデータプランの料金を支払うために必要な労働時間 |
|
| インド | $3.38 | $0.20 | 17 時間 |
| インドネシア | $2.39 | $0.43 | 6 時間 |
| ブラジル | $13.77 | $1.04 | 13 時間 |
ページの重さは、新興市場だけの問題ではありません。多くの国では、データ容量が制限されたモバイルプランが使用されており、サイトやアプリが重くて費用がかかると認識されると、ユーザーはアクセスしなくなります。「無制限」の携帯通信会社や Wi-Fi のデータプランでも、通常はデータの上限があり、上限を超えるとブロックまたはスロットリングされます。このような理由から、ページが消費するデータ量については、できる限り透明性を高めることが望ましいです。具体的なベスト プラクティスについては、次のブログ投稿をご覧ください。コストの透明性による信頼性の確保
結論: ページの重さはパフォーマンスに影響し、費用もかかります。コンテンツの効率を最適化するでは、その費用を削減する方法について説明します。