从数据看 JAMstack 的速度 | CSS-Tricks

人们说 JAMstack 网站速度很快——让我们通过查看真实的性能指标来了解原因！我们将涵盖常见的指标，例如第一个字节时间（TTFB）等，然后比较各种网站的数据，看看将这些网站划分为不同部分时的比较情况。

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

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

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

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

真实用户网络性能现状

以上数据来自实验室监控，并不能完全代表真实的用户体验。来自 Chrome 用户体验报告 (CrUX) 的真实用户数据提供了更全面的视角。

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

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

第一个字节时间

TTFB 表示浏览器等待从服务器接收响应的第一个字节的时间。TTFB 在全球用户中需要 200 毫秒到 1 秒的时间。接收页面的第一部分需要这么长时间，这确实很长。

首次内容绘制

FCP 在全球 23% 的页面浏览量中发生在 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"
    }
  ]

BigQuery

#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

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

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

TTFB 所有网站和 CMS 之间的移动速度分布比较（CrUX，2019年7月）

2019年7月的数据

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

BigQuery

#standardSQL
  SELECT
    COUNT(DISTINCT origin) AS freq,
      
    ROUND(SUM(IF(ttfb.start < 200, ttfb.density, 0)) / SUM(ttfb.density), 4) AS fastTTFB,
    ROUND(SUM(IF(ttfb.start >= 200 AND ttfb.start < 1000, ttfb.density, 0)) / SUM(ttfb.density), 4) AS avgTTFB,
    ROUND(SUM(IF(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

以下是 FCP 结果

至少 FID 结果好一点

2019年7月的数据

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

BigQuery

#standardSQL
  SELECT
    COUNT(DISTINCT origin) AS freq,
    ROUND(SUM(IF(fcp.start < 1000, fcp.density, 0)) / SUM(fcp.density), 4) AS fastFCP,
    ROUND(SUM(IF(fcp.start >= 1000 AND fcp.start < 2500, fcp.density, 0)) / SUM(fcp.density), 4) AS avgFCP,
    ROUND(SUM(IF(fcp.start >= 2500, fcp.density, 0)) / SUM(fcp.density), 4) AS slowFCP,
    ROUND(SUM(IF(fid.start < 50, fid.density, 0)) / SUM(fid.density), 4) AS fastFID,
    ROUND(SUM(IF(fid.start >= 50 AND fid.start < 250, fid.density, 0)) / SUM(fid.density), 4) AS avgFID,
    ROUND(SUM(IF(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

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

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

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

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

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

要详细了解网络性能如何与收入相关联，请查看 WPO 统计数据。它列出了来自真实公司的案例研究，以及他们在改进性能后取得的成功。

JAMstack 有助于提高网络性能

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

阅读 Mathieu Dionne 的 “JAMstack 入门指南：你需要了解的一切”，以便更好地了解 JAMstack。

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

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

以下是 TTFB 的结果

TTFB 所有网站、CMS 和 JAMstack 网站之间的移动速度分布比较（CrUX，2019年7月）

2019年7月的数据

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

BigQuery

#standardSQL
SELECT
  COUNT(DISTINCT origin) AS n,
  ROUND(SUM(IF(ttfb.start < 200, ttfb.density, 0)) / SUM(ttfb.density), 4) AS fastTTFB,
  ROUND(SUM(IF(ttfb.start >= 200 AND ttfb.start < 1000, ttfb.density, 0)) / SUM(ttfb.density), 4) AS avgTTFB,
  ROUND(SUM(IF(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

以下是 FCP 的结果

FCP 所有网站、CMS 和 JAMstack 网站之间的移动速度分布比较（CrUX，2019年7月）

现在让我们看看 FID

FID 所有网站、CMS 和 JAMstack 网站之间的移动速度分布比较（CrUX，2019年7月）

2019年7月的数据

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

BigQuery

#standardSQL
  SELECT
    COUNT(DISTINCT origin) AS n,
    ROUND(SUM(IF(fcp.start < 1000, fcp.density, 0)) / SUM(fcp.density), 4) AS fastFCP,
    ROUND(SUM(IF(fcp.start >= 1000 AND fcp.start < 2500, fcp.density, 0)) / SUM(fcp.density), 4) AS avgFCP,
    ROUND(SUM(IF(fcp.start >= 2500, fcp.density, 0)) / SUM(fcp.density), 4) AS slowFCP,
    ROUND(SUM(IF(fid.start < 50, fid.density, 0)) / SUM(fid.density), 4) AS fastFID,
    ROUND(SUM(IF(fid.start >= 50 AND fid.start < 250, fid.density, 0)) / SUM(fid.density), 4) AS avgFID,
    ROUND(SUM(IF(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

数据显示 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 日

以下是上面所有结果的对比

所有 Web、CMS 和 JAMstack 网站的移动速度分布对比（CrUX，2019 年 7 月）

JAMstack 通过使用 CDN 静态提供页面，从而为 Web 带来了更好的性能。这一点很重要，因为一个快速的后端如果需要很长时间才能到达用户，速度就会变慢，同样，一个缓慢的后端如果很快就能到达用户，速度也会变慢。

JAMstack 还没有赢得性能竞赛，因为它构建的网站数量不如例如 CMS 那样庞大，但其赢得比赛的意图非常强烈。

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

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

明智地使用它们 🙂

编辑注：Artem Denysov 来自 Stackbit，这是一项服务，可以极大地帮助您启动 JAMstack 网站，以及更多即将推出的工具，以简化 JAMstack 网站和内容的一些工作流程边缘。Artem 告诉我，他希望感谢 Rick Viscomi、Rob Austin 和 Aleksey Kulikov 在审查本文方面提供的帮助。

Henri

# 2019 年 11 月 1 日

您必须喜欢 HA + CrUX。可以从这些平台中提取出色的见解。最终，CDN 状态可能是最重要的一个——表明它仍然是 Mike Belshe 曾经写到的：延迟几乎是一切。
CMS 整体上使用起来很有挑战性，因为最流行的一些 CMS 通常是最慢的。bit.ly/ttfb-crux-wp
有趣的文章！谢谢！

Artem Denysov

评论永久链接# 2019 年 11 月 2 日

谢谢，Henri :)
Joe Pea

评论永久链接# 2019 年 11 月 3 日

为什么每个人都在玩弄这个 JAMstack 的营销词？它只是“静态网站”的一个代名词，用来获得关注，而且这个概念本身与 Web 性能或速度无关。

Phil Hawksworth

# 2019 年 11 月 4 日

Joe，这是一个可以理解的观点。而且您说得对，“静态网站”已经存在很长时间了。现在不同的是，围绕“静态网站”的工具和服务提供了比以前更多的可能性。并且由于“静态”一词含义过于丰富，因此使用新的词汇来帮助我们超越其局限性的传统观点是有用的。

在性能方面，JAMstack 网站可以做到非常出色。即使在流量负载很大的情况下，也能保持良好的性能状态，而传统架构则需要更多的工程和基础设施。但当然，它们并不能仅仅因为是 JAMstack 就能保证速度。它们消除了一些提供快速网站的常见障碍，但我们作为开发人员仍然掌握着保持网站快速或使其变慢的关键。

David Elstob

# 2020 年 2 月 7 日

虽然 JAMstack 网站确实很快，但如果您使用像 Cloudflare 这样的 CDN 并正确配置，也可以使 WordPress 变得同样快速。

我将我的 WordPress 测试网站转换为静态 HTML 并使用 Cloudflare Workers 托管，然后将其与原始网站进行比较。速度上几乎看不出区别，它们非常接近。

WordPress 由于其庞大的插件商店而更容易配置，但讽刺的是，当您想要更改一些简单的东西时，它反而最麻烦。静态网站则相反。

所有网站都有优缺点，这取决于您想要什么。

此外，专业开发人员对 CMS 嗤之以鼻，因为像我这样的平民百姓使用它们。 :)

真实用户网络性能现状

第一个字节时间

首次内容绘制

首次输入延迟

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

JAMstack 有助于提高网络性能

来自工程领导者的亮点

评论