对于服务器端渲染,我发现了两种方法：
> next.js
>铬无头预渲染(例如react-snap)
NextJs在GitHub和一个很棒的社区上有很多明星,但是另一种方法(chrome无头预渲染)似乎更干净,并且需要几乎零配置才能工作.
有谁有经验与他们一起工作吗？
每个人的主要利弊是什么？
解决方法:
(前段时间我一直在为这个困境而苦苦挣扎,并想与大家分享一些我的个人观点)
SPA应用程序中SSR的一些优点
> SEO / SMO-最理想的因素,可以像标准网站一样实现SPA的可爬网性,
>性能-在预渲染HTML节点的同时,更快地渲染SPA网站,
>资源-就像总是在服务器渲染站点中一样,SSR为您的用户利用现有服务器体系结构的计算能力.
有用的来源：Server-side vs client-side rendering in React apps、Next.js — React Server Side Rendering Done Right.
SEO的实际价值是无与伦比的,在撰写本文时,Google可以正确地抓取SPA(insights & analysis),尽管可以将其视为自然搜索,但通常对于社交媒体来说是不可接受的,因为社交媒体不会轻易产生链接摘录而导致您的业务的缺点.
性能案例是有限的-React Apps(通常是SPA)都可以有效地存储在客户端上.首次运行通常是：安装脱机Web worker,将大量缓存加载到浏览器中.几乎只有在用户第一次加载网站的情况下,这种优势才可行.
资源的可用性或其优势严格地与应用程序体系结构相关,在某些情况下,通过缓存执行可能比完全不涉及服务器更有效.
使用NextJS / Gatsby / SSR应用程序框架
JS的不断发展的性质在这些框架需要与之竞争的过程中非常迅速地推动着这一发展.这暗示了在一段时间内落后于其技术最佳功能的事实.
一个关键的例子是在React-Router v4更新后进行的大肆宣传,该更新风靡一时,但在诸如NextJS Use with React Router 4 #1632之类的框架上踩踏而已,但有很多社区压力,因为开发人员我们*使用提供给我们的架构.
这意味着要减少CRA(和一般的React标准),而要像NextJS一样：
>应用程序结构,下一个/标题,文档,< layout> ;、
> @ zeit / next-css,@ zeit / next-sass,样式为jsx,
>静态异步getInitialProps()模式,
> next-redux-wrapper,next-redux-saga,
><链接预取>从下一个/链接,
>从/ pages /路由,从/ static /提供文件,等等.
并使修补的“感觉”像成熟的CRA一样工作.
另一个失败点是标准的no-SSR应用程序很难移植到像NextJS / Gatsby这样的SSR解决方案中,后者具有自己的规则和体系结构.在一开始就强制做出这样的决定.
无头预渲染
使您的应用程序不受SSR应用程序内解决方案的限制. SPA站点假定使用API而不在服务器上呈现,因此许多模式/程序包没有从头准备好进行SSR,并可能污染您的标准代码库.
如果您寻求SEO / SEM,虽然使用SSR对其进行优化可能不是最佳选择,但它是一个非常简单明了的解决方案.
自动工具(如您的react-snap提供的工具)可能会遇到一些Caveats的问题,其中包括正确快照网站正确HTML输出的问题(例如,对于SEO用途最有价值的HTML输出).
尽管纯粹针对SEO的SSR方法没有什么问题,但是有一个合理的事实,那就是在不久的将来,任何爬网程序都将朝着SPA的最佳爬网能力发展,因此,一段时间后,完整的SSR解决方案可能不是一个好选择.