言

目前，教学、教研各种内容线上沉淀、展示丰富多彩，但线上内容“线下化”能力不足或过分依赖人力，比如，线上练习题组卷后以PDF形式分发给学生，家长希望将考试、练习题目打印后，学生带到学校去做（高中生使用手机等电子设备的时间有限），线上各类分析报告以PDF形式分享给学生/家长等。

从业务方面看，不同业务线的多个业务场景都有输出PDF的诉求，如果各业务线自己设计、实现符合自身业务场景的具体方案，除调研、开发工作量较大之外，还会有重复调研，踩坑的情况。

从技术角度看，线上内容转PDF的内容源头来自于H5富文本内容，业界内以此为基础的PDF生成方案多种多样，也各有优劣，比如：

方案对比-表格-1

因此，我们综合了各种PDF生成方案并总结了在探索讲义生成PDF过程中的经验，抽象出了一套通用的，可复用的能力供各业务线快速利用，基本方案和优劣如下：

最终方案-表格-2

目 标

旨在提供一套以H5为载体的PDF通用生成方案，这套方案有如下特点：

1. 通用性强：能够处理各类H5页面，从分页到生成，做到一套方案，多般兼容。
2. 扩展性、配置性强：各场景可根据自己的需要自定义页眉、页脚、页码，水印，背景等配置，做到输出形式丰富多彩。
3. 方便易接入：各业务场景只需关注要展现的内容，无需关注分页，PDF生成等背后的处理 ，为需要产出PDF的业务场景提效赋能；整体来看，调研、设计、开发（+踩坑）一整套 H5 转 PDF的能力至少需要近 30人/日，我们希望这套通用能力的接入成本控制在 7人/日左右；在很多场景接入后，从实际反馈来看，平均只需要 2-3 人/日就接入了。
4. 质量高：保证输出PDF中内容的展示与H5中无异，各种复杂公式的展示也丝毫无差错。
5. 性能好：保证 1 分钟内能处理 100+ 的 20页左右的PDF生成任务
6. 稳定性高：保证有各种兜底策略妥善处理各类异常，同时能够通过限流方案应对突发流量，保证服务稳定。

这套方案可分为两个核心部分，页面展示侧 - Medusa，PDF生成侧 - Hydra

页面展示侧 - Medusa

我们页面展示侧的通用能力——Medusa，是基于Paged.js的二次封装，并以NPM包形式提供给业务方使用。Medusa可对任何HTML进行分页、并根据配置添加页眉、页脚等，最终将处理后的HTML渲染到页面中。Medusa封装并简化了对PDF格式的配置，可覆盖绝大多数业务场景，使得各业务场景将更多精力投入其自身业务逻辑的开发。

之所以选择Pagedjs为基础开发我们自己的SDK，是因为它是目前我们能找到的唯一开源的、具有HTML内容分页，样式处理的前端库，同时我们也在讲义中经过了长期的摸索与沉淀。

接下来将详细介绍Paged.js原理、Medusa支持的功能与使用方法。

一 Paged.js是如何工作的

Paged.js包含了 3 个大模块

• Chunker（负责HTML内容分页）
• Polisher （负责CSS样式处理）
• Previewer （负责预览呈现Chunker和Polisher处理后的内容）
• 
  

这里将主要介绍 Previewer 和 Chunker，因为我们的二次开发和维护不涉及到Polisher。

Previewer

Previewer 的工作非常简单，但我们会主要利用它封装我们的Medusa，初始化一个Previewer对象，Previewer初始化了Chunker和Polisher对象：

Medusa-代码-1

再调用Previewer的preview()方法，preview()方法做了两件事：

1. 通过Polisher处理样式内容
2. 通过Chunker处理需要分页的HTML内容，如果没有指定需要分页的HTML，则会处理整个Body的内容

Medusa-代码-2

当chunker.flow结束，即可在浏览器看到整个页面处理完之后的样子。

Chunker

首先，Chunker解析、预处理需要分页的HTML，为其添加一些必要的属性

Medusa-代码-3

然后创建容纳所有页(pages)的容器，并挂载到renderTo容器下(默认Body)，以备组织后续的所有页：

Medusa-代码-4

接着，chunker创建了一个page模版，以便增加页面使用：

Medusa-代码-5

其中，TEMPLATE是Pagedjs内部创建页面时所使用的基础模版。

Medusa-代码-6

接下来，chunker进入了渲染+分页过程（这个过程我们不会在二次开发中做修改，但需要了解其基本思路以便在出问题时能有解决思路），这个过程在循环一个迭代器（*layout），迭代器一直在做3件事：

1. 将内容添加到模版内容区域的容器中 -> 渲染。
2. 探测overflow，找到overflow的offset并创建BreakToken （探测overflow过程中很多处都用到了迭代器，此处为了说明思路，简化了相关代码）。

原则：

寻找overflow时会将尽可能多的内容节点插入内容区域，这里，“尽可能多”分为几种情况，比如：

• 没有剩余节点需要再添加了
• 达到了一页所能承载的最大字符数；刚开始的时候，如果没有指定每页的最大字符数，Pagedjs会给一个默认值为 1500 的每页最大字符用做判断，在之后会记录分隔好的每一页中的字符数，并取最近4页 （少于4页取全部）的平均值作为之后分页的判断条件，这里，Pagedjs相当于对每一页中能够承载的内容做了一个简单的预测，这个算法对于比较规律的内容做分页时还是比较简单高效的。
• 
  

步骤：

Pagedjs遵循了如下步骤去寻找overflow：

两个前置条件：

• 内容区域盒子边界已经确定，下面以contentArea.right 和 contentArea.bottom 分别代指其右边界和下边界。
• 处理过程中每个节点的边界可以计算（对于文字节点，Pagedjs中使用了Range对象为其创建边界），下面以 node.left、 node.right、node.top 和 node.bottom 分别代指节点的左、右、上、下边界。

i. 从需要处理的内容第一个节点开始，判断是否 node.left >= contentArea.right || node.top >= contentArea.bottom

Medusa-代码-7

ii.如果不满足，则判断 node.right <= contentArea.right && node.bottom <= contentArea.bottom

Medusa-代码-8

iii.如果不满足，那说明有子节点overflow了，则继续深入其子节点查找即可。

3.使用模版添加新的页面，并从BreakToken处继续上述动作。

二 Medusa支持的功能及使用方法

基于Paged.js，Medusa支持了如下功能，并为业务方提供了更加简洁、定制化的配置。

1. 动态页面分页能力
2. 单页模版配置 -> 生成能力
3. 前、后置静态页面生成、与分页后的动态页面拼接能力
4. 页面处理成功后，通知PDF生成服务(Hydra)执行任务

下方是调用Medusa的代码示例：

Medusa-代码-9

1.1 动态页面分页能力

Medusa核心功能，可将连续的HTML页面转化成一页页PDF样式的HTML。

1.2 单页模版配置 -> 生成能力

通过Grid布局，Paged.js将一个单页模版分为多个区域，整体分为2个大的部分：

1. base 页面基础配置：每个PDF纸型、水印，内容区域的宽高、margin与padding等等
2. surround 页面周围区域：如页眉、页脚等配置

业务方通过简单的配置，即可还原UI设计稿中的PDF样式，例子如下图：

1.2.1 base

页面基础配置是对每页的。支持纸型或页面宽高、内容区域margin、padding、背景及水印的设置。

在封装Medusa时，Medusa将读取传入的页面模版配置、静态页内容配置，并将样式上的配置解析并转化为Previewer可理解的样式内容，比如页面宽高的设置：

Medusa-代码-10

将被转化为：

Medusa-代码-11

1.2.2 surround

1. 可以看到图中的16种不同位置的surround区域。通过设置position，可将业务方自定义的元素渲染到对应的位置上。

2. 目前支持3种类型的surround item:

• text 文字
• img 图片
• pageNum (动态获取)当前页码

example:

Medusa-代码-12

1.3 前/后置静态页面

业务方可通过如下方式配置静态页面的具体内容：

Medusa-代码-13

其中，传入的React JSX Element将会被这样处理：

Medusa-代码-14

处理完成后，将HTML String拼接到页面模版中，再插入分页后内容的前后。

PDF生成侧 - Hydra：

页面展示侧为PDF生成做好了页面的准备，对于PDF生成侧，需要做的工作就更纯粹了，业务方除了请求生成PDF，定期检查PDF生成的进度，无需做任何额外工作。

1.整体流程：

PDF生成是CPU和内存密集型的，由于页面内容的不确定性，也意味着页面渲染时间与生成PDF的时间都是不确定的，因此整体PDF生成的链路被设计成是异步的，如下图：

整体流程上，业务方在请求生成PDF时，会先在后端做一条记录，后端再将任务发送给Node服务，即Hydra；

在生成PDF时， 第 1 步是做页面上的准备，一个生成任务可能有多个URL页面需要生成PDF，所以我们预先启动对应URL数量的PPTR Page，页面都启动完成后，进入下一步；

第 2 步：渲染页面，这个过程中，如果请求是包含多个URL的，这些页面会同步渲染，在所有页面渲染完成后，进入下一步。

第 2.5 步，如果是需要生成连续页码的一整个PDF，还会做额外的一个动作：页码矫正，通过页码矫正，可以将同步渲染的每个页面，按照其之前页面的页码数修正，以保证整体PDF的页码的连贯。

第 3 步，通过PPTR Page的能力将页面转换为PDF buffer，如有必要，再将生成的PDF buffer拼接到一起生成一整个PDF，或者将每个PDF buffer都生成一个PDF，压缩成zip文件。

第 4 步，文件上传OSS，最终返回OSS CDN链接。

2.请求生成PDF：

业务侧请求将对应页面生成PDF的时，只需传入如下字段：

Hydra-代码-1

3.PDF生成过程：

正如在整体流程中所述，PDF生成侧，我们借助 PPTR 的能力打开页面并生成PDF流。

在页面调用 Medusa 分页、组装能力时，所有内容分页组装完成后会向body中插入了一个额外的DOM以标识该页面处理完成：

Hydra-代码-2

这是为了 Hydra 感知页面渲染完成所做的准备，当生成服务的 PPTR 等到该DOM出现时，则表示页面成功渲染并处理完成了：

Hydra-代码-3

此后，在上面已经提到过，对于需要将多个页面生成的PDF拼接成一个PDF的情况，在生成PDF之前需要做一个重要的动作，即页码矫正，原因如下：

1. 每个页面无法感知其他页面情况的，如：第二个页面不知道第一个页面会生成多少页的PDF。
2. 它们的页码需要是连续的。

并且我们不希望页面的处理是串行的，因为串行势必导致速度较慢，生成时间长。

这个问题的解决方案如下：

1. 对于每个页面都启用一个page，并同时处理

2. 每个页面处理完成后（pdfLastDOM出现），通过Page.$eval()来统计页数并记录:

Hydra-代码-4

3. 计算出页面中分页之后每一个页面的起始页码，以及所有页面的页码总和

4. 再修改页码容器样式的 counterReset 值即可，其后续页码可自递增。

Hydra-代码-5

5. 之后，再通过 Medusa 在页面window对象中Polyfill的相关配置，比如需要生成的PDF的单页宽、高以生成PDF流。

Hydra-代码-6

6. 最后如有必要，通过pdf-lib拼接这些 pdfBuffer 即可。

Hydra-代码-7

7. PDF生成完成后，上传OSS并返回URL链接

4.性能、稳定性保证：

在整体方案落地前，我们对服务进行了多次性能测试：

以下载题目为例，在4个容器，每个容器 3C 12G 的配置下的并行处理能力如下：

对于 20 道题目，每个PDF生成任务在 15 页左右，平均 1 分钟内能完成 280 个任务的处理。

对于 40 道题目，每个PDF生成任务在 30 页左右，平均 1 分钟内能完成 105 个任务的处理。

对于 60 到题目，每个PDF生成任务在 40 页左右，平均 1 分钟内能完成 54 个任务的处理。

同时，根据 Hydra 服务的整体的处理能力，后端通过任务队列的形式帮助我们保证服务不被瞬间的突刺流量击垮。

已接入/正在接入的相关业务线及场景：

目前，公司有 5 大业务线，8 个场景已经完全接入我们的能力用于 H5 转 PDF，如下是错题本、内容资料库接入后生成的PDF样例：

错题本：

内容资料库试卷：

未来展望

目前整体的PDF生成方案已经能够满足大多数场景和内容，但依然有可改进空间。

HTML的流式布局要求我们必须手动的对内容分页，才能添加页眉，页脚等（即Mdusa做的工作），正因为如此，在处理复杂的内容时，可能会出现一些问题：比如，遇到复杂表格时，由于表格可能会有多种多样的行、列合并，同时表格单元格内的内容也可以多种多样，在分页过程中，Medusa内部的PagedJS并不能完美的处理对于长、且复杂的表格的分割，因此可能遇到分割后表格单元格缺失、错乱或宽高错误的问题，这些问题在讲义中体现较明显。

我们仍在持续关注与研究复杂DOM内容的分割问题，会尝试加以优化和改进PagedJS的能力，同时，我们也以另外一种思路设计了自己的DOM分页器方案，但经过评估，由于实现比较复杂，成本较高，暂时没有投入开发资源。

不过，我们相信，未来我们一定能以更完美的方式分割DOM以生成更高质量的PDF。

作者:高源、陈欣博

来源:微信公众号:高途技术

出处:https://mp.weixin.qq.com/s/c_N7jdNklrNFKR_Cub2Tgg

需2行代码，就能实现上图中的优化效果，让JS文件的加载耗时从1.4秒减少到0.4秒，大幅减少951ms（-67%），代码实现也非常简单方便，一起学起来吧~

资源优先级提示：预取回 Prefetch，预加载 Preload 和预连接 Preconnect

资源优先级提示是浏览器平台为控制资源加载时机而设计的一系列API，主要包括：

1. 四类资源优先级提示

1. 预取回 Prefetch

用于提示浏览器在CPU和网络带宽空闲时，预先下载指定URL的JS，图片等各类资源，存储到浏览器本地缓存中，从而减少该资源文件后续加载的耗时，优化用户体验。

具体使用方式是将link标签的rel属性设为prefetch，并将href属性设为目标资源URL，例如 <link rel="prefetch" href="https://github.com/JuniorTour/juniortour.js" />。

该标签插入DOM后，将触发一次href属性值对应URL的请求，并将响应保存到本地的prefetch cache中，同时不会解析、运行该资源。

可以预取回的资源有很多：JS、CSS、各种格式的图片、各种格式的音频、WASM文件、字体文件、甚至HTML文档本身都可实施 prefetch，预先缓存。

命中预取回缓存的请求，在开发者工具中的Network标签中的Size列，会有独特的(prefetch cache)标记：

crossorigin属性是浏览器同源策略的一部分，用于对link、script、img等元素指定是否允许以跨域资源共享模式加载目标资源。

默认情况下，JS脚本、图片等部分静态资源不受同源策略的限制，可以从任何跨域域名加载第三方JS文件、图片文件。

这样的规则有明显的安全风险，例如：

第三方JS文件可以访问第一方网站的错误上下文，从而获取内部信息。

第三方JS文件、图片文件的源服务器可以在请求过程中通过SSL握手验证、cookies等手段获取用户信息。

为了缓解这些安全风险，浏览器引入了可用于script、img和link标签的crossorigin属性，对于这些标签加载的资源：

没有crossorigin属性，就无法获取JavaScript的错误上下文。

将crossorigin设置为"anonymous"，可以访问JavaScript的错误上下文，但在请求过程中的SSL握手阶段不会携带cookies或其他用户凭据。

将crossorigin设置为"use-credentials"，既可以访问JavaScript的错误上下文，也可以在请求过程中的SSL握手阶段时携带cookies或用户凭据。

此外，Chrome浏览器的HTTP缓存以及相应的Prefetch、Preconnect资源优先级提示也会受到crossorigin属性的影响。

对于跨域资源，则其资源优先级提示也需要设置为跨域，即crossorigin="anonymous"，例如：<link rel="prefetch" href="https://github.com/JuniorTour/juniortour.js" crossorigin="anonymous" />

资源是否跨域，可以依据浏览器自动附带的Sec-Fetch-Mode请求头判断：

值为no-cors，表示当前资源加载的模式并非跨域资源共享模式。其对应的资源优先级提示不需要设置为跨域crossorigin="anonymous"。

值为cors，表示当前资源加载的模式是跨域资源共享模式。其对应的资源优先级提示需要设置为跨域crossorigin="anonymous"。

2. 预加载 Preload

与预取回不同，预加载用于提高当前页面中资源加载的优先级，确保关键资源优先加载完成。

预加载最常见的用法是用于字体文件，减少因字体加载较慢导致的文字字体闪烁变化。例如：<link rel="preload" as="font" href="/main.woff" />

应用了preload提示的资源，通常会以较高的优先级率先在网页中加载，例如下图中的nato-sans.woff2请求，Priority列的值为High，加载顺序仅次于Document本身。

as属性是必填属性，是link标签带有rel="preload"属性时，确定不同类型资源优先级的依据。

3. 预连接 Preconnect

用于提前与目标域名握手，完成DNS寻址，并建立TCP和TLS链接。

具体使用方式是将link标签的rel属性设为preconnect，并将href属性设为目标域名，例如 <link rel="preconnect" href="https://github.com" />。

优化效果是通过提前完成DNS寻址、建立TCP链接和完成TLS握手，从而减少后续访问目标域名时的连接耗时，改善用户体验。

注意！强烈建议只对重要域名进行Preconnect优化，数量不要超过 6 个。

因为Preconnect生效后，会与目标域名的保持至少10秒钟的网络连接，占用设备的网络和内存资源，甚至阻碍其他资源的加载。

4. DNS预取回 DNS-Prefetch

与上文的预取回Prefetch不同，DNS预取回用于对目标域名提前进行DNS寻址，取回并缓存域名对应的IP地址，而非像预取回Prefetch那样缓存文件资源。

具体使用方式是将link标签的rel属性设为dns-prefetch，并将href属性值设为目标域名，例如 <link rel="dns-prefetch" href="https://github.com" />。

优化效果是通过提前解析出目标域名的IP地址，从而减少后续从目标域名加载资源的耗时，加快页面加载速度，改善用户体验。

通常来说，解析DNS的耗时往往有几十甚至几百毫秒，对资源加载耗时有直接影响。

DNS预取回的能力与预连接Preconnect有所重合，以往因为dns-prefetch的浏览器兼容性略好于preconnect，往往两者一同使用。 但近年来，IE被废弃，用户大都已更新到现代浏览器，兼容性不再重要，单独使用preconnect即可替代dns-prefetch。

例如，我们的静态资源部署在域名为static.zhihu.com的CDN上，那么添加如下2行HTML代码：

<link rel="preconnect" href="static.zhihu.com" />
<link rel="dns-prefetch" href="static.zhihu.com" />

就能观察到CDN上的JS、CSS等资源加载耗时大幅减少，产生了显著的优化效果：

5. 四类资源优先级提示对比

在2022年初，Chrome 102 新增了fetch-priority属性，可用来更精细地控制资源加载的优先级，目前仍处于实验阶段，未来可能会更加完善，示例如下：

<img src="important.jpg" fetchpriority="high">
<img src="small-avatar.jpg" fetchpriority="low">

<script src="low-priority.js" fetchpriority="low"></script>

// 只对 preload link 标签生效
<link href="main.css" rel="preload" as="image" fetchpriority="high"> 

2. 示例：快速增加资源优先级提示

笔者基于多年实践，制作了一套方便实用的资源优先级提示生成工具，目前已发布为 NPM 包：resource-hint-generator，支持根据构建产物，自动生成资源优先级提示标记。

下面我们以本书配套的fe-optimization-demo项目为例，演示如何接入该库，为我们的前端项目方便快捷地增加各类资源优先级提示。

1. 安装resource-hint-generator，并添加运行命令及参数

npm install resource-hint-generator --save-dev

并新建配置文件resource-hint-generator-config.js到项目根目录：

// resource-hint-generator-config.js
module.exports = {
  resourcePath: `./dist`,
  projectRootPath: __dirname,
  resourceHintFileName: `resource-hint.js`,
  includeFileTestFunc: (fileName) => {
    return /(main.*js)|(main.*css)/g.test(fileName);
  },
  crossOriginValue: '',
  publicPath: 'https://github.com/JuniorTour',
  preconnectDomains: ['https://preconnect-example.com'],
};

主要参数说明：

• distPath：打包产物路径
• includeFileTestFunc：指定一个函数，返回布尔值表示，遍历distPath找到的的fileName，是否会被作为<link rel="prefetch">的href属性值
• publicPath：部署目标环境的CDN域名，用于和includeFileTestFunc、includeFileNames匹配到的文件名，拼接出<link rel="prefetch">标签的href属性值
• preconnectDomains：指定一个数组，数组中的每个字符串元素，都将产生2个href属性值为当前字符串的<link rel="preconnect">标签和<link rel="dns-prefetch">标签

2. 在项目打包构建完成后，运行生成工具

1. 我们的目标是在项目打包完成后，遍历产物文件，生成对应的资源优先级提示。因此我们需要在项目构建完成后，运行resource-hint-generator。

例如，我们的前端项目通过调用 npm run build 运行打包构建，那只需要在这条命令中追加运行resource-hint-generator的逻辑即可实现我们的目标。

2. 具体做法是，在package.json的scripts中添加generate-resource-hint命令，运行resource-hint-generator，并将&& npm run generate-resource-hint补充到原来的build命令中：

// package.json
"scripts": {
    "generate-resource-hint": "resource-hint-generator",
    "build": "cross-env NODE_ENV=production webpack && npm run generate-resource-hint",
}

测试运行构建后，如果在打包产物文件夹（./dist）中找到了生成的resource-hint.js文件，并且其中包含我们配置的 prefetch，preconnect目标数据，就说明配置完成了。

3. 项目上线后，加载运行生成的resource-hint.js

推荐在登录页，活动页，官网首页等前端项目外页面提前加载运行resource-hint.js ，从而在项目加载时，充分利用这些提前加载的缓存。

3. 验证，量化与评估

1. 上线前验证

优化上线前，在本地开发环境或设法直接到生产环境验证优化效果必不可少。

各类资源优先级提示是否生效，可以通过开发者工具中的网络 Network 面板判断。我们主要使用 优先级列（Priority），体积列（Size）和 加载时间序标签页（Timing）判断。

2. 建立量化监控指标

基于前文介绍的优化效果，我们可以通过对比2类监控指标在优化前后的变化来评估优化效果：

1. FCP 和 LCP

JS,CSS等各类静态资源更快的加载，更多的命中本地缓存，可以显著减少页面渲染耗时，预期也能改善我们在第一章介绍的web-vitals首次内容绘制FCP，最大内容绘制LCP2项用户体验指标。

2. 缓存命中率指标

收集优化前后生产环境中用户资源请求是否命中缓存，也可以更直接地判断优化效果。

我们可以基于Performance API的entry.duration属性来实现缓存命中率指标，示例：

<!DOCTYPE html>
<html lang="zh">
  <head>
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <title>Report CacheHit metric</title>
    <link
      rel="prefetch"
      href="https://static.zhihu.com/heifetz/6116.216a26f4.7e059bd26c25b9e701c1.css"
    />
  </head>
  <body>
    <script>
      // 上报数据到 Grafana
      function report(name, label) {
        // ...
      }

      // 检查资源加载是否命中缓存
      function checkResourceCacheHit() {
        // 获取页面加载性能信息
        const perfEntries = performance.getEntriesByType('resource');

        for (const entry of perfEntries) {
          // 判断资源的加载时间是否小于50毫秒
          // 50ms 来自于经验总结，可以根据实际情况调整
          let hitCache = entry.duration < 50;
          report('cacheHiteRate', hitCache);
        }
      }

      setTimeout(() => {
        checkResourceCacheHit();
      }, 3000);
    </script>
  </body>
</html>

将收集到的数据上报到Grafana后，加以格式化，我们就可以做出如下图的缓存命中率可视化图表：

3. 评估优化效果

首先，记录优化前状态：在优化上线前提前上线监控指标，并收集一段时间的指标数据。建议上线前持续观察7至15天，从而尽量避免来自生产环境用户的指标数据受到工作日和节假日影响所产生的异常波动。

其次，优化上线后间隔几天多次观察，并在优化上线后1至3个月后回归优化效果，确保效果稳定。

如果资源优先级提示这一优化生效，我们应该能观察到 FCP 和 LCP 有明显的改善，例如下图：

观察FCP的评分百分比可视化图，在4月30日优化上线后，评分为优的用户占比从优化前的约50%，显著提升到了90%。

再观察一段时间这一指标，如果评分优的占比都能稳定在90%，那我们就有理由判定资源优先级优化显著地提升了用户体验！

同样的，我们也可以观察缓存命中率指标来判断优化效果，例如下图：

观察上述缓存命中率可视化图，在4月30日优化上线后，缓存命中率从优化前的约40%，显著提升到了70%，同样可以佐证我们的优化产生了显著的正向收益。

原文链接：https://juejin.cn/post/7274889579076108348

reamweaver的CSS面板分类

type(类型)

background(背景)

block(区块)

box(方框) 或盒子意思

border(边框)

list(列表)

positioning(定位)

extensions(扩展)

共八个部分

1. type(类型)

type面板主要是对文字的字体，大小，颜色，效果等基本样式进行设置。

注意：属性名带*号的是指样式效果不能在编辑文档时显示，要用浏览器打开才能看到效果。

(1)font-family：设置字体系列。什么叫字体系列呢?是指对文字设定几个字体，当遇到第一个字体不能显示的文字时会自动用系列中的第二个

字体或后面的字体显示。

注意:一般英文字体我们用"Verdana, Arial, Helvetica, sans-serif"这个系列比较好看。如果不用这些字体系列，你就需要自己编辑字体系列，

也可以直接手动在下拉框里写字体名，字体之间用逗号隔开。中文网页默认字体是宋体, 一般就空着不要选取任何字体。

默认值： not specified(取决于浏览器,系统默认的字体, 如: 微软雅黑)

注意：

1.如果有汉字, 那么我们要加引号

2.如果有多个英文字母组成的单词, 我们也要加引号; "microsoft yahei" 中间用空格隔开

3.font-family:"黑体","宋体","华文隶书"; 首先找黑体, 没有黑体找宋体...

为了避免在CSS中使用 font 或 font-family 设置中文字体时乱码, 可以使用 Unicode 编码来表示字体。

/* 示例:使用Unicode字体编码设置字体为"微软雅黑" */
font-family: "\5FAE\8F6F\96C5\9ED1";

(2)font-size：定义文字的大小。你可以通过选取数字和度量单位来选择具体的字体大小，或者你也可以选择一个相对的字体大小。

最好使用pixels作为单位，这样不会在浏览器中文本变形。一般字体用比较标准的12px或14px, 默认值为16px。

注意：CSS中长度的单位分绝对长度单位和相对长度单位:

绝对长度单位有：

pt：磅(point)

mm、cn、in、pc：(毫米、厘米、英寸、活字)根据显示的实际尺寸来确定长度。

此类单位不随显示器的分辨率改变而改变。

相对长度单位有：

px：(像素)根据显示器的分辨率来确定长度。

em：当前文本的尺寸。例如：{font-size:2em}是指文字大小为原来的2倍。

比如自身font-size: 30px; 那么此时1em=30px;

ex：当前字母"x"的高度，一般为字体尺寸的一半。

%：是以当前文本的百分比定义尺寸。例如：{ font-size:300%}是指文字大小为原来的3倍。

small、large：表示比当前小一个级别或大一个级别的尺寸。

默认值：medium(标准大小)

(3)font-style：定义字体样式为normal、italic、oblique。默认设置为normal。

注意： italic 斜体 oblique 歪斜体 italic和oblique实际效果是一样的。

默认值:normal

(4)line-height：设置文本所在行的行高。默认为normal。可以是行内元素、行内块元素, 通常与height设置的高度值相同, 可以做到垂直居中的作用。

你也可以自己键入一个精确的数值并选取一个计量单位。

比较直观的写法用百分比, 例如140%是指行高等于文字大小的1.4倍。

最常用的方法: line-height:1.5em; /*行间距,相对数值,1.5倍行距,*/ 可有效的避免文字发生重叠

默认值： normal

(5)text-decoration：在文本中添加underline(下划线)、overline(上划线)、line-through(中划线)、blink(闪烁效果)。

这些效果可以同时存在，将效果前的复选框选定即可。

注意：链接的默认设置是underline，我们可以通过选none去除下划线。blink(闪烁效果)只在mozilla浏览器里可以看到, IE、opera不支持

默认值： none

(6)font-weight：给字体指定粗体字的磅值。

normal 默认值。定义标准的字符。

bold 定义粗体字符。

bolder 定义更粗的字符。

lighter 定义更细的字符。

100

200

300

400

500

600

700

800

900

inherit 规定应该从父元素继承字体的粗细。

定义由粗到细的字符。400 等同于 normal, 而 700 等同于 bold。

默认值: normal

(7)font-variant：允许你选取字体的变种, 选small-caps(小型大写字母)时, 此样式区域内所有字母大写。

normal表示正常的字体, 为默认值；

默认值: normal

(8)text-transform：将选区中每个单词的第一个字母转为大写, 或者令单词全部大写或全部小写。

参数：capitalize(单词首字母大写)、uppercase(转换成大写)、lowercase(转换成小写)、none(不转换)。

默认值：none

(9)color：定义文字颜色。包括对表单输入的文字颜色。

CSS中颜色的值有三种表示方法：

#RRGGBB格式，是由红绿蓝三种颜色的值组合，每种颜色的值为"00 – FF"的两位十六进制正整数。

例如：#FF0000表示红色，#FFFF00表示黄色。

rgb(R,G,B)格式, RGB为三色的值, 取0~255, 例如：rgb(255,0,0)表示红色, rgb(255,255,0)表示黄色。

用颜色名称。CSS可以使用已经定义好的颜色名称。例如：red表示红色, yellow表示黄色。

颜色值的缩写:

p{color:#000000} 可以缩写为：p{color:#000}

p{color:#336699} 可以缩写为：p{color:#369}

默认值： not specified

color: transparent; 透明色

rgba() 解释: rgba(红0-255, 绿0-255, 蓝0-255, 透明度0-1)

注意: 如果文字的颜色通过单独的类选择去设置没有改变颜色, 则应该通过组合选择器(.header .top .topR .blue)去设置, 改变它的优先级。

2. background(背景)

background面板主要是对元素的背景进行设置，包括背景颜色、背景图象、背景图象的控制。

一般是对body(页面)、table(表格)、div(区域)的设置。

(1)background-color：设置元素的背景色。包括对input表单输入框的背景颜色;

默认值: transparent(背景颜色为透明)

rgba() 解释: rgba(红0-255, 绿0-255, 蓝0-255, 透明度0-1) 一般用于背景色

(2)background-image：设置元素的背景图像。

默认值:none

CSS3支持多重背景图,只要加上一个url指定图片路径,并用逗号(,)将两组url分隔就可以了

background-image:url(a.jpg),url(b.jpg);

base64使用

background-image: url("data:image/png;base64,iVBORw0KGgo=...");

(3)background-repeat：确定背景图像是否以及如何重复。

repeat 默认值。背景图像将在垂直方向和水平方向重复。

repeat-x 背景图像将在水平方向重复。

repeat-y 背景图像将在垂直方向重复。

no-repeat 背景图像将仅显示一次。

inherit 规定应该从父元素继承background-repeat属性的设置。

注意：如果定义的元素的body，可以控制页面背景是否重复。

默认值: repeat

(4)background-attachment：固定背景图像或者跟随内容滚动。

参数fixed表示固定背景(不随屏幕滚动而滚动，决定背景图像是否要固定在原来的位置), scroll表示跟随内容滚动的背景。

注意：如果定义的元素的body, 可以使页面背景固定。

默认值: scroll

(5)background-position(X)：指定背景图像的水平位置。

可以指定为left(左边), center(居中)，right(右边)；

也可以指定数值，如20px是指背景距离左边20象素。

background-position(Y)：指定背景图像的垂直位置。

可以指定为top(顶部), center(居中), bottom(底部)；也可以指定数值。

background-position属性值:

left top

center top

right top

left center

center center

right center

left bottom

center bottom

right bottom

如果您仅规定了一个关键词，那么第二个值将是"center"。

注意:采用英文单词的水平位置和垂直位置的属性值可以调换

x% y% 第一个值是水平位置，第二个值是垂直位置。左上角是 0% 0%。右下角是 100% 100%。如果您仅规定了一个值，另一个值将是 50%。

xpos ypos 第一个值是水平位置，第二个值是垂直位置。左上角是 0 0。单位是像素 (0px 0px) 或任何其他的 CSS 单位。

如果您仅规定了一个值，另一个值将是50%。

您可以混合使用 % 和 position 值。

默认值：0% 0%