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.

Das könnte Sie auch interessieren

Schreibe einen Kommentar

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