数字によるJamstack＆＃039;の速度を見てください

JamstackのWebサイトはその速度で知られています。この記事では、実際のパフォーマンスメトリックを通じて理由を明らかにします。 Time to First Byte（TTFB）などの一般的なメトリックをカバーし、さまざまなWebサイトのデータを比較して、異なる同期メソッドがパフォーマンスにどのように影響するかを確認します。

まず、背景情報を提供するために小さな分析を行いましょう。ページの読み込みに関するHTTParchiveのメトリックレポートによると、ユーザーはメインコンテンツを見るために平均6.7秒待っています。

First Content Draw（FCP） - テキストまたはグラフが最初に画面にレンダリングされる時点を測定します。

ページエンゲージメント（相互作用時間）について話している場合、ユーザーは長く待ちます。平均相互作用時間は9.3秒です。

インタラクション時間（TTI） - ユーザーが遅滞なくページと対話できる時間。

実際のユーザーネットワークパフォーマンスステータス

上記のデータは、実験室の監視からのものであり、実際のユーザーエクスペリエンスを完全に表すことはできません。 Chromeユーザーエクスペリエンスレポート（CRUX）に基づく実際のユーザーデータは、より包括的な画像を示しています。

モバイルデバイスを使用するユーザーから集約されたデータを使用します。具体的には、次のメトリックを使用します。

• 最初のバイト（TTFB）までの時間
• 最初のコンテンツ描画（FCP）
• 最初の入力遅延（FID）

最初のバイトまでの時間

TTFBは、ブラウザが最初のバイトがサーバーから応答を受信するのを待つ時間を表します。世界中のユーザーの場合、TTFBは200ミリ秒から1秒の範囲です。これは、ページのデータブロックの最初のバッチを受け取るのにかなり長い時間です。

最初のコンテンツ図

世界のページビューの23％で、FCPは2.5秒後に発生します。

最初の入力遅延

FIDメトリックは、Webページがユーザー入力（クリック、スクロールなど）にどれだけ速く応答するかを示しています。

さまざまな制限のため、CruxにはTTIデータがありませんが、FIDがあり、ページの対話性をさらによく反映しています。モバイルユーザーエクスペリエンスの75％以上の入力遅延は50ミリ秒で、ユーザーは遅れを経験していません。

以下のクエリを使用して、そのサイトでそれらを使用できます。

2019年7月のデータ

`` `` [{"date"： "2019_07_01"、 "Timestamp"： "1561939200000000"、 "client"： "desktop"、 "fastttfb"： "27.33"、 "avgttfb"： "46.24"、 "slowtfb" "avgfcp"： "33.17"、 "slowfcp"： "17.84"、 "fastfid"： "95.78"、 "avgfid"： "2.79"、 "slowfid"： "1.43"}、{"date"： "2019_07_01"、Timestamp "Fastttfb"： "23.61"、 "avgttfb"： "46.49"、 "slowttfb"： "29.89"、 "fastfcp"： "38.58"、 "avgfcp"： "38.28"、 "slowfcp"： "23.14"： "75.13" "" "17.95"、 "slowfid"： "6.92"}]

<code>
</code><details><summary>ビッグクエリー</summary>`` `
#standardsql
  選択します
    regexp_replace（yyyymm、 '（\\ d {4}）（\\ d {2}）'、 '\\ 1 _ \\ 2_01'）、
    unix_date（cast（regexp_replace（yyyymm、 '）（\\ d {4}）（\\ d {2}）'、 '\\ 1- \\ 2-01'））） * 1000 * 60 * 60 * 24
    if（device = 'desktop'、 'desktop'、 'mobile'）として、
    round（sum（fast_fcp） * 100 /（sum（fast_fcp）sum（avg_fcp）sum（slow_fcp））、2）fastfcp、
    round（sum（avg_fcp） * 100 /（sum（fast_fcp）sum（avg_fcp）sum（slow_fcp））、2）avgfcp、
    round（sum（slow_fcp） * 100 /（sum（fast_fcp）sum（avg_fcp）sum（slow_fcp））、2）slowfcp、
    round（sum（fast_fid） * 100 /（sum（fast_fid）sum（avg_fid）sum（slow_fid））、2）fastfid、
    round（sum（avg_fid） * 100 /（sum（fast_fid）sum（avg_fid）sum（slow_fid））、2）avgfid、
    round（sum（slow_fid） * 100 /（sum（fast_fid）sum（avg_fid）sum（slow_fid））、2）slowfid
  から
    `Chrome-ux-report.materialized.device_summary`
  どこ
    yyyymm = '201907'
  グループ
    日付、
    タイムスタンプ、
    クライアント
  注文
    日付DESC、
    クライアント</details>

###コンテンツ管理システム（CMS）パフォーマンスステータス

CMSは私たちの救世主であり、より高速なWebサイトの構築を支援する必要があります。しかし、データから判断すると、そうではありません。 CMSグローバルの現在のパフォーマンスは理想的ではありません。

2019年7月のデータ

`` `` [{"freq"： "1548851"、 "fast"： "0.1951"、 "avg"： "0.4062"、 "slow"： "0.3987"}]]

<code>
</code><details><summary>ビッグクエリー</summary>`` `
#standardsql
  選択します
    freqとしてカウント（明確な起源）、

    round（sum（if（ttfb.start = 200およびttfb.start = 1000、ttfb.dences、0）） / sum（ttfb.dences）、4）slowttfbとして

  から
    `chrome-ux-report.all.201907`、
    unnest（experimental.time_to_first_byte.histogram.bin）as ttfb
  参加する （
    選択します
      URL、
      アプリ
    から
      `httparchive.technologies.2019_07_01_mobile`
    どこ
      category = 'cms'
    ））
  concat（origin、 '/'）= url
  注文
    freq desc</details>

FCPの結果は次のとおりです。

少なくともFIDの結果はより良いです：

2019年7月のデータ

`` `` [{"freq"： "546415"、 "fastfcp"： "0.2873"、 "avgfcp"： "0.4187"、 "slowfcp"： "0.2941"、 "fastfid"： "0.8275"、 "avgfid"

<code>
</code><details><summary>ビッグクエリー</summary>`` `
#standardsql
  選択します
    freqとしてカウント（明確な起源）、
    round（sum（if（fcp.start = 1000およびfcp.start = 2500、fcp.density、0） / sum（fcp.dences）、slowfcpとして、
    round（sum（if（fid.start = 50およびfid.start = 250、fid.density、0）） / sum（fid.dencess）、4）slowfidとして
  から
    `chrome-ux-report.all.201907`、
    fcpとしてunnest（first_contentful_paint.histogram.bin）、
    fidとしてunnest（experimental.first_input_delay.histogram.bin）
  参加する （
    選択します
      URL、
      アプリ
    から
      `httparchive.technologies.2019_07_01_mobile`
    どこ
      category = 'cms'
    ））
  concat（origin、 '/'）= url
  注文
    freq desc</details>

ご覧のとおり、CMSで構築されたWebサイトのパフォーマンスは、ウェブ上のWebサイトの全体的なパフォーマンスよりもはるかに優れていません。

このhttparchiveフォーラムのディスカッションでは、さまざまなCMSのパフォーマンス分布を見つけることができます。

eコマースのWebサイトは、通常CMS上に構築されているWebサイトの優れた例であり、非常に悪いページビューの統計があります。

• 〜40％ - TTFBは1秒です
• 〜30％ - 1.5秒以上のFCP
• 〜12％ - ページインタラクション遅延。

これらのユーザーからのトラフィックは1％を占めているため、IE10-IE11のサポートを求めるクライアントに会いました。これは数百万ドルの収益に相当します。ユーザーの1％がすぐに出発し、パフォーマンスが低いために戻ってこない場合、損失の量を計算してください。ユーザーが満足していない場合、ビジネスも不満になります。

ネットワークのパフォーマンスが収益にどのように関連しているかについての詳細については、WPO統計をご覧ください。これは、パフォーマンスを改善した後の実際の企業からの研究ケースとその成功事例のリストです。

Jamstackは、ネットワークのパフォーマンスの向上に役立ちます

Jamstackを使用すると、開発者はクライアントのレンダリング作業を最小限に抑え、代わりにサーバーインフラストラクチャを使用してほとんどのことを処理します。言うまでもなく、ほとんどのJamstackワークフローは展開の取り扱いに非常に優れており、スケーラビリティやその他の利点に貢献しています。コンテンツは静的ファイルホストに静的に保存され、CDNを介してユーザーに提供されます。

Jamstackのより良いアイデアを得るために、Mathieu Dionneの「Jamstack Newbie？始めるために必要なすべて」を読んでください。

私は人気のあるeコマースCMSを使用して2年の経験があり、展開、パフォーマンス、スケーラビリティに多くの問題がありました。チームはこれらの問題を修正するために何日も費やします。これは顧客が望んでいるものではありません。これらは、Jamstackが解決する大きな問題です。

Cruxデータを見ると、Jamstack Webサイトのパフォーマンスは素晴らしく見えます。次の値は、NetlifyとGitHubが提供するWebサイトに基づいています。 httparchiveフォーラムでは、データをより正確にするために関与することができるいくつかの議論があります。

TTFBの結果は次のとおりです。

2019年7月のデータ

`` `` [{"n"： "7627"、 "fastttfb"： "0.377"、 "avgttfb"： "0.5032"、 "slowttfb"： "0.1198"}]]

<code>
</code><details><summary>ビッグクエリー</summary>`` `
#standardsql
選択します
  n、count（明確な起源）、
  round（sum（if（ttfb.start = 200およびttfb.start = 1000、ttfb.dences、0）） / sum（ttfb.dences）、4）slowttfbとして
から
  `chrome-ux-report.all.201907`、
  unnest（experimental.time_to_first_byte.histogram.bin）as ttfb
参加する
  （select url、regexp_extrage（lower（concat（respotherheaders、resp_x_powered_by、resp_via、resp_server）））
      '（netlify | x-github-request）'）
    プラットフォームとして
  `httparchive.summary_requests.2019_07_01_mobile`から
の上
  concat（origin、 '/'）= url
どこ
  プラットフォームはヌルではありません
注文
  n desc</details>

FCPの結果は次のとおりです。

さて、fidを見てみましょう：

2019年7月のデータ

`` `` [{"n"： "4136"、 "fastfcp"： "0.5552"、 "avgfcp"： "0.3126"、 "slowfcp"： "0.1323"、 "fastfid"： "0.9263"、 "avgfid"： "0.0497"、 "0.0497

<code>
</code><details><summary>ビッグクエリー</summary>`` `
#standardsql
  選択します
    n、count（明確な起源）、
    round（sum（if（fcp.start = 1000およびfcp.start = 2500、fcp.density、0） / sum（fcp.dences）、slowfcpとして、
    round（sum（if（fid.start = 50およびfid.start = 250、fid.density、0）） / sum（fid.dencess）、4）slowfidとして
  から
    `chrome-ux-report.all.201907`、
    fcpとしてunnest（first_contentful_paint.histogram.bin）、
    fidとしてunnest（experimental.first_input_delay.histogram.bin）
  参加する
    （select url、regexp_extrage（lower（concat（respotherheaders、resp_x_powered_by、resp_via、resp_server）））
        '（netlify | x-github-request）'）
      プラットフォームとして
    `httparchive.summary_requests.2019_07_01_mobile`から
  の上
    concat（origin、 '/'）= url
  どこ
    プラットフォームはヌルではありません
  注文
    n desc</details>

データは、Jamstack Webサイトが最適に機能することを示しています。モバイルとデスクトップの値はほぼ同じですが、さらに驚くべきことです！

エンジニアリングリーダーからのいくつかの考え

業界の有名な人々の例をいくつか見せてみましょう。

@httparchiveからの4億6800万のリクエストのうち、48％がCDNから提供されませんでした。以下のサービスソースを視覚化しました。これらの多くは、サードパーティサービスの要求です。リクエストを行ったクライアントは、カリフォルニア州レッドウッドシティにあります。遅延が重要です。 #webperf pic.twitter.com/0f7nfa1qgm

- Paul Calvano（@paulcalvano）2019年8月29日

Jamstack Webサイトは通常、CDNSでホストされ、TTFBを緩和します。ファイルホスティングはAmazon Webサービスまたは同様のインフラストラクチャによって処理されるため、すべてのWebサイトを単一の修理で改善できます。

別の実際の調査では、FCPを改善するためには、静的HTMLを提供することが最善であることが示されています。

最初の意味のある描画時間が良いのはどれですか？

olly 27,506のすべてのツイートを含む生の8.5MB HTMLファイルフルテキスト

（ネタバレ：@____Lighthouseは、8.5MBのHTMLが約200ミリ秒を獲得したと報告しています）

- Zach Leatherman（@zachleat）2019年9月6日

上記のすべての結果の比較は次のとおりです。

Jamstackは、CDNを使用して静的にページを提供することにより、ネットワークのパフォーマンスを向上させます。これは重要です。これは、高速バックエンドがユーザーに到達するのに長い時間がかかり、非常に遅くなるためです。同様に、遅いバックエンドがすぐにユーザーに届き、非常に遅くなります。

Jamstackは、それを使用するサイトの数がCMSほど大きくないため、パフォーマンスコンテストにまだ優勝していませんが、コンテストに勝つ意図は非常に良いためです。

これらのメトリックをパフォーマンス予算に追加することで、ワークフローで優れたパフォーマンスを構築できます。例えば：

• TTFB：200ミリ秒
• FCP：1秒
• FID：50ミリ秒

賢く使う？

編集者注： Artem Denysovは、Jamstack Webサイトの立ち上げを大幅に支援するサービスであり、Jamstack Webサイトとコンテンツのワークフローエッジを簡素化するための今後のツールであるStackbitから来ています。 Artemは、Rick Viscomi、Rob Austin、Aleksey Kulikovに、記事のレビューを手伝ってくれたことに感謝していると言いました。

以上が数字によるJamstack＆＃039;の速度を見てくださいの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。