JAMstack網(wǎng)站以速度著稱，本文將通過實(shí)際性能指標(biāo)來揭示其原因。我們將涵蓋常見的指標(biāo)，例如時(shí)間到第一個(gè)字節(jié) (TTFB) 等，然后比較各種網(wǎng)站的數(shù)據(jù)，看看不同的切分方式如何影響性能。

首先，讓我們進(jìn)行一個(gè)小分析來提供一些背景信息。根據(jù)HTTPArchive關(guān)于頁面加載的指標(biāo)報(bào)告，用戶平均等待6.7秒才能看到主要內(nèi)容。

首次內(nèi)容繪制 (FCP) – 衡量文本或圖形首次渲染到屏幕上的時(shí)間點(diǎn)。

如果我們談?wù)摰氖琼撁鎱⑴c度（互動(dòng)時(shí)間），用戶等待的時(shí)間更長(zhǎng)。平均互動(dòng)時(shí)間為9.3秒。

互動(dòng)時(shí)間 (TTI) – 用戶可以無延遲地與頁面交互的時(shí)間。

真實(shí)用戶網(wǎng)絡(luò)性能現(xiàn)狀

以上數(shù)據(jù)來自實(shí)驗(yàn)室監(jiān)控，不能完全代表真實(shí)的用體驗(yàn)?；贑hrome用戶體驗(yàn)報(bào)告 (CrUX) 的真實(shí)用戶數(shù)據(jù)展現(xiàn)了更全面的情況。

我將使用從使用移動(dòng)設(shè)備的用戶那里匯總的數(shù)據(jù)。具體來說，我們將使用以下指標(biāo)：

• 時(shí)間到第一個(gè)字節(jié) (TTFB)
• 首次內(nèi)容繪制 (FCP)
• 首次輸入延遲 (FID)

時(shí)間到第一個(gè)字節(jié)

TTFB 表示瀏覽器等待從服務(wù)器接收響應(yīng)的第一個(gè)字節(jié)的時(shí)間。對(duì)于世界各地的用戶來說，TTFB 從 200 毫秒到 1 秒不等。這是一個(gè)相當(dāng)長(zhǎng)的時(shí)間來接收頁面的第一批數(shù)據(jù)塊。

首次內(nèi)容繪制

在全球 23% 的頁面瀏覽中，F(xiàn)CP 在 2.5 秒后發(fā)生。

首次輸入延遲

FID 指標(biāo)顯示網(wǎng)頁對(duì)用戶輸入（例如點(diǎn)擊、滾動(dòng)等）的響應(yīng)速度。

由于不同的限制，CrUX 沒有 TTI 數(shù)據(jù)，但有 FID，它甚至可以更好地反映頁面交互性。超過 75% 的移動(dòng)用戶體驗(yàn)的輸入延遲為 50 毫秒，用戶沒有遇到任何卡頓。

您可以使用下面的查詢，并在該網(wǎng)站上使用它們。

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

### 內(nèi)容管理系統(tǒng) (CMS) 性能現(xiàn)狀

CMS 應(yīng)該成為我們的救星，幫助我們構(gòu)建更快的網(wǎng)站。但從數(shù)據(jù)來看，情況并非如此。全球 CMS 的當(dāng)前性能狀況并不理想。

<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 結(jié)果：

至少 FID 結(jié)果好一些：

<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 構(gòu)建的網(wǎng)站的性能與網(wǎng)絡(luò)上網(wǎng)站的整體性能并沒有好多少。

您可以在此HTTPArchive論壇討論中找到不同 CMS 的性能分布。

電子商務(wù)網(wǎng)站是通?；?CMS 構(gòu)建的網(wǎng)站的一個(gè)很好的例子，其頁面瀏覽量統(tǒng)計(jì)數(shù)據(jù)非常糟糕：

• ~40% – TTFB 為 1 秒
• ~30% – FCP 超過 1.5 秒
• ~12% – 頁面交互延遲。

我遇到過一些客戶，他們要求支持 IE10-IE11，因?yàn)閬碜赃@些用戶的流量占 1%，相當(dāng)于數(shù)百萬美元的收入。請(qǐng)計(jì)算一下，如果 1% 的用戶因?yàn)樾阅懿疃⒓措x開并且永不返回，您的損失是多少。如果用戶不滿意，業(yè)務(wù)也會(huì)不滿意。

要詳細(xì)了解網(wǎng)絡(luò)性能如何與收入相關(guān)聯(lián)，請(qǐng)查看 WPO Stats。這是一個(gè)來自真實(shí)公司及其在改進(jìn)性能后的成功案例的研究案例列表。

JAMstack 有助于提高網(wǎng)絡(luò)性能

使用 JAMstack，開發(fā)人員盡可能減少客戶端的渲染工作，而是使用服務(wù)器基礎(chǔ)設(shè)施來處理大部分事情。更不用說，大多數(shù) JAMstack 工作流程非常擅長(zhǎng)處理部署，并有助于擴(kuò)展性以及其他好處。內(nèi)容靜態(tài)存儲(chǔ)在靜態(tài)文件主機(jī)上，并通過 CDN 提供給用戶。

閱讀 Mathieu Dionne 的“JAMstack 新手？入門所需的一切”可以更好地了解 JAMstack。

我有兩年使用流行的電子商務(wù) CMS 的經(jīng)驗(yàn)，我們?cè)诓渴?、性能、可擴(kuò)展性方面遇到了很多問題。團(tuán)隊(duì)會(huì)花費(fèi)數(shù)天時(shí)間來修復(fù)這些問題。這不是客戶想要的。這些都是 JAMstack 解決的大問題。

查看 CrUX 數(shù)據(jù)，JAMstack 網(wǎng)站的性能看起來非常出色。以下值基于 Netlify 和 GitHub 提供服務(wù)的網(wǎng)站。在 HTTPArchive 論壇上有一些討論，您可以參與其中，使數(shù)據(jù)更準(zhǔn)確。

以下是 TTFB 的結(jié)果：

<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 的結(jié)果：

現(xiàn)在讓我們看看 FID：

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

數(shù)據(jù)顯示 JAMstack 網(wǎng)站的性能最佳。移動(dòng)端和桌面端的數(shù)值幾乎相同，這更令人驚嘆！

工程領(lǐng)導(dǎo)者的幾點(diǎn)看法

讓我向您展示業(yè)內(nèi)一些知名人士的幾個(gè)例子：

在 @HTTPArchive 的 4.68 億次請(qǐng)求中，有 48% 未從 CDN 提供服務(wù)。我在下面可視化了它們的服務(wù)來源。其中許多是針對(duì)第三方服務(wù)的請(qǐng)求。發(fā)出請(qǐng)求的客戶端位于加利福尼亞州雷德伍德城。延遲很重要。#WebPerf pic.twitter.com/0F7nFa1QgM

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

JAMstack 網(wǎng)站通常由 CDN 托管，并減輕了 TTFB 的負(fù)擔(dān)。由于文件托管由 Amazon Web Services 或類似的基礎(chǔ)設(shè)施處理，因此可以通過一次修復(fù)來改進(jìn)所有網(wǎng)站的性能。

另一項(xiàng)真實(shí)調(diào)查表明，為了獲得更好的 FCP，最好提供靜態(tài) HTML。

哪一個(gè)具有更好的首次有意義繪制時(shí)間？

① 一個(gè)包含我所有 27,506 條推文全文的原始 8.5MB HTML 文件 ② 一個(gè)客戶端渲染的 React 網(wǎng)站，其中只有一個(gè)推文

（劇透：@____lighthouse 報(bào)告稱，8.5MB 的 HTML 贏得了大約 200 毫秒）

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

以下是上面顯示的所有結(jié)果的比較：

JAMstack 通過使用 CDN 靜態(tài)提供頁面來提高網(wǎng)絡(luò)性能。這很重要，因?yàn)榭焖俚暮蠖诵枰荛L(zhǎng)時(shí)間才能到達(dá)用戶，速度會(huì)很慢，同樣，緩慢的后端快速到達(dá)用戶，速度也會(huì)很慢。

JAMstack 尚未贏得性能競(jìng)賽，因?yàn)槭褂盟木W(wǎng)站數(shù)量不如 CMS 那樣龐大，但贏得比賽的意圖非常好。

將這些指標(biāo)添加到性能預(yù)算中，可以確保您在工作流程中構(gòu)建良好的性能。例如：

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

明智地使用它吧 ?

編輯注： Artem Denysov 來自 Stackbit，這是一項(xiàng)服務(wù)，它極大地幫助了 JAMstack 網(wǎng)站的啟動(dòng)，以及更多即將推出的工具，以簡(jiǎn)化 JAMstack 網(wǎng)站和內(nèi)容的工作流程邊緣。Artem 告訴我，他感謝 Rick Viscomi、Rob Austin 和 Aleksey Kulikov 幫助他審核這篇文章。

以上是看看Jamstack的速度，按數(shù)字的詳細(xì)內(nèi)容。更多資訊請(qǐng)關(guān)注PHP中文網(wǎng)其他相關(guān)文章！