前端架构方案 第1篇
结论
本文介绍了许多因素，这些因素可能会在加载过程的不同时刻使你的页面速度减慢。使用 ，和之类的工具来确定其中哪些适用于你的应用程序。
实际上，你几乎不可能在所有方面进行优化。找出对用户有最大影响的因素，并专注于此。
我在写这篇文章时意识到的一件事是，我根深蒂固地相信，发出许多单独的请求对性能不利。过去，当每个请求都需要一个单独的连接时，Thas就是这样，而浏览器每个域只允许几个连接。但是，使用 和现代浏览器已不再是这种情况。
并且有强烈的理由支持拆分请求。它允许仅加载必要的资源，并可以更好地利用缓存的内容，因为仅需要重新加载已更改的文件。
前端架构方案 第2篇
服务端端渲染意味着在服务器上预渲染你的应用程序，并使用整页HTML响应文档请求。这意味着客户端可以看到完全呈现的页面，而不必等待加载其他代码或数据！
由于服务器只是将静态HTML发送给客户端，因此你的应用尚无法进行交互。需要加载应用程序，它需要重新运行呈现逻辑，然后将必要的事件侦听器附加到DOM。
如果看到非交互式内容很有价值，请使用服务器呈现。如果你能够将呈现的HTML缓存在服务器上并将其提供给所有用户而又不会延迟初始文档请求，那么它也将有所帮助。例如，如果你使用 来渲染博客文章，则服务器渲染非常合适。
前端架构方案 第3篇
在浏览器的初始渲染之前，用户看不到任何东西。渲染页面至少需要加载 文件，但是大多数时候需要加载其他资源，例如 和 文件。一旦这些都加载完毕，浏览器就可以开始在屏幕上渲染。
在本文中，我将使用 瀑布图。你网站的请求瀑布可能看起来像这样。
文档将加载一堆其他文件，并在这些文件加载后渲染页面。请注意， 文件是并行加载的，因此每个其他请求不会增加明显的延迟。
（备注： 启用了 ，因此资产域可以重新使用与 的现有连接！我将在下面详细讨论服务器连接。）
前端架构方案 第4篇
允许只加载当前页面所需的代码，而不是加载整个应用程序。还意味着可以缓存其中的一部分，即使其他部分已经更改，需要重新加载。
通常，代码被分成三种不同类型的文件:
可以使用 自动拆分共享代码以减少总下载量。确保启用运行时块，以使 哈希稳定，并从长期缓存中受益。
分离页面特定的代码不能自动完成，你需要识别可以单独加载的位。通常这是一个特定的路径或一组页面。使用动态导入来延迟加载代码。
会导致更多的请求被发送来加载你的应用程序。但是只要请求是并行发送的，这就不是什么大问题，特别是当你的站点开启了 服务的时候。你可以看到在这个瀑布的前三个请求:
然而，这个瀑布图还显示了两个按顺序发出的请求。这些块只在这个页面中需要，并通过 调用动态加载。
如果你知道需要这些块，你可以通过插入预加载链接标记来解决这个问题。
但是，你会看到，与总页面加载时间相比，这样做的好处可能很小。
另外，使用预加载有时会适得其反，因为加载其他更重要的文件时可能会延迟。
前端架构方案 第5篇
这是一个顺序请求链的特殊情况:你加载应用程序包，然后代码请求页面数据。
有两种方法可以避免这种情况：
将数据嵌入HTML可以确保你的应用程序不必等待数据加载。这也降低了应用程序的复杂性，因为你不必处理加载状态。
但是，如果获取数据会大大延迟你的文档响应，那将不是一个好主意，因为这会延迟你的初始渲染。
然后，如果数据准备就绪，你的应用程序可以立即开始渲染，或者等到准备就绪。
对于这两种技术，你都需要知道在应用开始呈现之前页面必须加载哪些数据。对于与用户相关的数据（用户名，通知 ...），这往往很容易，但是对于特定于页面的内容，则比较棘手。考虑确定最重要的页面并为这些页面编写自定义逻辑。
前端架构方案 第6篇
iframe 天然具备微前端的基因。我们只需将单体的前端应用，按照业务模块进行拆分，分别部署。最后通过 iframe 进行动态加载即可。
优点：
缺点：
在iframe的页面中，通过JavaScript编写代码来调用父组件的方法。可以使用或来引用父窗口对象，然后调用父窗口的方法。
例如，假设父组件中有一个名为_handleClick_的方法，可以在iframe的页面中使用以下代码来调用它：
在父窗口中，通过JavaScript获取iframe的引用，然后使用contentWindow属性访问子窗口的对象
postMessage 用于在不同的域之间发送消息。它允许你发送消息到父窗口，并接收来自父窗口的消息。
在 iframe 中：
在父窗口中：
方法一：父窗口可以使用方法向子窗口发送消息
在子窗口中，可以使用以下代码监听消息：
方法二：使用URL查询参数：如果父窗口和子窗口处于同一域下，并且没有跨域限制，父窗口可以通过修改iframe的src属性，将参数作为URL查询参数传递给子窗口。在父窗口中，可以使用以下代码将参数作为URL查询参数传递给子窗口：
在子窗口中，可以通过JavaScript获取URL查询参数：
常见的实现方式是，服务端根据路由动态渲染特定页面的模板文件。架构图如下：
优点：
缺点：
借助 single-spa，开发者可以为不同的子应用使用不同的技术栈，比如子应用 A 使用 vue 开发，子应用 B 使用 react 开发，完全没有历史债务。
single-spa 的实现原理并不难，从架构上来讲可以分为两部分：子应用和容器应用。
子应用与传统的单页应用的区别在于：
容器应用主要负责注册应用，当 url 命中子应用的路由时激活并挂载子应用，或者当子应用不处于激活状态时，将子应用从页面中移除卸载。其核心方法有两个：
容器应用代码
代码如下：
子应用代码：
优点：
缺点：
qiankun 是一个基于 single-spa 的微前端实现库，旨在帮助大家能更简单、无痛的构建一个生产可用微前端架构系统。
在主应用中注册微应用
当微应用信息注册完之后，一旦浏览器的 url 发生变化，便会自动触发 qiankun 的匹配逻辑，所有 activeRule 规则匹配上的微应用就会_入到指定的 container 中，同时依次调用微应用暴露出的生命周期钩子。
微应用需要在自己的入口 js (通常就是你配置的 webpack 的 entry js) 导出 bootstrap、mount、unmount 三个生命周期钩子，以供主应用在适当的时机调用。
优点：
缺点：