Ressourcen Verbrauch der Website ermitteln

[Testa2014]

Moin zusammen,

ich brauch mal n Stupser oder eine Erklärung von euch.

Also, ich bin dabei ne Seite (BA) zu basteln. Da diese letzten Endes auch für Mobile Geräte ausgelegt ist und wir alle das elend mit den Android Smartphones und Tablets kennen (Seite schmiert ab oder lädt permanent neu), wollte ich mal schauen was an Ressourcen benötigt wird und entsprechend optimieren. Bitte jetzt keine Diskussion darüber das eure Geräte 8GB RAM und 10 Kerne haben, es gibt Menschen deren Telefon oder Tablet nur einen halben GB mit 2 Kernchen hat.

Also gut, Entwicklertools auf und unter Memory geschaut was er sagt. Da steht ne magische Zahl von 46MB, diese ist jedoch bei jedem Laden mal höher oder auch niedriger (~3MB). Nächster Gedanke, gut schmeißt du mal deine ganzen generischen Module raus. Siehe da die Zahl hat sich nicht groß geändert. Und die Module laden schon fleißig Content und generieren den auch auf dem Endgerät.

Dann gibt es noch diesen Performancemesser, naja so richtig werde ich aus den Zahlen auch nicht schlau und scheint eher auf Zeiten ausgerichtet zu sein.

Lighthouse ... ähh ja. Ein Index von 12 bis 21 bei unterschiedlichen Ladeversuchen mit dem selben Content. Aber richtige feste Zahlen hat der mir auch nicht gegeben.

Der Taskmanager vom Browser sagt übrigens 222MB.

Gibt es hier Profis die mir eine entsprechende Ressource verlinken können (ja Google kenn ich) oder mir anderweitig sagen können wie ich an die Werte komme?

Vielen Dank
Testa

 

[Mercator]

Zumindest für den Chrome Browser gibt es eine brauchbare Erweiterung:
https://chrome.google.com/webstore/...alyser/djgfmlohefpomchfabngccpbaflcahjf?hl=de

Ansonsten erklär mal um welches Web-Projekt es genau geht - mit BA kann ich nix anfangen.

 

[Aduasen]

Nur die Webseite oder willst Du auch messen, was z.B. an Werbezeug rein kommt.
Da wirst Du nicht viel machen können, denn es hängt ja z.B. davon ab, was für ein Clip da (zufällig) geladen wird.

 

[Testa2014]

Danke für eure Antworten

brauchbare Erweiterung

die zeigt mir das gleiche wie die Entwicklertools an, nur anders aufbereitet. Gescheite Zahlen zu den Ressourcen kann ich auch da nicht entnehmen.

mit BA kann ich nix anfangen

Business Application, ist eine Anwendung die aktuell noch in Entwicklung ist, würde euch ja einen Link geben wenn ich dürfte . Ne Simple Tabelle und anschließend wenn auf einen Eintrag geklickt wird, wird das ganze Gedöns was dahinter liegt geladen. Wie gesagt, kann ich das dahinter liegende komplett entfernen und es ändert sich nichts groß bzw. das ist in den Toleranzen einzuordnen.

z.B. an Werbezeug rein kommt

Werbung wird es nicht geben.

 

[BeBur]

Hast du das mit Firefox auf smartphone geprüft oder an deinem PC?
RAM Verbrauch kann ich mir vorstellen könnte unterschiedlich sein.
Ich würde womöglich ganz naiv den Traffic versuchen zu minimieren. Dazu findet man ggf. auch Content, von RAM Minimieren beim Client hab ich noch wie was gehört, bin aber auch kein Frontend-Dev .
Welches Framework bzw. welchen TechStack verwendest du?

Jedenfalls klingt das schwer nach 'premature optimizing'. Du vermutest einfach nur, dass 40 MB zu viel sein könnten für alte Geräte, richtig? Ich würde mir ja ein uralt smartphone besorgen und diese Theorie mal prüfen. Kann mir irgendwie nicht so recht vorstellen, dass die ersten Smartphones keine 40 MB RAM freiräumen konnten.

 

[Joshinator]

Sehe ich genauso

Mobile Geräte ausgelegt ist und wir alle das elend mit den Android Smartphones und Tablets kennen

liest sich nicht so als ob es konkrete Fälle gibt sondern man welche in der Zukunft vorbeugen will.
Wenn es Fälle gibt, günstig so ein Low-End Gerät anschaffen und mit den Devtools (Remote Devices) gucken was das Gerät macht wenn du es in die Knie zwingst.
46MB JS Heap klingt jetzt nicht überzogen viel, je nachdem was deine "Business Application" tut. Google Sheets ist ja auch "nur" ne Tabelle hat bei mir trotzdem 100MB Heap wenn ich eine leere Tabelle auf mache.

Wenn deine Zielgruppe 500MB RAM & 2 Kerne sind dann sollte man sich von vorn herein Gedanken drüber machen wie man programmiert.
Modernes Javascript (ala SPA) ist bei solchen Low-End Geräten immer ein Problem, wirklich schlimm wird's wenn deine Bundle Megabyte groß ist.
Falls ihr das vermasselt habt kann man jetzt nur mit den üblichen Optimierungen gucken das man dem User weniger Javascript sendet.
Dein Bundle untersuchen (für Webpack z.B.)) um herauszufinden welche Dependencies riesig sind (Lodash, Momentjs sind oft solche Kandidaten).
Chunks um einzelne Routen/Components nachzuladen statt die direkt auszuliefern, je nach Browser-Support unterschiedliche Bundles (nur IE11 braucht ES6 Polyfills), Webworker benutzen wenn ihr mit größeren Datenmengen arbeitet um den Main/UI-Thread frei zu halten, "virtual scroll lists" bei riesigen Listen/Tabellen.

Aber das sind die generischen Tipps, ohne zu wissen was deine "Business Application" genau ist und tut kann dir keiner konkret helfen.

 

[Testa2014]

Ich nutze Vivaldi und entwickle auf dem Desktop. Auf dem iPhone rennt das ganze auch geschmeidig vonstatten.

Mir ist klar das der Verbrauch unterschiedlich ist, nur wundert es mich sehr das er bei unterschiedlichen Aufrufen ein gap von ~6MB ist. Was ja doch ne Menge ist. Selbst die 40 MB sind schon echt viel, wenn ich daran denke was wir damals mal zu Verfügung hatten und wie dort entwickelt wurde.

Habe mir eben mal den Fuchs runtergeladen, der kommt bei den Snapshots zwischen 22 und 36MB.

Ja, Traffic ist kein Problem. Die Requests werden nach dem deployen zusammengefasst und dadurch massiv minimiert. Aktuell laufen die noch einzeln, wenn ich das testeshalber mal zusammenwürfeln lasse sehe ich auch keinen großen Unterschied, nur das es halt bei einer langsamen Verbindung noch schneller ist

Ich bin auch eher im Backend zu Hause und spiele gerne mit Datenbanken rum, musste jetzt aber mal wieder einen Exkurs machen. Die Technik die genutzt wird ist openUI5.

Naja, wie oben geschrieben kann fast jeder ein Lied von Android und abgeschmierten Seiten singen (bzw. ich habe das schon häufiger gehört und gesehen das es relativ tief sitzt) dem möchte ich ganz einfach vorbeugen. Ich werde mal auf die Suche gehen ob ich noch ein "so altes" Gerät in meinem Fundus habe. Aber du hast Recht, im nachhinein nochmal überall drüberzurattern, da bin ich kein Freund von. Lieber gleich einmal ordentlich und 30 Minuten mehr Zeit reinstecken als im nachhinein 2 Wochen sitzen ...

46MB JS Heap klingt jetzt nicht überzogen viel

Oh, danke. Habe davon null Ahnung, wenn das noch im Rahmen ist dann mach ich mir da keine großen Sorgen weiter.

was deine "Business Application" tut

Wie geschrieben, bisher ist es nur eine Tabelle. Wenn du einen Eintrag auswählst wird erst das tatsächlich aufwendige geladen was im Browser gerendert wird (Text, Diagramme, Prozesse, ...).

Falls ihr das vermasselt habt kann man jetzt nur mit den üblichen Optimierungen gucken das man dem User weniger Javascript sendet.

Der Kunde hat schon aktuelle Geräte (alles wird nach max 2 Jahren einmal durchgetauscht), die Mitarbeiter können jedoch auch Ihre privaten nutzen oder von zu Hause aus darauf zugreifen. Darum ging es mir jetzt, oder ein weiterer Kunde will das Produkt dann auch kaufen: Bedingungen fraglich. Auf einem Fernseher würde ich das ganze jetzt auch nicht ausschließen.

Dann mach ich mir dort erstmal keine große Platte und seh das als größtenteils optimiert an auch wenn mein Gehirn was anderes bei diesen Zahlen schreit.

 

[Michael-Menten]

Beliebig viel RAM geben und zu sagen das ist der Verbrauch ist nicht immer das beste Ergebnis da der Brwoser dann ggf. anders arbeitet.
Bei Lightroom muss man aufpassen was sonst noch im Browser an Addons drin ist, da dies das Ergebnis verfälscht (Addons sind teilweise bereits ab Werk installiert, z.B. Vivaldi picture in picture mode für youtube und co.).

Wenn sowas häufiger gebraucht wird am besten ein externes Programm verwenden was auch Test durchführen kann.

 

[Joshinator]

Oh, danke. Habe davon null Ahnung, wenn das noch im Rahmen ist dann mach ich mir da keine großen Sorgen weiter.

Kommt am Ende auf die Komplexität an, kannst dir ja mal die Demos von OpenUI5 angucken. Die befinden sich zu Launch je nach Demo entweder bei 8MB oder bei 32MB und beruhigen sich später wenn Javascript den Müll rausgebracht hat.
Aber setzt dir nicht irgendeine aus der Luft gegriffene Heapgröße die du krampfhaft erreichen willst damit uralte Handys unterstützt werden, solange du nicht alle Variablen im globalem Scope definierst oder etwas ähnlich dummes machst wodurch JS nicht aufräumen kann.

Eine Heapgröße von 10MB, 40MB oder 100MB ist nicht der Grund warum der Tab in einem Browser crasht. Sowas passiert in der Regel wenn man den Thread zu lange blockiert und der Browser sich entscheidet einzugreifen. Alle JS Ausführungen passieren im UI-Thread, wenn du für 20sec ein riesiges Bild Pixel für Pixel mit JS invertierst kann der Thread nicht auf User-Input reagieren und das mag der Browser nicht.
Da ist dann Stichwort Webworker wo man Arbeit in neue Threads auslagern kann, aber ich behaupte mal das die meisten Webseiten sich um sowas wirklich keinen Kopf machen müssen.

Ich betreibe Zuhause noch ein Moto G 1rst Gen als Fernsteuerung/Statusdisplay für Spotify (sonst nix drauf), mit 1GB RAM und Quadcore ein richtiges Bonzengerät.
Jede App laggt vor sich hin und braucht 2-5sec bevor ich irgendwas machen kann. Personen mit solchen Geräten werden sich nicht wundern wenn eine Website nicht flüssig läuft.

So ein Gerät ist nur anfälliger für blockierte Hauptthreads, in den Chrome-Devtools gibt es eine Throttle-Funktion (im Performance-Tab hinter dem Settings-Icon) die es dir einfacher macht so eine CPU zu simulieren.

 

[Piktogramm]

Wenn du Software schreibst, nimm keine Rücksicht auf Ewiggestrige. Jene Kunden die derart "sparen" dass sie dem technischem Stand bei Soft- und Hardware um Jahre hinterher hängen, sparen auch an deiner Bezahlung und ziehen dein Projekt auf ihre Niveau runter. Was du eigentlich willst sind Kunden die aktuellen Entwicklungen halbwegs zeitnah folgen und die das entsprechen honorieren können/wollen.
Vor allem wird deine Software im Laufe der Zeit sowieso durch die Entwicklung überholt. Wenn du jetzt auf aktuellem Stand von HW und SW entwickelst hast du ein paar Jahre Ruhe, bevor dein Code alt und ranzig daher kommt. Wenn du die selbe Entwicklung aber bereits jetzt auf den Stand von vor 5 Jahren optimierst, kannst du gleich mit dem 1. Release das Refaktoring beginnen..

Oder aber du bedienst die Knauserer, versiehst dein Produkt mit einem Vendorlockin und ziehst nach 2-3Jahren die Preise derart an, dass sich ein Wechsel der Software durch den Kunden gerade so nicht lohnt.

############
Technisch:

• Bist du mit Treeshaking schon auf deinen Code losgegangen?
• Lazyloading von Content und Scripten nach Bedarf kann die Zeit bis zum 1. idle deutlich reduzieren
• Vieles wofür früher JS Frameworks nötig waren kann Vanilla JS mittlerweile und einige Dinge sind sogar direkt in HTML/CSS integriert worden. Jenachdem auf welchem technischem Stand du bist, kann man da recht viele Altlasten entsorgen.

 

[Testa2014]

Aber setzt dir nicht irgendeine aus der Luft gegriffene Heapgröße die du krampfhaft erreichen willst damit uralte Handys unterstützt werden

Ich bin kein Freund von Ressourcenverschwendender Programmierung. Aber wenn Ihr sagt: alles im grünen, bin ich an dieser Stelle ruhig.

Stichwort Webworker

Da muss ich mich mal etwas zu einlesen, klingt interessant. Ich weiß adhoc gar nicht ob das Standardmäßig bereits irgendwo abgebildet ist. Vor allem wenn wir dann recht viele Daten dynamisch laden und aktuell halten ... Nehm ich mal mit.

Chrome-Devtools gibt es eine Throttle-Funktion

Mega, Danke. Muss ich mal ausprobieren.

keine Rücksicht auf Ewiggestrige

Wie schon oben geschrieben gehe ich gerne sparsam mit den Ressourcen um. Wir haben Reports/Services die laufen ewig ohne das diese irgendwas groß machen (und das auf einer In Memory DB mit Wums unterm Arsch). Ganz einfach, die Queries sind der allergrößte Murks. Dann permanent Daten hin und herkopieren. Mir ist bewusst das wir heutzutage wesentlich mehr Leistung zu Verfügung haben. Aber müssen wir diese so verschwenden? Nimm dir 2 Stunden Zeit und du schaffst es die Ausführungszeit Minimum zu halbieren. Nur durch effiziente Queries, die Verwendung von Referenzen und auslagern von Logik in die Datenbank. Resultat das rauskommt ist das gleiche. Irgendwann fragt n Kollege oder der Kunde wieso das auf einmal schneller geht ... Ja, weils mir irgendwann auf die Nerven ging zu warten. Es gibt aber auch Sachen da habe ich den Kampf schon lange aufgegeben, das ist aber alles ein anderes Thema.

sparen auch an deiner Bezahlung und ziehen dein Projekt auf ihre Niveau runter.

Bin angestellt, mach dir keine Sorgen.

Bist du mit Treeshaking schon auf deinen Code losgegangen?

Noch nicht, ich werde mir die Tools aber alle mal anschauen und sehen was ich schönes daraus lernen kann. Mich beruhigt erstmal das es anscheinend "normal" ist.

Lazyloading von Content und Scripten nach Bedarf kann die Zeit bis zum 1. idle deutlich reduzieren

Wird angewandt, es gibt eine Hauptkomponente (die angesprochene Tabelle), hinter dieser verstecken sich andere Module. Je nach ausgewählten Prozess wird ein Modul als ganzes geladen und entsprechender Content gerendert.

Jenachdem auf welchem technischem Stand du bist, kann man da recht viele Altlasten entsorgen.

Nope, die Bibliothek UI5 steht. Das ganze wird anschließend in einer SAP Umgebung laufen. Außerdem ist die Integration mit dem Backend (oData) super. Welche Libs sonst noch laufen kann ich eben nicht sagen, muss ich mal schauen. Die Jungs haben auch n bisschen was selber gebastelt.

Ergänzung (13. Oktober 2020)

ein externes Programm verwenden was auch Test durchführen kann

hast du hier ein Beispiel?

 

[Dalek]

Speicherverbrauch ist nicht das erste auf das ich schauen würde, außer es gibt da ein sehr offensichtliches Problem. Die Dev tools sind da schon der richtige Ort um das nachzuschauen, bei 46 MB würde ich mir aber noch keine großen Gedanken machen.

Für diesen Fall würde ich vor allem auf die Bundle-Size achten, also wie viel Javascript insgesamt von der Seite geladen wird. Das ist so der Teil bei dem man am einfachsten viel Ressourcen verschwendet wenn man nicht aufpasst. Zu viel Javascript ist nicht nur schlecht weil das über langsame mobile Verbindungen geladen werden muss, sondern das muss auch alles erstmal geparst werden, was anständig CPU verbrauchen kann.

Ansonsten würde ich einfach mal den Chrome Profiler anwerfen (Firefox geht auch, beim Profiler find ich die Chrome Version aber deutlich besser). Damit kann man ganz gut ein Gefühl dafür bekommen ob es irgendwelche Funktionen gibt die unerwartet viel Leistung verbraten. Für manche Frameworks wie React gibt es auch nochmal spezielle Developer Extensions die auch Profiler beinhalten die z.B. genau zeigen können welche Komponente wie lange brauchen zum rendern, und wie häufig sie gerendert werden müssen.

 

[Piktogramm]

@Testa2014
Queries wie du sie beschreibst sind einfach scheiß Code. Sowas hat nirgends etwas zu suchen. Wobei Reporting, solche Queries sollten sowieso automatisiert laufen und so viele Daten wie sinnvoll vorberechnen/aggregieren und bei Abfrage durch Nutzer wenn möglich nur die Aggregate auswerten. Die Laufzeit von Queries für Reports sollte also eigentlich kaum wer mitbekommen.

Ansonsten, openui5 ist ein Monster. Allein https://openui5.org schaufelt 4,2MB komprimiertes und >17MB entpacktes JS in den Browser, was in ~45MB Speicherbelegung resultiert. Ich vermute, dass da wie üblich das Framework massiv Overhead mitbringt und TreeShaking hier die erfolgversprechendste Hoffnung Verbesserung liefert.
Wobei es auf der anderen Hand wahrscheinlich recht egal ist. Ein Großteil des JS wird wahrscheinlich liegt nach dem ersten Aufruf sowieso im Cache vom Browser.

 

[Dalek]

@Testa2014
Ansonsten, openui5 ist ein Monster. Allein https://openui5.org schaufelt 4,2MB komprimiertes und >17MB entpacktes JS in den Browser, was in ~45MB Speicherbelegung resultiert. Ich vermute, dass da wie üblich das Framework massiv Overhead mitbringt und TreeShaking hier die erfolgversprechendste Hoffnung Verbesserung liefert.

Das ist schon heftig, selbst für die typischen modernen JS Frameworks mit allem drin. Da ist es ja fast egal wie gut man das mit dem eigenen Code macht, das fällt dann kaum noch ins Gewicht. Ich glaube aber nicht das man in so einem Fall Tree Shaking vernünftig hinbekommt, wenn das Framework das vermutlich nicht integriert.

 

[Testa2014]

Für diesen Fall würde ich vor allem auf die Bundle-Size achten, also wie viel Javascript insgesamt von der Seite geladen wird.

Die Libs sind (jedenfalls die Standard) schon optimiert, unsere eigenen werden es wie gesagt erst beim deployen. Nach dem ersten Laden liegen die auch im Cache und müssen nicht nochmal geladen werden. Dann ist nur noch der Punkt der Ausführung. Da dies alles Standard ist werde ich da wohl wenig bis nichts machen können. Vor allem wenn jetzt Minimum 4 Leute sagten das es mehr oder weniger Standard ist.

Chrome Profiler anwerfen

Habe ich eben mal getan, auch berücksichtigt die Option mit dem Throttle:

Das die Seite in 4 Sekunden lädt ist im Grunde in Ordnung aus meiner Sicht. Wenn ich den ohne Limitierung ausführe bin ich bei ~800ms. Wenn ich dem JS Heap Graph hinten folge (nach dem fertigladen der Seite wo er Ressourcen freigibt) liege ich bei 34,...MB. D.h. die Seite frisst im aktuellen Zustand beim Aufbau 44,6MB und nach dem Aufbau liegen wir bei 35MB?
Document ist die Größe der Seite? Wenn ja, warum fällt die am Ende auch ab?
Nodes, versteh ich auch erstmal, bis darauf das die auch abfällt.
Listeners, ja die Events werden irgendwann abgearbeitet und sind damit erledigt. Verstanden.
GPU ... juckt mich nicht.
Irgendwie scheinen die das alles in der Doku vergessen zu haben: https://developers.google.com/web/tools/chrome-devtools/evaluate-performance

Am Anfang parst er die HTML Datei, wenn ich das richtig sehe dauert das wesentlich länger als die Lib auseinanderzunehmen?
Bin ganz ehrlich, die Balken Schocken mich eben etwas, ich glaub da muss ich mir mal n halben Tag Zeit nehmen und ausgiebig belesen. Gute Literaturempfehlungen nehme ich hiermit gerne an.

Das ganze UI5 Zeug frisst bei mir laut Taschenrechner in der Übertragung 1623,75 KB. Inbegriffen die benötigten Libs, Standardtexte, Design, Schriftart.

so viele Daten wie sinnvoll vorberechnen/aggregieren

Wird schwer wenn es sich teilweise um Echtzeitdaten handelt und diese mit einfließen müssen (Zustand einer bestimmten Anlage z.B.). Aber sonst, ja bin ich bei dir.

schaufelt 4,2MB komprimiertes und >17MB entpacktes JS in den Browser, was in ~45MB Speicherbelegung resultiert

Darf ich Fragen wie du das ermittelt hast?

Ich glaube aber nicht das man in so einem Fall Tree Shaking vernünftig hinbekommt

Ich habe dazu einiges bei Google gefunden, nur ist mein Gehirn heute nicht mehr in der Lage das irgendwie zusammenzubekommen. Ich möchte da auch gar nicht allzu viel dran rumfummeln, nachher haben wir irgendwelche anderen Probleme. Mich hat halt echt diese Größe "geschockt".

 

[Piktogramm]

Ermittelt:
Firefox Entwicklertools, Seite Laden mit aktivem Netzwerkmonitoring. Speicherbelegung als Memory Snapshot. Funktioniert bei allen Chromium basierten Browsern ähnlich.

Das Parsen vom HTML scheint vor allem deswegen so lang zu dauern, weil das HTML Gerüst durch ein umfangreiches JS-Script zusammengesetzt wird. Der limitierende Faktor scheint hier schon die Ausführungszeit vom Script zu sein.

Wie nimmst du eigentlich die Performance Analyse aus? Beim "Start recoding and reload" sollte es anders aussehen als bei dir:

Bei dir gehen 800ms ins Land bevor das erste Script ausgeführt wird und ab da gibt es nochmals 400ms Verzögerung bis es mit dem Rendern des HTML los geht. Da ist irgendwas faul. Entweder weil du manuell aufzeichnen klickst und dann manuell das erneute Laden ausmachst, oder aber aus irgend welchen Gründen dauert es recht lang bis der Server die notwendigen Daten ausliefert.