Unsere Analyse zeigt ein sehr großes Potenzial, den Energiebedarf Ihrer Website zu reduzieren und die User Experience zu verbessern.
Die Handlungsfelder mit dem größten Impact sind WOFF2, Umfang von Custom Font Schriftarten und -Stilen aus dem Bereich Schriften und Lazy Loading, Bildformate, Responsive Bilder aus dem Bereich Bilder. Eine Übersicht über alle Bereiche finden Sie hier.
Auf Basis der Anzahl Ihrer Seitenaufrufe ist das Einsparungspotenzial im Vergleich zu ähnlichen Websites sehr groß. Als Grundlage für die Berechnung verwenden wir CO2.js der »The Green Web Foundation« mit dem »Sustainable Web Design Model (SWDM)« in Version 4 (Lizenz).
kritisch
Moderne Bildformate wie WebP und AVIF reduzieren signifikant die Dateigrößen, besonders bei hochauflösenden Bildern. Dies führt zu schnelleren Ladezeiten und verringert den Datentransfer, was die Performance Ihrer Website erheblich verbessert.
Einige Dateien tragen die falsche Endung (z.b. .jpg.webp, der Mime-Type ist jedoch jpeg). WebP wird nicht verwendet.
Verwenden Sie in unterstützten Browsern das WebP- oder AVIF-Format für Bilder, um die Dateigröße im Vergleich zu JPG oder PNG deutlich zu reduzieren. Korrigieren sie falsche Dateiendungen.
Gerne stellen wir Ihnen Dienste wie z.B. Cloudinary vor, die automatisch die besten Bild- und Videoformate für Ihre Nutzer*innen ausliefern.
vorbildlich
Carousels präsentieren mehrere Inhalte oder Bilder in einem rotierenden Container. Häufig werden dabei mehrere Ressourcen gleichzeitig geladen, die jedoch nicht von jedem*r Nutzer*in gesehen werden. Dies führt zu längeren Ladezeiten, erhöhtem Datenverbrauch und einer verschlechterten User Experience.
Keine Auffälligkeiten.
vorbildlich
Große Bilddateien beanspruchen mehr Bandbreite, was zu Verzögerungen bei der Darstellung von Websites führt und den Datenverbrauch erhöht. Hierdurch entstehen auch größere CO₂-Emissionen, was wiederum die Umweltbelastung Ihrer Website steigert.
Auf großen Viewports ist keine maximale Inhaltsbreite gesetzt.
Bilder, die auf kleineren Viewports über die volle Breite laufen, könnten auf eine maximale Breite auf größeren Viewports gesetzt werden, um auf sehr großen Bildschirmen zu sparen und auch optisch nicht zu überwältigen.
optimierbar
Lazy Loading lädt Inhalte außerhalb des initial sichtbaren Viewports erst, wenn sie in das Sichtfeld der Nutzer*innen gelangen. Dies verkürzt die initiale Ladezeit, da zu Beginn weniger Daten geladen werden. Abhängig vom Scroll-Verhalten der Nutzer*innen resultiert dies in signifikanten Einsparungen an geladenen Daten.
Bilder des initialen Viewports werden “lazy” geladen. Anstelle von nativen Lazy Loading-Attributen wird eine Javascript-Library verwendet.
Bilder „above the fold” sollten nicht lazy loaded werden, da dadurch die Darstellung verzögert wird. Nutzen Sie die nativen Lazy Loading Methode via loading="lazy", decoding="async" und fetchpriority="low", um dem Browser noch mehr Anweisungen zu geben, sich erst später um entsprechende Bilder zu kümmern. Dadurch können Sie auch auf das Laden der zusätzlichen Javascript-Datei (vanilla-lazyload.js) verzichten.
kritisch
Preloading priorisiert das Laden von Bildern, die sofort beim Seitenaufruf sichtbar sind und verbessert so die initiale Ladezeit. Für Bilder, die erst beim Herunterscrollen sichtbar werden, empfiehlt sich das Prefetching, um dem Browser frühzeitig zu signalisieren, welche Bilder später benötigt werden. Dies steigert die Effizienz des Ladeprozesses, ohne den initialen Seitenaufbau zu beeinträchtigen.
Bilder außerhalb des initialen Viewports werden nicht prefetched oder preloaded.
Priorisieren Sie Bilder „above the fold“ durch Preloading (rel="preload" as="image"). Verwenden Sie die Anweisung rel="prefetch" as="image", um dem Browser frühzeitig zu signalisieren, welche Bilder vermutlich später benötigt werden, die jedoch nicht kritisch für den initialen Seitenaufbau sind („below the fold“) und zu denen bald gescrollt wird.
kritisch
Responsive Web Design passt Ihre Website flexibel an verschiedene Bildschirmgrößen an und verwendet optimierte Bildvarianten für die jeweiligen Darstellungsgrößen. Dies verbessert die Ladezeiten und die User Experience, indem es den Datenverbrauch reduziert und somit auch die CO₂-Emissionen verringert.
Einige Bilder sind Hintergrundbilder eingebunden und erlauben somit kein responsives Laden anhand der Viewport-Größe.
Es werden <picture>-Elemente mit einer exzessiven Deklaration von <source>-Knoten ohne srcset und sizes verwendet.
Nutzen Sie das <img> Elementes in Kombination mit den srcset und sizes Attributen anstatt des sehr starren <picture> Elements mit fest definierten Bildern pro Breakpoint. Eine große Auswahl an Bildgrößen im srcset und genaue und korrekte Angaben im sizes Attribut geben dem Browser die meiste Flexibilität immer das für Viewport und Pixeldichte optimalste Bild auszuliefern. Das Ausliefern von WebP- anstatt JPG-Dateien sollte auf Server-Ebene passieren und muss nicht zusätzlich den HTML Code vergrößern. Sollten Sie an einer Stelle wirklich auf einem speziellen Viewport ein anderes Bildformat (Hochformat/Querformat) ausliefern wollen, sollten Sie dort das <picture> Element mit verschiedenen <source> Elementen inklusive srcset und sizes verwenden.
Bilder nur per CSS als Hintergrundbilder einzubinden und somit das gleiche Bild auf allen Viewports und Geräten auszuliefern ist ein No-go (unnötige Datentlast).
optimierbar
SVGs sind vektorbasierte Grafiken, die ideal für Logos und Icons geeignet sind, da sie ohne Qualitätsverlust skalierbar sind. Sie beschleunigen die Ladezeiten, reduzieren den Datenverbrauch und verbessern dadurch die Performance Ihrer Website.
Das Logo wird als Rastergrafik ausgeliefert. Es scheint zweifelhaft, ob der per CSS geladene Icon-Font “swiper icons” verwendet wird.
Überprüfen Sie, ob einfache Grafiken wie zum Beispiel Logos als SVG-Dateien verfügbar sind und verwenden Sie diese anstelle von Rastergrafiken wie JPG oder PNG. Zudem sollten Sie prüfen, ob die per CSS eingebundene Icon Font „swiper-icons“ tatsächlich verwendet wird.
optimierbar
SVG Sprites bündeln mehrere SVG-Grafiken in einer einzigen Datei, wodurch die Anzahl der HTTP-Anfragen reduziert wird. Dies verbessert die Ladezeiten, da der Browser weniger Ressourcen laden muss. Die Verwendung von SVG Sprites ist effizient für die Darstellung wiederkehrender grafischer Elemente auf Ihrer Website und steigert somit die Gesamtperformance.
SVG Icons wie die Social Media Icons des Footer werden inline in Seiten eingebettet, anstatt sie in ein Spritesheet auszulagern..
Überprüfen Sie, ob es SVG-Icons gibt, die auf jeder Seite verwendet werden, wie zum Beispiel die Social-Media-Icons im Footer. Diese wären in einem SVG-Sprite möglicherweise effizienter organisiert als inline im Code. Auf einigen Unterseiten wird bereits ein SVG-Sprite verwendet. Es wäre sinnvoll, diesen Ansatz konsistent auf allen Seiten umzusetzen.
vorbildlich
Optimierte SVG-Dateien reduzieren die Dateigröße und benötigen weniger Bandbreite, was die Ladezeiten Ihrer Website verbessert.
Keine Auffälligkeiten.
optimierbar
Inline SVGs laden schneller, weil sie ohne zusätzliche Serveranfragen auskommen. Externe SVGs, die separat vom HTML geladen werden, sind wiederverwendbar über verschiedene Seiten hinweg, erfordern jedoch jeweils eine Serveranfrage. Für häufig wiederkehrende Grafiken innerhalb einer Seite können auch Inline SVGs effizient wiederverwendet werden. Die optimale Wahl hängt von der spezifischen Struktur und den Anforderungen der Website ab. Generell sind SVGs bandbreitenschonend und verbessern die Performance der Website.
Identische SVG-Icons sind mehrfach inline in Seiten eingebettet.
Sie sollten Icons, die mehrfach auf derselben Seite erscheinen, wie zum Beispiel die Striche unter „Mehr lesen” Links, nur einmal als Inline-SVG in Form eines <symbol> Elements einbinden. Alle weiteren Instanzen des Icons können dann durch das <use> Element auf dieses SVG verweisen. Dies reduziert die Redundanz und verbessert die Ladezeiten Ihrer Seite.
optimierbar
Die Bereitstellung von Alternativinhalten als Fallback für Videos verbessert die Zugänglichkeit der Website, indem Nutzer*innen mit eingeschränkter Bandbreite oder inkompatiblen Geräten Texte oder Bilder angezeigt werden. Dies stellt sicher, dass alle Besucher*innen relevante Informationen erhalten, auch wenn Videos nicht geladen werden können. Gleichzeitig optimiert es die Performance der Website und minimiert unnötigen Datenverkehr.
Fallback-Bilder bzw. Preview-Bilder von Videos werden als Hintergrundbild und damit nicht-responsiv eingebunden.
Binden Sie das Fallback-Bild für das Video nicht als Hintergrundbild, sondern als reguläres <img>-Element ein. Versehen Sie das Bild mit einem alt-Attribut sowie srcset und sizes-Attributen, um die Zugänglichkeit und Responsivität zu verbessern. Fügen Sie zudem ein <button>-Element mit beschreibendem Text hinzu, um das Video zu laden.
vorbildlich
Gezielt eingesetzte Videos steigern das Engagement. Wählen Sie Dauer und Auflösung passend zur Zielsetzung, um unnötig hohen Datenverbrauch und Energiebedarf zu vermeiden.
Keine Auffälligkeiten.
vorbildlich
Die Auflösung ist neben der Länge ein entscheidender Faktor für den Datenverbrauch. Es gilt, das passende Maß zwischen 4K und niedrigeren Auflösungen zu finden, um den Datenverbrauch zu optimieren.
Keine Auffälligkeiten.
vorbildlich
Autoplay von Videos startet diese automatisch, was die Aufmerksamkeit erhöht, aber auch Datenverbrauch und Ladezeiten steigert. Dies erhöht CO2-Emissionen. Ein bedachter Einsatz kann die Umweltbelastung signifikant verbessern.
Keine Auffälligkeiten.
vorbildlich
Integrationen von Drittanbieter*innen erhöhen schnell den funktionalen Mehrwert einer Website, führen jedoch oft zu höherem Datenverbrauch. Dies kann die Ladezeiten verlängern und die CO2-Emissionen erhöhen.
Keine Auffälligkeiten.
vorbildlich
Kürzere Videos reduzieren die Ladezeiten und den Datenverbrauch, was die Performance der Website verbessert. Bestimmen Sie passend zum Inhalt und Kontext die Länge ihrer Videos.
Keine Auffälligkeiten.
vorbildlich
Moderne Videoformate wie H.264 und VP9 bieten effiziente Kompression bei hoher Qualität. Die richtige Wahl dieser Formate reduziert Datenmengen und Ladezeiten, was die Performance verbessert und die Umweltfreundlichkeit Ihrer Website steigert.
Keine Auffälligkeiten.
kritisch
Das Preloading von Schriftarten beschleunigt die Darstellung von Text auf Ihrer Website, indem die benötigten Fonts früher im Ladevorgang geladen werden. Diese Technik verbessert die sichtbare Ladezeit, indem sie sicherstellt, dass Textinhalte sofort in der gewünschten Schriftart angezeigt werden, was die User Experience erheblich steigert.
Es wird kein Font-Preloading verwendet.
Achten Sie auf das Preloading von Schriften, die für den initialen Seitenaufbau kritisch sind, um die Ladezeiten zu verkürzen und die Performance zu optimieren. Dies verbessert nicht nur die visuelle Darstellung der Seite, sondern verhindert auch ein FOUT (Flash of Unstyled Text).
vorbildlich
Das Laden von Schriften von externen Quellen kann die Ladezeiten Ihrer Website verlängern, da zusätzliche Anfragen an externe Server erforderlich sind. Dies erhöht die Abhängigkeit von externen Diensten und kann zu Verzögerungen führen, besonders wenn diese Server langsam reagieren oder ausfallen.
Keine Auffälligkeiten.
kritisch
Custom Fonts zahlen auf die Wiedererkennung einer Marke ein und individualisieren das Design. Die richtige Strategie zum Laden der Fonts ist hier entscheidend. Schriften erst bei Bedarf zu laden, verbessert die Ladezeiten und verringert die Datenmenge beim Erstbesuch.
Das Laden der Seite wird durch fehlende CSS-Attribute an font-faces verzögert.
Binden Sie Ihre Schriften im CSS mit der Anweisung font-display: swap im @font-face-Block ein, um das Laden der Seite durch das Nachladen der Schriften nicht zu verzögern.
kritisch
Subsetting reduziert die Größe von Schriftdateien, indem nur Zeichen, die auf der Website verwendet werden, eingebunden sind.
Font-Subsetting scheint nicht verwendet zu werden.
Wenn Sie bestimmte Zeichen, wie solche für nicht genutzte Sprachen, nicht benötigen, entfernen Sie diese aus den Schriftdateien, um Datenvolumen zu sparen.
optimierbar
Wählen Sie bewusst die Anzahl der Schriftarten und Stile, da sie eine Auswirkung auf den Ressourcenbedarf Ihrer Website haben.
Die via CSS geladenen Schriftschnitte Roboto Slab Thin, Light, Regular und Bold werden auf den getesteten Seiten nicht verwendet.
Überprüfen Sie, ob alle eingebundenen Schriftschnitte tatsächlich verwendet werden oder vom Design her notwendig sind. Zum Beispiel könnten Roboto Slab Thin und Light optisch fast identisch sein. Lesen Sie auch den Punkt „Variable Fonts” für eine bessere Lösung.
kritisch
Variable Fonts erlauben mehrere Variationen einer Schriftart in einer Datei, was die Ladezeiten reduziert und die Flexibilität erhöht.
Roboto Slab ist nicht als Variable Font eingebunden.
Um Datenvolumen zu sparen und die gestalterische Flexibilität zu erhöhen, sollten Sie die verschiedenen Schriftschnitte der Roboto Slab durch den variablen Font Roboto Slab ersetzen.
optimierbar
WOFF (Web Open Font Format) ist speziell für den Webeinsatz optimiert und bietet eine hohe Kompressionsrate, die schnelle Ladezeiten ermöglicht. Es ist dem TTF-Format vorzuziehen, da WOFF die Bandbreitennutzung reduziert und die Textdarstellung auf Ihrer Website beschleunigt.
Bis auf eine Ausnahme werden keine WOFF2-Schriften verwendet.
Überprüfen Sie, ob die von Ihnen genutzten Schriften auch im WOFF2-Format verfügbar sind, und verwenden Sie dieses Format anstelle der WOFF-Dateien, um Ladezeiten zu optimieren.
kritisch
Die Optimierung der Größe von Skript-Bundles ist entscheidend für schnelle Ladezeiten. Durch Minimierung und effiziente Aufteilung der Skripte in kleinere, bedarfsorientierte Pakete werden nur notwendige Ressourcen geladen. Dies verbessert die Ladezeiten und die Performance der Website erheblich.
Die main.js Ihrer Website ist mit 311kB auffällig groß. Dies kann darauf hindeuten, dass Bestandteile in separaten Chunks sinnvoller organisiert wären.
Die main.js Ihrer Website ist mit 311kB auffällig groß. Teilen Sie main.js in mehrere Bundles auf und laden Sie auf jeder Seite nur die Bundles, die auf ihr benötigt werden.
kritisch
Chunking teilt große Ressourcen in kleinere Pakete, beschleunigt die initiale Ladezeit und verbessert die allgemeine Performance Ihrer Website.
Javascript-Code wurde zwar in einzelne Files aufgeteilt, es werden aber auf allen Seiten jeweils alle Skripte geladen, anstatt selektiv z.b. via dynamischer Imports nur die auf der jeweiligen Seite benötigten Inhalte nachzuladen.
Der Javascript-Code Ihrer Applikation ist zwar auf mehrere Dateien aufgeteilt, jedoch lädt abgesehen vom implementierten Lazy Loading für z.B. den YouTube-Player jede getestete Seite alle Javascript-Bundles. Zudem enthält die auf allen Seiten geladene main.js externe Libraries wie z.B. Mabbox, obwohl sie nicht auf allen Seiten benötigt werden.
Teilen Sie Ihren Code so in Bundles auf, dass auf den jeweiligen Seiten nur der Code geladen wird, der auf dieser Seite auch benötigt wird. Die immer initial geladene Datenmenge der Javascript-Chunks wird hierdurch reduziert.
kritisch
Große Abhängigkeiten verlangsamen die Ladezeiten. Durch die Optimierung der Bibliotheksgrößen verbessern Sie die Performance der Website erheblich.
In Ihrer main.js ist Mapbox enthalten, obwohl keine Maps verwendet werden.
Prüfen Sie die in main.js gebundeltete Mapbox-Library auf Ihre Notwendigkeit. Auf keiner der getesteten Seiten war eine dynamische Karte integriert. Sollten Mapbox-Features abseits von Kartendarstellungen benötigt werden ist z.B. ggf. ein direkter API-Aufruf ohne die aktuell verwendete Library möglich.
vorbildlich
Mit Lazy Loading Skripte werden JavaScript-Ressourcen erst geladen, wenn sie benötigt werden. Die initiale Ladezeit wird damit verkürzt und die Website-Performance verbessert.
Keine Auffälligkeiten.
optimierbar
Die Minifizierung von Skripten entfernt überflüssige Zeichen aus JavaScript-Dateien, was die Dateigröße reduziert und die Ladezeiten verkürzt. Diese Praxis optimiert die Ausführungszeit und verbessert die Gesamtperformance der Website, indem sie die Zeit minimiert, die benötigt wird, um Skripte herunterzuladen und zu verarbeiten.
Der Applikations-Code der geladenen Javascript-Bundles sind nicht vollständig minified.
Die Dateigröße kann durch weiteres Minifiying weiter optimiert werden. Der gesamte Javascript-Code sollte während des Build-Prozess minified werden, um die Dateigröße der erzeugten Chunks zu reduzieren.
optimierbar
Beim Tree Shaking wird ungenutzter Code aus JavaScript-Bundles entfernt. Dies erhöht die Performance und führt zu kleineren Dateigrößen und schnelleren Ladezeiten.
Die main.js Ihrer Website ist mit 311kB auffällig groß. Dies kann darauf hindeuten, dass Libraries ohne Tree-Shaking gebundelt wurde.
Prüfen Sie, ob die gebundelten Dependencies weiterhin benötigt werden und dass Sie verwendete Libraries wie lodash nicht in Gänze importieren, sondern lediglich die Fragmente, die in Ihrem Applikations-Code verwendet werden.
optimierbar
Die Optimierung der Bundle-Größen für CSS verbessert die Ladezeiten, indem nur notwendiger Code geladen wird. Kleine und effiziente CSS-Bundles reduzieren die Übertragung unnötiger Daten und beschleunigen das Rendering der Seiteninhalte. Dies minimiert den Gesamtdatenverkehr und steigert die Servereffizienz.
Einige CSS-Files werden nicht auf allen Seiten verwendet.
Obwohl keine Ihrer CSS-Dateien besonders groß ist: überprüfen Sie bitte, ob alle geladenen CSS-Dateien auf jeder Seite wirklich benötigt werden. Laden Sie gegebenenfalls nur die Dateien, die die erforderlichen CSS-Anweisungen enthalten.
vorbildlich
Ein komplexer DOM verlangsamt das Rendering Ihrer Website. Vereinfachen Sie die Struktur, um schnellere Ladezeiten und eine höhere Interaktivität zu erreichen.
Keine Auffälligkeiten.
kritisch
Minifizieren von HTML und CSS entfernt überflüssige Daten wie Kommentare und Leerzeichen, wodurch die Dateigröße reduziert und die Ladezeit der Webseite verbessert wird. Diese Optimierung macht den Datenverkehr effizienter und reduziert die CO2-Emissionen.
Der CSS-Code Ihrer Website wurde zum Teil minified, der HTML-Code gar nicht.
Sowohl HTML als auch CSS-Code sollte im Rahmen des Build-Prozesses minified werden.
vorbildlich
Asynchrones Laden von Tracking-Skripten verbessert die Ladezeiten, indem es die Ausführung bis nach dem Laden der wesentlichen Inhalte verzögert. Diese Methode stellt sicher, dass die initiale Ladezeit nicht beeinträchtigt wird, was die allgemeine Performance der Website optimiert.
Keine Auffälligkeiten.
vorbildlich
Übermäßiger Einsatz von Tracking-Skripten beeinträchtigt die Ladezeiten Ihrer Website signifikant. Eine Reduzierung und Optimierung dieser Skripte verbessert nicht nur die Performance, sondern steigert auch die User Experience durch schnellere Seitenreaktionen deutlich.
Keine Auffälligkeiten.
kritisch
Privacy-friendly Provider legen großen Wert auf den Schutz der Nutzer*innendaten und bieten datenschutzkonforme Lösungen an. Der Einsatz solcher Dienste verbessert das Vertrauen der Nutzer*innen und stärkt die Einhaltung von Datenschutzbestimmungen.
Sie verwenden Google Analytics.
Prüfen Sie, ob Sie anstelle von Google Analytics privacy-friendly Provider wie Fathom oder Plausible integrieren können.
kritisch
Integriertes Tracking erfasst Nutzer*innendaten zur Analyse des Verhaltens auf der Website, wird jedoch die Ladezeiten und Performance beeinträchtigen. Eine sorgfältige und sparsame Implementierung dieser Skripte ist entscheidend, um die User Experience nicht negativ zu beeinflussen.
Ihre Applikation verwendet ein Besucher-Tracking.
Prüfen Sie, ob Sie in Gänze auf die Verwendung eines Trackings verzichten können.
vorbildlich
Das Laden von Skripten erst nach Einholung der Nutzer*inneneinwilligung verbessert die initiale Ladezeit der Website, da unnötige Skripte nicht sofort ausgeführt werden. Diese Praxis hält Datenschutzstandards ein und stärkt das Vertrauen der Nutzer*innen.
Keine Auffälligkeiten.
optimierbar
Ein Content Delivery Network (CDN) ist ein Netzwerk aus vielen weltweit verteilten Servern, die dazu dienen, Inhalte einer Website näher an die geografische Position der Nutzer*in zu bringen. Indem Kopien der Inhalte auf verschiedenen Servern gespeichert werden, können diese schneller zu den Endnutzer*innen gelangen. Dies verkürzt die Ladezeiten der Website erheblich, da Daten über kürzere Distanzen übertragen werden müssen. Gleichzeitig reduziert dies den Bedarf an Bandbreite und Energieverbrauch, was den CO₂-Ausstoß verringert und so die Umweltbelastung durch den Betrieb der Website minimiert.
Ihre Website verwendet kein Content Delivery Network (CDN).
Durch das deutsche Zielpublikum fallen die Vorteile eines CDNs im Vergleich zu einer Website mit internationalem Zielpublikum weniger stark ins Gewicht. Dennoch wird durch das Caching von Seiten in CDN-Edges in der Nähe des Nutzenden die Datenmenge reduziert, die über weite Entfernungen übermittelt werden muss. Für Seitenaufrufe von Endgeräten fällt hierdurch für einen großen Teil der Anfragen lediglich Traffic zwischen dem Endnutzer und CDN Edge-Caches an. Zudem optimieren viele CDN-Dienste die Datenrouten für eine schnellere Auslieferung. Bei der Auswahl eines CDN sollten Sie ein Green CDN wählen, da es erneuerbare Energiequellen nutzt, um den ökologischen Fußabdruck des Datenverkehrs Ihrer Website zu minimieren.
optimierbar
Effizientes Downstream Caching reduziert die zu ladenden Datenmengen für wiederkehrende Besucher*innen und erhöht die Verfügbarkeit Ihrer Website. Dies verbessert die Zugriffsgeschwindigkeit und die User Experience durch schnellere Seitenaufrufe.
Die Server Response-Header verhindern ein effizientes Caching im Browser. Z.B. dürfen Javascript und CSS-Ressourcen für lediglich 30 Tage gecached werden.
Prüfen Sie die Cache TTL / maxage für Webfonts, Javascript und CSS-Resourcen. Diese Ressourcen sollten mit einer hohen TTL wie z.B. 1 Jahr und zusätzlich via Cache-Control Header als „immutable” ausgewiesen werden. Build-Artefakte wie CSS oder JS-Dateien müssen dabei wie bei modernen Bundlern üblich ggf. mit einzigartigen Hashes im Dateinahmen ausgezeichnet werden.
vorbildlich
Green Hosting nutzt umweltfreundliche Technologien und bezieht Energie aus erneuerbaren Quellen, um den Betrieb von Websites nachhaltiger zu gestalten. Dieses Hosting reduziert den ökologischen Fußabdruck einer Website, indem es den Energieverbrauch minimiert und zur Reduzierung der Umweltbelastung beiträgt.
Keine Auffälligkeiten.
optimierbar
Effizient gestaltete Response-Header optimieren das Caching und verkürzen die Serverantwortzeiten.
Es wird ein nicht benötigter Response-Header X-Powered-By gesetzt.
Vermeiden Sie nicht benötigte Response-Header wie X-Powered-By. Auch wenn die durch sie entstehende Datenmenge auf den ersten Blick gering erscheinen mag, erzeugen sie in jeder einzelne Response Ihrer Server einen sich kontinuierlich aufsummierenden Overhead an übertragenen Daten. Zudem können Header Informationen zum verwendeten Stack preisgeben, die unter Umständen ein Sicherheitsrisiko darstellen.
optimierbar
Komprimierte Server-Antworten verringern die zu übertragende Datenmenge, was das Laden Ihrer Website beschleunigt.
Der Webserver unterstützt zwar gzip zur Komprimierung von Responses, nicht aber Brotli.
Ihre Server-Responses werden für nicht ohnehin bereits komprimierte Ressourcen mit gzip komprimiert. Verwenden Sie für die Komprimierung von Server-Responses anstelle von gzip Brotli, in sofern Sie nicht auf die Verwendung von stark veralteten Browsern angewiesen sind. Brotli erzielt je nach Datei eine >20% bessere Komprimierung.
Folgende Seiten wurden für den Audit analysiert:
Mit Hilfe dieser Übersicht können Sie auf einen Blick sehen, welchen Impact und Aufwand die einzelnen Prüfungsfelder haben. Per Klick können Sie zudem die Reihenfolge der beiden Dimensionen auf- und absteigend sortieren.
