Facebook 前端技术栈重构分享

阿里@张克军翻译

当我们考虑如何构建一个新的网络应用—一个为现代浏览器设计的、具有用户对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)被添加到一个精心筛选的列表中,并给出了自己的预算。共享基础设施会计入所有页面的预算,但其中的模块是免费提供给产品团队使用的。对于延迟加载、有条件加载或交互时加载的代码也有预算。

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

  • 依赖关系图工具让我们更容易理解字节来自哪里,并识别出减少代码大小的机会。
  • 合并请求上的大小监控会显示大小回归 / 改进,并触发可定制的警报。
  • 通过交互式图表显示历史大小以及修订之间的变化情况。
  • 通过Dashboard帮助我们了解当前的大小与预算的关系。

尽早实现数据获取(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。它正在逐步推出,很快就会对大家开放。

Chrome 81 正式发布 !消灭混合内容最后一步~

Chrome 81 于前天正式发布了,这个版本其实最初是计划在 3 月 17 号 发布的,但由于冠状病毒(COVID-19)爆发而导致推迟到了现在。Chrome 81 的延迟也扰乱了 Google 正常的六周发布时间表。因此 Google 此前也宣布,下一个版本将直接跳过 Chrome 82 ,直接发布 Chrome 83。 下面我就来带大家看看 Chrome 81 有哪些重要的更新。

发布于:1月以前  |  108次阅读  |  详细内容 »

当浏览器全面禁用三方 Cookie

苹果公司前不久对 Safari 浏览器进行一次重大更新,这次更新完全禁用了第三方 Cookie,这意味着,默认情况下,各大广告商或网站将无法对你的个人隐私进行追踪。而微软和 Mozilla 等也纷纷采取了措施禁用第三方 Cookie,但是由于这些浏览器市场份额较小,并没有给市场带来巨大的冲击。

发布于:1月以前  |  95次阅读  |  详细内容 »

H5 直播的疯狂点赞动画是如何实现的?

直播有一个很重要的互动:点赞。 为了烘托直播间的氛围,直播相对于普通视频或者文本内容,点赞通常有两个特殊需求: 点赞动作无限次,引导用户疯狂点赞 直播间的所有疯狂点赞,都需要在所有用户界面都动画展现出来(广播用户使用websocket消息)

发布于:1月以前  |  92次阅读  |  详细内容 »

探索 Serverless 中的前端开发模式

最近关于 Serverless 的讨论越来越多。看似与前端关系不大的 Serverless,其实早已和前端有了渊源,并且将对前端开发模式产生变革性的影响。本文主要就根据个人理解和总结,从前端开发模式的演进、基于 Serverless 的前端开发案例以及 Serverless 开发最佳实践等方面,与大家探讨 Serverless 中的前端开发模式。本人也有幸在 QCon2019 分享了这一主题。

发布于:1月以前  |  119次阅读  |  详细内容 »

前端需要了解的9种设计模式

设计模式是对软件设计开发过程中反复出现的某类问题的通用解决方案。设计模式更多的是指导思想和方法论,而不是现成的代码,当然每种设计模式都有每种语言中的具体实现方式。学习设计模式更多的是理解各种模式的内在思想和解决的问题,毕竟这是前人无数经验总结成的最佳实践,而代码实现则是对加深理解的辅助。

发布于:1月以前  |  102次阅读  |  详细内容 »

为什么你的网页需要 CSP?

内容安全策略(CSP)是一个 HTTP Header,CSP 通过告诉浏览器一系列规则,严格规定页面中哪些资源允许有哪些来源, 不在指定范围内的统统拒绝。

发布于:1月以前  |  89次阅读  |  详细内容 »

10 种跨域解决方案(附终极方案)

嗯。又来了,又说到跨域了,这是一个老生常谈的话题,以前我觉得这种基础文章没有什么好写的,会想着你去了解底层啊,不是很简单吗。但是最近在开发一个 「vscode 插件」 发现,当你刚入门一样东西的时候,你不会想这么多,因为你对他不熟悉,当你遇到不会的东西,你就是想先找到解决方案,然后通过这个解决方案再去深入理解。

发布于:1月以前  |  147次阅读  |  详细内容 »

移动 Web 最佳实践(干货长文,建议收藏)

笔者在公司用 web 技术开发移动端应用已经有一年多的时间了,开始主要以 vue 技术栈配合 native 为主,目前演进成 vue + react native 技术架构,vue 主要负责开发 OA 业务,比如报销、出差、crm 等等,react native 主要负责即时通信部分,是在 mattermost-mobile的基础上修改的(mattermost 是一个开源的即时通讯方案)。

发布于:1月以前  |  104次阅读  |  详细内容 »

不可错过的实用前端工具

给大家整理了 25 个前端相关的学习网站和一些靠谱的小工具,包括一些小游戏、教程、社区网站和博客,以及一些资源网站,希望可以帮助到大家!

发布于:1月以前  |  98次阅读  |  详细内容 »

理解 WebView

我们通常使用 Chrome, Firefox, Safari, Internet Explorer 和 Edge 等浏览器来浏览网页。你也许正在使用其中一种浏览器阅读本文!虽然浏览器对于访问互联网内容的任务来说非常流行,它们还有一些我们从未过多关注过的竞争对手。这些竞争对手以 WebView 的形式被我们所熟知。这片文章将讲解 WebView 的神秘之处以及为什么它这么棒。

发布于:1月以前  |  98次阅读  |  详细内容 »

Facebook 前端技术栈重构分享

当我们考虑如何构建一个新的网络应用—一个为现代浏览器设计的、具有用户对Facebook(我们已知的)所有期望的功能,我们现有的技术栈无法支持我们所需要的类似于桌面应用的感觉和性能。

发布于:1月以前  |  100次阅读  |  详细内容 »

最多阅读

为Electron程序添加运行时日志 1年以前  |  4831次阅读
初探 React 组件 1年以前  |  2174次阅读
wordpress标签页的制作 1年以前  |  2061次阅读
Node.js下通过配置host访问URL 1年以前  |  2001次阅读
js动态创建类和实例化 1年以前  |  1984次阅读
500行PHP代码搞定富文本安全过滤 1年以前  |  1957次阅读
22个HTML5的初级技巧 1年以前  |  1912次阅读
使用 SRI 增强 localStorage 代码安全 1年以前  |  1904次阅读
浅谈浏览器的原生拖拽事件 1年以前  |  1872次阅读
第三版主题上线 1年以前  |  1864次阅读
CSS清除浮动 1年以前  |  1856次阅读
2014年度总结 1年以前  |  1811次阅读
【译】V8 团队眼中的 ES6、ES7及未来 1年以前  |  1801次阅读
利用服务器返回header来传输数据 1年以前  |  1791次阅读
获取元素的计算的样式 1年以前  |  1790次阅读