站前端的用戶體驗(yàn)，決定了用戶是否想要繼續(xù)使用網(wǎng)站以及網(wǎng)站的其他功能，網(wǎng)站的用戶體驗(yàn)佳，可留住更多的用戶。除此之外，前端優(yōu)化得好，還可以為企業(yè)節(jié)約成本。那么我們應(yīng)該如何對我們前端的頁面進(jìn)行性能優(yōu)化呢？

前端性能優(yōu)化可以分為三個方面：接口訪問優(yōu)化、靜態(tài)資源優(yōu)化和頁面渲染速度優(yōu)化。

一、接口訪問優(yōu)化

1.1、減少http請求，合理設(shè)置 HTTP緩存

http協(xié)議是無狀態(tài)的應(yīng)用層協(xié)議，每次發(fā)送http請求時，都需要建立連接、通信、斷開連接，在服務(wù)器端每個http都需要開啟獨(dú)立的線程去處理。所以盡量減少http請求，盡可能地提高訪問性能。

減少http請求的方法：

1. 合并 js、css、圖片等文件，合并成一個文件，瀏覽器就只需請求一次就可以了。圖片合并要適當(dāng)，不能想著優(yōu)化呢，盲目地都合并成一張圖片。
2. 借用瀏覽器緩存。恰當(dāng)?shù)木彺嬖O(shè)置可以大大減少http請求。不懂瀏覽器緩存的可參考《瀏覽器九大緩存方法》。
3. 接口合并。前端交互，經(jīng)常需要請求多個并行或串行接口，此時可以通過接口合并方式，提高接口訪問速度。
4. 能使用css的盡量不使用js，能使用js的盡量不用三方插件，避免三方插件大量的庫。

1.2、減少cookie傳輸

cookie 存在于 http 頭，在客戶端與服務(wù)器之間交換，盡可能地控制 cookie 的大小，cookie越小，響應(yīng)速度越快，減少 cookie 傳輸，響應(yīng)速度更快。

1.3、使用CDN提供靜態(tài)文件

使用 CDN 可以更快地在全球范圍內(nèi)獲取到你的靜態(tài)文件，加快網(wǎng)頁加載。

1.4、啟用 GZIP 壓縮

http 協(xié)議上 GZIP 編碼，是一種用來改進(jìn) web 應(yīng)用程序的。開啟 GZIP 后，服務(wù)器會把網(wǎng)頁內(nèi)容壓縮后傳輸，一般能壓縮到原大小40%，這樣網(wǎng)頁傳輸速度就更快了。GZIP 有兩大好處：一是減少存儲空間，二是通過網(wǎng)絡(luò)傳輸文件時，可以減少傳輸時間。

1.5、分域存放資源

HTTP 客戶端一般對同一個服務(wù)器的并發(fā)連接個數(shù)都是有限制的，通常最大并行連接為四了，剩下的會進(jìn)入等待隊(duì)列，等前邊的執(zhí)行完畢，等待的才會執(zhí)行。所以利用多域名主機(jī)存放資源，增加并行連接量，縮短資源加載時間。

1.6、減少頁面重定向

開啟 https 可以有效防范攻擊，保證用戶始終訪問到網(wǎng)站的加密連接，保護(hù)數(shù)據(jù)安全，同時省去 301/302 跳轉(zhuǎn)的時間，大大提升網(wǎng)站的安全系數(shù)和用戶體驗(yàn)。

如果在網(wǎng)站設(shè)置當(dāng)用戶訪問域名的時候強(qiáng)制 https 進(jìn)行 301 或者 302 跳轉(zhuǎn)，但是這個過程中，用到 HTTP 因此容易發(fā)生劫持，受到第三方的攻擊。所以盡可能使用https安全。

1.7、避免使用iframe

iframe 相當(dāng)于本頁面又嵌套了一個頁面，消耗性能，還要加載嵌套頁面的資源，所以更消耗時間。

1.8、借用瀏覽器緩存

ajax 請求到的數(shù)據(jù)，可以緩存到瀏覽器，下次使用的時候無需再次獲取，直接取緩存數(shù)據(jù)就可以。這個會根據(jù)具體的項(xiàng)目來做，比如常用的角色類型就會緩存，獲取到的普通數(shù)據(jù)為了保證實(shí)時性，不能使用緩存。

二、靜態(tài)資源優(yōu)化

2.1、壓縮 html、css、js 等文件

刪除不必要的空格、注釋和中行，減少文件大小，顯著減少用戶下載時間，加快網(wǎng)頁加載速度。可以直接使用壓縮工具，可以自動刪除所有不必要內(nèi)容。

2.2、在 js 之前引用 css

這是一個小細(xì)節(jié)，js 執(zhí)行的時候會進(jìn)入阻塞，如果放入 js 之后加載，會等待 js 執(zhí)行完成之后才能加載 css，渲染頁面，此時就會出現(xiàn)布局錯亂。所以 css 文件需要非阻塞引入，以防DOM 花費(fèi)更多時間才能渲染。

2.3、非阻塞 js

js 會阻止 html 文檔的正常解析，當(dāng)解析器到達(dá) script 標(biāo)記時，它會停止解析并執(zhí)行腳本。所以我們經(jīng)常把 script 引入的 js，放到 html 中最底下。如果需要讓腳本位于頁面頂部，建議添加非阻塞屬性。經(jīng)常使用 defer 和 async 來異步加載js文件。

<!--  使用defer  -->
<script defer src="foo.js" ></script>
<!--   使用async  -->
<script async src="foo.js"></script>

2.4、圖片壓縮

最常見的就是 css 雪碧，就是將很多很多的小圖標(biāo)放在一張圖片上，就稱為雪碧圖。雪碧圖最大優(yōu)點(diǎn)就是可以減少http請求，除此也能壓縮圖片文件大小。使用的時候，通過設(shè)置 background-position ，移動圖片的位置。除此之外，網(wǎng)站用到的大圖，也需要在保證圖片質(zhì)量前提下優(yōu)化到最小。

2.5、矢量圖替代位圖

矢量圖（SVG）往往比圖像小很多，縮放的時候不失真，這些圖像還可以通過 css 進(jìn)行動畫和修改，比位圖方便控制。可以的話，盡量用矢量圖多點(diǎn)。

2.6、js代碼相關(guān)優(yōu)化

1. 盡量減少使用閉包，因?yàn)殚]包所在的上下文不會被釋放。
2. js避免嵌套循環(huán)和死循環(huán)，一旦遇到死循環(huán)，瀏覽器會卡死。
3. 在js封裝過程中，盡量做到低耦合高內(nèi)聚。減少頁面的冗余代碼。
4. 盡量減少遞歸，避免死遞歸。
5. 盡量使用window.requestAnimationFrame替代傳統(tǒng)的定時器。

三、頁面渲染速度

3.1、懶加載

素材類的網(wǎng)站，頁面一屏展示很多圖片，而且圖片還不能失真，圖片加載太多，網(wǎng)頁加載慢得很，所以就引用懶加載，只加載可視區(qū)的圖片，避免加載可以能不需要或不必要的圖像。改善頁面的響應(yīng)時間。

3.2、避免響應(yīng)式布局

響應(yīng)式網(wǎng)站雖然能夠兼容所有終端設(shè)備，但是會出現(xiàn)隱藏部分無用內(nèi)容，浪費(fèi)帶寬，加載時間還長，頁面的渲染時間也長。想更多了解響應(yīng)式布局，請點(diǎn)擊《前端響應(yīng)式布局為什么是個坑？》。

3.3、設(shè)置大小，避免重繪

遇到 img 標(biāo)簽，會立馬發(fā)送一個 http 請求，下載圖片，頁面繼續(xù)向下渲染，等圖片加載成功了，發(fā)現(xiàn)圖片的寬高大小發(fā)生變化，影響后邊排版，所以頁面會重新再繪制一次這部分。所以盡可能設(shè)置圖片的大小。

3.4、減少DOM元素

解析 html 內(nèi)容，將標(biāo)簽轉(zhuǎn)化為DOM節(jié)點(diǎn)，之后再解析其他文件，DOM元素越少，也就是標(biāo)簽越少，文件轉(zhuǎn)化得越快，加載速度也就快了。

3.5、減少 Flash 的使用

flash 文件比較大，加載起來耗時。除此，flash 插件還需要運(yùn)行才能運(yùn)行，最主要有些瀏覽器flash插件馬上要下線了，建議盡量不用 flash。

3.6、文件順序

css文件放在最頂部，優(yōu)先渲染。js放在最底部，避免阻塞。

讓網(wǎng)頁如何加載更快，有好多的細(xì)節(jié)，還是要好好提升自己的技能~~~~~~~~~

點(diǎn)個關(guān)注！更多分享內(nèi)容。

SS in JS

CSS in JS是一種解決css問題想法的集合，而不是一個指定的庫。從CSS in JS的字面意思可以看出，它是將css樣式寫在JavaScript文件中，而不需要獨(dú)立出.css、.less之類的文件。將css放在js中使我們更方便的使用js的變量、模塊化、tree-shaking。還解決了css中的一些問題，譬如：更方便解決基于狀態(tài)的樣式，更容易追溯依賴關(guān)系，生成唯一的選擇器來鎖定作用域。盡管CSS in JS不是一個很新的技術(shù)，但國內(nèi)的普及程度并不高。由于Vue和Angular都有屬于他們自己的一套定義樣式的方案，React本身也沒有管用戶怎樣定義組件的樣式[1]，所以CSS in JS在React社區(qū)的熱度比較高。

目前為止實(shí)現(xiàn)CSS in JS的第三方庫有很多:(http://michelebertoli.github.io/css-in-js/)。像JSS[2]、styled-components[3]等。在這里我們就不展開贅述了(相關(guān)鏈接已放在下方)，這篇文章的重點(diǎn)是JS in CSS。

JS in CSS又是什么

在上面我們提到CSS in JS就是把CSS寫在JavaScript中，那么JS in CSS我們可以推斷出就是可以在CSS中使用JavaScript腳本，如下所示。可以在CSS中編寫Paint API的功能。還可以訪問：ctx，geom。甚至我們還可以編寫自己的css自定義屬性等。這些功能的實(shí)現(xiàn)都基于CSS Houdini[4]。

.el {
  --color: cyan;
  --multiplier: 0.24;
  --pad: 30;
  --slant: 20;
  --background-canvas: (ctx, geom) => {
    let multiplier = var(--multiplier);
    let c = `var(--color)`;
    let pad = var(--pad);
    let slant = var(--slant);

    ctx.moveTo(0, 0);
    ctx.lineTo(pad + (geom.width - slant - pad) * multiplier, 0);
    ctx.lineTo(pad + (geom.width - slant - pad) * multiplier + slant, geom.height);
    ctx.lineTo(0, geom.height);
    ctx.fillStyle = c;
    ctx.fill();
  };
  background: paint(background-canvas);
  transition: --multiplier .4s;
}
.el:hover {
  --multiplier: 1;
}

Houdini 解決了什么問題

CSS 與 JS的標(biāo)準(zhǔn)制定流程對比

在如今的Web開發(fā)中，JavaScript幾乎占據(jù)了項(xiàng)目代碼的大部分。我們可以在項(xiàng)目開發(fā)中使用ES 2020、ES2021、甚至提案中的新特性（如:Decorator[5]），即使瀏覽器尚未支持，也可以編寫Polyfill或使用Babel之類的工具進(jìn)行轉(zhuǎn)譯，讓我們可以將最新的特性應(yīng)用到生產(chǎn)環(huán)境中（如下圖所示）。

JavaScript標(biāo)準(zhǔn)制定流程.png

而CSS就不同了，除了制定CSS標(biāo)準(zhǔn)規(guī)范所需的時間外，各家瀏覽器的版本、實(shí)戰(zhàn)進(jìn)度差異更是曠日持久（如下圖所示），最多利用PostCSS、Sass等工具來幫我們轉(zhuǎn)譯出瀏覽器能接受的CSS。開發(fā)者們能操作的就是通過JS去控制DOM與CSSOM來影響頁面的變化，但是對于接下來的Layout、Paint與Composite就幾乎沒有控制權(quán)了。為了解決上述問題，為了讓CSS的魔力不在受到瀏覽器的限制，Houdini就此誕生。

CSS 標(biāo)準(zhǔn)制定流程.png

CSS Polyfill

我們上文中提到JavaScript中進(jìn)入提案中的特性我們可以編寫Polyfill，只需要很短的時間就可以講新特性投入到生產(chǎn)環(huán)境中。這時，腦海中閃現(xiàn)出的第一個想法就是CSS Polyfill，只要CSS的Polyfill 足夠強(qiáng)大，CSS或許也能有JavaScript一樣的發(fā)展速度，令人可悲的是編寫CSS Polyfill異常的困難，并且大多數(shù)情況下無法在不破壞性能的情況下進(jìn)行。這是因?yàn)镴avaScript是一門動態(tài)腳本語言[6]。它帶來了極強(qiáng)的擴(kuò)展性，正是因?yàn)檫@樣，我們可以很輕松使用JavaScript做出JavaScript的Polyfill。但是CSS不是動態(tài)的，在某些場景下，我們可以在編譯時將一種形式的CSS的轉(zhuǎn)換成另一種(如PostCSS[7])。如果你的Polyfill依賴于DOM結(jié)構(gòu)或者某一個元素的布局、定位等，那么我們的Polyfill就無法編譯時執(zhí)行，而需要在瀏覽器中運(yùn)行了。不幸的是，在瀏覽器中實(shí)現(xiàn)這種方案非常不容易。

頁面渲染流程.png

如上圖所示，是從瀏覽器獲取到HTML到渲染在屏幕上的全過程，我們可以看到只有帶顏色（粉色、藍(lán)色）的部分是JavaScript可以控制的環(huán)節(jié)。首先我們根本無法控制瀏覽器解析HTML與CSS并將其轉(zhuǎn)化為DOM與CSSOM的過程，以及Cascade,Layout,Paint,Composite我們也無能為力。整個過程中我們唯一完全可控制的就是DOM，另外CSSOM部分可控。

CSS Houdini草案中提到，這種程度的暴露是不確定的、兼容性不穩(wěn)定的以及缺乏對關(guān)鍵特性的支持的。比如，在瀏覽器中的 CSSOM 是不會告訴我們它是如何處理跨域的樣式表，而且對于瀏覽器無法解析的 CSS 語句它的處理方式就是不解析了，也就是說——如果我們要用 CSS polyfill讓瀏覽器去支持它尚且不支持的屬性，那就不能在 CSSOM 這個環(huán)節(jié)做，我們只能遍歷一遍DOM，找到 <style> 或 <link rel="stylesheet"> 標(biāo)簽，獲取其中的 CSS 樣式、解析、重寫，最后再加回 DOM 樹中。令人尷尬的是，這樣DOM樹全部刷新了，會導(dǎo)致頁面的重新渲染（如下如所示）。

即便如此，有的人可能會說：“除了這種方法，我們也別無選擇，更何況對網(wǎng)站的性能也不會造成很大的影響”。那么對于部分網(wǎng)站是這樣的。但如果我們的Polyfill是需要對可交互的頁面呢？例如scroll，resize，mousemove，keyup等等，這些事件隨時會被觸發(fā)，那么意味著隨時都會導(dǎo)致頁面的重新渲染，交互不會像原本那樣絲滑，甚至導(dǎo)致頁面崩潰，對用戶的體驗(yàn)也極其不好。

綜上所述，如果我們想讓瀏覽器解析它不認(rèn)識的樣式（低版本瀏覽器使用grid布局），然而渲染流程我們無法介入，我們也只能通過手動更新DOM的方式，這樣會帶來很多問題，Houdini的出現(xiàn)正是致力于解決他們。

Houdini API

Houdini是一組底層API，它公開了CSS引擎的各個部分，如下圖所示展示了每個環(huán)節(jié)對應(yīng)的新API（灰色部分各大瀏覽器還未實(shí)現(xiàn)），從而使開發(fā)人員能夠通過加入瀏覽器渲染引擎的樣式和布局過程來擴(kuò)展CSS。Houdini是一群來自Mozilla，Apple，Opera，Microsoft，HP，Intel和Google的工程師組成的工作小組設(shè)計(jì)而成的。它們使開發(fā)者可以直接訪問CSS對象模型（CSSOM），使開發(fā)人員可以編寫瀏覽器可以解析為CSS的代碼，從而創(chuàng)建新的CSS功能，而無需等待它們在瀏覽器中本地實(shí)現(xiàn)。

CSS Houdini-API

Properties & Values API

盡管當(dāng)前已經(jīng)有了CSS變量，可以讓開發(fā)者控制屬性值，但是無法約束類型或者更嚴(yán)格的定義，CSS Houdini新的API，我們可以擴(kuò)展css的變量，我們可以定義CSS變量的類型,初始值,繼承。它是css變量更強(qiáng)大靈活。

CSS變量現(xiàn)狀：

.dom {
  --my-color: green;
  --my-color: url('not-a-color'); // 它并不知道當(dāng)前的變量類型
  color: var(--my-color);
}

Houdini提供了兩種自定義屬性的注冊方式，分別是在js和css中。

CSS.registerProperty({
  name: '--my-prop', // String 自定義屬性名
  syntax: '<color>', // String 如何去解析當(dāng)前的屬性，即屬性類型，默認(rèn) *
  inherits: false, // Boolean 如果是true，子節(jié)點(diǎn)將會繼承
  initialValue: '#c0ffee', // String 屬性點(diǎn)初始值
});

我們還可以在css中注冊，也可以達(dá)到上面的效果

@property --my-prop {
  syntax: '<color>';
  inherits: false;
  initial-value: #c0ffee;
}

這個API中最令人振奮人心的功能是自定義屬性上添加動畫，像這樣：transition: --multiplier 0.4s;，這個功能我們在前面介紹什么是js in css那個demo[8]用使用過。我們還可以使用+使syntax屬性支持一個或多個類型，也可以使用|來分割。更多syntax屬性值：

屬性值描述<length>長度值<number>數(shù)字<percentage>百分比<length-percentage>長度或百分比,calc將長度和百分比組成的表達(dá)式<color>顏色<image>圖像<url>網(wǎng)址<integer>整數(shù)<angle>角度<time>時間<resolution>分辨率<transform-list>轉(zhuǎn)換函數(shù)<custom-ident>ident

Worklets

Worklets是渲染引擎的擴(kuò)展，從概念上來講它類似于Web Workers[9]，但有幾個重要的區(qū)別：

1. 設(shè)計(jì)為并行，每個Worklets必須始終有兩個或更多的實(shí)例，它們中的任何一個都可以在被調(diào)用時運(yùn)行
2. 作用域較小，限制不能訪問全局作用域的API（Worklet的函數(shù)除外）
3. 渲染引擎會在需要的時候調(diào)用他們，而不是我們手動調(diào)用

Worklet是一個JavaScript模塊，通過調(diào)用worklet的addModule方法（它是個Promise）來添加。比如registerLayout,registerPaint, registerAnimator 我們都需要放在Worklet中

//加載單個
await demoWorklet.addModule('path/to/script.js');

// 一次性加載多個worklet
Promise.all([
  demoWorklet1.addModule('script1.js'),
  demoWorklet2.addModule('script2.js'),
]).then(results => {});

registerDemoWorklet('name', class {

  // 每個Worklet可以定義要使用的不同函數(shù)
  // 他們將由渲染引擎在需要時調(diào)用
  process(arg) {
    return !arg;
  }
});

Worklets的生命周期

Worklets lifecycle

1. Worklet的生命周期從渲染引擎內(nèi)開始
2. 對于JavaScript，渲染引擎啟動JavaScript主線程
3. 然后他將啟動多個worklet進(jìn)程，并且可以運(yùn)行。這些進(jìn)程理想情況下是獨(dú)立于主線程的線程，這樣就不會阻塞主線程(但它們也不需要阻塞)
4. 然后在主線程中加載我們?yōu)g覽器的JavaScript
5. 該JavaScript調(diào)用 worklet.addModule 并異步加載一個worklet
6. 加載后，將worklet加載到兩個或多個可用的worklet流程中
7. 當(dāng)需要時，渲染引擎將通過從加載的Worklet中調(diào)用適當(dāng)?shù)奶幚砗瘮?shù)來執(zhí)行Worklet。該調(diào)用可以針對任何并行的Worklet實(shí)例。

Typed OM

Typed OM是對現(xiàn)有的CSSOM的擴(kuò)展，并實(shí)現(xiàn) Parsing API 和 Properties & Values API相關(guān)的特性。它將css值轉(zhuǎn)化為有意義類型的JavaScript的對象，而不是像現(xiàn)在的字符串。如果我們嘗試將字符串類型的值轉(zhuǎn)化為有意義的類型并返回可能會有很大的性能開銷，因此這個API可以讓我們更高效的使用CSS的值。

現(xiàn)在讀取CSS值增加了新的基類CSSStyleValue，他有許多的子類可以更加精準(zhǔn)的描述css值的類型：

子類描述CSSKeywordValueCSS關(guān)鍵字和其他標(biāo)識符（如inherit或grid）CSSPositionValue位置信息 (x,y)CSSImageValue表示圖像的值屬性的對象CSSUnitValue表示為具有單個單位的單個值（例如50px），也可以表示為沒有單位的單個值或百分比CSSMathValue比較復(fù)雜的數(shù)值，比如有calc，min和max。這包括子類 CSSMathSum, CSSMathProduct, CSSMathMin,CSSMathMax, CSSMathNegate 和 CSSMathInvertCSSTransformValue由CSS transforms組成的CSSTransformComponent列表，其中包括CSSTranslate, CSSRotate, CSSScale, CSSSkew, CSSSkewX, CSSSkewY, CSSPerspective 和 CSSMatrixComponent

使用Typed OM主要有兩種方法：

1. 通過attributeStyleMap設(shè)置和獲取有類型的行間樣式
2. 通過computedStyleMap獲取元素完整的Typed OM樣式

使用attributeStyleMap設(shè)置并獲取

myElement.attributeStyleMap.set('font-size', CSS.em(2));
myElement.attributeStyleMap.get('font-size'); // CSSUnitValue { value: 2, unit: 'em' }

myElement.attributeStyleMap.set('opacity', CSS.number(.5));
myElement.attributeStyleMap.get('opacity'); // CSSUnitValue { value: 0.5, unit: 'number' };

在線demo[10]

使用computedStyleMap

.foo {
  transform: translateX(1em) rotate(50deg) skewX(10deg);
  vertical-align: baseline;
  width: calc(100% - 3em);
}

const cs = document.querySelector('.foo').computedStyleMap();

cs.get('vertical-align');
// CSSKeywordValue {
//  value: 'baseline',
// }

cs.get('width');
// CSSMathSum {
//   operator: 'sum',
//   length: 2,
//   values: CSSNumericArray {
//     0: CSSUnitValue { value: -90, unit: 'px' },
//     1: CSSUnitValue { value: 100, unit: 'percent' },
//   },
// }

cs.get('transform');
// CSSTransformValue {
//   is2d: true,
//   length: 3,
//   0: CSSTranslate {
//     is2d: true,
//     x: CSSUnitValue { value: 20, unit: 'px' },
//     y: CSSUnitValue { value: 0, unit: 'px' },
//     z: CSSUnitValue { value: 0, unit: 'px' },
//   },
//   1: CSSRotate {...},
//   2: CSSSkewX {...},
// }

Layout API

開發(fā)者可以通過這個API實(shí)現(xiàn)自己的布局算法，我們可以像原生css一樣使用我們自定義的布局（像display:flex, display:table）。在Masonry layout library[11] 上我們可以看到開發(fā)者們是有多想實(shí)現(xiàn)各種各樣的復(fù)雜布局，其中一些布局光靠 CSS 是不行的。雖然這些布局會讓人耳目一新印象深刻，但是它們的頁面性能往往都很差，在一些低端設(shè)備上性能問題猶為明顯。

CSS Layout API 暴露了一個registerLayout方法給開發(fā)者，接收一個布局名（layout name）作為后面在 CSS中使用的屬性值，還有一個包含有這個布局邏輯的JavaScript類。

my-div {
  display: layout(my-layout);
}

// layout-worklet.js
registerLayout('my-layout', class {
  static get inputProperties() { return ['--foo']; }
  
  static get childrenInputProperties() { return ['--bar']; }
  
  async intrinsicSizes(children, edges, styleMap) {}

  async layout(children, edges, constraints, styleMap) {}
});

await CSS.layoutWorklet.addModule('layout-worklet.js');

目前瀏覽器大部分還不支持

Painting API

我們可以在CSS background-image中使用它，我們可以使用Canvas 2d上下文，根據(jù)元素的大小控制圖像，還可以使用自定義屬性。

await CSS.paintWorklet.addModule('paint-worklet.js');

registerPaint('sample-paint', class {
  static get inputProperties() { return ['--foo']; }

  static get inputArguments() { return ['<color>']; }

  static get contextOptions() { return {alpha: true}; }

  paint(ctx, size, props, args) { }
});

Animation API

這個API讓我們可以控制基于用戶輸入的關(guān)鍵幀動畫，并且以非阻塞的方式。還能更改一個 DOM 元素的屬性，不過是不會引起渲染引擎重新計(jì)算布局或者樣式的屬性，比如 transform、opacity 或者滾動條位置（scroll offset）。Animation API的使用方式與 Paint API 和Layout API略有不同我們還需要通過new一個WorkletAnimation來注冊worklet。

// animation-worklet.js
registerAnimator('sample-animator', class {
  constructor(options) {
  }
  animate(currentTime, effect) {
    effect.localTime = currentTime;
  }
});

await CSS.animationWorklet.addModule('animation-worklet.js');

// 需要添加動畫的元素
const elem = document.querySelector('#my-elem');
const scrollSource = document.scrollingElement;
const timeRange = 1000;
const scrollTimeline = new ScrollTimeline({
  scrollSource,
  timeRange,
});

const effectKeyframes = new KeyframeEffect(
  elem,
  // 動畫需要綁定的關(guān)鍵幀
  [
    {transform: 'scale(1)'},
    {transform: 'scale(.25)'},
    {transform: 'scale(1)'}
  ],
  {
    duration: timeRange,
  },
);
new WorkletAnimation(
  'sample-animator',
  effectKeyframes,
  scrollTimeline,
  {},
).play();

關(guān)于此API的更多內(nèi)容：(https://github.com/w3c/css-houdini-drafts/tree/main/css-animation-worklet-1)

Parser API

允許開發(fā)者自由擴(kuò)展 CSS 詞法分析器。

解析規(guī)則：

const background = window.cssParse.rule("background: green");
console.log(background.styleMap.get("background").value) // "green"

const styles = window.cssParse.ruleSet(".foo { background: green; margin: 5px; }");
console.log(styles.length) // 5
console.log(styles[0].styleMap.get("margin-top").value) // 5
console.log(styles[0].styleMap.get("margin-top").type) // "px"

解析CSS：

const style = fetch("style.css")
        .then(response => CSS.parseStylesheet(response.body));
style.then(console.log);

Font Metrics API

它將提供一些方法來測量在屏幕上呈現(xiàn)的文本元素的尺寸，將允許開發(fā)者控制文本元素在屏幕上呈現(xiàn)的方式。使用當(dāng)前功能很難或無法測量這些值，因此該API將使開發(fā)者可以更輕松地創(chuàng)建與文本和字體相關(guān)的CSS特性。例如：

• flex布局: align-items baseline特性。需要知道每一個flex盒子中第一個元素的基線位置。
• 首字母: 需要知道每個字母的基線高度和字母最大的高度，以及換行內(nèi)容的基線長度。
• 單個字形的前進(jìn)和后退。
• 換行: 需要訪問字體數(shù)據(jù)，文本的所有樣式輸入以及布局信息（可用的段落長度等）。
• 元素中的每一個line boxes都需要一個基線。(line boxes代表包含眾多inline boxes的這行)

Houdini 目前進(jìn)展

Is Houdini ready yet

(https://ishoudinireadyyet.com/)

Houdini 的藍(lán)圖

了解到這里，部分開發(fā)者可能會說：“我不需要這些花里胡哨的技術(shù)，并不能帶收益。我只想簡簡單單的寫幾個頁面，做做普通的Web App，并不想試圖干預(yù)瀏覽器的渲染過程從而實(shí)現(xiàn)一些實(shí)驗(yàn)性或炫酷的功能。”如果這樣想的話，我們不妨退一步再去思考。回憶下最近做過的項(xiàng)目，用于實(shí)現(xiàn)頁面效果所使用到的技術(shù)，grid布局方式在考慮兼容老版本瀏覽器時也不得不放棄。我們想控制瀏覽器渲染頁面的過程并不是僅僅為了炫技，更多的是為了幫助開發(fā)者們解決以下兩個問題：

1. 統(tǒng)一各大瀏覽器的行為
2. 像JavaScript一樣，在推出新的特性時，我們可以通過Polyfill的形式快速的投入生產(chǎn)環(huán)境中。

幾年過后再回眸，當(dāng)主流瀏覽器完全支持Houdini的時候。我們可以在瀏覽器上隨心所欲的使用任何CSS屬性，并且他們都能完美支持。像今天的grid布局在舊版本瀏覽器支持的并不友好的這類問題，那時我們只需要安裝對應(yīng)的Polyfill就能解決類似的問題。