生産的なモバイルAPIを設計するためのベストプラクティス

Webには、モバイルデバイスでの高いパフォーマンスに関する一般的なAPI設計に関する多くの有益な記事があります。 しかし、モバイルクライアントでの使用を目的としたバックエンドAPIのパフォーマンスを最適化するために必要なアーキテクチャソリューションについては、ほとんど議論されていません。



もちろん、モバイルアプリケーション自体のパフォーマンスを最適化する必要があります。 しかし、インフラストラクチャエンジニアは、モバイルクライアントにデータリソースとソフトウェアリソースを確実かつ迅速に提供するために多くのことを行うことができます。



モバイルソフトウェアを設計する際に考慮すべき事項を次に示します。

• 限られた画面サイズ 。 データ用の小さなスペース、小さな画像。
• 同時接続が少ない 。 多くの同時非同期リクエストを実行できるデスクトップブラウザーとは異なり、モバイルブラウザーは同じドメインへの接続数が限られているため、これは重要です。
• ネットワークが遅い 。 ネットワークのパフォーマンスは、複数の加入者にサービスを提供する信号受信の全体的なレベルに大きく影響されます（一部のネットワークはWi-Fiに接続していますが、一部のネットワークは過負荷になり、ユーザーが別のベースステーションに接続すると追加の検索操作を実行します）。
• より低い処理能力 。 集中的なクライアントコンピューティング、3Dレンダリング、およびJavaScriptの頻繁な使用により、パフォーマンスが大幅に低下する可能性があります。
• より少ないキャッシュ 。 通常、モバイルクライアントのメモリは限られているため、パフォーマンスを向上させるためにキャッシュされたコンテンツに頼りすぎないことが最善です。
• 「特別な」ブラウザ 。 多くの点でモバイルブラウザのエコシステムは、開発者が致命的な欠陥と非互換性を備えた新しいバージョンをリリースした数年前のデスクトップブラウザの断片化された環境に似ています。

説明した困難を解決する方法は多数ありますが、この記事では主に、モバイルクライアントのパフォーマンス（または認識）を改善するためにAPIまたはバックエンドでできることについて説明します。 2つの主要な問題を検討します。

1. ネットワーク接続とデータ転送の要件を最小限に抑えます 。 効果的なマルチメディア処理、効率的なキャッシング、およびより少ない接続でのデータ処理向けのより長い操作の使用。
2. 「正しい」データのネットワークを介して送信します 。 必要な/要求されたデータのみを返すようなAPIの設計、およびさまざまなタイプのモバイルデバイスの最適化。

この記事ではモバイルセグメントに焦点を当てていますが、他の分野のAPIクライアントにも多くの教訓とアイデアを適用できます。

ネットワーク接続とデータ転送を最小限に抑える

モバイルデバイスのパフォーマンスを向上させるために解決する必要がある最も重要なタスクの1つは、Webページのレンダリングに必要なHTTP要求の数を最小限にすることです。 これはさまざまな方法で行われ、アプローチの選択はデータによって異なる場合があります。

画像

ページ上の画像ごとに1つのリクエストを行うと、速度を向上させ、個々の画像のキャッシュを活用できます。 デスクトップブラウザーはリクエストを迅速かつ並行して処理できるため、その数によってパフォーマンスが大幅に低下することはありません（キャッシュにより、「強度」マージンはさらに高くなります）。 ただし、モバイルデバイスでは、多数の要求が致命的になる可能性があります。



画像に対するリクエストを最小化すると、リクエストの総数を減らすことができ、場合によっては送信データの量を減らすことができます（これはパフォーマンスに良い影響を与えます）。 どのような戦略に従うことができますか？

スプライト

スプライト画像を使用すると、サーバーからダウンロードする必要がある個々の画像の数を減らすことができます。 しかし、このソリューションには欠点があります：スプライトはサポートに問題を引き起こす可能性があり、状況によっては生成が簡単ではありません（たとえば、製品カタログを検索する場合、多数のプレビューを表示する必要があります）。

画像の代わりにCSSを使用する

どこでも、可能な限り、画像を避け、 シャドウ 、 グラデーション 、その他の効果にCSSレンダリングを使用する場合、転送およびダウンロードする必要があるバイト数を減らすことができます。

レスポンシブ画像のサポート

レスポンシブ画像は、適切なデバイスに正しい画像を配信する一般的な方法です。 Appleは、通常の画像をロードし、JavaScriptを使用してそれらをより高解像度の画像に置き換えることでこれを行います。 他の多くのアプローチがありますが、私たちはこの問題を解決するにはほど遠いです。



レスポンシブイメージを使用するには、それらがサーバーでサポートされていることと、APIが同じイメージの異なるバージョンをサポートしていることを確認してください。 特定の実装は、クライアントの決定に依存します。

データURIを使用して画像をインライン化することにより、追加のクエリを削減します

スプライトの代替方法は、データURIを使用してHTMLの画像をインライン化することです。 その結果、画像はページ全体の一部になります。 また、バイト単位のサイズは増加する可能性がありますが、このような画像はGzipを使用して圧縮されるため、送信される情報量の増加を補います。



ヒント ：URIを使用する場合：

• URIに埋め込む前に、画像を目的のサイズに縮小します。
• Gzipが要求に対する応答を圧縮することを確認します（圧縮を利用するため）。
• URIに埋め込まれた画像はCSSページの一部であることに注意してください。これは、個々の画像をキャッシュすることがより困難になることを意味します。 したがって、画像をローカルにキャッシュする正当な理由がある場合（たとえば、異なるページで頻繁に使用される場合）は、インライン展開を避けてください。

ローカルストレージとキャッシュの使用

モバイルネットワークの動作は遅いため、HTML、CSS、および画像はローカルストレージ（localStorage）に保存できます。 ローカルストレージを使用してBingのパフォーマンスを向上させる優れた研究は、HTMLドキュメントのサイズを約200 Kbから約30 Kbに削減するのに役立ちました。



ユーザーによるパフォーマンスの主観的評価を改善する優れた方法は、モバイルデバイスで使用されるデータを事前に選択して、追加の要求なしに顧客に送信することです。 これには、ページ分割された検索結果、人気のある検索、ユーザーデータが含まれます。 このアプローチを考えてアーキテクチャで検討すると、ユーザーが要求する前にデータを準備およびキャッシュできるAPIを作成できます。これにより、パフォーマンスの主観的な認識が向上します。



ヒント ：アプリケーションの更新中に変更される可能性が低いデータ（カテゴリやメインナビゲーションなど）は、ネットワーク経由で転送する時間とリソースを無駄にしないようにアプリケーション内で配信する必要があります。



理想的には、必要に応じてデータを転送し、適切なときに事前にロードする必要があります。 ユーザーに画像やコンテンツが表示されない場合は、送信しないでください（一部の要素は単に「非表示」になるため、応答性の高いサイトでは特に重要です）。 予備的な画像準備の優れたアプリケーションは、検索結果のギャラリーです。 インターフェイスを高速化するには、次の画像と前の画像をすぐにロードすることをお勧めします。 ただし、夢中になったり、写真をアップロードしすぎたりしないでください。ユーザーが写真を見ることさえできないからです。



ローカルストレージからデータを取得するとパフォーマンスが低下する可能性がありますが、この効果はネットワーク経由でデータを転送するよりもはるかに弱いです。 さらに、一部のアプリケーションは、ローカルストレージ以外に、 appCacheなどの他のHTML5機能を使用して、パフォーマンスと起動速度を向上させます。



ヒント ：CSSとJavaScriptを個別のリクエストに直接埋め込み、これらのファイルへのリンクを保存し、Cookieを介してサーバーに転送する場合、クライアントはこれらのリソースを再度ダウンロードする必要はありません（新しいファイルのみがネットワーク経由で転送されます）。 これにより多くの時間を節約でき、ローカルキャッシュを使用するための優れたツールです。 上記のファイルを直接埋め込み、リンクする方法の詳細については、 http ： //calendar.perfplanet.com/2011/mobile-ui-performance-considerations/に記載されています 。

ノンブロッキングI / O

クライアントの最適化に関しては、パフォーマンスを大幅に低下させる可能性のあるJavaScriptのブロック実行を監視することをお勧めします。 しかし、APIにとっては、これはさらに重要です。 たとえば、タイムアウトする可能性があるサードパーティのリソースへの呼び出しなど、長いAPI呼び出しがある場合は、呼び出しを非ブロッキングとして実装する（または長時間待機させる）ことが重要であり、ポーリングモデルまたはトリガーモデルを選択する必要があります。

• ポーリング（プルモデル） ：ポーリングAPIでは、クライアントは要求を作成し、結果を定期的にチェックし、必要に応じてチェックの頻度を減らします。
• トリガー（プッシュモデル） ：トリガーAPIで、呼び出しは要求を生成してからリッスンし、サーバーが応答するのを待ちます。 彼はイベントをトリガーするコールバックを提供します。これにより、呼び出し元はクエリ結果の外観について学習します。

通常、モバイルクライアントは信頼できないため、トリガーAPIの実装はより困難です。 したがって、ほとんどの場合、ポーリングモデルを使用することをお勧めします。



たとえば、 モバイルアプリケーションの決定では、製品ページにこれらの製品が利用可能な国の現地価格が表示されていました。 結果はサードパーティのサービスによって提供されたため、ポーリングAPIの助けを借りて、アプリケーションを停止せずに結果を受信し、結果を待つ間、開いている接続をサポートできませんでした。



モバイルクライアントの接続数は限られているため、APIが迅速に応答し、実行保留中の結果をブロックしないことを確認してください。



ヒント：おしゃべりなAPIは避けてください 。 ネットワークが遅い場合、いくつかのAPI呼び出しを避ける必要があります。 目安として、返されたページをレンダリングするために必要なすべてのデータを1つのAPI呼び出しに入れることをお勧めします。



サーバー側で、一部のコンポーネントが他のコンポーネントよりもかなり遅い場合、特性の応答時間に焦点を合わせて、APIを個別の呼び出しに分割することをお勧めします。 したがって、クライアントは最初のクイックコールの後にページのレンダリングを開始し、遅いコールへの応答を待ちます。 つまり、画面上のテキストの表示に必要な時間を削減します。

リダイレクトを避け、DNSクエリを最小限に抑える

クエリに関しては、特にDNSクエリを必要とするドメイン間のリダイレクトである場合、リダイレクトはパフォーマンスを低下させる可能性があります。



たとえば、多くのサイトは、クライアントリダイレクトを使用してモバイルバージョンで動作します。 つまり、モバイルクライアントがメインサイト（たとえば、 katemats.com ）のURLにアクセスすると、モバイルサイトm.katemats.comにリダイレクトされます （これは、サイトがさまざまなテクノロジースタック上に構築されている場合によく見られます）。 同様のスキームの例を次に示します。

1. ユーザーは「yahoo」をグーグル検索し、検索結果の最初のリンクをクリックします。
2. GoogleはトラッキングURLを使用してクリックをキャプチャし、 www.yahoo.comにリダイレクトします [リダイレクト]
3. Googleリダイレクトへの回答は、モバイルオペレーターのベースステーションを通過し、クライアントの電話に到達します。
4. www.yahoo.comに対してDNSクエリが実行されています 。
5. 見つかったIPは、BSを介して電話に送信されます。
6. 電話がwww.yahoo.comにアクセスすると、モバイルクライアントとして認識され、 m.yahoo.comにリダイレクトされます [リダイレクト]
7. 次に、電話は再びm.yahoo.comサブドメインに対してDNSクエリを実行する必要があります。
8. 見つかったIPは、BSを介して電話に送信されます。
9. 最後に、最終的なHTMLと必要なリソースがBSを介して電話に転送されます。
10. モバイルサイトのページの一部の画像は、 l2.yimg.comなどの別のドメインへのリンクを介してCDN経由で提供されます。
11. 電話は再びl2.yimg.comサブドメインのDNSクエリを作成します。
12. 見つかったIPは、BSを介して電話に送信されます。
13. 写真が描かれ、ページの準備ができました。

ご覧のとおり、サーバー側でリダイレクトを使用する（つまり、サーバーを経由してルーティングし、クライアントでDNSクエリとリダイレクトの数を最小限に抑える）か、または適応技術を使用することで回避できるオーバーヘッドコストがたくさんあります。



ヒント ：DNSクエリを回避できない場合は、時間を節約するために、既知のドメインに対して予備のDNSクエリを使用してみてください。

HTTPおよびSPDYパイプライン

別の便利なテクニックはHTTPパイプラインです。 複数のクエリを1つに結合できます。 私はSPDYを選択しますが、これはHTTPリクエストを最適化し、それらがより効率的になるようにします。 このプロトコルは、Amazon Kindle、Twitter、およびGoogleでサポートされています。

「正しい」データを送信する

クライアントごとに、CSSとJavaScriptの異なるファイルを送信する必要があります。 結果の数でさえ異なる場合があります。 結果とファイルのさまざまな組み合わせとバージョンをサポートするAPIを設計すると、優れたコラボレーションエクスペリエンスを最大限に柔軟に作成できます。

制限とオフセットを使用して結果を取得します。

通常のAPIと同様に、 limit



とoffset



を使用して結果を抽出limit



と、クライアントは特定の使用に必要なさまざまなデータを要求できます（モバイルクライアントの結果は少なくなります）。 私はlimit



とoffset



表記を好みます。これは（ start



やnext



よりも）より一般的であり、多くのデータベースでよく理解されており、したがって使いやすいからです。



/products?limit=25&offset=75







最大または最小公倍数（共通分母）に対応するデフォルト値を選択します。これにより、ビジネスで最も重要な顧客を選択できます（対象ユーザーのコアがモバイルクライアントである場合、主に訪問している場合はそれ以上）デスクトップコンピュータ、これは通常B2Bサイトおよびサービスに当てはまります）。

部分応答と部分更新をサポート

顧客が必要な情報のみを要求できるようにAPIを設計します。 これは、APIがフィールドのセットをサポートする必要があり、毎回リソースの完全なビューを返さないことを意味します。 クライアントが不要なデータを収集および解析する必要がない場合、要求が簡素化され、生産性が向上します。



部分的な更新により、顧客はAPIに書き込むデータで同じことができます（そして、リソースの分類内ですべての要素を定義する必要はありません）。

Googleは、カンマ区切りリストの形式で追加のオプションフィールドを使用した部分応答をサポートしています。



http://www.gogle.com/calendar/feeds/[emil prtected ]/private/full? fields=entry(title,gd:when)







呼び出しにentry



が指定されている場合、これは、呼び出し元がフィールドの部分セットのみを要求することを意味します。

Cookieの使用を回避または最小化します。

クライアントがドメインにリクエストを送信するたびに、このドメインから受信したすべてのCookie（重複した値や無関係な値も含む）が含まれます。 したがって、転送されるデータの量を減らしてパフォーマンスを向上させる別の方法は、小さいサイズのCookieを維持することです（不要な場合は要求しません）。 Cookieを不必要に使用または要求しないでください。 Cookieのないドメイン（たとえば、静的ドメインまたはCDNからの画像）からのアクセス許可を必要としない静的コンテンツを提供します。 https://developers.google.com/speed/docs/best-practices/request：Cookieを操作するいくつかの方法について説明します 。

APIのデバイスプロファイルを作成する

デスクトップ、タブレット、スマートフォンのさまざまな画面サイズと解像度を考えると、サポートするプロファイルを作成すると便利です。 プロファイルごとに、特定のデバイスに適した異なる画像、データ、ファイルを提供できます。 これは、クライアントへのメディアクエリを使用して行われます 。



プロファイルが多いほど、特定のデバイスの操作性が向上します。 ただし、サポートされているすべての種類の機能とスクリプトを維持することはさらに困難になります（デバイスは絶えず変化および開発しているため）。 したがって、絶対に必要な数のプロファイルのみを維持することをお勧めします。 良いインタラクション体験を生み出すための妥協と機会については、この記事を読むことをお勧めします： https : //mobiforge.com/design-development/effective-design-multiple-screen-sizes



ほとんどのアプリケーションでは、3つのプロファイルで十分です。

1. 携帯電話：より小さな画像、利用可能なタッチコントロール、低ネットワーク帯域幅。
2. タブレット：画像は大きくなりますが、低帯域幅のネットワークに適合し、タッチ制御が利用でき、リクエストでより多くのデータが送信されます。
3. デスクトップコンピューター：タブレット用の画像と、Wi-Fiおよびデスクトップブラウザー用の高解像度画像。

目的のプロファイルをクライアントで選択できます。 サーバー側APIは、これらのプロファイルを取得し、要求を送信したデバイスに応じて異なる情報を送信するように設計する必要があります。 たとえば、小さな画像が送信されたり、結果のサイズが縮小されたり、CSSとJavaScriptがインラインになります。



APIの1つが検索結果を返す場合、プロファイルは次のようになります。



/products?limit=25&offset=0







デフォルトのプロファイル（デスクトップ）が使用され、標準のページが指定されます。このページは各画像を個別に要求するため、後続のビューをキャッシュからロードできます。



/products?profile= mobile &limit=10&offset=0







10個の結果が返され、低解像度の画像は単一のHTTPリクエストでURIとして送信されます。



/products?profile= tablet &limit=25&offset=0







20の結果が返されます。低解像度の画像はサイズは大きくなりますが、1つのHTTP要求でURIとして送信されます。



フィーチャーフォンなどのガジェット用のプロファイルを作成することもできます。 スマートフォンとは異なり、ページごとにのみファイルをキャッシュできます。 そのため、このようなクライアントでは、各リクエストでCSSとJavaScriptを送信するよりもプロファイルを使用する方が適切です。



サーバーの応答がプロファイルによって大きく異なる場合は、部分応答の代わりにプロファイルを使用することをお勧めします。 たとえば、ある場合には応答にインラインURIイメージとコンパクトレイアウトが含まれ、別の場合にはそれは存在しません。 もちろん、プロファイルは「部分的な回答」を使用して設定することもできますが、通常は、別のデータセットや形式などではなく、標準スキーム（たとえば、より大きな分類のサブセット）の一部（または一部）を決定するために使用されます

結論として

モバイルデバイスを含め、Webを高速化する多くの方法があります。 この記事が、モバイルクライアントを操作するためのサーバーパーツを設計するAPI開発者にとって役立つガイドになることを願っています。