前言 在目前的前端领域，单页web应用（SPA）已经有了比较高的占有率，比较主流的web框架React、Angular、Vue几乎已经统治了前端市场。...单页应用确实带来了更好的前后端分离，以及用户体验好、快，内容的改变不需要重新加载整个页面等等的优点，喜忧参半，SPA应用首屏加载慢、白屏以及 SEO 等问题也就慢慢显露出来。...如果假设你需要更好SEO和内容到达时间 (time-to-content) ，如果你使用服务器端渲染 (SSR) 只是用来改善少数页面，那么这个时候你可能更需要预渲染，优点是设置预渲染更简单，你可以获得...录了两个GIF点击刷新体验下差别，提前在调试工具钩上Disable cache，每次刷新都不会使用缓存，重新向服务器发起请求。没有使用预渲染： ? 使用预渲染： ?...可以点击下面链接亲自体验一下，Demo地址： 没有预渲染Demo 预渲染Demo 不足 预渲染的只是快照页面，不适合频繁变动的页面 设置路由越多，构建时间越长 这是我使用时感觉比较遗憾的地方，并不一定全面
这意味着用户在浏览器中请求页面时，会直接收到服务器生成的HTML，而不是一个空白的页面，然后再通过JavaScript填充内容。...CSR通常会加载一个空白的HTML页面，然后使用JavaScript异步请求数据并渲染页面，这可能导致首次加载时的白屏延迟。而SSR则在服务器端生成完整的HTML页面，减少了客户端的渲染工作。 2....为什么选择服务端渲染（SSR） 2.1 提升性能 SSR可以显著减少首次加载的时间，因为浏览器直接接收到完整的HTML页面，而不需要等待JavaScript的下载和执行。...如何实现服务端渲染（SSR） 3.1 使用服务器端框架 一些流行的服务器端框架，如Next.js（React）、Nuxt.js（Vue.js）、Angular Universal（Angular）等，提供了...3.3 数据预取 在SSR中，通常需要提前加载数据并将其注入到HTML中，以确保页面在客户端渲染时具备所需的数据。 4.
同源链接 案例中，我们将开启一个服务器端渲染 Server-Side Rendering(SSR) 的项目： ssr-app ├── public │ └── test.txt ├── index.ejs...node index.js 开启服务后，整个页面渲染如下。 我们触发下 Download File: test.txt 超链接，test.txt 被下载。...上面两小节通过超链接下载和通过 Blob 下载都是自动调起浏览器下载，下载的进度浏览器进行反馈，文件小的时候浏览器会很快下载完并提示，但是文件很大的话，那么下载就很慢了，准确来说数据拉取很慢，点击之后页面很久才会响应...是否让用户知道数据加载到哪里了呢，加载完后浏览器吊起下载？ 需要解答上面这个问题，其实我们解决问题我们如何获取到文件加载的进度呢？ 即可。...结合 angular 使用 axios 在 react 和 vue 框架开发的时，用的比较频繁。笔者使用的 angular 框架来开发，其中集成了 @angular/common/http 模块。
但是，Qwik更极端，他的目标是 —— 干掉所有不必要的JS耗时，这里的耗时包括两部分： JS作为静态资源加载的耗时 JS运行时的耗时 超超超细粒度hydrate 如果说传统SSR的粒度是「整个页面」。...比如在Counter中，onClick带后缀，那么点击回调是懒加载的，所以首屏渲染不会包含「点击后的逻辑」对应的JS代码。...在点击按钮后，会发起2个JS请求，第一个请求返回的是「点击后的逻辑」： 第2个JS请求返回的是「组件重新render的逻辑」： 这两段代码执行后，Counter变为1。...当钟露出后，会发起两个JS资源请求： useClientEffect的逻辑 Clock组件重新渲染的逻辑 如果审查元素，在钟露出前，指针对应元素都是不动的： 当钟露出，加载并执行JS代码后，才开始执行动效...我们发现，有一条评论被折叠了，点击后会展开这条评论： 点击这个行为会请求： 点击逻辑对应的JS代码 这条评论对应组件的重新渲染逻辑 此时，评论数据才会出现在qwik/json中，因为点击交互激活了这个数据
而 Angular Universal 会在服务端通过一个被称为服务端渲染（server-side rendering - SSR）的过程生成静态的应用页面。...它可以生成这些页面，并在浏览器请求时直接用它们给出响应。 它也可以把页面预先生成为 HTML 文件，然后把它们作为静态文件供服务端使用。...Angular Universal 可以为你生成应用的静态版本，它易搜索、可链接，浏览时也不必借助 JavaScript。它也让站点可以被预览，因为每个 URL 返回的都是一个完全渲染好的页面。...会把 appId 值（它可以是任何字符串）添加到服务端渲染页面的样式名中，以便它们在客户端应用启动时可以被找到并移除。...它会把客户端请求转换成服务端渲染的 HTML 页面。如果你使用不同于Node的服务端技术，你需要在该服务端的模板引擎中调用这个函数。 第一个参数是你以前写过的 AppServerModule。
你知道 Angular Universal 吗？可以帮助网站提供更好的 SEO 支持哦！一般来说，普通的 Angular 应用是在 浏览器 中运行，在 DOM 中对页面进行渲染，并与用户进行交互。...Angular 的 SSR 有一些编译和构建时的设置，甚至需要一些代码的改动。下面看看我们是怎么做的吧！...这么做的好处是，我们可以先用静态网页抓住用户的注意力，在用户浏览网页的时候，同时加载整个 Angular 应用。这给了用户一个非常好的极速加载的体验。...而 prerender（npm run prerender）会在构建时生成静态 HTML 文件。...针对页面数量较少、又有 SEO 需求的网站或系统，则可以考虑使用 Universal 和 SSR 技术。
以及通常在 SCR 中当我们点击任何页面中的导航链接并不会向服务端发起请求，而是通过下载的 JS 脚本中的路由模块(比如 ReactRouter、VueRouter 这样的模块)重新执行 JS 来处理页面跳转从而进行页面重新渲染...在页面初始化后，网站所有的 HTML 内容都是在客户端通过执行 JS 生成，并不需要再次请求服务器即可重新渲染 HTML 。...因为它并不需要在客户端浏览器上再次下载和执行 JavaScript 脚本来进行页面渲染。...注意，在 React、Vue 中 hydration 并不意味这重新渲染。因为在 Server 端已经渲染了和 Client 完全相同的 DOM 结构所以完全没有必要在此重新渲染。...那么难免需要在用户触发交互时动态生成对应的事件处理函数进行执行。
以及通常在 CSR 中当我们点击任何页面中的导航链接并不会向服务端发起请求，而是通过下载的 JS 脚本中的路由模块(比如 ReactRouter、VueRouter 这样的模块)重新执行 JS 来处理页面跳转从而进行页面重新渲染...在页面初始化后，网站所有的 HTML 内容都是在客户端通过执行 JS 生成，并不需要再次请求服务器即可重新渲染 HTML 。...因为它并不需要在客户端浏览器上再次下载和执行 JavaScript 脚本来进行页面渲染。...注意，在 React、Vue 中 hydration 并不意味着重新渲染。因为在 Server 端已经渲染了和 Client 完全相同的 DOM 结构所以完全没有必要在此重新渲染。...那么难免需要在用户触发交互时动态生成对应的事件处理函数进行执行。
当然Vue有Nuxt.js，Angular有 Angular Universal。 正式开始之前，强烈推荐Next.js的官方文档，挺清晰易懂。...基于文件路径的路由 页面 一般前端web应用都可以简化为，基于路由的页面和API接口两部分。Next的路由系统基于文件路径自动映射，不需要做中性化的配置。这就是约定大于配置。...getServerSideProps（SSR）每次访问时请求数据 页面中export一个async的getServerSideProps方法，next就会在每次请求时候在服务端调用这个方法。...也就是使用它的页面，如果是浏览器渲染你需要在组件内再显示地请求一次。开发体验不太好。 如果没有特殊问题，建议使用getServerSideProps替代getInitialProps方法。...Next 在9.5.0之后getStaticProps方法可以增加revalidate的属性以此来重新生成缓存，这点就很强大：页面加载仍然很快，页面永不离线，即使重新生成失败，老的还可以访问，而且可以大幅减少数据库
应用支持全量创建和增量修改页面内容，仅需要一份代码实现。 最早期的 Web 中，所有内容都由服务端页面产生，用户通过超链接访问或者表单提交来进行页面跳转与交互。...因此模版内容任何情况都不会暴露到页面中。典型代表包括 Angular（JIT）、Vue； 对于渲染后模版，模版自身会被浏览器端当作内容渲染，而后模版引擎基于由模版生成的 DOM 树进行后续操作。...并且由于内容与用户无关，仍然不需要在服务器端进行计算过程（非实时数据敏感的页面），可以在构建时完成全部操作，或者使用基于 API 事件的动态构建策略并缓存。...(SSR lv.3 (真 SSR) 效果) 为了能够在不使用 CSR 的情况下也能得到最终视图，需要在服务器端进行身份认证（一般基于 Cookie），并且根据用户身份返回专有内容，这时候需要在服务器端进行实时渲染...销毁 SSR 产生的全部内容，由 CSR 重新创建内容。 Level 1：Rehydrate。在可能的情况下复用 SSR 的视图节点，不再重新创建。 Level 2：Resume。
SSR 只是给我们准备好了初始的数据和 HTML, 实际上和 CSR 一样，我们还是需要加载完整的客户端程序，然后在浏览器端重新渲染一遍(更专业的说是 Hydration 水合/注水)，才能让 DOM...和 SSR 的区别是，SSG 是在构建时渲染的。 和 CSR 一样，因为是静态的，所以在服务端不需要渲染运行时，部署在静态服务器就行了。...对于内容为中心的站点来说，实际上并不需要太多交互，客户端程序还有较大压缩的空间。 在构建时渲染，如果内容变更，需要重新构建，比较麻烦 ISG - 增量静态生成 ISG 是 SSG 的升级版。...ISG 依旧会在构建时预渲染页面，但是这里多出了一个服务端运行时，这个运行时会按照一定的过期/刷新策略(通常会使用 stale-while-revalidate )来重新生成页面。...而 Foo、Bar 可以按照一定的策略来按需加载和水合，比如在视口可见时、浏览器空闲时，或者交给 React Concurrent Mode 根据交互的优先级来加载。
不需要服务器计算——所以您的页面将加载快。而且一个单独的HTML文件非常容易在Netlify上托管，通过连接Git存储库或通过Netlify Drop上传。这是我之前创建的一个。...## 服务器端渲染（SSR）随着Web的发展，出现了更大的站点和更动态的体验的需求，从而出现了服务器端渲染（SSR）的崛起。SSR是一种渲染方法，其中Web页面在请求时在服务器上构建。...与 SSR 类似，CSR 最适合动态实时数据，但它也有一些缺点。使用 CSR 的页面上可能需要处理数百兆字节的 JavaScript，因此您的网站可能加载和显示数据很慢。...## 静态站点生成 (SSG)静态站点生成（SSG）是预先生成HTML页面的过程，以便在不需要服务器端渲染（SSR）或客户端渲染（CSR）的情况下立即向用户提供服务。...该页面的以前（过时）版本将被提供，直到在后台重新验证和重新生成该页面，下一个请求该页面的请求将接收更新的版本。
这是一套基于SSR（服务端渲染）的架构。要了解他的特点，我们需要先了解传统SSR的缺陷。 在传统SSR中，首屏渲染时，服务端会向浏览器输出HTML结构。...传统SSR架构的页面随着应用体积变大，TTI指标会持续走高。 孤岛架构的目的就是为了优化SSR架构下TTI指标的问题。...SSR让用户能够更早看到页面，孤岛架构让页面中重要的部分（立刻购买按钮）可以更早被点击。...比如在Counter中，onClick带后缀，那么点击回调是懒加载的，所以首屏渲染不会包含「点击后的逻辑」对应的JS代码。...在点击按钮后，会发起2个JS请求，第一个请求返回的是「点击后的逻辑」： 第2个JS请求返回的是「组件重新render的逻辑」： 这两段代码执行后，Counter变为1。
性能 TTFB：首字节时间(Time to First Byte)——从点击链接 到 接收第一个字节内容 之间的时间。 FP：首次绘制(First Pain)——第一次有像素对用户可见的时间。...SSR 页面通常看起来具有欺骗性的加载完成和可交互性，但在执行客户端JS并绑定事件处理之前，页面实际上无法响应输入。这在移动设备上可能持续几秒甚至几分钟。...也许你自己也经历过这种情况——在页面看起来已经加载后的一段时间内，点击或触摸什么都没反应。这很快变得令人沮丧......“为什么没有反应？ 为什么我不能滚动？...为了使客户端 JavaScript 能够不用重新请求服务器，就能准确地获取服务器返回的用于呈现其 HTML 的所有数据，当前的 SSR 解决方案通常将UI的数据响应序列化， 以 Script 标签形式存放在...只有在 bundle.js 完成加载和执行后，页面才会变为可交互。 从使用 Rehydration SSR 站点收集的性能数据显示，这种用法应极力避免。
浏览器接收到这样的文档响应之后，会根据文档内的链接加载脚本与样式资源，并完成以下几方面主要工作：执行脚本、进行网络访问以获取在线数据、使用 DOM API 更新页面结构、绑定交互事件、注入样式，以此完成整个渲染过程...这有赖于社区生态的发展，上面提到 CSR 的框架/类库（当然还有没提到，笔者本身也很少实践的 Angular、Svelte 等），都有非常优秀的 SSR 方案。...在此基础上，另外对于一些需要在客户端激活的内容，如 Vue 实例接管组件行为、React Effect 在客户端的触发执行，则由编译时生成 Bundle，并在响应页面内的超链接脚本额外附着。...优势之上，SSR 也带来了一些局限： 「引入成本高」：SSR 方案重新将视图渲染的工作交给了服务器做，这就引入了新的概念和技术栈（如 Node），并且带来了更高的服务器硬件成本和运维成本； 「响应时间长...说它是缝合怪，是因为它与 CSR 一样，只需要页面托管，不需要真正编写并部署服务端，页面资源在编译完成部署之前就已经确定；但它又与 SSR 一样，属于一种 Prerender 预渲染操作，即在用户浏览器得到页面响应之前
当然Vue有Nuxt.js，Angular有 Angular Universal，甚至Svelte也有Sapper 。 正式开始之前，强烈推荐Next.js的官方文档，挺清晰易懂。...基于文件路径的路由 页面 一般前端web应用都可以简化为，基于路由的页面和API两部分。Next的路由系统基于文件路径自动映射，不需要做中性化的配置。 一般都约定在根目录pages文件夹内： ....`getServerSideProps`（SSR）每次访问时请求数据 页面中export一个async的getServerSideProps方法，next就会在每次请求时候在服务端调用这个方法。...也就是使用它的页面，如果是浏览器渲染你需要在组件内再显示地请求一次。开发体验不太好。 如果没有特殊问题，建议使用getServerSideProps替代getInitialProps方法。...Next 在9.5.0之后getStaticProps方法可以增加revalidate的属性以此来重新生成缓存，这点就很强大：页面加载仍然很快，页面永不离线，即使重新生成失败，老的还可以访问，而且可以大幅减少数据库
随着Angular、React和Vue的兴起，SPA开始流行，单页面应用可以在不重载整个页面的情况下，通过ajax和服务器进行交互，高效更新部分页面，这无疑带来了良好的用户体验。...Vue SSR适用场景及解决的问题 我们主要在管理后台系统和内嵌H5电商页中使用Vue，对于管理后台系统，不需要考虑SEO和首屏渲染时间，所以是否用SPA的方式其实问题不大。...而对于电商页，虽然不需要SEO，但是首屏渲染变得十分重要。一般的SPA页面打开时，HTML大体的结构如下： <!...显而易见，服务端渲染少了在浏览器加载的过程，解决了页面最开始白屏的问题，明显的提高了首屏渲染的速度。 目前我们主要在电商导购页、挖客分享页中使用Vue的SSR，接下来我们主要讲SSR的实现。...然而在使用SSR时，我们在asyncData这个钩子中发起请求获取数据，此时并不能获取到window对象下的localStorage这个对象。
对SEO依赖程度不高且用户预期页面加载后会有大量交互操作的场景。 CSR技术挑战： 首次加载时由于缺少初始内容，搜索引擎可能无法正确索引页面，影响SEO排名。...SSR技术挑战： 每次用户请求都需服务器重新计算和渲染页面，增加了服务器端的CPU和内存消耗。 状态管理和缓存策略设计较为复杂，尤其是在处理动态内容和用户登录状态时。...SSR优点：利于SEO，用户首次访问即可看到完整内容，对于加载速度要求高的场景如新闻网站尤为关键。 SSR缺点：服务端负载高，每次请求都需要重新渲染整个页面，维护成本相对较高。...同构渲染案例：Next.js、Nuxt.js等框架构建的应用，兼顾SEO与性能，例如GitHub的个人主页，首次加载时SSR生成HTML，后续交互由CSR接管。...结论 在决定采用哪种渲染方式时，前端工程师应根据项目需求权衡SEO优化、首屏加载速度、服务端资源消耗和用户体验等因素。
比如，你使用 vue 去开发一个运营活动的项目，首屏加载缓慢，你应该怎么办呢？又比如，你开发官网，你选择 ssr 还是 spa 呢？...本文，我们来聊聊遇到前端加载缓慢，应该怎么做～ 框架生命周期熟悉使用 现在前端框架已是三足鼎立 -- Angular，React 和 Vue。...接口处理 接口方面，可以考虑下面的处理方案： 避免同个接口多次发起请求 避免不必要的接口请求 需要缓存的数据，进行缓存，不需要发起二次请求 列表接口采用分页处理，避免一次性加载数据，从而造成系统卡顿...减少重绘和重排，他们会导致页面重新渲染 DOM 节点元素需要语义化，不能都一股脑的使用 DIV 元素，这样不利于 SEO；起码在对外的系统上要注重语义化的处理 老生常谈的点了：样式需要放在 ...样式靠后会使得骨架 HTML 看起来辣眼睛；脚本提前加载会造成页面阻塞。
，融合互补，例如： ISR（Incremental Static Regeneration）：增量静态再生成，运行时定期重新生成静态 HTML SSG 降级 SSR：未命中预先生成的静态 HTML 时，...立即进行 SSR SSR 带静态缓存：SSR 完成之后，将结果缓存起来，下次命中静态缓存直接返回（相当于 SSG） SSG 结合 CSR：编译时生成静态部分（页面外框），CSR 填充动态部分（页面内容）...SSG 相当于把 SSR 的渲染过程前移到了编译时，从而优化掉这部分耗时，达到极佳的页面加载性能。...内容更新其实就是重新 SSG，所以只缺一个更新时机…… 另一个不那么显而易见的限制是静态内容的数量，因为渲染工作要在编译时全部完成，如果静态数据有 100 万条，就要编译生成 100 万份 HTML，编一次可能需要好几天...除非，编译时不生成全量页面…… 而面向用户请求的 SSR 恰好能够提供合适的更新时机，同时作为编译的下游，SSR 有机会拦住漏网之鱼。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
即时通信 IM
对象存储
