观麦最佳实践

[liyatang]

如题，准备做一个最佳实践的收录，朝花夕拾，温故知新。也方便新人少踩坑，更快容易融入。

形式：评论留下你的最佳实践，我定时收集整理到 wiki 观麦最佳实践上。

[Pines-Cheng]

这个issue不要关，最近事太多，也来不及整理，只能零碎地贴点东西。

webpack生产环境建议使用DLL，能够显著地提升build和rebuild的速度，而这些软性的东西对开发的影响其实比大家想象的要大。

但是在生产环境使用DLL要谨慎，因为DLL不会对包做任何解析及优化，会一股脑全部打进去，这点在使用echart、lodash的按需加载的写法的时候特别明显，会直接导致按需加载的写法失效。

import echarts from 'echarts/lib/echarts';
import 'echarts/lib/chart/pie';
import 'echarts/lib/chart/line';
import 'echarts/lib/chart/gauge';

[Pines-Cheng]

性能优化方面，WebPageTest可以生成很多不错的报表和统计数据，相比DevTools，更方便宏观的查看性能分析统计的结果。

也可以部署在本地并且与CI集成，但是比较复杂且耗费人力。我们是暂时没精力折腾了。

其中WebpageTest内置的网站图片分析工具Website Speed Test Image Analysis Tool简直太强大太详细了太全面了，目前为止最好，没有之一。

它不仅仅是从单纯的格式和压缩的角度告诉你图片应该被压缩到多少，而是深入到实际的网页，分析网页的每一张图片显示需要多少像素，图片实际有多少像素，可以被裁减为多少像素，能够节省百分之多少。太人性化了。

[liyatang]

@Pines-Cheng 生产环境建议用 DLL，开发环境也用 DLL，这样更快。

另外 echarts 本就不应该打进DLL吧，echarts 非高频用。

那 echarts 是不应该进 dll。那在构建或增量构建 echarts 时就会非常耗费计算资源，一开始也是和你上诉代码一样写法，非常卡。

后来还是把 echarts 拆出去了异步加载，整个 echarts.min.js 也就 230kb 左右，完全可以接受。 拆出去之后也不在 webpack 里构建，也快了很多。

另外，lodash 写的时候不用刻意按需加载，这类劳动力可交给其他工具去实现（不知道有没有）。 比如有赞按需加载插件 babel-plugin-zent

[Pines-Cheng]

DevTools 的 Performance 性能优化真的特别好用，特别好用。就是文档什么的太少，并且和实际的业务（功能）结合得太紧，所以基本只能靠自己摸索。官方文档在这里Get Started With Analyzing Runtime Performance，部分中文。

这里一个接口返回消耗大量的时间，后来发现是render前使用了filter方法过滤数据，filter方法会生成新的数组，导致PureRender失效。

这里两个接口是同步请求的，一个返回才会发起另外一个，分析代码才发现两个接口请求用了两个yield，而不是yield[ ]或Promise.all[ ]。

我用到的还只是冰山一角，就已经暴露出了很多问题了。

[Pines-Cheng]

extract-text-webpack-plugin的allChunks: true谨慎使用，参数为true的情况下，整个工程所有的CSS全部会被抽取到一个文件中去，如果你又不幸的开启了图片转base64并且工程中小图还挺多的情况下：

{
    test: /\.(jpe?g|png|gif|svg)$/i,
    use: [
      {
        loader: 'url-loader',
        options: {
          limit: 1024 * 8,
          publicPath: config.public,
          name: 'img/[name].[hash:8].[ext]'
        }
      }
    ]
  }

那你的首页的CSS会极其庞大！且minify和Gzip对它的作用远比不上纯CSS那么明显。因为图片转base64之后，体积会增大1/3，并且minify和Gzip都对其作用微乎其微。

关于Base64，可以看这个Base64笔记科普。

GZIP 是一种可以作用于任何字节流的通用压缩程序。它会在后台记忆一些之前看到的内容，并尝试以高效方式查找并替换重复的数据片段。（欲知详情，请参阅浅显易懂的 GZIP 低阶说明。）但实际上，GZIP 对基于文本的内容的压缩效果最好，在压缩较大文件时往往可实现高达 70-90% 的压缩率，而如果对已经通过替代算法压缩过的资产（例如，大多数图片格式）运行 GZIP，则效果甚微，甚至毫无效果。

因此，使用extract-text-webpack-plugin 一定要记得把webpack的打包信息给过一遍，特别是注意emitted（喷出，意思是没打包进去，打包成单独的文件了）和build（打包进去了）,就会发现很多问题。因为JS的打包结果可以用webpack的一些图形化的分析工具分析，而CSS暂时还没发现图形化的分析工具。

这里两个比较大的字体相关的CSS被打包进去了，查看代码才发现有人把字体文件给copy到CSS里面去了。而第二个字体文件根本就没用上。

[Pines-Cheng]

React 性能问题排查

Profiling Components with the Chrome Performance Tab

In the development mode, you can visualize how components mount, update, and unmount, using the performance tools in supported browsers. For example:

React Developer Tools

The React Developer Tools Chrome extension has a built-in feature for visualizing component updates. This is helpful for detecting unnecessary render cycles. To use it, first make sure to install the extension here.

Then, open the extension by clicking the “React” tab in the Chrome DevTools and check “Highlight Updates”.

Then, simply use your app. Interact with various components and watch the DevTools work its magic.

The React Developer Tools highlights components that are re-rendering at a given point in time. Depending on the frequency of updates, a different color is used. Blue shows infrequent updates, ranging to green, yellow, and red for components that update frequently.

Seeing yellow or red isn’t necessarily a bad thing. It would be expected when adjusting a slider, or other UI element that triggers frequent updates. But if you click a simple button and see red- it may mean that something is awry. The purpose of the tool is to spot components that are updating unnecessarily. As the app developer, you should have a general idea which components should be updating at a given time.

参考

下面两篇可以撸一遍：

• High Performance React: 3 New Tools to Speed Up Your Apps
• Optimizing Performance