谷歌搜索引擎核心算法揭秘:如何完成秒级页面交互?

作者丨Ben Schwarz
译者丨核子可乐
去年,谷歌公司对其搜索索引及排名算法做出了两项重大变更:
去年 3 月,索引编目开始基于页面的移动版本,而非桌面版。
去年 7 月,SEO 排名算法迎来更新,将页面速度作为移动页面及广告的排名因素。
由此,我们可以总结出两点可靠结论:
站点在移动设备上的速度将影响整体扫描引擎优化排名。
如果页面加载速度较慢,则会降低广告质量得分,意味着广告成本将因此上升。
谷歌方面写道:
速度更快的网站不仅能够改善用户体验。最近的调查数据显示,提高网站速度还有助于降低运营成本。像我们一样,每位用户都能够通过速度获得巨大的价值收益,因此我们决定将网站速度纳入搜索排名的考量当中。
为了从性能角度理解这些调整会对我们造成怎样的影响,首先需要理解其中的基础性技术。PageSpeed 5.0 可谓对以往版本做出了彻底颠覆,其现在由Lighthouse 以及CrUX(Chrome 用户体验报告)提供支持。
此次升级还带来了一种新的评分算法,使得网站更难获得较高的 PageSpeed 得分。
在 5.0 版本之前,PageSpeed 会针对特定页面运行一系列启发式算法。如果页面中包含大量未经压缩的图像,则 PageSpeed 会建议进行图像压缩。如果缺少 Cache-Header,PageSpeed 也会建议立即添加。
这些启发式方法还与系列指导方针相结合。当然,我们不能简单地认为只要遵循这些指导方针,就足以带来更理想的性能。因为其中并不涉及对真实访客所面对的负载与渲染体验进行实际分析。
在 PageSpeed 5.0 当中,页面会被加载至由 Lighthouse 控制的真实 Chrome 浏览器当中。Lighthouse 会记录来自浏览器的指标,利用评分模型进行指标分析,并给出整体性能得分。根据具体的指标评分方式,PageSpeed 即可给出改进建议。
与 PageSpeed 类似,Lighthouse 同样提供性能评分。在 PageSpeed 5.0 当中,性能得分会直接被发送给 Lighthouse。这意味着 PageSpeed 的速度得分现在与 Lighthouse 性能得分保持一致。

现在,我们了解了 PageSpeed 的得分来源,下面开始深入了解具体得分的计算方法,以及如何对其进行有意义的改进。
Lighthouse 是一个由谷歌 Chrome 旗下专项团队负责运营的开源项目。过去几年以来,其已经逐步发展成一款免费的性能分析工具。
Lighthouse 采用 Chrome 的远程调试协议读取网络请求信息、测量 JavaScript 性能、观察可访问性标准,并测量以用户为中心的各项时序指标,包括首次内容填充、交互时间或者索引速度等。
在性能测试过程中,Lighthouse 会记录下一系列与用户观感及体验相关的指标。
总体性能得分的建立基于六项具体指标,分别为:
交互时间 (TTI)
索引速度
首次内容填充 (FCP)
首次 CPU 空闲
首次有意义填充 (FMP)
估算输入延迟
Lighthouse 会为以上各项指标打出 0 到 100 之间的得分。整个过程会从 HTTP Archive 当中提取第 75 与第 95 百分位的移动测量指标,而后应用一项 log normal 函数。
根据用于计算交互时间的算法与参考数据,我们可以看到,如果页面在 2.1 秒之内实现“交互”,则交互时间指标的标准得分为 92/100。

每项指标接受评分之后,Lighthouse 会为其分配一个权重,该权重作为总体性能得分计算中的调节器。具体权重如下所示:

这些权重代表着每一项指标对移动用户体验造成的具体影响。
未来,大家还可以引入来自 Chrome 用户体验报告数据集的用户观察数据来进一步增强估算结果。
您可能希望了解每项指标的权重如何影响整体性能得分。Lighthouse 团队开发出一款实用的谷歌 Spreadsheet 计算器,用以解释整个过程:

使用上述示例,如果我们将交互时间从 5 秒改为 17 秒(全局平均移动 TTI),那么,我们的得分将降至 56%(即 100 分制中的 56 分)。
如果我们将首次内容填充指标修改为 17 秒,那么得分将为 62%。
交互时间 (TTI) 是性能得分当中最重要的一项指标。
因此,要获得较高的 PageSpeed 得分,需要优先关注 TTI 速度水平。
从高级视角来看,有两个重要因素会对 TTI 产生直接影响:
传递给页面的 JavaScript 代码量
主线程上 JavaScript 任务的运行时间
我们在交互时间指南当中解释了 TTI 的具体工作原理,如果大家希望快速了解情况,我们将优化思路总结如下:
减少 JavaScript 代码量在可能的情况下,删除未使用的 JavaScript 代码或者确保仅交付当前页面需要运行的脚本。这可能意味着您需要删除旧的 polyfill,或者使用更小、更现代的第三方库作为替代。需要注意的是,JavaScript 代码带来的成本并不仅仅体现在下载时间上。浏览器需要对相关代码进行解压缩、解析、编译以及最终执行,这一切都会带来可观的处理时间,特别是在移动设备当中。
下面来看减少页面中脚本数量的有效方法:
审查并删除访客并不需要的 polyfills。
了解各类第三方 JavaScript 的性能成本。使用 webpack-bundle-analyser 或者 source-map-explorer 对各个库的大小进行可视化。
现代 JavaScript 工具(例如 Webpack)能够将大型 JavaScript 应用拆分成一系列小型捆绑包,这些捆绑包会在用户导航时自动加载。这种方法被称为代码拆分,且具有显著的 TTI 改进效果。
服务工作程序会缓存经过解析且编译的脚本的字节码结果。如果能够使用此项功能,那么访问者只需要付出一次性解析与编译成本,接下来相关结果都可以从缓存中直接调用。
为了成功发现用户体验中的重大差异,我们建议使用性能监控系统(例如 Calibre),其允许通过至少两台设备进行测试,包括一台调整台式设备与一台中低端移动手机。
通过这种方式,开发者就能够得到最佳与最差情况下的客户体验数据。下面,我们以客户使用低性能硬件为例,聊聊如何进行体验优化。
为了在分析 JavaScript 性能方面获得最佳结果,大家应该主动使用低性能设备进行页面测试。如果您的办公桌里恰好有一部旧手机,是时候让它再发挥一波余热了。
另有一种理想的真实设备替代方案,即使用 Chrome DevTools 硬件仿真模式。我们编写了一份广泛的性能分析指南,可帮助大家快速理解运行时性能。
接下来是索引速度、首次内容填充以及首次有意义填充,这些都是浏览器填充方面的指标。它们也受到类似因素的影响,而且一般能够同时接受优化。
通过页面呈现的速度计算这些指标,能够在客观上降低指标的改进难度。另外,您可以根据 Lighthouse 性能审查规则对这些指标做出优化。如果尚未预加载字体或者针对关键请求进行优化,那么这两项工作无疑应该首先完成。
谷歌最近更新了搜索控制台,Lighthouse 与 PageSpeed Insights 都是快速获得页面性能直观结果的好办法。但对于需要持续跟踪并改善网页性能的用户而言,其功能可能仍然不够理想。持续性能监控对于确保最终速度改进至关重要,并且能够在性能退化时立即向团队发送通知。手动测试则可能在结果当中引入意想不到的变化,而且如果没有专门的实验室环境,我们几乎不可能在不同区域及各类设备之上进行测试。
速度已经成为搜索引擎优化排名中的关键因素,特别是考虑到目前近 50% 的网络流量都来自移动设备。为了避免排名下降,请确保使用最新性能套件跟踪关键页面(pssst,我们将 Calibre 打造成性能伴侣,其中内置有 Lighthouse。目前全球范围内数百支团队都在日常使用这款工具)。
原文链接:
https://calibreapp.com/blog/how-pagespeed-works/

点个在看少个 bug ?
关注公众号:拾黑(shiheibook)了解更多
[广告]赞助链接:
四季很好,只要有你,文娱排行榜:https://www.yaopaiming.com/
让资讯触达的更精准有趣:https://www.0xu.cn/
关注网络尖刀微信公众号随时掌握互联网精彩
- 1 习近平听取岑浩辉述职报告 7904526
- 2 收入分配制度或迎重大改革 7808928
- 3 4400万粉丝网红直播泳池派对被处理 7713601
- 4 2025年度文化记忆 重温感动瞬间 7615998
- 5 河南学校火灾致13人遇难 25人被处分 7523675
- 6 “爱你老己”是今年最好的梗 7424897
- 7 39岁中国女子伦敦被刺身亡 7328854
- 8 云南一村告示:外省结婚交1500元 7238603
- 9 62岁乒乓球名将倪夏莲正式复出 7135962
- 10 用漫画方式了解海南自贸港封关 7041749

InfoQ
