Google.com 和其他流量大的网站能否使用 Google 的 PSI API 获得 "fast" 排名？
Can Google.com and other heavily trafficked websites get a "fast" rank using Google's PSI API?
Google 将 fast-ranking FCP 的 PSI 定义从低于 1000 毫秒的 90% 更改为 75%
来自 PSI 文档：
Why does the FCP in v4 and v5 have different values?
FCP in v5 reports the 75th percentile (as of November 4th 2019),
previously it was the 90th percentile. In v4, FCP reports the median
(50th percentile).
好 data/tips 仍然是来自 Rick 下面的最佳答案。
原始问题：
在说 "based on field data the 'page is slow'" 时，是否使用 90% 而不是之前的中位数分数或较低的百分位数会使 google.com 等流量大的网站无法获得排名"Fast"？这是由于月流量在1000万以上且全球分布时出现的长尾？
我上次检查时（2018 年 2 月初），桌面 google.com 获得了 100 的 Lighthouse 综合分数，这应该被解释为 "there is little room for improvement," 然而，该页面排名 "slow" 因为第 90 个百分位数的 FCP 超过 3s。
像 nytimes.com 这样的页面在这个标准下是否会被认为是快速的，甚至 google.com 的桌面页面根据现场数据排名很慢？
最近的例子（2019 年 2 月 14 日）
之前的 FCP 尾巴更长的例子：
您误解了 google 灯塔结果。首先，没有性能测试是绝对的。不可能拥有完全 100% 性能的页面，因为即使它对我来说在 1 秒内加载，由于网络问题和延迟，它可能不会在加纳的人 1 秒内加载。即使我有一个没有 javascript 的纯 HTML 页面，它作为来自超快速 Web 服务器的静态文件提供，对于某个地方有拨号上网的人来说，该页面可能会在 10 秒内加载古巴或牙买加。
交通繁忙仅仅意味着"I get traffic not just from USA or Europe where the internet is blazing fast, I also get traffic from Jamaica where internet speed is a joke"。每个严肃的 Web 应用程序都有这个问题。所以是的，几乎没有改进的余地，因为你做的一切都是对的——这是一个本地互联网问题。
我想这会立即转化为 sociological/political "first world problem" 心态问题。您显然生活在第一世界国家或至少拥有 3G/4G 互联网，您无法想象牙买加人拥有 2G 互联网。所以不要担心灯塔百分比。由于该国家/地区的技术限制，使网站完全 100% 性能并在全球任何地方加载时间都不到 1 秒是不可能的——您无法修复。
直接回答问题，不，获得快速FCP标签并非不可能。这个问题还有很多，所以我会尽量详细说明。
表达 "fast" 标准的另一种方式是："Do at least 90% of user experiences have an FCP less than 1 second?"
为什么是 90%？因为它包含了大量的用户体验。正如 PSI docs 所说：
Our goal is to make sure that pages work well for the majority of users. By focusing on 90th and 95th percentile values for our metrics, this ensures that pages meet a minimum standard of performance under the most difficult device and network conditions.
为什么是 1 秒？这是用户期望页面开始显示有意义的进度的速度的主观值。 1 秒后，用户可能会分心甚至沮丧。当然，圣杯是即时加载，但选择这个作为努力实现的现实基准。
所以最坏情况下 10% 的 FCP 体验是 1 秒或更慢。这种特定类型的保证是一个足够高的标准，可以确保用户始终拥有快速体验。
这解释了为什么将栏设置在原处。对于实现的现实性问题，我们实际上可以使用公开可用的 CrUX data on BigQuery.
来回答这个问题
#standardSQL
SELECT
p90,
COUNT(0) AS numOrigins
FROM (
SELECT
origin,
MIN(start) AS p90
FROM (
SELECT
origin,
bin.start,
SUM(bin.density) OVER (PARTITION BY origin ORDER BY bin.start) AS cdf
FROM
`chrome-ux-report.all.201901`,
UNNEST(first_contentful_paint.histogram.bin) AS bin)
WHERE
cdf >= 0.9
GROUP BY
origin)
GROUP BY
p90
ORDER BY
p90
这是一个计算 FCP 直方图中起点的第 90 个百分位数的查询。如果这听起来令人困惑，这是一个可视化：
红色累积分布线穿过 1000 毫秒标记的位置告诉我们将被标记为快速的来源百分比。不是很多；数据集中只有 2% 或 110153 个来源。
有趣的是，浏览 "fast FCP" 个来源列表，其中许多都有 .jp 和 .kr TLD。可以合理地假设它们是本地化的日本和韩国网站，其用户几乎完全来自这些国家。这些国家 fast internet speeds。因此，当您的用户始终保持快速连接速度时，90% 以上的时间自然会更容易为快速网站提供服务。
我们可以做的另一件事是将其加入 Alexa 前 100 万个域列表：
#standardSQL
SELECT
Alexa_rank,
Alexa_domain,
COUNT(0) AS numOrigins,
ARRAY_AGG(origin LIMIT 3) AS originSample
FROM (
SELECT
origin,
MIN(start) AS p90
FROM (
SELECT
origin,
bin.start,
SUM(bin.density) OVER (PARTITION BY origin ORDER BY bin.start) AS cdf
FROM
`chrome-ux-report.all.201901`,
UNNEST(first_contentful_paint.histogram.bin) AS bin)
WHERE
cdf >= 0.9
GROUP BY
origin)
JOIN
`httparchive.urls.20170315`
ON
NET.REG_DOMAIN(origin) = Alexa_domain
WHERE
p90 < 1000
GROUP BY
Alexa_rank,
Alexa_domain
ORDER BY
Alexa_rank
有 35985 个来源的域名在前 1M。您可以 运行 自己查询以查看完整结果。
您可以看到前 20 个域中有大约 100 个来源符合 FCP 的快速要求。在列表的下方挑选一些有趣的例子：
- [#139]https://mobile.alibaba.com
- [#178] https://www.google.se
- [#422]http://www.design.samsung.com
- [#744]http://taxes.ca.gov
需要注意的是，这些 来源 不一定排名第一，只是他们的域名。在没有来源排名数据的情况下，这是我能做的最好的近似。
desktop/mobile BigQuery 和 PSI 是略有不同的数据集和 PSI 段，而我的分析将它们结合在一起。所以这项研究并不能完美地代表对 PSI 的期望。
最后，我只想解决有关在 Lighthouse 中获得 100 分的其他问题。 100 分并不一定意味着没有任何需要改进的地方。像这样的综合测试需要进行校准以代表实际用户体验。因此，例如，如果在代表菲律宾用户体验的条件下进行测试，性能审计可能会开始失败。实际上 运行 从该位置进行测试可能会出现性能问题，例如内容分发问题，以及我们可以在任何地方模拟的条件，例如连接速度。
总结一切：
- 设置高标准是因为我们要确保绝大多数用户体验是快速的
- 许多网站已经超过了这个标准，尽管只占整个数据集的一小部分
- Alexa 排名向我们表明，拥有一个流量大的网站并提供始终如一的快速体验是可能的
Will a page like nytimes.com ever be considered fast with this standard, when even google.com's desktop page is ranked slow based on field data?
答案是：是的，绝对。
我明白你的困惑。这是由 Google 拥有一个性能良好的网站的错误假设引起的。请注意 Google 的主页大得离谱。仅 HTML 就超过 200kb。它加载的 javascript 重达 436kb。页面总重量超过1Mb。我们在这个页面上看到了什么？绝对没有。字面意思是 an empty white page. One megabyte is the amount of code that could fill 500 pages of a book. The code in these two Harry Potter novels 需要在您加载此空页面后立即由您的浏览器执行。
只是为了让您了解这是多么大得离谱：我拥有一个 web development agency in Amsterdam 并且我的网站（首页）和这个 Google 页面一样空洞。但是，它只有41kb（包括一个完全不需要的自定义woff2字体文件，占用17kb）。
当您使用常规 3G 连接连接到 Google 主页时，页面加载时间超过 3.5 秒。想想这对牙买加或古巴人意味着什么！他们几乎无法在桌面上访问 Google，或者至少是非常糟糕的体验。作为比较：my website 加载速度比普通 3G 快 0.7 秒。重要的是要知道，当您的互联网速度较慢（相当于世界的一半）时，大小是影响速度的主要因素。
所以...桌面上的 Google 主页是一个非常糟糕的例子，它的低（速度）分数不值一提。 《纽约时报》很容易获得更好的分数，只需将其页面的权重降低到 Google 主页的权重以下。
性能得分与 FCP
Last time I checked (early Feb. 2018), the Desktop google.com received a 100 Lighthouse synthetic score, which is supposed to be interpreted as "there is little room for improvement," and yet, the page is ranked "slow" because the 90th percentile FCP is way over 3s.
在上面的部分中，您将 100 分与 FCP 联系起来。它不是那么简单（不再）。性能分数是以下变量的 a complex metric. It is the weighted avarage（请注意，FCP 不再是其中的一部分）。
第一个有意义的油漆 - 重量：5
首次互动 - 权重：5
持续互动 - 权重：5
速度指数指标 - 权重：1
估计输入延迟 - 权重：1
请注意，Google 主页需要 3.5 秒才能进行交互（根据 Lighthouse）。然而，由于指标的计算方式，它目前在性能上仍然得分为 97，这至少很了不起。这证实了（接近）100 分可能是一个误导性数字。
Google 将 fast-ranking FCP 的 PSI 定义从低于 1000 毫秒的 90% 更改为 75%
来自 PSI 文档：
Why does the FCP in v4 and v5 have different values?
FCP in v5 reports the 75th percentile (as of November 4th 2019), previously it was the 90th percentile. In v4, FCP reports the median (50th percentile).
好 data/tips 仍然是来自 Rick 下面的最佳答案。
原始问题：
在说 "based on field data the 'page is slow'" 时，是否使用 90% 而不是之前的中位数分数或较低的百分位数会使 google.com 等流量大的网站无法获得排名"Fast"？这是由于月流量在1000万以上且全球分布时出现的长尾？
我上次检查时（2018 年 2 月初），桌面 google.com 获得了 100 的 Lighthouse 综合分数，这应该被解释为 "there is little room for improvement," 然而，该页面排名 "slow" 因为第 90 个百分位数的 FCP 超过 3s。
像 nytimes.com 这样的页面在这个标准下是否会被认为是快速的，甚至 google.com 的桌面页面根据现场数据排名很慢？
最近的例子（2019 年 2 月 14 日）
之前的 FCP 尾巴更长的例子：
您误解了 google 灯塔结果。首先，没有性能测试是绝对的。不可能拥有完全 100% 性能的页面，因为即使它对我来说在 1 秒内加载，由于网络问题和延迟，它可能不会在加纳的人 1 秒内加载。即使我有一个没有 javascript 的纯 HTML 页面，它作为来自超快速 Web 服务器的静态文件提供，对于某个地方有拨号上网的人来说，该页面可能会在 10 秒内加载古巴或牙买加。
交通繁忙仅仅意味着"I get traffic not just from USA or Europe where the internet is blazing fast, I also get traffic from Jamaica where internet speed is a joke"。每个严肃的 Web 应用程序都有这个问题。所以是的，几乎没有改进的余地，因为你做的一切都是对的——这是一个本地互联网问题。
我想这会立即转化为 sociological/political "first world problem" 心态问题。您显然生活在第一世界国家或至少拥有 3G/4G 互联网，您无法想象牙买加人拥有 2G 互联网。所以不要担心灯塔百分比。由于该国家/地区的技术限制，使网站完全 100% 性能并在全球任何地方加载时间都不到 1 秒是不可能的——您无法修复。
直接回答问题，不，获得快速FCP标签并非不可能。这个问题还有很多，所以我会尽量详细说明。
表达 "fast" 标准的另一种方式是："Do at least 90% of user experiences have an FCP less than 1 second?"
为什么是 90%？因为它包含了大量的用户体验。正如 PSI docs 所说：
Our goal is to make sure that pages work well for the majority of users. By focusing on 90th and 95th percentile values for our metrics, this ensures that pages meet a minimum standard of performance under the most difficult device and network conditions.
为什么是 1 秒？这是用户期望页面开始显示有意义的进度的速度的主观值。 1 秒后，用户可能会分心甚至沮丧。当然，圣杯是即时加载，但选择这个作为努力实现的现实基准。
所以最坏情况下 10% 的 FCP 体验是 1 秒或更慢。这种特定类型的保证是一个足够高的标准，可以确保用户始终拥有快速体验。
这解释了为什么将栏设置在原处。对于实现的现实性问题，我们实际上可以使用公开可用的 CrUX data on BigQuery.
来回答这个问题#standardSQL
SELECT
p90,
COUNT(0) AS numOrigins
FROM (
SELECT
origin,
MIN(start) AS p90
FROM (
SELECT
origin,
bin.start,
SUM(bin.density) OVER (PARTITION BY origin ORDER BY bin.start) AS cdf
FROM
`chrome-ux-report.all.201901`,
UNNEST(first_contentful_paint.histogram.bin) AS bin)
WHERE
cdf >= 0.9
GROUP BY
origin)
GROUP BY
p90
ORDER BY
p90
这是一个计算 FCP 直方图中起点的第 90 个百分位数的查询。如果这听起来令人困惑，这是一个可视化：
红色累积分布线穿过 1000 毫秒标记的位置告诉我们将被标记为快速的来源百分比。不是很多；数据集中只有 2% 或 110153 个来源。
有趣的是，浏览 "fast FCP" 个来源列表，其中许多都有 .jp 和 .kr TLD。可以合理地假设它们是本地化的日本和韩国网站，其用户几乎完全来自这些国家。这些国家 fast internet speeds。因此，当您的用户始终保持快速连接速度时，90% 以上的时间自然会更容易为快速网站提供服务。
我们可以做的另一件事是将其加入 Alexa 前 100 万个域列表：
#standardSQL
SELECT
Alexa_rank,
Alexa_domain,
COUNT(0) AS numOrigins,
ARRAY_AGG(origin LIMIT 3) AS originSample
FROM (
SELECT
origin,
MIN(start) AS p90
FROM (
SELECT
origin,
bin.start,
SUM(bin.density) OVER (PARTITION BY origin ORDER BY bin.start) AS cdf
FROM
`chrome-ux-report.all.201901`,
UNNEST(first_contentful_paint.histogram.bin) AS bin)
WHERE
cdf >= 0.9
GROUP BY
origin)
JOIN
`httparchive.urls.20170315`
ON
NET.REG_DOMAIN(origin) = Alexa_domain
WHERE
p90 < 1000
GROUP BY
Alexa_rank,
Alexa_domain
ORDER BY
Alexa_rank
有 35985 个来源的域名在前 1M。您可以 运行 自己查询以查看完整结果。
您可以看到前 20 个域中有大约 100 个来源符合 FCP 的快速要求。在列表的下方挑选一些有趣的例子：
- [#139]https://mobile.alibaba.com
- [#178] https://www.google.se
- [#422]http://www.design.samsung.com
- [#744]http://taxes.ca.gov
需要注意的是，这些 来源 不一定排名第一，只是他们的域名。在没有来源排名数据的情况下，这是我能做的最好的近似。
desktop/mobile BigQuery 和 PSI 是略有不同的数据集和 PSI 段，而我的分析将它们结合在一起。所以这项研究并不能完美地代表对 PSI 的期望。
最后，我只想解决有关在 Lighthouse 中获得 100 分的其他问题。 100 分并不一定意味着没有任何需要改进的地方。像这样的综合测试需要进行校准以代表实际用户体验。因此，例如，如果在代表菲律宾用户体验的条件下进行测试，性能审计可能会开始失败。实际上 运行 从该位置进行测试可能会出现性能问题，例如内容分发问题，以及我们可以在任何地方模拟的条件，例如连接速度。
总结一切：
- 设置高标准是因为我们要确保绝大多数用户体验是快速的
- 许多网站已经超过了这个标准，尽管只占整个数据集的一小部分
- Alexa 排名向我们表明，拥有一个流量大的网站并提供始终如一的快速体验是可能的
Will a page like nytimes.com ever be considered fast with this standard, when even google.com's desktop page is ranked slow based on field data?
答案是：是的，绝对。
我明白你的困惑。这是由 Google 拥有一个性能良好的网站的错误假设引起的。请注意 Google 的主页大得离谱。仅 HTML 就超过 200kb。它加载的 javascript 重达 436kb。页面总重量超过1Mb。我们在这个页面上看到了什么？绝对没有。字面意思是 an empty white page. One megabyte is the amount of code that could fill 500 pages of a book. The code in these two Harry Potter novels 需要在您加载此空页面后立即由您的浏览器执行。
只是为了让您了解这是多么大得离谱：我拥有一个 web development agency in Amsterdam 并且我的网站（首页）和这个 Google 页面一样空洞。但是，它只有41kb（包括一个完全不需要的自定义woff2字体文件，占用17kb）。
当您使用常规 3G 连接连接到 Google 主页时，页面加载时间超过 3.5 秒。想想这对牙买加或古巴人意味着什么！他们几乎无法在桌面上访问 Google，或者至少是非常糟糕的体验。作为比较：my website 加载速度比普通 3G 快 0.7 秒。重要的是要知道，当您的互联网速度较慢（相当于世界的一半）时，大小是影响速度的主要因素。
所以...桌面上的 Google 主页是一个非常糟糕的例子，它的低（速度）分数不值一提。 《纽约时报》很容易获得更好的分数，只需将其页面的权重降低到 Google 主页的权重以下。
性能得分与 FCP
Last time I checked (early Feb. 2018), the Desktop google.com received a 100 Lighthouse synthetic score, which is supposed to be interpreted as "there is little room for improvement," and yet, the page is ranked "slow" because the 90th percentile FCP is way over 3s.
在上面的部分中，您将 100 分与 FCP 联系起来。它不是那么简单（不再）。性能分数是以下变量的 a complex metric. It is the weighted avarage（请注意，FCP 不再是其中的一部分）。
第一个有意义的油漆 - 重量：5
首次互动 - 权重：5
持续互动 - 权重：5
速度指数指标 - 权重：1
估计输入延迟 - 权重：1
请注意，Google 主页需要 3.5 秒才能进行交互（根据 Lighthouse）。然而，由于指标的计算方式，它目前在性能上仍然得分为 97，这至少很了不起。这证实了（接近）100 分可能是一个误导性数字。