Geschwindigkeit Tablet-UI - Aufruf von Labels, Switches optimieren

[setstate]

Im Firefox gibt es Netzwerkanalyse. Dort sieht man in der Spalte "Übertragen", ob xxKB oder "Aus Cache"

[Tsturm]

Laut Firefox werden alle Dateien geladen. "disable Cache" ändert die Ladezeiten nicht mal eine ms.

Die großen Zeitverbraucher sind die Stylesheets und die js scripts beim Laden, die sollten vom Caching sehr profitieren.

Vielleicht ist das Thema Caching tatsächlich der Schlüssel - irgendetwas schaltet das aus.

[setstate]

Da muss ich heute Abend zuhause weiter forschen, Kopfzeilen Anfragen/Antworten ansehen.

[Eisix]

Hallo,

kann ich bestätigen. Ist bei mir auch so Apache ist cached, HTTPSRV + FTUISRV nicht.

Gruß
Eisix

[Eisix]

update:

muss meine Aussage teilweise revidieren. Bei FTUISRV wird beim 3 load teilweise aus dem Cache geholt.

Gruß
Eisix

[setstate]

Ich habe mir den FHEMWEB Code angesehen. Wenn ein Request über HTTPSVR kommt, wird keine Anstalten gemacht den Browser-Cache zu unterstützen. $cacheable wird fest auf 0 gesetzt und über diesen Zweig wird kein ETag im Header mitgegeben.
Da müsste wirklich jemand am FHEMWEB optimieren ...

Bis dahin kann ich nur empfehlen, einen externen Web-Server (Apache, nginx) zum Ausliefern der FTUi Seiten zu benutzen oder die Files nach pgm2 kopieren. -> ./www/pgm2/tablet/

Im Header müsste dann der Verweis zum ftui-script angepasst werden:

Code Auswählen Erweitern

<script src="../pgm2/tablet/js/fhem-tablet-ui.js" defer></script>

Der Aufruf der Startseite muss dann auch geändert werden:

http://fhem:8083/fhem/tablet/index.html

Die Ladezeiten meiner Seiten gingen damit von 3.8sek auf 2.2sek.

[Tsturm]

Das Umziehen des Tablet-Folders nach ./www/pgm2/tablet/ hat eine deutliche Verbesserung gebracht - Messung muss ich noch machen, aber der zweite Aufruf geht richtig flott - ganz ohne neuen Webserver...

Thx!
Zwei aber...
- Chrome zeigt, dass nur fhem-tablet-ui.min.js und zuwei images gecached werden. Die CSS sheets etc laden immer noch (wenn auch gefühlt schneller)
- tablet-UI-Update nicht mehr glücklich, schreibt fröhlich alles in die alte location

Noch eine Änderung:
   <script src="../pgm2/tablet/js/fhem-tablet-ui.min.js" defer></script>
hatte ich vorher auf "async" stehen, gefühlt hat das auch noch was gebracht.

Doch nochmals mit einem Webserver arbeiten...

[octek0815]

- tablet-UI-Update nicht mehr glücklich, schreibt fröhlich alles in die alte location

Das kannst du mit einem Link lösen.

[Mikka]

Hallo zusammen,

weiß zwar nicht ob das hier ganz reinpasst, aber wenn ich statt:

Code Auswählen Erweitern


    <script src="js/fhem-tablet-ui.js" defer></script>


Code Auswählen Erweitern


    <script src="js/fhem-tablet-ui.min.js" defer></script>


benutze, werden z. B. Icons wieftui-window und ftui-thermo nicht mehr angezeigt.

Mikka

[Tsturm]

Hallo zusammen, habe das Thema mal in fhemweb aufgemacht, Rudis Anteort zum Thema ist mir noch nicht klar... geht in die Tiefen von tablet-ui...

https://forum.fhem.de/index.php/topic,85555.msg779481.html#msg779481
Quote:

Wenn ich den Link richtig verstehe, verwendet Tablet-UI HTTPSRV. Ich verstehe weder den Sinn von HTTPSRV (FHEMWEB kann doch beliebige Dateien ausliefern), noch warum Tablet-UI auf HTTPSRV besteht.

Btw. pgm2 muss es nicht sein, FHEMWEB liefert alles aus, was in www steht.


Viele Grüße timmo

[setstate]

Ja tatsächlich,

http://fhem:8083/fhem/tablet/index.html

funktioniert (inkl. Cache), mit der default Skript Definition

Code Auswählen Erweitern

<script src="js/fhem-tablet-ui.js" defer></script>

kleiner Nachteil:
. man muss das File immer angeben, http://fhem:8083/fhem/tablet/ funktioniert nicht
- die Quicklinks aus dem FHEMWEB gibt es nur mit HTTPSRV

Am besten die HTTPSRV Definitionen löschen. Man bekommt sonst Vermischungen und es werden nur einige Files gecached.

[Tsturm]

Habe etwas Interessantes gefunden:

Ich habe eine weitere FHEMWEB Instanz für Tablet-UI mit Port 8087 aufgemacht - ohne HTTPS. Wenn ich diesen Port verwende, werden alle Dateien wunderbar gecached - und die Tablet-UI fliegt. Man muss sich natürlich in der richtigen FHEMWeb-Instanz befinden, damit Tablet-UI ohne HTTPS aufgerufen wird. Für den mobilen Zugang einfach die URL mit dem richtigen Port nutzen (ich gehe hier über VPN on Demand, so dass das sicher ist).

Code Auswählen Erweitern

Internals:
   CONNECTS   82
   CSRFTOKEN  csrf_323432897555053
   DEF        8087 global
   FD         14
   NAME       WEB_Tablet_UI
   NR         204
   NTFY_ORDER 50-WEB_Tablet_UI
   PORT       8087
   STATE      Initialized
   TYPE       FHEMWEB
Attributes:
   CORS       1
   JavaScripts codemirror/fhem_codemirror.js
   SVGcache   1
   codemirrorParam { "lineWrapping":true }
   confirmDelete 0
   confirmJSError 0
   iconPath   fhemSVG:openautomation:default:icons_small
   longpoll   websocket
   mainInputLength 80
   room       9.0_System

Wenn man sich die Header der Seite über HTTPS im Dev-Board anschaut, sieht man, das beim https im ersten Aufruf die no-cache parameter gesetzt werden:

Code Auswählen Erweitern

GET wss://192.168.178.2:8083/fhem/?XHR=1&inform=type=status;filter=WEB_Tablet_UI,Garage,Licht_01_Garten_struc,Kueche_Sw_LED,EG_Rolladen,Stereo_struc,Kaffee_plug,Licht_06_Haus_struc,Licht_02_Garage_struc,Licht_03_Mitte_struc,Licht_04_Deck_struc,Licht_05_Strasse_struc,RainSW_2_4,RainSW_2_1,RainSW_1_3,RainSW_2_2,RainSW_2_3,RainSW_1_1,RainSW_1_2,RainSW_1_4,Rain_Para,Rain_2_4_counter,Rain_2_1_counter,Rain_1_3_counter,Rain_2_2_counter,Rain_2_3_counter,Rain_1_1_counter,Rain_1_2_counter,Rain_1_4_counter,%20STATE%20longpoll%20target_2_4_min%20pulseTimePerDayMin%20target_2_1_min%20target_1_3_min%20target_2_2_min%20target_2_3_min%20target_1_1_min%20target_1_2_min%20target_1_4_min;since=1520767706411;fmt=JSON&timestamp=1520767706515 HTTP/1.1
Host: 192.168.178.2:8083
Connection: Upgrade
Pragma: no-cache
Cache-Control: no-cache
Upgrade: websocket
Origin: https://192.168.178.2:8083
Sec-WebSocket-Version: 13
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.186 Safari/537.36
DNT: 1
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9,de-DE;q=0.8,de;q=0.7
Cookie: AuthToken=dGltbW86dGpoc25pZTIxIQ==
Sec-WebSocket-Key: pF2LqeTP/BP5iiJV/7q3Mg==
Sec-WebSocket-Extensions: permessage-deflate; client_max_window_bits
Mit dem Aufruf über port 8087 nichts mehr von Cachecontrol zu sehen.

Scheinbar ist die Behandlung von HTTPS-abfragen in FHEMWEB deutlich konservativer und fügt die No-Cache-Header ein. Drauf gekommen bin ich über diese Seite - wenn es auch nicht direkt damit zu tun hat:

http://securityevaluators.com/knowledge/case_studies/caching/

VG Timmo

[Tsturm]

Rudolf hatte noch eine Anmerkung.

https://forum.fhem.de/index.php/topic,85555.msg779952.html#msg779952

So langsam habe ich zwei Theorien, die gleichzeitg auftreten:

• Zitat Rudolf:
  "FHEMWEB Plugins (wie HTTPSRV, FLOORPLAN, etc) muessen auf Caching verzichten, es sei denn, sie implementieren die komplette Rueckgabe samt Header. Soweit ich sehe, macht HTTPSRV das nicht, insofern sind HTTPSRV Daten (aktuell) nicht cachebar."
  Ergebnis - Aufruf aus der FHEMWEB-Oberfläche via HTTPSRV hat kein Caching
  
• 
  Ungültiges HTTPS-Zertifikat (da kein öffentliches) führt dazu, das Chrome (und evtl andere Browser) das einfach nicht cachen.
  

Abhilfe - direkter Aufruf des Links ohne HTTPSRV, und ohne HTTPS über eigene HTTPWEB-Instanz (die man ja zur Sicherheit auch noch weiter einschränken kann). Das scheint konsistent mit dem oben genannten Verhalten zu sein.

VG Timmo



-