Google将快速排序FCP的PSI定义从1000ms以下的90％更改为75％
从PSI文档中:
来自下面Rick的最佳答案中的好的数据/提示。
原始问题:
如果说“基于现场数据，“页面速度很慢””，使用90％的分数而不是以前的中位数或更低的百分位数，是否会使排名高的网站(如google.com)永远无法排名“快速地”？这是由于当月流量在1000万以上且分布在全局范围内时会出现长尾部吗？
上次我检查(2018年2月上旬)时，Desktop google.com的综合得分为100，应该被解释为“几乎没有改进的余地”，但是，该页面的排名为“慢”，因为第90个百分点的FCP超过3秒。
即使根据字段数据将google.com的桌面页面排名都较慢，使用nytimes.com之类的页面是否会被视为采用该标准的页面？
最近的示例(2019年2月14日)
FCP的尾部更长的前一个示例:
最佳答案
要直接回答这个问题，不，并非没有不可能获得快速的FCP标签。这个问题还有更多，所以我将尽力阐述。
用另一种方式表达“快速”标准的方法是:“至少90％的用户体验的FCP 小于1秒吗？”
为什么是90％？因为它包含了大量的用户体验。正如PSI docs所说:
为什么是1秒？这是用户期望页面开始显示有意义的进度的速度的主观值(value)。 1秒后，用户可能会分神，甚至感到沮丧。当然， chalice 应该具有即时的加载能力，但这被选为努力的现实基准。
因此，最糟糕的是，FCP经验的10％是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个原点。
有趣的是，浏览“快速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的快速资格。在列表中进一步挑选一些有趣的示例:
值得注意的是，这些起源不一定是排名最高的，而只是它们的领域。没有原始排名数据，这是我能做的最好的近似值。
较小的警告是，按我的分析，BigQuery和PSI在台式机/移动设备上的数据集和PSI分割略有不同，而我将它们组合在一起。因此，本研究并不能完美地表示对PSI的期望。
最后，我只想谈谈关于在Lighthouse中获得100分的问题。满分为100并不一定意味着没有任何改善的余地。诸如此类的综合测试需要进行校准，以代表实际的用户体验。因此，例如，如果在代表菲律宾用户体验的条件下进行测试，性能审核可能会开始失败。实际上，从该位置运行测试可能会带来性能问题，例如内容分发问题，以及我们可以在任何地方模拟的条件(例如连接速度)。
总结一切: