JAMstack website is known for its speed, and this article will reveal the reasons through actual performance metrics. We will cover common metrics such as time to first byte (TTFB) and then compare data from various websites to see how different sync methods affect performance.

First, let's do a small analysis to provide some background information. According to HTTPArchive's metrics report on page loading, users wait on average 6.7 seconds to see the main content.

First Content Draw (FCP) – Measures the point in time when a text or graph is first rendered to the screen.

If we are talking about page engagement (interaction time), the user waits longer. The average interaction time is 9.3 seconds .

Interaction Time (TTI) – The time the user can interact with the page without delay.

Real user network performance status

The above data comes from laboratory monitoring and cannot fully represent the real user experience. Real user data based on Chrome User Experience Reports (CrUX) presents a more comprehensive picture.

I will use data aggregated from users who use mobile devices. Specifically, we will use the following metrics:

• Time to the first byte (TTFB)
• First Content Drawing (FCP)
• First input delay (FID)

Time to the first byte

TTFB represents the time the browser waits for the first byte to receive the response from the server. For users around the world, TTFB ranges from 200 milliseconds to 1 second. This is a fairly long time to receive the first batch of data blocks of the page.

First content drawing

In 23% of the world's page views, FCP occurs after 2.5 seconds.

First input delay

The FID metric shows how quickly the web page responds to user inputs (such as clicks, scrolls, etc.).

Due to different limitations, CrUX does not have TTI data, but has FID, which even better reflects page interactivity. More than 75% of mobile user experiences have an input latency of 50 milliseconds and users have not experienced any lag.

You can use the queries below and use them on that site.

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

### Content Management System (CMS) Performance Status

CMS should be our savior and help us build faster websites. But judging from the data, this is not the case. The current performance of CMS globally is not ideal.

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

Here are the FCP results:

At least the FID results are better:

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

As you can see, the performance of a website built with CMS is not much better than the overall performance of the website on the web.

You can find the performance distribution of different CMSs in this HTTPArchive forum discussion.

An e-commerce website is a great example of a website that is usually built on CMS, with a very bad page view statistics:

• ~40% – TTFB is 1 second
• ~30% – FCP over 1.5 seconds
• ~12% – Page interaction delay.

I've met some clients who ask for support for IE10-IE11 because traffic from these users accounts for 1%, which is equivalent to millions of dollars in revenue. Please calculate how much your loss is if 1% of users leave immediately and never return due to poor performance. If the user is not satisfied, the business will also be dissatisfied.

To learn more about how network performance is associated with revenue, check out WPO Stats. Here is a list of research cases from real companies and their success stories after improving performance.

JAMstack helps improve network performance

With JAMstack, developers minimize rendering work on clients and instead use server infrastructure to handle most of the things. Not to mention, most JAMstack workflows are very good at handling deployments and contribute to scalability and other benefits. Content is stored statically on a static file host and provided to users via CDN.

Read Mathieu Dionne's "JAMstack Newbie? Everything You Need to Get Started" to get a better idea of ??JAMstack.

I have two years of experience using popular e-commerce CMS and we have had a lot of problems with deployment, performance, scalability. The team will spend days fixing these issues. This is not what the customer wants. These are the big problems that JAMstack solves.

Looking at the CrUX data, the performance of the JAMstack website looks great. The following values ??are based on websites provided by Netlify and GitHub. There are some discussions on the HTTPArchive forums where you can get involved to make your data more accurate.

Here are the results of TTFB:

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

Here are the results of FCP:

Now let's look at the FID:

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

Data shows that JAMstack websites perform best. The values ??of mobile and desktop are almost the same, which is even more amazing!

Some thoughts from engineering leaders

Let me show you a few examples of some well-known people in the industry:

Of the 468 million requests from @HTTPArchive, 48% were not served from the CDN. I visualized their service sources below. Many of these are requests for third-party services. The client that made the request is located in Redwood City, California. Delay is important. #WebPerf pic.twitter.com/0F7nFa1QgM

— Paul Calvano (@paulcalvano) August 29, 2019

JAMstack websites are typically hosted by CDNs and relieve TTFBs. Because file hosting is handled by Amazon Web Services or similar infrastructure, all websites can be improved with a single repair.

Another real survey shows that in order to get better FCP, it is best to provide static HTML.

Which one has better first meaningful drawing time?

① A raw 8.5MB HTML file containing all my 27,506 tweets full text ② A client-side rendered React website with only one tweet

(Spoiler: @____lighthouse reports that 8.5MB of HTML won about 200 milliseconds)

— Zach Leatherman (@zachleat) September 6, 2019

Here is a comparison of all the results shown above:

JAMstack improves network performance by providing pages statically using CDN. This is important because a fast backend takes a long time to reach the user and will be very slow. Similarly, a slow backend quickly reaches the user and will be very slow.

JAMstack hasn't won the performance contest yet because the number of sites using it is not as large as CMS, but the intention to win the contest is very good.

Adding these metrics to your performance budget ensures that you build good performance in your workflow. For example:

• TTFB: 200 milliseconds
• FCP: 1 second
• FID: 50 milliseconds

Use it wisely?

Editor's Note: Artem Denysov comes from Stackbit, a service that greatly helps the launch of the JAMstack website, and more upcoming tools to simplify the workflow edge of the JAMstack website and content. Artem told me that he thanked Rick Viscomi, Rob Austin and Aleksey Kulikov for helping him review the article.

The above is the detailed content of A Look at JAMstack's Speed, By the Numbers. For more information, please follow other related articles on the PHP Chinese website!