React SSR、NextJS 与 Chrome 无头预渲染

Question

对于服务器端渲染，我发现了两种方法：

• 下一个.js
• chrome 无头预渲染（例如react-snap）

NextJs 在 GitHub 上有很多明星和一个很棒的社区，但另一种方法（chrome 无头预渲染）似乎更干净，需要几乎零配置才能工作。

有没有人有与他们一起工作的经验？
每种方法的主要优缺点是什么？

Answer 1

（前段时间一直在为这个困境苦苦挣扎，想和大家分享一下我的一些个人观点）

SPA 应用程序中 SSR 的一些优点

• SEO/SMO - 最需要的因素，像标准网站一样实现 SPA 的可抓取性，
• 性能 - 更快呈现 SPA 站点，同时预呈现 HTML 节点，
• 资源 - 就像它总是在服务器渲染的站点中一样，SSR 为您的用户利用现有服务器架构的计算能力。

有用的来源：React 应用程序中的服务器端与客户端渲染，Next.js?—?React 服务器端渲染完成。

SEO 的实际价值是无与伦比的，在撰写本文时，主要是 Google 可以正确地抓取 SPA（见解和分析），而对于有机搜索来说它可以被认为是足够的，但对于社交媒体来说是不可接受的，因为链接摘录根本不会对您的业务造成不利影响。

性能案例仅限于一种 - React Apps（以及一般的 SPA）用于在客户端上有效地存储站点。通常第一次运行：安装离线 Web Worker，将大量缓存加载到浏览器中。使这个优点几乎只在用户第一次加载网站的情况下才有效。

资源的可用性或其优势与应用程序架构严格相关，在某些情况下，缓存可能比涉及服务器的性能更高。

使用 NextJS/Gatsby/SSR 应用框架

JS 不断发展的本质正在快速推动这些框架需要与进步竞争的问题。这意味着在一段时间内落后于其技术最佳功能的事实。

一个关键的例子是在React-Router v4 更新之后大肆宣传，它掀起了风暴，但在社区压力很大的情况下踩到了像 NextJS与 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,
• BE 路由来自/pages/，提供的文件/static/等。

并让“感觉”被修补后可以像成熟的 CRA 一样工作。

另一个失败点是标准的无 SSR 应用程序不会很容易地移植到像 NextJS/Gatsby 这样的 SSR 解决方案，它们有自己的规则和架构。最好在一开始就强迫做出这样的决定。

无头预渲染

使您的应用程序免受 SSR 应用程序内解决方案的限制。SPA 站点假定使用 API 而不在服务器上呈现，因此许多模式/包还没有从头开始准备好 SSR，并且可能会污染您的标准代码库。

如果您寻求 SEO/SEM，虽然它可能不是最好的优化以使用 SSR 为您的应用程序提供服务，但这是非常简单和直接的解决方案。

自动工具（如您提供的react-snap）可能会遇到一些注意事项，包括正确拍摄站点正确 HTML 输出的问题（例如，对于 SEO 目的最有价值的那个）。

虽然纯粹用于 SEO 的 SSR 方法没有任何问题，但有一个合理的事实，即在不久的将来，任何爬虫都会取得 SPA 的最佳爬虫能力，因此一段时间后，完整的 SSR 解决方案可能不是一个优势。