绿色 Web 与可持续指标

• PUE 的定义与计算公式（数据中心总能耗 / IT 设备能耗）
• 可再生能源占比（Renewable Energy Percentage）对"灰色能源"的影响
• 前端如何通过选择 Green Hosting 降低 Scope 3 碳排放

PUE 是数据中心衡量能源效率的核心指标，等于数据中心总能耗除以 IT 设备能耗，PUE 越接近 1 说明基础设施越高效。可再生能源占比指数据中心使用风电、光伏等清洁能源的比例。前端工程师虽然无法直接控制服务器硬件，但选择使用绿色能源、PUE 低的托管商（如 Green Hosting provider）可以直接降低页面每次访问所对应的"每请求碳成本"。前端选型时应把托管商的能源透明度（如提供的碳足迹报告、PUE 公开数据）作为供应商评估的一部分，并结合内容精简、资源优化等前端手段共同降低总体碳足迹。

绿色 Web 的核心是"每单位价值的碳排放"最小化，前端优化的效益会被高 PUE、高碳足数据中心放大，因此选择节能托管是前端可持续性决策的杠杆之一。工程上应把 PUE 与可再生能源占比作为可持续性 KPI 的输入项纳入托管选型评估。

• Lighthouse CI 在 PR 中自动跑性能与碳足迹检查
• 用预算与阈值门禁防止性能回退
• CO2 模式基于 Lighthouse 指标估算碳排放

Lighthouse 的 Performance 得分衡量网站加载速度，第三方 CO2 检查（如 CO2.js 或 Lighthouse 相关扩展）可基于传输字节数、页面权重估算单次访问的 CO2 排放。在 PR 检查中通过 Lighthouse CI 或自定义 CI 脚本，针对 LCP、CLS、总字节量、估算碳排放等指标设置阈值，作为门禁（budget）阻止显著的性能与碳足迹回退，从而把可持续性治理前置到每天提交阶段而非事后优化。

性能与碳排放高度相关，一般页面越小越省电。把 Lighthouse 与 CO2 纳入 PR 门禁，能让团队在代码合并前就感知性能与能耗的回归，形成可持续的工程习惯，比事后全量审计更有效。

• 资源体积与网络传输能耗、设备渲染能耗的关系
• 代码分割、Tree Shaking、压缩、懒加载等优化
• 图片格式与尺寸优化（AVIF/WebP、响应式图片）

前端资源体积越大，网络传输耗电越多，设备解析、执行、渲染耗电也越多，因此减小资源体积是降低碳排放最直接的手段之一。工程实践包括：代码分割与 Tree Shaking 减少 JS 冗余、Gzip/Brotli 压缩、CSS 删除未使用规则、图片使用 AVIF/WebP 并结合 srcset 响应式加载、字体子集化、懒加载非首屏资源。这些手段既改善性能（LCP、TBT）也降低能源消耗，是"性能与绿色双赢"的典型做法。

传输与渲染能耗都随资源体积近似线性增长，前端资源优化是可持续 Web 的核心抓手。工程上应把体积控制纳入 performance budget，并定期用打包分析工具（如 webpack-bundle-analyzer）审计。

• 绿色只是多维决策因素之一
• 性能、可维护性、团队成本、生态等其他维度
• 避免"绿色洗白"（greenwashing）与过度营销

绿色可持续是前端技术决策的重要维度，但不应是唯一依据。技术选型还需权衡性能、可维护性、开发效率、团队技能、生态成熟度、可访问性、长期成本等。过度宣传"绿色"——例如把某次优化当作减排里程碑而忽略整体成本——容易陷入 greenwashing，且可能误导团队选择边际收益低却有巨大维护负担的方案。正确做法是把可持续性作为指标之一纳入决策矩阵，与性能、成本、可维护性共同权衡。

可持续性优化通常与性能优化高度重合，但二者并非完全等价。工程决策应以综合价值为准，避免单一指标绑架，同时要对"绿色"宣传保持言行一致的透明度，避免夸大减排效果。

• 碳强度（Carbon Intensity）的定义
• 数据传输、数据中心、设备能耗三个环节
• 估算的近似性与局限性

网页访问的碳排放估算通常分解为三个环节：数据中心的服务器能耗、网络传输能耗以及用户设备（网络与渲染）的能耗，三者各自乘以对应的碳强度（单位能耗的碳排放量）后累加。碳强度取决于当地电网的能源结构，不同地区差异很大。前端工程师主要能影响的是传输数据量与设备渲染能耗，而数据中心能耗与碳强度更多由托管商与电网决定。估算公式应是近似值，用于横向对比与趋势监测，而非精确计量。

理解了公式才知前端能控制哪一环——主要是传输字节数与设备能耗，而碳强度与数据中心属外部因素。常见的 CO2.js 等库正是基于此类模型估算，工程上应把估算结果用于相对比较而非绝对碳账。

• SCI 的计算公式与组成
• 软件碳强度的量化维度
• 前端结合 SCI 做可持续性度量

SCI（Software Carbon Intensity）是 Green Software Foundation 提出的标准化指标，用于量化软件系统每单位功能（如每次请求、每个用户）的碳排放强度。其核心理念是把软件运行产生的碳排放量化，公式大致为：碳强度 = 软件能耗 × 碳强度因子 + 嵌入式碳（硬件制造分摊），再除以用户数量或功能单位。前端可通过 SCI 思路，把页面单次访问的估算碳排放作为可持续性指标，追踪趋势并据此优化。

SCI 的价值在于把"绿色"从口号变成可度量、可对比的指标，支持团队在碳强度、能耗、功能三个维度做权衡。前端实践中常与 CO2.js、Lighthouse 等结合，把估算碳排量纳入可持续性报告。

• 流量：传输字节数越多，网络能耗越高
• 渲染：设备执行与渲染耗电
• 数据中心能耗：请求处理成本

Web 性能与碳排放呈强相关：页面加载慢、体积大，意味着更多网络流量、更长的设备渲染占用、更多的服务器处理时间，从而带来更高的能耗与碳排放。性能差的页面不仅浪费用户流量，还因页面长时间运行、多次重试等增加能耗。因此提升性能（减少体积、减少请求、优化渲染、减少不必要的重排回流）通常同时降低碳排放。反之，性能优化带来的可访问性与转化率提升，也能从"单位价值"角度摊薄碳成本。

把性能与碳排放绑定，可用现有性能指标（LCP、TBT、字节量）作为可持续性的代理指标，无需新增复杂计量，工程落地成本低。优化性能即优化能耗，是"绿色 Web"的最实用路径。

• Performance Budget 的定义与设置
• LCP 等核心指标与能耗的关联
• 用预算同时约束性能与碳足迹

性能预算是在开发周期内为页面设定的硬性指标上限，例如 LCP ≤ 2.5s、总 JS ≤ 300KB、首屏请求数 ≤ 20 个。由于能耗与体积、加载时间正相关，一个达标的性能预算通常也能把单次访问的碳排放控制在合理范围。团队可以把"单次访问估算碳排量"也作为预算项，与 LCP、CLS 等 Core Web Vitals 一起纳入 CI 与 Dashboard，形成"性能 + 可持续"双目标治理。

性能预算给了可持续性一个可执行、可追踪的落地载体。因为碳排量难以直接测量，用 LCP、字节量等性能代理指标作为预算约束，是工程上最可行、最可验证的绿色优化手段。

• 精简内容（减少冗余字节）
• 高效媒体（图片/视频格式与尺寸优化）
• 低碳托管（绿色数据中心）

Sustainable Web Design（可持续网页设计）由 Wholegrain Digital 等倡导，核心是"设计更轻、更高效的网站"。三大支柱包括：一、精简内容与设计——去除冗余组件、样式与文案，只保留必要功能；二、高效媒体——使用现代压缩格式（AVIF/WebP）、响应式尺寸、懒加载与视频优化，避免无效大图；三、低碳托管——选择使用可再生能源、PUE 低的托管服务。三者共同把"每页碳排放"降到最低，同时往往带来更好的性能与体验。

可持续设计把"减少"而非"增加"作为设计哲学，与传统性能优化和可访问性目标高度一致。工程上应把这三条原则固化为设计规范与代码审查约束，形成可持续的默认行为。

• CO2.js 的估算模型与输入
• 在 Node/构建脚本里调用
• 与 CI 门禁结合

CO2.js 是 GreenWeb Foundation 提供的开源库，通过传入页面数据量、访问次数等参数，基于"传输数据量 × 碳强度"模型估算碳排放。它可用在浏览器与 Node 环境，支持按最新碳强度数据（如 1-byte 模型）估算。集成到 CI 时，可在构建脚本中读取打包产物总字节数、结合 Lighthouse 的 transferSize 等数据，调用 CO2.js 计算单次访问估算，并与阈值比较，超限则令 CI 失败，从而把碳足迹纳入持续集成门禁。

CO2.js 的价值在于把抽象的"碳排放"变成可计算的数值，并支持自动化。CI 集成的关键是数据输入（传输字节、访问量）与阈值设定，起到"趋势监控 + 门禁"的作用，避免人工估算。

• prefers-reduced-data 的语义与浏览器支持
• 用 CSS/JS 对外提供服务降级
• 与用户数据套餐、省电的关联

prefers-reduced-data 是 CSS 媒体特性，用于检测用户是否表达了"减少数据使用"的偏好（如开启省流量模式）。配合 prefers-reduced-motion 等，前端可据此降级：替换大图为占位或低清图、禁用自动播放视频、减少非关键请求、关闭预加载与预取等。典型写法是 @media (prefers-reduced-data: reduce) { ... } 或通过 matchMedia('(prefers-reduced-data: reduce)') 在 JS 中动态控制。不过该特性目前浏览器支持有限，需考虑降级策略。

prefers-reduced-data 把"减少流量"的主动权交给用户，是尊重用户偏好、降低能耗与数据成本的实践。工程上应作为渐进增强，不支持时按默认行为，支持时提供轻量降级版本。

• 各格式的压缩率与宽容度
• 浏览器支持与降级策略
• 对 LCP 与带宽的影响

AVIF 在同等质量下压缩率通常优于 WebP，能显著减小体积，从而降低带宽、加快 LCP；JPEG-XL 压缩率与画质优秀但在浏览器支持上仍有限。AVIF 因主流浏览器（Chrome、Firefox、Safari）均已支持而成为 Baseline（可安全使用），而 JPEG-XL 支持仍不普及。工程取舍上，通常用 <picture> 提供 AVIF 优先、WebP/JPEG 回退的多源方案，兼顾体积与兼容性。对 LCP 而言，首屏大图（hero image）用 AVIF 带来的体积下降可明显改善 LCP 与带宽。

图片常占页面流量大头，格式选择直接影响 LCP 与能耗。AVIF 成 Baseline 使其成为默认首选，但需配合 <picture> 降级；JPEG-XL 未来可期但当前不宜作为唯一格式。取舍要结合图片类型（照片 vs 图形）与目标浏览器分布。

• 深色模式省电与屏幕类型的依赖（OLED vs LCD）
• Reduced Motion 减少动画能耗与确保可达性
• 省电的边界与适用条件

深色模式在 OLED/AMOLED 屏幕上因为黑像素不发光而确实省电，但在 LCD 屏幕上省电效果有限或几乎无差异。Reduced Motion 通过减少动画、过渡与滚动，能降低 GPU 工作与设备渲染能耗，同时对晕动症等用户可访问性有显著改善。所谓"省电边界"是指：深色模式的省电效果依赖屏幕技术，动画减少的能耗取决于动画对 GPU 的占用程度。因此不能想当然认为"深色即省电"，应根据设备与场景评估，并始终把可达性作为首要目标。

低功耗模式的省电是一个有条件的结论，依赖硬件与使用场景。工程上应同时尊重 prefers-color-scheme 与 prefers-reduced-motion，把可达性放在第一位，省电作为附带收益，避免过度承诺"绿色"。

• WSG 1.0 的定位与内容
• 与 W3C 的关系（WSG 被 W3C 采纳为规范）
• 对前端工程的指导意义

Web Sustainability Guidelines（WSG 1.0）是 Web 可持续性领域的一套指导准则，由 Sustainable Web Design 社区等推动，后来被 W3C 采纳为工作规范（W3C Sustainability Guidelines），为设计、开发、内容与运营提供可持续的落地建议。内容涵盖资源优化、媒体、托管、用户偏好、可访问性等，目标是把"绿色实践"系统化、可参照。前端团队可据此建立可持续性 checklist，纳入设计与代码评审。

WSG 把零散的可持续实践整理成结构化规范，并与 W3C 标准化接轨，使其从社区倡议走向可遵循的行业标准。工程上可作为团队可持续性治理的参考基线。

• MPA 每次导航全量重载 JS 的能耗
• SPA 复用运行时、减少全量重载
• 可持续性与性能的权衡

MPA（多页应用）每次导航都会重新加载并重新评估整页 JS，虽然首屏更简单、更利于缓存，但频繁切换时重复解析与执行 JS 会消耗更多设备能量；SPA 通过客户端路由仅加载增量 chunk，复用已实例化的运行时，理论上减少重复执行，但首屏需加载较大 JS 包，且长时间停留内存占用更高。可持续性取舍上，MPA 更适合内容站（缓存友好、切换少），SPA 更适合交互密集型应用（减少重复执行）。现代框架常以 MPA 为基础 + 局部增强（如 Astro、HTMX）来平衡。

MPA/SPA 的能耗差异来自"全量重评估"与"运行时复用"的权衡，没有绝对优劣，取决于页面切换频率与交互密度。工程上应结合业务形态选择，避免为 SPA 而 SPA。

• navigator.getBattery 的用途与限制
• Energy Impact 仅在 Chromium 内部，未暴露为 Web API
• 隐私与平台限制

Battery Status API（navigator.getBattery()）可读取设备电量、充电状态等，理论上可用于在低电量时提示用户或降级动画、减少非必要请求。但它存在隐私风险（电量可被用于追踪）且并非所有浏览器支持，它也未提供精确的"能耗 API"。所谓 Energy Impact 是 Chromium 内部用于性能评估的能耗估算指标，并未暴露为可供页面调用的 Web API，因此前端无法直接获取精确的能耗数值。工程上应谨慎使用 Battery API，并优先通过 prefers-reduced-motion 等可访问性偏好实现降级。

前端对能耗的控制是间接的，主要靠减少资源与尊重用户偏好，而非直接读取硬件能耗。Battery API 的隐私与支持局限决定了它不应作为核心节能手段，Energy Impact 更是内部指标，不可当作标准 API。

• 103 Early Hints 提前发送 Link 头
• Preload 提前加载关键资源
• 减少等待与往返，降低能耗

HTTP 103 Early Hints 允许服务器在最终响应前先发送 Link 头与预加载提示，浏览器可提前下载关键资源（CSS、字体、图片），与页面的 HTML 解析并行，从而减少关键路径等待时间。Preload（<link rel="preload">）则主动告知浏览器提前获取首屏关键资源。在弱网下，提前并行下载能减少往返延迟、避免串行等待，缩短加载时间，从而减少用户设备在等待期间的耗电与数据消耗。不过 Preload 需精准使用，过度预加载反而浪费数据。

Early Hints 与 Preload 通过"提前、并行"优化加载时序，在弱网下收益明显，既省时也省电。工程上应只预加载真正关键资源并配合优先级优化，避免盲目预加载造成数据浪费。

• 监控上报对网络请求的消耗
• 采样率与批量上报降低请求次数
• 在监控完整性与能耗之间权衡

前端监控（埋点、错误上报、性能上报）本身会产生大量网络请求，若每个事件都立即逐条上报，会显著增加网络负载与能耗。工程上通过采样（按比例抽样，如 hash 采样）、批量上报（把多条事件合并成一次请求，如 sendBeacon 批量发送）、以及节流/去重来减少请求次数。边界在于：过度采样会牺牲数据的完整性与准确性，需要在监控覆盖度与网络/能耗开销之间取得平衡，同时避免重复上报干扰数据质量。

监控本身也是"资源消耗者"，需控制其开销。采样与批量上报是降低前端监控对网络与能耗影响的标准手段，关键是设定合理的采样率与上报策略，使监控数据既足够又不过度。