Front-End-Checklist 中的 compression 技能:用 Gzip/Brotli 启用文本压缩并验证传输体积-二趣网

Front-End-Checklist 中的 compression 技能:用 Gzip/Brotli 启用文本压缩并验证传输体积

【免费下载链接】Front-End-Checklist🗂 The essential checklist for modern web development, for humans and AI agents项目地址: https://gitcode.com/gh_mirrors/fr/Front-End-Checklist

本篇技术文章基于 Front-End-Checklist 仓库中的skills/compression/SKILL.md技能文档展开,完整覆盖该技能定义的检查项(确认Content-Encoding: gzip或br响应头)、修复方式(Nginx/Apache/CDN 或 Node.js 中间件启用压缩),并结合仓库中技能生成脚本与 MCP 规则服务实现,讲解这条"启用文本压缩"性能规则的完整落地与验证路径。读完后,你可以复现该技能在 Agent 工作流中的调用链路,并掌握一份可复制的 Gzip/Brotli 配置与验证清单。

技能定位:压缩规则在 Front-End-Checklist 中的位置

skills/compression/SKILL.md是仓库中约 400 条前端性能/SEO/可访问性规则之一被生成为 Agent 技能(Skill)后的产物,其 frontmatter 声明了技能的元数据:

name: compression description: "Use when auditing slow page loads, heavy assets, or rendering delays related to Enable text-based compression. Verify the actual bottleneck in DevTools, Lighthouse, or field data before recommending changes." metadata: category: performance priority: high difficulty: beginner estimatedTime: "10" source: frontendchecklist.io

从源码结构看,这些技能并不是手写的:scripts/generate/generate-skills.ts负责把packages/content/rules/en/下的规则 MDX 文件按 frontmatter 逐条生成为skills/{slug}/目录(含SKILL.md与references/rule.md),可通过pnpm generate:skills全量生成,或由 lefthook 钩子对变更文件做增量生成。compression 技能的"母本"正是 compression 规则源文件,其 frontmatter 中的prompts(check/fix/explain/codeReview 四段提示词)、aiContext、sources与relatedRules字段,最终会被拆分进 SKILL.md 与 references/rule.md 两个文件。

核心概念:文本资源为什么"可压"且值得压

规则源文件的正文开宗明义:HTML、CSS、JavaScript 这类文本资产具有高度重复性,在网络传输前通常可以压缩 70% 以上。压缩资产下载更快,能缩短首次绘制时间,改善整体感知性能,在较慢的移动网络上收益尤其明显。

references/rule.md的 "Why It Matters" 一节给出了四条论据:

更快的下载:文件越小传输越快,高延迟、低带宽连接上收益最明显;
降低成本:降低带宽占用,可能减少托管或 CDN 费用;
改善 Core Web Vitals:直接影响 First Contentful Paint(FCP)与 Largest Contentful Paint(LCP);
浏览器支持普遍:所有现代浏览器支持 Gzip,多数浏览器支持压缩效率更高的 Brotli。

检查项与修复动作:Check 与 Fix

技能文档将规则拆为四个可执行段落,这也是 Agent 使用此技能时的工作流骨架:

Check(检查):验证文本类资源是否以Content-Encoding: gzip或br响应头提供服务;
Fix(修复):在 Web 服务器(Nginx、Apache)或 CDN 设置中启用 Gzip 或 Brotli 压缩;
Explain(解释):说明文本压缩的工作原理及其对资产投递速度的影响;
Code Review(代码审查):审查影响该规则的路由、资产与加载行为,标记出确切添加不必要网络/CPU/布局成本的文件、请求或渲染步骤,并说明用于确认问题的测量方法。

frontmatter 中的aiContext字段进一步约束了使用时机:只有在审计慢页面加载、重资产或渲染延迟,且已用 DevTools、Lighthouse 或真实用户数据确认了实际瓶颈之后,才应给出压缩相关建议——先验证瓶颈,再开药方。

配置实操:从 references/rule.md 继承的完整示例

技能引用的 references/rule.md 给出了两类可直接落地的配置,完整保留如下。

Nginx 配置

# Enable Gzip compression gzip on; gzip_types text/plain text/css application/javascript application/json image/svg+xml; gzip_min_length 1000; # Enable Brotli (requires module) brotli on; brotli_types text/plain text/css application/javascript application/json image/svg+xml;

逐条解读:gzip on打开 Gzip;gzip_types显式列出要压缩的 MIME 类型——注意官方示例特意包含了image/svg+xml(SVG 是文本格式)、application/json与application/xml系格式,这正好呼应了后文"别只压 HTML/CSS/JS"的最佳实践;gzip_min_length 1000设置了 1000 字节的最小压缩阈值,避免为极小文件做无用功。Brotli 段依赖 Nginx 的 Brotli 模块(配置注释中已注明 "requires module")。

Express.js(Node.js)

const compression = require('compression'); const express = require('express'); const app = express(); // Enable Gzip compression for all responses app.use(compression()); app.get('/', (req, res) => { res.send('Hello World!'); });

这是基于compression中间件的最小示例:app.use(compression())会对所有响应启用 Gzip,中间件内部会依据请求方的Accept-Encoding头协商编码并写入Content-Encoding响应头,这正是 Check 步骤中要验证的头。

权衡分析:压缩省的是"传输",不是"解析"

references/rule.md的 "Compression Tradeoffs" 一节是本规则最有工程判断力的部分,引用了 web.dev 的性能指导观点:传输收益只解决了网络侧问题,字节到达客户端后的解析与执行成本依然存在:

网络 vs CPU:Brotli/Gzip 降低的是线上字节数,但浏览器仍要对下载的代码做解压、解析、编译与执行;
大 bundle 依然伤性能:一个重度压缩后的 300 KB JavaScript bundle,在下载结束后仍可能长时间阻塞主线程;
拆分依然重要:压缩应与代码分割、懒加载配合,让用户在初始路由上不必下载用不到的代码;
服务器成本要算账:过高的实时压缩等级会推高源站 CPU 使用率与 TTFB,静态资产尽量在构建时预压缩。

最佳实践清单:五条 Do、两条 Don't

原文档以 ✅/❌ 形式给出了七条实践,全部保留:

✅优先 Brotli:Brotli 通常比 Gzip 小 15–20%; ✅压缩所有文本格式:HTML、CSS、JS 之外,别忘了 SVG、JSON、XML; ✅预压缩静态资产:在构建过程中压缩,而不是运行时实时压缩,效率最高; ✅检查最小体积阈值:极小文件(如 < 1KB)的压缩开销可能超过收益,不要压; ✅把压缩放回上下文:它只是传输层优化,不能替代更小的 bundle 和更少的主线程工作量。

❌不要压缩二进制格式:JPG、PNG 图片和视频本身已是压缩格式,再次 Gzip 反而可能增大文件并浪费 CPU; ❌避免实时高压缩等级:在线上用最高压缩等级会因 CPU 开销推高 TTFB。

验证方法与工具:从响应头到 Lighthouse

技能的 "Tools & Validation" 与 "Verification" 两节把验证拆成了三层:

DevTools 检查:在 Network 面板的资源响应中查找Content-Encoding头;
在线校验工具:原文档提及了 GZIP 与 Brotli 的在线检测工具,可用它们针对特定 URL 验证编码协商是否生效(文中不附外部链接,按名称在搜索引擎中查找即可);
指标级验证:启用压缩后,用 Lighthouse 或 PageSpeed Insights 测量受影响页面,确认更小的载荷确实转化为路由级性能提升,而不仅仅是一个"配置勾选框"。

此外还给出了自动化与手动两条验证路径:自动化方面,在 Lighthouse、PageSpeed Insights 或 DevTools 中测量受影响页面并确认目标指标改善,同时检查网络瀑布流/性能时间线确认资源或执行变更真的生效;手动方面,必须在节流的移动网络档案下验证,而不是只看本地桌面,若该规则映射到某个性能预算或 Web Vital 阈值,还要确认页面现在稳定落在阈值之内。

仓库内的服务链路:规则如何被 MCP 工具与技能生成消费

为了让"事实边界"清晰,这里补充仓库源码中确认的两条链路:

技能生成链路:scripts/generate/generate-skills.ts从规则 MDX 的 frontmatter 生成skills/{slug}/目录。compression 技能的目录结构(SKILL.md + references/rule.md)即由该脚本产出,目录名必须与name字段一致(脚本注释中提到的 skill-checkname_matches_directory规则)。
MCP 规则服务链路:packages/mcp/src/tools/get-rule.ts 实现了get_rule工具,按 slug(本规则为compression)查找规则,用mdxToMarkdown把规则正文转换为 Markdown 后连同prompts(check/fix/explain/codeReview)、aiContext、difficulty、estimatedTime、sources等字段一并返回给 Agent;若规则在 frontmatter 中定义了relatedRules,则优先使用,否则回退到源码中维护的静态关系图。compression 规则在规则源文件中声明了三条关联规则:css-file-size、http-requests、js-file-size,均属于performance/assets域、常被一起审查——这也提示读者:压缩排查时通常要与 CSS/JS 体积、请求数量规则联动评估,与技能正文"把压缩放回上下文"的建议一致。

企业官网建设流程全解析