font-spider的webpack插件来了，且更适配于SPA项目

背景

为了丰富页面的文案效果或者为了统一不同客户端设备预置字体包不同导致的客户看到的文案效果不一样。前端开发工程师会使用自定义字体系列@font-face来解决问题。

自定义字体系列的问题

自定义字体系列到目前为止使用起来都不是尽善尽美的，我们按照时间来阐述各个阶段的问题。

第一阶段

问题：

通常一个全量字体包的体积是十份大的，以思源黑体举例，只ttf文件格式的所有权重字体(regular、bold…)加起来有 10M+，这往往超过了我们整个项目打包构建后的包体积了。如果直接使用全量字体包的话，往往会遇到FOIT和FOUT两个问题，详情请移步原文

解决方案:

既然全量的字体包体积较大，受限于下载时间过长，我们的首选解决方法就是只提取我们项目需要的字符。font-spider应运而出。这个工具的大致原理是去静态解析构建后的web包，找到自定义的字体所用的CSS选择器，下一步匹配并提取出使用这些选择器的html元素下的字符，再经由fontmin压缩出一套新的字体包替代原来的全量字体包。

第二阶段

问题：

上面方案目前适用在 解析web包时，其中已包含了全部我们预期的字符，但是对于目前占据市场一定比例的SPA项目而言，页面上大部分的文案内容都是由从服务器端接口所请求回来，进而渲染的。

解决方案:

既然静态解析的使用场景不够覆盖全面，那么我们就使用动态解析方案。动态解析web包中指定字符，进行提取压缩,font-spider-plus就此而出。它的工作原理是利用puppeteer来将本地构建后的web包放到headless模式下进行指定页面的渲染，将渲染后的完整html内容先持久化到本地，进而再使用font-spider达到适应SPA项目的目的。

第三阶段

问题：

到目前为止，我们经历了静态解析过渡到动态解析。但是思考下现在font-spider-plus方案的缺陷：

• 需要开发者自己指定SPA下所有可以被渲染出的Url对应的页面内容，但是对于一个大的SPA项目不太友好，有些较大的SPA项目中的页面会有几十个。另一个更重要的问题是，不同状态下的页面渲染出的字符显然不一定完全一致。这也是不使用全量字体包一个不可避免的缺点
• 两个工具都依然还需要对通过webpack等其他前端资源打包工具构建后的包进行命令行式地显式操作，对于当前的前端项目开发流程显然是不是非常友好的

解决方案:

既然全量字体包和解析(静态或动态)项目得到的缩量字体包都各有缺陷，我们的目标就很明确了，两者兼备。
核心思路：对于首页(或者说暴露对外的url集合)，动态解析出缩量字体包，并将字体包一起打包进构建的web包，解决了首页的FOIT和FOUT两个问题，同时在背后，去加载全量包，这样子，等到用户切换到非首页的页面，也会看到我们使用自定义字体系列中渲染出的字符。同时将这些流程开发为webpack的插件，集成到webpack的打包构建过程中，开发者无需对构建后的web包进行二次操作

因为spa-spa-font-spider-webpack-plugin开发而出，插件的使用，详情请在npm上搜索spa-font-spider-webpack-plugin 或者查看Github仓库中的readme使用手册，对于改进意见，请直接留言讨论。同时文中如果有一些内容描述不对，也烦请指出，作者看到后会第一时间进行更改