前端優(yōu)化做到最后往往卡在一個(gè)很不起眼的小環(huán)節(jié)上那幾十個(gè)幾KB的小圖標(biāo)到底要不要合并成雪碧圖。我最早做這事是手動(dòng)在Photoshop里拼圖、量坐標(biāo)后來(lái)接觸了ponytail這個(gè)構(gòu)建插件才發(fā)現(xiàn)雪碧圖完全可以交給構(gòu)建工具自動(dòng)處理。這個(gè)插件的思路很干脆開發(fā)者繼續(xù)正常在CSS里寫background-imageponytail在構(gòu)建階段把符合條件的圖片自動(dòng)合并成一張雪碧圖順手把CSS里的背景坐標(biāo)改好整個(gè)過(guò)程不用手工維護(hù)坐標(biāo)表。這篇文章就圍繞ponytail的定位、安裝、配置、原理和避坑經(jīng)驗(yàn)展開。如果你是前端開發(fā)、構(gòu)建負(fù)責(zé)人或者正在做頁(yè)面性能優(yōu)化但被零散小圖標(biāo)折騰得頭疼這篇內(nèi)容可以直接當(dāng)作接入指南來(lái)用。1. ponytail到底是什么一場(chǎng)對(duì)傳統(tǒng)雪碧圖的自動(dòng)化改造很多剛接觸的人會(huì)問(wèn)雪碧圖不是老古董了嗎HTTP/2都普及了還有必要搞這個(gè)這個(gè)問(wèn)題很實(shí)際但先別急著下結(jié)論我們把ponytail做的事和傳統(tǒng)方案放在一起看。1.1 傳統(tǒng)雪碧圖為什么讓人又愛(ài)又恨雪碧圖的原理不復(fù)雜把多張小圖平鋪在一張大圖里通過(guò)background-position控制顯示區(qū)域減少圖片請(qǐng)求次數(shù)。好處肉眼可見(jiàn)壞處也肉眼可見(jiàn)——維護(hù)成本非常高。我最早在團(tuán)隊(duì)里做雪碧圖流程大概是這樣的設(shè)計(jì)師導(dǎo)出圖標(biāo)我用腳本把所有PNG拼到一張畫布記下每張圖左上角的坐標(biāo)再把坐標(biāo)寫進(jìn)一個(gè)_sprite.scss變量文件里。比如$icon-add-x: -20px; $icon-add-y: -40px;業(yè)務(wù)代碼引用時(shí)再拼到background-position上。這套流程聽(tīng)起來(lái)有序?qū)嶋H一改就亂。新增一個(gè)圖標(biāo)得重新拼圖、重新量坐標(biāo)、重新出圖然后全局排查哪些地方用了舊圖。最難受的是拼圖工具或手動(dòng)排版總會(huì)留下空隙雪碧圖體積在不知不覺(jué)中膨脹。傳統(tǒng)的另一個(gè)痛點(diǎn)是人和人之間的協(xié)作成本。每個(gè)前端都有自己整理雪碧圖的習(xí)慣有人按業(yè)務(wù)模塊拆有人按頁(yè)面拆有人干脆把所有圖標(biāo)全放一張圖里最后誰(shuí)都不敢動(dòng)那張大圖因?yàn)橐粍?dòng)就牽一發(fā)動(dòng)全身。這些問(wèn)題不是雪碧圖方案本身的問(wèn)題而是手工維護(hù)帶來(lái)的問(wèn)題。1.2 ponytail的核心定位與設(shè)計(jì)思路ponytail做的最重要一件事是把“人為協(xié)調(diào)的工序”變成“構(gòu)建期的純代碼操作”。它本質(zhì)上是webpack構(gòu)建鏈路上的一個(gè)插件職責(zé)范圍非常聚焦掃描CSS中的圖片引用、過(guò)濾出適合合并的小圖、自動(dòng)拼合成雪碧圖、重寫CSS坐標(biāo)。這個(gè)設(shè)計(jì)思路有一個(gè)核心關(guān)鍵詞約定優(yōu)于配置。開發(fā)者在業(yè)務(wù)CSS里怎么寫背景圖ponytail不去干涉它默認(rèn)你寫的是正?？山馕龅膗rl()。構(gòu)建時(shí)插件自己判斷哪些圖該合并、哪些圖不該合并開發(fā)者不需要在代碼里標(biāo)注這個(gè)圖標(biāo)要加入雪碧圖之類的東西。這種無(wú)侵入式設(shè)計(jì)對(duì)老項(xiàng)目尤其友好接入時(shí)不需要大規(guī)模改動(dòng)現(xiàn)有CSS。ponytail另一個(gè)值得說(shuō)的設(shè)計(jì)選擇是局部自動(dòng)化而不是全量暴力合成。它默認(rèn)只處理小于設(shè)定閾值的圖片大圖、長(zhǎng)圖、高清背景圖不會(huì)被塞進(jìn)雪碧圖里。這個(gè)取舍很關(guān)鍵因?yàn)檠┍虉D的核心收益是減少零碎小文件的請(qǐng)求數(shù)如果無(wú)腦把所有圖片都合成雪碧圖體積和尺寸會(huì)失控反而拖累加載。1.3 為什么不用base64、iconfont或HTTP/2替代有對(duì)比才更容易理解一個(gè)工具的定位。這幾個(gè)方案都解決小圖片請(qǐng)求過(guò)多的問(wèn)題但適用場(chǎng)景差異很大。方案優(yōu)點(diǎn)典型問(wèn)題適合場(chǎng)景base64內(nèi)聯(lián)零額外請(qǐng)求、接入簡(jiǎn)單CSS體積膨脹約33%無(wú)法緩存復(fù)用極少量且長(zhǎng)期不變的小圖iconfont單色圖標(biāo)表現(xiàn)好、可用CSS控制多色/復(fù)雜圖形難做、字體文件本身也要加載圖標(biāo)庫(kù)、風(fēng)格統(tǒng)一的UI圖標(biāo)HTTP/2多路復(fù)用降低連接開銷、實(shí)現(xiàn)簡(jiǎn)單零散小圖仍各有Header損耗老設(shè)備/內(nèi)網(wǎng)環(huán)境不穩(wěn)請(qǐng)求數(shù)不多、以長(zhǎng)連接為主的業(yè)務(wù)CSS Sprite請(qǐng)求數(shù)大幅下降、圖片可緩存維護(hù)成本高容易坐標(biāo)錯(cuò)亂多小圖標(biāo)、低頻變化的業(yè)務(wù)ponytail Sprite自動(dòng)合成、自動(dòng)改坐標(biāo)需要構(gòu)建環(huán)境配合有webpack構(gòu)建流程的項(xiàng)目我的觀點(diǎn)是HTTP/2并不能完全替代雪碧圖。HTTP/2雖然能多路復(fù)用但每個(gè)圖片文件依然有獨(dú)立請(qǐng)求和處理過(guò)程幾十個(gè)小圖標(biāo)就是幾十個(gè)請(qǐng)求服務(wù)端日志、緩存策略、CDN回源成本都還在。而base64和iconfont各自有硬傷一個(gè)不適合批量場(chǎng)景一個(gè)只適合單色場(chǎng)景。雪碧圖的定位依然牢固最大的歷史包袱就是維護(hù)成本ponytail恰好補(bǔ)上了自動(dòng)化這一環(huán)。2. 安裝與基礎(chǔ)接入給構(gòu)建管線加上雪碧圖能力接入ponytail的門檻很低前提是你已經(jīng)有一個(gè)webpack構(gòu)建項(xiàng)目并且CSS里通過(guò)相對(duì)路徑引用本地圖片。下面按步驟完整走一遍。2.1 環(huán)境準(zhǔn)備與安裝建議在Node.js 12以上的環(huán)境使用webpack 4或webpack 5都可以。安裝時(shí)作為開發(fā)依賴npm install --save-dev ponytail如果項(xiàng)目用的是yarnyarn add --dev ponytail裝完后可以在package.json里確認(rèn)一下版本不必追求最新版本。構(gòu)建類插件跟著大版本走比較穩(wěn)新版本發(fā)布后建議先在一個(gè)分支上試跑構(gòu)建確認(rèn)無(wú)報(bào)錯(cuò)再升級(jí)。2.2 webpack配置接入在webpack.config.js的plugins數(shù)組里添加PonytailPluginconst PonytailPlugin require(ponytail); module.exports { // ...其他配置 plugins: [ new PonytailPlugin({ limit: 10240, // 小于10KB的圖片參與合并 outputPath: assets/img/, // 雪碧圖輸出目錄 publicPath: /static/, // 雪碧圖在瀏覽器中的訪問(wèn)前綴 spriteName: sprite-[contenthash].png, include: /\.css$/, exclude: [/node_modules/, /background-pattern/] }) ] };幾個(gè)核心配置項(xiàng)的作用我實(shí)際測(cè)下來(lái)是這樣的limit單位是字節(jié)這是最重要的閥門。我一般設(shè)10240也就是10KB。超過(guò)這個(gè)大小的圖說(shuō)明本身就不是零碎小圖標(biāo)放進(jìn)雪碧圖只會(huì)讓母圖過(guò)大。outputPath雪碧圖生成到打包目錄的位置對(duì)應(yīng)webpack輸出目錄下的assets/img/。如果你希望它直接產(chǎn)出到某個(gè)靜態(tài)目錄改成相對(duì)路徑即可。publicPath瀏覽器加載時(shí)的前綴讓CSS里生成的background-image路徑能正確指向線上資源。這個(gè)值如果配錯(cuò)雪碧圖會(huì)加載不到后面排查部分會(huì)細(xì)說(shuō)。include/exclude限定插件掃描哪些CSS、忽略哪些文件。通常要排除node_modules避免把第三方庫(kù)里的圖片混進(jìn)來(lái)。background-pattern這類大尺寸背景素材一般也建議排除。需要提醒一點(diǎn)不同版本的ponytail對(duì)外暴露的配置字段名可能有細(xì)微差別。有的版本用spriteName有的版本直接用filename接入前先看一眼當(dāng)前版本的README避免照著舊文檔配置報(bào)錯(cuò)。2.3 最小化示例驗(yàn)證我建議第一次接入時(shí)不要直接上全量配置先搞一個(gè)最小case驗(yàn)證流程通不通。準(zhǔn)備一個(gè)最簡(jiǎn)單的頁(yè)面結(jié)構(gòu)project/ ├── src/ │ ├── index.js │ ├── style/ │ │ └── main.css │ └── img/ │ ├── icon-add.png │ └── icon-check.png └── webpack.config.jsmain.css內(nèi)容就一行.btn-add { background-image: url(../img/icon-add.png); } .icon-check { background-image: url(../img/icon-check.png); }執(zhí)行npm run build然后打開打包后的CSS文件你會(huì)看到原來(lái)的兩張圖片引用被替換成.btn-add { background-image: url(/static/assets/img/sprite-xxxx.png); background-position: 0 0; } .icon-check { background-image: url(/static/assets/img/sprite-xxxx.png); background-position: -20px 0; }同時(shí)dist/assets/img/下多了一張sprite-xxx.png?？吹竭@個(gè)結(jié)果就說(shuō)明管線已經(jīng)跑通接下來(lái)再擴(kuò)大到真實(shí)業(yè)務(wù)。2.4 接入時(shí)的三個(gè)前提第一CSS必須是可靜態(tài)解析的。如果項(xiàng)目里大量通過(guò)JS動(dòng)態(tài)拼background-image比如el.style.backgroundImage url( path )ponytail掃描不到這部分圖片不會(huì)進(jìn)雪碧圖。這類動(dòng)態(tài)引用需要業(yè)務(wù)上改造或者接受它們獨(dú)立加載。第二圖片路徑要能定位到真實(shí)文件。webpack配置里用了alias別名時(shí)CSS里寫url(~assets/img/xxx.png)這種寫法ponytail不一定能解析。最穩(wěn)的方式是在CSS里用相對(duì)路徑或者確保插件配置里設(shè)置了正確的上下文路徑。第三參與合并的圖片盡量保持原樣。不要在CSS里對(duì)同一張圖做旋轉(zhuǎn)、縮放再作為背景ponytail合并的是磁盤上的原始圖片CSS濾鏡效果不會(huì)反映到合并結(jié)果里。3. 核心機(jī)制拆解ponytail是怎么做到自動(dòng)化的知其然還要知其所以然這章拆一拆ponytail的內(nèi)部工作流程。理解這些機(jī)制后面排查問(wèn)題會(huì)輕松很多。3.1 圖片掃描與過(guò)濾不是所有url()都值得合并ponytail的第一步是收集圖片引用。它會(huì)在resolve階段讀取webpack處理過(guò)的CSS內(nèi)容用AST或正則的方式提取所有url()引用然后做一輪過(guò)濾過(guò)濾掉data:協(xié)議的內(nèi)聯(lián)圖片它們已經(jīng)是base64了再合并沒(méi)有意義過(guò)濾掉http://、https://開頭的遠(yuǎn)程圖片避免把遠(yuǎn)程資源誤下載到本地過(guò)濾掉超過(guò)limit閾值的圖片過(guò)濾掉exclude規(guī)則命中的路徑和重復(fù)出現(xiàn)的同一張圖。這一步的原則是保守。寧可少合并也不能把不該合的資源塞進(jìn)來(lái)。我看過(guò)有人在生產(chǎn)環(huán)境把一張200KB的橫幅圖片誤合并進(jìn)雪碧圖結(jié)果整張圖變成了寬6000多像素的巨型母圖CSS里還多出一長(zhǎng)串坐標(biāo)加載體驗(yàn)反而變差了。3.2 坐標(biāo)映射與CSS重寫原理過(guò)濾完成后插件把剩余圖片打包到同一張畫布上。算法上就是經(jīng)典的矩形裝箱問(wèn)題用盡量緊湊的方式排列圖片減少雪碧圖整體尺寸。排列時(shí)有間隙很正常間隙越小越好這也是內(nèi)存和體積的博弈。排列完成最關(guān)鍵的動(dòng)作來(lái)了重新寫CSS。我們把原始CSS里你對(duì)圖片的引用拆開看它包含兩部分信息——第一是圖片文件本身第二是它的顯示位置。而雪碧圖把所有圖片揉到一張圖后原圖的顯示位置就不能靠原文件確定了必須告訴瀏覽器從雪碧圖的哪個(gè)坐標(biāo)開始截取。所以插件會(huì)在原CSS規(guī)則旁邊新增一些樣式聲明。比如原始規(guī)則是.icon-add { width: 20px; height: 20px; background-image: url(../img/icon-add.png); background-repeat: no-repeat; }構(gòu)建后可能變成.icon-add { width: 20px; height: 20px; background-image: url(/static/assets/img/sprite-abc123.png); background-repeat: no-repeat; background-position: 0 0; background-size: 120px 80px; }這里background-position: 0 0代表這張圖位于雪碧圖的左上角另一個(gè)圖標(biāo)如果位于右側(cè)20像素處坐標(biāo)就是負(fù)數(shù)-20px 0。插件會(huì)把每張圖左上角的坐標(biāo)取負(fù)值填進(jìn)去因?yàn)檎禃?huì)讓背景圖往右下移負(fù)值才是從雪碧圖里截取對(duì)應(yīng)區(qū)域。還有一個(gè)細(xì)節(jié)容易被忽視background-size要填的是整張雪碧圖的寬高而不是單個(gè)圖標(biāo)的大小。這樣寫才能保證CSS里的背景縮放按原始比例計(jì)算。如果這里漏了Retina屏上圖片顯示會(huì)模糊。3.3 多入口、多CSS文件與分包策略現(xiàn)實(shí)項(xiàng)目不會(huì)只有一兩張CSSwebpack會(huì)有多個(gè)入口、多個(gè)樣式文件。ponytail處理多CSS時(shí)會(huì)做全局去重和收集同一張圖片在三個(gè)CSS里都被引用插件只會(huì)把它合并一次所有CSS引用的坐標(biāo)保持一致。這比手動(dòng)維護(hù)可靠得多手動(dòng)方案里同一張圖被兩個(gè)CSS引用時(shí)很容易出現(xiàn)一處改了另一處沒(méi)改的問(wèn)題。如果項(xiàng)目里既有業(yè)務(wù)圖標(biāo)又有編輯器素材、運(yùn)營(yíng)位素材混合在一張雪碧圖里雖然可用但會(huì)讓母圖體積和坐標(biāo)體系變復(fù)雜。我建議用多個(gè)規(guī)則的思路來(lái)分包在配置里針對(duì)不同目錄設(shè)置不同的include規(guī)則和spriteName讓插件分別生成獨(dú)立雪碧圖。需要注意的是這樣會(huì)犧牲一部分合并率換來(lái)的是各業(yè)務(wù)線可獨(dú)立更新、互不污染。3.4 輸出與壓縮細(xì)節(jié)合并完成后插件會(huì)輸出最終雪碧圖。輸出格式通常支持PNG部分版本可能支持WebP。用PNG時(shí)要注意小圖標(biāo)帶透明通道很常見(jiàn)PNG-8索引色就能覆蓋大部分場(chǎng)景插件一般會(huì)做調(diào)色板優(yōu)化直接在構(gòu)建產(chǎn)物里把多余顏色裁掉體積會(huì)比原始多張小圖的總和還小。如果你想進(jìn)一步壓體積可以在ponytail之后掛一個(gè)圖片壓縮插件或接入pngquant讓它們?cè)诋a(chǎn)物落盤前再處理一次。要注意壓縮與質(zhì)量之間找平衡圖標(biāo)類素材用高頻壓縮基本沒(méi)問(wèn)題但含漸變、投影的小圖壓得太狠會(huì)有色帶。輸出文件的命名建議帶上[contenthash]這個(gè)hash由內(nèi)容計(jì)算而來(lái)圖片不變文件名就不變?yōu)g覽器緩存能長(zhǎng)期生效圖片一變hash就變不會(huì)出現(xiàn)舊緩存覆蓋不了的問(wèn)題。4. 實(shí)戰(zhàn)案例一個(gè)典型業(yè)務(wù)頁(yè)面的雪碧圖接入理論講了那么多下面用一個(gè)具體場(chǎng)景完整走一遍。這個(gè)案例是我在某個(gè)后臺(tái)系統(tǒng)改造時(shí)做的結(jié)構(gòu)簡(jiǎn)化過(guò)但流程是完整的。4.1 項(xiàng)目現(xiàn)狀與優(yōu)化目標(biāo)那是一個(gè)后臺(tái)訂單列表頁(yè)不算復(fù)雜但頁(yè)面上的狀態(tài)圖標(biāo)、操作按鈕圖標(biāo)加起來(lái)有20個(gè)分布在3個(gè)CSS文件里。圖片單個(gè)體積都不大最小1.8KB最大6.4KB全是PNG小圖標(biāo)。當(dāng)時(shí)的性能報(bào)告顯示這個(gè)頁(yè)面圖片請(qǐng)求數(shù)超過(guò)30個(gè)其中絕大部分是這些小圖標(biāo)。我們希望把零碎小圖請(qǐng)求集中在1到2個(gè)雪碧圖里同時(shí)不能改動(dòng)現(xiàn)有業(yè)務(wù)邏輯和頁(yè)面結(jié)構(gòu)。很多團(tuán)隊(duì)接到這種需求第一反應(yīng)是找設(shè)計(jì)師重新切圖但設(shè)計(jì)師也很無(wú)奈圖標(biāo)本來(lái)就是按需更新的。如果用ponytail這個(gè)問(wèn)題從根上就不再是“設(shè)計(jì)協(xié)作”問(wèn)題了而是構(gòu)建產(chǎn)物問(wèn)題。4.2 改造步驟實(shí)錄第一步確認(rèn)所有CSS引用方式。我翻了一遍代碼統(tǒng)一把帶alias的圖片路徑改成相對(duì)路徑。這里有個(gè)經(jīng)驗(yàn)相對(duì)路徑雖然丑但在構(gòu)建工具面前最穩(wěn)不會(huì)出現(xiàn)解析歧義。第二步安裝依賴并配置。我用的配置如下把閾值設(shè)在8KB因?yàn)轫?yè)面里幾個(gè)超過(guò)8KB的圖其實(shí)是插畫素材不適合合并const PonytailPlugin require(ponytail); module.exports { // ... plugins: [ new PonytailPlugin({ limit: 8192, outputPath: assets/sprite/, publicPath: /assets/, spriteName: sprite-[contenthash].png, include: /[\\/]src[\\/].*\.css$/, exclude: [/node_modules/, /[\\/]assets[\\/]big/] }) ] };第三步處理CSS中的背景簡(jiǎn)寫。原始CSS里有不少寫法是background: #fff url(...) no-repeat left center。ponytail重寫坐標(biāo)時(shí)容易跟簡(jiǎn)寫里的left center沖突我在實(shí)際改造時(shí)把這些地方先拆成了完整寫法也就是background-image、background-repeat、background-position分開寫。這一步雖然不是必須的但能讓重寫結(jié)果更可預(yù)測(cè)。第四步構(gòu)建。執(zhí)行npm run build構(gòu)建日志正常通過(guò)沒(méi)有報(bào)錯(cuò)。接著打開dist目錄確認(rèn)三件事雪碧圖文件存在、CSS里的background-image都指向新生成的雪碧圖、頁(yè)面渲染正常。如果頁(yè)面出現(xiàn)圖標(biāo)錯(cuò)亂不用慌優(yōu)先排查是不是哪個(gè)背景圖被exclude規(guī)則誤傷了或者引用到了另一個(gè)CSS里同名但不同內(nèi)容的圖標(biāo)。4.3 構(gòu)建前后對(duì)比與收益改造完成后我拉了頁(yè)面數(shù)據(jù)做對(duì)比結(jié)果如下指標(biāo)優(yōu)化前優(yōu)化后圖片請(qǐng)求數(shù)211圖片總體積34.6KB18.4KB合并優(yōu)化后CSS增量0約2.3KB坐標(biāo)代碼頁(yè)面加載完成時(shí)間776ms緩存為空412ms緩存為空緩存命中場(chǎng)景21個(gè)請(qǐng)求各查一次緩存1個(gè)請(qǐng)求查一次緩存實(shí)際體感最明顯的是多圖片并行下載時(shí)的等待時(shí)間。20個(gè)小圖雖然并行但每個(gè)都有獨(dú)立請(qǐng)求頭和解析過(guò)程HTTP/2下也有開銷改成一張雪碧圖后網(wǎng)絡(luò)往返次數(shù)大幅減少弱網(wǎng)環(huán)境下提升尤其明顯。而CSS坐標(biāo)代碼增加的那2KB在Gzip后幾乎可以忽略不計(jì)。4.4 后續(xù)新增和修改圖標(biāo)的工作流接入ponytail之后日常迭代從原來(lái)的拼圖、量坐標(biāo)、改CSS、驗(yàn)頁(yè)面變成兩步把新圖標(biāo)文件放進(jìn)圖片目錄在CSS里正常引用然后重新構(gòu)建。構(gòu)建完雪碧圖自動(dòng)更新、坐標(biāo)自動(dòng)生成不需要人工介入。唯一要適應(yīng)的是新增任何小圖標(biāo)都會(huì)讓整張雪碧圖的contenthash變化導(dǎo)致所有圖標(biāo)在客戶端緩存同時(shí)失效。這在圖標(biāo)更新頻繁的業(yè)務(wù)里是個(gè)客觀代價(jià)。折中方案是按模塊拆多個(gè)雪碧圖比如icon-common、icon-order、icon-user讓小范圍改動(dòng)只影響對(duì)應(yīng)模塊的雪碧圖緩存。5. 常見(jiàn)問(wèn)題與排查技巧實(shí)錄接入過(guò)程中總有一些奇奇怪怪的問(wèn)題下面把我在私下和團(tuán)隊(duì)項(xiàng)目里碰到過(guò)的典型問(wèn)題列成速查表方便你對(duì)照排查。5.1 問(wèn)題速查表現(xiàn)象可能原因解決方向圖片沒(méi)被合并進(jìn)雪碧圖limit太小、exclude誤傷、CSS里是動(dòng)態(tài)路徑調(diào)大limit檢查include/exclude規(guī)則頁(yè)面圖標(biāo)錯(cuò)亂或花屏同一張圖被多個(gè)CSS重復(fù)引用、background-size缺失保留坐標(biāo)唯一性確認(rèn)background-size填的是整圖尺寸雪碧圖加載404publicPath配置錯(cuò)誤、CSS引用路徑與實(shí)際輸出不符核對(duì)打包產(chǎn)物路徑手動(dòng)訪問(wèn)一下圖片URLCSS樣式覆蓋雪碧圖坐標(biāo)業(yè)務(wù)里后續(xù)又寫了background簡(jiǎn)寫覆蓋了插件生成的position檢查選擇器優(yōu)先級(jí)必要時(shí)用獨(dú)立類名控制構(gòu)建報(bào)錯(cuò)找不到圖片模塊圖片路徑在webpack resolve里解析不到檢查CSS里的相對(duì)路徑或配置plugin的上下文路徑雪碧圖過(guò)大limit設(shè)太高、把大素材混進(jìn)來(lái)、排列算法利用率差調(diào)低limit正確排除大圖按模塊分包輸出JS動(dòng)態(tài)插入的背景圖沒(méi)合并插件只掃描靜態(tài)CSS對(duì)動(dòng)態(tài)樣式做改造或接受獨(dú)立加載5.2 我踩過(guò)的幾個(gè)坑說(shuō)細(xì)節(jié)第一個(gè)坑是background簡(jiǎn)寫屬性的覆蓋問(wèn)題。ponytail生成的坐標(biāo)是直接追加在規(guī)則里的但如果業(yè)務(wù)代碼在這個(gè)樣式后面又用一個(gè)簡(jiǎn)寫background: url(...) no-repeat center覆蓋坐標(biāo)會(huì)被重置。遇到這種情況我會(huì)調(diào)整一下選擇器的書寫位置或者干脆把簡(jiǎn)寫里的坐標(biāo)部分去掉讓它繼承插件生成的background-position。第二個(gè)坑是Retina屏適配。合并后我用background-size寫的是整張雪碧圖的原始尺寸但在2x屏上如果不做處理圖標(biāo)會(huì)發(fā)虛。簡(jiǎn)單方案是在媒體查詢里把background-size放大一倍或者讓設(shè)計(jì)師提供2x素材隨后在合并時(shí)統(tǒng)一處理。ponytail合并的是磁盤原圖它不會(huì)幫你自動(dòng)生成2x版本這塊還是得靠性能和資源的取舍。第三個(gè)坑是CSS壓縮插件的處理順序。項(xiàng)目中如果同時(shí)使用css-minimizer-webpack-plugin要注意執(zhí)行順序。最好是讓ponytail先基于完整的CSS生成雪碧圖和坐標(biāo)隨后再做壓縮混淆順序反了的話插件可能掃描不到任何可用的url()引用結(jié)果就是什么都沒(méi)合并。第四個(gè)坑很隱蔽圖片路徑里有重復(fù)文件名。兩個(gè)不同目錄下都有icon-add.pngponytail默認(rèn)按路徑區(qū)分圖片但如果某個(gè)步驟做了路徑歸一化兩張不同語(yǔ)義的圖可能被當(dāng)成同一張圖。排查時(shí)看到雪碧圖里缺少某個(gè)圖標(biāo)第一反應(yīng)應(yīng)該就是重復(fù)文件名問(wèn)題。5.3 與webpack5、常用loader的兼容性注意事項(xiàng)如果你用的是webpack5建議先確認(rèn)一下ponytail版本是否支持。有些老版本基于webpack4的hook編寫在webpack5里可能不生效。兼容性問(wèn)題的表現(xiàn)通常不是報(bào)錯(cuò)而是插件不執(zhí)行構(gòu)建靜默通過(guò)這對(duì)自動(dòng)化工具來(lái)說(shuō)比報(bào)錯(cuò)更危險(xiǎn)因?yàn)闆](méi)人注意到它沒(méi)干活。和less-loader、sass-loader混用時(shí)我建議讓ponytail處理的CSS是經(jīng)過(guò)預(yù)處理器編譯后的最終CSS。也就是說(shuō)如果你在SCSS里寫background-image: url(...)沒(méi)問(wèn)題less/sass會(huì)把url()原樣留在編譯結(jié)果里。但如果你在SCSS里用變量拼接路徑比如background-image: url(#{$img-path}/icon.png)編譯后變成url(/assets/img/icon.png)這時(shí)候要確認(rèn)這個(gè)絕對(duì)路徑能被ponytail有效解析。我自己的習(xí)慣是配置里關(guān)閉preserve-url一類的選項(xiàng)讓路徑保持可解析狀態(tài)。6. 什么時(shí)候不應(yīng)該用ponytail講了這么多接入和收益最后也要把邊界說(shuō)清楚。ponytail這類自動(dòng)化雪碧圖插件不是所有項(xiàng)目都適合用。如果整個(gè)項(xiàng)目的圖片請(qǐng)求總數(shù)本來(lái)就很少比如一個(gè)單頁(yè)應(yīng)用只有五六個(gè)裝飾圖那么合并的收益很有限反而引入一個(gè)構(gòu)建依賴意義不大。如果項(xiàng)目大量使用矢量圖標(biāo)庫(kù)比如直接引入iconfont或SVG庫(kù)那也沒(méi)有雪碧圖的用武之地。還有一種情況是圖片本身會(huì)動(dòng)態(tài)變化比如用戶上傳的縮略圖、活動(dòng)運(yùn)營(yíng)臨時(shí)替換的Banner這些本來(lái)就該走獨(dú)立URL不能塞進(jìn)構(gòu)建期的靜態(tài)雪碧圖。我個(gè)人的判斷標(biāo)準(zhǔn)是當(dāng)頁(yè)面里零散的小圖數(shù)量達(dá)到10個(gè)以上、且它們的變化頻率低于每周一次時(shí)ponytail的投入產(chǎn)出比最劃算。如果活動(dòng)頁(yè)面圖標(biāo)每周都在變也能用但要做好“每次構(gòu)建都更新雪碧圖緩存”的心理準(zhǔn)備。我自己接入這個(gè)插件后最明顯的感受是把一項(xiàng)需要人工細(xì)心維護(hù)的活變成了構(gòu)建管線里一個(gè)不起眼的環(huán)節(jié)。團(tuán)隊(duì)新成員不需要知道雪碧圖坐標(biāo)怎么量他們只需要正常寫CSS、正常引圖構(gòu)建完就自動(dòng)處理好了。最后再分享一個(gè)小技巧接入完成后故意在CSS里新增一個(gè)臨時(shí)圖標(biāo)然后構(gòu)建如果產(chǎn)物里多出那張小圖且CSS坐標(biāo)正確說(shuō)明整個(gè)自動(dòng)鏈路是通的這個(gè)驗(yàn)證方法比看配置、讀文檔都直觀我每次改造完都會(huì)跑一遍。