我100%同意上述观点。从实践的角度来看，我认为我们应该制定一个开放的排放数据存储和传输标准。然后，不同的托管提供商可以将其数据导入到一个通用的文件位置和文件格式中，然后可持续插件可以使用该文件格式。如果我们现在设定这个标准，我们可以（希望）避免旧的xkcd竞争标准脚本。

我想了很多，有一些想法要提

1. 应报告mgCO中特定现场的排放数据₂/请求
2. 我们应该指定构成请求的内容，例如从“本地”缓存提供、执行PHP、从边缘缓存或CDN提供。
3. 排放数据应存储在WordPress可持续发展插件可用的特定文件位置
4. 排放数据的格式应该定义良好、开放并可扩展（这里首先想到的是JSON）

早些时候的谈话告诉我，为了成为一个最终目标是有一天成为WordPress核心的一部分的插件，该插件不应该与任何外部API或服务交互。

@黄色时间NL你有这方面的书面证明吗。我在开发人员指南中找不到它，但诚然，搜索它很困难。

我们需要认识到插件的逻辑限制。它可以追踪的排放量不是绝对的，而是相对的。

此限制的原因可能包括以下几点-我愿意接受这些方面的更正，但我理解，所有这些可能都与WordPress的一些重要安装基础相关：

1. 托管服务很少提供能源使用的完整分类，通常不包括冷却和其他不特定于服务器/实例的项目。
2. 页面呈现不包括网站的高能耗功能，如搜索和消息传递。
3. 搜索和消息传递可以在核心WP中进行，也可以在外部进行，这种架构对于插件来说是不可见的，但它对效率和能源使用有着巨大的影响。
4. 网络分发通常比服务器消耗更多的能源（如果使用零碳托管，则碳影响要大得多）
5. 页面权重和数据调用对网络的影响无法准确测量，因为能量消耗取决于网络架构，而这对插件来说是不可见的。
6. 渲染客户端通常比服务器或网络分发更耗能。
7. 虽然页面权重和本地处理可以给出相对效率评级，但如果没有渲染客户端的能源详细图片，则无法给出页面的绝对能源和碳排放数据。

这并不是说插件没有用处。是的。但是。。。。我们需要非常清楚插件输出的值。如果我们要为更广泛的WP社区提供一套好的指导，我们可能还需要认真考虑插件以及其他工具和服务。

哦，引用你的一些原始资料，“事情很快就会变得复杂”😁 我真的很喜欢计算数字发射文档，但就他们关于封闭系统和数据可用性有限的观点而言，我一直试图做的大部分工作都集中在数据中心部分的数据表面。看看我们自己的数据，我满怀信心地说，碳生产中存在两大变化轴：网站设计和网站所在地。除了告诉你你的碳排放量外，网站托管公司对第一个问题无能为力。显然，通过提供可再生能源数据中心的选项，托管可以在第二方面发挥很大作用。

也就是说，我以前不知道这个标准，但我现在正在阅读它，并有一些担忧。首先，报告指标kWh/GB的选择是站点的平均值全球合作组织₂/千兆字节在整个互联网上，因为获取实际的碳强度常数通常是不可能的。然而，如果托管公司提供了这些数据，那么全球合作组织₂/访问可以为特定网站更准确地计算。我认为这一点很重要，因为（a）它可以让最能控制排放的人更准确地知道他们的排放量，（b）它可以通过他们自己的设计选择更有效地减少这些排放量，以及（c）它可以使他们通过他们的购买决策，即托管选择，更有效地降低这些排放量；这可能会开始对托管公司施加压力，迫使其在某种程度上做出更好的选择千瓦时平均法没有。

我认为可能还有问题/国标还有一点，因为就排放量而言，从CDN中提供一个非常大的静态文件可能比在源代码中不断地计算复制相同的内容更便宜。另一个例子是，与在静态文件中下载相同数量的字节相比，AI聊天机器人在生成数千字节文本时消耗的能量要多得多。

这就是为什么我支持全球合作组织₂/访问; 在我看来，不是碳排放计算专家的网站所有者可以更容易地理解这一点。此外，这是一个衡量网站所有者可以影响的指标，因为他们控制的碳排放操纵实际上只有三个方面：他们在哪里托管（影响碳强度），他们如何设计网站（影响服务的字节数千兆字节)以及他们如何使用CDN/caching/etc从技术上设计他们的网站（影响碳强度）。两个控制杆未在/GB（英国）计算。

注意：全球合作组织₂/访问与我建议的测量值相同mgCO公司₂/请求，只是归一化为克。如果以克为标准，这对我来说很管用，尽管许多人以克为单位报告会导致许多前导零的😉

好吧，回顾一下我之前写的内容，我想指出，我建议制定的标准是WordPress标准，允许托管公司（和开源托管堆栈）以WordPres网站可以访问的方式存储计算出的碳强度修改信息，所以任何想要使用它的插件都可以使用它，我建议使用的标准单位应该是全球合作组织₂/访问因为标准的这一部分考虑了不同的碳强度。。。

因为CO2.js是开源的，所以可以选择向他们（项目维护人员）提供您提到的一些反馈吗？
我只是大声思考。

如果不是，您提议的模型是否也会公开收集外部反馈？
我只是担心我们会创建更多可以维护的模型/库。

对不起，我直到现在才看到这个回复。迷失在电子邮件洪流中😞

当然可以。在所有方面。如果我们能逆流而上，使其不仅仅是WordPress，我认为这将是一场巨大的胜利。我愿意听取任何人和任何地方对此的反馈。此外，我一直在思考如何最好地做到这一点，现在我相信HTTP头是一种更好的方式。这使得像CO2.JS和浏览器扩展这样的JS库可以使用这些数据。

AFAICT我们需要两个输入来有效使用网站碳API，我们需要字节和绿色作为输入（参见示例请求：https://api.websitecarbon.com/data？字节=1000&green=1。我意识到完美是进步的敌人，但我希望看到Google Pagespeed作为退路。使用浏览器提供JS API以更轻松地获取“下载的字节”可能更理想。失败了，也许正确的方法是浏览器扩展，而不是WP插件。无论哪种方式，都可以获得绿色高度依赖于托管提供商。我认为，为托管提供商提供一种标准方法，为绿色，可能在HTTP标头中。我绝对明白这会被滥用，应该得到核实。所以我想我们可以将其与绿色网络基金会的列表结合使用，使用逻辑AND。如果这两个值不匹配，我们将显示从乐观到悲观的一系列排放。

我还认为碳足迹应该成为Page Health的首要和核心（最终）

我认为可能是一张罚单（在Trac中），并推动WP 6.6。

字体库将针对该版本（可能是之前的版本）进行更改，因此新的迭代可以很好地进行测试，可能首先使用Gutenberg，然后再在核心中进行测试。

关于woof2，100%与你https://caniuse.com/woff2

我发现了与GitHub相关的编辑器问题（我本应该知道），但很高兴在这里提到它：WordPress/gutenberg#54186.

我还需要找时间测试Perfume.js。我相信你可以衡量资产负载的权重，但我想，还是只针对第一方资产（例如CDN等第三方资产）。

不错，听起来很棒！我认为这是一场伟大的胜利，特别是因为还有一个与隐私相关的部分。我不确定造型是否超出范围。

一个问题：一旦用户同意，嵌入是否会在连续页面加载时自动加载？或者它仍然是某种占位符（所以在新页面加载上仍然有一个发射胜利）？我认为，理想情况下，我们应该两全其美，同意与立即加载分开。

哦，对不起，如果脱线了。也许阅读嵌入内容的讨论本身应该是一个线程。

嗯，真有趣。我不知道有那么多。另一个插件和资产管理插件AssetCleanup也提供了删除其中一些插件的功能。即使使用免费版本的“免费增值”插件，我也能体验到良好的效果。

https://wordpress.org/plugins/wp-asset-clean-up/