React SSR、NextJS与Chrome无头预渲染

(我之前一直在努力解决这个难题,我想和大家分享我的一些个人观点)

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

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

有用的来源: Server-side vs client-side rendering in React apps ,请 Next.js — React Server Side Rendering Done Right .

SEO的实际价值是无与伦比的,在写作的时候,谷歌可以适当地爬行SPA。( insights & analysis ,虽然它可以被认为是足够的有机搜索,但对于社交媒体来说,这通常是不可接受的,因为这些社交媒体的链接摘录不会对你的业务造成不利影响。

性能案例是有限的—React应用程序(通常是SPA)可以有效地将站点存储在客户机上。第一次运行通常是:安装离线的Web工作者,将大量的缓存加载到浏览器中。使这一优点几乎只有在第一次加载的情况下,网站的用户。

资源的可用性或它的优点严格地与应用程序体系结构相关,有些情况下,通过缓存可能比涉及到服务器更具性能。

使用nextjs/gatsby/ssr应用程序框架

JS的不断发展的本质是在这些框架需要与进步竞争的问题上非常快地推动这条线。这就意味着在某个时间内,IT技术的最佳功能已经落后。

一个重要的例子是在 反应路由器v4更新 它在暴风雨中使用样板,但却在nextjs等框架上被踩踏。 Use with React Router 4 #1632 虽然社区压力很大,但作为开发人员,我们不得不使用提供给我们的体系结构。

这意味着CRA(和一般的反应标准)越少,nextj就越像:

• 应用程序结构, 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/ ,文件来自 /static/ 等。

使“感觉”被修补工作一样完全羽翼丰满的CRA。

另一个缺点是,标准的no ssr应用程序不太容易移植到ssr解决方案,比如nextjs/gatsby,它有自己的规则和架构。一开始就被迫做出这样的决定。

无头预渲染

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

虽然它可能不是最好的优化服务您的应用与SSR是相当容易和直接的解决方案,如果您寻求搜索引擎优化/扫描电镜。

自动工具(如您提供的 反应捕捉 )可能会与一些 Caveats 包括正确抓取站点的正确HTML输出的问题(例如,对于SEO来说最有价值的问题)。

虽然单纯针对SEO的SSR方法没有任何问题,但有一个合理的事实是,在不久的将来,任何爬虫类都会发展成为SPA的最佳爬虫能力,因此,在一段时间后,完整的SSR解决方案可能不是一个优势。