本文网络性能的重要意义进行一番论证（博文末尾）

发布时间:2023/04/28 浏览次数:37 分类:SEO优化

导读：本文虽然明指了某个主页seo优化思路与网站定位，但是其实是适合所有网站系统前端的优化技巧的。

最近，我们将主页的性能提升了十倍以上。在本文中，我们将解析实现这一重大改进的具体技术手段。

但在开始之前，让我们先对网络性能的重要意义进行一番论证（博文末尾提供相关案例研究链接）：

在本篇文章中，我们将简要介绍以下几大有助于我们提高页面性能的主要领域：

这里再介绍一点我们的情况：我们的主页由 React（TypeScript）、Phoenix（Elixir）、Puppeteer（headless Chrome）以及 GraphQL API（Ruby on Rails）构建而成。以下为主页在移动设备上显示的效果：

Universe 主页与浏览效果

性能测量

没有数据作为支持，一切意见都将毫无意义。

—— W. Edwards Deming

实验室工具

实验室工具能够立足受控环境从预定义的设备及网络设置中收集数据。利用这些工具，我们能够轻松调试任何性能问题并实现良好的可重复测试。

Lighthouse 就是一款立足本地计算机对 Chrome 内网页进行审计的出色工具。其能够提供一系列关于如何提高性能、可访问性以及搜索引擎优化的实用性提示。下面，我们来看模拟高速 3G 加 4x CPU 场景下的 Lighthouse 性能审计报告：

之前与之后：首屏内容填充（简称 FCP）性能实现 10 倍提升

然而，单纯使用实验室工具也会带来不少弊端：这类工具不一定能准确反映出最终用户所面临的设备、网络、位置以及多种其它现实因素造成的性能瓶颈。正因为如此，我们才需要配合现场工具进行补充。

现场工具

现场工具允许我们模拟并测量用户的真实页面负载。目前有多种服务可帮助大家从实际设备当中获取真实性能数据：

WebPageTest 报告

渲染

内容的渲染可通过多种方法实现，其中每一种都拥有独特的优势与缺点：

客户端渲染

以前，我们将自己的主页与 Ember.js 框架一同实现为采用客户端渲染方法的单页面应用。但这种做法的一大问题在于，我们的 Ember.js 应用程序包过大。这意味着在浏览器下载 JavaScript 文件并对其进行解析、编译与执行的过程中，用户只能对着空白屏幕发呆：

最要命的空白屏幕

因此，我们决定利用 React 重构应用当中的某些部分。

预渲染与服务器端渲染

客户端渲染应用程序的具体构建——例如采用 React Router DOM，仍然会带来与 Ember.js 相同的问题。JavaScript 需要占用大量资源，而且访问者需要经历一段首屏内容填充周期才能看到实际内容。

因此在决定使用 React 之后，我们开始尝试其它潜在的渲染选项，以确保浏览器能够更快地完成内容渲染。

使用 React 时的常规渲染选项

因此，我们打算尝试一下混合方法，即发挥每一种渲染选项中的独特优势。

运行时预渲染

Puppeteer 是一套 Node.js 库，允许用户使用 headless Chrome。我们希望尝试利用 Puppeteer 在运行时当中实现预渲染。这代表着一种有趣的混合方法：利用 Puppeteer 进行服务器端渲染，同时利用 hydration 进行客户端渲染。感兴趣的朋友可以点击此处查看谷歌提供的关于如何利用 headless 浏览器进行服务器端渲染的相关提示。

利用 Puppeteer 对 React 应用程序进行运行时预渲染

这种方法具备以下优势：

但在采用这种方法的过程中，我们也遇到了一些挑战：

利用 Puppeteer 的服务器端渲染架构

• 稳定性。对众多 headless 浏览器进行规模伸缩，同时保持进程不致过热并实现负载均衡绝对是一项高难挑战。我们尝试了不同的托管方法，包括在 Kubernetes 集群内进行自托管，以及利用 AWS Lambda 与 Google Cloud Functions 实现无服务器计算。我们注意到，后一种方法在配合 Puppeteer 时存在一些性能问题：

AWS Lambdas和GCP函数的Puppeteer响应时间

在配合 AWS Lambdas 与 GCP Functions 时，Puppeteer 的响应时间结果随着我们对 Puppeteer 熟悉程度的逐步提升，我们开始对初始方法进行迭代（后文将具体说明）。我们还进行了其它一系列有趣的实验，希望通过 headless 浏览器渲染 PDF。再有，即使不编写任何代码，我们也能够利用 Puppeteer 自动进行端到端测试。而且除了 Chrome 之外，Puppeteer 现在还支持 Firefox 浏览器。

混合渲染方法

在运行时中使用 Puppeteer 并非易事。正因为如此，我们才决定在构建时中加以使用，同时配合一款工具用于在运行时内从服务器端获取用户生成的实际内容。很明显，这款工具必须拥有比 Puppeteer 更强大的稳定性与吞吐能力。

我们决定使用 Elixir 编程语言。Elixir 看起来与 Ruby 非常相似，但运行在 BEAM（Erlang VM）之上。顺带一提，BEAM 专门为构建高容错、高稳定性系统而生。

Elixir 采用 Actor 并发模型。每个“Actor”（即 Elixir 进程）的内存占用量都非常有限seo优化思路与网站定位，仅为 1 到 2 KB。这意味着系统将能够同时运行成千上万个独立的进程。Phoenix 则是一套 Elixir Web 框架，能够支持高吞吐量，并允许开发者在各个独立的 Exlixir 进程当中处理各项 HTTP 请求。

我们将上述方法结合起来，充分利用其各自优势，希望能够切实满足自身需求：

Puppeteer 用于实现预渲染，Phoenix 则用于实现服务器端渲染

我们可以继续构建一款简单的浏览器 React 应用程序，并在无需等待最终用户设备 JavaScript 处理过程的同时获得快速初始页面加载效果。

利用 Puppeteer 建立预渲染架构，利用 Phoenix 进行服务器端渲染，React 则在客户端上实现 hydration

网络

内容交付网络 (CDN)

利用 CDN 可帮助我们实现内容缓存，并加速其在全球范围内的交付速度。我们选择了，其目前处理着全球超过 10% 的请求总量，并得到 GitHub、Stripe、Airbnb 以及 Twitter 等诸多厂商的青睐。

Fastly 允许我们编写定制化缓存，并可利用 VCL 配置语言建立路由逻辑。下面，我们将具体聊聊基础请求流如何根据路由、请求头等因素分步起效：

VCL 请求流

提高性能的另一个选项是配合 Fastly 在边缘位置使用 WebAssembly（WASM）。大家可以将其视为一种无服务器模式，只是处于边缘位置；所使用的语言则包括 C、Rust、Go 以及 TypeScript 等等。Cloudflare 就拥有一个类似的项目，用于在 Workers 上支持 WASM。

缓存

尽可能多地利用缓存处理请求是改善性能水平的关键所在。立足 CDN 层级进行缓存，将能够更快地为新用户提供响应。而通过发送 Cache-Control 头进行缓存，则可加快浏览器中重复请求的响应速度。

大多数构建工具（例如 Webpack）允许用户向文件名当中添加哈希值。由于指向这些文件的任何变更都会产生新的输出文件名，因此大家可以安心将文件添加至缓存当中。