看看Jamstack的速度，按数字-css教程-PHP中文网

首页

web前端

css教程

看看Jamstack的速度，按数字

Joseph Gordon-Levitt

Apr 15, 2025 am 10:39 AM

A Look at JAMstack's Speed, By the Numbers

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>
</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>

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

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

2019年7月的数据

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

<code>
</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>

以下是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>
</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>

如您所见，使用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>
</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>

以下是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>
</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>

数据显示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中文网其他相关文章！

声明

本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系admin@php.cn