Site Performance

[cekageka]

Ich hab jetzt auch mal wieder die Google Search Console reaktiviert und ich denke das Ergebnis ist eindeutig: Unser Ranking ist massiv downgraded wegen poor performance. Mir ist klar, das ist nicht trivial zu beheben ... aber wir müssen da dran.

cc @Listor @cakageka

[cakageka]

Aber warum ist denn unsere Performance so schlecht? Wenn ich die Seiten aufrufe, sind sie asap da. Übersehe ich was?

[Listor]

Welche Seite hast du hier geprüft @cekageka ?

@cakageka schlecht ist ja relativ. Der Lighthouse Test Mobil ist der "schlechte".

Generell können wir hier natürlich schneller werden. Ich prüfe was man "schnell" tun kann. Betrifft somit auch das Thema Bundle.

Nach meinem Verständnis nach, spielt aber auch der Content eine große Rolle. Der hat zwar keine Auswirkung auf den Lighthouse Score, aber aufs Ranking.

Will aber erstmal meine Quick Maßnahmen durchkriegen.

[cekageka]

Welche Seite hast du hier geprüft @cekageka ?

readius ist wohl am schlimmsten, die anderen Sites sind aber ähnlich.

@Listor Quick-Maßnahmen oder Quic-Maßnahmen ;-)

[Listor]

@cekageka kannst du auch die Core Web Vitals von Radius Staging sehen https://viable-bee.cloudvent.net/ ? Wenn ich das über die Seite mache spuckt er mir dort keine Daten aus.

Die Daten die ich über https://pagespeed.web.dev/analysis/https-www-radius-as-a-service-com/92q3yvlwoh?hl=de&form_factor=mobile oder https://pagespeed.web.dev/analysis/https-viable-bee-cloudvent-net/gaugjhi6vd?hl=de&form_factor=mobile bekomme sind jedenfalls anders, als die die ich direkt über den Browser bekomme.

Die Leistung ist dort auf STAGING sogar schlechter als auf PROD, was für mich keinen Sinn ergibt, nachdem ich dort schon Einiges optimiert habe. Die Testsysteme sind bei CC aber auch immer etwas langsamer, so zumindest meine Wahrnehmung.

Im Browser kann ich sehen, dass ich knapp 16 Punkte mehr Leistung in STAGING habe, die durch diverse Maßnahmen erzielt wurden. Unter anderem auch ein JS Bundle als Test.

Die Version könnte man zum Ausprobieren auf Radius PROD spielen und dann schauen, ob sich was verbessert und nochmal einen Core Web Vitals Test laufen lassen.

Wir tragen, aber auch weiterhin Legacy Code, wie jQuery, Plugins aus dem Front Theme und Bootstrap mit uns herum. Diese Abhängigkeiten, kann man nicht so leicht auflösen und tragen einen Teil zur Performance bei.

Mit Bundle von CSS und zusätzlich dem Theme JS Kram, kann man sicherlich noch etwas rausholen, bei verhältnismäßig mittelmäßigem Aufwand.

Der Legacy Kram ist deutlich aufwendiger.

Meine Empfehlung wäre hier auch mal über Nuxt nachzudenken. Im Moment ist unser Stack schon ziemlich Custom, durch die Verbindung von Jekyll und Vue.

Nuxt könnte beispielsweise Vue Komponenten, die jetzt am Client gerendert werden am Server Vorrednern und nur wenn notwendig zur Laufzeit Hydraten. Das führt dazu, dass die Performance am Anfang wieder stark steigt, weil die meisten Daten statisch gerendert werden können. Die Einarbeitungszeit für andere Entwickler ist auch geringer, weil es ein gängiges Framework ist und man weg von einer Custom-Lösung wäre. Ist aber vom Aufwand her schon eine größere Aufgabe, weil wir dafür alle Komponente migrieren müssten. Wäre trotzdem langfristig meine Empfehlung.

Können da auch gerne drüber quatschen.

Zusammenfassend:

• Legacy Stuff (hoher Aufwand)
• Bundle ausarbeiten (gering bis mittlerer Aufwand)
• Nuxt Migration (hoher Aufwand)

Würde auf jeden fall das Bundle noch ausarbeiten und dann auf PROD bringen, um es dort zu testen.

[Listor]

Desktop:

Mobile:

SEO ist mMn. schlecht wegen der URL und Testsystem.

[Listor]

Der Stand ist jetzt auf PROD von Radius.

Lighthouse Score in Chrome schwankt aber auch, aber man kann sehen

Desktop:

Mobile:

Ich weiß nicht, wie schnell und ob man das in der Google Search Console sieht @cekageka

@cakageka du kannst deine Headlines jetzt auch in STAGING einbauen und deployen dann.

[cekageka]

Hi @Listor, erstmal Danke dir für die bisherigen Verbesserungen. Mir ist eben noch ein nettes neues Tool untergekommen, ich finde die Ergebnisse ziemlich spannend. Vielleicht magst du bei Gelegenheit mal drüberschauen und - falls gut zu bearbeiten - auch gerne verbessern:

https://yellowlab.tools/result/guf3f27n2w
(link geht direkt auf ein Result von glueckkanja.com)

Spannend fand ich den no-cache der shared components. Idee warum das so ist?

[Listor]

@cekageka das liegt daran, dass diese JS Files dynamisch aus dem JS heraus geladen werden und dadurch kein "richtiges" statisches File sind, wie bei einem Bundle. Deshalb können sie nicht gecacht werden.

Schaue mir das Tool mal an und bei Radius, dort wo wir das Bundling aktiviert haben, ist das Problem nicht so schlimm, wobei auch dort noch einige dynamische Imports sind. Könnte man wahrscheinlich durch Konfigurationen noch optimieren:

https://yellowlab.tools/result/gufxokemk6 Radius mit Bundle https://yellowlab.tools/result/gufxqson07 Konnekt ohne Bundle

[cekageka]

Danke dir! Ich hab allerdings nicht mobile, sondern HD-Desktop gemessen. RADIUS schneidet echt gut ab, aber bei Konnekt haben wir wohl irgendwie den Wurm drin: https://yellowlab.tools/result/guheohod68.

Das mit dem Bundling ist doch eh ne gute Idee ;-)

[Listor]

Alles klar, ich schaue mir noch Konnekt gesondert an, würde aber bei den Produkten & Corp das Bundling ausrollen.

[Listor]

Alle Seiten verwenden jetzt das Bundling.

Auf Der Konnekt Seite sind die Videos im Accordion das Problem, für die schlechte Bewertung. Ich habe diese mal durch Animierte WebP's ersetzt, das kann Cloudinary. Dann landen wir bei 10mb https://yellowlab.tools/result/gv38nt106u

In Lighthouse wird das Bild jedoch eh viel später geladen, weil es auch ein Lazy Load hat. Verstehe nicht genau, wieso das im initialen Payload bei Yellowlab geladen wird, würde ich deshalb eher ignorieren. Ansonsten müssen wir noch schauen, ob wir die größe der Videos noch so reduzieren, um hier noch ein paar Mb's zu sparen.

Cloundinary kann Videos irgendwie nicht skalieren, stürzt bei mir jedenfalls immer ab. Man müsste also die Quellvideos nochmal in kleiner ausspeichern. Aktuell sind sie bei 800x und werden so maximal bei 600x angezeigt. Denke darüber könnte man nochmal ordentlich was einsparen.

@cekageka @cakageka wie wollen wir weitermachen?

[cekageka]

@Listor Was meinst du mit 'kann nicht skalieren'?

https://res.cloudinary.com/c4a8/image/upload/h_200,w_200/products/konnekt/konnekt-drive-letter.webp

[Listor]

@cekageka weird.

Vielleicht brauchen die auch einfach so lange bis die es konvertiert haben. Ich habe es über deren Interface zusammengeklickt und mir wurde immer ein 400er geschmissen.

Wenn ich in deinem Request einfach mal die Parameter ändere auf: https://res.cloudinary.com/c4a8/image/upload/h_400,w_600/products/konnekt/konnekt-drive-letter.webp oder https://res.cloudinary.com/c4a8/image/upload/h_600,w_600/products/konnekt/konnekt-drive-letter.webp bekomme ich wieder 400er.

Hatte es gestern öfter probiert, aber ohne Erfolg.

Hast du irgendwas Spezielles gemacht? Kann mir sonst nur vorstellen, dass es einfach zu lange auf der Cloudinary Seite dauert, bis sie neu gebaut wurden.

[cekageka]

@Listor hehe, ist lustig. Aber gut erklärbar, die Doku hilft. Im Inspector findest du einen X-Cld_Error, in diesem Fall

Maximum total number of pixels in all frames/pages is 200 Megapixels. Requested 220.08 Megapixels

Source: https://cloudinary.com/documentation/advanced_url_delivery_options#error_handling

Übrigens ist auch die Frage, ob wir h+w angeben sollten, kann immer eine Verzerrung zur Folge haben. Gibt da natürlich tausend weitere Parameter, um das Optimum zu erzielen (ist echt mal ein Blick wert, auch bzgl. Kompression etc), aber in dem Fall könnte zB nur h oder nur w sinnvoll sein:

https://res.cloudinary.com/c4a8/image/upload/h_410/products/konnekt/konnekt-drive-letter.webp

[cakageka]

@cekageka Jetzt haben wir parallel experimentiert. Skalierung ist bis 500 möglich. Gilt übrigens für alle Formate. https://res.cloudinary.com/c4a8/image/upload/c_scale,w_500/products/konnekt/konnekt-drive-letter.webp

[Listor]

Ah das erklärt es :D JETZT sehe ich es auch.

Gut dann wäre es trotzdem hilfreich, man passt die Datei auf unserer Seite nochmal mit der Quelldatei an und optimiert auf 600px würde ich vorschlagen. 500 ist glaube ich bei der Qualität schon etwas grenzwertig und wenn man das manuell exportiert, kann man noch mehr auf die Qualität achten.

Und genau es würde nur die Breite mit übergeben werden, wie hoch das Asset ist, wäre uns dann egal und die Aspect Ratio bleibt bestehen.

[Listor]

@cakageka hast du die Assets eigentlich schon? Ansonsten würde ich die Anpassung auch mal in den Master schieben und man tauscht die Assets aus, wenn man sie hat?

[Listor]

Habe die Anpassung wie besprochen schon mal in den Master genommen. Dann kann man nachträglich die Assets austauschen, wenn man sie hat.

[lenadaflis]

Bin bisher noch nicht dazu gekommen, die Assets als webm zu exportieren – von daher super, dass wir sie jetzt auch nachträglich austauschen können. Danke, Michi!

[Listor]

@cakageka wollen wir mit dem Ticket noch etwas machen? Ansonsten würde ich es schließen oder @lenadaflis für die Assets geben?

[lenadaflis]

Gibs gerne mir, dann vergesse ich es auch nicht. :-)

[cekageka]

@Listor bevor wir das Ticket hier zu machen... die Produkt-Webs sind mittlerweile alle auf A, sehr geil. Aber bei GK sieht es noch echt mies aus, können wir hier noch was machen?

[cakageka]

@lenadaflis Ich muss die Videos noch suchen :-)

[Listor]

@cekageka der größte Punkt dort ist das Bild https://res.cloudinary.com/c4a8/image/upload/events/event-thumb-tech-conf.jpg mit 4.4mb etwas groß.

Ich denke hier könnte man auch den Request, der notwendig ist, um die Bildgröße zu errechnen an das gewählte Preset koppeln, so dass es in der Größe beschränkt ist.

Würde ich Morgen mal testen, und das sollte das F dort auch lösen.

Die anderen "C"-Bewertungen gehen dann in die Maßnahmen, die Bootstrap und Nuxt betreffen. Also keine schnellen Verbesserungen.

[Listor]

@cekageka ich habe das mal auf DEV https://chartreuse-sky.cloudvent.net/de/ deployed. Siehe https://yellowlab.tools/result/gwswliydsc

Hat die Obergrenze der Bilder nochmal mehr eingedämmt. Würde ich zeitnah auch auf STAGING spielen. Je nachdem, auf welche Seite man geht, hat das vom Payload schon nochmal eine deutliche Reduzierung herbeigeführt. Ist jetzt nur ein "B", aber hier setzen wir auch auf 2 Fonts im Vergleich zu den Produkten und laden mehr Bilder.

Also es besteht nicht mehr soviel Potential, um es "einfach" noch zu optimieren.

Passt das so für dich?

[cekageka]

Top, vielen Dank!

[lenadaflis]

Die Aufgabe für den webm-Export steht aber weiterhin, oder?

[Listor]

Yes