SharePoint Online 门户性能指南

每个门户设计至少包含要求 SharePoint 自定义的一方面。 SharePoint Online 门户的自定义模型是 SharePoint 外接程序模型或 SharePoint 框架。 这两种模型都使用可包含许多执行环境的分布式应用程序体系结构：SharePoint Online、Web 主机托管服务提供商、服务提供商和客户端浏览器。 该体系结构基于客户端到服务器数据请求的概念。

SharePoint Online 自定义的实现更加注重 Web 应用程序（特别是客户端 Web 应用程序）的整体设计和开发效果，在涉及到应用程序性能的概念时尤为如此。

注意

尽管本指南主要针对的是 SharePoint Online，但大多数内容也同样适用于本地 SharePoint 环境中托管的门户。

优化经典门户页面

如果你尚未使用新式页面并且希望优化现有或新的经典门户页面，则本部分适用于你。 为了协助某些初始网页审查并启动了解 SharePoint Online 经典门户页面性能的过程，可以使用 SharePoint 页面诊断工具。 它是一种由 Microsoft 开发的 Chrome 扩展，用于突出显示 SharePoint 经典门户页面优化指南。

尽管部分突出显示的项目与现有的开箱即用功能相关，但是我们将会争取删除这些组件，因为替换组件性能更佳，可提供更快速的用户体验。 最主要的原因是结构导航的使用。 该工具还可以突出显示增强功能，如内容传递网络 (CDN)，Microsoft 已提供这些增强功能，以进一步优化最终用户体验。 另请参阅调整 SharePoint Online 性能

在页面诊断工具和调整指南之间，提供了性能影响因素的高级概述，并且通过该页面上的详细信息，你可以更深入地了解应该如何构建自定义项，以避免影响页面性能。

不应执行的操作

以下列表包含在规划性能时不应执行的关键事项。

禁止事项：

• 生成自定义客户端控件，用于对 SharePoint 发出客户端数据请求，并将其中的十几个或更多数量的控件添加到此页面。
• 无需对 SharePoint 数据进行集中式数据访问即可实现客户端控件，因此许多控件在页面中多次请求完全相同的数据。
• 将冗余自定义 JavaScript 和 CSS 嵌入该页面正文。
• 将多个 10MB 的缩略图嵌入页面正文。
• 在页面加载时执行所有客户端数据请求，即使最初不需要或不显示此数据，甚至可能从不会使用此数据。
• 将不需要的顺序依存关系注入数据请求序列并使用同步数据请求确保执行顺序。
• 选择将旧版的 SharePoint 列表 (SOAP) Web 服务作为数据请求 API，并向其传递存在格式错误的 CAML 查询。
• 避免在客户端上缓存数据响应（尤其是静态数据），以确保在每次加载页面时重新执行每个数据请求。
• 各数据响应完成时执行对该页面的文档对象模型 (DOM) 的数百个更新，无论是否冗余或存在冲突。

SharePoint Online 自定义模型演变

SharePoint Online 自定义模型已从在服务器上执行自定义代码，并且执行服务器端数据请求的基于服务器的经典模型升级为远程运行自定义代码并执行客户端数据请求的基于客户端的新式模型。 此模型的原生解决方案体系结构是分布式客户端 Web 应用程序。

分布式客户端 Web 应用程序模型除了可增加新式自定义解决方案的固有复杂性外，还显著增加了与新式自定义解决方案关联的客户端到服务器网络流量，并加大了对客户端执行环境的依赖性。

以下是对各个 Web 应用程序模型关联的页面加载序列的对比，请参考。

经典服务器端 Web 应用程序序列

• 首次访问页面
  • 发出页面请求
  • 发出资源文件请求（零个或多个）
  • 执行一些 JavaScript
• 再次访问页面
  • 发出页面请求
  • 执行一些 JavaScript

新式客户端 Web 应用程序序列

• 首次访问页面
  • 发出页面请求
  • 发出资源文件请求（零个或多个）
  • 执行一些 JavaScript
  • 发出数据请求（零个或多个）
  • 执行更多 JavaScript
• 再次访问页面
  • 发出页面请求
  • 执行一些 JavaScript
  • 发出数据请求（零个或多个）
  • 执行更多 JavaScript

网络监视器将显示与经典网页相比，新式网页可以更加轻松地按数量级增加网络流量。 基于浏览器的执行探查器还将显示新式网页对客户端 JavaScript 执行的依赖性更大。 当然，这些增长是新解决方案的设计和实现的作用，但是显著增长的可能性非常大。

客户端 Web 应用程序的整体性能准则

在你负责生成自定义客户端 Web 应用程序后：

• 确认你现在负责该应用程序的客户端性能。
• 确认服务器端呈现和缓存功能不再适用于你的自定义控件。
• 了解你的应用程序现在必须提供性能良好的客户端等效项。

从性能角度，新式 Web 应用程序的整体目标（尤其是客户端 Web 应用程序）是实现必要的客户端逻辑，以模仿再次访问经典 Web 页面时遵循的最小网络流量模式。

以下各节介绍了用于实现此目标的性能指南。

禁用经典门户网站中不必要的功能

在门户上激活发布功能时，设备通道和搜索引擎优化功能 (SEO) 均打开其默认设置。 SEO 功能旨在提高搜索相关性和在公共消费门户中的排名。 由于 SharePoint Online 不再提供公共网站，因此不再需要此功能。 但是，它仍会增加页面呈现的额外成本。

设备通道功能最初设计用于促进发布门户的移动呈现，但是，此功能的大部分已被新式功能（如移动应用和新式 UI）所取代。 如果尚未为门户设计自定义移动主页，则应禁用此功能。 与 SEO 功能类似，它会增加服务器页面呈现的额外成本和复杂性，最终降低性能。

这两个功能都隐藏在站点 UI 中，因此必须使用代码停用它们。 请参阅本节底部的 PnP PowerShell 脚本以强制禁用这些功能：：

元数据导航和筛选功能（不要与托管导航混淆）提供了一种基于元数据的动态筛选列表视图的方法。 虽然这可能对内容作者定位需要更改的特定内容很有用，但是它会增加激活此功能的站点上的每个页面呈现加额外成本。 这不仅适用于列表视图，也适用于发布页面。 建议性能至关重要的任何门户禁用此功能。

Connect-PnPOnline -Url https://yourtenant.sharepoint.com/sites/yourportal

# Device channels
Disable-PnPFeature -Scope Site -Identity 57cc6207-aebf-426e-9ece-45946ea82e4a -Force
# SEO
Disable-PnPFeature -Scope Site -Identity 17415b1d-5339-42f9-a10b-3fef756b84d1 -Force
# MetadataNav
Disable-PnPFeature -Scope Web -Identity 7201D6A4-A5D3-49A1-8C19-19C4BAC6E668 -Force

注意

PnP PowerShell 是一种开放源代码解决方案，其中包含为其提供支持的活动社区。 没有用于 Microsoft 开放源代码工具支持的 SLA。

避免基于 Web 部件的 XSLT

XSLT 会显著增加页面呈现的成本开销。 这些服务器控件要求在请求时间将样式表编译为可运行的代码。 这可能需要一些时间来完成，并且特定于服务器。 在云级别上，自定义 XSLT 的编译可能是一个常见事件。 若要避免这些成本，请考虑改用客户端呈现控件。 基于 Web 部件的 XSLT 包括（但不限于）：

• 内容查询 Web 部件
• XSLT 列表视图 Web 部件
• RSS 查看器 Web 部件
• 数据窗体 Web 部件
• 摘要链接 Web 部件

使用遥测

通常，最终用户从主观角度审视性能。 但是，门户运行速度慢等问题很难具体解决。 若要量化感知到的性能问题，请务必获取客户端 Web 应用程序的客观指标。

客户端 Web 应用程序的设计和开发应包含遥测功能，以建立性能基线并持续监视应用程序的运行时性能。

捕获关键信息应用程序指标，例如：

• 应用程序初始化时间
• 页面加载时间（整体时间及特定页面的时间）
• 客户端时间（整体时间及特定操作的时间）
• 外部请求/响应时间（例如，SharePoint REST 调用、第三方服务等）
• 搜索执行时间
• 发生的页面事件
• 发生的控制级别（即用户）操作
• 发生的异常（例如：数据请求失败、数据请求受到限制等）

为客户端 Web 应用程序建立目标性能基线，并使用该基线验证/调整初始设计决策。 部署应用程序后，监视运行性能并使用这些指标发现和解决可能出现的任何问题。

请考虑使用 Azure Application Insights，其中提供了可以轻松地将遥测功能添加到任何客户端 Web 应用程序的 JavaScript 模块。 另外，也可以生成自己的遥测后端服务，但请注意，我们不建议在 SharePoint 中存储遥测数据，因为这会对门户性能造成不良影响。

使用新式客户端浏览器

就实际性能和可用功能而言，客户端浏览器可以对客户端 Web 应用程序的性能产生重大影响。

通常，应针对与你的桌面操作系统兼容的最新版新式浏览器。

大型企业至少拥有一个仍然需要使用旧版浏览器的基于 Web 的业务线 (LOB) 应用程序，这种情况很常见。 但是，这种限制不应阻碍新式 Web 应用程序的进展。 设计新式客户端 Web 应用程序，从而利用新式浏览器的改进性能和功能。

处理旧版浏览器限制时：

• 将旧版浏览器要求视为异常；分析解决此异常的总成本。
• 在运行期间检测到旧版浏览器时，降级/禁用新应用程序中的新式功能。
• 考虑仅对受限制的 LOB 应用程序使用旧版浏览器；对于任何其他应用程序（包括新式客户端 Web 应用程序）使用新式浏览器。

有关最新的 Office 365 浏览器要求，请参阅哪些浏览器适用于 Office Online。

请考虑使用客户端环境和网络拓扑

将客户端连接到服务器的客户端环境和网络拓扑可能对客户端 Web 应用程序的性能产生重大影响。

在理想情形下，客户端环境由运行新式浏览器的最新客户端计算机组成，并通过拥有充足带宽和低延迟的网络连接到服务器。 实际上，你将面临不太理想的情形，你的 Web 应用程序可能缺少促成实时更改所需的策略价值。

因此，请通过部署客户端环境改进功能后应用这些功能的计划量身定制客户端 Web 应用程序的初始设计以遵循当前限制。 在这种情形下，最终会遇到客户端计算机组合，因此请确保你的客户端 Web 应用程序在运行期间可以检测到客户端功能并对其行为进行相应调整。

有关网络性能计划的指南，请参阅 Office 365 网络计划和性能优化。

管理数据请求模式

正确管理客户端数据请求流量对于自定义客户端 Web 应用程序的性能至关重要。 在此上下文中，你的主要目标是最小化和优化应用程序所需的客户端到服务器数据请求。

使用智能数据加载模式管理（来自服务器或任何其他后端数据源的）数据请求

• 尽可能地延迟数据请求（即延迟加载）。
• 仅在确实需要时才请求数据；例如，在响应浏览器事件或用户操作时（即，不请求折叠/隐藏控件的数据；等待直至控件展开/呈现）。

使用缓存来实现所有数据请求

• 对于用户特定的内容（如用户配置文件信息），请将内容缓存到客户端上的 LocalStorage。
  • 对服务器发出数据请求之前参考本地数据缓存。
  • 如果存在缓存数据且其尚未过期（例如在缓存命中后），则返回缓存数据。
• 对于跨多个用户共享的内容 - 请考虑使用中间层缓存服务。
  • 对于动态生成或频繁更新的内容（如新闻文章），应使用 Azure Redis 缓存或任何类似的此类服务来缓存数据。
  • 对于静态内容或不经常更新的内容（如站点导航），请考虑将此内容写入 JSON 文件并从 CDN 提供。
  • 为了降低中间层的成本，客户端还可以将响应缓存到 LocalStorage。

有关其他信息，请参阅缓存。

仅在发生缓存失误时调用服务器（或其他后端数据源）

• 通过异步 AJAX 调用提取新数据（从不使用同步 AJAX 调用）。
• 如果新数据请求失败，则返回旧（或默认）数据。
• 高延迟调用运行期间考虑显示进度指示器。

分析数据响应

• 去除响应中的所有特定于请求的包装层。
• 提取核心数据结果并转换为独立于请求的最小 JSON 表示形式：
  • 最小表示形式在（有限的）客户端缓存中所需的存储空间较少。
  • 独立于请求的表示形式将数据从其数据源和请求语义中分离出来；这样就可以在开发解决方案时轻松地更改数据源（静态、模拟、实时）。
  • 可以通过 JSON 使用 JavaScript 对象，使自定义客户端显示控件可以轻松地与该对象绑定；它还用于定义 UX 和数据团队之间的工作数据协定。

将数据响应存储在缓存中

• 将数据响应的 JSON 表示形式存储在缓存中。
  • 对共享数据（例如，全局菜单）使用中间层缓存。
  • 对个人数据（例如，我的股票）使用专用（即本地存储）缓存。
• 使用与关联数据的波动性一致的特定于组件的有效期值；例如全局菜单数据（30 分钟）、股票代码数据（5 分钟）等。
• 务必存储“无结果”，因为这是有效的数据响应。
• 确保缓存的数据在客户端 Web 应用程序的所有页面和组件上可用。

利用客户端数据访问层框架

客户端数据访问层框架将在本文后续部分中介绍，它将实现上述模式。

将数据访问层视为整个客户端框架的核心组件，并确保所有客户端 Web 应用程序均使用它，以保证一致性和性能。

管理数据请求 API

一些客户端数据请求可能会对 SharePoint 服务器产生严重的不良影响

• 避免使用客户端 CAML 查询，尤其是那些针对旧版列表 (SOAP) Web 服务的查询。
• 客户端 CAML 查询通常会绕过所有的服务器端缓存机制，从而导致在负载过大时服务器性能欠佳。

如果必须使用 CAML 查询，请遵循以下准则：

• 避免在大容量页面（例如，门户主页）上使用。
• 尽可能定义最简单、最高效的 CAML 查询并验证其性能。
• 使用客户端数据访问层框架（将在本文后续部分中介绍）缓存数据响应。

通常情况下，将 SharePoint REST API 用于客户端数据请求。 执行数据/内容聚合时，使用 SharePoint 搜索 REST API。

优化搜索查询，从而最小化执行时间和响应大小

• 限制使用通配符。
• 仅返回必要的字段（即，避免 Select *）。
• 限制结果数量（即，使用行限制）。
• 尽可能地缩小范围。
• 尽可能减少搜索查询的数量。
• 执行常规查询审核，以整合针对相同数据的冗余/类似查询。

消除冗余调用

• 通常，页面上的多个控件将需要来自单个源的数据。 如果计划不当，这可能会导致多个类似服务调用。 确保一个控件检索到的数据可供其他人使用（如果适用）可以消除不必要的往返。

仅请求所需内容

• SharePoint 客户端库允许开发人员指定其应用程序所需的字段，并仅返回此数据。 这可减少所有层的成本。

有关演示此技术的代码示例，请参阅仅检索网站的选定属性

注意聚合请求卷

• 对 SharePoint Online 的客户端 REST 请求现在受到请求限制甚至请求阻止的制约。
• 注意数据请求的 HTTP 响应代码/警告并对数据请求行为进行相应的更改，以避免客户端 Web 应用程序中发生数据服务中断。

有关如何避免受限或遭屏蔽的详细信息，请参阅避免在 SharePoint Online 中被限制或阻止

批处理 REST 请求流量

• 现在可以通过 OData 批处理优化 REST 请求流量。
• 有关详细信息，请参阅 OData 批处理请求教程和 OData 批处理请求协议规范。
• 也可以考虑使用“Office 开发模式和做法 - JavaScript 核心 (PnP-JS-Core) 组件”，其中也提供了用于封装批处理请求功能的包装器。

使用“自由传递”功能

利用可以自动将数据传递到客户端 Web 应用程序的内置功能，无需使用显式数据请求：

• 使用名称为 spPageContextInfo 的全局 JavaScript 变量（如果存在）。

  • 它包含在每个经典 SharePoint 页的全局 JavaScript 命名空间中。
  • 它包含页面加载后客户端环境需要的通用上下文信息。
  • 页面加载时无需调用 SharePoint 来获取此数据。

• 如果使用现代页面并使用 SharePoint 框架实现自定义，请使用 SharePoint 框架中的预加载信息。

• 使用 JavaScript 文件存储客户端 Web 应用程序使用的配置设置。

  • 将这些文件置于资源文件所在位置（例如 SharePoint 样式库）。
  • 在客户端 Web 应用程序中将这些文件作为 JavaScript 资源文件进行引用。
  • 页面加载时浏览器自动将这些文件传递到客户端环境；此外，每个都从本地 Internet 文件缓存存储/提供。
  • 页面加载时无需调用 SharePoint 来获取此数据。

使用资源文件

有效利用资源文件，增强客户端 Web 应用程序的性能。

• 使用 JavaScript/CSS 文件传递页面和组件中共享的通用脚本/ CSS 内容。 可获得基于 JavaScript 的配置文件的上述相同功能，还包括：

  • 遵循“一个规则，一个位置”准则。
  • 避免冗余的嵌入脚本/ CSS 内容。
  • 最小化页面内容。

• 将资源文件打包（即“缩小”），以减小他们的大小并加快下载速度。

• 仅在必要时利用动态文件请求延迟/加载可选 JavaScript 文件（即延迟加载）。

• 务必按正确的顺序请求 JavaScript 文件；实现逻辑以确保存在所需的功能。

• 利用 Image Sprites 减少需要下载的图像文件数量。

• 利用 SharePoint 中的图像呈现形式定义常见图像用例场景（例如，缩略图、横幅图像、滚动图像等）的最优图像限制。

使用内容传递网络

内容交付网络 (CDN) 是地理位置分散型网络，最终用户可以通过它从最近的 CDN 位置获取给定资源文件。 使用 CDN 可以优化下载时间，并有助于改善对整体页面性能的感知。

• 利用现有的 CDN 传递第三方客户端框架（例如 jQuery、Bootstrap、Knockout、AJAX 等）。

• 请考虑使用 CDN 以提供自定义资源文件：

  • Azure CDN
  • Office 365 公用/专用 CDN
  • SharePoint 门户样式库（不使用 CDN 时的默认选项）。

注意

Office 365 专用 CDN 功能具有自动将 URL 重写为 CDN URL 的发布功能。 因此启用专用 CDN 后，SharePoint 将使用指向你的专用 CDN 位置的链接返回发布页面，你无需以开发人员身份执行生成。 此功能适用于发布页面，同时也适用于由“搜索内容”Web 部件返回的数据、图片库幻灯片、SPList REST 查询中的图像字段和 SharePoint 图像呈现形式。 此外，发布门户还可以在同一个门户中组合使用专用 CDN 和公用 CDN。

使用 AJAX

通过异步 JavaScript 和 Xml (AJAX)，客户端 Web 应用程序无需进行完整的页面加载即可执行后台数据请求。

特别强调一点，AJAX 中的 A 表示“异步”；最好将其保持不变。 虽然可以在 AJAX 中执行同步调用，但是这并不是一个好方法。

任何情况下都不执行同步 AJAX 调用；浏览器将进行阻止，直至调用完成，这会导致用户体验较差。

通常是由于数据请求流中的顺序依存关系而需要执行同步调用。 在设计时分析数据请求流并消除（或者至少减少）顺序依存关系。 通过将异步数据请求的成功事件处理程序关联在一起，降低剩余的所有依赖项的影响。

明智地执行 JavaScript

JavaScript 执行阶段是整体页面加载序列的最后一部分。 在此阶段中，浏览器执行所有必要的 JavaScript 来将所有项关联在一起并向用户显示最终的呈现页面。

即使客户端 Web 应用程序遵循了所有准则来请求 Web 页面（其资源文件）并执行其所有的数据请求，未正确实现的 JavaScript 仍然可能导致用户体验不佳。

JavaScript 的众多性能准则不属于本文范围之内；但是，我们在此处汇总了几个最为重要的概念：

• 限制 DOM 更新。
• 有效使用循环结构。
• 在重要的代码段中限制使用 try/catch。
• 使用合适的变量范围。

有关 JavaScript 性能的深入指导：

• JavaScript 模式和性能
• Office Dev PnP 网络广播 – SharePoint 中的 JavaScript 性能注意事项

监视大容量页面

特别注意客户端 Web 应用程序中的大容量页面的设计和实现。

常见的大容量页面是门户主页。 以以下情形为例：一个大型企业（50,000 个用户）的公司 IT 部门决定实现组策略对象 (GPO)，它将强制所有桌面浏览器默认打开门户主页。 门户主页的性能现在成为关键的注意事项。 如果初始设计未将该流量容量考虑在内，此门户的性能可能会显著下降。

最佳实践：

• 避免在页面上使用按查询显示的内容 Web 部件；而首选按搜索显示的内容 Web 部件。

• 限制并优化页面发出的客户端数据请求数量。

• 确保对客户端数据请求的客户端缓存正在正常进行。

• 将页面“分区”：

  • 将初始页面处理仅限制在页面的上半部分（即第一个区块）。
  • 使用滚动事件在用户向下移动时触发对页面其他区块的处理。

• 限制热点（例如，最新案例分析）和汇总（例如最热门的三个新闻链接）等自定义显示控件中显示的数据量。

  • 提供“阅读全文...”链接，将用户重定向到小容量的详情页，用户可在其中查看展开的内容，从而降低对门户的整体影响。

客户端数据访问层 (DAL) 框架

客户端数据访问层 (DAL) 框架是一个自定义客户端 JavaScript 框架，你可以将其实现并用于客户端 Web 应用程序的所有自定义客户端显示控件。 它支持智能数据加载模式，可提取客户端到服务器请求的详细信息，可提供数据缓存功能，以便最大程度降低客户端到服务器的请求流量，并显著提高感知页面性能。

可以使用大量的客户端 JavaScript 框架和库实现 DAL。 选择最熟悉的内容，并遵循以下原则。 将建议的逻辑体系结构用作实现模板。

客户端数据访问层 (DAL) 示例提供了客户端数据访问层 (DAL) 框架的实用参考实现代码。

体系结构原则

• 性能是最重要的功能。
• 整体客户端框架的核心组件；所有自定义客户端 Web 应用程序和组件为了确保一致性和性能而使用。
• 通过数据缓存实现数据请求；如果发生缓存失误，则执行客户端到服务器数据提取。
• 通过客户端到服务器异步 AJAX 调用（永不使用同步调用），提取服务器数据。
• 在数据请求失败时重用过时数据，降低级联调用失败次数。
• 接受请求限制响应，并对行为进行相应调整。
• 使用独立于请求的最小 JSON 表示形式将服务器数据响应存储在缓存中。
• 支持暂时和持久存储选项。
• 对个人数据使用暂时存储选项，对共享数据使用持久存储选项。
• 支持绝对和可调到期策略。
• 允许每个存储项配置自己的存储选项，包括存储（暂时/持久）、到期策略（绝对/可调）和到期超时（以分钟为单位）。
• 通过记录和遥测持续监视运行时性能。
• 持续检查数据流方案/序列，确保它们始终经过优化，可确保整体网页性能和响应能力。

下图展示了客户端数据访问层 (DAL) 框架的逻辑体系结构。

主要组件

数据访问层 (DAL) 框架的逻辑体系结构包括以下组件：

• 基于 JavaScript 的显示组件

  • 这些控件利用智能数据访问模式（例如延迟加载）和 DOM 事件来确保尽可能地延迟数据请求，并仅在必要时启动这些请求（例如等待直至折叠的菜单展开）。
  • 数据请求正在运行时显示控件可显示状态指示器。

• 基于事件的数据请求

  • 这些事件处理程序与控件或网页事件绑定，触发后将调用数据访问方法。

• 业务数据管理器

  • 提供可供显示组件使用的业务数据对象 (BDO)。
  • 提供用于提取基础数据源的逻辑数据访问方法。
  • BDO 数据可以源自 mock 对象、客户端缓存或实际数据源。

• 外部服务

  • 提供用于访问服务器端（例如后端）数据的 API。
  • 包括 SharePoint Online、第三方数据服务、自定义数据源和自定义应用程序。

• 存储管理器

  • 提供客户端数据缓存语义，包括持续性（暂时或永久）、持续时间（到期超时）和策略（绝对和可调）。
  • Web 存储允许客户端环境存储暂时数据（会话存储）和长期数据（本地存储）。
    • 会话存储支持缓存个人数据。
    • 本地存储支持缓存共享数据。
  • 如果需要，可以添加 Cookie 支持，从而提供其他客户端存储选项。
  • 从客户端缓存中提供数据可减少对实际数据源的请求次数，并提升网页性能。

典型调用序列

1. 事件（隐式或显式）在客户端浏览器中发生。

2. 显示组件确定是否需要请求数据才能呈现。

3. 显示组件从业务数据管理器请求获取关联的业务数据对象 (BDO)。

   • 显示组件还可以视需要在请求执行过程中显示进度指示器。

4. 业务数据管理器计算存储密钥，并确定 BDO 的存储选项。

5. 业务数据管理器根据存储选项从存储管理器请求获取 BDO。

   • 如果现有 BDO 是最新的，则会发生缓存命中，并且存储管理器会返回 BDO（转到第 10 步）。
   • 如果 BDO 不存在或过时，则会发生缓存失误，并且存储管理器不会返回 BDO（转到第 6 步）。

6. 业务数据管理器向外部服务发出（异步）请求，以获取最新数据。

   • 如果请求失败，业务数据管理器会重用过时的 BDO（若有）（转到第 9 步）。
   • 如果请求成功，业务数据管理器会处理最新数据响应（转到第 7 步）。

7. 业务数据管理器创建业务数据对象 (BDO)。

8. 业务数据管理器在 BDO 中填充最新数据。

9. 业务数据管理器根据存储选项要求存储管理器存储 BDO。

10. 业务数据管理器将 BDO 返回给显示组件。

11. 显示组件与 BDO 绑定，并呈现数据。

另请参阅

• SharePoint Online 性能优化简介
• 调整 SharePoint Online 性能
• 了解如何在 SharePoint Online 中生成快速响应的 SharePoint 门户（第 9 频道视频）
• 生成 SharePoint Online 门户