说起网站优化，很多人的第一反应是问问大模型或者「Google一下」。

然后你会发现大量的教程：

「10个提升网站性能的方法」「SEO优化的5个技巧」「WCAG无障碍设计指南」...

这些文章都有道理，但存在两个问题：

第一，知识点太散了。 性能、SEO、无障碍、安全...每个领域都有一堆要注意的地方，但你很难把它们串成一个整体。

第二，标准太模糊。 有人说首屏加载要在3秒内，有人说2秒，有人说1秒。到底谁说的对？这些数字从哪来的？

我之前做项目的时候，就经常陷入这种「东一榔头西一棒槌」的状态。性能达标了但SEO没做，SEO做好了又发现无障碍有问题，改来改去总是按下葫芦浮起瓢。

直到我接触到一个叫 Web Quality Skills 的开源项目。

Web Quality Skills 是基于 Google Lighthouse 指南构建的 Agent Skills 集合。它的设计思路很有意思：不是简单地告诉你「要做什么」，而是系统地告诉你「怎么做才能达到专业标准」。

打个比方，这就像是给你的网站请了一个24小时在线的顾问。这个顾问懂性能、懂SEO、懂无障碍、懂安全，而且对Google的评分标准了如指掌。

更重要的是，这个顾问可以集成到你日常使用的AI编程工具里。当你问「这个页面加载慢怎么办」，它不是泛泛地建议你「优化图片」，而是直接告诉你：

「你的LCP指标是4.2秒，主要原因是hero图片没有设置 preload，建议在HTML里加这行代码...」

听起来很美好对吧？

让我们来看看它具体是怎么工作的。

Web Quality Skills 把网站质量拆成了六个核心模块。如果把整个项目比作一个医院体检中心，那么：web-quality-audit 是前台挂号处，负责接待、分配检查项目，剩下五个模块分别是各个专科诊室。

综合质量审计（web-quality-audit）

web-quality-audit 会自动调用其他五个模块的能力，对网站做一次全面检查。它会把所有发现的问题汇总成一份报告，按严重程度排序：

• Critical（紧急） —— 安全漏洞、致命错误，需要立刻处理
• High（高优先级） —— Core Web Vitals不达标、严重无障碍障碍，上线前必须修复
• Medium（中优先级） —— 性能优化机会、SEO改进点，建议在当前迭代处理
• Low（低优先级） —— 代码风格、轻微优化，可以择机处理这份报告就像体检报告一样，让你对自己网站的质量状况有一个全景了解。

性能优化（performance）：让你的网站「快」起来

做网站的人都听说过「网页加载要快」。但「快」到底是什么概念？

Google的标准是这样的：

• LCP（最大内容绘制）≤ 2.5秒 —— 用户能看到主要内容的时间
• INP（交互到下一帧绘制）≤ 200毫秒 —— 用户点击或输入后，屏幕多久更新一次
• CLS（累积布局偏移）≤ 0.1 —— 页面加载时，内容会不会「跳来跳去」这些数字不是随便定的。Google分析了成千上万个网站的用户行为，发现当LCP超过2.5秒，用户的流失率会显著上升。性能优化模块会教你具体怎么做：比如图片这件事，很多人以为只要压缩一下就行了。但实际上讲究很多：用什么格式？业内普遍认为WebP比JPEG体积小30%左右，AVIF压缩率更高，但不同浏览器兼容性不同；要不要预加载？首屏的图片应该在HTML里就用 link rel="preload" 提前告诉浏览器；多大的尺寸？手机和电脑屏幕不一样，用 srcset 属性让浏览器自动选择合适的尺寸；...这些细节单个看都不起眼，但加在一起，决定了你网站的速度。

核心网络生命力（core-web-vitals）：专注于Google的三大指标

这是一个专门针对 Google Core Web Vitals 三大指标优化的模块。

为什么要单独拆出来？因为这三个指标直接影响了你的网站在 Google 搜索结果中的排名。Google 明确把「页面体验」纳入了排名因素，而 Core Web Vitals 就是衡量页面体验的核心标准。

这个模块会深入检查：

LCP（最大内容绘制） —— 页面主要内容多久能呈现？

常见问题包括：服务器响应太慢、图片没有预加载、存在阻塞渲染的资源（CSS/JS）、使用客户端渲染导致内容加载延迟。

INP（交互到下一帧绘制） —— 用户操作后多久能看到反馈？

常见问题包括：主线程被长任务阻塞、事件处理函数执行时间过长、没有使用 requestIdleCallback 延迟非紧急工作。

CLS（累积布局偏移） —— 页面视觉是否稳定？

常见问题包括：图片和视频没有设置尺寸、动态内容在加载后才插入、字体切换导致文字位置跳动（FOUT）。

无障碍（accessibility）：让每个人都能用

我之前对无障碍设计也有误解，觉得「我的用户都是正常人，不需要管这些」。

后来我发现这个想法很片面。

无障碍设计的受益者远不止残障人士：

• 有人在户外阳光下使用手机，普通的灰色文字根本看不清
• 有人手臂受伤临时无法使用鼠标，只能用键盘操作
• 甚至只是网速不好的人，也受益于懒加载等无障碍相关的优化技术无障碍模块遵循的是 WCAG 2.2 标准，这是W3C发布的国际无障碍指南。它检查的核心就四点，简称 POUR：可感知 —— 内容能不能被不同感官接收到？图片有没有替代文字？视频有没有字幕？可操作 —— 所有功能能不能不用鼠标也能用？键盘能不能完整操作？可理解 —— 语言是否清晰？表单错误有没有明确提示？健壮性 —— 页面在各种浏览器、屏幕阅读器里能不能正常工作？具体到代码层面，有意思的细节就更多了。比如颜色对比度。大家都说「对比度要够高」，那多高算够？WCAG AA标准要求正常文本对比度至少4.5:1，大文本（指18px及以上，或14px及以上的粗体）至少3:1。更严格的AAA标准是7:1和4.5:1。翻译成大白话就是：如果你用浅灰色文字配白色背景，在电脑上可能看着挺舒服，但到了阳光下或者对视力不好的人来说，就几乎是透明的。再比如图片alt属性。我以前觉得随便写点就行，但好的alt应该是描述性的：「一张产品的照片」不如「这是一款黑色双肩背包，正面有一个拉链口袋，肩带上有反光条」。这些细节看起来琐碎，但真正需要的时候，一个好的alt文字能帮助无数人理解那张图片的内容。

SEO：让Google读懂你的页面

说到SEO，很多人第一反应是「关键词密度」。但这是十几年前的老黄历了。

现代SEO的核心是三件事：

你的页面Google能不能找到？ 这涉及robots.txt、sitemap、结构化数据等技术细节。

你的页面内容Google能不能理解？ 这涉及标题、描述、标题层级、内链布局等。

你的页面体验Google认不认可？ 这就是前面说的Core Web Vitals——Google已经把页面体验纳入了排名因素。

SEO模块会逐项检查这些内容。比如标题，Google能显示的字数大概在50-60个字符，超过了会被截断。比如meta description，虽然不直接影响排名，但会影响搜索结果的点击率——一个写得好的描述能让更多人愿意点进来。

有意思的是结构化数据。很多人都忽略了这个。结构化数据是一种用特定格式告诉Google「这个页面是什么内容」的技术。

比如你写了一篇食谱，在页面里加一段JSON-LD代码，Google就能在搜索结果里显示「烹饪时间」「卡路里」「评分」这样的丰富摘要。

这种东西对点击率的提升是很明显的。

最佳实践（best-practices）：安全与代码质量

这一块可能不如前面几个那么常被提起，但同样重要。

它检查的是：

网站是否使用了HTTPS加密？

是否有潜在的安全漏洞，比如XSS跨站脚本攻击？

代码里有没有使用过时的、已经不推荐的API？

控制台有没有错误信息？

...

很多人觉得「我这是小网站，没人黑我」。但实际情况是，自动化的扫描工具一直在互联网上寻找存在漏洞的网站，不管你网站大小。

所以这一块的检查，某种程度上是给自己买个保险。

说完了各个模块，我们来聊聊这个项目本身有意思的地方。

第一个特点是框架无关。

现在前端框架太多了。React、Vue、Angular、Svelte、Nuxt、Next.js、Astro...每个框架都有自己的最佳实践。

很多工具是为特定框架量身定做的，换个框架就用不了。

Web Quality Skills 不是这样。它检查的是「网页最终的效果」，而不是「代码怎么写的」。不管你用什么框架（甚至纯HTML），最终渲染出来的HTML在浏览器里表现如何，这才是它关心的。

这让它有了很强的通用性。你今天用Next.js做了个项目，明天想迁移到Astro，技能包直接就能用，不需要重新学习。

第二个特点是和AI编程助手的结合。

传统的网站审计流程是这样的：打开Lighthouse，跑一遍，看报告，逐一修复。

这种方式有几个问题：

你得自己理解每个问题的原因；

你得自己查找修复方案；

你得自己判断优先级。

而Web Quality Skills 把它变成了对话：

你：「这个页面加载有点慢，帮我看看」

AI：「我扫描了一下，发现三个主要问题。第一，LCP时间是3.8秒，超过了2.5秒的标准，主要原因是...」

这种方式的门槛低了很多。你不需要先成为网站优化的专家，也能做出专业水准的网站。

第三个特点是持续更新。

Google的评分标准不是一成不变的。Lighthouse每年都有更新，Core Web Vitals的算法也可能调整。

Web Quality Skills 作为开源项目，可以跟着Google的步伐持续迭代。你用的时候，相当于始终在用最新的标准。

写在最后。

写这篇文章的时候，我一直在想一个问题：Web Quality Skills 解决的到底是什么问题？

表面上看，它解决的是「网站质量怎么提升」的问题。

但往深一层，它解决的是「如何系统地学习网站质量」的问题——通过和AI的对话，你能从一个更高维度理解各个知识点之间的关联。

再往深一层，它其实解决的是「技术民主化」的问题——让没有专职前端工程师、没有SEO专家的小团队，也能做出达到专业水准的网站。

技术路上的成长，大概就是这样吧。

遇到问题，解决问题，然后变得更强一点。

相关资源

• Web Quality Skills 项目地址：https://github.com/addyosmani/web-quality-skills
• Google Lighthouse：https://developer.chrome.com/docs/lighthouse/
• Core Web Vitals 详解：https://web.dev/articles/vitals
• WCAG 无障碍指南：https://www.w3.org/WAI/WCAG22/quickref/