Guess.js (alpha)

用于在 Web 上实现数据驱动型用户体验的库和工具。

快速入门

针对 Webpack 用户：

:black_circle: 数据驱动的打包

安装并配置 GuessPlugin —— Guess.js 的 Webpack 插件，它可以尽可能地为您自动化设置流程。

如果您希望单独试用我们提供的模块，packages 目录下包含三个包：

• ga —— 一个用于从 Google Analytics API 获取结构化数据的模块，以了解用户的导航模式。
• parser —— 一个提供 JavaScript 框架解析功能的模块。它为 Guess Webpack 插件中实现的路由解析功能提供了支持。
• webpack —— 一个用于在您的应用中设置预测性预取的 Webpack 插件。它会使用 ga 和 parser 模块，并提供大量选项来配置预测性预取在您的应用中如何工作。

针对非 Webpack 用户：

:black_circle: 数据驱动的加载

我们的 适用于静态站点的预测性预取 流程提供了一组步骤，您可以按照这些步骤将基于 Google Analytics API 的预测性预取集成到您的网站中。

该仓库利用 Google Analytics 数据来确定用户从当前页面最有可能访问的下一个页面。客户端脚本（您需要将其添加到您的应用中）会向服务器发送请求，获取应预取页面的 URL，然后提前加载该资源。

了解更多

Guess.js 是什么？

Guess.js 提供库和工具，以简化基于预测性数据分析的方法，从而改善 Web 上的用户体验。这些数据可以来自多种来源，包括分析数据或 机器学习 模型。Guess.js 的目标是降低在所有现代网站和应用程序中采用和应用这种思路的门槛，包括为流行的工作流构建库和工具。

将预测性数据分析思维应用于网站可以在多种场景中发挥作用：

• 预测用户接下来可能访问的页面（或多个页面），并提前预取这些页面，从而提升用户感知到的页面加载性能并提高用户满意度。
  • 页面级别：预渲染/预取最有可能被访问的下一个页面。
  • 包级别：预取与前 N 个页面相关的代码包，在每次页面跳转时，对当前页面的所有相邻页面按访问概率降序排序，并根据当前网络的有效类型，为前 N 个页面获取相应的资源（JavaScript 块）。
• 预测用户接下来可能想要查看的内容（文章、产品、视频），并据此调整或过滤用户体验。
• 预测单个用户更有可能与哪些类型的组件进行交互（例如游戏），并利用这些数据打造更加个性化的体验。

通过在整个生态系统的不同接触点上开展协作，以便轻松应用数据驱动的方法，我们希望能够标准化常见的基础设施组件，从而最大限度地提高它们在不同技术栈中的适用性。

我们希望解决的问题

• 使用 <link rel=prefetch> 进行未来导航预取的开发者，很大程度上依赖于手动分析描述性指标来决定应该预取哪些内容。
• 这些决策通常是在某个特定时间点做出的，并且：
  • (1) 很少会随着数据趋势的变化而重新评估；
  • (2) 预取策略的应用范围非常有限。许多实现仅对首页或少数几个关键页面进行预取，而对于网站上的其他潜在入口页面则不会采取类似措施，这可能导致性能优化机会被忽略；
  • (3) 决策过程中需要对所用数据有较高的置信度，否则开发者可能会担心浪费带宽而不采用预取技术。目前，<link rel=prefetch> 仅在 Chrome 总页面加载次数的 5% 中使用，但这一比例仍有提升空间。
• 对于普通 Web 开发者而言，实现预测性分析过于复杂。
  • 大多数开发者并不熟悉如何利用 Google Analytics API 来估算用户接下来访问某页面的概率。我们目前缺乏：
  • (1) 页面级别的解决方案：一种开箱即用的客户端方案，用于预取用户可能访问的页面；
  • (2) 打包级别的解决方案：一组插件或工具，能够与当今的 JavaScript 打包工具（如 webpack）协同工作，将导航路径聚类并生成预取后可更快加载的代码块或 bundle。
• 大多数开发者尚未了解 机器学习 的工作原理。他们通常：
  • (1) 不清楚如何（以及为何）将机器学习集成到现有的 Web 技术栈中；
  • (2) 对 TensorFlow 的价值主张，或者像 CloudML 引擎这样的解决方案的具体定位感到困惑。我们有机会简化这些技术的使用门槛。
• 在这一领域，一流的、低门槛的解决方案仍在逐步涌现，但对于没有机器学习或数据科学背景的 Web 开发者来说，仍然不够易用。
  • IIH Nordic 的 机器学习与云结合：智能预取
    • 像 Google Tag Manager 这样的标签管理器，可以将页面内容与跟踪内容使用情况的代码解耦，从而允许 Web 分析人员在不中断站点运行的情况下实时升级跟踪代码。标签管理器提供了一种通用的代码注入方案，可用于部署智能预取功能。其优势在于：构建模型所需的分析数据直接来自标签管理器；我们还可以将实时数据发送至预测服务，而无需额外的跟踪器开销。只需在 GTM 安装中添加几段 IIH Nordic 提供的代码，站点便能开始预取下一页的资源，并追踪加载时间的节省效果。
    • IIH Nordic 将预测预取模型部署为一个 Web 服务，当用户访问新页面时，浏览器会向该服务发起查询。该服务会响应每个请求，并充分利用 Google Cloud、App Engine 和 Cloud ML 等服务。他们的解决方案会选择最准确的模型，选项包括 马尔可夫模型 或更常见的基于 TensorFlow 的深度神经网络。
    • 由于用户行为会随时间变化，预测模型需要定期更新（训练）。训练模型的过程涉及收集和转换数据，并相应地调整模型参数。IIH Nordic 利用 Google Cloud 从客户的分析服务中提取数据，将其存储到 BigQuery 中的私有数据桶内。他们对这些数据进行处理、训练和测试预测模型，从而无缝更新预测服务。
    • IIH Nordic 建议小型或流量较小的站点每月更新一次模型；而大型站点，尤其是新闻网站，则可能需要每天甚至每小时重新训练一次。
    • 在云端训练机器学习模型的好处在于易于扩展，可以根据需要随时增加机器、GPU 和处理器等资源。
  • Minko 的 机器学习驱动的打包：JavaScript 工具的未来

首要优先级：通过数据驱动的预取提升性能

Guess.js 的首要任务将是通过内容的预测性预取来提升 Web 性能。

基于任意起始页面，构建用户可能访问的页面模型，该方案可以计算用户访问下一个页面或一组页面的可能性，并在用户仍在浏览当前页面时提前预取相关资源。这样有望提升后续页面的加载性能，因为目标页面很可能已经存在于用户的缓存中。

预测性预取的可能方法

为了预测用户接下来最有可能访问的页面，解决方案可以使用Google Analytics API。通过分析Google Analytics中的会话数据，可以构建一个模型来预测用户在网站上下一步最可能访问的页面。这种会话数据的优势在于它能够随时间动态更新，因此即使用户的导航路径发生变化，预测结果也能保持最新。

有了这些数据，预取引擎可以在HTML中插入<link rel="[prerender/prefetch/preload]">标签，以加快下一次页面请求的加载速度。在一些测试中，例如Mark Edmondson的使用R语言加速页面加载，这种方法使页面加载时间提升了30%。Mark在其研究中采用的方法是利用GTM标签和机器学习来训练页面预测模型。这一思路也在他的另一篇文章机器学习与云结合——智能预取中得到了延续。

尽管这种方法可行，但其具体实现方式略显复杂。另一种更简单的方式是从Google Analytics API获取准确的预测数据。只需运行一份包含页面和前一页面路径维度，以及页面浏览量和退出次数指标的报告，就能获得足够的数据，为最受欢迎的页面配置预取功能。

机器学习在预测性预取中的应用

机器学习可以帮助提高解决方案预测的整体准确性，但在初始实现中并非必需。可以通过训练模型来识别用户可能访问的页面，并随着时间的推移不断优化该模型，从而实现预测性预取。

深度神经网络尤其擅长挖掘可能导致用户选择某一页面而非另一页面的复杂因素，特别是在我们希望针对特定用户或“普通/平均”用户分别制定预取策略时。从处理固定的页面序列（前一页、当前页、下一页）入手可能是最容易的起点。这意味着需要为你的文档集构建一个专属模型。

模型更新通常定期进行，因此可以设置每晚或每周的任务，根据新的用户行为刷新模型。虽然也可以实现实时更新，但这可能会比较复杂，因此定期更新可能就足够了。设想一种通用的用户行为模式模型，它可以基于训练好的状态集合、Google Analytics数据，或者通过自定义描述由插件添加到路由器中，从而使网站具备预测性预取未来页面的能力，进而提升页面加载性能。

推测性预取的可能方法

页面加载时的推测性预取

推测性预取可以在页面加载时预先获取用户可能导航到的页面。这需要事先了解某个页面后续所需页面或页面集合的概率，或者有一个能够基于数据驱动确定这些概率的训练模型。

页面加载时的预取可以通过多种方式实现：例如，将资源预取的时机交由用户代理决定（如以低优先级使用<link rel=prefetch>），在页面空闲时段（通过requestIdleCallback()）执行，或在其他指定的时间间隔内进行。整个过程无需用户进一步交互。

当链接进入视口时的推测性预取

当页面中的链接出现在视口中时，页面可以开始推测性地预取相关内容，这表明用户很可能点击这些链接。

Gatsby就采用了这种方法（它使用React和React Router）。他们的具体实现如下：

• 在支持IntersectionObserver的浏览器中，每当一个<Link>组件不再可见时，该链接就会为所指向的页面投出一票；每次投票的权重会略微降低，以便优先预取页面顶部的链接。
• 例如，如果某个页面被多次链接，其投票计数就会增加，预取器会优先选择得票最高的页面并开始预取相关资源。
• 为了减少与页面内容加载对带宽的竞争，每次只预取一个页面（在高速网络环境下通常不会有问题）。如果用户访问了一个尚未完全下载资源的页面，预取操作会暂停，直到页面加载完毕，以确保用户等待时间尽可能短。

用户交互时的推测性预取

当用户表现出对某些内容的兴趣时，页面可以开始推测性地预取相关资源。这种兴趣的表现形式多种多样，比如用户将鼠标悬停在某个链接上，或停留在会引导他们跳转到另一个页面的UI区域。一旦浏览器检测到明确的兴趣信号，就可以立即开始获取目标页面的内容。JavaScript库InstantClick就采用了类似的做法。

风险

数据消耗

与任何提前预取内容的机制一样，这一方法需要非常谨慎地使用。对于数据流量有限的用户来说，提前加载页面可能并不会带来太多好处，甚至会迅速消耗掉他们的流量。站点或解决方案可以采取一些措施来缓解这一问题，例如尊重 Save-Data 头部信息。

预取不希望的页面

预取“注销”页面通常是不理想的。同样地，任何在页面加载时触发操作的页面（如一键购买）也不宜被预取。为提高预取页面的实用性，解决方案可以维护一个永远不会被预取的 URL 黑名单。

Web 标准

rel=prerender 的未来

过去曾有一些尝试通过 <link rel=prerender> 来实现类似的功能。目前，Chrome 团队正在探讨是否要弃用 rel=prerender，转而采用 NoStatePrefetch——这是一种更为轻量化的机制，它仅将资源预取至 HTTP 缓存中，而不使用 Web 平台的其他状态信息。因此，解决方案需要考虑是依赖于 rel=prerender 的替代方案，还是采用 prefetch、preload 或其他方式。

NoStatePrefetch 和 Prefetch 之间存在两个关键区别：

1. nostate-prefetch 是一种机制，而 <link rel=prefetch> 则是一个 API。nostate-prefetch 可以通过其他入口点被触发，例如地址栏预测、自定义标签页以及 <link rel=prerender>。

2. 实现方式不同：<link rel=prefetch> 只会预取单个资源，而 nostate-prefetch 在此基础上还会对该资源运行预加载扫描器（在一个全新的渲染进程中），发现其中的子资源并一并进行预取（但不会递归调用预加载扫描器）。

相关数据分析

在这个领域中有三种主要的数据分析类型值得了解：描述性分析、预测性分析和 prescriptive 分析。每种分析类型相互关联，可以帮助团队从不同角度挖掘洞察。

描述性分析——发生了什么？

描述性分析将原始数据汇总并转化为人类可理解的形式。它可以回顾过去的事件，无论这些事件发生的时间如何。通过描述性分析，团队可以从历史行为中学习，并利用这些经验来影响未来的决策。例如，描述性分析可以确定用户曾经访问过哪些页面，以及在给定起始页面的情况下，他们通常会遵循怎样的导航路径。

预测性分析——接下来会发生什么？

预测性分析旨在“预测”未来可能发生的事情。它帮助我们理解未来趋势，并基于数据提供可操作的见解。预测性分析能够评估某一未来结果发生的可能性及其潜在价值。需要注意的是，没有任何算法能够完全准确地预测未来事件，但我们可以通过尽可能多地利用现有信号来提升预测的准确性。预测性分析的基础是基于数据计算出的概率。例如，预测性分析可以根据任意起始页面，预测用户接下来可能会访问的页面或页面集合。

Prescriptive 分析——我们应该怎么做？

Prescriptive 分析不仅能够预测未来可能发生的事情，还能进一步提出具体的行动建议，以引导团队走向解决方案。它试图量化未来决策可能产生的影响，在决策实施之前就给出关于可能结果的建议。Prescriptive 分析的目标不仅仅是预测“将会发生什么”，而是深入探究“为什么会发生”，并针对这些预测提出可行的行动方案，以便更好地利用这些洞察。例如，Prescriptive 分析可以预测用户接下来会访问的页面，同时还可以建议一些个性化设置，以充分利用这一预测信息。

相关预测模型

马尔可夫模型

在预取问题领域，预测模型的核心目标是在给定某一页面请求的情况下，识别用户接下来可能需要的请求。这样，服务器或客户端可以预先获取下一组页面，并尽量确保这些页面在用户直接访问之前已缓存在其缓存中。其目的是减少整体加载时间。如果实施得当，这一技术能够缩短页面访问时间和延迟，从而提升整体用户体验。

马尔可夫模型已被广泛用于研究和理解随机过程（随机概率分布）[Ref, Ref]。研究表明，它们非常适合建模和预测用户的浏览行为。这类问题的输入通常是用户或一组用户（全站范围）访问的网页序列，目标是构建可用于建模和预测用户最有可能接下来访问哪些页面的马尔可夫模型。马尔可夫过程的状态代表已访问的页面，边则表示状态之间的转移概率，这些概率是从分析日志中的给定序列计算得出的。训练好的马尔可夫模型可以根据前k个状态来预测下一个状态。

在某些应用中，一阶马尔可夫模型在预测用户浏览行为时并不够准确，因为它们并不总是回溯历史以区分已观察到的不同模式。这也是为什么通常会使用高阶模型的原因之一。然而，高阶模型存在状态空间复杂度高、覆盖范围较窄以及有时预测准确率降低等局限性。

全K阶马尔可夫模型

一种解决该问题的方法[Ref]是训练不同阶数的马尔可夫模型，然后在预测阶段加以使用。这种方法在该Ref中提出的全K阶马尔可夫模型中得到了尝试。不过，这样做可能会使状态空间复杂度进一步恶化。另一种方法是识别频繁访问的模式（最长重复子序列），并利用这些序列进行预测。尽管这种方法可以将状态空间复杂度降低一个数量级，但可能会降低预测准确率。

选择性马尔可夫模型

选择性马尔可夫模型（SMM）只存储模型中的一部分状态，也被提出作为解决状态空间复杂度权衡问题的一种方案。它首先从全K阶马尔可夫模型开始，随后采用后剪枝方法去除那些预计无法提供准确预测的状态。最终得到的模型具有与全K阶模型相同的预测能力，同时拥有更低的状态空间复杂度和更高的预测精度。在Deshpane和 Karpis的研究中，探讨了在预测前对模型中的状态进行剪枝的不同标准（频率、置信度、误差）。

语义剪枝的选择性马尔可夫模型

在Mabroukeh和 Ezeife的研究中，对富含语义信息的1阶和2阶马尔可夫模型的性能进行了研究，并将其与高阶SMM及语义剪枝的SMM进行了比较。他们发现，语义剪枝的SMM比按频率剪枝的SMM小16%，且预测准确率几乎相当。

聚类分析

通过观察用户的导航模式，我们可以分析其行为。这种方法需要访问用户会话标识，将会话聚集成相似的簇，并基于当前及之前的访问模式建立预测模型。该领域的许多先前工作都依赖于诸如K-means聚类之类的聚类算法，并结合欧几里得距离来提高预测的置信度。然而，使用K-means的一个缺点是难以确定聚类的数量，初始中心点的选择也较为随机，而且页面访问顺序往往未被充分考虑。Kumar等人对此进行了研究，提出了一种改进的Levenshtein距离的层次聚类方法，结合基于访问时间长度和频率的PageRank，以及高阶马尔可夫模型来进行预测。

研究综述

以下章节中引用的许多论文都围绕马尔可夫模型、关联规则和聚类展开。我们重点关注那些突出与演化页面预测准确性相关的模式发现工作的文献。

Sarukkai [2000] “利用马尔可夫链进行链接预测与路径分析”。

该研究使用一阶马尔可夫模型来建模用户请求的网页序列，以预测他们接下来可能访问的页面。马尔可夫链使系统能够根据先前的状态动态地模拟导航日志中观察到的 URL 访问模式。为每个用户训练一个“个性化”马尔可夫模型，并用于预测用户的未来会话。然而，在实践中，为每个用户构建独特的模型成本过高，且当网站拥有庞大的用户群体时，这种扩展的成本会变得更加棘手。

Chun-Jung Lin [2005] “利用隐马尔可夫模型预测网络购物用户的意图”

这是首篇探讨隐马尔可夫模型（HMM）的论文。作者收集了 Web 服务器日志，对数据进行了修剪，并补全了用户浏览过的路径。基于 HMM，作者构建了一个专门用于 Web 浏览的模型，用以实时预测用户是否具有购买意图。此外，还研究了相关措施，例如加快操作速度及其在购物模式下的影响。

Elli Voudigari [2010–2011] “网页排名预测框架”。

提出了一种基于页面历史排名来预测其排名位置的框架。假设有一组连续的 Top-K 排名，作者基于不同的方法论识别出预测因子。预测质量通过预测排名与实际排名之间的相似度来量化。研究者在一个真实的大规模数据集上，针对全局和基于查询的 Top-K 排名进行了详尽的实验。文中还介绍了一系列用于比较 Top-K 排行榜的现有相似度度量，其中包括一种新颖的方法。

Mogul [1996] “利用预测性预取提升万维网延迟”。

提出使用 N 跳马尔可夫模型来预测用户接下来可能访问的网页。该方法将用户当前的访问序列与其历史 Web 访问序列进行匹配，以提高预取的预测准确率。

Borges, Levene [2007] “评估变长马尔可夫链模型在用户 Web 导航会话分析中的应用”。

提出了一种基于动态聚类的方法，以提高马尔可夫模型在表示一组 Web 导航会话时的准确性。该方法采用状态克隆的概念，通过分离对应二阶概率存在差异的入链，从而复制状态。所提出的方法还包括一种聚类技术，用于将具有相似二阶概率的入链分配到同一克隆中。

Banu Deniz Gunel [2010] “研究持续时间、页面大小和频率对基于 PageRank 算法的下一页推荐的影响”。

将 PageRank 算法的应用扩展到了多个导航属性：页面大小、页面停留时间、页面间过渡的持续时间（即连续两次访问页面的时间间隔）、页面及过渡的频率。定义了基于持续时间的排名（DPR）和基于受欢迎程度的 PageRank（PPR）。作者结合持续时间信息，考察了页面和过渡的受欢迎程度，并将其与页面大小和访问频率相结合。通过利用页面的受欢迎程度，本文试图改进传统的 PageRank 算法，并在给定 Top-N 值的情况下构建下一页预测模型。

参考文献

• 使用 R 加速页面加载
• 利用 Google Analytics 预测点击
• Gatsby 的 Link 组件
• Eve Dynamic Prerender 插件
• InstartLogic - 多页面预测性预取
• Sirko Engine —— 依赖 Service Worker

团队

Minko Gechev

Addy Osmani

Katie Hempenius

Kyle Mathews

Guess.js 快速上手指南

环境准备

• Node.js 10.0+（建议使用 LTS 版本）
• Google Analytics 账号（用于获取 API 数据）

安装步骤

# 使用国内镜像加速安装
npm install -g cnpm --registry=https://registry.npmmirror.com
# 安装 Guess.js Webpack 插件
cnpm install guess-webpack --save-dev

基本使用

1. 在 webpack.config.js 中添加插件配置：

const GuessPlugin = require('guess-webpack').default;

module.exports = {
  // ... 其他配置
  plugins: [
    new GuessPlugin({
      ga: {
        viewId: 'YOUR_VIEW_ID', // 替换为你的 Google Analytics View ID
      }
    })
  ]
};

2. 运行构建命令：npm run build
   （构建后将自动基于 Google Analytics 数据预加载用户可能访问的页面）