Melihat kelajuan Jamstack ' dengan nombor

Laman web Jamstack terkenal dengan kelajuannya, dan artikel ini akan mendedahkan sebab -sebab melalui metrik prestasi sebenar. Kami akan meliputi metrik biasa seperti Time to First Byte (TTFB) dan kemudian membandingkan data dari pelbagai laman web untuk melihat bagaimana kaedah penyegerakan yang berbeza mempengaruhi prestasi.

Pertama, mari kita lakukan analisis kecil untuk memberikan beberapa maklumat latar belakang. Menurut laporan metrik HttParchive pada pemuatan halaman, pengguna menunggu purata 6.7 saat untuk melihat kandungan utama.

Lukisan Kandungan Pertama (FCP) - mengukur titik dalam masa apabila teks atau graf pertama kali diberikan ke skrin.

Jika kita bercakap mengenai penglibatan halaman (masa interaksi), pengguna menunggu lebih lama. Masa interaksi purata ialah 9.3 saat .

Waktu Interaksi (TTI) - Masa pengguna boleh berinteraksi dengan halaman tanpa berlengah -lengah.

Status Prestasi Rangkaian Pengguna Sebenar

Data di atas berasal dari pemantauan makmal dan tidak dapat mewakili sepenuhnya pengalaman pengguna sebenar. Data pengguna sebenar berdasarkan Laporan Pengalaman Pengguna Chrome (CRUX) membentangkan gambar yang lebih komprehensif.

Saya akan menggunakan data yang diagregatkan dari pengguna yang menggunakan peranti mudah alih. Khususnya, kami akan menggunakan metrik berikut:

• Masa ke Byte Pertama (TTFB)
• Lukisan Kandungan Pertama (FCP)
• Kelewatan Input Pertama (FID)

Masa ke bait pertama

TTFB mewakili masa penyemak imbas menunggu bait pertama untuk menerima respons dari pelayan. Bagi pengguna di seluruh dunia, TTFB berkisar antara 200 milisaat hingga 1 saat. Ini adalah masa yang agak lama untuk menerima kumpulan pertama blok data halaman.

Lukisan kandungan pertama

Dalam 23% pandangan halaman dunia, FCP berlaku selepas 2.5 saat.

Kelewatan input pertama

Metrik FID menunjukkan betapa cepatnya laman web bertindak balas terhadap input pengguna (seperti klik, skrol, dan lain -lain).

Oleh kerana batasan yang berbeza, Crux tidak mempunyai data TTI, tetapi mempunyai FID, yang lebih baik mencerminkan interaktiviti halaman. Lebih daripada 75% pengalaman pengguna mudah alih mempunyai latensi input 50 milisaat dan pengguna tidak mengalami sebarang ketinggalan.

Anda boleh menggunakan pertanyaan di bawah dan menggunakannya di laman web tersebut.

Data untuk Julai 2019

``` [ { "date": "2019_07_01", "timestamp": "15619392000000", "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"}, {"tarikh": "2019_07_01", " "fastttfb": "23.61", "avgttfb": "46.49", "slowttfb": "29.89", "fastfcp": "38.58", "avgfcp": "38.28" "17.95", "Slowfid": "6.92"}]

<code>
</code><details><summary>BigQuery</summary> `` `
#standardsql
  Pilih
    Regexp_replace (yyyymm, '(\\ d {4}) (\\ d {2})', '\\ 1 _ \\ 2_01')
    Unix_date (cast (regexp_replace (yyyymm, '(\\ d {4}) (\\ d {2})', '\\ 1-\\ 2-01')
    Jika (peranti = 'desktop', 'desktop', 'mudah alih') sebagai pelanggan,
    Bulat (jumlah (fast_fcp) * 100 / (jumlah (fast_fcp) jumlah (avg_fcp) jumlah (slow_fcp)), 2) sebagai fastfcp,
    Bulat (jumlah (avg_fcp) * 100 / (jumlah (fast_fcp) jumlah (avg_fcp) jumlah (slow_fcp)), 2) sebagai avgfcp,
    Pusingan (SUM (SLOW_FCP) * 100 / (SUM (FAST_FCP) SUM (AVG_FCP) SUM (SLOW_FCP)), 2) sebagai SLOWFCP,
    Bulat (jumlah (fast_fid) * 100 / (jumlah (fast_fid) jumlah (avg_fid) jumlah (slow_fid)), 2) sebagai fastfid,
    Bulat (jumlah (avg_fid) * 100 / (jumlah (fast_fid) jumlah (avg_fid) jumlah (slow_fid)), 2) sebagai avgfid,
    Bulat (jumlah (slow_fid) * 100 / (jumlah (fast_fid) jumlah (avg_fid) jumlah (slow_fid)), 2) sebagai perlahan
  Dari
    `chrome-ux-report.materialized.device_summary`
  Di mana
    yyyymm = '201907'
  Kumpulan oleh
    tarikh,
    timestamp,
    pelanggan
  Pesanan oleh
    tarikh desc,
    pelanggan</details>

Status Prestasi Sistem Pengurusan Kandungan (CMS)

CMS harus menjadi Juruselamat kita dan membantu kita membina laman web yang lebih cepat. Tetapi berdasarkan data, ini tidak berlaku. Prestasi semasa CMS di seluruh dunia tidak sesuai.

Data untuk Julai 2019

`` `[{" freq ":" 1548851 "," cepat ":" 0.1951 "," avg ":" 0.4062 "," lambat ":" 0.3987 "}]

<code>
</code><details><summary>BigQuery</summary> `` `
#standardsql
  Pilih
    Kiraan (asal berbeza) sebagai freq,

    Bulat (jumlah (if (ttfb.start = 200 dan ttfb.start = 1000, ttfb.density, 0)) / sum (ttfb.density), 4) sebagai slowttfb

  Dari
    `Chrome- Ux-Port.all.201907`,
    Unnest (Experimental.Time_TO_FIRST_BYTE.HISTOGRAM.BIN) sebagai TTFB
  Menyertai (
    Pilih
      URL,
      App
    Dari
      `httparchive.technologies.2019_07_01_mobile`
    Di mana
      kategori = 'cms'
    )
  Pada concat (asal, '/') = url
  Pesanan oleh
    Freq Desc</details>

Berikut adalah hasil FCP:

Sekurang -kurangnya keputusan FID lebih baik:

Data untuk Julai 2019

``` [ { "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
  Pilih
    Kiraan (asal berbeza) sebagai freq,
    Pusingan (jumlah (jika (fcp.start = 1000 dan fcp.start = 2500, fcp.density, 0)) / sum (fcp.density), 4) sebagai slowfcp,
    Bulat (jumlah (if (fid.start = 50 dan fid.start = 250, fid.density, 0)) / jumlah (fid.density), 4) sebagai perlahan
  Dari
    `Chrome- Ux-Port.all.201907`,
    Unsnest (first_contentful_paint.histogram.bin) sebagai fcp,
    Unnest (Experimental.First_input_delay.histogram.bin) sebagai FID
  Menyertai (
    Pilih
      URL,
      App
    Dari
      `httparchive.technologies.2019_07_01_mobile`
    Di mana
      kategori = 'cms'
    )
  Pada concat (asal, '/') = url
  Pesanan oleh
    Freq Desc</details>

Seperti yang dapat anda lihat, prestasi laman web yang dibina dengan CMS tidak jauh lebih baik daripada prestasi keseluruhan laman web di web.

Anda boleh mencari pengedaran prestasi CMS yang berbeza dalam perbincangan forum HttParchive ini.

Laman web e-dagang adalah contoh hebat laman web yang biasanya dibina di atas CMS, dengan statistik paparan halaman yang sangat buruk:

• ~ 40% - TTFB adalah 1 saat
• ~ 30% - FCP lebih dari 1.5 saat
• ~ 12% - Kelewatan interaksi halaman.

Saya telah bertemu dengan beberapa pelanggan yang meminta sokongan untuk IE10-IE11 kerana lalu lintas dari pengguna ini menyumbang 1%, yang bersamaan dengan berjuta-juta dolar dalam pendapatan. Sila hitung berapa banyak kerugian anda jika 1% pengguna pergi dengan serta -merta dan tidak pernah kembali kerana prestasi yang lemah. Sekiranya pengguna tidak berpuas hati, perniagaan juga tidak berpuas hati.

Untuk mengetahui lebih lanjut mengenai bagaimana prestasi rangkaian dikaitkan dengan pendapatan, lihat statistik WPO. Berikut adalah senarai kes penyelidikan dari syarikat sebenar dan kisah kejayaan mereka selepas meningkatkan prestasi.

Jamstack membantu meningkatkan prestasi rangkaian

Dengan Jamstack, pemaju meminimumkan kerja rendering pada pelanggan dan sebaliknya menggunakan infrastruktur pelayan untuk mengendalikan kebanyakan perkara. Belum lagi, kebanyakan aliran kerja jamStack sangat baik untuk mengendalikan penyebaran dan menyumbang kepada skalabiliti dan faedah lain. Kandungan disimpan secara statik pada hos fail statik dan diberikan kepada pengguna melalui CDN.

Baca Mathieu Dionne's "Jamstack Newbie? Semua yang anda perlukan untuk memulakan" untuk mendapatkan idea yang lebih baik mengenai Jamstack.

Saya mempunyai dua tahun pengalaman menggunakan CMS e-dagang yang popular dan kami mempunyai banyak masalah dengan penempatan, prestasi, skalabilitas. Pasukan akan menghabiskan hari menyelesaikan masalah ini. Ini bukan apa yang pelanggan mahu. Ini adalah masalah besar yang diselesaikan Jamstack.

Melihat data Crux, prestasi laman web Jamstack kelihatan hebat. Nilai berikut adalah berdasarkan laman web yang disediakan oleh Netlify dan GitHub. Terdapat beberapa perbincangan mengenai forum HttParchive di mana anda boleh terlibat untuk membuat data anda lebih tepat.

Berikut adalah hasil TTFB:

Data untuk Julai 2019

`` `[{" n ":" 7627 "," fastttfb ":" 0.377 "," avgttfb ":" 0.5032 "," Slowttfb ":" 0.1198 "}]

<code>
</code><details><summary>BigQuery</summary> `` `
#standardsql
Pilih
  Kiraan (asal berbeza) sebagai n,
  Bulat (jumlah (if (ttfb.start = 200 dan ttfb.start = 1000, ttfb.density, 0)) / sum (ttfb.density), 4) sebagai slowttfb
Dari
  `Chrome- Ux-Port.all.201907`,
  Unnest (Experimental.Time_TO_FIRST_BYTE.HISTOGRAM.BIN) sebagai TTFB
Menyertai
  (Pilih URL, REGEXP_EXTRACT (lebih rendah (CONCAT (RESPOtherHeaders, resp_x_powered_by, resp_via, resp_server))
      '(netlify | x-github-request)')
    Sebagai platform
  Dari `httparchive.summary_requests.2019_07_01_mobile`)
Pada
  Concat (asal, '/') = url
Di mana
  platform tidak batal
Pesanan oleh
  n desc</details>

Berikut adalah hasil FCP:

Sekarang mari kita lihat FID:

Data untuk Julai 2019

``` [ { "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
  Pilih
    Kiraan (asal berbeza) sebagai n,
    Pusingan (jumlah (jika (fcp.start = 1000 dan fcp.start = 2500, fcp.density, 0)) / sum (fcp.density), 4) sebagai slowfcp,
    Bulat (jumlah (if (fid.start = 50 dan fid.start = 250, fid.density, 0)) / jumlah (fid.density), 4) sebagai perlahan
  Dari
    `Chrome- Ux-Port.all.201907`,
    Unsnest (first_contentful_paint.histogram.bin) sebagai fcp,
    Unnest (Experimental.First_input_delay.histogram.bin) sebagai FID
  Menyertai
    (Pilih URL, REGEXP_EXTRACT (lebih rendah (CONCAT (RESPOtherHeaders, resp_x_powered_by, resp_via, resp_server))
        '(netlify | x-github-request)')
      Sebagai platform
    Dari `httparchive.summary_requests.2019_07_01_mobile`)
  Pada
    Concat (asal, '/') = url
  Di mana
    platform tidak batal
  Pesanan oleh
    n desc</details>

Data menunjukkan bahawa laman web Jamstack melakukan yang terbaik. Nilai mudah alih dan desktop hampir sama, yang lebih menakjubkan!

Beberapa pemikiran dari pemimpin kejuruteraan

Izinkan saya menunjukkan kepada anda beberapa contoh orang terkenal dalam industri:

Daripada 468 juta permintaan dari @httparchive, 48% tidak disampaikan dari CDN. Saya memvisualisasikan sumber perkhidmatan mereka di bawah. Kebanyakannya adalah permintaan untuk perkhidmatan pihak ketiga. Pelanggan yang membuat permintaan itu terletak di Redwood City, California. Kelewatan adalah penting. #Webperf pic.twitter.com/0f7nfa1qgm

- Paul Calvano (@paulcalvano) 29 Ogos 2019

Laman web Jamstack biasanya dihoskan oleh CDN dan melegakan TTFBS. Oleh kerana hosting fail dikendalikan oleh Perkhidmatan Web Amazon atau infrastruktur yang serupa, semua laman web boleh diperbaiki dengan pembaikan tunggal.

Satu lagi kaji selidik sebenar menunjukkan bahawa untuk mendapatkan FCP yang lebih baik, adalah yang terbaik untuk menyediakan HTML statik.

Mana yang mempunyai masa lukisan pertama yang lebih baik?

① Fail HTML 8.5MB mentah yang mengandungi semua teks penuh 27,506 tweet saya ② laman web reaksi yang diberikan oleh pelanggan dengan hanya satu tweet

(Spoiler: @____Lighthouse melaporkan bahawa 8.5MB HTML memenangi kira -kira 200 milisaat)

- Zach Leatherman (@zacheat) 6 September 2019

Berikut adalah perbandingan semua hasil yang ditunjukkan di atas:

Jamstack meningkatkan prestasi rangkaian dengan menyediakan halaman secara statik menggunakan CDN. Ini penting kerana backend cepat mengambil masa yang lama untuk mencapai pengguna dan akan menjadi sangat perlahan. Begitu juga, backend yang perlahan dengan cepat mencapai pengguna dan akan menjadi sangat perlahan.

Jamstack belum memenangi pertandingan persembahan lagi kerana bilangan laman web yang menggunakannya tidak sebesar CMS, tetapi niat untuk memenangi pertandingan ini sangat baik.

Menambah metrik ini ke bajet prestasi anda memastikan anda membina prestasi yang baik dalam aliran kerja anda. Contohnya:

• TTFB: 200 milisaat
• FCP: 1 saat
• FID: 50 milisaat

Menggunakannya dengan bijak?

Nota Editor: Artem Denysov berasal dari Stackbit, sebuah perkhidmatan yang sangat membantu pelancaran laman web Jamstack, dan lebih banyak alat yang akan datang untuk memudahkan kelebihan aliran kerja laman web dan kandungan Jamstack. Artem memberitahu saya bahawa dia mengucapkan terima kasih kepada Rick Viscomi, Rob Austin dan Aleksey Kulikov kerana membantunya mengkaji artikel itu.

Atas ialah kandungan terperinci Melihat kelajuan Jamstack ' dengan nombor. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!