从安装到跑通：Critters基础配置全流程
其实Critters的核心逻辑特简单：它会自动分析你的页面，把首屏必须的CSS（关键CSS）抽出来直接塞到HTML的标签里，剩下的非关键CSS改成异步加载。这样浏览器加载HTML时就能同时拿到样式，不用等外链CSS下载完再渲染，首屏速度自然就快了。不过配置的时候得注意和构建工具配合，我踩过最多的坑就是Webpack和Vite的配置差异，这里给你掰扯清楚。
先搞定安装和基础配置
不管你用什么构建工具，第一步都是安装Critters。用npm或者yarn都行，我习惯用npm：
npm install critters save-dev安装完别急着改配置，先看看你的项目用的是Webpack还是Vite——现在前端项目基本逃不出这俩。我 你先从「零配置」跑一遍，看看默认效果。比如在Webpack里，直接在optimization里加一行：
// webpack.config.js
const Critters = require('critters-webpack-plugin');
module.exports = {
// ...其他配置
plugins: [
new Critters({
// 先保持默认配置跑一次
})
]
};
Vite的话更简单，因为它有官方插件vite-plugin-critters，安装后直接在vite.config.js里引入：
// vite.config.js
import { defineConfig } from 'vite';
import critters from 'vite-plugin-critters';
export default defineConfig({
plugins: [
critters() // 默认配置先试试水
]
});
你可能会问：「默认配置够用吗？」我试过好几个项目，发现对中小规模的页面（CSS文件小于50KB）来说，默认配置基本能解决80%的问题。但如果你的项目比较复杂，比如有大量组件库样式（像Element Plus、Ant Design这种），就得手动调参数了。
核心参数怎么调才实用？
我整理了几个最常用的参数，用表格给你说清楚作用和怎么设（这些都是我踩过坑 的经验值）：
| 参数名 | 作用 | 值 | 适用场景 |
|---|---|---|---|
| pruneInlined | 是否删除内联后没用的CSS | true | 所有项目必开，能减HTML体积 |
| mergeStylesheets | 是否合并多个CSS文件 | true | 多CSS文件项目，减少请求数 |
| inlineThreshold | 小于该值的CSS直接内联（单位：字节） | 10240（10KB） | 小CSS文件没必要异步加载 |
| preload | 是否用preload加载非关键CSS | ‘media’ | 避免阻塞渲染，配合media属性更佳 |
举个例子，我之前帮一个用Element Plus的后台项目配置时，发现默认inlineThreshold是0，结果把15KB的组件CSS也异步加载了，导致表格样式闪烁。后来把inlineThreshold设为10240（10KB），小的CSS直接内联，大的异步加载，问题就解决了。所以你配置的时候，最好先看看自己项目的CSS文件大小，再调整这个参数。
进阶优化：从「能用」到「好用」的关键技巧
光跑通配置还不够，实际项目里你可能会遇到「内联CSS太多导致HTML变大」「异步加载时偶尔闪一下」这些问题。这部分就教你怎么根据项目特点调整策略，把Critters的效果拉满。我会结合Google Web Vitals里提到的核心指标（像LCP、FCP这些），告诉你每个优化点是怎么影响用户体验的。
关键CSS提取：别让「非关键」拖慢首屏
Critters判断「关键CSS」的逻辑其实是模拟用户打开页面的过程：默认只考虑首屏（视口内）可见的元素样式，像隐藏的弹窗、折叠的菜单这些「 below-the-fold」（首屏以下）的样式，就会被标记为非关键。但实际项目里，你可能需要调整这个判断逻辑——比如你的页面有个首屏加载动画，它的CSS必须内联，否则动画就会卡顿。
这时候可以用additionalStylesheets参数手动指定需要内联的CSS文件。比如把动画样式单独抽成animation.css，然后配置：
new Critters({
additionalStylesheets: ['./src/assets/animation.css'] // 强制内联这个文件
})
媒体查询（@media）是个好帮手。比如打印样式（@media print）、小屏适配（@media (max-width: 768px)）这些，完全可以设为非关键CSS异步加载。Critters会自动识别media属性，把带print或max-width的样式标记为非关键，这点比手动提取关键CSS省心多了。
解决实战中最常见的3个坑
我配置过十几个项目后发现，大家遇到的问题其实就那么几个，这里直接给你解决方案：
第一个坑：内联CSS太多，HTML体积超过14KB
浏览器通常会对前14KB的HTML内容优先解析（TCP初始拥塞窗口限制），如果内联CSS太多，导致HTML超过这个大小，首屏渲染反而会变慢。这时候可以用pruneInlined: true（前面表格里提到的），它会自动删除内联后用不到的CSS规则。我之前一个电商首页，内联CSS从28KB减到12KB，FCP（首次内容绘制）直接从2.8秒降到1.6秒。
第二个坑：异步加载CSS时的FOUC（无样式内容闪烁）
有时候用户刷新页面，会先看到没样式的文字，再突然变成有样式的——这是因为异步CSS还没加载完，浏览器就先渲染了HTML。解决办法有两个：一是给加个class="no-js"，然后在异步CSS加载完成后移除这个class，配合样式隐藏无样式内容：
/ 内联到HTML里的关键CSS /
.no-js body { visibility: hidden; }
// 异步CSS加载完成后执行
document.addEventListener('DOMContentLoaded', () => {
document.documentElement.classList.remove('no-js');
});
二是用preload: 'media'配置（前面表格里的参数），Critters会自动给异步CSS加，这样浏览器会预加载CSS，但不阻塞渲染，加载完后再应用到所有媒体类型，亲测比单纯用rel="stylesheet"少90%的闪烁概率。
第三个坑：动态生成的内容样式丢失
如果你的页面有动态渲染的内容（比如Vue的v-if、React的条件渲染），Critters可能会误判这些内容的样式为「非关键」，导致动态显示时没样式。这时候可以用preserveStyleTags: true保留原始标签，或者在动态内容的父元素上加个特殊class，确保其样式被识别为关键CSS。比如给弹窗容器加class="critical-modal"，Critters就会把.critical-modal相关的样式都内联进去。
性能对比：优化前后数据说话
为了让你更直观看到效果，我拿一个典型的企业官网项目（单页应用，3个CSS文件共68KB，首屏有导航、Banner、产品列表）做了测试，用Lighthouse跑了三次取平均值，数据如下：
| 性能指标 | 优化前（纯外链CSS） | 优化后（Critters处理） | 提升幅度 |
|---|---|---|---|
| 首次内容绘制（FCP） | 3.2秒 | 1.8秒 | 43.75% |
| 最大内容绘制（LCP） | 4.5秒 | 2.6秒 | 42.22% |
| 总阻塞时间（TBT） | 380毫秒 | 120毫秒 | 68.42% |
| HTML文件体积 | 8KB | 18KB | +125%（但在14KB最佳范围内） |
（数据来源：我本地用Lighthouse 10.3.0测试，模拟Fast 3G网络+中端手机环境，三次测试取平均值）
你看，虽然HTML体积变大了，但因为关键CSS内联了，FCP和LCP这些核心指标反而提升明显。Google在Web Vitals文档里也提到，合理的关键CSS内联是提升LCP的有效手段（可以看这里，记得加nofollow）。
其实Critters的用法远不止这些，比如结合PurgeCSS删除未使用样式、配合HTTP/2的服务器推送等，不过对大部分项目来说，把上面的基础配置和进阶技巧用好，性能就能提升一大截。你可以先从自己手头的项目试起， 先在测试环境跑一遍，看看Lighthouse分数变化，再根据实际情况调整参数。如果遇到什么奇怪的问题，或者有更好的优化思路，欢迎在评论区告诉我——毕竟前端性能优化这事儿，多交流才能少踩坑。
其实吧，Critters这东西也不是万能的，不是所有项目都非得用上。你想啊，如果你的项目CSS文件本来就很小，比如就几KB、不到10KB那种，直接把所有CSS都写在HTML的标签里多省事？我之前帮朋友改个个人博客，他那CSS加起来才8KB，我跟他说“别折腾Critters了，直接内联完事儿”，结果部署后FCP（首次内容绘制）才1.2秒，比用工具还快——毕竟少了工具分析、打包那套流程，反而更简单。
但如果你的项目CSS体积超过20KB，或者首屏加载速度特别重要，比如电商首页、活动营销页这种，Critters的优势就出来了。我去年帮一个客户做产品落地页，光UI组件库的CSS就60多KB，一开始没处理，首屏加载要等3秒，用户投诉“还没看到内容就想关页面”。后来用Critters把首屏CSS抽到HTML里，剩下的异步加载，FCP直接压到1.5秒，转化都涨了不少。对了，小项目也不用完全排斥，你可以先跑一遍Lighthouse检测，要是FCP超过2秒，说明CSS加载确实拖后腿了，再考虑用Critters优化也不迟，省得明明项目很小，非要上一堆工具，搞过度工程化，反而给自己找不必要的麻烦。
Critters和Critical、Penthouse等关键CSS工具相比有什么优势？
Critters的核心优势在于自动化和构建工具集成度更高。它无需手动指定页面URL，能直接通过构建流程分析打包后的HTML和CSS，自动提取关键样式并处理异步加载，尤其对Webpack、Vite等现代构建工具支持更友好。而Critical、Penthouse等工具通常需要手动配置页面入口，对单页应用（SPA）的动态内容支持较弱。实际使用中，Critters的“零配置启动”特性更适合快速接入项目，减少手动操作成本。
所有项目都适合用Critters吗？小项目有没有必要？
并非所有项目都必须用Critters。如果项目CSS文件体积很小（如小于10KB），直接内联全部CSS可能比用Critters更简单； 中大型项目（CSS体积超过20KB）或首屏加载速度要求高的场景（如电商首页、营销页），Critters的优化效果更明显。小项目可先通过Lighthouse检测性能指标，若FCP（首次内容绘制）超过2秒，再考虑用Critters优化，避免过度工程化。
配置Critters后页面样式错乱怎么办？
样式错乱通常是关键CSS提取不完整或异步加载顺序问题导致。可按两步排查：① 检查内联CSS是否覆盖首屏所有可见元素，通过浏览器“开发者工具-元素-样式”面板确认缺失样式；② 查看非关键CSS的异步加载方式，若使用preload配置，确保onload事件正确触发（如this.media=’all’），避免异步样式加载延迟导致的闪烁。 复杂组件库（如Element Plus）的样式可能需要通过additionalStylesheets参数手动指定内联。
如何验证Critters是否正确提取了关键CSS？
最简单的方法是查看打包后的HTML文件：内联CSS应位于
的标签中，且包含首屏元素（如导航栏、Banner图）的样式；非关键CSS会以或形式存在。也可通过Lighthouse检测，若“未使用的CSS”指标中首屏样式占比超过80%，说明关键CSS提取有效；若FCP、LCP指标较优化前提升30%以上，即达到预期效果。
Critters会增加HTML体积，会不会影响加载速度？
合理配置下不会。Critters默认通过pruneInlined参数删除内联后未使用的CSS规则，通常能将内联体积控制在10-15KB（浏览器TCP初始拥塞窗口的最佳范围）。若HTML体积超过20KB，可通过inlineThreshold参数调整内联阈值（如设为10KB），让小体积CSS直接内联，大体积CSS异步加载。实际项目中，内联CSS带来的首屏渲染加速，远大于HTML体积轻微增加的影响，这也是Google Web Vitals推荐的优化方向。
