Google.com和其他访问量大的网站能否获得“快速"访问?使用Google的PSI API排名? [英] Can Google.com and other heavily trafficked websites get a "fast" rank using Google's PSI API?

问题描述

从PSI文档中:

为什么v4和v5中的FCP具有不同的值?

Why does the FCP in v4 and v5 have different values?

v5中的FCP报告了第75个百分点(截至2019年11月4日)， 以前是第90个百分位.在v4中，FCP报告了中位数 (百分之五十).

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).

Rick下方的最佳答案中的最佳数据/提示.

在说基于字段数据，'页面很慢'"时，是否使用90％的分数而不是以前的中位数或更低的百分比，使得google.com等流量大的网站无法曾经排名快速"吗?这是由于当月流量在1000万以上且分布在全球范围内时会出现长尾巴吗?

Does using the 90-percentile instead of previous median score, or a lower percentile, when saying, "based on field data the 'page is slow'" make it impossible for heavily trafficked websites, such as google.com, from ever getting ranked "Fast"? This due to the long tail that occurs when monthly traffic is in the 10M+ ranges and globally distributed?

我上次查看(2018年2月上旬)时，Desktop google.com的综合得分为100，应该被解释为几乎没有改进的余地"，但该页面的排名为慢"，因为第90个百分点的FCP超过了3秒.

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.

即使基于字段数据将google.com的桌面页面排名都较慢，使用此标准也不会将nytimes.com之类的页面视为快速?

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?

最近的示例(2019年2月14日)

Recent example (Feb. 14, 2019)

以前的示例中，FCP的尾巴甚至更长:

Former example with even longer tail for FCP:

推荐答案

要直接回答这个问题，不，要获得快速的FCP标签不是不可能的.这个问题还有更多，所以我会尽力阐述.

To directly answer the question, no it's not impossible to get a fast FCP label. There's more to the question so I'll try to elaborate.

表述快速"标准的另一种方法是:至少90％的用户体验具有小于1秒的FCP吗??"

Another way to phrase the "fast" criteria is: "Do at least 90% of user experiences have an FCP less than 1 second?"

为什么是90％?因为它包含了大量的用户体验.正如 PSI文档所说:

Why 90%? Because it's inclusive of a huge proportion of user experiences. As the PSI docs say:

我们的目标是确保页面对大多数用户都能正常运行.通过关注指标的第90和第95个百分位数，可以确保页面在最困难的设备和网络条件下达到最低性能标准.

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秒后，用户可能会分神，甚至感到沮丧.当然，圣杯应该具有即时加载能力，但这是我们努力追求的现实基准.

Why 1 second? It's a subjective value for how quickly users expect the page to start showing meaningful progress. After 1 second, users may become distracted or even frustrated. Of course the holy grail is to have instant loading, but this is chosen as a realistic benchmark to strive towards.

因此，最糟糕的是，FCP体验的10％是1秒或更慢.这种特定的保证是足够高的标准，足以使用户确信始终如一的快速体验.

So at worst 10% of the FCP experience is 1 second or slower. That specific kind of guarantee is a high enough bar to be confident that users ~consistently have a fast experience.

这说明了为什么将标尺设置在原位置.对于如何实现现实的问题，我们实际上可以使用公开提供的 CrUX来回答. BigQuery上的数据.

That explains why the bar is set where it is. To the question of how realistic it is to achieve, we can actually answer that using the publicly available 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个百分位数.如果这听起来令人困惑，这是一个可视化效果:

This is a query that counts where in the FCP histogram origins have their 90th percentile. If that sounds confusing, here's a visualization:

红色累积分配线超过1000毫秒标记的位置告诉我们被标记为快速的起源百分比.不是很多数据集中只有2％或110153个原点.

Where the red cumulative distribution line crosses the 1000ms mark tells us the percent of origins who would be labelled as fast. It isn't very many; just 2% or 110153 origins in the dataset.

有趣的是，浏览快速FCP"起源列表时，其中许多具有.jp和.kr TLD.可以合理地假设它们是本地化的日文和韩文网站，其用户几乎完全来自那些国家/地区.这些国家具有快速的互联网速度.因此，自然而然地，如果您的用户始终保持快速的连接速度，则90％以上的时间为快速的网站提供服务会很容易.

Anecdotally, browsing through the list of "fast FCP" origins, many of them have .jp and .kr TLDs. It's reasonable to assume they are localized Japanese and Korean websites whose users are almost entirely from those countries. And these are countries with fast internet speeds. So naturally it'd be easier to serve a fast website 90+% of the time when your users have consistently fast connection speeds.

我们可以做的另一件事是获得原产地知名度，那就是加入Alexa前100万个域名列表:

Another thing we can do to get a sense of origin popularity is join it with the Alexa Top 1 Million Domains list:

#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以内.您可以自己运行查询以查看完整结果.

There are 35985 origins whose domains are in the top 1M. You can run the query for yourself to see the full results.

您会发现，前20个域中有约100个源符合FCP的快速资格.在列表中进一步挑选一些有趣的示例:

You can see that there are ~100 origins on top 20 domains that qualify as fast for FCP. Cherrypicking some interesting examples further down the list:

• [#139] https://mobile.alibaba.com
• [#178] https://www.google.se
• [#422] http://www.design.samsung.com
• [#744] http://taxes.ca.gov

• [#139] https://mobile.alibaba.com
• [#178] https://www.google.se
• [#422] http://www.design.samsung.com
• [#744] http://taxes.ca.gov

需要注意的是，这些起源不一定是排名最高的，而只是它们的域名.没有原始排名数据，这是我能做的最好的近似值.

Big caveat that these origins are not necessarily top ranked, just their domains. Without having origin ranking data this is the best approximation I can do.

请注意，按我的分析，BigQuery和PSI在台式机/移动设备上的数据集和PSI细分略有不同.因此，这项研究并不是对PSI期望值的完美体现.

Lesser caveat that BigQuery and PSI are slightly different datasets and PSI segments by desktop/mobile while my analysis combines them together. So this research is not a perfect representation of what to expect on PSI.

最后，我只想解决有关在Lighthouse中获得100分的问题.满分为100并不一定意味着没有任何改善的余地.需要对类似的综合测试进行校准，以代表实际的用户体验.因此，例如，如果在代表菲律宾用户体验的条件下进行测试，性能审核可能会开始失败.除了可以在任何地方模拟的条件(例如连接速度)之外，实际上从该位置运行测试可能还会带来性能问题，例如内容分发问题.

Finally, I just want to address something else that was in the question about getting 100 scores in Lighthouse. A score of 100 doesn't necessarily mean that there isn't anything left to improve. Synthetic tests like that need to be calibrated to be representative of the actual user experience. So for example the performance audits might start failing if tested under conditions representative of user experiences in the Philippines. Actually running the test from that location might turn up performance problems, eg content distribution issues, in addition to the conditions that we could simulate anywhere like connection speed.

总结所有内容:

• 设置较高的门槛是因为我们要确保绝大多数用户体验都很快
• 尽管占整体数据集的一小部分，但许多网站已经超出了这个限制
• Alexa排名向我们表明，有可能是一个人流量大的网站，而且还可以提供一致的快速体验

这篇关于Google.com和其他访问量大的网站能否获得“快速"访问?使用Google的PSI API排名?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！