Optimierung der Webperformance: Die intelligenten Komprimierungsstandards von Fastly im Detail

In der heutigen schnelllebigen digitalen Landschaft ist eine langsame Website eine Website, die an Attraktivität verliert. Dies führt nicht nur zu Frustration bei den Nutzern, sondern wirkt sich auch auf die Platzierungen in Suchmaschinen und letztendlich auf Ihren Gewinn aus. 

Was wäre, wenn es eine einfache, aber dennoch wirkungsvolle Möglichkeit gäbe, Ihre Website drastisch zu beschleunigen und gleichzeitig die Kosten zu senken?

Das Geheimnis liegt in der Inhaltskomprimierung.  Mit dieser häufig übersehenen Optimierung lassen sich die Payload-Größen um bis zu 70 % reduzieren. Durch die Verwendung von Algorithmen wie Brotli oder gzip können Sie Inhalte schneller ausliefern, die Bandbreitennutzung reduzieren und Ihren Nutzern ein reibungsärmeres und schnelleres Erlebnis bieten.  Und das alles, ohne eine einzige Zeile am Design Ihrer Website zu ändern.

Bei Fastly setzen wir uns dafür ein, die Websites unserer Kunden schneller zu machen, und die Inhaltskomprimierung ist ein Eckpfeiler dieses Engagements.  Tatsächlich sind wir seit über einem Jahrzehnt Vorreiter in diesem Bereich. 

In diesem Post werden wir die Standard-Komprimierungseinstellungen von Fastly genauer unter die Lupe nehmen, ihre Effektivität anhand aktueller Daten aus dem HTTP-Archiv überprüfen und zeigen, wie wir diese Daten nutzen, um unseren Kunden ein besseres Erlebnis zu bieten.

Wie Fastly Ihre Inhalte durch Komprimierung optimiert

Fastly optimiert automatisch Anfragen, um komprimierte Antworten effizient zu cachen, was zu einer erheblichen Performance-Steigerung führt. Wir unterstützen zwei primäre Kompressionsalgorithmen für Daten auf der Edge: Gzip und Brotli.

Fastly handhabt die Inhaltskomprimierung auf einige wesentliche Arten:

• Kompression am Origin: Wenn Ihr Origin Inhalte bereits komprimiert und korrekt mit Accept-Encoding und Vary Header konfiguriert ausliefert, stellt Fastly sicher, dass diese komprimierten Antworten nur an unterstützende Clients ausgeliefert und so weit wie möglich aus dem Cache wiederverwendet werden.

• Kompression auf der Edge: Fastly kann Daten auch direkt auf der Edge unserer Plattform komprimieren:

• Statische Kompression: Statische Kompression tritt auf, wenn Fastly Antworten von Ihrem Origin-Server erhält, bevor sie zwischengespeichert werden. Für cachefähige Inhalte ist dies hocheffizient – Fastly nimmt die unkomprimierte Antwort, komprimiert sie auf der Edge und speichert das komprimierte Objekt für zukünftige Anfragen.

Statische Kompression ist für VCL-Services entweder mit Gzip oder Brotli verfügbar. Da das gecachte Objekt zwischengespeichert und in seiner kleineren Form ausgeliefert wird, basiert die Abrechnung auf der komprimierten Größe, die an den Kunden ausgeliefert wird. Dies trägt zur Reduzierung der Bandbreitenkosten bei und verbessert gleichzeitig die Gesamt-Performance. 

• Dynamische Kompression: Dies geschieht kurz bevor die Antworten an den Kunden ausgeliefert werden, nach dem Caching. Es ist ideal, wenn statische Komprimierung nicht möglich ist und mit Edge Side Includes kompatibel ist. Dynamisch komprimierte Antworten werden basierend auf der unkomprimierten Größe abgerechnet, bevor die Komprimierung erfolgt.

• Optimierung Accept-Encoding: Fastly normalisiert die von den Clients gesendeten Accept-Encoding-Header-Werte. Viele Varianten dieses Headers sind semantisch äquivalent (zum Beispiel gzip, br und gzip, br, deflate).  Durch die Normalisierung dieses Header reduziert Fastly die Anzahl der cache-Schlüssel-Permutationen, sodass eine einzelne zwischengespeicherte komprimierte Antwort von mehr Nutzern wiederverwendet werden kann, selbst wenn ihre Browser leicht unterschiedliche Accept-Encoding-Werte senden. Das Ergebnis sind eine höhere Cache-Effizienz und schnellere Antwortzeiten für Endnutzer.

Die Standard-Komprimierungseinstellungen von Fastly: Ein detaillierter Blick

Wenn Sie sich bei Fastly registrieren, werden bestimmte Komprimierungseinstellungen standardmäßig aktiviert. Diese Standardeinstellungen bestimmen, welche Inhaltstypen und Dateierweiterungen Fastly automatisch komprimiert, wenn sie unkomprimiert von Ihrem Origin-Server ankommen.

Zu den standardmäßig komprimierbaren Inhaltstypen von Fastly gehören:

text/html|application/x-javascript|text/css|application/javascript|text/javascript|application/json|application/vnd\.ms-fontobject|application/x-font-opentype|application/x-font-truetype|application/x-font-ttf|application/xml|font/eot|font/opentype|font/otf|image/svg\+xml|image/vnd\.microsoft\.icon|text/plain|text/xml

Die standardmäßigen komprimierbaren Erweiterungen sind:

"\.(?:css|js|html|eot|ico|otf|ttf|json|svg)(?:$|\?)"

Wie schneiden diese Standardeinstellungen in der Praxis ab? 

Um dies zu beantworten, wenden wir uns an das HTTP Archive, einen monatlichen Datensatz, der WebPageTest-Ergebnisse für etwa 15 Millionen URLs im CrUX-Datensatz von Google sammelt. 

Für den Datensatz vom Juli 2025 umfasste diese Analyse insgesamt erstaunliche 25 Milliarden Anfragen. Dieser umfangreiche Datensatz ermöglichte eine detaillierte Untersuchung von Anfrage-URLs, Dateierweiterungen und Content-Type / Content-Encoding-Antwortheadern, um die Effektivität der Komprimierung zu bewerten.

Diese Arbeit baut auf der grundlegenden Forschung von Steve Souders (2014) auf, der ebenfalls das HTTP Archive nutzte, um die Gzip-Einstellungen von Fastly zu verfeinern und zu optimieren – und damit ein jahrzehntelanges Streben nach besserer Web-Performance durch intelligentere Kompression fortsetzte.

Eine Auswertung der HTTP-Archive-Daten für Fastly zeigt, dass die Mehrheit der Dateierweiterungen, die unter der Standardkonfiguration von Fastly als komprimierbar klassifiziert werden, in der Praxis in einem komprimierten Format mit hoher Rate ausgeliefert wird. Diese Übereinstimmung zwischen Konfiguration und beobachtetem Verhalten deutet darauf hin, dass die Standardeinstellungen von Fastly im Allgemeinen effektiv sind, um die Übertragungsgröße für komprimierbare Inhalte zu optimieren.

Eine bemerkenswerte Ausnahme bildet die .ico-Erweiterung, die eine vergleichsweise niedrige Kompressionsrate aufweist. Eine genauere Untersuchung zeigt, dass ein erheblicher Teil der Ressourcen mit dieser Erweiterung mit dem Inhaltstyp image/png bereitgestellt wird. Da PNG bereits ein verlustfreies Komprimierungsformat ist, ist der zusätzliche Vorteil einer weiteren HTTP-Komprimierung vernachlässigbar, was wahrscheinlich die geringe Akzeptanz erklärt. Die folgende Tabelle listet die am häufigsten beobachteten Inhaltstypen im Zusammenhang mit .ico-Antworten auf.

Für Ressourcen mit Erweiterungen, die nicht in der Standardliste der komprimierbaren Dateien von Fastly enthalten sind, wurde ein erheblicher Anteil dennoch komprimiert bereitgestellt, da es Übereinstimmungen im Content-Type-Header gab. Obwohl die Dateiendung .php beispielsweise nicht in der Standardliste enthalten ist, waren die meisten .php-Antworten im Datensatz Inhaltstypen wie application/javascript, text/css, application/json und text/html zugeordnet – allesamt Bereiche, die unter die Standardkomprimierungsregeln von Fastly fallen. Die einzigen häufig beobachteten komprimierbaren Inhaltstypen ohne entsprechende Erweiterung in der Standardliste waren text/vtt und text/markdown. Die folgende Tabelle fasst die häufigsten Inhaltstypen zusammen, die von Fastly-Kunden ausgeliefert werden, und zeigt, ob sie den Standardkomprimierungsregeln entsprechen würden.

Verbesserte Komprimierungsstandards: Schnellere Websites, niedrigere Kosten

Obwohl die Standardkomprimierungskonfiguration von Fastly bereits sehr effektiv war, zeigte die Analyse der HTTP-Archivdaten Möglichkeiten zur schrittweisen Verbesserung auf. Basierend auf diesen Erkenntnissen haben wir die Standard-Komprimierungsregeln erweitert, um die Abdeckung und Effizienz weiter zu steigern:

Zu den Standardeinstellungen hinzugefügte Erweiterungen

• jsonp

• txt

• vtt

Zu den Standardeinstellungen hinzugefügte Inhaltstypen

• text/* (Wildcard für alle textbasierten Formate)

• application/*json (Wildcard für alle JSON-basierte Anwendungstypen)

• application/*xml (Wildcard für alle XML-basierten Anwendungstypen)

Diese Ergänzungen ermöglichen es Fastly, ein noch breiteres Spektrum relevanter Inhalte automatisch zu komprimieren, wodurch die Payload-Größen weiter reduziert werden – ein doppelter Gewinn: schnellere Performance und niedrigere Auslieferungskosten, und das alles, ohne eine einzige Zeile Code zu ändern.

Und wir hören hier nicht auf. Unsere Entwicklerteams überwachen und bewerten aktiv neue Kompressionstechnologien wie Zstandard und Compression Dictionary Transport, um herauszufinden, wo sie weitere Geschwindigkeits- und Effizienzsteigerungen erzielen können. Während sich das Web weiterentwickelt, werden sich auch die intelligenten Komprimierungsstandards von Fastly anpassen – damit unsere Kunden stets an der Spitze der Webperformance bleiben.

Sind Sie neugierig, was die intelligente Komprimierung von Fastly für Ihre Performance-Metriken bewirken könnte? Nehmen Sie Kontakt zu Ihrem Account-Team auf oder kontaktieren Sie uns.  Wir würden es Ihnen sehr gerne zeigen!

Unterstützender Datensatz

Der BigQuery-SQL-Code, der zur Ermittlung der Komprimierungsstatistik verwendet wird, ist unten aufgeführt. Die Ausführung dieser Abfrage verarbeitet ungefähr 2 TB Daten (diese Query kann das Datenvolumen von „Free“ überschreiten). 

Um das verarbeitete Volumen zu reduzieren und die damit verbundenen Query-Kosten zu senken, können die Filterklauseln ‚is_root_page‘ und ‚rank‘ unkommentiert gelassen werden, um den Datensatz weiter einzuschränken.

WITH request_data AS (
 SELECT
   rank, page, url,
   JSON_VALUE(payload._contentEncoding) AS encoding,
   JSON_VALUE(summary._cdn_provider) AS cdn,
   header_name.value AS content_type,
   JSON_VALUE(summary.ext) AS ext,
   JSON_VALUE(summary.type) AS type,
   JSON_VALUE(summary.respBodySize) AS size,
 FROM `httparchive.crawl.requests` ,
   UNNEST (response_headers) AS header_name
 WHERE
   date = "2025-07-01"
   --AND is_root_page = true
   --AND rank <= 1000000
   AND client= "mobile"
   AND header_name.name = "content-type"
)
SELECT
 ext,
 content_type,
 COUNTIF(encoding IN ('gzip', 'br')) AS compressed,
 COUNTIF(ext IN ('css','js','html','eot','ico','otf', 'ttf', 'json', 'svg')) AS fastly_extension_defaults,
 COUNTIF(REGEXP_CONTAINS(content_type,
'(text/html|application/x-javascript|text/css|application/javascript|text/javascript|application/json|application/vnd.ms-fontobject|application/x-font-opentype|application/x-font-truetype|application/x-font-ttf|application/xml|font/eot|font/opentype|font/otf|image/svg\\+xml|image/vnd.microsoft.icon|text/plain|text/xml)')
) AS fastly_content_types_defaults,

 COUNTIF(ext IN ('css','js','html','eot','ico','otf', 'ttf', 'json', 'svg') OR REGEXP_CONTAINS(content_type,
'(text/html|application/x-javascript|text/css|application/javascript|text/javascript|application/json|application/vnd.ms-fontobject|application/x-font-opentype|application/x-font-truetype|application/x-font-ttf|application/xml|font/eot|font/opentype|font/otf|image/svg\\+xml|image/vnd.microsoft.icon|text/plain|text/xml)')) AS fastly_default_compressible,
 COUNT(*) AS requests,
 COUNTIF(encoding IN ('gzip', 'br')) / COUNT(*) AS pct_compressed
FROM request_data
--WHERE cdn = "Fastly"
GROUP BY 1,2
HAVING COUNT(*) > 1000
ORDER BY 3 DESC