对于服务器端渲染，我发现了两种方法:
NextJs 在 GitHub 上有很多明星和一个很棒的社区，但另一种方法(chrome headless 预渲染)似乎更干净，需要几乎零配置才能工作。
有没有人有与他们一起工作的经验？
每种方法的主要优缺点是什么？
最佳答案
(前段时间一直在为这个困境苦苦挣扎，想和大家分享一下我的一些个人观点)
SPA 应用程序中 SSR 的一些优点
有用的来源: Server-side vs client-side rendering in React apps 、 Next.js — React Server Side Rendering Done Right 。
SEO 的实际值(value)是无与伦比的，在撰写本文时，主要是 Google 可以正确抓取 SPA( insights & analysis )，虽然它可以被认为足以进行有机搜索，但通常对于社交媒体来说是 Not Acceptable ，因为社交媒体根本不会产生链接的摘录，导致您的业务的缺点。
性能案例仅限于一种 - React Apps(以及一般的 SPA)用于在客户端上有效地存储站点。通常第一次运行:安装离线 Web Worker，将大量缓存加载到浏览器中。使这个优点几乎只在用户第一次加载网站的情况下才有效。
资源的可用性或其优势与应用程序架构严格相关，在某些情况下，缓存可能比涉及服务器的性能更高。
使用NextJS/Gatsby/SSR应用程序框架
JS 不断发展的本质正在快速插入这些框架需要与进步竞争的问题。这意味着在一段时间内落后于其技术最佳功能的事实。
一个关键的例子是在 React-Router v4 更新 之后大肆宣传，它在 Storm 中掀起了样板，但在社区压力很大的情况下踩了像 NextJS Use with React Router 4 #1632 这样的框架，因为开发人员我们被迫使用提供给我们的架构.
这意味着更少的 CRA(以及一般的 React 标准)和更像 NextJS:
next/head、Document、<layout>、@zeit/next-css , @zeit/next-sass , styled-jsx , static async getInitialProps () 模式，next-redux-wrapper , next-redux-saga , <Link prefetch> 来自 next/link , /pages/ 的 BE 路由，从 /static/ 等提供的文件。 并让“感觉”被修补后可以像成熟的 CRA 一样工作。
另一个失败点是标准的无 SSR 应用程序不会很容易地移植到像 NextJS/Gatsby 这样的 SSR 解决方案，它们有自己的规则和架构。最好在一开始就强制做出这样的决定。
headless 预渲染
使您的应用程序免受 SSR 应用程序内解决方案的限制。 SPA 站点假定使用 API 而不在服务器上呈现，因此许多模式/包还没有从头开始准备好 SSR，并且可能会污染您的标准代码库。
如果您寻求SEO/SEM，虽然可能没有最佳的优化方案来为您的SSR服务，但它是一个非常简单明了的解决方案。
自动工具(如您的 react-snap 提供的)可能会遇到一些 Caveats 问题，包括正确捕捉站点正确 HTML 输出的问题(例如，对于 SEO 目的最有值(value)的那个)。
虽然纯粹用于 SEO 的 SSR 方法没有任何问题，但有一个合理的事实，即在不久的将来，任何爬虫都会取得 SPA 的最佳爬虫能力，因此一段时间后，完整的 SSR 解决方案可能不是一个优势。
关于javascript - React SSR，NextJS与Chrome headless 预渲染，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/51011222/