Dass es im Web vor allem um Performance geht, ist schon lange kein Geheimnis mehr. An allen denkbaren Stellen wird versucht noch die letzte Millisekunde an Ladezeit einzusparen.
Zwar genießen wir den Luxus von immer höheren Verbindungsgeschwindigkeiten, doch überproportional dazu sinkt auch die Geduld der User auf Inhalte zu warten.
Im Wesentlichen gibt es zwei Möglichkeiten hier vorzugehen:
- Höhere technische Kapazitäten bereitstellen
- Weniger technische Kapazitäten zu benötigen
Eine Erhöhung der bereitgestellten Kapazitäten ist in der Regel mit wenigen Klicks erledigt. Geht aber je nach Umfang schnell richtig ins Geld. Vor allem auf lange Sicht scheint dieser Weg also nicht das Maß der Dinge zu sein.
In dieser Case Study zeigen wir, wie wir mit geringem Aufwand die Performance eines Online Shops steigern, das Nutzererlebnis verbessern und dem Google Ranking zuarbeiten konnten.
Was ist CLS?
Unter Cumulative Layout Shift (CLS) versteht sich ein Verschieben von Elementen nachdem eine Website geladen wurde.
Die Bewertung/Auswertung von CLS ist Teil der von Google zusammengestellten Core Web Vitals. Mit denen sowohl Aspekte der Performance einer Website als auch das Nutzererlebnis messbar gemacht werden sollen. Über Googles Pagespeed Insights Tool können diese Werte erfasst und die Auswirkung von Optimierungsmaßnahmen gemessen werden.
Da die Core Web Vitals seit Mai 2021 auch einen Rankingfaktor darstellen, ist es ratsam diese Werte nicht aus den Augen zu verlieren.
Neben dem CLS werden in den Core Web Vitals außerdem erfasst:
- First Content Full Paint (Zeit bis der User Inhalte auf einer Website sieht)
- Total Blocking Time (Zeit in der zu ladende Resourcen den Seitenaufbau blockieren)
- Time to Interactive (Zeit bis User mit einer Website interagieren können)
- Largest Contentful Paint (Zeit bis Inhalte im ersten Sichtbereich des Users geladen wurden)
Quellen:
sistrix.de/news/google-bestaetigt-core-web-vitals-ab-mai-2021-ein-rankingfaktor
Ausgangssituation
Wir haben die technische Betreuung eines Online Shops für Innenausstattung übernommen.
Der Shop läuft auf Basis von WooCommerce und konnte insgesamt bereits gute Ergebnisse in Hinsicht auf Ladezeit und Gesamtperformance verzeichnen.
Was der Kundin nun aber ein Dorn im Auge war: die Bewertung des Shops mit Googles Pagespeed Insights hatte zwei Schwachstellen.
- Largest Contentful Paint
- Cummulative Layout Shift
Wo Performanceoptimierung sonst auf eine Gesamtverbesserung abzielt, galt es hier ganz gezielt die Auslöser für diese beiden schlechten Werte zu finden.
Dafür muss man zunächst verstehen wer, also welche Sprache, zu welchem Zeitpunkt des Seitenaufbaus welche Aufgaben erfüllt.
Was steht also zur Auswahl?
- Das serverseitige Zusammenstellen des HTML Codes (im Fall von WooCommerce: PHP)
- Der zum Browser gesendete HTML Code
- Das Styling via CSS
- Interaktion mit dem DOM via JavaScript
Um eine Verschiebung von Layoutelementen zu verursachen, muss es erstmal Layoutelemente geben.
Serverseitig wird der HTML Code zusammengestellt. Zu dem Zeitpunkt wird im Wesentlich ein Textblock mit Inhalten gefüllt. Layoutelemente, die sich jemand anschauen kann, haben wir hier nicht.
Das was vom Server dann an den Browser gesendet wird, ist eben dieser fertige HTML Code. Immer noch: nicht weiter als Text.
Nun sind wir aber vom Ablauf her schon mal im Browser. Doch sehen können wir immer noch nichts. Der Browser arbeitet sich nun durch den HTML Code und rendert die Website. Sprich: aus dem Textblock wird das DOM (Document Object Model) gebildet. Grundsätzlich wäre hier also ein guter Ansatz für die Problemanalyse.
So ein HTML Code besteht allerdings nicht nur aus Dingen, die man sieht, sondern auch aus Zusatzinformationen. Das kann z.B. der Verweis zu einem Stylesheet (CSS) sein, in dem definiert ist, wie Elemente aussehen sollen.
Klingt soweit schonmal ganz gut. Wir haben nun unsere Layoutelemente (HTML) und die Definition, wie sie aussehen sollen (CSS). An dieser Stelle ist die Seite im Browser aufgebaut und sieht aus wie sie aussehen soll.
Damit bleibt in unserem Ablauf zum Seitenaufbau nur noch ein Kandidat, der, nachdem die Seite steht, für eine Verschiebung verantwortlich sein kann: JavaScript.
Mit JavaScript kann im Browser mit dem DOM interagiert werden. Z.B. bei Klick auf einen Button soll ein anderes Element geöffnet oder geschlossen werden.
Nun wurde in diesem Fall der JavaScript Code allerdings verwendet, um Positionierungen im Layout zu korrigieren. Tja, aber warum eigentlich?
Was vielen an der Nutzung von Wordpress Websites gefällt, ist die Möglichkeit Seiten und ihre Inhalte mit PageBuildern zu gestalten. Damit können Websitebetreiber die Inhalte ihrer Website ohne Programmierkenntnisse bearbeiten.
Nun stehen die Entwickler von solchen PageBuildern natürlich vor der Hürde, dass sie so viele Gestaltungsmöglichkeiten wie möglich bieten wollen und dabei aber mit den denkbar unterschiedlichsten Grundstrukturen von Websites zurechtkommen müssen.
Der in diesem Shop verwendete PageBuilder hatte nun die Funktion Blöcke einer Website, trotz einer festen Seitenbegrenzung, auf die volle Breite des Browsers zu ziehen, ein netter Effekt. Allerdings tat der PageBuilder genau das: er wartete bis die betreffenden Blöcke im Browser gerendert wurden und hat sie dann so positioniert, dass sie von ganz links nach ganz rechts ragten.
Hier hatten wir sie nun also gefunden: die nachträgliche Verschiebung von Elementen.
Lösung
Nachdem wir nun ausfindig machen konnten, wie die Layoutverschiebung zustande kommt, können wir gezielt nach einer Alternative suchen.
Der erste Gedanke war: das betreffende Element, da es im Header (Kopfbereich) der Website lag, aus dem Pagebuilder rauszunehmen. Somit könnten wir es außerhalb des Wrappers (seitliche Begrenzung des Inhaltes) platzieren und bräuchten die nachträgliche Streckung nicht mehr.
Grundsätzlich wäre das sicher eine wirkungsvolle Lösung gewesen. Hätte allerdings zwei entscheidende Nachteile mit sich gebracht.
- Relativ hoher Entwicklungsaufwand, da diese Anpassung an einigen Templatedateien vorgenommen werden müsste und das Backend um entsprechende Pflegemöglichkeiten für Bild und Text in dem Element erweitert werden müsste.
- Die Inhalte für die Elemente müssten auf allen betreffenden Unterseiten neu eingepflegt werden.
Da das Element auf der Startseite und nahezu allen Unterseiten (in diesem Shop etwa 100) vorhanden ist, war ein solcher Mehraufwand höchstens als Notfalllösung denkbar.
Der zweite Gedanke: das Element bereits im CSS Styling richtig zu positionieren. Somit hätte das Korrekturskript des Pagebuilders nichts mehr zu tun, da das Element bereits beim Rendern an der richtigen Stelle wäre.
Das klingt nach einem Plan.
Allerdings mussten wir hier ein wenig in die Trickkisten greifen, denn der nötige Versatz, um aus dem Wrapper herauszukommen, ist beim Rendern der Seite ja noch nicht bekannt.
Der Grund dafür lag bei diesem Projekt an der festen Breite des Wrappers von 1000 Pixeln. Das Browserfenster des Besuchers kann nun aber jeden beliebigen anderen Wert haben.
Gehen wir ins Detail:
Unser Wrapper hat eine Breite von 1000 Pixeln. Im Szenario 1 öffnet der Besucher den Shop mit einer Bildschirmbreite von 1800 Pixeln. Damit das Element nun genauso breit ist wie das Browserfenster, geben wir ihm eine Breite von 100vw (1vw = 1% der Bildschirmbreite). Allerdings sitzt es nun immer noch linksbündig im Wrapper und ragt nach rechts über. Damit es linksbündig am Browserfenster sitzt, ziehen wir das Element um 400 Pixel nach links. 1800px - 1000px / 2 ergibt den Platz links und rechts neben dem Wrapper.
Im Szenario 2 kommt der Besucher nun mit einem Bildschirm, der nur 1600 Pixel breit ist. Wenn das Element nun immer noch um 400 Pixel nach links versetzt wird, steht es links über.
Also keine sehr flexible Lösung, was den Versatz angeht.
Mit sogenannten Media Queries kann man im Styling zwar verschiedene Bildschirmgrößen ansprechen, allerdings wäre hier ja für jeden Pixelbereich, der größer als die Breite des Wrappers ist eine eigene Anweisung nötig.
Wie bekommen wir den Versatz nach links dynamischer?
Ganz klar: mit einem Versatz nach rechts!
Wir wissen bei jeder Bildschirmauflösung zwei Dinge:
Der Wrapper hat eine feste Breite und sitzt mittig im Browserfenster Der Browser hat eine feste Breite
Wer welche Maße hat, ist dabei eher nebensächlich.
Wenn wir unser Element um die halbe Breite des Wrappers (50%) nach rechts verschieben, liegt die linke Seite des Elements genau mittig im Browserfenster. Wenn wir es jetzt um die Hälfte der Breite des Browserfensters (50vw) nach links verschieben, liegt die linke Seite genau an der linken Seite des Browserfensters. Und zwar bei jeder Bilderschirmauflösung.
Die Implementierung war nun recht schnell gemacht. Da der Pagebuilder den Elementen, die gestreckt werden sollen, spezielle Attribute im HTML Code zuweist, konnten wir sie gezielt ansprechen und an den Elementen selbst war keine weitere Anpassung nötig.
Das Ergebnis lässt sich nun durchaus sehen:
Der CLS Wert hat sich von 0,245 auf 0,007 verbessert und am Largest Contentful Paint konnten wir auch eine Verbesserung feststellen.
Insgesamt hat uns das Drehen an diese konkreten Stellschraube 11 Punkte eingebracht.
Fazit
Pagebuilder haben durchaus ihre Daseinsberechtigung. Schnell und unkompliziert lassen sich Websites aufbauen und gestalten. Codekenntnisse sind dabei vor Vorteil, aber meist nicht erforderlich.
Allerdings kommen sie mit so manchen Schwachstellen. Sei es was gestalterische Freiheit und Feinheiten in der Mobiloptimierung angeht oder wie in diesem Beispiel die Performance.
Zum Glück stehen wir hier vor keiner Entweder-oder-Situation und oft reichen schon kleine aber gezielte Handgriffe um solchen Schwachstellen entgegenzuwirken.