Dotaz: Zrychleni mobilniho klienta pro embedded WWW aplikaci

[RadekXxX]

Ahoj, mam nejaky hw s embedded serverem, ten distribuuje html kod pro klasicky prohlizec, pri otevreni se stahnou vsechny soubory, pak se zavola nejaka JS funkce login a dal vse bezi pres websocket. Tenky klient pro Android, iOS a WIN html kod zobrazuje pres nativni prohlizec, nacteni celeho webu a proste vseho trva asi 8 sekund, kdyz je 4G aspon na nejake urovni. Udelal jsem to, ze si ze serveru stahnu vsechny soubory (html, js a css) a ty ulozim do lokalni databaze s jejich otiskem, kdyz se soubory na serveru zmeni, tak si je aktualizuji, dal kdyz se chci pripojit, tak jen porovnam otisky, v 99% jsou beze zmeny, ze vsech souboru vygeneruju jeden html soubor, tzn. "script src=...." nahradim obsahem konkretniho souboru, css taky a vysledny soubor poslu do prohlizece, pak jenom zavolam js login, ktery navaze websocket a vse je ok, timto se dostanu asi na 2 sekundy (pri dobrem pripojeni). A ted 2 moje otazky...

1) Pokud pouziju na strane serveru na JS soubory nejaky minify, dostanu se s celkovym vyslednym html souborem z 800kb asi na 200kb, ale zrychleni to neprinese, u dost testovanych variant je nacitani webu spis pomalejsi, nacitani webu myslim, ze prohlizeci predhodim hotovy soubor a uz nic nemusi stahovat z internetu. Ma smysl teda delat nejake minify na JS a CSS nebo kde delam chybu ?

2) Aplikace ma asi 150 ikon a to je kolem 800 kB, prvne to fungovalo tak, ze tyhle ikony se posilaji na web aplikaci pres websocket a ukladaji se do nejake promenne v base64 (JS tyto ikony dynamicky vyuziva), vsechno funguje dobre, ale kdyz tyhle ikony zkusim ulozit do lokalni db a napevno je vlozit do html kodu jako promennou v base64, abych usetril prenos tech 800kB, tak vsechno funguje, ale doba nacteni teho vygenerovaneho html kodu, ktery ma asi 1MB se najednou zvysi asi na 20 sekund. Android, iOS i WIN nedokazou zpracovat vestsi html soubor nebo kde delam chybu ?

Ma nekdo nejakou radu ?

Odpovědi

[RadekXxX]

Omlouvam se za zalozeni vice stejnych vlaken, pri odeslani dotazu se nic nedelo a asi jsem kliknul vicekrat na dokonci, prosim o odstraneni duplikatu, dekuji.

[Gréta]

neni to vtom prohlížeči skovaný v cache a proto se to načítá víc rychlejc?? :O :O

pro firefox about:cache třeba :O :O

[j]

Chjo ... tvle, 1MB html je naprosto silene moc. Jako si uvedom, ze vubec nejde o prenos tech dat po siti, ale predevsim o to, ze ten browser to pak musi vsechno rozparsovat. A ty tomu jeste nalozis naprdel tim, ze to tlacis pres js pokud sem to dobre pochopil, takze to zhorsis jeste o dalsi rad.

To co tady popisujes, je snad vubec to nehorsi co se da s html a js zbastlit = vyrobis prazdnej web a pak ho dodelavas tim js, takze jako bonus prestanou fungovat vsechny cache.

---

Dete s tim guuglem dopice!

[OldFrog {Ondra Nemecek}]

Jako nebyl bych tak příkrý v hodnocení, vše je nejlepší hodnotit na základě analýzy, kdy se porovná, jaké zdržení přináší: čekání na server, přenos po síti, běh js kódu a renderování v prohlížeči.

Ale jinak souhlas, že to renderování může být na slabším hardware dost problém. Embedování ikon do html a podobné chytristické postupy mohou být na škodu. Zkontrolujte, že se dobře požívají cachovací hlavičky u všech servírovaných souborů, že se používá komprese a případně zvažte/zkontrolujte použití HTTP/2 https://www.vzhurudolu.cz/prirucka/http-2 Věci které se snažíte řešit po vlastní ose je už dnes vyřešena systémově a nejspíš lépe :)

[RadekXxX]

Pro prenos vsech dat pres websocket se pouziva komprese dat, coz ma taky znacny prinos na rychlost, serverova cas bezi na nejakem MCU, takze to neni zadny Apache, Nginx, ... kde by se dal jednoduse nasadit HTTP/2. Pokud se ikony stahuji pres websocket do promenne, tak je vse ok, ale chtel bych to vyresit tak, ze aplikace pri studenem startu nebude zadna data stahovat. Aplikace neni klasicky prohlizec na telefonu, ale je to primo napsana aplikace pro iOS a Android, html kod se vklada do WebView, proto chci cachovani vyresit primo v ramci aplikace.

[Max]

A je problém před to ten Nginx hodit? MCU -> http1/ Nginx -> http/2 client.
Ta stránka je malá, takže ten počet requestů bude ten problém. Ještě by mohl být problém výkon toho MCU při servírování dat, ale to by vše řešil předřazený Nginx.
Zdar Max

[RadekXxX]

Mezi server a clienta neni mozne nic vlozit, je to krabicka, kterou klient ve vlastni rezii zapoji do site. HTTP/2 se nevyuziva, to by se muselo cely doprogramovat a dlouhodobe testovat.

[RadekXxX]

Ne, co tyce bodu 1, tak zrychleni je minimalne o 6 sekund na pomalym zarizeni, jenom nechapu, proc minifikovany JS 800->200kB kod se parsuje pomaleji.

[OldFrog {Ondra Nemecek}]

Minifikace by neměla parsování zpomalit. Chyba bude IMHO někde jinde, například metodika měření nebo odlišná data, jiný stav cache atd. atd. Jinak webview má podle mě možnosti cachování stejně jako klasický prohlížeč, nutno se podívat na nastavení webview.

Jinak pokud byste místo webview použil klasickou mobilní aplikaci, tak budete přenášet skutečně jen aplikační data (nějaké to JSON API) zatímco aplikace si bude vše ponese s sebou (ikony, statická data, logiku vykreslování...), takže budete tam, kde chcete být. Jen na zvážení jako další možnost.

[RadekXxX]

Puvodni aplikace klienta fungovala jako klasicka aplikace, ktera prenasela pouze XML o zmene stavu ruznych prvku systemu, ale nebylo udrzitelne udrzovat web, ios a android,.. na stejne graficke a hlavne funkcni rovine, verze serveru se zmeni, klient neaktualizuje, ... udrzovat u klientske aplikace vice ruznych API pro komunikaci ze serverem,... a tech problemu bylo daleko vic.

K tomu mereni, na Win jsem pouzil klasicky dev console v chrome, na mobilnich klientech interni logger aplikace.

Pokud neresim ikony, tak se od studeneho startu aplikace v pripade, ze se nezmenila verze sablon, dostanu asi na 1 sekundu, kdy mam vykreslenou aplikaci vcetne veskere logiky, kdyz na tom stejnym zarizeni ten server otevru pres web prohlizec, tak su asi na 6ti sekundach, takze si uplne nemyslim, ze to je spatna cesta.

Jeste vyzkousim ty ikony do toho klienta nacpat pres lokalni volani JS pro WebView, ze bych mu ty data nacpal rovnou do ram, dam vedet jak jsem dopadl.

[ehmmm]

Takze v roce 2027 bude zuivatel resit, ze prohlizecem z te doby se nepripoji ke kusu vyrobenem v roce 2022. A pokud ano, tak stejne bude cele zobrazeni nejak rozhozene. Takze uzivatel stejne bude muset hledat nejaky stary prohlizec, nebo novy prohlizec prepinat do nejakeho kompatibilniho modu. Ale chapu, ze rozhodnuti uz bylo ucineno a je dulezite drzet krok z dobou.

[RadekXxX]

Asi jsi vubec nepochopil nebo necetl ty 2 otazky..., ale to je jedno, nevim proc:

1) Proc by se nepripojil, pro klasicky web prohlizec se nic nemeni, interni cache se tyka pouze mobilni aplikace, ktera si sama html upravuje

2) Proc by melo byt zobrazeni nejak rozhozene, kdyz se dal udrzuje html kod

3) Proc prepinat do kampatibilniho rezimu

4) To, ze nyni nepodporuje HTTP/2 neznamena, ze ho v budoucnu podporovat nebude, jestli ti jde o toto

[ehmmm]

Otazky jsem docela pochopil, jen jsem si chctel zanadavat na soucasny pristup, kdy vsechno musi byt webova javascriptova aplikace.

Myslis, ze zakaznik, ktery tu krabicku bude mit cca pet let, u ni bude prehravat firmware (nebo jak jinak nazvat ten webovy server v te krabicce)?

Nevim, co to je za krabicku, ale pokud se to podoba krabickam, ktere delame my, tak ta se dva tydny po zakoupeni az do konce sveho zivota na internet nepodiva. Maximalne se nekdo podiva na ni pres nejakou VPN.

Ale uznavam, ze jsem dost off-topic.

[RadekXxX]

A jeste jedna vec, pokud se pripojuji pres Chrome z Win, tak se normalne prenasi vsechny soubory, zadne spojovani souboru, ... Toto se tyka pouze mobilnich telefonu, kde neni dostatecny vykon

[Max]

Ověř si, zda používáš http/2. To by mohlo ušetřit spoustu requestů. Ta velikost té stránky mi přijde malá, takže co jiného, než počet requestů to musí být .
Jinak kešování si řeší prohlížeč sám, takže to suplování vlastní db, to mi přijde zbytečný.
Zdar Max

[Matlák]

Jenom zvědavý dotaz: proč vlastně ta aplikace není PWA? Asi by se tím plno práce ušetřilo, ne? Nemá náhodou Apple nějakou politiku omezování použití WebView v nativních aplikacích?