React 服务端渲染缓慢原因浅析

React 服务端渲染缓慢原因浅析从属于笔者的Web 前端入门与工程实践

前几日笔者在服务端渲染性能大乱斗:Vue,React,Preact,Rax,Marko 一文中比较了当前流行的数个前端框架服务端渲染的性能表现,下图数值越高越好:

笔者看完这个数据对比之后不由好奇,缘何 React 服务端渲染的性能会如此之差;从设计理念的角度来看 React 本身专注于跨平台的界面库,其保证较好抽象层次的同时势必会付出一定的代价,并且 Facebook 在生产环境中并未大规模应用服务端渲染,也就未花费过多的精力来优化服务端渲染的性能。笔者也对比了下 React 与 Preact 有关服务端渲染的实现代码,确实高度的抽象需要额外的代码逻辑与对象创建,React 本身并没有冗余的部分,只是单纯地大量的毫秒级别额外对象操作的耗时的累加导致了最后性能表现的巨大差异。我们首先看下 Preact 的renderToString的函数实现,其紧耦合于 DOM 环境,以较低的抽象程度换取较少的代码实现:

/** The default export is an alias of `render()`. */
export default function renderToString(vnode,context,opts,inner,isSvgMode) {

  // 获取节点属性
  let { nodeName,attributes,children } = vnode || EMPTY,isComponent = false;
  context = context || {};
  opts = opts || {};

  let pretty = opts.pretty,indentChar = typeof pretty==='string' ? pretty : '\t';

  if (vnode==null) {
    return '';
  }

  // 字符串类型则直接返回
  if (!nodeName) {
    return encodeEntities(vnode);
  }

  // 处理组件
  if (typeof nodeName==='function') {
    isComponent = true;
    if (opts.shallow && (inner || opts.renderRootComponent===false)) {
      nodeName = getComponentName(nodeName);
    }
    else {
      ...

      if (!nodeName.prototype || typeof nodeName.prototype.render!=='function') {
        // 处理无状态函数式组件
        ...
      }
      else {
        // 处理类组件
        ...
      }

      //递归处理下一层元素
      return renderToString(rendered,opts.shallowHighOrder!==false);
    }
  }

  // 将 JSX 渲染到 HTML
  let s = '',html;

  if (attributes) {
    let attrs = objectKeys(attributes);

    //处理所有元素属性
        ...

  }

  // 处理多行属性
  ...

  if (html) {
    // 处理多行缩进
        ...
  }
  else {
    // 递归处理子元素
        ...
  }

  ...

  return s;
}

Preact 的实现还是比较简单明了的,我们继续来看下 React 中涉及到服务端渲染相关的代码,其主要涉及到 ReactDOMServer.js,ReactServerRendering.js,instantiateReactComponent.js,ReactCompositeComponent.js 以及 ReactReconciler.js 等几个文件,其中前两个文件算是专注于服务端渲染,而后三个文件则是用于定义 React 组件以及组件系统的组合与调和机制,其并不耦合于某个具体的平台,也是主要的以牺牲性能来换取较好地抽象层次的实现类。首先我们来从应用的角度考虑下两个可能影响服务端渲染性能的因素,一个是对于环境变量的设置。在 React 的源代码中我们可以发现很多如下的调试语句:

if (process.env.NODE_ENV !== 'production') {
    ...
}

显而易见如果我们没有将环境变量设置为production,势必会在运行时调用更多的调试代码,拖慢整体性能。另一个有可能拖慢服务端渲染性能的因素是 React 在生成 HTML 后会对元素进行校验和计算并且附加到元素属性中:

<div data-reactroot="" data-reactid="1" data-react-checksum="-492408024">
...
</div>

上述代码中的data-react-checksum就是计算而来的校验和,该计算过程是会占用部分时间,不过影响甚微。笔者对于renderToStringImpl函数进行了断点性能分析,主要是利用console.time记录函数执行时间并且进行对比:

...
return transaction.perform(function () {
      var componentInstance = instantiateReactComponent(element,true);
      var reactDOMContainerInfo = ReactDOMContainerInfo();
      console.time('transaction');
      console.log('transaction 开始:' + Date.now());
      var markup = ReactReconciler.mountComponent(componentInstance,transaction,null,reactDOMContainerInfo,emptyObject,0 /* parentDebugID */
      );
      console.log('transaction 结束:' + Date.now());
      console.timeEnd('transaction');
      ...
      if (!makeStaticMarkup) {
        console.time('markup');
        markup = ReactMarkupChecksum.addChecksumToMarkup(markup);
        console.timeEnd('markup');

      }
      return markup;
...
// 运行结果为:
// transaction: 12.643ms
// markup: 0.249ms

从运行结果上可以看出,计算校验和并未占用过多的时间比重,因此这也不会是拖慢服务端渲染性能的主因。实际上当我们调用ReactDOMServer.renderToString时,其会调用ReactServerRendering.renderToStringImpl这个内部实现,该函数的第二个参数makeStaticMarkup用来标识是否需要计算校验和。换言之,如果我们使用的是ReactDOMServer.renderToStaticMarkup,其会将makeStaticMarkup设置为true并且不计算校验和。完整的一次服务端渲染的对象与函数调用流程如下:

整个流程同样是递归解析组件树到 HTML 标记的过程,笔者同样是以断点计时的方式进行追踪,有趣的一个细节是从 Transaction 开始到首次调用ReactReconciler 中mountComponent函数之间间隔 2ms,换言之,有大量的时间花费在了具体的解析之外,可能这种类型的抽象带来的额外消耗会是 React 服务端渲染性能较差的原因之一吧。

版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。

相关推荐


react 中的高阶组件主要是对于 hooks 之前的类组件来说的,如果组件之中有复用的代码,需要重新创建一个父类,父类中存储公共代码,返回子类,同时把公用属性...
我们上一节了解了组件的更新机制,但是只是停留在表层上,例如我们的 setState 函数式同步执行的,我们的事件处理直接绑定在了 dom 元素上,这些都跟 re...
我们上一节了解了 react 的虚拟 dom 的格式,如何把虚拟 dom 转为真实 dom 进行挂载。其实函数是组件和类组件也是在这个基础上包裹了一层,一个是调...
react 本身提供了克隆组件的方法,但是平时开发中可能很少使用,可能是不了解。我公司的项目就没有使用,但是在很多三方库中都有使用。本小节我们来学习下如果使用该...
mobx 是一个简单可扩展的状态管理库,中文官网链接。小编在接触 react 就一直使用 mobx 库,上手简单不复杂。
我们在平常的开发中不可避免的会有很多列表渲染逻辑,在 pc 端可以使用分页进行渲染数限制,在移动端可以使用下拉加载更多。但是对于大量的列表渲染,特别像有实时数据...
本小节开始前,我们先答复下一个同学的问题。上一小节发布后,有小伙伴后台来信问到:‘小编你只讲了类组件中怎么使用 ref,那在函数式组件中怎么使用呢?’。确实我们...
上一小节我们了解了固定高度的滚动列表实现,因为是固定高度所以容器总高度和每个元素的 size、offset 很容易得到,这种场景也适合我们常见的大部分场景,例如...
上一小节我们处理了 setState 的批量更新机制,但是我们有两个遗漏点,一个是源码中的 setState 可以传入函数,同时 setState 可以传入第二...
我们知道 react 进行页面渲染或者刷新的时候,会从根节点到子节点全部执行一遍,即使子组件中没有状态的改变,也会执行。这就造成了性能不必要的浪费。之前我们了解...
在平时工作中的某些场景下,你可能想在整个组件树中传递数据,但却不想手动地通过 props 属性在每一层传递属性,contextAPI 应用而生。
楼主最近入职新单位了,恰好新单位使用的技术栈是 react,因为之前一直进行的是 vue2/vue3 和小程序开发,对于这些技术栈实现机制也有一些了解,最少面试...
我们上一节了了解了函数式组件和类组件的处理方式,本质就是处理基于 babel 处理后的 type 类型,最后还是要处理虚拟 dom。本小节我们学习下组件的更新机...
前面几节我们学习了解了 react 的渲染机制和生命周期,本节我们正式进入基本面试必考的核心地带 -- diff 算法,了解如何优化和复用 dom 操作的,还有...
我们在之前已经学习过 react 生命周期,但是在 16 版本中 will 类的生命周期进行了废除,虽然依然可以用,但是需要加上 UNSAFE 开头,表示是不安...
上一小节我们学习了 react 中类组件的优化方式,对于 hooks 为主流的函数式编程,react 也提供了优化方式 memo 方法,本小节我们来了解下它的用...
开源不易,感谢你的支持,❤ star me if you like concent ^_^
hel-micro,模块联邦sdk化,免构建、热更新、工具链无关的微模块方案 ,欢迎关注与了解
本文主题围绕concent的setup和react的五把钩子来展开,既然提到了setup就离不开composition api这个关键词,准确的说setup是由...
ReactsetState的执行是异步还是同步官方文档是这么说的setState()doesnotalwaysimmediatelyupdatethecomponent.Itmaybatchordefertheupdateuntillater.Thismakesreadingthis.staterightaftercallingsetState()apotentialpitfall.Instead,usecom