
Hinter den Kulissen
Lego und iPhone: Danach sucht die Kundschaft am häufigsten
von Manuel Wenk
Schnelle Webseiten-Ladezeiten sind wichtig. Wir wollen, dass du dich mit Lichtgeschwindigkeit im Digitec Galaxus Universum bewegst. Rage-Clicks oder Herzbarracken wegen langsamen Ladezeiten gehören definitiv der Vergangenheit an. Wir legen uns mächtig ins Zeug, damit wir in Zukunft zu den Online-Shops in Europa mit den schnellsten Ladezeiten gehören.
Der Mensch als komplexes Wesen ist als Produkt seines Genoms der Gleiche wie vor 10 000 Jahren. Seine Umwelt ist es nicht. Wir leben in einer voll digitalisierten Welt, in der wir keine Mammuts mehr jagen. Page Speed ist daher vor allem aus zwei Gründen wichtig:
Dazu ein Fun Fact: gemäss einer Studie ist die kognitive Belastung bei langsamen Ladezeiten für einen Menschen so stressig, dass er mit dem Anschauen eines Horror-Films verglichen werden kann. Gute Horror-Filme gibt es hier, aber nicht als Experience auf unserem Online-Shop.
Was bisher geschah: It's mobile, stupid!
Haben wir hier bei Digitec Galaxus also die Pfeile beiseitegelegt und aufgehört, haarige Zehn-Tönner zu jagen? Nicht ganz. Es gibt definitiv noch viel zu tun in Sachen Page Speed. Das hat auch damit zu tun, dass das Thema aus einer technischen Perspektive in den letzten Jahren stetig an Priorität gewonnen hat. Vor allem zwei Entwicklungen haben dazu stark beigetragen:
Die Ladezeit (Load) einer Webseite stellt gemäss dem RAIL-Modell von Google eine von vier relevanten Dimensionen für die Evaluation und Konzeption der wahrgenommenen Performance-Experience einer Webseite dar. Die drei anderen Dimensionen sind Responsiveness, Animation und Idle, welche als Ganzes die wahrgenommene Performance-Experience für dich als Kunde versuchen abzubilden.
Der isomorphe Frontend-Stack bringt Tempo
Es ist wichtig zu verstehen, dass die Ladezeit nicht einen einzigen Moment in einer Ladeanimation einer Webseite darstellt – sie ist viel mehr als eine ganzheitliche Experience im visuellen und interaktiven Aufbau einer Webseite zu verstehen. Daher kann sie auch nicht mit nur anhand einer Metrik gemessen werden. Um unsere Ladezeit optimal zu messen, halten wir uns an die Konzeption von Google und orientieren uns im Bereich "Load" des Rail-Modells an den "User Centric Performance Metrics". Die User Centric Performance Metrics beschreiben den kundenseitigen Erfolg als meilensteinbasierte Timing-Metriken, also in Sekunden.
Um Metriken zu definieren, ist es wichtig, das dahinterliegende Kundenbedürfnis zu kennen, damit genau dieses gemessen werden kann. Beim Laden einer Webseite verlangt ein Kunde vor allem bei drei Meilensteinen ein rasches Feedback, um die Experience mit der Webseite als positiv zu bewerten.
Meilenstein | Kundenbedürfnis |
---|---|
1 | Passiert etwas, nachdem ich eine Eingabe gemacht habe? Wurde die Navigation erfolgreich gestartet? Hat der Server geantwortet? |
2 | Ist es nützlich, was mir zuerst angezeigt wird? Also werden mir die wichtigsten Elemente einer Seite zuerst angezeigt? |
3 | Sind die angezeigten visuellen Elemente brauchbar? Kann ich mit ihnen interagieren? |
Mit dem Wechsel unseres Frontends auf einen isomorphen Frontend-Stack wird die Seite nicht mehr auf einmal auf dem Server gerendert, sondern progressiv beim Client. Somit haben wir neu die Möglichkeit, jedem Pixel auf der Webseite einen individuellen Wert zuzuordnen. Es ist einfach verständlich, dass wir visuelle Elemente im Viewport möglichst prioritär und schnell anzeigen wollen.
Um die Kundenbedürfnisse zu messen, resp. um zu verstehen, wann eine Webseite das visuelle Feedback in Form von gerenderten Elementen ausspielt, erweitern wir unsere Tabelle mit folgenden drei Metriken und deren Bedeutung:
Meilenstein | Metrik | Bedeutung | |
---|---|---|---|
1 | Passiert etwas? | First Contentful Paint | First Contentful Paint markiert den Zeitpunkt, wenn das erste Mal Text oder Bilder für den Benutzer sichtbar sind. |
2 | Ist es nützlich? | First Meaningful Paint | First Meaningful Paint (FMP) markiert den Zeitpunkt, wenn das/die wichtigsten Elemente der Seite für den Benutzer sichtbar sind. |
3 | Kann ich damit interagieren? | Time to Interactive & First Input Delay | Time to Interactive (TTI) markiert den Zeitpunkt, wenn die Anwendung sowohl visuell dargestellt als auch zuverlässig auf Benutzereingaben reagiert.
First Input Delay (FID) misst die Verzögerung, welche ein Kunde bei einer ersten Interaktion verspürt, wenn die Seite (oder gewisse Teile davon) noch nicht interaktiv ist. |
Die Metriken können in einer Zeitachse einer Ladeanimation einer Webseite wie folgt veranschaulicht werden:
Messwerte: Die Mischung macht's aus
Die Messung dieser Metriken können von zwei Datenquellen stammen: von realen Kundendaten und aus sogenannten synthetischen Messungen.
Reale Kundendaten, auch RUM (Real User Monitoring) genannt, greift dabei auf Daten zurück, welche von realen Kunden während dem Aufruf einer Seite erfolgen. Also von allen von euch, egal ob ihr neben einer 5G-Antenne seid oder im Tunnel in den Bergen auf unserem Online-Shop surft. Für uns ist dies die nackte Wahrheit und repräsentiert genau die Experience, welche ihr erlebt.
Synthetische Messungen repräsentieren dagegen Messungen, welche unter Simulationen stattfinden und so versuchen, die erlebte Kunden-Experience zu modellieren. Bekannte Tools dafür sind Lighthouse von Google oder WebPageTest.org. Mit verschiedenen Einstellungen können so Lade-Performances von Webseiten anhand Kriterien wie Device oder Netzwerkgeschwindigkeiten gemessen werden.
Um die Performance-Messungen in eine Relation setzen zu können, haben wir uns auf klare Budgets geeinigt. Damit können wir pro Seite die Frage beantworten, ob die Ladezeiten unseren Ansprüchen an eine exzellente User Experience gerecht werden. Unsere Budgets sind absolute Zahlenwerte, welche wir für das 95. Percentil erreichen wollen. Also 95% aller Seitenaufrufe sollen schneller als das Budget in den einzelnen Metriken performen. Folglich können wir unsere Tabelle wie folgt erweitern:
Meilenstein | Metrik | Budget (95 Percentil) | Messung | |
---|---|---|---|---|
1 | Passiert etwas? | First Contentful Paint | <1 Sek | RUM |
2 | Ist es nützlich? | First Meaningful Paint | <3 Sek | RUM |
3 | Kann ich damit interagieren? | Time to Interactive | <5 Sek | Synthetisch |
3 | Kann ich damit interagieren? | First Input Delay | <100ms | RUM |
Die Budgets sind Industrie-Standards und gelten heutzutage als Messlatte, um eine Seiten-Performance zu evaluieren. Spannenderweise basieren die Budgets teilweise noch auf dem Werk von Robert B. Miller "Response Time in Man-Computer Conversational Transactions aus dem Jahre 1968. Unsere Kunden erwarten jedoch stetig schnellere Ladezeiten und stellen höhere Anforderungen an diese Limiten. Bei der Interpretation der Messwerte mit den Budgets ist, wie anfänglich erwähnt, die Page Performance nicht als ein einziger Moment in der Ladeanimation einer Webseite zu verstehen. Die Kombination aus allen Metriken fügt sich im Endprodukt zu einer gesamtheitlichen und zufriedenstellenden User Experience zusammen.
Eine Investition in die Zukunft
Neben den elementaren Vorteilen einer schneller wahrgenommen Webseite für den Kunden sind schnelle Webseiten auch ein wichtiger Bestandteil jeglicher Visibilität. Damit ist das Scoring von unseren Seiten gegenüber Suchmaschinen wie Google gemeint. Google investiert seit 2009 mit dem Launch der "Let's make the web faster" Initiative stark in ein schnelles und benutzerfreundliches Web und bevorzugt entsprechende Webseiten mit schnellen Ladezeiten in ihren Rankings. Dabei ist die Performance ein wichtiger Rankingfaktor unter vielen.
Das Thema gewinnt bei uns gerade richtig an Fahrt und wir experimentieren stark mit Anpassungen unsere Code-Basis, um weitere Speed-Verbesserungen zu realisieren. Wir halten euch auf dem Laufenden.
Möchtest du aktiv bei der Optimierung des Pagespeeds mithelfen? Alle offenen Stellen findest du hier. Im Moment suchen wir u.a.:
Habt ihr auch schon Optimierungen an der Performance einer Webseite gemacht? Was hat dabei gut funktioniert? Wir freuen uns auf einen spannenden Austausch.
Besessener Löser von digitalen Problemstellungen. Outcome über Output. Vermeide notorisches Verfolgen von Technologie-Trends. Fälsche nie Produkterfolg mit willkürlichen KPIs. Gebe nie auf wegen einer gescheiterten Idee. Das ganze Leben ist ein Versuch. Amen.