前端需要加载一个大体积的文件时

前言

我们平时开发的过程中，常常会遇到性能优化的要求。而对于前端的性能优化，我理解为有两大类，一类是网络层面的优化，即加速你的资源加载；另一类也是代码层面上的优化，即根据不同的业务场景写出更高性能的代码。

网络层面上的优化常常令人体验最深，想象一下你把站点的包从 10M 压缩到了 1M ，那么用户打开页面的时间也会大大缩短，相比这样用户的体验也会更好。

初探

开始之前，先来介绍一下 FFmpeg.wasm 是什么。 FFmpeg.wasm 使用 WebAssembly 技术将 FFmpeg 的功能集成到 Web 应用程序中，使开发者能够在浏览器环境中处理音频和视频。

它的一些关键特点和用途如下：

• 多媒体处理：  FFmpeg.wasm 允许在浏览器中进行媒体处理，如音频和视频的解码、编码、剪辑、合成、添加字幕等操作。
• 转码： 可以在 Web 应用程序中实现实时的音视频转码
• 独立性：  FFmpeg.wasm 可以独立运行，不需要服务器端的支持，因此可以直接在客户端进行媒体处理，降低服务器负担。

简要来说 FFmpeg 是一个处理音视频的库，常规的音视频处理任务常常放在服务端执行，这些任务十分耗费服务端的 CPU 、内存资源。得益于 WebAssembly ， FFmpeg 可以移植到浏览器端使用——即 FFmpeg.wasm ，也就是说这些耗费资源的任务可以放在客户端去执行，也无疑是帮我们省掉了很多服务端资源。

在它的使用文档中，我们发现了这么一句话。

也就是说加载这个库时我们需要加载将近 30M 的资源，假设我们的服务器下行带宽是 4M ，在用户能跑满这个带宽的情况下，那么加载这个库大概需要 60秒 左右。如果每一次进来都要等待加载 60秒 的话，那用户估计早就受不了。

如果你的团队里有 FFmpeg 的大佬，那么可以根据你们业务的要求去裁剪一个 FFmpeg ，这样的包体积应该会减少不少。本文还是会采用一些常规的思路去做优化，即压缩与缓存。

PS:如果你是 vite 用户，在跑上面的官方 demo 时遇到了这个报错的话，请把这段配置加到你的 vite 配置文件中。

压缩

在现代化构建工具中，我们会发现打包出来的产物中往往存在 .gz 后缀名的这种类型的产物。它就是今天我们需要介绍的主角—— gzip 压缩。

gzip 使用 DEFLATE 算法进行数据压缩。 DEFLATE 算法是一种无损数据压缩算法，它基于 霍夫曼编码 和 LZ77 算法的组合。压缩后的文件通常以 .gz 作为扩展名。 gzip 可以压缩单个文件或多个文件，并将它们打包成一个压缩文件。

压缩文件可以使用gzip filename命令，默认情况下， gzip 在压缩文件时会不保留原始文件，可以加上 -k 选项可以防止删除原始文件， gzip 支持不同的压缩级别，通过指定 -1 到 -9 之间的数字来调整。级别越高，压缩比越高，但耗费的时间也越多。解压文件则可以使用：gunzip filename.gz 或 gzip -d filename.gz 命令。

接下来就可以使用 gzip 压缩去压缩我们的 wasm 文件，即 gzip -9 ffmpeg-core.wasm ，压缩后的文件体积降到了原文件体积的 1/3 左右。