HTML 2 PDF通用能力的設(shè)計與實(shí)現(xiàn)

言

目前，教學(xué)、教研各種內(nèi)容線上沉淀、展示豐富多彩，但線上內(nèi)容“線下化”能力不足或過分依賴人力，比如，線上練習(xí)題組卷后以PDF形式分發(fā)給學(xué)生，家長希望將考試、練習(xí)題目打印后，學(xué)生帶到學(xué)校去做（高中生使用手機(jī)等電子設(shè)備的時間有限），線上各類分析報告以PDF形式分享給學(xué)生/家長等。

從業(yè)務(wù)方面看，不同業(yè)務(wù)線的多個業(yè)務(wù)場景都有輸出PDF的訴求，如果各業(yè)務(wù)線自己設(shè)計、實(shí)現(xiàn)符合自身業(yè)務(wù)場景的具體方案，除調(diào)研、開發(fā)工作量較大之外，還會有重復(fù)調(diào)研，踩坑的情況。

從技術(shù)角度看，線上內(nèi)容轉(zhuǎn)PDF的內(nèi)容源頭來自于H5富文本內(nèi)容，業(yè)界內(nèi)以此為基礎(chǔ)的PDF生成方案多種多樣，也各有優(yōu)劣，比如：

方案對比-表格-1

因此，我們綜合了各種PDF生成方案并總結(jié)了在探索講義生成PDF過程中的經(jīng)驗，抽象出了一套通用的，可復(fù)用的能力供各業(yè)務(wù)線快速利用，基本方案和優(yōu)劣如下：

最終方案-表格-2

目標(biāo)

旨在提供一套以H5為載體的PDF通用生成方案，這套方案有如下特點(diǎn)：

通用性強(qiáng)：能夠處理各類H5頁面，從分頁到生成，做到一套方案，多般兼容。
擴(kuò)展性、配置性強(qiáng)：各場景可根據(jù)自己的需要自定義頁眉、頁腳、頁碼，水印，背景等配置，做到輸出形式豐富多彩。
方便易接入：各業(yè)務(wù)場景只需關(guān)注要展現(xiàn)的內(nèi)容，無需關(guān)注分頁，PDF生成等背后的處理，為需要產(chǎn)出PDF的業(yè)務(wù)場景提效賦能；整體來看，調(diào)研、設(shè)計、開發(fā)（+踩坑）一整套 H5 轉(zhuǎn) PDF的能力至少需要近 30人/日，我們希望這套通用能力的接入成本控制在 7人/日左右；在很多場景接入后，從實(shí)際反饋來看，平均只需要 2-3 人/日就接入了。
質(zhì)量高：保證輸出PDF中內(nèi)容的展示與H5中無異，各種復(fù)雜公式的展示也絲毫無差錯。
性能好：保證 1 分鐘內(nèi)能處理 100+ 的 20頁左右的PDF生成任務(wù)
穩(wěn)定性高：保證有各種兜底策略妥善處理各類異常，同時能夠通過限流方案應(yīng)對突發(fā)流量，保證服務(wù)穩(wěn)定。

這套方案可分為兩個核心部分，頁面展示側(cè) - Medusa，PDF生成側(cè) - Hydra

頁面展示側(cè) - Medusa

我們頁面展示側(cè)的通用能力——Medusa，是基于Paged.js的二次封裝，并以NPM包形式提供給業(yè)務(wù)方使用。Medusa可對任何HTML進(jìn)行分頁、并根據(jù)配置添加頁眉、頁腳等，最終將處理后的HTML渲染到頁面中。Medusa封裝并簡化了對PDF格式的配置，可覆蓋絕大多數(shù)業(yè)務(wù)場景，使得各業(yè)務(wù)場景將更多精力投入其自身業(yè)務(wù)邏輯的開發(fā)。

之所以選擇Pagedjs為基礎(chǔ)開發(fā)我們自己的SDK，是因為它是目前我們能找到的唯一開源的、具有HTML內(nèi)容分頁，樣式處理的前端庫，同時我們也在講義中經(jīng)過了長期的摸索與沉淀。

接下來將詳細(xì)介紹Paged.js原理、Medusa支持的功能與使用方法。

一 Paged.js是如何工作的

Paged.js包含了 3 個大模塊

Chunker（負(fù)責(zé)HTML內(nèi)容分頁）
Polisher （負(fù)責(zé)CSS樣式處理）
Previewer （負(fù)責(zé)預(yù)覽呈現(xiàn)Chunker和Polisher處理后的內(nèi)容）

這里將主要介紹 Previewer 和 Chunker，因為我們的二次開發(fā)和維護(hù)不涉及到Polisher。

Previewer

Previewer 的工作非常簡單，但我們會主要利用它封裝我們的Medusa，初始化一個Previewer對象，Previewer初始化了Chunker和Polisher對象：

Medusa-代碼-1

再調(diào)用Previewer的preview()方法，preview()方法做了兩件事：

通過Polisher處理樣式內(nèi)容
通過Chunker處理需要分頁的HTML內(nèi)容，如果沒有指定需要分頁的HTML，則會處理整個Body的內(nèi)容

Medusa-代碼-2

當(dāng)chunker.flow結(jié)束，即可在瀏覽器看到整個頁面處理完之后的樣子。

Chunker

首先，Chunker解析、預(yù)處理需要分頁的HTML，為其添加一些必要的屬性

Medusa-代碼-3

然后創(chuàng)建容納所有頁(pages)的容器，并掛載到renderTo容器下(默認(rèn)Body)，以備組織后續(xù)的所有頁：

Medusa-代碼-4

接著，chunker創(chuàng)建了一個page模版，以便增加頁面使用：

Medusa-代碼-5

其中，TEMPLATE是Pagedjs內(nèi)部創(chuàng)建頁面時所使用的基礎(chǔ)模版。

Medusa-代碼-6

接下來，chunker進(jìn)入了渲染+分頁過程（這個過程我們不會在二次開發(fā)中做修改，但需要了解其基本思路以便在出問題時能有解決思路），這個過程在循環(huán)一個迭代器（*layout），迭代器一直在做3件事：

將內(nèi)容添加到模版內(nèi)容區(qū)域的容器中 -> 渲染。
探測overflow，找到overflow的offset并創(chuàng)建BreakToken （探測overflow過程中很多處都用到了迭代器，此處為了說明思路，簡化了相關(guān)代碼）。

原則：

尋找overflow時會將盡可能多的內(nèi)容節(jié)點(diǎn)插入內(nèi)容區(qū)域，這里，“盡可能多”分為幾種情況，比如：

沒有剩余節(jié)點(diǎn)需要再添加了
達(dá)到了一頁所能承載的最大字符數(shù)；剛開始的時候，如果沒有指定每頁的最大字符數(shù)，Pagedjs會給一個默認(rèn)值為 1500 的每頁最大字符用做判斷，在之后會記錄分隔好的每一頁中的字符數(shù)，并取最近4頁（少于4頁取全部）的平均值作為之后分頁的判斷條件，這里，Pagedjs相當(dāng)于對每一頁中能夠承載的內(nèi)容做了一個簡單的預(yù)測，這個算法對于比較規(guī)律的內(nèi)容做分頁時還是比較簡單高效的。

步驟：

Pagedjs遵循了如下步驟去尋找overflow：

兩個前置條件：

內(nèi)容區(qū)域盒子邊界已經(jīng)確定，下面以contentArea.right 和 contentArea.bottom 分別代指其右邊界和下邊界。
處理過程中每個節(jié)點(diǎn)的邊界可以計算（對于文字節(jié)點(diǎn)，Pagedjs中使用了Range對象為其創(chuàng)建邊界），下面以 node.left、 node.right、node.top 和 node.bottom 分別代指節(jié)點(diǎn)的左、右、上、下邊界。

i. 從需要處理的內(nèi)容第一個節(jié)點(diǎn)開始，判斷是否 node.left >= contentArea.right || node.top >= contentArea.bottom

Medusa-代碼-7

ii.如果不滿足，則判斷 node.right <= contentArea.right && node.bottom <= contentArea.bottom

Medusa-代碼-8

iii.如果不滿足，那說明有子節(jié)點(diǎn)overflow了，則繼續(xù)深入其子節(jié)點(diǎn)查找即可。

3.使用模版添加新的頁面，并從BreakToken處繼續(xù)上述動作。

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

基于Paged.js，Medusa支持了如下功能，并為業(yè)務(wù)方提供了更加簡潔、定制化的配置。

動態(tài)頁面分頁能力
單頁模版配置 -> 生成能力
前、后置靜態(tài)頁面生成、與分頁后的動態(tài)頁面拼接能力
頁面處理成功后，通知PDF生成服務(wù)(Hydra)執(zhí)行任務(wù)

下方是調(diào)用Medusa的代碼示例：

Medusa-代碼-9

1.1 動態(tài)頁面分頁能力

Medusa核心功能，可將連續(xù)的HTML頁面轉(zhuǎn)化成一頁頁P(yáng)DF樣式的HTML。

1.2 單頁模版配置 -> 生成能力

通過Grid布局，Paged.js將一個單頁模版分為多個區(qū)域，整體分為2個大的部分：

base 頁面基礎(chǔ)配置：每個PDF紙型、水印，內(nèi)容區(qū)域的寬高、margin與padding等等
surround 頁面周圍區(qū)域：如頁眉、頁腳等配置

業(yè)務(wù)方通過簡單的配置，即可還原UI設(shè)計稿中的PDF樣式，例子如下圖：

1.2.1 base

頁面基礎(chǔ)配置是對每頁的。支持紙型或頁面寬高、內(nèi)容區(qū)域margin、padding、背景及水印的設(shè)置。

在封裝Medusa時，Medusa將讀取傳入的頁面模版配置、靜態(tài)頁內(nèi)容配置，并將樣式上的配置解析并轉(zhuǎn)化為Previewer可理解的樣式內(nèi)容，比如頁面寬高的設(shè)置：

Medusa-代碼-10

將被轉(zhuǎn)化為：

Medusa-代碼-11

1.2.2 surround

可以看到圖中的16種不同位置的surround區(qū)域。通過設(shè)置position，可將業(yè)務(wù)方自定義的元素渲染到對應(yīng)的位置上。

2. 目前支持3種類型的surround item:

text 文字
img 圖片
pageNum (動態(tài)獲取)當(dāng)前頁碼

example:

Medusa-代碼-12

1.3 前/后置靜態(tài)頁面

業(yè)務(wù)方可通過如下方式配置靜態(tài)頁面的具體內(nèi)容：

Medusa-代碼-13

其中，傳入的React JSX Element將會被這樣處理：

Medusa-代碼-14

處理完成后，將HTML String拼接到頁面模版中，再插入分頁后內(nèi)容的前后。

PDF生成側(cè) - Hydra：

頁面展示側(cè)為PDF生成做好了頁面的準(zhǔn)備，對于PDF生成側(cè)，需要做的工作就更純粹了，業(yè)務(wù)方除了請求生成PDF，定期檢查PDF生成的進(jìn)度，無需做任何額外工作。

1.整體流程：

PDF生成是CPU和內(nèi)存密集型的，由于頁面內(nèi)容的不確定性，也意味著頁面渲染時間與生成PDF的時間都是不確定的，因此整體PDF生成的鏈路被設(shè)計成是異步的，如下圖：

整體流程上，業(yè)務(wù)方在請求生成PDF時，會先在后端做一條記錄，后端再將任務(wù)發(fā)送給Node服務(wù)，即Hydra；

在生成PDF時，第 1 步是做頁面上的準(zhǔn)備，一個生成任務(wù)可能有多個URL頁面需要生成PDF，所以我們預(yù)先啟動對應(yīng)URL數(shù)量的PPTR Page，頁面都啟動完成后，進(jìn)入下一步；

第 2 步：渲染頁面，這個過程中，如果請求是包含多個URL的，這些頁面會同步渲染，在所有頁面渲染完成后，進(jìn)入下一步。

第 2.5 步，如果是需要生成連續(xù)頁碼的一整個PDF，還會做額外的一個動作：頁碼矯正，通過頁碼矯正，可以將同步渲染的每個頁面，按照其之前頁面的頁碼數(shù)修正，以保證整體PDF的頁碼的連貫。

第 3 步，通過PPTR Page的能力將頁面轉(zhuǎn)換為PDF buffer，如有必要，再將生成的PDF buffer拼接到一起生成一整個PDF，或者將每個PDF buffer都生成一個PDF，壓縮成zip文件。

第 4 步，文件上傳OSS，最終返回OSS CDN鏈接。

2.請求生成PDF：

業(yè)務(wù)側(cè)請求將對應(yīng)頁面生成PDF的時，只需傳入如下字段：

Hydra-代碼-1

3.PDF生成過程：

正如在整體流程中所述，PDF生成側(cè)，我們借助 PPTR 的能力打開頁面并生成PDF流。

在頁面調(diào)用 Medusa 分頁、組裝能力時，所有內(nèi)容分頁組裝完成后會向body中插入了一個額外的DOM以標(biāo)識該頁面處理完成：

Hydra-代碼-2

這是為了 Hydra 感知頁面渲染完成所做的準(zhǔn)備，當(dāng)生成服務(wù)的 PPTR 等到該DOM出現(xiàn)時，則表示頁面成功渲染并處理完成了：

Hydra-代碼-3

此后，在上面已經(jīng)提到過，對于需要將多個頁面生成的PDF拼接成一個PDF的情況，在生成PDF之前需要做一個重要的動作，即頁碼矯正，原因如下：

每個頁面無法感知其他頁面情況的，如：第二個頁面不知道第一個頁面會生成多少頁的PDF。
它們的頁碼需要是連續(xù)的。

并且我們不希望頁面的處理是串行的，因為串行勢必導(dǎo)致速度較慢，生成時間長。

這個問題的解決方案如下：

1. 對于每個頁面都啟用一個page，并同時處理

2. 每個頁面處理完成后（pdfLastDOM出現(xiàn)），通過Page.$eval()來統(tǒng)計頁數(shù)并記錄:

Hydra-代碼-4

3. 計算出頁面中分頁之后每一個頁面的起始頁碼，以及所有頁面的頁碼總和

4. 再修改頁碼容器樣式的 counterReset 值即可，其后續(xù)頁碼可自遞增。

Hydra-代碼-5

5. 之后，再通過 Medusa 在頁面window對象中Polyfill的相關(guān)配置，比如需要生成的PDF的單頁寬、高以生成PDF流。

Hydra-代碼-6

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

Hydra-代碼-7

7. PDF生成完成后，上傳OSS并返回URL鏈接

4.性能、穩(wěn)定性保證：

在整體方案落地前，我們對服務(wù)進(jìn)行了多次性能測試：

以下載題目為例，在4個容器，每個容器 3C 12G 的配置下的并行處理能力如下：

對于 20 道題目，每個PDF生成任務(wù)在 15 頁左右，平均 1 分鐘內(nèi)能完成 280 個任務(wù)的處理。

對于 40 道題目，每個PDF生成任務(wù)在 30 頁左右，平均 1 分鐘內(nèi)能完成 105 個任務(wù)的處理。

對于 60 到題目，每個PDF生成任務(wù)在 40 頁左右，平均 1 分鐘內(nèi)能完成 54 個任務(wù)的處理。

同時，根據(jù) Hydra 服務(wù)的整體的處理能力，后端通過任務(wù)隊列的形式幫助我們保證服務(wù)不被瞬間的突刺流量擊垮。

已接入/正在接入的相關(guān)業(yè)務(wù)線及場景：

目前，公司有 5 大業(yè)務(wù)線，8 個場景已經(jīng)完全接入我們的能力用于 H5 轉(zhuǎn) PDF，如下是錯題本、內(nèi)容資料庫接入后生成的PDF樣例：

錯題本：

內(nèi)容資料庫試卷：

未來展望

目前整體的PDF生成方案已經(jīng)能夠滿足大多數(shù)場景和內(nèi)容，但依然有可改進(jìn)空間。

HTML的流式布局要求我們必須手動的對內(nèi)容分頁，才能添加頁眉，頁腳等（即Mdusa做的工作），正因為如此，在處理復(fù)雜的內(nèi)容時，可能會出現(xiàn)一些問題：比如，遇到復(fù)雜表格時，由于表格可能會有多種多樣的行、列合并，同時表格單元格內(nèi)的內(nèi)容也可以多種多樣，在分頁過程中，Medusa內(nèi)部的PagedJS并不能完美的處理對于長、且復(fù)雜的表格的分割，因此可能遇到分割后表格單元格缺失、錯亂或?qū)捀咤e誤的問題，這些問題在講義中體現(xiàn)較明顯。

我們?nèi)栽诔掷m(xù)關(guān)注與研究復(fù)雜DOM內(nèi)容的分割問題，會嘗試加以優(yōu)化和改進(jìn)PagedJS的能力，同時，我們也以另外一種思路設(shè)計了自己的DOM分頁器方案，但經(jīng)過評估，由于實(shí)現(xiàn)比較復(fù)雜，成本較高，暫時沒有投入開發(fā)資源。

不過，我們相信，未來我們一定能以更完美的方式分割DOM以生成更高質(zhì)量的PDF。

作者:高源、陳欣博

來源:微信公眾號:高途技術(shù)

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

需2行代碼，就能實(shí)現(xiàn)上圖中的優(yōu)化效果，讓JS文件的加載耗時從1.4秒減少到0.4秒，大幅減少951ms（-67%），代碼實(shí)現(xiàn)也非常簡單方便，一起學(xué)起來吧~

資源優(yōu)先級提示：預(yù)取回 Prefetch，預(yù)加載 Preload 和預(yù)連接 Preconnect

資源優(yōu)先級提示是瀏覽器平臺為控制資源加載時機(jī)而設(shè)計的一系列API，主要包括：

1. 四類資源優(yōu)先級提示

1. 預(yù)取回 Prefetch

用于提示瀏覽器在CPU和網(wǎng)絡(luò)帶寬空閑時，預(yù)先下載指定URL的JS，圖片等各類資源，存儲到瀏覽器本地緩存中，從而減少該資源文件后續(xù)加載的耗時，優(yōu)化用戶體驗。

具體使用方式是將link標(biāo)簽的rel屬性設(shè)為prefetch，并將href屬性設(shè)為目標(biāo)資源URL，例如 <link rel="prefetch" href="https://github.com/JuniorTour/juniortour.js" />。

該標(biāo)簽插入DOM后，將觸發(fā)一次href屬性值對應(yīng)URL的請求，并將響應(yīng)保存到本地的prefetch cache中，同時不會解析、運(yùn)行該資源。

可以預(yù)取回的資源有很多：JS、CSS、各種格式的圖片、各種格式的音頻、WASM文件、字體文件、甚至HTML文檔本身都可實(shí)施 prefetch，預(yù)先緩存。

命中預(yù)取回緩存的請求，在開發(fā)者工具中的Network標(biāo)簽中的Size列，會有獨(dú)特的(prefetch cache)標(biāo)記：

crossorigin屬性是瀏覽器同源策略的一部分，用于對link、script、img等元素指定是否允許以跨域資源共享模式加載目標(biāo)資源。
默認(rèn)情況下，JS腳本、圖片等部分靜態(tài)資源不受同源策略的限制，可以從任何跨域域名加載第三方JS文件、圖片文件。
這樣的規(guī)則有明顯的安全風(fēng)險，例如：
第三方JS文件可以訪問第一方網(wǎng)站的錯誤上下文，從而獲取內(nèi)部信息。
第三方JS文件、圖片文件的源服務(wù)器可以在請求過程中通過SSL握手驗證、cookies等手段獲取用戶信息。
為了緩解這些安全風(fēng)險，瀏覽器引入了可用于script、img和link標(biāo)簽的crossorigin屬性，對于這些標(biāo)簽加載的資源：
沒有crossorigin屬性，就無法獲取JavaScript的錯誤上下文。
將crossorigin設(shè)置為"anonymous"，可以訪問JavaScript的錯誤上下文，但在請求過程中的SSL握手階段不會攜帶cookies或其他用戶憑據(jù)。
將crossorigin設(shè)置為"use-credentials"，既可以訪問JavaScript的錯誤上下文，也可以在請求過程中的SSL握手階段時攜帶cookies或用戶憑據(jù)。
此外，Chrome瀏覽器的HTTP緩存以及相應(yīng)的Prefetch、Preconnect資源優(yōu)先級提示也會受到crossorigin屬性的影響。
對于跨域資源，則其資源優(yōu)先級提示也需要設(shè)置為跨域，即crossorigin="anonymous"，例如：<link rel="prefetch" href="https://github.com/JuniorTour/juniortour.js" crossorigin="anonymous" />
資源是否跨域，可以依據(jù)瀏覽器自動附帶的Sec-Fetch-Mode請求頭判斷：
值為no-cors，表示當(dāng)前資源加載的模式并非跨域資源共享模式。其對應(yīng)的資源優(yōu)先級提示不需要設(shè)置為跨域crossorigin="anonymous"。
值為cors，表示當(dāng)前資源加載的模式是跨域資源共享模式。其對應(yīng)的資源優(yōu)先級提示需要設(shè)置為跨域crossorigin="anonymous"。

2. 預(yù)加載 Preload

與預(yù)取回不同，預(yù)加載用于提高當(dāng)前頁面中資源加載的優(yōu)先級，確保關(guān)鍵資源優(yōu)先加載完成。

預(yù)加載最常見的用法是用于字體文件，減少因字體加載較慢導(dǎo)致的文字字體閃爍變化。例如：<link rel="preload" as="font" href="/main.woff" />

應(yīng)用了preload提示的資源，通常會以較高的優(yōu)先級率先在網(wǎng)頁中加載，例如下圖中的nato-sans.woff2請求，Priority列的值為High，加載順序僅次于Document本身。

as屬性是必填屬性，是link標(biāo)簽帶有rel="preload"屬性時，確定不同類型資源優(yōu)先級的依據(jù)。

3. 預(yù)連接 Preconnect

用于提前與目標(biāo)域名握手，完成DNS尋址，并建立TCP和TLS鏈接。

具體使用方式是將link標(biāo)簽的rel屬性設(shè)為preconnect，并將href屬性設(shè)為目標(biāo)域名，例如 <link rel="preconnect" href="https://github.com" />。

優(yōu)化效果是通過提前完成DNS尋址、建立TCP鏈接和完成TLS握手，從而減少后續(xù)訪問目標(biāo)域名時的連接耗時，改善用戶體驗。

注意！強(qiáng)烈建議只對重要域名進(jìn)行Preconnect優(yōu)化，數(shù)量不要超過 6 個。
因為Preconnect生效后，會與目標(biāo)域名的保持至少10秒鐘的網(wǎng)絡(luò)連接，占用設(shè)備的網(wǎng)絡(luò)和內(nèi)存資源，甚至阻礙其他資源的加載。

4. DNS預(yù)取回 DNS-Prefetch

與上文的預(yù)取回Prefetch不同，DNS預(yù)取回用于對目標(biāo)域名提前進(jìn)行DNS尋址，取回并緩存域名對應(yīng)的IP地址，而非像預(yù)取回Prefetch那樣緩存文件資源。

具體使用方式是將link標(biāo)簽的rel屬性設(shè)為dns-prefetch，并將href屬性值設(shè)為目標(biāo)域名，例如 <link rel="dns-prefetch" href="https://github.com" />。

優(yōu)化效果是通過提前解析出目標(biāo)域名的IP地址，從而減少后續(xù)從目標(biāo)域名加載資源的耗時，加快頁面加載速度，改善用戶體驗。

通常來說，解析DNS的耗時往往有幾十甚至幾百毫秒，對資源加載耗時有直接影響。

DNS預(yù)取回的能力與預(yù)連接Preconnect有所重合，以往因為dns-prefetch的瀏覽器兼容性略好于preconnect，往往兩者一同使用。但近年來，IE被廢棄，用戶大都已更新到現(xiàn)代瀏覽器，兼容性不再重要，單獨(dú)使用preconnect即可替代dns-prefetch。

例如，我們的靜態(tài)資源部署在域名為static.zhihu.com的CDN上，那么添加如下2行HTML代碼：

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

就能觀察到CDN上的JS、CSS等資源加載耗時大幅減少，產(chǎn)生了顯著的優(yōu)化效果：

5. 四類資源優(yōu)先級提示對比

在2022年初，Chrome 102 新增了fetch-priority屬性，可用來更精細(xì)地控制資源加載的優(yōu)先級，目前仍處于實(shí)驗階段，未來可能會更加完善，示例如下：

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

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

// 只對 preload link 標(biāo)簽生效
<link href="main.css" rel="preload" as="image" fetchpriority="high">

2. 示例：快速增加資源優(yōu)先級提示

筆者基于多年實(shí)踐，制作了一套方便實(shí)用的資源優(yōu)先級提示生成工具，目前已發(fā)布為 NPM 包：resource-hint-generator，支持根據(jù)構(gòu)建產(chǎn)物，自動生成資源優(yōu)先級提示標(biāo)記。

下面我們以本書配套的fe-optimization-demo項目為例，演示如何接入該庫，為我們的前端項目方便快捷地增加各類資源優(yōu)先級提示。

1. 安裝resource-hint-generator，并添加運(yùn)行命令及參數(shù)

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'],
};

主要參數(shù)說明：

distPath：打包產(chǎn)物路徑
includeFileTestFunc：指定一個函數(shù)，返回布爾值表示，遍歷distPath找到的的fileName，是否會被作為<link rel="prefetch">的href屬性值
publicPath：部署目標(biāo)環(huán)境的CDN域名，用于和includeFileTestFunc、includeFileNames匹配到的文件名，拼接出<link rel="prefetch">標(biāo)簽的href屬性值
preconnectDomains：指定一個數(shù)組，數(shù)組中的每個字符串元素，都將產(chǎn)生2個href屬性值為當(dāng)前字符串的<link rel="preconnect">標(biāo)簽和<link rel="dns-prefetch">標(biāo)簽

2. 在項目打包構(gòu)建完成后，運(yùn)行生成工具

我們的目標(biāo)是在項目打包完成后，遍歷產(chǎn)物文件，生成對應(yīng)的資源優(yōu)先級提示。因此我們需要在項目構(gòu)建完成后，運(yùn)行resource-hint-generator。

例如，我們的前端項目通過調(diào)用 npm run build 運(yùn)行打包構(gòu)建，那只需要在這條命令中追加運(yùn)行resource-hint-generator的邏輯即可實(shí)現(xiàn)我們的目標(biāo)。

具體做法是，在package.json的scripts中添加generate-resource-hint命令，運(yùn)行resource-hint-generator，并將&& npm run generate-resource-hint補(bǔ)充到原來的build命令中：

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

測試運(yùn)行構(gòu)建后，如果在打包產(chǎn)物文件夾（./dist）中找到了生成的resource-hint.js文件，并且其中包含我們配置的 prefetch，preconnect目標(biāo)數(shù)據(jù)，就說明配置完成了。

3. 項目上線后，加載運(yùn)行生成的resource-hint.js

推薦在登錄頁，活動頁，官網(wǎng)首頁等前端項目外頁面提前加載運(yùn)行resource-hint.js ，從而在項目加載時，充分利用這些提前加載的緩存。

3. 驗證，量化與評估

1. 上線前驗證

優(yōu)化上線前，在本地開發(fā)環(huán)境或設(shè)法直接到生產(chǎn)環(huán)境驗證優(yōu)化效果必不可少。

各類資源優(yōu)先級提示是否生效，可以通過開發(fā)者工具中的網(wǎng)絡(luò) Network 面板判斷。我們主要使用優(yōu)先級列（Priority），體積列（Size）和加載時間序標(biāo)簽頁（Timing）判斷。

2. 建立量化監(jiān)控指標(biāo)

基于前文介紹的優(yōu)化效果，我們可以通過對比2類監(jiān)控指標(biāo)在優(yōu)化前后的變化來評估優(yōu)化效果：

1. FCP 和 LCP

JS,CSS等各類靜態(tài)資源更快的加載，更多的命中本地緩存，可以顯著減少頁面渲染耗時，預(yù)期也能改善我們在第一章介紹的web-vitals首次內(nèi)容繪制FCP，最大內(nèi)容繪制LCP2項用戶體驗指標(biāo)。

2. 緩存命中率指標(biāo)

收集優(yōu)化前后生產(chǎn)環(huán)境中用戶資源請求是否命中緩存，也可以更直接地判斷優(yōu)化效果。

我們可以基于Performance API的entry.duration屬性來實(shí)現(xiàn)緩存命中率指標(biāo)，示例：

<!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>
      // 上報數(shù)據(jù)到 Grafana
      function report(name, label) {
        // ...
      }

      // 檢查資源加載是否命中緩存
      function checkResourceCacheHit() {
        // 獲取頁面加載性能信息
        const perfEntries = performance.getEntriesByType('resource');

        for (const entry of perfEntries) {
          // 判斷資源的加載時間是否小于50毫秒
          // 50ms 來自于經(jīng)驗總結(jié)，可以根據(jù)實(shí)際情況調(diào)整
          let hitCache = entry.duration < 50;
          report('cacheHiteRate', hitCache);
        }
      }

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

將收集到的數(shù)據(jù)上報到Grafana后，加以格式化，我們就可以做出如下圖的緩存命中率可視化圖表：

3. 評估優(yōu)化效果

首先，記錄優(yōu)化前狀態(tài)：在優(yōu)化上線前提前上線監(jiān)控指標(biāo)，并收集一段時間的指標(biāo)數(shù)據(jù)。建議上線前持續(xù)觀察7至15天，從而盡量避免來自生產(chǎn)環(huán)境用戶的指標(biāo)數(shù)據(jù)受到工作日和節(jié)假日影響所產(chǎn)生的異常波動。

其次，優(yōu)化上線后間隔幾天多次觀察，并在優(yōu)化上線后1至3個月后回歸優(yōu)化效果，確保效果穩(wěn)定。

如果資源優(yōu)先級提示這一優(yōu)化生效，我們應(yīng)該能觀察到 FCP 和 LCP 有明顯的改善，例如下圖：

觀察FCP的評分百分比可視化圖，在4月30日優(yōu)化上線后，評分為優(yōu)的用戶占比從優(yōu)化前的約50%，顯著提升到了90%。

再觀察一段時間這一指標(biāo)，如果評分優(yōu)的占比都能穩(wěn)定在90%，那我們就有理由判定資源優(yōu)先級優(yōu)化顯著地提升了用戶體驗！

同樣的，我們也可以觀察緩存命中率指標(biāo)來判斷優(yōu)化效果，例如下圖：

觀察上述緩存命中率可視化圖，在4月30日優(yōu)化上線后，緩存命中率從優(yōu)化前的約40%，顯著提升到了70%，同樣可以佐證我們的優(yōu)化產(chǎn)生了顯著的正向收益。

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

reamweaver的CSS面板分類

type(類型)

background(背景)

block(區(qū)塊)

box(方框) 或盒子意思

border(邊框)

list(列表)

positioning(定位)

extensions(擴(kuò)展)

共八個部分

1. type(類型)

type面板主要是對文字的字體，大小，顏色，效果等基本樣式進(jìn)行設(shè)置。

注意：屬性名帶*號的是指樣式效果不能在編輯文檔時顯示，要用瀏覽器打開才能看到效果。

(1)font-family：設(shè)置字體系列。什么叫字體系列呢?是指對文字設(shè)定幾個字體，當(dāng)遇到第一個字體不能顯示的文字時會自動用系列中的第二個

字體或后面的字體顯示。

注意:一般英文字體我們用"Verdana, Arial, Helvetica, sans-serif"這個系列比較好看。如果不用這些字體系列，你就需要自己編輯字體系列，

也可以直接手動在下拉框里寫字體名，字體之間用逗號隔開。中文網(wǎng)頁默認(rèn)字體是宋體, 一般就空著不要選取任何字體。

默認(rèn)值： not specified(取決于瀏覽器,系統(tǒng)默認(rèn)的字體, 如: 微軟雅黑)

注意：

1.如果有漢字, 那么我們要加引號

2.如果有多個英文字母組成的單詞, 我們也要加引號; "microsoft yahei" 中間用空格隔開

3.font-family:"黑體","宋體","華文隸書"; 首先找黑體, 沒有黑體找宋體...

為了避免在CSS中使用 font 或 font-family 設(shè)置中文字體時亂碼, 可以使用 Unicode 編碼來表示字體。

/* 示例:使用Unicode字體編碼設(shè)置字體為"微軟雅黑" */
font-family: "\5FAE\8F6F\96C5\9ED1";

(2)font-size：定義文字的大小。你可以通過選取數(shù)字和度量單位來選擇具體的字體大小，或者你也可以選擇一個相對的字體大小。

最好使用pixels作為單位，這樣不會在瀏覽器中文本變形。一般字體用比較標(biāo)準(zhǔn)的12px或14px, 默認(rèn)值為16px。

注意：CSS中長度的單位分絕對長度單位和相對長度單位:

絕對長度單位有：

pt：磅(point)

mm、cn、in、pc：(毫米、厘米、英寸、活字)根據(jù)顯示的實(shí)際尺寸來確定長度。

此類單位不隨顯示器的分辨率改變而改變。

相對長度單位有：

px：(像素)根據(jù)顯示器的分辨率來確定長度。

em：當(dāng)前文本的尺寸。例如：{font-size:2em}是指文字大小為原來的2倍。

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

ex：當(dāng)前字母"x"的高度，一般為字體尺寸的一半。

%：是以當(dāng)前文本的百分比定義尺寸。例如：{ font-size:300%}是指文字大小為原來的3倍。

small、large：表示比當(dāng)前小一個級別或大一個級別的尺寸。

默認(rèn)值：medium(標(biāo)準(zhǔn)大小)

(3)font-style：定義字體樣式為normal、italic、oblique。默認(rèn)設(shè)置為normal。

注意： italic 斜體 oblique 歪斜體 italic和oblique實(shí)際效果是一樣的。

默認(rèn)值:normal

(4)line-height：設(shè)置文本所在行的行高。默認(rèn)為normal。可以是行內(nèi)元素、行內(nèi)塊元素, 通常與height設(shè)置的高度值相同, 可以做到垂直居中的作用。

你也可以自己鍵入一個精確的數(shù)值并選取一個計量單位。

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

最常用的方法: line-height:1.5em; /*行間距,相對數(shù)值,1.5倍行距,*/ 可有效的避免文字發(fā)生重疊

默認(rèn)值： normal

(5)text-decoration：在文本中添加underline(下劃線)、overline(上劃線)、line-through(中劃線)、blink(閃爍效果)。

這些效果可以同時存在，將效果前的復(fù)選框選定即可。

注意：鏈接的默認(rèn)設(shè)置是underline，我們可以通過選none去除下劃線。blink(閃爍效果)只在mozilla瀏覽器里可以看到, IE、opera不支持

默認(rèn)值： none

(6)font-weight：給字體指定粗體字的磅值。

normal 默認(rèn)值。定義標(biāo)準(zhǔn)的字符。

bold 定義粗體字符。

bolder 定義更粗的字符。

lighter 定義更細(xì)的字符。

100

200

300

400

500

600

700

800

900

inherit 規(guī)定應(yīng)該從父元素繼承字體的粗細(xì)。

定義由粗到細(xì)的字符。400 等同于 normal, 而 700 等同于 bold。

默認(rèn)值: normal

(7)font-variant：允許你選取字體的變種, 選small-caps(小型大寫字母)時, 此樣式區(qū)域內(nèi)所有字母大寫。

normal表示正常的字體, 為默認(rèn)值；

默認(rèn)值: normal

(8)text-transform：將選區(qū)中每個單詞的第一個字母轉(zhuǎn)為大寫, 或者令單詞全部大寫或全部小寫。

參數(shù)：capitalize(單詞首字母大寫)、uppercase(轉(zhuǎn)換成大寫)、lowercase(轉(zhuǎn)換成小寫)、none(不轉(zhuǎn)換)。

默認(rèn)值：none

(9)color：定義文字顏色。包括對表單輸入的文字顏色。

CSS中顏色的值有三種表示方法：

#RRGGBB格式，是由紅綠藍(lán)三種顏色的值組合，每種顏色的值為"00 – FF"的兩位十六進(jìn)制正整數(shù)。

例如：#FF0000表示紅色，#FFFF00表示黃色。

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

用顏色名稱。CSS可以使用已經(jīng)定義好的顏色名稱。例如：red表示紅色, yellow表示黃色。

顏色值的縮寫:

p{color:#000000} 可以縮寫為：p{color:#000}

p{color:#336699} 可以縮寫為：p{color:#369}

默認(rèn)值： not specified

color: transparent; 透明色

rgba() 解釋: rgba(紅0-255, 綠0-255, 藍(lán)0-255, 透明度0-1)

注意: 如果文字的顏色通過單獨(dú)的類選擇去設(shè)置沒有改變顏色, 則應(yīng)該通過組合選擇器(.header .top .topR .blue)去設(shè)置, 改變它的優(yōu)先級。

2. background(背景)

background面板主要是對元素的背景進(jìn)行設(shè)置，包括背景顏色、背景圖象、背景圖象的控制。

一般是對body(頁面)、table(表格)、div(區(qū)域)的設(shè)置。

(1)background-color：設(shè)置元素的背景色。包括對input表單輸入框的背景顏色;

默認(rèn)值: transparent(背景顏色為透明)

rgba() 解釋: rgba(紅0-255, 綠0-255, 藍(lán)0-255, 透明度0-1) 一般用于背景色

(2)background-image：設(shè)置元素的背景圖像。

默認(rèn)值:none

CSS3支持多重背景圖,只要加上一個url指定圖片路徑,并用逗號(,)將兩組url分隔就可以了

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

base64使用

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

(3)background-repeat：確定背景圖像是否以及如何重復(fù)。

repeat 默認(rèn)值。背景圖像將在垂直方向和水平方向重復(fù)。

repeat-x 背景圖像將在水平方向重復(fù)。

repeat-y 背景圖像將在垂直方向重復(fù)。

no-repeat 背景圖像將僅顯示一次。

inherit 規(guī)定應(yīng)該從父元素繼承background-repeat屬性的設(shè)置。

注意：如果定義的元素的body，可以控制頁面背景是否重復(fù)。

默認(rèn)值: repeat

(4)background-attachment：固定背景圖像或者跟隨內(nèi)容滾動。

參數(shù)fixed表示固定背景(不隨屏幕滾動而滾動，決定背景圖像是否要固定在原來的位置), scroll表示跟隨內(nèi)容滾動的背景。

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

默認(rèn)值: scroll

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

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

也可以指定數(shù)值，如20px是指背景距離左邊20象素。

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

可以指定為top(頂部), center(居中), bottom(底部)；也可以指定數(shù)值。

background-position屬性值:

left top

center top

right top

left center

center center

right center

left bottom

center bottom

right bottom

如果您僅規(guī)定了一個關(guān)鍵詞，那么第二個值將是"center"。

注意:采用英文單詞的水平位置和垂直位置的屬性值可以調(diào)換

x% y% 第一個值是水平位置，第二個值是垂直位置。左上角是 0% 0%。右下角是 100% 100%。如果您僅規(guī)定了一個值，另一個值將是 50%。

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

如果您僅規(guī)定了一個值，另一個值將是50%。

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

默認(rèn)值：0% 0%

在線咨詢

您的項目需求

*請認(rèn)真填寫需求信息，我們會在24小時內(nèi)與您取得聯(lián)系。

整合營銷服務(wù)商