关于前端:前端是性能优化图文并茂通俗易懂

一、动态和动静导入

默认状况下，咱们动态导入的所有模块都会增加到初始捆绑包中。应用默认 ES2015 导入语法 导入的模块将动态导入。
import module from 'module'

实际上，咱们能够而把那些在须要时展现的组件，通过动静导入来实现

import("b.vue").then()  // 动静导入，在打包时会主动 chunk

如上图，在点击时 emoji 时，才去加载 emoji-picker 组件。

动静路由和动静组件会主动拆分 bundle。

二、可见性导入

除了用户交互之外，咱们通常还有在初始页面上不可见的组件。一个很好的例子是提早加载图像，这些图像在视口中不间接可见，但只有在用户向下滚动后才会加载。

三、交互时导入（懈怠式加载）

当用户与须要它的 UI 交互时，提早加载非关键资源

您的页面可能蕴含不是立刻必须的组件或资源的代码或数据。例如，用户看不到用户界面的一部分，除非他们单击或滚动页面的某些局部。例如模态框、列表的详情页、视频播放器或聊天小部件、第三方资源等等

与其立刻加载这些资源，不如在更适合的时刻加载它们，例如：

• 当用户首次单击以与该组件进行交互时
• 将组件滚动到视图中
• 或提早该组件的加载，直到浏览器闲暇（通过 requestIdleCallback API）。

加载资源的不同办法概括如下：

• 立刻加载资源（加载脚本的失常形式）
• Lazy（路由）- 当用户导航到路由或组件时加载
• Lazy（交互时）– 当用户单击 UI 时加载（例如显示聊天）
• Lazy（在视口中）- 当用户滚动到组件时加载
• Prefetch – 预拉取
• Preload – 预加载

如: 第三方 UI

如: 视频播放器嵌入

如: 认证

如：聊天小部件

如: 帮忙页

四、基于路由的拆分

依据以后路由动静加载组件

{
    path: "/home",
    component: () => import(/* webpackChunkName: "home"*/  "@/components/layout/Index.vue"),
    children: [//todo],
},

五、捆绑拆分

将代码拆分为可重用的小块

构建古代 Web 应用程序时，打包器例如，Webpack 或 rollup 获取应用程序的源代码，并将其打包到一个或多个 bundle 中，
当用户拜访网站时，bundle 申请并加载，以便将数据显示到用户的屏幕。

bundle 越大，则浏览器引擎达到进行第一次出现调用的行所需的工夫越长。在那之前，用户必须盯着空白屏幕相当长一段时间，这可能是. 十分令人丧气！

咱们心愿尽快向用户显示数据。更大的 bundle 导致加载工夫、解决工夫和执行工夫减少. 如果咱们能减小这个捆绑包的大小，以便加快速度，那就太好了。

六、断续器模式

通过预缓存、提早加载和最小化往返来优化初始负载

当咱们想要拜访一个网站时，咱们首先必须向服务器发出请求能力取得这些资源。入口点指向的文件从服务器返回，这通常是咱们应用程序的初始 HTML 文件！浏览器的 HTML 解析器在开始从服务器接管此数据后立刻开始解析此数据。如果解析器发现须要更多资源（如样式表或脚本），则会向服务器发送另一个 HTTP 申请以获取这些资源！

断续器模式侧重于四个次要的性能注意事项：

• 无效地推送要害资源，从而最大限度地缩小到服务器的往返量并缩小加载工夫。
• 尽快渲染初始路由，晋升用户体验
• 在后盾为常常拜访的路由预缓存资源，以最大限度地缩小对服务器的申请量并实现更好的脱机体验
• 懈怠地加载不常常申请的路线或资源

七、Tree Shaking

通过打消死代码来减小捆绑包大小

咱们可能会将代码增加到咱们的捆绑包中，而这些代码在应用程序中的任何中央都没有应用。这段死代码能够打消，以减小捆包的尺寸，并避免不必要地加载更多数据！打消死代码的过程在将其增加到咱们的捆绑包之前，称为 tree-shaking

八、Preload

在发现要害资源之前告诉浏览器 (指要害资源加载完后，会接着加载 preload 的资源。)

<link rel=”preload”> 形式

webpackPreload: true 形式 (Webpack 4.6.0+)

const EmojiPicker = import(/* webpackPreload: true */ "./EmojiPicker");

九、Prefetch

获取和缓存可能很快申请的资源 (指要害资源加载完后，不肯定会加载 prefetch 的资源，可能等到具体须要时才加载)

<link rel=”prefetch”> 形式

webpackPrefetch: true 形式

const EmojiPicker = import(/* webpackPrefetch: true */ "./EmojiPicker");

十、虚构列表

这是在动静列表中仅出现可见内容行而不是整个列表的想法。出现的行只是残缺列表的一小部分，当用户滚动时，可见的内容（窗口）会挪动。这能够进步渲染性能。

十一、压缩脚本

缩小通过网络传输脚本所需的工夫

• 1、Gzip 和 Brotli 是两种最罕用的被当初浏览器所反对的 压缩 js 形式 (须要和 nginx 配置应用)
• 2、Brotli 在类似的压缩级别下提供了更好的压缩比 (然而须要 https，而 gzip 在 http 下也能够)
• 3、如果你应用 webpack 来打包你得代码，你能够应用 CompressionPlugin 压缩为 gzip 或者 应用 BrotliWebpackPlugin 压缩为 brotli，如果应用 rollup，则应用 rollup-plugin-gzip 插件
• 4、Gzip 压缩切换到 Brotli 压缩，文件体积大小会升高 15%-25% 左右。
• 5、compress(a + b) <= compress(a) + compress(b) – 单个大捆绑包将比多个较小的捆绑包提供更好的压缩

HTTP 数据压缩能够以不同的形式进行分类。其中之一是有损与无损。
有损压缩意味着压缩 - 解压缩循环会导致文档略有更改，同时放弃其可用性。最终用户大多无奈察觉到这种变动。有损压缩最常见的示例是图像的 JPEG 压缩。
应用无损压缩，压缩和后续解压缩后复原的数据将与原始数据准确匹配。PNG 图像是无损压缩的一个示例。无损压缩与文本传输相干，应利用于基于文本的格局，如 HTML、CSS 和 JavaScript。

有多个工具可用于放大 HTML、CSS 和 JS 资源。Terser 是 ES6+ 中风行的 JavaScript 压缩工具，默认状况下，Webpack 蕴含一个用于此库的插件，用于创立放大的构建文件。
也能够应用 esbuild 压缩，它是一种比 terser 速度还快的压缩形式。能快 10-100 倍

动态与动静压缩

放大有助于显著减小文件大小，但压缩 JS 能够提供更显著的增益。能够通过两种形式实现服务器端压缩。
动态压缩：能够应用动态压缩来预压缩资源，并在生成过程中提前保留它们。罕用于打包时压缩。比方 webpack 或者 rollup 在打包时，就提前压缩为 gzip，而后放到 nginx 上，配置 gzip_static:on; 这样在 http 申请时，会获取 gzip 的文件，而后浏览器解压缩，显示页面。
动静压缩：通过此过程，当浏览器申请资源时，压缩会动静进行。罕用于接口中的数据压缩，在申请接口时，服务器动静压缩数据，而后返回到浏览器。

Gzip 和 Brotli 算法

Gzip 压缩格局曾经存在了近 30 年，是一种基于 Deflate 算法的无损算法。Deflate 算法自身应用 LZ77 算法和霍夫曼编码的组合。
LZ77 算法标识反复的字符串，并将它们替换为反向援用，反向援用是指向它以前呈现的地位的指针，后跟字符串的长度。随后，霍夫曼编码辨认罕用的援用，并用具备较短位序列的援用替换它们。较长的位序列用于示意不常常应用的援用。

所有支流浏览器都反对 Gzip。

Brotli
2015 年，谷歌推出了 Brotli 算法和 Brotli 压缩数据格式。与 GZip 一样，Brotli 也是一种基于 LZ77 算法和霍夫曼编码的无损算法。此外，它还应用二阶上下文建模以相似的速度产生更密集的压缩。上下文建模是一项性能，它容许在同一块中对同一字母表应用多个霍夫曼树。Brotli 还反对更大的窗口大小用于反向援用，并具备动态字典。这些性能有助于进步其作为压缩算法的效率。
Brotli 目前受到所有次要服务器和浏览器的反对，并且越来越受欢迎。

比拟 gzip 和 brotli

下表显示了不同压缩级别的 Brotli 和 Gzip 压缩率和速度的基准比拟。

启用压缩

webpack 配置

module.exports = {
 //...
 plugins: [
   //...
   new CompressionPlugin()]
}

Nginx 这样的 HTTP 代理上启用它

server {
        listen 8080;
        server_name localhost;

        # 须要 http_gzip_static_module 模块
        gzip_static on;  
        
        location / {
            alias html
            index index.html index.htm;
            try_files $uri $uri/ /html/index.html;
        }
}

浏览器通过申请中的 Accept-Encoding HTTP 标头传播它反对的压缩算法, 这表明浏览器反对 Gzip 和 brotli
Accept-Encoding: gzip, br

服务器将返回 Content-Encoding HTTP 响应标头，以批示响应中应用的压缩算法。例如，
Content-Encoding: br