Ein Blick auf die Geschwindigkeit von JAMstack, in Zahlen

Man sagt, JAMstack-Seiten sind schnell – finden wir heraus, warum, indem wir uns echte Leistungsmetriken ansehen! Wir werden gängige Metriken wie Time to First Byte (TTFB) und andere behandeln und dann Daten über einen breiten Querschnitt von Seiten vergleichen, um zu sehen, wie sich verschiedene Arten der Aufschlüsselung dieser Seiten vergleichen.

Zuerst möchte ich eine kleine Analyse präsentieren, um einen Hintergrund zu geben. Laut dem HTTPArchive Metrics Report zur Seitenladung warten Nutzer durchschnittlich **6,7 Sekunden**, bis sie primäre Inhalte sehen.

First Contentful Paint (FCP) – misst den Zeitpunkt, zu dem Text oder Grafiken zum ersten Mal auf dem Bildschirm gerendert werden.

Wenn wir über die Interaktion mit einer Seite sprechen (Time to Interactive), warten Nutzer noch länger. Die durchschnittliche Zeit bis zur Interaktivität beträgt **9,3 Sekunden**.

Time to Interactive (TTI) – eine Zeit, in der der Nutzer ohne Verzögerung mit einer Seite interagieren kann.

Stand der realen Nutzer-Webperformance

Die obigen Daten stammen aus der Labormonitoring und repräsentieren nicht vollständig die reale Nutzererfahrung. Echtzeitdaten von Nutzern aus dem Chrome User Experience Report (CrUX) zeigen ein noch breiteres Bild.

Ich werde Daten verwenden, die von Nutzern mobiler Geräte aggregiert wurden. Insbesondere werden wir Metriken wie

• Time To First Byte (TTFB)
• First Contentful Paint (FCP)
• First Input Delay (FID)

Time To First Byte

TTFB repräsentiert die Zeit, die der Browser wartet, um die ersten Bytes der Antwort vom Server zu erhalten. TTFB dauert für Nutzer weltweit zwischen 200 ms und 1 Sekunde. Das ist ziemlich lange, um die ersten Teile der Seite zu empfangen.

First Contentful Paint

FCP tritt bei 23% der Seitenaufrufe weltweit nach 2,5 Sekunden ein.

First Input Delay

FID-Metriken zeigen, wie schnell Webseiten auf Benutzereingaben reagieren (z.B. Klick, Scrollen usw.).

CrUX hat aufgrund unterschiedlicher Einschränkungen keine TTI-Daten, hat aber FID, was noch besser die Interaktivität der Seite widerspiegeln kann. Über 75% der mobilen Nutzererfahrungen haben eine Eingabeverzögerung von 50 ms und die Nutzer hatten keine Ruckler.

Sie können die folgenden Abfragen verwenden und damit auf dieser Website experimentieren.

[
    {
      "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"
    }
  ]

#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

Stand der Leistung von Content Management Systemen (CMS)

CMSs *sollten* unsere Retter gewesen sein und uns geholfen haben, schnellere Seiten zu bauen. Aber wenn man sich die Daten ansieht, ist das nicht der Fall. Der aktuelle Stand der CMS-Performance weltweit ist nicht besonders gut.

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

#standardSQL
  SELECT
    COUNT(DISTINCT origin) AS freq,
      
    ROUND(SUM(IF(ttfb.start < 200, ttfb.density, 0)) / SUM(ttfb.density), 4) AS fastTTFB,
    ROUND(SUM(IF(ttfb.start >= 200 AND ttfb.start < 1000, ttfb.density, 0)) / SUM(ttfb.density), 4) AS avgTTFB,
    ROUND(SUM(IF(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

Und hier sind die FCP-Ergebnisse

Immerhin sind die FID-Ergebnisse etwas besser

[
    {
      "freq": "546415",
      "fastFCP": "0.2873",
      "avgFCP": "0.4187",
      "slowFCP": "0.2941",
      "fastFID": "0.8275",
      "avgFID": "0.1183",
      "slowFID": "0.0543"
    }
  ]

#standardSQL
  SELECT
    COUNT(DISTINCT origin) AS freq,
    ROUND(SUM(IF(fcp.start < 1000, fcp.density, 0)) / SUM(fcp.density), 4) AS fastFCP,
    ROUND(SUM(IF(fcp.start >= 1000 AND fcp.start < 2500, fcp.density, 0)) / SUM(fcp.density), 4) AS avgFCP,
    ROUND(SUM(IF(fcp.start >= 2500, fcp.density, 0)) / SUM(fcp.density), 4) AS slowFCP,
    ROUND(SUM(IF(fid.start < 50, fid.density, 0)) / SUM(fid.density), 4) AS fastFID,
    ROUND(SUM(IF(fid.start >= 50 AND fid.start < 250, fid.density, 0)) / SUM(fid.density), 4) AS avgFID,
    ROUND(SUM(IF(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

Wie Sie sehen können, performen Seiten, die mit einem CMS erstellt wurden, nicht viel besser als die Gesamtleistung von Seiten im Web.

Sie können die Performance-Verteilung über verschiedene CMS auf dieser HTTPArchive-Foren-Diskussion finden.

E-Commerce-Websites, ein gutes Beispiel für Seiten, die typischerweise auf einem CMS basieren, haben wirklich schlechte Statistiken für Seitenaufrufe

• ~40% – 1 Sekunde für TTFB
• ~30% – mehr als 1,5 Sekunden für FCP
• ~12% – Verzögerung bei der Seiteninteraktion.

Ich hatte Kunden, die die Unterstützung für IE10-IE11 forderten, weil der Traffic von diesen Nutzern 1% ausmachte, was Millionen von Dollar Umsatz bedeutete. Bitte berechnen Sie Ihre Verluste, falls 1% der Nutzer sofort abspringen und wegen schlechter Performance nie wiederkommen. Wenn die Nutzer nicht glücklich sind, wird auch das Geschäft unglücklich sein.

Um mehr Details darüber zu erfahren, wie Web-Performance mit Umsatz korreliert, schauen Sie sich WPO Stats an. Es ist eine Liste von Fallstudien echter Unternehmen und ihres Erfolgs nach Leistungsverbesserungen.

JAMstack hilft bei der Verbesserung der Webperformance

Mit JAMstack rendern Entwickler so wenig wie möglich auf dem Client, stattdessen nutzen sie Server-Infrastruktur für die meisten Dinge. Ganz zu schweigen davon, dass die meisten JAMstack-Workflows hervorragend für Deployments und Skalierbarkeit geeignet sind, unter anderem. Inhalte werden statisch auf statischen Dateihosts gespeichert und über CDNs für die Nutzer bereitgestellt.

Lesen Sie Mathieu Diones „Neu bei JAMstack? Alles, was Sie wissen müssen, um loszulegen“, um sich mit JAMstack vertraut zu machen.

Ich hatte zwei Jahre Erfahrung mit einem der beliebten CMSs für E-Commerce und wir hatten viele Probleme mit Deployments, Performance, Skalierbarkeit. Das Team verbrachte Tage mit deren Behebung. Das ist nicht, was Kunden wollen. Das sind die Art von großen Problemen, die JAMstack löst.

Wenn man sich die CrUX-Daten ansieht, ist die Performance von JAMstack-Seiten wirklich solide. Die folgenden Werte basieren auf Seiten, die über Netlify und GitHub bereitgestellt werden. Es gibt eine Diskussion im HTTP-Archive-Forum, an der Sie teilnehmen können, um die Daten genauer zu machen.

Hier sind die Ergebnisse für TTFB

[
  {
    "n": "7627",
    "fastTTFB": "0.377",
    "avgTTFB": "0.5032",
    "slowTTFB": "0.1198"
  }
]

#standardSQL
SELECT
  COUNT(DISTINCT origin) AS n,
  ROUND(SUM(IF(ttfb.start < 200, ttfb.density, 0)) / SUM(ttfb.density), 4) AS fastTTFB,
  ROUND(SUM(IF(ttfb.start >= 200 AND ttfb.start < 1000, ttfb.density, 0)) / SUM(ttfb.density), 4) AS avgTTFB,
  ROUND(SUM(IF(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

So schnitten die FCP-Werte ab

Betrachten wir nun FID

[
    {
      "n": "4136",
      "fastFCP": "0.5552",
      "avgFCP": "0.3126",
      "slowFCP": "0.1323",
      "fastFID": "0.9263",
      "avgFID": "0.0497",
      "slowFID": "0.024"
    }
  ]

#standardSQL
  SELECT
    COUNT(DISTINCT origin) AS n,
    ROUND(SUM(IF(fcp.start < 1000, fcp.density, 0)) / SUM(fcp.density), 4) AS fastFCP,
    ROUND(SUM(IF(fcp.start >= 1000 AND fcp.start < 2500, fcp.density, 0)) / SUM(fcp.density), 4) AS avgFCP,
    ROUND(SUM(IF(fcp.start >= 2500, fcp.density, 0)) / SUM(fcp.density), 4) AS slowFCP,
    ROUND(SUM(IF(fid.start < 50, fid.density, 0)) / SUM(fid.density), 4) AS fastFID,
    ROUND(SUM(IF(fid.start >= 50 AND fid.start < 250, fid.density, 0)) / SUM(fid.density), 4) AS avgFID,
    ROUND(SUM(IF(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

Die Zahlen zeigen die beste Performance der JAMstack-Seiten. Die Zahlen sind für Mobilgeräte und Desktops ziemlich gleich, was sogar noch erstaunlicher ist!

Einige Highlights von Engineering-Führungskräften

Lassen Sie mich Ihnen ein paar Beispiele von prominenten Persönlichkeiten der Branche zeigen

Von 468 Millionen Anfragen im @HTTPArchive wurden 48% nicht von einem CDN geliefert. Ich habe visualisiert, wo sie unten ausgeliefert wurden. Viele davon waren Anfragen an Dritte. Der anfragende Client befand sich in Redwood City, CA. Latenz ist wichtig. #WebPerf pic.twitter.com/0F7nFa1QgM

— Paul Calvano (@paulcalvano) 29. August 2019

JAMstack-Seiten werden im Allgemeinen CDN-gehostet und mildern TTFB. Da das Dateihosting von Infrastrukturen wie Amazon Web Services oder ähnlichem übernommen wird, kann die Performance aller Seiten mit einer einzigen Korrektur verbessert werden.

Eine weitere reale Untersuchung besagt, dass es besser ist, statisches HTML für bessere FCP zu liefern.

Welche hat eine bessere First Meaningful Paint Zeit?

① eine rohe 8,5 MB HTML-Datei mit dem vollständigen Text jedes meiner 27.506 Tweets
② eine clientseitig gerenderte React-Seite mit genau einem Tweet darauf

(Spoiler: @____lighthouse berichtet, dass 8,5 MB HTML mit rund 200 ms gewinnen)

— Zach Leatherman (@zachleat) 6. September 2019

Hier ist ein Vergleich aller oben gezeigten Ergebnisse

JAMstack bringt bessere Performance ins Web, indem es Seiten statisch mit CDNs ausliefert. Das ist wichtig, denn ein schnelles Backend, dessen Erreichung lange dauert, wird langsam sein, und ebenso wird ein langsames Backend, das schnell erreichbar ist, ebenfalls langsam sein.

JAMstack hat das Performance-Rennen noch nicht gewonnen, weil die Anzahl der damit erstellten Seiten nicht so riesig ist wie beispielsweise bei CMS, aber die Absicht, es zu gewinnen, ist sehr groß.

Das Hinzufügen dieser Metriken zu einem Performance-Budget kann eine Möglichkeit sein, sicherzustellen, dass Sie gute Performance in Ihren Workflow integrieren. Etwas wie

• TTFB: 200ms
• FCP: 1s
• FID: 50ms

Geben Sie es klug aus 🙂

Anmerkung des Herausgebers: Artem Denysov kommt von Stackbit, einem Service, der sehr dabei hilft, JAMstack-Seiten und weitere kommende Tools für JAMstack-Seiten und Inhalte zu erstellen. Artem sagte mir, er möchte Rick Viscomi, Rob Austin und Aleksey Kulikov für ihre Hilfe bei der Überprüfung des Artikels danken.