ul 更新需要昂贵的 DOM 操作，尽管 React 内部使用了几种巧妙的技术最小化 Dom 操作次数。对于大部分应用而言。使用 React 时不需做大量优化工作就能拥有高性能的用户界面。尽管如此仍然有办法加速你的 React 应用。

优化，面试我就被经常问，我去面 vue 的时候，也被问。

优化不是前端优化就行的，包括服务器 后端 这些。现在网站都很友好，甚至你可以自己搭建或者生成都可以做一个很好的网站，跟 早期CPU 一样，最开始我们不断得增加线路，到后来我们不断增加 芯片，到矩阵。

官方文档告诉了我们几个生产构建打包的东西，我就接触过 Browserify 所以我在这里说一下 Browserify 与 react

Browserify

感谢 Wael Yasmina 一直不嫌麻烦的解决我的问题，而且我总是使用一些翻译的英文与你对话。

通常在使用 javaScript 中，我们常常添加很多脚本标签，js 引入 react 引入啊，jq什么的，这些脚本就非常麻烦，有时候 js 运行机制可能还会导致一些错误发生，而 Browserify 可以解决这些，包括现在捆绑器，npm 模块，我们不需要关注 js 的运行，我们关注点在browserify

您应该只使用该插件来生成代码的发行版，因为在调试(稍后会详细介绍)发行版时，它会产生某种“模糊”:将被部署的代码的最终版本 Already on ‘tinyify’

指令

一共有6个分支，你可以知道使用 Browserify 让浏览器支持 require 通过 babel 识别 Es6 import ，打包，压缩，分割依赖项，指令优化及监听，让自己可以配架构。管理 npm js ，性能优化。

代码分割

为了避免搞出大体积的代码包，在前期就思考该问题并对代码包进行分割是个不错的选择。 代码分割是由诸如 Webpack，Rollup 和 Browserify（factor-bundle）这类打包器支持的一项技术，能够创建多个包并在运行时动态加载。

对你的应用进行代码分割能够帮助你“懒加载”当前用户所需要的内容，能够显著地提高你的应用性能。尽管并没有减少应用整体的代码体积，但你可以避免加载用户永远不需要的代码，并在初始加载的时候减少所需加载的代码量。

后面再说。

值得注意的是 前端部署 （个人理解）

我觉得有时候像一些浏览器抖屏（请求的问题）或者 白屏，这些不应该全都是性能的问题。

我们知道将 **HTML CSS JS **静态资源通过 FTP 软件，上传到 Web 服务器。用户一访问 状态 200，页面就渲染处理了，感觉简简单单👂

利用缓存

计算机大佬们在 HTTP 协议上制定了多种缓存策略。（有时间看看）

• 浏览器缓存是对之前请求过的文件进行缓存，以便下一次访问时重复使用，节省宽带，提高访问速度，降低服务器压力。

协商缓存

• 一种策略是浏览器问服务器有没有变化，没变化就用旧资源。
• 向服务器发送请求，服务器会根据这个请求的 请求头 的一些参数来判断是否命中协商缓存，如果命中，则返回 304 状态码 并带上新的 请求头 通知浏览器从缓存中读取资源
• 304 状态码，表示资源未发生变更，可使用浏览器缓存。

强缓存

这样，通过协商缓存，我们大幅优化了资源未变更时的网络请求，节约大量带宽，网站首屏性能也有不错的提升，美滋滋！
然而仔细观察，发现仍然有协商的过程，一百个静态文件就有一百个协商请求。在资源未发生变更时，追求极致的我们也应该优化掉这个协商请求，毕竟没有买卖就没有伤害！
和协商缓存对应的是使用强缓存，大概过程如下：

• 浏览器不会向服务器发送任何请求，直接从本地缓存中读取文件并返回 200
• 用上强缓存后，协商的请求也被消灭了，网站加载的性能达到极致了。美滋滋！

待续