Facebook 前端技术栈重构分享

3372次阅读  |  发布于4年以前

阿里@张克军翻译

当我们考虑如何构建一个新的网络应用—一个为现代浏览器设计的、具有用户对Facebook（我们已知的）所有期望的功能，我们现有的技术栈无法支持我们所需要的类似于桌面应用的感觉和性能。完全重写是非常罕见的，但在这种情况下，由于过去十年来Web技术发生了很多变化，我们知道这是我们实现性能和未来可持续发展目标的唯一途径。今天，我们就分享一下我们在重构Facebook.com时的经验教训，使用React（一种用于构建用户界面的声明式JavaScript库）和Relay（React的GraphQL客户端）来重构Facebook.com。

1. 开始

我们希望Facebook.com能够快速启动，快速响应，并提供高度互动的体验。虽然服务端驱动（server-driven）的应用程序可以提供快速启动时间，但我们不相信它能像客户端驱动（client-driven）的应用程序那样具有互动性和愉悦性。然而，我们相信我们可以构建一个客户端驱动的应用程序，并能提供具有竞争力的快速启动时间。

但是从头开始做一个客户端优先的APP，这带来了一系列新的问题。我们需要快速重建网站，同时解决速度和其他用户体验问题，而且在未来几年内能可持续的发展。在整个过程中，我们围绕着两个技术口号开展工作：

我们应用这些原则来改进网站的四个要素：CSS、JavaScript、数据和路由。

2. 反思CSS，解锁新功能

首先，我们通过改变编写和构建样式的方式，将主页上的CSS减少了80%。在新网站上，我们写的CSS与在浏览器上看到的CSS不同。当我们将CSS-like的JavaScript和组件写在一起时，构建工具会将这些样式分割成单独的优化包。因此，新网站的CSS数量减少了，支持暗模式和动态字体大小以实现可访问性，并改善了图片的渲染性能，同时让工程师们开发更容易。

原子化的CSS，减少主页80％的CSS

在我们的旧网站上加载主页时，加载了超过400KB的压缩CSS（2MB未压缩），但实际上只有10%的CSS被用于初始渲染。我们一开始并没有使用那么多的CSS，只是随着时间的推移而增加，很少做删减。之所以会出现这种情况，部分原因是每一个新功能都意味要添加新的CSS。

我们通过在构建时生成原子化CSS来解决这个问题。原子化CSS有一个对数增长曲线，因为它与唯一的样式声明的数量成正比，而不是与我们编写的样式和功能的数量成正比。这使得我们可以将整个网站中生成的原子型CSS合并到一个单一的、小的、共享的样式中。结果是新主页CSS下载量不到老网站的20%。

协同定位样式（Colocating styles）减少未使用的CSS，使其更容易维护

CSS随着时间的推移而增长的另一个原因是我们很难识别各种CSS规则是否还在使用。Atomic CSS有助于缓解这一点的性能影响，但独特的样式仍然会增加不必要的字节，而且我们的源代码中未使用的CSS会增加工程开销。现在，我们将我们的样式与我们的组件写在一起，这样就可以将它们串联起来删除，并且只在构建时将它们分割成单独的包。

我们还解决了另一个问题，CSS的优先级取决于顺序，当使用自动打包时，这一点尤其难以管理，因为自动打包会随着时间的推移而改变。以前，一个文件中的变化可能会在作者没有意识到的情况下破坏另一个文件中的样式。相反，我们现在用一种熟悉的语法来编写样式，它的灵感来自于React Native风格的API。我们保证样式以稳定的顺序应用，而且不支持CSS后裔选择器。

改变字体大小以提高无障碍性

在今天的许多网站上，人们会通过使用浏览器的缩放功能放大文字。这可能会不小心触发平板电脑或移动端布局，或者改变不需要放大的东西，比如图片。

通过使用rems，我们可以遵守用户指定的默认值，并且能够提供对自定义字体大小的控制，而不需要修改CSS。然而，设计通常是使用CSS像素值创建的。手动转换为rems会增加工程开销和潜在的bug，所以我们的构建工具自动完成这个转换。

构建时处理的例子

源代码

const styles = stylex.create({
  emphasis: {
    fontWeight: 'bold',
  },
  text: {
    fontSize: '16px',
    fontWeight: 'normal',
  },
});

function MyComponent(props) {
  return <span className={styles('text', props.isEmphasized && 'emphasis')} />;
}

生成的CSS)

.c0 { font-weight: bold; }
.c1 { font-weight: normal; }
.c2 { font-size: 0.9rem; }

生成的JavaScript

function MyComponent(props) {
  return <span className={(props.isEmphasized ? 'c0 ' : 'c1 ') + 'c2 '} />;
}
用于主题设计的CSS变量（暗夜模式）

在旧网站上，我们曾经尝试通过在body元素中添加一个类名来应用主题，然后用这个类名来覆盖现有的样式，这些样式有更高的优先级。这种方法有问题，它不再适用于我们新的原子化的CSS-in-JavaScript方法，所以我们改用CSS变量来进行主题切换。

CSS变量被定义在一个类下，当这个类应用到DOM元素上时，它的值会被应用到它的DOM子树中的样式。这让我们可以将主题组合成一个单一的样式表，这意味着切换不同的主题不需要重新加载页面，不同的页面可以有不同的主题而不需要下载额外的CSS，不同的产品可以在同一个页面上并排使用不同的主题。

.light-theme {
  --card-bg: #eee;
  }
.dark-theme  {  
  --card-bg: #111;
}
.card {
  background-color: var(--card-bg);
}
在JavaScript中使用SVG，实现快速、单一渲染的性能

为了防止图标在其他内容之后出现闪烁，我们使用 React 将 SVG 内联到 HTML 中，而不是将 SVG 以img的方式显示。因为这些SVG现在是有效的JavaScript，所以它们可以和周围的组件一起实现干净的单次渲染。我们发现，在加载JavaScript的同时加载这些SVG的好处大于SVG的绘制性能。通过内联，不会出现图标闪烁。

function MyIcon(props) {
  return (
  <svg {...props} className={styles({/*...*/})}>
       <path d="M17.5 ... 25.479Z" />
    </svg>
  );
}

3. JavaScript通过Code-splitting提高性能

代码大小是一个基于JavaScript的单页面应用最大的担忧之一，因为它对页面加载性能影响很大。我们知道，如果我们想让Facebook.com的客户端React app有客户端的效果，就需要解决这个问题。我们引入了几个新的API，这些API的工作原理与我们 "尽可能少，尽可能早"的口号一致。

递增的代码加载，在需要的时候提供需要的东西（what we need, when we need it）

在等待页面加载的时候，我们的目标是通过渲染页面的UI "骨架 "来即时反馈页面会是什么样子。这个骨架需要最少的资源，但如果代码被打成一个包，我们就无法提前渲染，所以我们需要根据页面显示的顺序将代码拆分成包。然而，如果简单地这样干（即使用在渲染过程中获取的动态导入），我们可能会伤害到性能，而不是有利于性能。这就是我们对“JavaScript加载层”的代码拆分设计的基础。我们将初始加载所需的JavaScript分成三层，使用一个声明式的、可静态分析的API。

第1层是显示上层内容的首刷所需的基本布局，包括初始加载状态的UI骨架。

第一层代码加载和渲染后的页面

import ModuleA from 'ModuleA';

第2层包括了所有需要的JavaScript，以完全呈现所有的折叠内容。第2层之后，屏幕上的任何内容都不应该因为代码加载而发生视觉上的变化。

第2层代码加载和渲染后的页面

importForDisplay ModuleBDeferred from 'ModuleB';

一旦遇到一个importForDisplay，它和它的依赖关系就会被移到第2层。返回一个基于promise包装的模块，以便在模块加载后访问它

第2层需要完整的交互。如果有人在第2层代码加载和渲染后点击菜单，即使菜单的内容还没有准备好渲染，也会立即得到反馈。第3层包含显示后才需要的、不影响当前屏幕展示的所有东西，包括log代码和订阅实时更新数据的代码。

importForAfterDisplay ModuleCDeferred from 'ModuleC';

// ...

function onClick(e) {
  ModuleCDeferred.onReady(ModuleC => {
    ModuleC.log('Click happened! ', e);
  });
}

一旦遇到importForAfterDisplay，它和它的依赖关系就会被移到第3层。返回一个基于promise包装的模块，以便在模块加载后访问它。

一个500KB的JavaScript页面，在第1层可以变成50KB，第2层可以变成150KB，第3层可以变成300KB。以这种方式分割代码，使我们能够通过减少需要下载的代码量来达到每一个里程碑，从而提高了从第一次绘制到视觉完成的时间。因为第3层并不影响屏幕上的像素，所以它并不是真正的渲染，最终的刷图完成时间更早。最重要的是，加载屏幕能够更早地渲染。

只有在需要的时候才加载的试验驱动（experiment-driven）的依赖项

我们经常需要渲染两个相同的UI的变体，例如在A/B测试中经常需要渲染两个相同的UI。最简单的方法是下载两个版本，但这意味着下载的代码可能永远不会被执行。一个稍微好一点的方法是在渲染时动态导入，但这可能会很慢。

相反，为了保持我们的 "尽可能少，尽可能早 "的口号，我们构建了一个声明式的API，可以提前提醒我们这些决定，并将其编码到我们的依赖图中。当页面正在加载时，服务器能够检查试验，并只向下发送所需版本的代码。

const Composer = importCond('NewComposerExperiment', {
  true: 'NewComposer',
  false: 'OldComposer',
});

我们将每个帖子类型所需的依赖关系作为查询的一部分来表达

更赞的是，PhotoComponent 本身就把它需要的照片附件类型的数据精确地描述为片段，这意味我们甚至可以把查询逻辑拆分出来。

使用JavaScript预算来防止代码蠕变

分层和条件依赖关系可以帮助我们交付每个阶段所需的代码，但我们还需要确保每个层的规模随着时间的推移保持在可控范围内。为了管理这个问题，我们引入了每个产品的JavaScript预算。

我们根据性能目标、技术约束、产品考虑制定预算。同时根据产品边界和团队边界分配页面级预算，并根据产品边界和团队边界进行细分。共享基础设施（Shared infra）被添加到一个精心筛选的列表中，并给出了自己的预算。共享基础设施会计入所有页面的预算，但其中的模块是免费提供给产品团队使用的。对于延迟加载、有条件加载或交互时加载的代码也有预算。

我们为过程的每一步创建了相关的工具：

尽早实现数据获取（data-fetching）的现代化

作为这次重写的一部分，我们对网站上的数据获取的基础设施进行了现代化改造。虽然旧网站的一些功能使用 Relay 和 GraphQL 进行数据采集，但大部分数据获取都是作为服务器端 PHP 渲染的一部分。在新网站上，我们能够与我们的移动应用标准化，并确保所有的数据获取都通过GraphQL进行。由于Relay和GraphQL已经为我们处理了 "尽可能少的 "工作，我们只需要做一些改变，以支持尽早获得我们所需要的数据。

初始请求预加载数据，以提高启动效率

许多Web应用程序需要等到所有的JavaScript被下载并执行后才从服务器上获取数据。有了Relay，我们可以静态地知道页面需要什么数据。这意味着，一旦我们的服务器收到页面的请求，它就可以立即开始准备必要的数据，并与所需的代码并行下载。当页面可用时，我们会将这些数据与页面一起流转，这样客户端就可以避免额外的往返次数，更快地呈现最终的页面内容。

为减少往返次数和提高互动性的流数据

注：流数据具有四个特点：数据实时到达；数据到达次序独立，不受应用系统所控制；数据规模宏大且不能预知其最大值；数据一经处理，除非特意保存，否则不能被再次取出处理，或者再次提取数据代价昂贵。（来自网上的解释）

在最初加载Facebook.com时，有些内容可能会被隐藏或呈现在视口之外。例如，大多数屏幕上可以容纳一到两个News Feed帖子，但我们不知道事先会容纳多少个。此外，用户很有可能会滚动，在连载往返的过程中，逐一抓取每个故事需要时间。另一方面，我们在一次查询中获取的故事越多，查询的速度就越慢，这就导致查询时间越长，即使是第一个故事，也需要更长的视觉完成（Visually Complete）时间。

注：视觉完成时间是指网页可见区域内的所有元素都被100%加载。

为了解决这个问题，我们使用了一个内部的GraphQL扩展—@stream，将Feed连接流向客户端，用于初始加载和后续滚动时的分页。这使得我们可以在每一个feed故事准备好后，只需进行一次查询操作，就可以将每一个feed故事逐一发送。

fragment HomepageData on User {
  newsFeed(first: 10) {
    edges @stream
  }
  ...AdditionalData
}
推迟暂不需要的数据

不同部分的查询时间是不同的，例如，在查看个人资料时，获取一个人的姓名资料和照片相对来说比较快，但获取他们的Timeline内容则需要较长的时间。

为了在一次查询中获取这两种类型的数据，我们使用@defer，当响应的不同部分准备好后就可以将其变成流数据。这让我们能够尽快用初始数据渲染大部分的UI，并为其余部分渲染加载状态。有了React Suspense就更容易了，因为我们可以显式地设计加载状态，以确保流畅的、自上而下的页面加载体验。

fragment ProfileData on User {
  name
  profile_picture { ... }
  ...AdditionalData @defer
}

5. 定义路由图加快导航速度

快速导航是单页应用的一个重要功能。当导航到一个新的路径时，我们需要从服务器上获取各种代码和数据来渲染目的页面。为了减少加载新页面时需要的网络往返次数，客户端需要提前知道每条路线需要哪些资源。我们将其称为路由图，每个条目称为路由定义。

尽早获得路由定义

对于Facebook来说，这个路由图太大了，无法一次性发送全部的。相反，我们在会话期间，随着新链接的呈现，动态地将路由定义添加到路由图中。路由图和路由器存在应用的最顶端，允许结合当前应用和路由器的状态来驱动应用级的状态决策，例如基于当前路由的顶部导航栏或聊天标签的行为。

尽早预获取资源

客户端应用程序通常要等到React渲染一个页面后才会下载该页面所需的代码和数据。通常情况下使用React.lazy或类似的东西实现。由于这可能会使页面导航速度变慢，所以我们反而会在链接被点击之前就开始请求一些必要的资源。

为了提供更流畅的体验，我们使用React Suspense转场来继续渲染上一个路由，直到下一个路由完全渲染完毕或暂停到下一个页面的UI骨架的 “友好 “的加载状态。这样做会减少很多干扰，而且它模仿了标准的浏览器行为。

代码和数据并行下载

在新网站上我们做了很多懒加载代码，但如果我们懒加载一个路由的代码，而这个路由的数据抓取代码就在这个路由的代码里面，最后就会出现串行加载的情况。

"传统 "的React / Relay app，加上懒加载的路由，结果会是两次往返为了解决这个问题，我们想出了EntryPoints，它是包裹代码分割点并将输入转化为查询的文件。这些文件非常小，对于任何可以到达的代码拆分点都会提前下载。

代码和数据是并行提取的，让我们可以在一次网络请求往返中下载这些

GraphQL查询仍然与视图写在一起，但EntryPoint封装了何时需要该查询以及如何将输入转化为正确的变量。应用程序使用这些 EntryPoints 来自动决定何时请求，确保默认情况下正确的发生。这有一个额外的好处，那就是创建一个单一的JavaScript函数，它包含了App中任何给定点的所有数据获取需求，可以用于前面讨论的服务器预加载。

我们在这里讨论的许多变化并不是Facebook特有的。这些概念和模式可以应用到任何框架或库的客户端应用程序中。通过标准化我们的技术栈，我们已经能够重新思考如何以一种执行力强、可持续的方式引入人们想要的功能--即使是在工程和产品规模的运营过程中也是如此。

工程体验的改善和用户体验的改善必须齐头并进，不能把性能和可访问性看作是对输出功能的额外负担。通过优秀的API、工具和自动化，我们可以帮助工程师们更快地推进工作，并同时发布更好的、更高性能的代码。为提高新的Facebook.com的性能所做的工作非常广泛，我们预计很快会分享更多关于这项工作的信息。要查看重新设计的内容，请访问facebook.com。它正在逐步推出，很快就会对大家开放。

Copyright© 2013-2020

All Rights Reserved 京ICP备2023019179号-8