详解Next.js页面渲染的优化方案
在过去一年的工作中我所使用的js框架是Next.js,尽管这个框架在前后端同构方面有着绝佳的体验，但是当页面js文件过大以及preload过多的时候还是会出现页面跳转卡顿和渲染阻塞等比较糟糕的用户体验问题。由于我之前既不知道这个框架的工作原理，自然也就不知道如何去优化它。乘着农历春节前工地活少所以稍微研究一下。
第一个问题：宣称前后台同构的Next.js为何会出现卡顿现象？
Next.js中的特有生命周期hook函数getInitialProps会在页面渲染的时候判断浏览器是否为首次渲染，如果是则是服务端渲染网页，如果不是则是客户端渲染。在页面首次渲染的时候，会加载commons.xxxxx.js文件，这个文件中打包了react.js、next.js以及相关的框架代码也就是如果是客户端渲染打包后的commons.xxxxx.js负载了整个前端的页面逻辑，这个文件相对比较大一般会在180kb以上。如果仅从文件大小角度来说，这个文件并不算大,就算利用了next.js的preload机制把文件大小放到300kb以上，也还行。但是一旦这个文件阻塞了页面的渲染，页面的渲染要等到commons.xxxxx.js加载完毕之后才渲染，那问题就来了。
在next7中使用的打包工具是webpack4，这在打包和加载过程有一个比较蠢的机制（或许仅仅是我个人观点），那就是但凡ReactDOM上绑定了style这些DOM都不会在服务端渲染出来，而是打包抽离成一个小的js文件，在commons.xxxxx.js加载完毕之后，再加载这个js,将DOM和内联style渲染到HTML。这就在某种程度上导致了next.js首次渲染是SSR失效了，更为糟糕的是卡顿感十足。
可能有人会说，那就不要写内联style不就好了。但是事实是在大量的后台数据动态渲染页面和用户自定义页面的情况下，不可能做到完全不写内联样式，而去傻乎乎地写一堆className。
所以我们要解决一个问题那就是如何保证，内联style的reactdom在首次渲染页面的时候是服务器端直接输出后扔给后台，而不是让commons.xxxxx.js卡卡卡卡卡，然后砰的一下蹦出来。
要解决上一个问题，首先要了解Next.js是如何渲染页面的？
在Next.js的规则中，所有页面级的代码都是写在pages文件夹中，比如/pages/home:
exportdefault()=>(你瞅啥？这是home页)
而其框架内置的Document组件中，已经帮开发者配置好传统的HTML文件的
,这些标签作为静态资源的外壳。Document组件中有一个renderPage()方法，如果代码正常运行，该方法就会将pages文件夹中的代码和它外部同步渲染到浏览器中。如果开发者希望自定义Document组件只需添加/pages/_document.js文件即可。renderPage()本质是一个回调函数，它的作用只有一个那就是执行React源码中渲染逻辑同步加载到Next.js的Document组件中形成DOM节点。
importDocument,{Head,Main,NextScript}from'next/document'
exportdefaultclassMyDocumentextendsDocument{
staticgetInitialProps({renderPage}){
//renderPage()位于next.js特有生命周期函数getInitialProps中。
returnrenderPage();
}
render(){
return(
没见过标题党吗？
服务端渲染样式
为了能让服务器端渲染样式，我们首先得先做两件事：
- 在页面首次加载的时候，也就是所谓的SSR.能让renderPage方法在服务器端就能对ReactDom进行解析，让HTML归HTML，CSS归CSS；
- 能让Document组件在页面切换时，能及时更新,这样不同的页面就能加载自己所需的script,style。
解决方案的登场
隆重介绍神器styled-components出场，styled-components在github上目前为止已经超过1万stars，它的设计初衷在于在服务端渲染的时候，同时渲染出一个ServerStyleSheet，然后把这个ServerStyleSheet送入ReactDOM树中。它主要就做两件事：
- 把组件中styles抽离到