Futurezone.at Relaunch im Performance-Test

Futurezone Relaunch im Performance-Test

Mitte JĂ€nner 2020 hat „Futurezone“ die Website in neuem Look prĂ€sentiert. Schöne Sache. Aber wie sieht es eigentlich aus technischer der Perspektive – mit der Website-Performance – aus? Das ist eines meiner Lieblingsthemen & aus Interesse habe ich einige Tests durchgefĂŒhrt und teile gerne meine Erkenntnisse.

Konkret geht es mir um einen Teilbereich der Benutzererfahrung (UX): Ladezeiten. Nicht gemeint ist, wie sich die Website generell bedient, sondern wie schnell die Website visualisiert & bedienbar ist. Ein feiner Unterschied: wir sprechen von der Zeitspanne zwischen dem Moment des Klicks auf den Link zur Website bis zu dem Zeitpunkt bis die Website interaktiv/bedienbar ist (und Schritte dazwischen).

ACHTUNG:
Dieser Artikel setzt zu einem gewissen Grad technisches Knowhow voraus. Falls du gar keine BerĂŒhrung mit dem Thema Webperformance hattest oder dir z.B. englische Begriffe wie „font“, „rendern“, „layout“ & „caching“ gar nichts sagen, wirst du dir womöglich schwertun und eventuell wenig mitnehmen. Ich bemĂŒhe mich dementsprechend weiterfĂŒhrende Literatur an den richtigen Stellen zu verlinken, die man nachlesen kann.

Disclaimer:
Viele Bereiche sind „sauber“ umgesetzt und auch viele Einzel-Tests wurden bestanden. Zum Zeitpunkt des Schreibens des Artikels sind es 15 bestandene PrĂŒfungen bei Google’s PageSpeed Insights. Diskutiert werden aber primĂ€r das Verbesserungspotential und einige dazugehörige Konzepte, daher liegt der Fokus auch auf den nicht bestandenen PrĂŒfungen.

Inhalt:

1. Test-Szenario – Wie testet man richtig?

Um einen Überblick zu bekommen habe ich die wichtigste Seite mit 2 unter­schiedlichen Tools getestet: die Startseite. Sinnvoller­weise testet man auch andere kritische Seiten: Das können Produkt-Seiten, Landingpages oder einzelnen Schritte eines Verkaufs-Funnels sein. Das wĂŒrde aber den Rahmen dieses Artikels sprengen.

Folgende 2 Test-Tools verwende ich in diesem Fall:

1.1. Drei Annahmen, die ich getroffen habe 



 natĂŒrlich kann ich auch daneben liegen.

  • Annahme 1: Die wichtigste Seite ist die Startseite.
  • Annahme 2: Die Zielgruppe ist hauptsĂ€chlich in Österreich bzw. im deutschsprachigen Raum.
  • Annahme 3: Traffic ist das wichtigste Gut (eine Einnahme-Quelle ist angezeigte Werbung).

Frage: Ist der Server-Standort fĂŒr Geschwindigkeit eigentlich relevant?

Üblicherweise ist das ein sehr wichtiger Punkt und ĂŒber zwei Fragen sollte man nachdenken:

  • Wo lebt meine Zielgruppe?
  • Und wo ist daher ein strategisch gĂŒnstiger Server-Standort fĂŒr meine Webseite?

In diesem Fall wird nach kurzer Recherche klar, dass ein CDN (Cloudflare) im Einsatz ist und ich nehme an, dass der eigentliche Serverstandort in Wien ist. Mit „CDN“ bezeichnet man ein welt­weites Server-Netzwerk, das gleiche Inhalte ausliefert. Cloudflare ist ein Dienstleister mit eben dem diese weltweite Infrastruktur zur VerfĂŒgung steht. Somit werden Teile der Website ausgelagert bzw. verteilt. Sinnvoll ist das fĂŒr Dinge, die sich nicht Ă€ndern (statische Ressourcen), wie Bilder. Ein Nachteil kann sein, dass der dynamische Teil einer Website (der Content) geringfĂŒgig lĂ€nger braucht, da quasi der Server des CDN-Anbieters noch dazwischen hĂ€ngt und vereinfacht die „Vermittlungszentrale fĂŒr Daten“ reprĂ€sentiert.

HĂ€h? Was heißt das jetzt fĂŒr unsere Tests?

Tja, eigentlich „nicht viel“. Futurezone hat sein Zielpublikum im deutschsprachigen Raum und – ich nehme an – ob die Website in Melbourne (AUS) genauso schnell lĂ€dt, ist nicht wichtig. (TatsĂ€chlich lĂ€dt sie lt. WebPageTest fast 3-mal so langsam in Melbourne, aber ja 
 „who cares?“, nicht wahr?).

Bei Google PageSpeed Insights teste ich auf meinem eigenen Computer & fĂŒr WebPageTest habe ich mich entschieden ĂŒber Frankfurt zu testen. Cloudflare hat in Frankfurt einen Server, insofern fĂŒhlt sich die Entscheidung fair an. (Durch die geografische NĂ€he kann man auch fĂŒr Prag argumentieren, wo nebenbei gesagt auch ein Cloudflare-Server steht.)

1.2. Tool #1: Google PageSpeed Insights

Hier ist am wenigsten zu konfigurieren. Man fĂŒgt die URL in das Feld ein, klickt Analysieren und wartet auf das Ergebnis. Die Tests laufen mehr oder weniger im Browser ab und die darunterliegende Test-Engine ist Lighthouse. Lighthouse kann auch andere Tests durchfĂŒhren, bloß liegt bei PageSpeed Insights der Fokus auf dem Performance-Teil. Möchte man auch andere Bereiche (Best Practices, technisches SEO, Barrierefreiheit, PWA) testen, geht das ĂŒber ein Web UI unter web.dev/measure.

Bei PageSpeed Insights kann man nichts viel falsch machen: URL eingeben; Analysieren klicken

Pro-Tipp: FĂŒhre die Tests in einem privaten Browser Fenster durch, damit Browser-Plugins deaktiviert bleiben. Zum Zeitpunkt des Schreibens des Artikels laufen Teile der Tests von PageSpeed Insights in deinem Browser, nicht auf einer externen Infrastruktur wie andere Test-Services – das ist aber geplant.

Nerd-Fact: Lighthouse drosselt die Internetverbindung auf ein „langsames 4G“, was ungefĂ€hr die Unteren 25 % der 4G-Verbindungen und die oberen 25 % der 3G-Verbindungen entspricht. ZusĂ€tzlich wendet Lighthouse eine CPU-Drosselung an, um ein mobiles GerĂ€t der Mittelklasse zu emulieren, auch wenn es auf einer weitaus leistungsfĂ€higeren Desktop-Hardware lĂ€uft. Quelle

1.3. Tool #2: WebPageTest

Um vergleichbare Testergebnisse liefern zu können verwenden wir die Option „3G Fast“, wenn es um Geschwindig­keits­drosselung geht. „3G Fast“ entspricht exakt der Grund­einstellung von PageSpeed Insights/Lighthouse. Quelle

Unsere Grund-Einstellungen auf webpagetest.org
Detail-Konfiguration im „Chromium Tab“

Um vergleichbare Bedingungen zu schaffen, wÀhlen wir folgende Konfiguration:

  • Als Test-Server wĂ€hlen wir Frankfurt. Frankfurt sollte fĂŒr unseren Use-Case wie oben beschrieben eine faire Wahl sein.
  • Bei der Verbindung „3G Fast“. „3G Fast“ entspricht exakt der Grundeinstellung von PageSpeed Insights/Lighthouse. Quelle
  • Wir fĂŒhren 3 Tests durch: simuliert wird jeweils der allererste Besuch und ein 2. Besuch (dabei sind Ressourcen teilweise gecacht – das wird spĂ€ter fĂŒr die Caching-Strategie interessant)
  • Im „Chromium“ Tab wird ein Ă€lteres/durchschnittliches Smartphone emuliert, das 2016 auf den Markt gekommen ist.
  • Außerdem wollen wir, dass ebenso ein Lighthouse Test durchgefĂŒhrt wird und setzen dementsprechend das Hakerl.

2. Ergebnisse im Überblick

Nun haben wir zwei Ergebnisse vor uns. Wie können wir das Ergebnis lesen? Und was können wir vor allem verbessern? Ersteres folgt, letzteres diskutiere ich im nÀchsten Kapitel.

2.1. Ergebnis: PageSpeed Insights

Getestet in Wien, 22.01.2020

Wie ĂŒblich fokussieren wir uns nur auf den mobilen Teil. Mobile-First ist nicht nur ein theoretisches Konzept, tatsĂ€chlich sind die meisten Internetnutzer „mobile first“. Ob eine Seite unter guten Bedingungen zu Hause am Desktop-Computer lĂ€uft, ist nebensĂ€chlich. Falls diese mobil schnell lĂ€dt, ist das in den meisten FĂ€llen am Desktop-Computer noch besser.

PageSpeed Insights Ergebnis der Startseite

Bei wiederholten Tests pendeln wir uns ungefÀhr im Bereich zw. 30 und 40 ein.

„Um eine gute Benutzererfahrung zu bieten, sollten Websites eine ‚gute‘ Punktzahl (90-100) anstreben.“

Quelle: Lighthouse Performance Scoring

PageSpeed Insights – Details

Gleich unter der Punktezahl sieht man zwei Bereiche, die interessant sind:

Labdaten ist das Ergebnis eines simulierten Tests und Felddaten, wie der Name schon vermuten lĂ€sst, Ergebnisse, die aus Googles DatensĂ€tzen des „Berichts zur Nutzererfahrung in Chrome“ gezogen werden. „Diese Daten [Felddaten] stellen anonymisierte Leistungsdaten echter Nutzer auf verschiedenen GerĂ€ten und unter unterschiedlichen Netzwerkbedingungen dar. Labdaten basieren auf einem simulierten Seitenaufbau auf einem einzelnen GerĂ€t und unter festgelegten Netzwerkbedingungen“ Quelle.

Vereinfacht heißt das: Felddaten sind nĂ€her an der tatsĂ€chlichen Erfahrung der Website-Besucher.

Die wichtigsten Begriffe fĂŒr die Bewertung:

  • „First Contentful Paint“ (FCP): Diese Metrik misst die Zeit vom Beginn des Ladens der Seite bis zu dem Zeitpunkt, an dem ein Teil des Seiteninhalts auf dem Bildschirm gerendert wird.
    Um eine gute Benutzererfahrung zu bieten, sollten Websites einen FCP-Wert unter 1 Sekunde anstreben. Quelle
  • „First Input Delay“ (FID): Diese Metrik misst die Zeit von der ersten Interaktion eines Benutzers mit einer Seite bis zu dem Zeitpunkt, an dem der Browser tatsĂ€chlich in der Lage ist diese Interaktion zu verarbeiten.
    FĂŒr ein gutes Benutzererlebnis sollten Websites einen FID-Wert von weniger als 100 Millisekunden anstreben. Quelle
  • „Largest Contentful Paint“ (LCP): Diese Metrik gibt die Renderzeit des grĂ¶ĂŸten im sogenannten viewport (sichtbarer Bereich) Bildes oder Textblocks an.
    Um eine gute Benutzererfahrung zu bieten, sollten Websites auf einen LCP-Wert von weniger als 2,5 Sekunden hinarbeiten. Quelle
  • „Cumulative Layout Shift“ (CLS) misst die Gesamtsumme aller individuellen layout shift-Werte fĂŒr jede unerwartete Layout-Verschi­ebung (layout shift), die wĂ€hrend der gesamten Ladezeit der Seite auftritt. Eine Layout-Verschie­bung tritt immer dann auf, wenn ein sichtbares Element seine Position von einem Moment zum nĂ€chsten Ă€ndert.
    Um eine gute Benutzererfahrung zu bieten, sollten Websites einen CLS-Wert von weniger als 0,1 anstreben. Quelle

Nerd-Fact: LCP, FID & CLS gehören zu den sogenannten „Web Vitals“. Web Vitals als Überbegriff wurde im Mai 2020 eingefĂŒhrt.

PageSpeed Insights: Detailergebnis der Startseite
First Contentful Paint (FCP)Largest Contentful Paint (LCP)Cumulative Layout Shift (CLS)First Input Delay (FID)Total Blocking Time
Felddaten1,2s3,5s1,5700,032ms
Labdaten2,3s15,5s0,1031,200s
Ziel/Gute Werte≀ 1s≀ 2,5s≀ 0,100≀ 0,100ms≀ 0,300s
Lighthouse Ergebnis: Wichtige Metriken fĂŒr die Startseite. LCP, FID & CLS gehören zu den sogenannten „Web Vitals“.

Wie man dieses Ergebnis verbessern kann, erlÀutere ich anhand von verschie­denen Konzepten im 3. Kapitel.

Um diesen Test selbst durchzufĂŒhren kannst du folgendem Link folgen:

2.2. Ergebnis: WebPageTest

Getestet ĂŒber einen Server in Frankfurt, 22.01.2020

WebPageTest testet wesentlich mehr als nur Ladezeiten und dazugehörige Metriken. Es kann zugegeben auch etwas ĂŒberwĂ€ltigend sein, wenn man damit zum ersten Mal in BerĂŒhrung kommt.

Gemessen werden verschiedene Metriken wĂ€hrend der Simulation des ersten und zweiten Besuchs. ZusĂ€tzlich gibt es hilfreiche Tipps fĂŒr die Konfi­guration des Webservers. Aber auch wie viel Geld der Besuch deiner kostet verglichen mit dem monatlichen Durch­schnitts­einkommen (Super interessant fĂŒr Webseiten mit Zielgruppen in LĂ€ndern mit einer weniger kaufstarken Bevölkerung).

Internet-Daten in Österreich kosten wenig und, im Vergleich mit anderen LĂ€ndern, ist der Zugang sehr schnell – wir werden diesbezĂŒglich verwöhnt.

WebPageTest Ergebnis der Startseite
First Contentful Paint (FCP)Largest Contentful Paint (LCP)Cumulative Layout Shift (CLS)Total Blocking Time
Erster Besuch1,647s3,714s0,0≄ 0,658s
Wiederholter Besuch0,912s2,645s0,1≄ 0,816s
Ziel/Gute Werte≀ 1s≀ 2,500s≀ 0,1≀ 0,300s
WebPageTest: Einige wichtige Metriken fĂŒr die Startseite. LCP, FID & CLS gehören zu den sogenannten „Web Vitals“

Wie man dieses Ergebnis verbessern kann, diskutiere ich im nÀchsten Kapitel.

NatĂŒrlich kannst du die Tests selbst durchfĂŒhren und/oder folgenden Links zu den archivierten Ergebnissen folgen:

3. Ergebnisse diskutiert

Generell gelten folgende Faustregeln fĂŒr eine schnelle Website:

  • Je weniger Datenmenge man sendet, desto schneller wird deine Website geladen.
  • Je weniger einzelne Ressourcen/Dateien (z.B. Bilder, Fonts, CSS, JS) man sendet, desto schneller wird deine Website.
  • Sende deinem Besucher, falls möglich, nur das notwendigste an Daten, lade den Rest nach – implementiere „lazy-loading“ wo es möglich ist.
  • Optimiere den ersten Besuch deiner User. Implementiere eine vernĂŒnftige Caching-Strategie fĂŒr den zweiten Besuch.
  • Performance ist nicht nur Entwickler-Sache: Falls du ein Team fĂŒr Content-Kreation hast, vereinbare Regeln/Performance-Budgets.
  • Die Verbesserung einer Metrik kann eine andere verschlechtern. Teste IMMER deine Änderungen!

„Erster Besuch“ erklĂ€rt

Der erste Eindruck zÀhlt, auch beim Besuch einer Website. Folgende Dinge sind aus Performance-Perspektive wichtig:

  1. Inhalt sollte so schnell wie möglich dargestellt werden.
  2. Inhalte sollten sich wÀhrend der Ladezeit nicht verschieben (das erzeugt einen layout-shift).
  3. Deine Website sollte so schnell wie möglich interaktiv/bedienbar sein.

Um das zu erreichen, verfolgt man vereinfacht folgende Strategie: Lade nur das notwendigste zum Anzeigen, der Rest wird nachgeladen.

Treibt man das auf die Spitze, werden nur die Dinge geladen, die fĂŒr den ersten Bildausschnitt („Above the fold“) benötigt werden. Alles andere wird nachgeladen. In dem Zusammenhang liest man regelmĂ€ĂŸig das Schlagwort „critical“, sowohl wenn es um Laden von CSS, als auch z.B. im Bereich der Ladestrategie fĂŒr Schriftarten.

„Wiederholter Besuch“ erklĂ€rt

Hier entscheidet deine Caching-Strategie.

Generell wird empfohlen alle statischen Inhalte so „aggressiv“ wie möglich zu cachen. Wer nicht weiß, was das ist: Caching bezeichnet man das Zwischen­speichern von Inhalten im Browser fĂŒr einen bestimmten Zeitraum. Ein wiederkehrender Besucher muss daher nicht immer alle Inhalte neu herunterladen.

Die Strategie: eine Ressource, sei es ein Bild oder irgendeine Datei, die sich nicht Ă€ndert, sollte im Browser-Cache des Besuchers deiner Website möglichst lange gespeichert werden. Falls dieser Besucher nach mehreren Tagen wiederkommt – das sollte mMn. fĂŒr die meisten Betreiber ein generelles Ziel sein – und noch einmal die eingesetzten Schriften, gleichen Bilder etc. nicht im Browser-Cache sind, ist das eine verpasste Gelegenheit.

Typischerweise wird Caching bei Bildern, Schriften, JavaScript & CSS angewandt. Nicht fĂŒr Inhalte, die sich regelmĂ€ĂŸig Ă€ndern. Über die Server-Konfiguration setzt man die gewĂŒnschte Zeitspanne, wie lange jene Ressource gecacht werden soll. Das passiert per HTTP Header. Wie gesagt, ĂŒblicherweise macht man das möglichst aggressiv, sprich sehr lange. „Sehr lange“ heißt 1 Jahr.

OK – Aber was ist nun mit diesem „Caching“, wenn sich nun etwas Ă€ndert?

Ein kleiner Trick hilft: Man Ă€ndert den Dateinamen (das kann automatisiert passieren), verlinkt die neue Datei im Code und der Browser weiß Bescheid. Es gibt auch noch anderen Techniken, aber diese sprengend den Rahmen und scheinen bei Futurezone auch nicht zum Einsatz zu kommen.

Futurezone’s Ladestrategie fĂŒr Bilder

Wie man Bilder fĂŒrs Web aufbereitet ist ein wiederkehrendes Thema. Im Fall von Futurezone werden manchmal PNGs verwendet, obwohl JPEG die bessere Wahl ist. Beispielsweise wird ein Screenshot/Bildschirmfoto gemacht (der Standard Datentyp hierfĂŒr ist PNG) und unbearbeitet hochgeladen.

Eine Möglichkeit wĂ€re den Optimierungs­prozess fĂŒr Bilder zu automatisieren, einen manuellen Prozess zu etablieren oder mit einem „Performance-Budget“ zu arbeiten. Ein Budget, das festlegt, wie groß ein Bild in Pixel und die DateigrĂ¶ĂŸe sein darf.

Kein Lazy-loading Strategie: falscher Alarm?

Verwunderlich ist, dass die Empfehlung „Nicht sichtbare Bilder aufschieben“ angezeigt wird. Beim manuellen Testen sieht man, dass eine Lazy-loading-Strategie fĂŒr Bilder implementiert ist. D.h. Bilder werden nur geladen, falls diese am Bildschirm sind bzw. unmittelbar bevor diese vom Besucher gesehen werden. Das ist auch hier der Fall. Ich vermute, dass es sich hier um ein falsch-negatives Ergebnis handelt, da kein natives Lazy-loading im Einsatz ist – habe diese Annahme aber nicht getestet.

Futurezone’s Ladestrategie fĂŒr Schriften

Hier ist keine Ladestrategie zu erkennen. Auch stellt sich ab einer gewissen Menge an Traffic bzw. Besucherzahl die Frage, ob man nicht ĂŒberhaupt nur mit Systemfonts arbeiten sollte. So war es einige Zeit lang Best Practice bei großen Websites mit viel Traffic.

Falls man sich fĂŒr eigene Schriftarten entscheidet, sollte man diese zumindest im Lade­vorgang mit sogenannten Resource-Hints priorisieren.

Absolut notwendige Ressourcen wie Schriften können mit Resource-Hints priorisiert werden, um diese PrĂŒfung zu bestehen.

Eine weitere Möglichkeit ist Inhalte zwischenzeitlich mit dem Systemfont anzuzeigen, bevor diese vollstÀndig geladen sind. font-display macht letzteres vollautomatisch und ist 1 Zeile CSS-Code. Falls man mit dem Systemfont startet und der Browser, nach abgeschlossenem Laden, gegen den eigenen Font austauscht, entsteht FOUT und womöglich eine Layout-Verschiebung (layout shift).

Kein font-display in Verwendung. Bewusste Entscheidung gegen FOUT?

Falls du dich fĂŒr FOIT, FOUT, Font-Ladestrategien oder generell Web-Fonts interessiert, empfehle ich Zach Leatherman’s Blog. Hier finden sich wertvolle Ressourcen fĂŒr den Web-Font-Nerd.

Pro-Tipp: Resource-Hints zu kann man auch fĂŒr andere kritische Ressourcen verwenden, wie beispielsweise Stylesheets oder JavaScript. Wir nutzen diese Option um die „Verkettung kritischer Anfragen“, wie es bei PageSpeed Insights heißt, zu reduzieren.

DOM – KomplexitĂ€t des HTML-Codes

Kurz gesagt: Das HTML-Dokument hat einen hohen Grad an KomplexitĂ€t erreicht und laut Lighthouse-Test einen Schwellwert ĂŒberschritten.

Das ist normalerweise ein typisches Problem, das man von Layout-Builder-Websites kennt. Diese Website/Layout-Builder sind dafĂŒr berĂŒchtigt, da sie dem zwar Nutzer ultimative FlexibilitĂ€t verspricht; mit dem Haken, dass dabei im Hintergrund sehr komplexer/verschachtelter Code erzeugt wird. Bei einer maßgeschneiderten Lösung ist diese Meldung ungewöhnlich, aber da mir auch die KomplexitĂ€t der Informations­struktur nicht bekannt ist, ist es schwer sich ein Urteil zu erlauben und mögliche Verbesserungen aufzuzeigen.

ErwĂ€hnenswert ist, dass die gemessenen 1.663 Elemente nur knapp ĂŒber dem Test-Schwellwert von 1.500 Elementen liegen. Ich glaube, nicht dass hier noch eine signifikante Verbesserung der Renderzeiten zu erreichen ist.

Futurezone’s Caching Strategie

Im Fall von Futurezone ist die Caching-Strategie durchaus interessant:

  • JavaScript und CSS-Styles werden tatsĂ€chlich sehr lange gecacht – nĂ€mlich 365 Tage
  • Ungewöhnlich ist, dass bei Fonts 10 Jahre (315.360.000 Sekunden) festgelegt sind. Vermutlich handelt es sich um ein Fehler, da der Maximalwert von 1 Jahr damit ĂŒberschritten ist.
  • Ebenso ungewöhnlich ist die Strategie bezĂŒglich der Bilder, die 7 Tage gecacht werden
  • Was mich aber am meisten ĂŒberrascht hat; die Entscheidung jede Seite/Webpage (die ich ĂŒberprĂŒft habe) 30 Sekunden zu cachen. Üblicherweise möchte man dynamischen Content immer frisch vom Server. Den sehr kurzen Zeitraum kann man sich als Kompromisslösung verstehen. Ein Kompromiss zw. die globale CDN-Server zu nutzen und maximal 30 Sekunden alten Content liefern.

Nerd-Fact: Caching greift erst ab dem 2. Besuch. Es muss eine Ressource zuerst gecacht werden, um diese aus dem Cache zu laden.

CDN – Cloudflare

Caching und ein CDN gehen in dem Fall eine Symbiose ein: Ohne unter die Haube schauen zu können, nehme ich an, dass Cloudflare folgendermaßen konfiguriert ist:

  1. Liefere Bilder von einem getrennten Cloudflare-Server, der nicht der Web-Server ist.
  2. Behandle alles so wie es in den Caching Headern konfiguriert ist. „Respektiere Caching Header“ heißt diese Option. D.h. falls ein Bild beispielsweise 7 Tage gecacht werden soll, wird auch Cloudflare dieses Bild auf ihren Servern (weltweit) zwischenspeichern und 7 Tage fĂŒr Futurezone-Besucher bereitstellen.
Ungewöhnliche Caching Strategie fĂŒr Bilder: CDN im Einsatz, aber gespeichert wird nur 7 Tage.

Wie auf dem Screenshot auch zu sehen ist: FĂŒr Bilder wird – wie oben erwĂ€hnt – ein getrennter Server bzw. CDN (//image.futurezone.at) eingesetzt. Der Webserver, der die Seite liefert ist vermutlich ein physisch anderer Server. Die Belastung ist bei vielen Zugriffen somit quasi auf 2 Server verteilt. Ob diese Technik mit HTTP/2 noch immer von großer Relevanz ist, wĂ€re interessant zu testen.

Nerd-Fact: Die vorgestellte Maßnahme war in Zeiten von HTTP/1.1 viel im Einsatz und von großer Bedeutung, da ĂŒber HTTP/1.1 nur 6 Verbindungen parallel zu einem Server aufgebaut werden können. Somit werden auch nur höchstens 6 Bilder (oder 3 Bilder + 3 Schriftarten usw.) geladen. Erst mit HTTP2 wurde die Übertragung deutlich effizienter. Falls du dich fĂŒr Details zu HTTP/2 interessierst, empfehle ich die „EinfĂŒhrung zu HTTP/2“ von Google Fundamentals.

4. Fazit – „Wie schnell ist nun das Futurezone Redesign?“

Handelt es sich hier um eine super schnelle Website?
Laut den durchgefĂŒhrten Tests kann man objektiv sagen: Nein.
Das heißt aber nicht, dass sie nicht „schnell genug“ fĂŒr die Zielgruppe ist.

Geht die Welt jetzt unter?
NatĂŒrlich nicht. Wir leben diesbezĂŒglich in einem privilegierten Land. „Unser Internet“ ist schnell, unsere deutschen Kollegen haben diesbezĂŒglich weniger GlĂŒck.

Machen Ladezeiten einen Unterschied?
SelbstverstĂ€ndlich. Ausreichend Studien berichten ĂŒber mehr wiederkehrende Besucher, bessere organische Platzierungen, bessere Conversion-Raten was zur Folge hat, das auch Marketing-Kosten sinken. Man muss sich mit dem Thema etwas beschĂ€ftigen und findet ausreichend Vorteile.

Das Spannende daran: man kann immer etwas verbessern.

Performance als Unternehmensstrategie?
Ein hierzulande unterschÀtztes Thema ist Branding: Man sollte sich die Frage stellen, möchte man als modernes, web-affines Unternehmen wahrgenommen?
Und sollte man seinen Kunden, Usern, seiner Community nicht entgegenkommen? Sparsam mit deren Daten umgehen? Die bestmögliche User-Experience als Mission verfolgen?

Falls JA, dann ist eine schnelle Webseite kein nice-to-have, sondern ein Muss – und btw. der feine Unterschied am internationalen Markt.

Falls dir dieser Beitrag geholfen hat, dann teile ihn und wenn du zusĂ€tzliche Fragen hast, schreibe diese doch einfach in die Kommentare! Wir freuen uns ĂŒber Feedback.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.