面向人民的Web性能自动化论文

8250面向人民的Web性能自动化0Robin Marx �0哈塞尔特大学 -tUL数字媒体专业中心，比利时迪彭贝克，robin.marx@uhasselt.be0摘要0Web性能对用户体验非常重要，可以对网页收入产生重大影响。虽然有许多已建立的Web性能优化（WPO）方法，但我们迄今为止的工作清楚地表明，新的网络协议、优化的浏览器和尖端的Web标准对已知的最佳实践可以产生重大影响。此外，仍然有可以利用的低成本果实，即根据用户环境（即当前设备、网络、浏览器）和用户偏好（例如，文本阅读与多媒体体验）个性化性能。在我们的博士项目中，我们努力将这些用户特定的元数据集成到现有和新的自动化WPO技术的动态配置中。中间服务器可以（预）生成经过优化的网页版本，然后根据用户环境和偏好进行选择。附加元数据也传递给浏览器，以改进浏览器的性能，并用于引导新的网络协议以加快页面资源的增量传递。我们使用Speeder平台进行全因子客观测量和使用一系列群体的主观用户研究来评估我们的方法对最终用户的适用性。我们的目标是提供关于如何针对特定用户调整WPO的见解，以期望引导出能够实现此行为的新Web标准。0CCS概念0• 网络 → 网络协议设计; 传输协议; 网络性能评估; 应用层协议;中间盒/网络设备; • 以人为本的计算 → 用户研究; 上下文设计; •社会和专业主题 → 自动化; • 软件及其工程 → 软件性能;0关键词0Web性能优化（WPO）; 页面加载时间（PLT）; 用户环境;QUIC协议; 分布式系统; Web浏览器; 网络; 系统自动化0� Robin Marx是FWO的SB博士研究员，研究基金会 -佛兰德地区，项目编号1S02717N。本博士项目由Peter Quax教授和WimLamotte教授指导。0本文发表在知识共享署名4.0国际许可证（CC BY4.0）下。作者保留在个人和公司网站上传播作品的权利，并附上适当的归属。WWW '18Companion，2018年4月23日至27日，法国里昂，© 2018IW3C2（国际万维网会议委员会），根据知识共享CC BY 4.0许可证发布。ACM ISBN978-1-4503-5640-4/18/04。https://doi.org/10.1145/3184558.31865700ACM参考格式：Robin Marx。2018。面向人民的Web性能自动化。在WWW '18Companion：2018年Web会议伴侣，2018年4月23日至27日，法国里昂。ACM，纽约，纽约，美国，5页。https://doi.org/10.1145/3184558.318657001 问题陈述0现代网站和基于Web的应用程序在移动设备和蜂窝网络上加载和交互通常很慢。这种次优的性能对用户来说非常烦人；事实上，即使页面加载时间稍微增加一点，也会对保留、转化和电子商务收入产生可测量和一致的影响[30]。微软和LinkedIn研究人员的一项研究[17]发现，“通过改善服务器性能10毫秒的工程师[...]足以支付他全年的成本。每一毫秒都很重要。”。我们不能仅仅依靠网络和设备速度的进步来确保用户随着时间的推移更加满意，因为近年来网页和用户代理的复杂性以惊人的速度增加[14]。鉴于这些挑战，Web性能优化（WPO）的现有技术在研究（§2）和工业界都已经得到了很好的建立。许多常青技术（例如，压缩、未使用的代码消除）可以在服务器端自动应用，无论是在预处理步骤中还是在运行时（例如，modpage-speed）。先进的后端设置可以更进一步，还可以使用（有限的）用户环境（例如，当前网络连接类型、设备）来提供进一步的定制优化[1]，或者在基于云的浏览器的情况下，深度重写网页的表示[8，36]（尽管这可能以其他方式对用户体验产生负面影响）。在用户端，现代浏览器使用先进的启发式算法[24]来优化常见情况，并为开发人员提供API（例如，预加载指令）来嵌入其他性能提示。加速移动页面（AMP）项目将自定义HTML/JavaScriptAPI与基于云的托管相结合，为一些用例（例如，新闻文章）提供了改进的性能。除了这些自动化技术外，开发人员还可以使用各种合成监视和分析工具（例如，Webpagetest.org，Sitespeed.io）来手动评估性能瓶颈。另一方面，实时用户监控（RUM）解决方案从用户设备上的实际页面加载中收集性能信息，提供更真实的见解。这些额外的数据通常需要手动调整单个页面的性能，因为自动化方法会犯错误或使用过于保守的启发式算法。0尽管存在这些自动化方法和手动缓解措施，但在互联网环境的最近和即将发生的几个变化以及最终用户的不断变化的期望面前，它们可能不足以保证最佳性能。我们希望0博士生论坛 WWW 2018，2018年4月23日至27日，法国里昂8260重点关注三个主要领域，这些领域对现有性能最佳实践可能产生重大影响，并需要更新已建立的方法：0• 区域1（A1）：新的网络协议最近标准化的HTTP/2和即将推出的QUIC[5]协议将取代老化的HTTP/1.1。虽然它们非常注重性能，但先前的工作（§2.2，§5）表明，很难对新协议功能进行微调，不同的实现可能会对性能产生很大影响。因此，HTTP/2的最佳实践尚未出现，一些大型网站（例如亚马逊，优步，Netflix）尚未（完全）转向新协议。我们在这个领域的主要研究问题是QUIC带来了哪些新机会和可能的陷阱，以及如何最好地利用它们。•区域2（A2）：不断增长的用户上下文异质性随着设备和网络变得更快，网页复杂性也相应增加。在较慢的网络上，移动设备通常无法为这些更复杂的页面提供适当的页面加载性能。此外，用户代理实现正在多样化，Firefoxv57进行了完全改版，UC浏览器在亚洲国家取代了Google Chrome[25]。现有的（自动化）方法通常不允许根据用户上下文调整优化，因此许多网站继续提供仅两个甚至一个（响应式）版本的网站，迫使低端智能手机下载和处理与高端台式机相同的资源。我们在这里的主要研究问题是如何调整新的和现有的WPO技术以更好地适应异质用户上下文。• 区域3（A3）：主观用户偏好关于性能，最终用户的体验可能高度主观和个人化（§2.4）。例如，Opera Mini[8]用户享受更快的页面加载速度，但会失去运行时JavaScript执行的权衡。此外，渐进式JPG图像可能会让一些用户感到烦恼，甚至感觉更慢[10]。用户还希望以其他方式个性化其Web浏览体验（例如，Brave浏览器提供了一种不同的广告服务模式）。然而，几乎没有现有的性能方法考虑（明确的）个人用户偏好，而是将所有用户视为相同。例如，现代浏览器包括“阅读模式”，但只有在下载和处理所有多余内容之后才启用此模式。我们的主要目标是研究如何利用（明确的）用户偏好来指导使用的WPO技术（的组合），以生成更好的个性化体验。02 现状 2.1 页面加载瓶颈0大量研究已经集中在识别网页加载行为的主要瓶颈上。从WProf研究[35]开始，该研究确定了资源相互依赖性和加载顺序如何定义“关键路径”，几个系统通过操纵这些加载顺序和资源获取优先级（例如，Klotski [4]，Polaris [22]，Vroom [28]和Meta-Push[13]）实现了令人印象深刻的性能提升。这些作品都使用额外的元数据，无论是在浏览器端还是服务器端，以进一步优化加载性能。0同时，其他工作特别关注移动性能，并经常发现设备的计算能力而不是网络[37]通常是瓶颈[6]，指出“我们需要从根本上重新思考移动浏览器的优化”[21]。然而，许多这些研究通常只考虑单个浏览器和/或几年前的情况，鉴于浏览器实现的快速演变，可能需要重新评估。02.2 网络协议0新的HTTP/2协议近年来一直是研究的主题。可悲的是，我们的调查显示，许多研究[7,9]产生了相互矛盾的结果（例如，服务器推送应该非常节制地使用[3,41]还是积极地使用[27]）。我们认为，这主要是由于个别测试设置中的有限网络仿真多样性和研究人员测试不同版本的提议协议所致。随着新的、更灵活的QUIC协议的发展[5]，我们预计这些矛盾将继续存在，这也得到了Kakhki等人最近的工作的证实[15]。幸运的是，许多出版物也同意，根据某些网络参数（例如，数据包丢失），不同的方法（例如，打开额外的TCP连接[11]）可以实现更好的性能，这也得到了我们自己实验的证实（§5）。由于QUIC协议在协议栈的所有层面上都允许更大的自由度，我们设想可以使用基于网络参数的深度配置来调整性能，这也得到了Qian等人的类似工作的暗示[26]。02.3 代理和基于云的浏览0许多现有的WPO工作都是通过使用中间代理或基于云的服务器来实现和评估的，这些服务器有助于提供加速。例如，Shandian[36]类似于Opera Mini[8]，因为它在服务器端执行JavaScript的（部分）操作。其他工作将资源捆绑在一起[23]，操纵资源加载顺序[18,28]或预取和预缓存网站资源[29,32]。这表明在我们自己的努力中使用这样的中间服务器是一个有效的方法（§3，步骤2）。02.4 主观性能指标0WPO技术通常使用客观指标进行测量，这些指标可以从Web浏览器中获得，也可以通过观察页面的视觉加载进度获得。然而，最近的研究已经明确表明，这些指标与实际主观用户对页面“准备就绪”的意见之间的相关性很差[16, 33,42]，而且这些意见往往高度个性化。相关的人机交互研究还表明，（自动）个性化用户界面可以缩短任务解决时间[31]。这些发现强调了将（明确的）用户偏好纳入WPO设置的潜力。03 提出的方法0我们设想一个传统的设置，其中一个中间服务器（§2.3）优化从源接收到的网页及其资源，可以提前或在接收请求时进行优化。这种设置类似于大多数内容分发网络（CDN）使用的模型，因为我们设想我们的工作对该行业最感兴趣。0PhD Track WWW 2018，2018年4月23日至27日，法国里昂8270图1：我们提出的整体系统概述。步骤3、4和5包括我们主要的设想贡献。0我们在图1的步骤3、4和5中的主要贡献。我们方法的关键是增加用户代理和服务器之间与性能相关的元数据的双向通信（步骤3和4）。这些额外的信息使我们能够选择更合适、与上下文相关的优化（步骤2），并使用适合当前上下文的协议设置来调整实际页面数据的传输（步骤5），例如使用多个连接取决于网络质量（§2.2）。反过来，浏览器可以使用应用优化的元数据来改进其启发式算法和内部处理（步骤4、5）。优化见解可以回馈给开发人员（步骤6），从而导致更优化的初始网页（步骤1）。步骤3：用户上下文和偏好（A2和A3）直到最近，浏览器相对较少地暴露用户上下文和偏好。随着关于客户端提示（例如，指示屏幕大小）、NetInfoAPI（提供当前网络质量参数的估计）、内存压力API和缓存摘要的持续工作，这种情况已经改变。然而，其中一些选项仍然是非常实验性的，它们的最佳使用方法尚不清楚。此外，尚未提供明确的用户偏好，例如指示计量（蜂窝）连接、选择广告类型（例如视频还是纯文本）、强制阅读模式、禁用动画或表达只延迟加载图像/视频的偏好。在这里，主要的挑战是评估这些新API的数据的有用性，以及如何尽快将这些数据与服务器通信。此外，我们必须考虑哪些用户偏好最有用，以及如何以可用、安全和注重隐私的方式将其集成到浏览器中。步骤4：页面优化元数据（A2）浏览器可以从具有关于网页内容和应用优化的额外元数据中受益。目前，通过资源提示或服务器推送[13]等方法已经部分实现了这一点，但更高级的选项，如明确的优先级提示，尚未标准化。总的来说，浏览器通常不知道页面将提前包含什么，并且必须迭代地发现子资源及其内容。这迫使浏览器使用（次优的）启发式算法，并对其方法过于保守。如果浏览器有更详细的元数据（例如，每个资源的文件大小，资源的完整列表及其对页面的概念贡献），它可以显著提高性能，这已经在相关的工作中提到过。0工作（§2.1，§5）。此外，如果浏览器100％确定网页不会使用给定的JavaScript / CSSAPI或以给定的已知方式结构化，它可能选择更快的执行路径，因为较慢的子系统可以完全跳过。尽管这些想法在以前的工作中已经得到了探索，但我们旨在进一步评估这些可能性，特别是针对较新的Web标准。第5步：优化的网络传输（A1）尽管较新的网络协议相对于旧的HTTP /1.1提供了明显的优势，但很明显，单个配置在所有设置中都不会产生最佳结果。例如，HTTP /2的单个连接会遭受数据包丢失，并且通过使用多个并行连接可以提高性能[11，19]。对于其他新功能，例如服务器推送和优先级，尚不清楚最佳实践是什么以及它们如何受用户上下文的影响[3，40]。新的QUIC协议在用户空间重新实现了TCP的许多功能，因此允许根据当前网络条件选择不同的拥塞避免算法等更动态的配置。由于QUIC正在标准化的过程中，因此它是一个活跃研究领域，基于较新的迭代版本，可能需要对旧版本QUIC的现有研究进行细化[15]。我们认为QUIC的设计允许进行许多可调整的性能优化，比其他类似的协议更多。第2步：自动资源重写（A1和A3）虽然网络传输配置主要是根据用户上下文进行操作，但广泛的资源重写也可以用于遵守明确的用户偏好。我们设想一个中间服务器，主要选择和组合已建立的自动化技术，根据用户上下文和选择的性能偏好（例如，具有非常简单布局的阅读器模式版本，延迟加载图像的版本，资源压缩/带宽优化的版本，仅用于GoogleChrome的版本等）来（预）生成不同的网页表示。这个中间服务器还可以生成与优化相关的元数据（例如，资源的优先级列表），以在第4步中与浏览器进行通信，或者用于第5步中的服务器推送等方面。虽然以前的工作在这方面包括了几种方法[22，36]，但我们预计还需要进行额外的工作来生成附加的元数据，并研究开发人员如何提供这些元数据。0PhD Track WWW 2018年4月23日至27日，法国里昂82804 方法 4.1 计划的发展0自定义QUIC和HTTP /2服务器我们目前正在开发基于NodeJS的自定义QUIC和HTTP /2服务器。这将使我们能够深入了解协议，并更快地动态测试QUIC协议中的几个方面和（拥塞控制）算法，并将它们与其他默认实现进行比较。中间服务器设置我们将实现一个中间服务器，将许多现有的自动WPO技术整合在一起。然后，这些技术将组合成几个“配置文件”，以符合特定的用户上下文和偏好组合。这些配置文件可以用于预取和预生成流行网站的优化版本，也可以实时应用。这些配置文件还可以通过使用Speeder框架（§4.2）测试其输出并丢弃次优排列来自动迭代地进行进一步的细化。自定义Web浏览器为了根据接收到的元数据启用快速路径处理，并允许传递其他用户上下文和特别是明确的用户偏好到服务器，将需要创建现有Web浏览器的自定义版本。为此，我们计划主要关注开源的Chromium和Firefox浏览器之一/或两者，首先进行广泛的源代码审查以确定可能的改进，然后逐步创建几个自定义版本。这最终将导致一个用于长期运行的主观用户研究的版本。04.2 评估设施0Speeder框架用于客观测量我们已经开发了一个名为Speeder的内部测试框架。这个自动化平台可以方便地设置测试并在多个浏览器、物理设备、服务器实现、网络仿真和协议上进行全因子评估。我们使用WebPageTest.org、Sitespeed.io和GoogleLighthouse等工具来收集客观性能指标。该平台包括各种不同的可视化和统计方法来评估收集到的数据（§5）。在这方面，Speeder采用了比类似框架（如mahimahi[23]）更综合的方法，后者通常只关注前端或后端，并很少集成可视化或分析工具。Speeder将允许我们完全控制测试我们自定义的QUIC和浏览器实现。表1显示了当前Speeder的功能。更多详细信息可在https://speeder . edm . uhasselt . be上找到。主观用户研究我们计划进行几项用户研究和问卷调查。首先，我们需要了解可能影响性能的典型用户环境，并了解哪些明确的用户偏好对广泛的终端用户来说是有趣的。其次，我们需要更好地了解为什么主观用户指标经常与客观指标不匹配（§2.4），以及如何处理这个问题。最后，我们将通过真实用户在实际场景中测试集成了高级用户上下文和偏好的最终版本的自定义Web浏览器。由于我们目前在这个领域几乎没有直接经验，我们计划依靠以前的工作（§2.4）和我们在人机交互研究中活跃的本地同事的支持。我们将使用分组0表1：Speeder框架支持的软件、指标和可视化工具（2017年12月）。0协议 HTTP/1.1（明文）、HTTPS/1.1、HTTPS/20浏览器 Chrome（v51 - v63）、Firefox（v45 - v56）0测试驱动程序 Sitespeed.io（v3）、Webpagetest（v3.0）0服务器 Apache（v2.4.20）、NGINX（v1.10）、NodeJS（v6.2.1）、H2O（v2.1）0网络 - DUMMYNET（电缆和蜂窝）- 固定 TCNETEM（电缆和蜂窝）- 动态 TC NETEM（蜂窝）[11]0所有导航计时值[34]、SpeedIndex[39]、其他Webpagetest指标[38]、GoogleLighthouse指标0可视化工具TCP和HTTP/2的数据包时间线，HTTP/2优先级依赖树。记录的指标的箱线图、折线图和CDF图0由学生、志愿的网络性能专业人士和通过MechanicalTurk等平台雇佣的受试者组成。05 结果0我们过去一年的工作已经导致了三篇被接受的出版物和一篇正在等待的综述性期刊出版物。我们的第一篇出版物验证了HTTP/1.1时代的最佳实践在HTTP/2设置中的有效性[19]。我们使用Speeder框架对不同因素进行了广泛分析，发现HTTP/2的性能不仅严重依赖于网络质量，还依赖于各个浏览器的内部实现和处理。因此，不同的HTTP/2配置（例如使用多个并行连接，更多或更少的资源聚合）可以根据这些上下文参数（§3步骤3,5）来提高性能。我们的结果得到了相关工作[11]的证实，并直接与之前的预期[12]相矛盾。我们的第二篇出版物专注于HTTP/2的资源优先级系统[40]，更清楚地显示了各个浏览器实现之间存在较大差异，并且次优启发式方法可能对性能产生不利影响，进一步证明了对额外元数据的需求（§3步骤3,4,5）。我们是最早深入研究HTTP/2优先级系统的研究之一，我们的结果证实了之前的主要工作[2]，同时提供了对观察到的行为原因的更多见解。我们的第三篇出版物涉及将HTML/CSS页面转换为WebVR兼容表示的技术[20]，这被用作了解浏览器的JavaScript和CSS引擎的基本细节的工具。我们的研究结果表明，这些引擎通常需要保持大量的内部状态来提供奇特的API，这为集成快速路径提供了机会（§3步骤4）。与现有的等效方法相比，我们的实现性能提高了一个数量级。06 结论和未来工作0通过对现有工作的调查和过去一年的努力，我们已经确定了几个在Web性能优化最佳实践方面取得进展的新机会，这些机会基于网络协议和浏览器实现的进展。0博士生论坛WWW 2018，2018年4月23日至27日，法国里昂[1] Victor Agababov, Michael Buettner, Victor Chudnovsky, Mark Cogan, BenGreenstein, Shane McDaniel, Michael Piatek, Colin Scott, Matt Welsh, and BolianYin. 2015. Flywheel: Google’s Data Compression Proxy for the Mobile Web.. InNSDI, Vol. 15. 367–380.[2] TomBergan.2016.BenchmarkingHTTP/2Priorities.Online,https://docs.google.com/document/d/1oLhNg1skaWD4DtaoCxdSRN5erEXrH-KnLrMwEpOtFY/. (October 2016).[3] Tom Bergan, Simon Pelchat, and Michael Buettner. 2016.Rules ofThumb for HTTP/2 Push.Online, https://docs.google.com/document/d/1K0NykTXBbbbTlv60t5MyJvXjqKGsCVNYHyLEXIxYMv0. (2016).[4] Michael Butkiewicz, Daimeng Wang, Zhe Wu, Harsha V. Madhyastha, and VyasSekar. 2015. KLOTSKI: Reprioritizing Web Content to Improve User Experienceon Mobile Devices. In Proceedings of the 12th USENIX Conference on NetworkedSystems Design and Implementation (NSDI’15). 439–453.[5] Gaetano Carlucci, Luca De Cicco, and Saverio Mascolo. 2015. HTTP over UDP:an Experimental Investigation of QUIC. In Proceedings of the 30th Annual ACMSymposium on Applied Computing. ACM, 609–614.[6] Calin Cascaval, Seth Fowler, Pablo Montesinos-Ortego, Wayne Piekarski, MehrdadReshadi, Behnam Robatmili, Michael Weber, and Vrajesh Bhavsar. 2013. ZOOMM:a parallel web browser engine for multicore mobile devices. In ACM SIGPLANNotices, Vol. 48. ACM, 271–280.[7] Hugues de Saxcé, Iuniana Oprescu, and Yiping Chen. 2015. Is HTTP/2 reallyfaster than HTTP/1.1?. In Proceedings of the IEEE Conference on ComputerCommunications Workshops. 293–299.[8] Dev.Opera. 2012. Opera Mini and JavaScript. Online, http://dev.opera.com/articles/view/opera-mini-and-javascript/. (2012).[9] Jeffrey Erman, Vijay Gopalakrishnan, Rittwik Jana, and K. K. Ramakrishnan. 2013.Towards a SPDY’ier Mobile Web?. In Proceedings of the 9th ACM InternationalConference on emerging Networking EXperiments and Technologies (CoNEXT’13).303–314.[10] Everts, Tammy. 2014.Progressive image rendering: Good or evil?Online,https://blog.radware.com/applicationdelivery/wpo/2014/09/progressive-image-rendering-good-evil/. (2014).[11] Utkarsh Goel, Moritz Steiner, Mike P Wittie, Stephen Ludin, and Martin Flack.2017. Domain-Sharding for Faster HTTP/2 in Lossy Cellular Networks. arXivpreprint arXiv:1707.05836 (2017).[12] Ilya Grigorik. 2013. High Performance Browser Networking. " O’Reilly Media, Inc.".[13] Bo Han, Shuai Hao, and Feng Qian. 2015. MetaPush: Cellular-Friendly ServerPush For HTTP/2. In Proceedings of the Workshop on All Things Cellular(AllThingsCellular’15). 57–62.[14] Ilya Grigorik and Pat Meenan and Rick Viscomi. 2017. HTTP Archive. Online,http://httparchive.org/. (October 2017).[15] Arash Molavi Kakhki, Samuel Jero, David Choffnes, Cristina Nita-Rotaru, andAlan Mislove. 2017.Taking a long look at QUIC: an approach for rigorousevaluation of rapidly evolving transport protocols. In Proceedings of the 2017Internet Measurement Conference. ACM, 290–303.[16] Conor Kelton, Jihoon Ryoo, Aruna Balasubramanian, and Samir R Das. 2017.Improving User Perceived Page Load Times Using Gaze.. In 14th USENIXSymposium on Networked Systems Design and Implementation (NSDI). 545–559.[17] Ron Kohavi, Alex Deng, Roger Longbotham, and Ya Xu. 2014. Seven rules of thumbfor web site experimenters. In Proceedings of the 20th ACM SIGKDD internationalconference on Knowledge discovery and data mining. ACM, 1857–1866.[18] Xuanzhe Liu, Yun Ma, Xinyang Wang, Yunxin Liu, Tao Xie, and Gang Huang.2017. Swarovsky: Optimizing resource loading for mobile web browsing. IEEE8290网络协议和浏览器实现。我们的目标是以个性化的方式利用这些机会，考虑到深入的用户上下文和明确的用户偏好，改进目前仍然普遍采用的一刀切方法。我们计划在三年内完成博士项目，第一年主要是为我们设置的各个方面做准备：实现和测试QUIC服务器，浏览器源代码审查以及围绕（图像）占位符格式偏好的主观用户研究。第二年将集中整合不同方面到一个单一的设置中，实现中间代理服务器并定义优化配置文件。最后一年将产生最终的定制浏览器版本，由真实用户进行测试和评估。在整个期间，我们还将更新Speeder框架，以便能够测试尽可能多的参数。0参考文献0《移动计算交易》16, 10 (2017). [19]  Robin Marx, Peter Quax, Axel Faes, and WimLamotte. [n. d.]. 连接、嵌入和分片：HTTP/1性能最佳实践在HTTP/2中是否有意义？.在第13届国际网络信息系统和技术会议（WEBIST’17）论文集中. Scitepress. [20]  RobinMarx, Sander Vanhove, Wouter Vanmontfort, Peter Quax, and Wim Lamotte. 2017.DOM2AFrame：将Web重新引入WebVR. 在第17届国际3D沉浸会议（IC3D17）论文集中.IEEE. [21]  Javad Nejati and Aruna Balasubramanian. 2016. 移动浏览器性能的深入研究.在第25届国际万维网会议论文集中. 1305–1315. [22]  Ravi Netravali, Ameesh Goyal,James Mickens, and Hari Balakrishnan. 2016.Polaris：使用精细的依赖跟踪加快页面加载速度.在第13届USENIX网络系统设计与实现会议（NSDI’16）论文集中. 123–136. [23]  RaviNetravali, Anirudh Sivaraman, Somak Das, Ameesh Goyal, Keith Win- stein, JamesMickens, and Hari Balakrishnan. 2015. Mahimahi：用于HTTP的准确记录和重放.在USENIX年度技术会议中. 417–429. [24]  Osmani, Addy. 2017.Chrome中的预加载、预取和优先级. 在线，https://medium .com/reloading/preload-prefetch-and-priorities-in-chrome- 776165961bbf. (2017).[25]  Purnell, Newley. 2018. UC浏览器与谷歌Chrome. 在线，https://www . wsj .com/articles/a-browser-youve-never-heard-of-is-dethroning-google-in-asia-1514808002. (2018). [26]  Feng Qian, VijayGopalakrishnan, Emir Halepovic, Subhabrata Sen, and Oliver Spatscheck. 2015. TM3：无头阻塞的灵活传输层多管道多路复用中间盒.在第11届ACM新兴网络实验和技术会议论文集中. [27]  Sanae Rosen, Bo Han, Shuai Hao,Z Morley Mao, and Feng Qian. 2017.推送还是请求：HTTP/2服务器推送改善移动性能的研究.在第26届国际万维网会议论文集中. 459–468. [28]  Vaspol Ruamviboonsuk, RaviNetravali, Muhammed Uluyol, and Harsha V Madhyastha. 2017.VROOM：使用服务器辅助的依赖解析加速移动Web.在ACM数据通信特别兴趣小组会议论文集中. [29]  Ali Sehati and Majid Ghaderi. 2015.WebPro：一种基于代理的低延迟移动设备浏览方法.在2015年IEEE第23届国际服务质量研讨会上. IEEE, 319–328. [30]  Tammy Everts and TimKadlec. 2017. WPO统计数据. 在线，https://wpostats . com/. (2017). [31]  KashyapTodi, Jussi Jokinen, Antti Oulasvirta, and Kris Luyten. 2018.Familiarisation：使用视觉学习模型重构布局. 在2018年智能用户界面国际会议（IUI）上.ACM. [32]  Jeroen van der Hooft, Stefano Petrangeli, Tim Wauters, Rameez Rahman,Nico Verzijp, Rafael Huysegems, Tom Bostoen, and Filip De Turck. 2017.对个人交付网络验证的大型多媒体丰富Web门户分析.在2017年IFIP/IEEE综合网络和服务管理（IM）研讨会上. IEEE, 714–719. [33]  MatteoVarvello, Jeremy Blackburn, David Naylor, and Konstantina Papagiannaki. 2016.EYEORG：用于众包Web体验质量测量的平台.在第12届ACM新兴网络实验和技术会议论文集中. 399–412. [34]  W3C推荐。2012.导航计时。在线，https: //www . w3 . org/TR/navigation-timing. (2012年12月). [35]Xiao Sophia Wang, Aruna Balasubramanian, Arvind Krishnamurthy, and DavidWetherall. 2013. 用WProf揭示页面加载性能的神秘面纱.在第10届USENIX网络系统设计与实现会议（NSDI’13）论文集中. 473–486. [36]  XiaoSophia Wang, Arvind Krishnamurthy, and David Wetherall. 2016.使用Shandian加快Web页面加载速度.在第13届USENIX网络系统设计与实现会议（NSDI’16）论文集中. 109–122. [37]  ZhenWang, Felix Xiaozhu Lin, Lin Zhong, and Mansoor Chishtie. 2011.为什么智能手机上的Web浏览器很慢？. 在第12届移动计算系统和应用研讨会论文集中.ACM, 91–96. [38]  WebPagetest. 2017. 网站性能和优化测试. 在线，https://www .webpagetest . org/. (2017). [39]  WebPageTest文档。2012. 速度指数. 在线，https://sites . google . com/a/webpagetest . org/docs/using-webpagetest/metrics/speed-index. (2012). [40]  Maarten Wijnants, Robin Marx, Peter Quax, and WimLamotte. 2018. HTTP/2优先级及其对Web性能的影响. 在2018年WWW会议上. ACM. [41] Kyriakos Zarifis, Mark Holland, Manish Jain, Ethan Katz-Bassett, and RameshGovindan. 2017. 在内容交付网络中有效使用HTTP/2服务器推送. 技术报告. 南加州大学.[42]  Torsten Zimmermann, Benedikt Wolters, and Oliver Hohlfeld. 2017.从QoE的角度看HTTP/2服务器推送. 在QoE