这篇文章主要介绍如何优化Next.js页面渲染，文中介绍的非常详细，具有一定的参考价值，感兴趣的小伙伴们一定要看完！
第一个问题：宣称前后台同构的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，这在打包和加载过程有一个比较蠢的机制（或许仅仅是我个人观点），那就是但凡React DOM上绑定了style 这些DOM都不会在服务端渲染出来，而是打包抽离成一个小的js文件，在 commons.xxxxx.js 加载完毕之后，再加载这个js,将DOM和内联style渲染到HTML。这就在某种程度上导致了next.js首次渲染是SSR失效了，更为糟糕的是卡顿感十足。
可能有人会说，那就不要写内联style不就好了。但是事实是在大量的后台数据动态渲染页面和用户自定义页面的情况下，不可能做到完全不写内联样式，而去傻乎乎地写一堆className。
所以我们要解决一个问题那就是如何保证，内联style的react dom在首次渲染页面的时候是服务器端直接输出后扔给后台，而不是让 commons.xxxxx.js 卡卡卡卡卡，然后砰的一下蹦出来。
要解决上一个问题，首先要了解Next.js是如何渲染页面的？
在Next.js的规则中，所有页面级的代码都是写在pages文件夹中，比如/pages/home:
export default () => (你瞅啥？这是home页)
而其框架内置的Document组件中，已经帮开发者配置好传统的HTML文件的
, 这些标签作为静态资源的外壳。Document组件中有一个 renderPage() 方法，如果代码正常运行，该方法就会将pages文件夹中的代码和它外部同步渲染到浏览器中。如果开发者希望自定义Document组件只需添加 /pages/_document.js 文件即可。renderPage()本质是一个回调函数，它的作用只有一个那就是 执行React源码中渲染逻辑 同步加载到Next.js的Document组件中形成DOM节点。
重庆分公司
重庆分公司
import Document, { Head, Main, NextScript } from 'next/document'
export default class MyDocument extends Document {
static getInitialProps ({ renderPage }) {
// renderPage()位于next.js特有生命周期函数getInitialProps中。
return renderPage();
}
render () {
return (
没见过标题党吗？
服务端渲染样式
为了能让服务器端渲染样式，我们首先得先做两件事：
在页面首次加载的时候，也就是所谓的SSR.能让 renderPage 方法在服务器端就能对React Dom进行解析，让HTML归HTML，CSS归CSS；
能让 Document 组件在页面切换时，能及时更新
,这样不同的页面就能加载自己所需的script,style。解决方案的登场
隆重介绍神器 styled-components 出场， styled-components 在github上目前为止已经超过1万stars，它的设计初衷在于在服务端渲染的时候，同时渲染出一个ServerStyleSheet，然后把这个ServerStyleSheet送入React DOM树中。它主要就做两件事：
把组件中 styles 抽离到