看看Jamstack的速度，按數字

JAMstack网站以速度著称，本文将通过实际性能指标来揭示其原因。我们将涵盖常见的指标，例如时间到第一个字节 (TTFB) 等，然后比较各种网站的数据，看看不同的切分方式如何影响性能。

首先，让我们进行一个小分析来提供一些背景信息。根据HTTPArchive关于页面加载的指标报告，用户平均等待6.7秒才能看到主要内容。

首次内容绘制 (FCP) – 衡量文本或图形首次渲染到屏幕上的时间点。

如果我们谈论的是页面参与度（互动时间），用户等待的时间更长。平均互动时间为9.3秒。

互动时间 (TTI) – 用户可以无延迟地与页面交互的时间。

真实用户网络性能现状

以上数据来自实验室监控，不能完全代表真实的用体验。基于Chrome用户体验报告 (CrUX) 的真实用户数据展现了更全面的情况。

我将使用从使用移动设备的用户那里汇总的数据。具体来说，我们将使用以下指标：

• 时间到第一个字节 (TTFB)
• 首次内容绘制 (FCP)
• 首次输入延迟 (FID)

时间到第一个字节

TTFB 表示浏览器等待从服务器接收响应的第一个字节的时间。对于世界各地的用户来说，TTFB 从 200 毫秒到 1 秒不等。这是一个相当长的时间来接收页面的第一批数据块。

首次内容绘制

在全球 23% 的页面浏览中，FCP 在 2.5 秒后发生。

首次输入延迟

FID 指标显示网页对用户输入（例如点击、滚动等）的响应速度。

由于不同的限制，CrUX 没有 TTI 数据，但有 FID，它甚至可以更好地反映页面交互性。超过 75% 的移动用户体验的输入延迟为 50 毫秒，用户没有遇到任何卡顿。

您可以使用下面的查询，并在该网站上使用它们。

2019年7月的数据

``` [ { "date": "2019_07_01", "timestamp": "1561939200000", "client": "desktop", "fastTTFB": "27.33", "avgTTFB": "46.24", "slowTTFB": "26.43", "fastFCP": "48.99", "avgFCP": "33.17", "slowFCP": "17.84", "fastFID": "95.78", "avgFID": "2.79", "slowFID": "1.43" }, { "date": "2019_07_01", "timestamp": "1561939200000", "client": "mobile", "fastTTFB": "23.61", "avgTTFB": "46.49", "slowTTFB": "29.89", "fastFCP": "38.58", "avgFCP": "38.28", "slowFCP": "23.14", "fastFID": "75.13", "avgFID": "17.95", "slowFID": "6.92" } ]

<code>
<details><summary>BigQuery</summary>```
#standardSQL
  SELECT
    REGEXP_REPLACE(yyyymm, '(\\d{4})(\\d{2})', '\\1_\\2_01') AS date,
    UNIX_DATE(CAST(REGEXP_REPLACE(yyyymm, '(\\d{4})(\\d{2})', '\\1-\\2-01') AS DATE)) * 1000 * 60 * 60 * 24 AS timestamp,
    IF(device = 'desktop', 'desktop', 'mobile') AS client,
    ROUND(SUM(fast_fcp) * 100 / (SUM(fast_fcp)   SUM(avg_fcp)   SUM(slow_fcp)), 2) AS fastFCP,
    ROUND(SUM(avg_fcp) * 100 / (SUM(fast_fcp)   SUM(avg_fcp)   SUM(slow_fcp)), 2) AS avgFCP,
    ROUND(SUM(slow_fcp) * 100 / (SUM(fast_fcp)   SUM(avg_fcp)   SUM(slow_fcp)), 2) AS slowFCP,
    ROUND(SUM(fast_fid) * 100 / (SUM(fast_fid)   SUM(avg_fid)   SUM(slow_fid)), 2) AS fastFID,
    ROUND(SUM(avg_fid) * 100 / (SUM(fast_fid)   SUM(avg_fid)   SUM(slow_fid)), 2) AS avgFID,
    ROUND(SUM(slow_fid) * 100 / (SUM(fast_fid)   SUM(avg_fid)   SUM(slow_fid)), 2) AS slowFID
  FROM
    `chrome-ux-report.materialized.device_summary`
  WHERE
    yyyymm = '201907'
  GROUP BY
    date,
    timestamp,
    client
  ORDER BY
    date DESC,
    client</details></code>

### 内容管理系统 (CMS) 性能现状

CMS 应该成为我们的救星，帮助我们构建更快的网站。但从数据来看，情况并非如此。全球 CMS 的当前性能状况并不理想。

2019年7月的数据

``` [ { "freq": "1548851", "fast": "0.1951", "avg": "0.4062", "slow": "0.3987" } ]

<code>
<details><summary>BigQuery</summary>```
#standardSQL
  SELECT
    COUNT(DISTINCT origin) AS freq,

    ROUND(SUM(IF(ttfb.start = 200 AND ttfb.start = 1000, ttfb.density, 0)) / SUM(ttfb.density), 4) AS slowTTFB

  FROM
    `chrome-ux-report.all.201907`,
    UNNEST(experimental.time_to_first_byte.histogram.bin) AS ttfb
  JOIN (
    SELECT
      url,
      app
    FROM
      `httparchive.technologies.2019_07_01_mobile`
    WHERE
      category = 'CMS'
    )
  ON CONCAT(origin, '/') = url
  ORDER BY
    freq DESC</details></code>

以下是 FCP 结果：

至少 FID 结果好一些：

2019年7月的数据

``` [ { "freq": "546415", "fastFCP": "0.2873", "avgFCP": "0.4187", "slowFCP": "0.2941", "fastFID": "0.8275", "avgFID": "0.1183", "slowFID": "0.0543" } ]

<code>
<details><summary>BigQuery</summary>```
#standardSQL
  SELECT
    COUNT(DISTINCT origin) AS freq,
    ROUND(SUM(IF(fcp.start = 1000 AND fcp.start = 2500, fcp.density, 0)) / SUM(fcp.density), 4) AS slowFCP,
    ROUND(SUM(IF(fid.start = 50 AND fid.start = 250, fid.density, 0)) / SUM(fid.density), 4) AS slowFID
  FROM
    `chrome-ux-report.all.201907`,
    UNNEST(first_contentful_paint.histogram.bin) AS fcp,
    UNNEST(experimental.first_input_delay.histogram.bin) AS fid
  JOIN (
    SELECT
      url,
      app
    FROM
      `httparchive.technologies.2019_07_01_mobile`
    WHERE
      category = 'CMS'
    )
  ON CONCAT(origin, '/') = url
  ORDER BY
    freq DESC</details></code>

如您所见，使用 CMS 构建的网站的性能与网络上网站的整体性能并没有好多少。

您可以在此HTTPArchive论坛讨论中找到不同 CMS 的性能分布。

电子商务网站是通常基于 CMS 构建的网站的一个很好的例子，其页面浏览量统计数据非常糟糕：

• ~40% – TTFB 为 1 秒
• ~30% – FCP 超过 1.5 秒
• ~12% – 页面交互延迟。

我遇到过一些客户，他们要求支持 IE10-IE11，因为来自这些用户的流量占 1%，相当于数百万美元的收入。请计算一下，如果 1% 的用户因为性能差而立即离开并且永不返回，您的损失是多少。如果用户不满意，业务也会不满意。

要详细了解网络性能如何与收入相关联，请查看 WPO Stats。这是一个来自真实公司及其在改进性能后的成功案例的研究案例列表。

JAMstack 有助于提高网络性能

使用 JAMstack，开发人员尽可能减少客户端的渲染工作，而是使用服务器基础设施来处理大部分事情。更不用说，大多数 JAMstack 工作流程非常擅长处理部署，并有助于扩展性以及其他好处。内容静态存储在静态文件主机上，并通过 CDN 提供给用户。

阅读 Mathieu Dionne 的“JAMstack 新手？入门所需的一切”可以更好地了解 JAMstack。

我有两年使用流行的电子商务 CMS 的经验，我们在部署、性能、可扩展性方面遇到了很多问题。团队会花费数天时间来修复这些问题。这不是客户想要的。这些都是 JAMstack 解决的大问题。

查看 CrUX 数据，JAMstack 网站的性能看起来非常出色。以下值基于 Netlify 和 GitHub 提供服务的网站。在 HTTPArchive 论坛上有一些讨论，您可以参与其中，使数据更准确。

以下是 TTFB 的结果：

2019年7月的数据

``` [ { "n": "7627", "fastTTFB": "0.377", "avgTTFB": "0.5032", "slowTTFB": "0.1198" } ]

<code>
<details><summary>BigQuery</summary>```
#standardSQL
SELECT
  COUNT(DISTINCT origin) AS n,
  ROUND(SUM(IF(ttfb.start = 200 AND ttfb.start = 1000, ttfb.density, 0)) / SUM(ttfb.density), 4) AS slowTTFB
FROM
  `chrome-ux-report.all.201907`,
  UNNEST(experimental.time_to_first_byte.histogram.bin) AS ttfb
JOIN
  (SELECT url, REGEXP_EXTRACT(LOWER(CONCAT(respOtherHeaders, resp_x_powered_by, resp_via, resp_server)),
      '(netlify|x-github-request)')
    AS platform
  FROM `httparchive.summary_requests.2019_07_01_mobile`)
ON
  CONCAT(origin, '/') = url
WHERE
  platform IS NOT NULL
ORDER BY
  n DESC</details></code>

以下是 FCP 的结果：

现在让我们看看 FID：

2019年7月的数据

``` [ { "n": "4136", "fastFCP": "0.5552", "avgFCP": "0.3126", "slowFCP": "0.1323", "fastFID": "0.9263", "avgFID": "0.0497", "slowFID": "0.024" } ]

<code>
<details><summary>BigQuery</summary>```
#standardSQL
  SELECT
    COUNT(DISTINCT origin) AS n,
    ROUND(SUM(IF(fcp.start = 1000 AND fcp.start = 2500, fcp.density, 0)) / SUM(fcp.density), 4) AS slowFCP,
    ROUND(SUM(IF(fid.start = 50 AND fid.start = 250, fid.density, 0)) / SUM(fid.density), 4) AS slowFID
  FROM
    `chrome-ux-report.all.201907`,
    UNNEST(first_contentful_paint.histogram.bin) AS fcp,
    UNNEST(experimental.first_input_delay.histogram.bin) AS fid
  JOIN
    (SELECT url, REGEXP_EXTRACT(LOWER(CONCAT(respOtherHeaders, resp_x_powered_by, resp_via, resp_server)),
        '(netlify|x-github-request)')
      AS platform
    FROM `httparchive.summary_requests.2019_07_01_mobile`)
  ON
    CONCAT(origin, '/') = url
  WHERE
    platform IS NOT NULL
  ORDER BY
    n DESC</details></code>

数据显示 JAMstack 网站的性能最佳。移动端和桌面端的数值几乎相同，这更令人惊叹！

工程领导者的几点看法

让我向您展示业内一些知名人士的几个例子：

在 @HTTPArchive 的 4.68 亿次请求中，有 48% 未从 CDN 提供服务。我在下面可视化了它们的服务来源。其中许多是针对第三方服务的请求。发出请求的客户端位于加利福尼亚州雷德伍德城。延迟很重要。#WebPerf pic.twitter.com/0F7nFa1QgM

— Paul Calvano (@paulcalvano) 2019 年 8 月 29 日

JAMstack 网站通常由 CDN 托管，并减轻了 TTFB 的负担。由于文件托管由 Amazon Web Services 或类似的基础设施处理，因此可以通过一次修复来改进所有网站的性能。

另一项真实调查表明，为了获得更好的 FCP，最好提供静态 HTML。

哪一个具有更好的首次有意义绘制时间？

① 一个包含我所有 27,506 条推文全文的原始 8.5MB HTML 文件 ② 一个客户端渲染的 React 网站，其中只有一个推文

（剧透：@____lighthouse 报告称，8.5MB 的 HTML 赢得了大约 200 毫秒）

— Zach Leatherman (@zachleat) 2019 年 9 月 6 日

以下是上面显示的所有结果的比较：

JAMstack 通过使用 CDN 静态提供页面来提高网络性能。这很重要，因为快速的后端需要很长时间才能到达用户，速度会很慢，同样，缓慢的后端快速到达用户，速度也会很慢。

JAMstack 尚未赢得性能竞赛，因为使用它的网站数量不如 CMS 那样庞大，但赢得比赛的意图非常好。

将这些指标添加到性能预算中，可以确保您在工作流程中构建良好的性能。例如：

• TTFB：200 毫秒
• FCP：1 秒
• FID：50 毫秒

明智地使用它吧 ?

编辑注： Artem Denysov 来自 Stackbit，这是一项服务，它极大地帮助了 JAMstack 网站的启动，以及更多即将推出的工具，以简化 JAMstack 网站和内容的工作流程边缘。Artem 告诉我，他感谢 Rick Viscomi、Rob Austin 和 Aleksey Kulikov 帮助他审核这篇文章。

以上是看看Jamstack的速度，按數字的詳細內容。更多資訊請關注PHP中文網其他相關文章！