SharePoint Online ポータル パフォーマンス ガイダンスPerformance guidance for SharePoint Online portals

すべてのポータル設計には、SharePoint のカスタマイズを必要とする少なくとも 1 つの側面が含まれています。Every portal design includes at least one aspect that requires customizing SharePoint. SharePoint Online ポータルのカスタマイズ モデルは、SharePoint アドイン モデルまたは SharePoint Framework です。The customization model for SharePoint Online portals is the SharePoint Add-in model or the SharePoint Framework. これらはどちらも、SharePoint Online、Web ホスト、サービス プロバイダー、クライアント ブラウザーなどの実行環境を含む、分散アプリケーション アーキテクチャを使用します。These both use a distributed application architecture that encompasses several execution environments: SharePoint Online, web hosters, service providers, and the client browser. このアーキテクチャは、クライアントからサーバーへのデータ要求の概念に基づいています。This architecture is predicated on the concept of client-to-server data requests.

SharePoint Online のカスタマイズの実装は、Web アプリケーション全般の効果的な設計と開発、特にアプリケーション パフォーマンスの概念に関してはとりわけクライアント側の Web アプリケーションの効果的な設計と開発に、重きを置いています。Implementing customizations in SharePoint places an even greater emphasis on effective design and development for web applications in general, and client-side web applications in particular, especially when it comes to the concept of application performance.

注意

このガイダンスは主に SharePoint Online を対象にしていますが、大部分はオンプレミスの SharePoint 環境でホストされているポータルにも適用されます。Although this guidance primarily targets SharePoint Online, most of it also applies to portals hosted in an on-premises SharePoint environment.

従来のポータル ページの最適化Optimizing Classic Portal Pages

最新のページをまだ実装しておらず、既存または新規のクラシック ポータル ページの最適化を検討している場合は、このセクションが役に立ちます。If you have not implemented Modern pages yet and are looking to optimize your existing or new Classic portal pages then this section applies to you. 初期のページ レビューをいくつか支援し、SharePoint Online のクラシック ポータル ページでのパフォーマンスに関する学習を開始するには、SharePoint 用ページ診断ツールを使用できます。To assist with some initial page reviews and start the process of understanding performance on classic portal pages for SharePoint Online, the Page Diagnostics tool for SharePoint can be utilized. これは、クラシック SharePoint ポータル ページを最適化するためのガイダンスを強調表示するために、Microsoft で開発された Chrome 拡張機能です。It is a Chrome extension developed by Microsoft to highlight guidance for optimizing Classic SharePoint portal pages.

強調表示されている機能の一部は、既存の機能に関連しますが、より迅速なユーザー エクスペリエンスを提供するより適切な別の方法があるため、これらのコンポーネントは削除される予定です。その最大の原因は、構造ナビゲーションが使用されている点にあります。Whilst some of the items highlighted relate to existing out of the box functionality, we are working towards removing these components as there are better alternatives that provide a faster user experience.The biggest culprit is the use of structural navigation. このツールは、コンテンツ配信ネットワーク (CDN) などの拡張機能も強調表示します。これは、エンド ユーザー エクスペリエンスをさらに最適化するために Microsoft で利用できるようになったものです。The tool also highlights enhanced functionality e.g. Content Delivery Networks (CDNs), that have been made available by Microsoft to further optimize the end user experience. SharePoint Online のパフォーマンスをチューニングする」も参照してください。Please also see Tune SharePoint Online Performance

このツールでは、ページ診断ツールとチューニング ガイダンスの間に、パフォーマンスに影響を与えるものについて高レベルな概要が表示されます。また、このページの詳細情報から、ページのパフォーマンスに影響を与えることなくカスタマイズを作成する方法について、より深く理解することができます。What you will see is that between the Page Diagnostics tool and tuning guidance, they provide a high level overview of what impacts performance whilst the details on this page take you deeper into how customizations should be built to avoid impacting a pages performance.

行うべきではないことWhat not to do

以下の一覧に、パフォーマンスを計画するときに行うべきではない主要な事柄を示します。The following list contains the key things not to do when planning for performance.

以下を行わないでください:Don't

  • SharePoint にクライアント側のデータ要求を発行するカスタムのクライアント側コントロールを作成し、ページにそれらの十数個以上を追加する。Build custom client-side controls that issue client-side data requests to SharePoint and add a dozen or more of them to the page.
  • SharePoint データへの一元的なデータ アクセスがなくても、クライアント側コントロールを実装するため、多数のコントロールが 1 つのページにまったく同じデータを何回も要求している。Implement your client-side controls without centralized data access to the SharePoint data, so that numerous controls are requesting exactly the same data numerous times on a page.
  • ページ本文全体に冗長なカスタム JavaScript と CSS を埋め込む。Embed redundant custom JavaScript and CSS throughout the page body.
  • ページ本文全体に 10 MB のサムネイル イメージを複数埋め込む。Embed several 10-MB thumbnail images throughout the page body.
  • データが最初に必要でなく、表示もされておらず、また一度も使用されなくても、ページ読み込み時にすべてのクライアント側のデータ要求を実行する。Execute all client-side data requests at page-load time, even if the data is not initially needed or displayed, even if it might never be used.
  • 不要な順序依存関係をデータ要求シーケンスに挿入し、同期データ要求を使用して順番に実行されるようにする。Inject unnecessary order dependencies into the data request sequence and use synchronous data requests to ensure the order of execution.
  • 選択したデータ要求 API として従来の SharePoint リスト (SOAP) Web サービスを使用し、形式の整っていない CAML クエリを渡す。Use the legacy SharePoint Lists (SOAP) web service as the data request API of choice and pass it poorly-formed CAML queries.
  • クライアント上のデータ応答 (特に静的データの場合) のキャッシュを回避して、すべてのページ読み込み時に各データ要求が必ず再実行されるようにする。Avoid caching data responses (especially for static data) on the client to ensure that each data request gets re-executed on every page load.
  • 冗長であったり競合したりしている場合でも、各データ応答の完了時に、ページのドキュメント オブジェクト モデル (DOM) に対して、数百の更新を実行する。Perform hundreds of updates to the Document Object Model (DOM) of the page as each data response completes, even if they are redundant or conflicting.

SharePoint Online カスタマイズ モデルの進化Evolution of the SharePoint Online customization model

SharePoint Online カスタマイズ モデルは、カスタム コードをサーバー上で実行してサーバー側のデータ要求を行う旧型のサーバーベース モデルから、カスタム コードをリモートで実行してクライアント側のデータ要求を行う新型のクライアントベース モデルへと進化しました。The SharePoint Online customization model has evolved from the classic server-based model, where custom code executes on the server and performs server-side data requests, to a modern client-based model, where custom code runs remotely and performs client-side data requests. このモデルのナチュラル ソリューション アーキテクチャは、分散型クライアント側 Web アプリケーションです。The natural solution architecture for this model is the distributed client-side web application.

新しいカスタム ソリューション特有の複雑さの増加とは別に、分散型クライアント側 Web アプリケーション モデルの結果として、新しいカスタム ソリューションに関連付けられたクライアントからサーバーへのネットワーク トラフィックが著しく増加し、クライアント側実行環境への依存が大幅に高まります。A consequence of the distributed client-side web application model, aside from an increase in the inherent complexity of the new custom solution, is a significant increase in client-to-server network traffic associated with the new custom solution and a greater dependency on the client-side execution environment.

各 Web アプリケーション モデルに関連付けられているページ読み込みシーケンスについて、次を比較検討してください。Consider the following comparison of the page-load sequence associated with each web application model.

旧型のサーバー側 Web アプリケーション シーケンスClassic server-side web application sequence

  • ページへの最初のアクセスFirst visit to page
    • ページ要求の発行Issue page request
    • リソース ファイル要求 (0 個以上) の発行Issue resource file requests (zero or more)
    • いくつかの JavaScript の実行Execute some JavaScript
  • ページへの再アクセスReturn visit to page
    • ページ要求の発行Issue page request
    • いくつかの JavaScript の実行Execute some JavaScript

新型のクライアント側 Web アプリケーション シーケンスModern client-side web application sequence

  • ページへの最初のアクセスFirst visit to page
    • ページ要求の発行Issue page request
    • リソース ファイル要求 (0 個以上) の発行Issue resource file requests (zero or more)
    • いくつかの JavaScript の実行Execute some JavaScript
    • データ要求 (0 個以上) の発行Issue data requests (zero or more)
    • より多くの JavaScript の実行Execute more and more JavaScript
  • ページへの再アクセスReturn visit to page
    • ページ要求の発行Issue page request
    • いくつかの JavaScript の実行Execute some JavaScript
    • データ要求 (0 個以上) の発行Issue data requests (zero or more)
    • より多くの JavaScript の実行Execute more and more JavaScript

ネットワーク モニターは、旧型の Web ページの場合に比べ、新型の Web ページではネットワーク トラフィックが桁違いに増加しやすくなることを示します。A network monitor will show that a modern webpage can easily cause an order-of-magnitude increase in network traffic compared to that of a classic webpage. ブラウザー ベースの実行プロファイラーでも、クライアント側の JavaScript の実行に新型 Web ページがより多く依存していることが示されます。A browser-based execution profiler will also show that a modern webpage has a greater dependency upon the execution of client-side JavaScript. 確かに、これらの増加は新しいソリューションの設計と実装に応じたものですが、大幅に増加する可能性は高くなっています。Granted, these increases are a function of the design and implementation of the new solution, but the probability of a significant increase is high.

クライアント側の Web アプリケーション用の一般的なパフォーマンス ガイドラインGeneral performance guidelines for client-side web applications

カスタムのクライアント側 Web アプリケーションの作成にコミットすると、次のように見なされます。After you commit to building a custom client-side web application:

  • そのアプリケーションのクライアント側のパフォーマンスの担当者になることに同意している。Acknowledge that you are now responsible for the client-side performance of that application.
  • サーバー側のレンダリングとキャッシュの利点がカスタム コントロールで使用できなくなったことに同意している。Acknowledge that the benefits of server-side rendering and caching are no longer available for your custom controls.
  • 自分のアプリケーションが、パフォーマンスの良好なクライアント側の同等機能を提供する必要があることを理解している。Understand that your application must now provide well-performing, client-side equivalents.

パフォーマンスの観点から、新型の Web アプリケーション全般、特にクライアント側 Web アプリケーションの目標は、旧型の Web ページへの再アクセス用に観察される、最小限のネットワーク トラフィック パターンを模倣するために必要なクライアント側ロジックを実装することです。**From a performance perspective, the goal with modern web applications in general, and client-side web applications in particular, is to implement the client-side logic necessary to mimic the minimal network traffic patterns observed for return visits to classic webpages.

次のセクションでは、この目標を達成するためのパフォーマンス ガイダンスを提供します。The following sections provide performance guidance for achieving this goal.

テレメトリの使用Use telemetry

パフォーマンスは、多くの場合、エンドユーザーにより、主観的に観察されます。Performance is often viewed in subjective terms by end-users. しかし、ポータルの表示速度が遅い などの問題を根本的に解決することは、かなり困難です。However, it is rather challenging to definitively resolve issues such as The portal is slow. 体感的なパフォーマンスの問題を定量化するには、クライアント側 Web アプリケーションの客観的なメトリックスを取得することが重要です。To quantify perceived performance issues, it is critical to obtain objective metrics for the client-side web application.

クライアント側 Web アプリケーションの設計と開発には、パフォーマンス ベースラインを確立し、アプリケーションの実行時パフォーマンスを継続的に監視するためのテレメトリが含まれている必要があります。The design and development of your client-side web application should include telemetry to establish a performance baseline and continuously monitor the run-time performance of the application.

次のような重要な情報アプリケーションの指標をキャプチャします。Capture critical information application metrics such as:

  • アプリケーション初期化のタイミングApplication initialization timing
  • ページ読み込みのタイミング (ページ全般、および特定のページ)Page-load timing (in general, and for specific pages)
  • クライアント側のタイミング (アクション全般、および特定のアクション)Client-side timing (in general, and for specific actions)
  • 外部要求/応答のタイミング (SharePoint REST 呼び出し、サードパーティのサービスなど)External request/response timing (for example: SharePoint REST calls, third-party services)
  • 検索実行のタイミングSearch execution timing
  • ページ イベントの発生Page events occurring
  • コントロールレベル (つまり、ユーザー) アクションの発生Control-level (that is, user) actions occurring
  • 例外の発生 (データ要求の失敗、データ要求の調整など)Exceptions occurring (for example: data request failed, data request throttled)

クライアント側 Web アプリケーションの客観的なパフォーマンス ベースラインを確立し、そのベースラインを使用して、初期設計に関する決定を検証/調整します。Establish an objective performance baseline for your client-side web application, and use that baseline to validate/tune your initial design decisions. アプリケーションの展開後、継続的なパフォーマンスを監視し、指標を使用して、発生する可能性のある問題を特定して解決します。After the application has been deployed, monitor ongoing performance and use the metrics to identify and resolve any issues that might arise.

Azure Application Insights を検討してください。これには、クライアント側 Web アプリケーションにテレメトリを簡単に追加できるようにする JavaScript モジュールが用意されています。Consider using Azure Application Insights, which provides a JavaScript module that makes it easy to add telemetry to any client-side web application. 独自のテレメトリ バックエンド サービスを作成することもできます。ただし、SharePoint 内にテレメトリ データを格納すると、ポータルのパフォーマンスに悪影響を与えるため、推奨されていないことを理解しておいてください。You can also build your own telemetry back-end service, but do know that we don't recommend storing the telemetry data in SharePoint because it negatively impacts your portal performance.

最新のクライアント ブラウザーの使用Use a modern client browser

クライアント ブラウザーは、実際のパフォーマンスと利用可能な機能に関して、クライアント側 Web アプリケーションのパフォーマンスに大きな影響を与えることがあります。The client browser can have a significant impact on the performance of the client-side web application in terms of actual performance and available functionality.

一般に、デスクトップ オペレーティング システムと互換性がある最新バージョンの新型ブラウザーをターゲットにする必要があります。In general, you should target the most up-to-date version of modern browsers that are compatible with your desktop operating system.

大企業では、従来のブラウザーを使用する必要がある、少なくとも 1 つの Web ベースの基幹業務 (LOB) アプリケーションを保有していることが一般的です。It is common for a large enterprise to have at least one web-based Line-of-Business (LOB) application that still requires the use of a legacy browser. しかし、この制約が新しい Web アプリケーションの進歩の妨げになる必要はありません。However, that constraint should not hinder the forward progress of new web applications. 新型ブラウザーの強化された機能とパフォーマンスを活用するように、新しいクライアント側 Web アプリケーションを設計します。Design new client-side web applications to take advantage of the improved performance and functionality of modern browsers.

従来のブラウザー制約を処理する場合:When dealing with a legacy browser constraint:

  • 従来のブラウザー要件を例外として処理し、例外を解決する総コストを分析する。Treat legacy browser requirements as exceptions; analyze the total cost of resolving the exception.
  • 実行時に従来のブラウザーが検出されたときに、新しいアプリケーションの新型の機能を低下させたり無効にしたりする。Degrade/disable modern functionality in the new application when a legacy browser is detected at run-time.
  • 制約付きの LOB アプリケーションにのみ、従来のブラウザーを使用することを検討し、新しいクライアント側 Web アプリケーションを含む他のすべてには新型のブラウザーを使用する。Consider using the legacy browser only for the constrained LOB application; use a modern browser for everything else, including the new client-side web applications.

最新の Office 365 のブラウザー要件については、「Office Online で動作するブラウザーの種類」を参照してください。For the latest Office 365 browser requirements, see Which browsers work with Office Online.

クライアント環境とネットワーク トポロジについて考慮するConsider the client environment and network topology

クライアント環境と、クライアントをサーバーに接続するネットワーク トポロジは、クライアント側 Web アプリケーションのパフォーマンスに大きな影響を与える可能性があります。The client environment and the network topology that connects the client to the server can have a significant impact on the performance of client-side web applications.

理想的なシナリオでは、クライアント環境は、新型のブラウザーを実行している最新のクライアント マシンで構成され、帯域幅が十分にある待機時間の短いネットワーク経由でサーバーに接続されています。In the ideal scenario, the client environment is comprised of up-to-date client machines running modern browsers, and is connected to the server via a network that has ample bandwidth and low latency. 実際には、あまり理想的ではないシナリオに直面し、Web アプリケーションには、迅速な変更を促すために必要な政策的な予算がない場合があります。In reality, you will be faced with a less-than-ideal scenario, and your web application may lack the political currency necessary to drive immediate change.

したがって、展開されるときにはクライアント環境の機能強化を活用するように計画しつつ、現在の制約に準拠するようにクライアント側 Web アプリケーションの初期設計を調整します。As such, tailor the initial design of your client-side web application to adhere to the present constraints, with a plan to take advantage of client environment improvements as they are deployed. このようなシナリオでは、最終的にクライアント マシンが混在するため、実行時にクライアント側 Web アプリケーションがクライアントの能力を検出し、それに応じて動作を調整できるようにします。In such a scenario, you will eventually encounter a mix of client machines, so ensure that your client-side web application can detect client capabilities at run-time and adjust its behavior accordingly.

ネットワーク パフォーマンス計画のガイダンスについては、「Office 365 のネットワーク計画とパフォーマンスのチューニング」を参照してください。For more information about Office 365 networking and performance, see Network planning and performance tuning for Office 365.

データ要求のパターンを管理するManage data request patterns

クライアント側のデータ要求トラフィックの適切な管理は、カスタムのクライアント側 Web アプリケーションのパフォーマンスに不可欠です。The proper management of client-side data request traffic is critical to the performance of a custom client-side web application. このコンテキストでの主な目的は、アプリケーションが必要とするクライアントからサーバーへのデータ要求を最小限に抑え、最適化することです。In this context, your primary goal should be to minimize and optimize the client-to-server data requests that your application requires.

データの要求を (サーバーまたは他のバックエンド データ ソースから) 管理するには、インテリジェントなデータ読み込みパターンを使用します。Use an intelligent data loading pattern to govern your requests for data (from the server or any other back-end data source)

  • 可能な限りデータ要求を延期する (つまり、遅延読み込み)。Defer the data request for as long as possible (that is, Lazy Load).
  • ブラウザー イベントまたはユーザー アクションに応答するときなど実際に必要な場合にのみ、データを要求する (つまり、コントロールが折りたたみ済み/非表示の場合はデータを要求せず、コントロールが展開/レンダリングされるまで待機します)。Request the data only if, and when, it is actually needed; for example, as in response to a browser event or user action (that is, do not request data for a collapsed/hidden control; wait until the control is expanded/rendered).

すべてのデータ要求を満たすために、クライアント側のキャッシュを使用します。Use a client-side cache to fulfill all data requests

  • データ要求をサーバーに発行する前に、ローカル データ キャッシュを参照する。Consult the local data cache before issuing the data request to the server.
  • キャッシュ データが存在し、有効期限が切れていない場合 (キャッシュ ヒット時など)、キャッシュ データを返す。Return cached data if it is present and not yet expired (for example, upon a cache hit).

キャッシュ ミスが発生した場合にのみ、サーバー (または他のバックエンド データ ソース) を呼び出します。Call the server (or other back-end data source) only when a cache miss occurs

  • AJAX 非同期呼び出しを介して最新データをフェッチする (AJAX 同期呼び出しを使用しない)。Fetch the fresh data via an asynchronous AJAX call (never use a synchronous AJAX call).
  • 最新データの要求が失敗した場合は、古い (または既定の) データを返す。Return stale (or default) data if a request for fresh data fails.
  • 待機時間の長い呼び出しの実行中に、進行状況インジケーターを表示することを検討する。Consider presenting a progress indicator while a high-latency call is in flight.

データ応答を解析します。Parse the data response

  • 要求に固有のパッケージング層すべてを、応答から削除する。Strip all request-specific packaging layers from the response.
  • コア データの結果を抽出して、要求に依存しない最小限の JSON 表記に変換する。Extract the core data results and convert into a minimal, request-independent JSON representation:
    • 最小限の表記にすると、(有限の) クライアント側のキャッシュ内のストレージが小さくて済む。A minimal representation requires less storage within the (finite) client-side cache.
    • 要求に依存しない表記は、データをそのデータ ソースと要求セマンティクスから分離する。これにより、ソリューションを開発する際に、データソースを簡単に変更できます (静的、モック、ライブ)。A request-independent representation decouples the data from its data source and request semantics; this allows the data source to be easily changed (static, mock, live) as the solution is developed.
    • JSON を使用すると、カスタムのクライアント側表示コントロールで簡単にバインドできる JavaScript オブジェクトが使用可能になる。これは、UX チームとデータ チーム間の作業データ コントラクトを定義する役割も果たします。JSON enables the use of JavaScript objects to which custom client-side display controls can easily bind; this also serves to define the working data contract between the UX and Data teams.

データ応答をクライアント側のキャッシュに格納します。Store the data response in the client-side cache

  • データ応答の JSON 表記をローカル データ キャッシュ (Web ストレージなど) に格納する。Store the JSON representation of the data response in the local data cache (for example, Web Storage).
    • 共有データ (グローバル メニューなど) にはバブリック (ローカル ストレージ) キャッシュを使用する。Use a public (local storage) cache for shared data (for example, Global Menu).
    • 個人データ (マイ ストックなど) にはプライベート (セッション ストレージ) キャッシュを使用する。Use a private (session storage) cache for personal data (for example, My Stocks).
  • 関連するデータの変動性に合わせたコンポーネント固有の有効期限の値を使用する (グローバル メニュー データ (30 分)、株価情報データ (5 分) など)。Use component-specific expiration values that align with the volatility of the associated data; for example, Global Menu data (30 mins), Stock Ticker data (5 mins).
  • 結果なし は有効なデータ応答であるため、これも必ず格納する。Be sure to store No results as well because it is a valid data response.
  • クライアント側 Web アプリケーションのすべてのページとコンポーネント全体でキャッシュ データが利用できるようにする。Ensure cached data is available across all pages and components of the client-side web application.

クライアント側データ アクセス層フレームワークの利用Leverage the Client-Side Data Access Layer Framework

クライアント側データ アクセス層フレームワークについては、この記事で後述します。このフレームワークは、上記のパターンを実装しています。The Client-Side Data Access Layer Framework is described later in this article, and implements the patterns described earlier.

データ アクセス層をクライアント側全体のフレームワークのコア コンポーネントとして扱い、整合性とパフォーマンスのためにすべてのクライアント側 Web アプリケーションで使用されるようにします。Treat the Data Access Layer as a core component of your overall client-side framework, and ensure that it is used by all client-side web applications for consistency and performance.

データ要求 API の管理Manage data request APIs

クライアント側のデータ要求の中には、SharePoint サーバーに重大な悪影響を与えるものがあります。Some client-side data requests can negatively impact the SharePoint server severely

  • クライアント側 CAML クエリ、特に従来のリスト (SOAP) Web サービスをターゲットにするクエリの使用を避ける。Avoid the use of client-side CAML queries, especially those that would target the legacy Lists (SOAP) web service.
  • クライアント側 CAML クエリは、通常、すべてのサーバー側のキャッシュ メカニズムをバイパスし、その結果、負荷の高い状況下ではサーバーのパフォーマンスが低下する。Client-side CAML queries generally bypass all server-side caching mechanisms, which results in negative server performance under heavy loads.

CAML クエリを使用する必要がある場合は、次のガイドラインに従います。If you must use CAML queries, observe the following guidelines:

  • ボリュームの大きいページ (ポータルのホーム ページなど) での使用を避ける。Avoid their use on high-volume pages (for example, the portal home page).
  • できる限り最もシンプルで最も効率的な CAML クエリを定義し、そのパフォーマンスを検証する。Define the simplest, most-efficient CAML query possible, and verify its performance.
  • クライアント側データ アクセス層フレームワーク (この記事で後述) を活用して、データ応答をキャッシュする。Leverage the Client-Side Data Access Layer Framework (described later in this article) to cache the data response.

通常、クライアント側のデータ要求には SharePoint REST API を使用します。In general, use SharePoint REST APIs for client-side data requests. データ/コンテンツの集約を実行する場合は、SharePoint Search REST API を使用します。When performing data/content aggregation, use the SharePoint Search REST APIs.

検索クエリを最適化して、実行時間と応答サイズを最小限に抑えます。Optimize your search queries to minimize execution time and response sizes

  • ワイルドカードの使用を制限する。Limit use of wildcards.
  • 必要なフィールドのみを返す (つまり、Select * を回避する)。Return only those fields that are necessary (that is, avoid Select *).
  • 結果の数を制限する (つまり、行数制限を使用する)。Limit the number of results (that is, use row limits).
  • 可能な限り最も狭いスコープをターゲットにする。Target the narrowest scope possible.
  • 検索クエリの数を可能な限り少なくする。Keep the number of search queries as low as possible.
  • 定期的なクエリ監査を実行して、同じデータをターゲットとする冗長/類似のクエリを統合する。Conduct regular query audits to consolidate redundant/similar queries that target the same data.

クライアント側の REST 要求Client-side REST requests

  • SharePoint Online へのクライアント側の REST 要求は、要求調整と要求ブロックの対象になるようになりました。Client-side REST requests to SharePoint Online are now subject to request throttling and even request blocking.
  • データ要求の HTTP 応答コード/警告に注意し、それに応じてデータ要求の動作を変更して、クライアント側 Web アプリケーションでデータ サービスが中断されないようにします。Pay attention to the HTTP response codes/warnings of your data requests and alter your data request behavior accordingly to avoid data service disruptions in your client-side web applications.

調整やブロックを回避する方法の詳細については、「SharePoint Online で調整やブロックを回避する方法」を参照してください。For details about how to avoid being throttled or blocked, see Avoid getting throttled or blocked in SharePoint Online.

REST 要求トラフィックREST request traffic

"無料送付" の活用Take advantage of "free shipping"

明示的なデータ要求を必要とせずに、クライアント側 Web アプリケーションに自動的にデータを配信できる組み込みの機能を利用します。Make use of built-in functionality that can automatically deliver data to the client-side web application without the need for an explicit data request:

  • 使用可能な場合は、spPageContextInfo という名前のグローバル JavaScript 変数を使用する。Use the global JavaScript variable named spPageContextInfo, if available.

    • すべての旧型 SharePoint ページのグローバル JavaScript 名前空間にそれを含める。It is included in the global JavaScript namespace of every classic SharePoint page.
    • それには、ページの読み込み時に、クライアント側の環境で必要となる共通のコンテキスト情報が含まれている。It contains common context information needed by the client-side environment upon page loads.
    • ページの読み込み時に、このデータを取得するために SharePoint を呼び出す必要がない。There is no need to make a call to SharePoint to get this data when the page loads.
  • モダン ページを使用しており、SharePoint Framework を使用してカスタマイズを実装する場合は、SharePoint フレームワークから事前に読み込まれた情報を使用する。Use preloaded information from SharePoint Framework, if you are using modern pages and implementing your customization by using SharePoint Framework.

  • JavaScript ファイルを使用して、クライアント側 Web アプリケーションが使用する構成設定を格納する。Use JavaScript files to store configuration settings used by the client-side web application.

    • これらのファイルをリソース ファイルの場所 (SharePoint スタイル ライブラリなど) に配置する。Place these files in your resource file location (for example, SharePoint Style Library).
    • これらのファイルを、クライアント側 Web アプリケーションで JavaScript リソース ファイルとして参照する。Reference these files as a JavaScript resource file in your client-side web application.
    • ページの読み込み時に、ブラウザーがこれらのファイルをクライアント環境に自動的に配信する。さらに、それぞれがローカル インターネット ファイル キャッシュに格納/提供される。Browsers automatically deliver these files to the client environment when the page loads; furthermore, each is stored/served from the local internet files cache.
    • ページの読み込み時に、このデータを取得するために SharePoint を呼び出す必要がない。There is no need to make a call to SharePoint to get this data when the page loads.

リソース ファイルの使用Use resource files

効果的にリソース ファイルを使用して、クライアント側 Web アプリケーションのパフォーマンスを高めます。Use resource files effectively to improve the performance of your client-side web application:

  • JavaScript/CSS を使用して、ページとコンポーネント間で共有される共通のスクリプト/CSS コンテンツを配信します。Use JavaScript/CSS files to deliver common script/CSS content shared across pages and components. JavaScript ベースの構成ファイルには、上記で説明したものと同じ利点だけでなく、さらに次の利点もあります。You get the same benefits described earlier for JavaScript-based configuration files, plus:

    • "1 つの規則、1 つの場所" という基本的概念に従っている。Adheres to the precept of "One Rule, One Place."
    • 冗長な埋め込みスクリプト/CSS コンテンツを回避する。Avoids redundant, embedded script/CSS content.
    • ページ コンテンツを最小限にする。Minimizes page content.
  • リソース ファイルをパッケージ化 (つまり、"縮小") してサイズを小さくしし、ダウンロード時間を短縮する。Package (that is, "minify") your resource files to reduce their size and improve download times.

  • 動的なファイル要求を活用して、必要な場合にのみ、オプションの JavaScript ファイルの延期/読み込みを行う (つまり、遅延読み込み)。Leverage dynamic file requests to defer/load optional JavaScript files only when necessary (that is, Lazy Load).

  • JavaScript ファイルが正しい順序で要求されるようにする。必要な機能が必ず存在するロジックを実装する。Ensure that JavaScript files are requested in the proper order; implement logic to ensure required functionality is present.

  • イメージ スプライトを活用して、ダウンロードする必要があるイメージ ファイルの数を削減する。Leverage Image Sprites to reduce the number of image files that need to be downloaded.

  • SharePoint 内のイメージ表示を活用して、一般的なイメージ ユース ケース シナリオ (サムネイル、ヒーロー、ロールアップなど) に最適なイメージ制約を定義する。Leverage Image Renditions in SharePoint to define optimal image constraints for common image use case scenarios (for example, thumbnail, hero, rollup).

Content Delivery Network の使用Use a Content Delivery Network

コンテンツ配信ネットワーク (CDN) は、エンド ユーザーが最も近い CDN の場所から特定のリソース ファイルを取得できるようにする地理的に分散されたネットワークです。A Content Delivery Network (CDN) is a geo-dispersed network that allows an end-user to obtain a given resource file from the closest CDN location. CDN を使用するとダウンロード時間が短縮され、ページ全体の体感的なパフォーマンスが向上します。Use of a CDN results in better download times and contributes to an improved perception of overall page performance.

  • 既存の CDN を活用して、サードパーティのクライアント側フレームワーク (jQuery、Bootstrap、Knockout、AJAX など) を配信する。Leverage existing CDNs to deliver third-party client-side frameworks (for example, jQuery, Bootstrap, Knockout, AJAX).

  • カスタム リソース ファイルを提供するために CDN を使用することを検討してください。Consider using a CDN to deliver your custom resource files:

注意

Office 365 プライベート CDN 機能には、URL を CDN の URL に自動的に書き換える発行機能があります。The Office 365 private CDN capability has a publishing feature auto URL rewriting to CDN URLs. そのため、プライベート CDN が有効になると、SharePoint では、開発者が構築することなく、プライベート CDN の場所を指すリンクを含む発行ページが返されます。So after private CDN is enabled, SharePoint returns your publishing pages with links pointing to your private CDN location without you as a developer having to build this. これは発行ページだけでなく、コンテンツによる検索 Web パーツによって返されるデータ、画像ライブラリ スライドショー、SPList REST クエリのイメージ フィールド、SharePoint イメージ表示にも適用されます。This applies to publishing pages, but also to data returned by the content by a search web part, the picture library slideshow, image fields in SPList REST queries, and SharePoint Image renditions. 発行ポータルでは、同じポータルでプライベート CDN とパブリック CDN の両方を組み合わせることもできます。Your publishing portal can also combine both private and public CDN on the same portal.

AJAX の使用Use AJAX

Asynchronous JavaScript and Xml (AJAX) を使用すると、クライアント側 Web アプリケーションで、ページ全体の読み込みを必要としない方法でバックグラウンド データ要求を実行できます。Asynchronous JavaScript and Xml (AJAX) allows a client-side web application to execute background data requests in a way that does not require a full page load.

強調すると、AJAX の A非同期 を表すものであり、その状態を保つことが最善の方法です。For emphasis, the A in AJAX stands for asynchronous; it is best to keep it that way. AJAX では同期呼び出しを実行できますが、これが推奨されることはほとんどありません。While it is possible to execute synchronous calls in AJAX, it is rarely a good idea to do so.

AJAX 同期呼び出しを実行しないでください。呼び出しが完了するまでブラウザーがブロックされ、ユーザー エクスペリエンスが低下します。Never perform synchronous AJAX calls; the browser blocks until the call completes, which results in a poor user experience.

通常、同期呼び出しは、データ要求のフローでの順序に関する依存関係が原因で必要になります。The need for a synchronous call usually arises due to an order dependency in the flow of data requests. 設計時にデータ要求フローを分析し、順序の依存関係を削除 (または少なくとも削減) します。Analyze the data request flow at design time, and eliminate (or at least reduce) the order dependency. 非同期データ要求の成功イベントのハンドラーのチェーンにより、残っているすべての依存関係の影響を軽減します。Mitigate the impact of any dependencies that remain by chaining the success event handlers of asynchronous data requests.

JavaScript を賢く実行するExecute JavaScript wisely

JavaScript の実行フェーズは、全体的なページ読み込みシーケンスの最後の部分です。The JavaScript execution phase is the last portion of the overall page load sequence. このフェーズでブラウザーは、すべてをまとめて最終的なレンダリングされたページをユーザーに提示するために必要な JavaScript をすべて実行します。During this phase, the browser executes all of the JavaScript necessary to tie everything together and present the final, rendered page to the user.

クライアント側 Web アプリケーションが Web ページとリソース ファイルを要求するためのガイダンス、およびすべてのデータ要求を実行するためのガイダンスのすべてに従っていても、JavaScript の実装が不適切であると、依然としてユーザー エクスペリエンスが低下する可能性があります。Poorly-implemented JavaScript can still result in a poor user experience, even if your client-side web application follows all the guidance to request the webpage, its resource files, and execute all its data requests.

JavaScript の広範なパフォーマンス ガイドラインは、この記事の範囲外です。ただし、ここで最も重要な概念のいくつかを要約します。Extensive performance guidelines for JavaScript are outside the scope of this article; however, we summarize several of the most important concepts here:

  • 更新プログラムを DOM に制限する。Limit updates to the DOM.
  • ループ構造を効率的に使用する。Use looping structures efficiently.
  • 重要なコード セグメントで try/catch の使用を制限する。Limit use of try/catch in critical code segments.
  • 変数の適切なスコープを使用する。Use proper scope for variables.

JavaScript のパフォーマンスに関する詳細なガイドラインについては、以下のトピックを参照してください。For in-depth guidelines about JavaScript performance:

ボリュームの大きいページの監視Monitor high-volume pages

クライアント側 Web アプリケーション内でのボリュームの大きいページの設計と実装には、特に注意してください。Pay special attention to the design and implementation of high-volume pages within your client-side web application.

典型的なボリュームの大きいページは、ポータルのホーム ページです。A typical high-volume page is the portal home page. 大規模な企業 (50,000 人のユーザー) の会社の IT 部門が、既定でポータルのホーム ページをすべてのデスクトップ ブラウザーで開くように強制するグループ ポリシー オブジェクト (GPO) を実装することを決定するシナリオを検討してみましょう。Consider the scenario where the Corporate IT department of a large enterprise (50,000 users) decides to implement a Group Policy Object (GPO) that forces all desktop browsers to open the portal home page by default. この場合、ポータルのホーム ページのパフォーマンスは、重要な考慮事項になってきます。The performance of the portal home page has now become a critical consideration. 初期設計でこのトラフィックの量が考慮されなかった場合、ポータルのパフォーマンスが大幅に低下する可能性があります。If your initial design did not take this volume of traffic into account, the portal could encounter a significant performance degradation.

ベスト プラクティス:Best practices:

  • ページ上の "クエリ結果" Web パーツの使用を避け、代わりに "検索によるコンテンツ" Web パーツの使用を優先する。Avoid the use of Content-by-Query web parts on the page; favor Content-by-Search web parts instead.

  • ページによって発行されるクライアント側のデータ要求の数を制限し、最適化する。Limit, and optimize, the number of client-side data requests issued by the page.

  • クライアント側のデータ要求に対して、適切なクライアント側のキャッシュを必ず有効にする。Ensure that proper client-side caching is in play for client-side data requests.

  • ページを "チャンク" する。"Chunk" the page:

    • 初期ページ処理をページの上半分 (つまり、最初のチャンク) のみに制限する。Limit initial page processing to only the top half (that is, first chunk) of the page.
    • スクロール イベントを使用して、ユーザーが下に移動するときにページの追加のチャンクの処理をトリガーする。Use scroll events to trigger the processing of additional chunks of the page as the user moves downward.
  • ハイライト (最新のケース スタディなど) やロールアップ (トップ 3 ニュース リンクなど) など、カスタム表示コントロールでレンダリングされるデータ量を制限する。Limit the amount of data rendered in custom display controls such as Highlight (for example, Latest Case Study) and Roll-Ups (for example, Top 3 News Links).

    • [続きを読む...] リンクを提供して、ポータルへの全体的な影響の小さい拡張コンテンツを表示できる、ボリュームの少ない詳細ページにユーザーをリダイレクトする。Provide Read more... links to redirect users to low-volume detail pages where expanded content can be viewed with less overall impact to the portal.

クライアント側データ アクセス層 (DAL) フレームワークClient-Side Data Access Layer (DAL) Framework

クライアント側データ アクセス層 (DAL) フレームワークは、カスタムのクライアント側 JavaScript フレームワークであり、クライアント側 Web アプリケーションのすべてのクライアント側のカスタム表示コントロールを実装して使用できるようにします。The Client-Side Data Access Layer (DAL) Framework is a custom client-side JavaScript framework that you implement and make available to all custom client-side display controls of your client-side web applications. インテリジェントなデータ読み込みパターンをサポートし、クライアントからサーバーに対する要求の詳細を抽象化し、クライアントからサーバーに対する要求のトラフィックを最小限に抑えるためのデータ キャッシュ機能を提供し、体感するページ パフォーマンスの大幅な向上を実現します。It supports intelligent data loading patterns, abstracts the details of the client-to-server requests, provides data caching functionality to minimize client-to-server request traffic, and greatly improves perceived page performance.

クライアント側 JavaScript フレームワークとライブラリは複数あり、DAL の実装に利用できます。There are a number of client-side JavaScript Frameworks and Libraries that you can leverage to implement the DAL. 最も使い慣れたものを選択して、次の原則に従ってください。Choose the one with which you are most familiar and adhere to the following tenets. 実行用のテンプレートとして、提案されている論理アーキテクチャを使用します。Use the logical architecture proposed as a template for your implementation.

クライアント側データ アクセス層 (DAL) サンプルは、クライアント側データ アクセス層 (DAL) フレームワーク用の作業用参照実装を提供します。The Client-Side Data Access Layer (DAL) Sample provides a working reference implementation of the Client-Side Data Access Layer (DAL) Framework.

アーキテクチャの原則Architectural tenets

  • パフォーマンスが第一の機能である。Performance is Feature #1.
  • クライアント側のフレームワーク全体のコア コンポーネント。整合性とパフォーマンスのために、すべてのカスタムのクライアント側 Web アプリケーションとコンポーネントで利用される。Core component of the overall client-side framework; to be leveraged by all custom client-side web applications and components for consistency and performance.
  • クライアント側のデータ キャッシュを介してデータ要求を満たし、キャッシュ ミスが発生した場合は、クライアントからサーバーへのデータ フェッチを実行する。Fulfill data requests via the client-side data cache; if a cache miss occurs, execute the client-to-server data fetch.
  • クライアントからサーバーへの AJAX 非同期呼び出しを介してサーバー データをフェッチする (同期呼び出しを使用しない)。Fetch the server data via an asynchronous client-to-server AJAX call (never use a synchronous call).
  • データ要求に失敗した場合に古いデータを再利用して、呼び出しエラーの連鎖を削減する。Reduce cascading call failures by re-using stale data when/if a data request fails.
  • 要求調整応答を尊重し、それに応じて動作を調整する。Honor request throttling responses and adjust behavior accordingly.
  • 要求に依存しない最小限の JSON 表記を使用して、サーバー データの応答をクライアント側のキャッシュに格納する。Store the server data response in the client-side cache using a minimal, request-independent JSON representation.
  • 一時的および永続的なストレージ オプションをサポートする。Support transient and durable storage options.
  • 個人データには一時的ストレージ、共有データには永続的ストレージを使用する。Use transient storage for personal data and durable storage for shared data.
  • 絶対有効期限ポリシーとスライド式有効期限ポリシーをサポートする。Support absolute and sliding expiration policies.
  • ストレージ エントリごとに、ストレージ (一時的/永続的)、有効期限ポリシー (絶対/スライド式)、有効期限タイムアウト (分単位) の独自のストレージ オプションを構成できる。Allow each storage entry to configure its own storage options for storage (transient/durable), expiration policy (absolute/sliding), and expiration timeout (in minutes).
  • ログ記録とテレメトリによって実行時パフォーマンスを継続的に監視する。Continuously monitor run-time performance via logging and telemetry.
  • データ フロー シナリオ/シーケンスの継続的な確認を行い、それぞれが全体的なページのパフォーマンスと応答性のために常に最適化されているようにする。Continuously review data flow scenarios/sequences to ensure each remains optimized for overall page performance and responsiveness.

次の図は、クライアント側データ アクセス層 (DAL) フレームワークの論理アーキテクチャを示しています。The following diagram shows the logical architecture of the Client-Side Data Access Layer (DAL) Framework.

データ アクセス層の論理アーキテクチャ

主要コンポーネントMajor components

データ アクセス層 (DAL) フレームワークの論理アーキテクチャには、次のコンポーネントが含まれています。The logical architecture of the Data Access Layer (DAL) Framework includes the following components:

  • JavaScript ベースの表示コンポーネントJavaScript-based display components

    • これらのコントロールは、インテリジェントなデータ アクセス パターン (遅延読み込みなど) と DOM イベントを利用して、データ要求をできるだけ長く延期して、必要な場合にのみ開始されるようにします (折りたたまれているメニューが展開されるまで待機するなど)。These controls leverage intelligent data access patterns (for example, Lazy Load) and DOM events to ensure that data requests are deferred for as long as possible and initiated only when necessary (for example, wait until a collapsed menu is expanded).
    • 表示コントロールは、データ要求の実行中に状態インジケーターを表示する場合があります。Display controls may present status indicators while data requests are in flight.
  • イベントベースのデータ要求Event-based data requests

    • これらのイベント ハンドラーは、コントロールまたはページ イベントにバインドされ、発生時にデータ アクセス方法を呼び出します。These event handlers are bound to control or page events and invoke data access methods when fired.
  • ビジネス データ マネージャーBusiness data manager

    • 表示コンポーネントで使用するビジネス データ オブジェクト (BDO) を提供します。Provides business data objects (BDOs) for use by the display components.
    • 基になるデータ ソースを抽象化する論理的なデータ アクセス方法を提供します。Provides logical data access methods that abstract the underlying data sources.
    • BDO データは、モック、クライアント側のキャッシュ、実際のデータ ソースから取得できます。BDO data can come from a mock, a client-side cache, or the actual data source.
  • 外部サービスExternal services

    • サーバー側 (つまり、バックエンド) のデータにアクセスするための API を提供します。Provide APIs to access server-side (that is, back-end) data.
    • SharePoint Online、サード パーティのデータ サービス、カスタム データ ソース、カスタム アプリケーションが含まれています。Includes SharePoint Online, third-party data services, custom data sources, and custom applications.
  • ストレージ マネージャーStorage manager

    • クライアント側のデータ キャッシュのセマンティクスに持続性 (一時的または永続的)、期間 (有効期限タイムアウト)、ポリシー (絶対またはスライド式) を提供します。Provides client-side data cache semantics, with durability (transient or persistent), duration (expiration timeout), and policy (absolute or sliding).
    • Web ストレージを使用すると、クライアント環境で一時的なデータ (セッション ストレージ) と長期的なデータ (ローカル ストレージ) を格納できます。Web storage allows the client environment to store transient data (session storage) and long-term data (local storage).
      • セッション ストレージは、プライベート データのキャッシュをサポートします。Session storage supports caching of private data.
      • ローカル ストレージは、共有データのキャッシュをサポートします。Local storage supports caching of shared data.
    • 必要であれば、別のクライアント側ストレージ オプションを提供する Cookie のサポートを追加できます。Cookie support can be added to provide another client-side storage option if needed.
    • クライアント側のキャッシュからデータを処理すると、実際のデータ ソースへの要求が減少し、ページ フォーマンスが向上します。Serving data from a client-side cache reduces requests to the actual data source and improves page performance.

典型的な呼び出しシーケンスTypical call sequence

  1. イベント (暗黙または明示的) がクライアント ブラウザー内で発生する。An event (implicit or explicit) occurs within the client browser.

  2. 表示コンポーネントが、レンダリングするデータを要求する必要があると判断する。The display component determines that it needs to request data to render.

  3. 表示コンポーネントが、関連するビジネス データ オブジェクト (BDO) をビジネス データ マネージャーに要求する。The display component requests its associated business data object (BDO) from the Business Data Manager.

    • オプションで、表示コンポーネントにより、要求の進行中に、進行状況のインジケーターが表示される。Optionally, the display component displays a progress indicator while the request is in progress.
  4. ビジネス データ マネージャーがストレージ キーを計算し、BDO のストレージ オプションを決定する。The Business Data Manager computes the storage key and determines the storage options for the BDO.

  5. ビジネス データ マネージャーがストレージ オプションごとに BDO をストレージ マネージャーに要求する。The Business Data Manager requests the BDO from the Storage Manager per the storage options.

    • BDO が存在し、最新の場合、キャッシュ ヒットが発生し、ストレージ マネージャーが BDO を返す (ステップ 10 に進む)。If the BDO is present and fresh, a cache hit occurs and the Storage Manager returns the BDO (go to step 10).
    • BDO が存在しない、あるいは古い場合、キャッシュ ミスが発生し、ストレージ マネージャーは BDO を返さない (ステップ 6 に進む)。If the BDO is absent or stale, a cache miss occurs and the Storage Manager returns no BDO (go to step 6).
  6. ビジネス データ マネージャーが外部サービスに (非同期) 要求を発行し、最新データを求める。The Business Data Manager issues an (asynchronous) request to the External Service for fresh data.

    • 要求が失敗した場合、古い BDO が存在するなら、ビジネス データ マネージャーはそれを再利用する (ステップ 9 に進む)。If the request fails, the Business Data Manager re-uses the stale BDO if present (go to step 9).
    • 要求が成功した場合、ビジネス データ マネージャーは最新データの応答を処理する (ステップ 7 に進む)。If the request succeeds, the Business Data Manager processes the fresh data response (go to step 7).
  7. ビジネス データ マネージャーが、ビジネス データ オブジェクト (BDO) を作成する。The Business Data Manager creates the business data object (BDO).

  8. ビジネス データ マネージャーが、BDO に最新データを追加する。The Business Data Manager populates the BDO with the fresh data.

  9. ビジネス データ マネージャーがストレージ オプションごとにストレージ マネージャーに対して BDO の格納を要求する。The Business Data Manager asks the Storage Manager to store the BDO per the storage options.

  10. ビジネス データ マネージャーは、表示コンポーネントに BDO を返す。The Business Data Manager returns the BDO to the display component.

  11. 表示コンポーネントが BDO にバインドされ、データをレンダリングする。The display component binds to the BDO and renders the data.

関連項目See also