使用代码拆分和现在 React.Lazy 反应 ssr 的优缺点
the pros and const of react ssr with code splitting and now React.Lazy
我对 ssr 和代码拆分的优点以及仅在客户端上完成的代码拆分感到有些困惑。
我的想法是，服务器先呈现页面会带来更好的体验，而无需解析所有 javascript 然后再呈现服务器。
我对代码拆分如何适合 ssr 模型感到困惑，是 ssr 呈现第一个命中，然后在客户端完成代码拆分吗？
React.Lazy 表示 react.client 全部在客户端完成。它与服务器上的代码拆分有何不同。如果您转到特定路线，那么您是否会为第一次渲染检索该块？
我知道 React.Lazy 都是在客户端完成的，他们说得很有道理。如果在服务器上完成会有什么不同。
代码拆分对 ssr 有什么真正的好处吗？它不仅增加了复杂性吗？
你在这里问了很多问题。在我看来，代码拆分对于大型应用程序很有用，在这种情况下，您构建的捆绑包对于单次加载来说太大了。虽然服务器端呈现对于较小的着陆页样式的页面很有用，因此减少了浏览器中的计算时间。
服务端渲染
- 对 SEO 问题页面有用
请求页面时，服务器会处理请求并构建最终的 HTML 页面，然后将其传送给客户端。
这种方法有利于 SEO 问题页面，因为最终内容在第一个请求中可用，因此搜索引擎能够将其编入索引。
代码拆分
- 对于在不同时间加载内容的页面很有用
如果您的整个网站在不同的加载时间使用太多资源，代码拆分是性能优化的首选技术。您不是在第一次请求时加载所有资源，而是延迟加载直到需要资源。
同时实施两者
假设您的网站包含大量资源，并且您希望在将其处理给客户端之前呈现请求的整个页面，您可能希望同时实施这两种技术。
React.lazy()
React.lazy() 在 React v16.6.0 as a new method of using the Suspense 组件中实现以进行代码拆分。
备注
This feature is not yet available for server-side rendering.
Suspense support will be added in a later release.
总结
Suspense + React.lazy()暂不支持服务端渲染
服务端渲染+代码拆分，客户端不需要额外的资源就可以得到请求的渲染页面。
tl;博士
根据您的用例，您可以仅使用 SSR、仅代码拆分或根据需要将两者结合使用。
SSR的优点
更好的 SEO 因为搜索机器人有标记（不一定依赖于执行 javascript）来建立索引。
更快的初始渲染 因为标记是从服务器发送的，浏览器不必等待执行 javascript 来渲染它. （尽管在 React 被水合客户端之前，标记仍然缺乏交互性）。
首先交付关键CSS。初始页面呈现的关键 CSS 可以内联，更好的用户体验，因为加载的标记已经准备好样式。
更简单的路由拆分。 SSR imo 使路由拆分应用程序的推理变得更简单。例如，您可能有 /about 和 /home 的不同页面，您可以路由拆分以减小包大小（并在需要时在客户端预加载其他路由）。
组合代码拆分您的组件和 SSR
可能不需要服务器呈现整个页面。例如，假设您的主页（您希望服务器呈现）包含一个 Chat 组件，以便用户可以直接向您提问。
如果此组件很大，您可能会决定不在服务器上呈现它，以便用户可以首先获得页面中最重要的部分。这将通过在您的主页组件中拆分此组件来减少您的初始页面加载。
当浏览器解析标记后，它会在主包之后加载您的 Chat 组件。这样您就可以识别并控制您的捆绑包大小。
仅使用代码拆分
如果您对 SSR 的好处不感兴趣，这是构建应用程序 imo 的完美方式。
例如，如果您的应用程序是经过身份验证的用户的用户仪表板，则最好完全不用担心 SSR，只需对应用程序进行代码拆分。另请注意，服务器呈现您的应用程序将花费更多时间在服务器上发送响应（而不是普通的 REST APIs），因为必须生成标记。
回答您的问题：
I am confused how code splitting fits into the ssr model, is it that ssr renders the first hit and then code splitting is done thereafter on the client?
是的，有点。浏览器从服务器接收初始加载，然后客户端负责加载必要的位。现在，您可以决定预加载您的组件服务器端并发送所有内容（请检查我在本答案末尾提到的 react-loadable）。
How would it differ from code splitting on the server. Is that if you go to a specific route then you retrieve that chunk for the first render?
lazy 只是一个更干净的 API，支持 Suspense 代码拆分。理想情况下，当第一次加载路由时，您将服务器呈现初始标记，然后让客户端负责加载下一个位和路由。 Imo Next.js 做得很好。
How would it differ if it was done on the server.
您可以预加载所有组件或仅预加载必要的位。请检查 组合代码拆分您的组件和 SSR 部分。
Is there any real benefit to ssr with code splitting. Does it not just add complexity?
在我看来，一切都有自己的权衡。正如我在 仅使用代码拆分 部分中提到的那样，如果您的用例不需要 SSR 的优点，那么只使用代码拆分就完全没问题了。
Note
Currently lazy (in React v16.6.1) doesn't support SSR completely. You might want to check out react-loadable to handle the cases where you wish to preload components server side.
我对 ssr 和代码拆分的优点以及仅在客户端上完成的代码拆分感到有些困惑。
我的想法是，服务器先呈现页面会带来更好的体验，而无需解析所有 javascript 然后再呈现服务器。
我对代码拆分如何适合 ssr 模型感到困惑，是 ssr 呈现第一个命中，然后在客户端完成代码拆分吗？
React.Lazy 表示 react.client 全部在客户端完成。它与服务器上的代码拆分有何不同。如果您转到特定路线，那么您是否会为第一次渲染检索该块？
我知道 React.Lazy 都是在客户端完成的，他们说得很有道理。如果在服务器上完成会有什么不同。
代码拆分对 ssr 有什么真正的好处吗？它不仅增加了复杂性吗？
你在这里问了很多问题。在我看来，代码拆分对于大型应用程序很有用，在这种情况下，您构建的捆绑包对于单次加载来说太大了。虽然服务器端呈现对于较小的着陆页样式的页面很有用，因此减少了浏览器中的计算时间。
服务端渲染
- 对 SEO 问题页面有用
请求页面时，服务器会处理请求并构建最终的 HTML 页面，然后将其传送给客户端。
这种方法有利于 SEO 问题页面，因为最终内容在第一个请求中可用，因此搜索引擎能够将其编入索引。
代码拆分
- 对于在不同时间加载内容的页面很有用
如果您的整个网站在不同的加载时间使用太多资源，代码拆分是性能优化的首选技术。您不是在第一次请求时加载所有资源，而是延迟加载直到需要资源。
同时实施两者
假设您的网站包含大量资源，并且您希望在将其处理给客户端之前呈现请求的整个页面，您可能希望同时实施这两种技术。
React.lazy()
React.lazy() 在 React v16.6.0 as a new method of using the Suspense 组件中实现以进行代码拆分。
备注
This feature is not yet available for server-side rendering.
Suspense support will be added in a later release.
总结
Suspense + React.lazy()暂不支持服务端渲染
服务端渲染+代码拆分，客户端不需要额外的资源就可以得到请求的渲染页面。
tl;博士
根据您的用例，您可以仅使用 SSR、仅代码拆分或根据需要将两者结合使用。
SSR的优点
更好的 SEO 因为搜索机器人有标记（不一定依赖于执行 javascript）来建立索引。
更快的初始渲染 因为标记是从服务器发送的，浏览器不必等待执行 javascript 来渲染它. （尽管在 React 被水合客户端之前，标记仍然缺乏交互性）。
首先交付关键CSS。初始页面呈现的关键 CSS 可以内联，更好的用户体验，因为加载的标记已经准备好样式。
更简单的路由拆分。 SSR imo 使路由拆分应用程序的推理变得更简单。例如，您可能有
/about和/home的不同页面，您可以路由拆分以减小包大小（并在需要时在客户端预加载其他路由）。
组合代码拆分您的组件和 SSR
可能不需要服务器呈现整个页面。例如，假设您的主页（您希望服务器呈现）包含一个 Chat 组件，以便用户可以直接向您提问。
如果此组件很大，您可能会决定不在服务器上呈现它，以便用户可以首先获得页面中最重要的部分。这将通过在您的主页组件中拆分此组件来减少您的初始页面加载。
当浏览器解析标记后，它会在主包之后加载您的 Chat 组件。这样您就可以识别并控制您的捆绑包大小。
仅使用代码拆分
如果您对 SSR 的好处不感兴趣，这是构建应用程序 imo 的完美方式。
例如，如果您的应用程序是经过身份验证的用户的用户仪表板，则最好完全不用担心 SSR，只需对应用程序进行代码拆分。另请注意，服务器呈现您的应用程序将花费更多时间在服务器上发送响应（而不是普通的 REST APIs），因为必须生成标记。
回答您的问题：
I am confused how code splitting fits into the ssr model, is it that ssr renders the first hit and then code splitting is done thereafter on the client?
是的，有点。浏览器从服务器接收初始加载，然后客户端负责加载必要的位。现在，您可以决定预加载您的组件服务器端并发送所有内容（请检查我在本答案末尾提到的 react-loadable）。
How would it differ from code splitting on the server. Is that if you go to a specific route then you retrieve that chunk for the first render?
lazy 只是一个更干净的 API，支持 Suspense 代码拆分。理想情况下，当第一次加载路由时，您将服务器呈现初始标记，然后让客户端负责加载下一个位和路由。 Imo Next.js 做得很好。
How would it differ if it was done on the server.
您可以预加载所有组件或仅预加载必要的位。请检查 组合代码拆分您的组件和 SSR 部分。
Is there any real benefit to ssr with code splitting. Does it not just add complexity?
在我看来，一切都有自己的权衡。正如我在 仅使用代码拆分 部分中提到的那样，如果您的用例不需要 SSR 的优点，那么只使用代码拆分就完全没问题了。
Note
Currently
lazy(in React v16.6.1) doesn't support SSR completely. You might want to check outreact-loadableto handle the cases where you wish to preload components server side.