Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: mise 27. 02. 2016, 22:28:08
-
Ahoj,
potřebuju poradit, jak komprimovat js a css v html stránce. Je to trochu komplikovaný tím, že to musí být v jednom html souboru a v něm musím být vše - obrázky, styly, js... Je to embeded zařízení, nelze na něm nastavit gzip (.htaccess) nebo něco podobného. Zkoušel jsem i různé kompresory html i js, ale porad je to jen zhusteny text.
Zkoušel jsem i base64, sice funguje, ale také to není ono
<script type="text/javascript" "src="data: text/javascript;base64,xxxxxx">
Lze nějak upravit tento kod, aby prohlížeč pobral komprimovaný js i css např. v gzip?
<script type="text/javascript" "src="pokus.js.gz">
Díky
-
Mohl bych vědět, jaký je k tomu konkrétně důvod?
-
...že to musí být v jednom html souboru a v něm musím být vše
Vůbec nechápu smysl... Různé SoC dělám také, ale ještě jsem se nikdy nesetkal se zařízením, resp typem serveru, který by uměl vrátit html, ale samostatný js soubor ne.
Vždyť to je pak přece otázka té strany co to zpracovává, ne? Přiteče HTML, v něm src, tak vytvořím nový request na nalinkovaný soubor.. Nechápu. Ale k věci..
Můžete si použít kompresi jakou chcete, pokud ji na druhé straně dokážete dekomprimovat. V JS si můžete v plaintextu poslat pouze metodu, která vám dokáže zbytek scriptů dekódovat a spustit..
-
Nezkoušel jsem, ale popis zdá se odpovídá. (http://maf.mozdev.org/maff-file-format.html)
-
Možná jsem se špatně vyjádřil. Do zařízení mohu nahrát jen jeden soubor html. Pokud chci i obrázky, tak musí být součástí tohoto souboru včetně js a css. Normálně linkovat nelze a z externího zdroje to nemá smysl. Narážím tam na hranici velikosti tohoto soboru na 128kB. Proto jsem chtěl nějak komprimovat js a css. U obrázku musím použít base64 a to takhle <img src="data: image/png;base64,xxxxxxxxxxx"> a něco podobného mohu i u css a js. Spíše bych chtěl vědět, jak to js a css komprimovat. Stačí obecně, do html to pak nějak dostanu.
Druhá věc je ten plaintext, kterému nerozumím a nevím jaké a jak použít metody? Komprimaci na straně normálního serveru chápu, ale tady je to jinak. Nejde mi lokálně např. komprimovaný javascript<script type="text/javascript" "src="pokus.js.gz"> Jak dekomprimovat soubor na stránce?
Pozn. maff soubory jsem používal pro ukládání stránek v prohlížeči s pluginem, ale to jsou jen zazipované soubory do jednoho a na straně prohlížeče. Co potřebuju je podobné souborům .mht (používá i IE a FF), ale nahrané do zařízení.
-
Oukej, no ale stejně by možná bylo lepší popsat, čeho se vlastně snažíte dosáhnout, možná existuje i úplně jiná a lepší cesta.
Pro mě je stále záhadou, proč to zařízení využívat k něčemu, k čemu evidentně není uzpůsobeno (webserver). Asi je to jiný případ, ale pro srovnání... U ESP8266 potřebuji vytvořit nějaký výstup, v podobě třeba grafu na webu. Ani by mě nenapadlo využít ESP jako standardní webserver přestože to umí. Jdu na to tedy jinak.. Vytvořím APP jiném serveru a z ESP si po MQTT servíruji jen data co potřebuji, případně vracím třeba JSON. Vznikne tak vlastně SPA aplikace, kdy jednou načtu HTML + scripty a dále překresluji jen co je třeba na základě dat z ESP pomocí KnockoutJS.
HTML není nic jiného než značkovací jazyk pro browser. Nativně neumí nic jiného než to co známe, resp může to dělat cokoliv, ale musel byste naučit daný browser to chápat. Jestliže nevrátíte všechny instrukce k vykreslení rovnou inline v dokumentu, jediná jiná možnost co znám a browsery spolehlivě podporují, dát jim v HTML jasně najevo, že si mají další instrukce sosnout jinde (link na externí JS/CSS).
-
Lepší cesta by samozřejmě byla to rozdělit na zařízení a server, jak píšete, ale snažím se z toho dostat maximum. Pravda, na úkor času. Chci "jen" zmenšit html soubor, abych tam dostal další obrázky a js. Podivuju se jen nad prohlížečema, že umí kde co. Komprese souborů mezi normálním serverem a jím v gzip není problém, ale nalinkovaný komprimovaný soubor už neumí (nebo spíše já).
Prostě obecně potřebuju nalinkovat zabalený soubor s javascriptem (jedno v cem gz,zip..), rozbalit, abych ten javascript mohl používat v prohlížeči.
Věděl bych sice o jedné prasárně, jak v js dekomprimovat i celou stránku a najednou ji zobrazit, ale to už je přes čáru (např. pomocí algoritmu LZW nebo LZMA). Také nevím, jestli by to vedlo k nějaké úspoře, protože to musí být v html uloženo textově.
Nu, nic. Byl to spíše takový výkřik do tmy "co kdyby to nějak šlo". Ale díky.
Pozn. Jedná se o zařízení SDS micro.
-
Rozumím čeho chcete dosáhnout, ale snažit se dostat maximum ze zařízení s mizerným výkonem skončí stejně vždy mizerným výsledkem :-)
Nevím, proč by bylo výhodné zatěžovat takové zařízení odesíláním nějakých třeba javascript knihoven, pokud tedy ten JS generován rovnou na něm. Vždyť i na webu, jestliže nemám prostředky na pokrytí všech requestů, využiji CDN a statický obsah deleguji na ně. CSS je totéž. Spíše bych se snažil minimalizovat zátěž, jakýkoliv jiný server to vrátí rychleji. A to nemluvím o případném konkurenčním přístupu.
Obecně bych šel ale ještě dál a vůbec neodesílal žádné HTML, ale jen minimalistický JSON a interface který to bude zpracovávat zařídil na zařízení k tomu určeném, tedy nějakém VPS ;)
-
Mohu-li se zeptat, k čemu bude dobré mít webserver, který umí poskytnout jeden statický, předem nahraný html soubor? :)
Ale jestli už jste rozchodil způsob, jak dekomprimovat webovou stránku javascriptem, tak do toho. Není to přes čáru, když to funguje, tak to plní účel.
-
Reálné řešení je ty soubory vystavit někde na internetu a odkazovat na ně.
V HTML žádná dekomprese dat standardizována ani implementována není, takže si jí jedině můžete sám naprogramovat v JavaScriptu. Vzhledem k tomu,že všechny běžně používané kompresní algoritmy mají na vstupu i na výstupu binární data, nemůžete je přímo použít, protože do HTML přímo binární data nedostanete – musel byste je zase nafouknout base64, stejně jako ten obrázek. Takže lepší bude nějaký kompresní algoritmus si upravit tak, aby na výstupu používal znaky povolené v HTML. Ideální bude, když pro HTML použijete nějaké jednobajtové kódování (takže pro češtinu nejspíš ISO-8859-2) a pokusíte se pro kompresi využít maximální množství dostupných znaků.
Ovšem pokud tam nepřikládáte nějaké velké soubory, pochybuju, že dokážete napsat dekompresní funkci, která bude menší, než rozdíl nekomprimovaných a komprimovaných dat. Takže zbývá možnost, že soubory „zkomprimujete“ změnou jejich obsahu – JavaScriptové funkce a proměnné budete pojmenovávat jedním písmenem, stejně tak ID elementů pro CSS (a třídy nahradíte ID). Případně hledejte „javascript minification“ pro další triky, které můžete použít na zmenšení JavaScriptu.
-
Filip: Ano,pro mě asi bude jediná cesta - minify. Použil jsem to na celou stránku včetně scriptu a stylu. Komprese celé stránky pomocí algoritmů LZxx asi nepřinese takový výsledek, protože to bude muset být v base64. Zařízení mi momentálně funguje a nechci úplně ztrácet čas vývojem šíleností (pro přidání dalších věcí použiju lepší hw).
P_V: Je to sice jedna "statická" stránka, ale načítá dynamicky pomocí ajaxu data. Např. je to řídící jednotka kotelny. Reguluje teplotu v nádržích a je k tomu malý web pro zobrazení informací o stavu. Aby ta stránka nějak vypadala, tak teploty zobrazuju v obrázku. Stránka musí být funkční v lokální síti a nezávislá na dalším serveru. Musí být taky zobrazitelná kdekoliv, kde je nějaký prohlížeč. Nepotřebuju výkon, jen se stáhne stránka, a pak si prohlížeč jen sosá data. Chtěl jsem jen maximalizovat možné využití řídící jednotky, protože na řízení prosesů má výkon pro mě až moc (řízení je napsáno v úplně odděleném skriptu v C).
Ano, řešením je server (je to i můj názor), ale je to hudba budoucnosti a také otázka financí. To nechám na majiteli a rád to přenechám odborníkům.
-
O co se snažíte je dost šílené, ale budiž.
- BASE64 vám místo neušetří, naopak, zabere ho více
- vyzkoušejte místo obrázků SVG, mohlo by to být výrazně menší
- nenapsal jste, zda jste schopen ovlivnit hlavičky toho HTML souboru. Pokud ano, mohl byste ho tam uložit už komprimovaný a adekvátně nastavit ty hlavičky
- veškerý JS minifikujte, odstraňte všechny komentáře a nepotřebné středníky, dá se to snadno automatizovat nástroji
- podobně minimalizujte CSS a výsledný HTML (odstranění mezer, komentářů, konců řádků, krátké názvy, ...)
- s použitím non UTF-8 kódování bych byl opatrný, úspora bude minimální
Zvažte použité knihovny, omezte množinu povolených browserů (hlavně ty starší), je toho hodně co se dá udělat. Přesto 128 kB není mnoho.
Přemýšlel bych, jestli to stojí za to. Ale je to dobré cvičení znalostí. Existují soutěže, co vše se vleze do 1 kb JS kódu. Je to inspirující čtení.
-
Komprese celé stránky pomocí algoritmů LZxx asi nepřinese takový výsledek, protože to bude muset být v base64.
Nevím, proč by to muselo být v base64. Ale hlavně je vám komprese celé stránky pomocí LZxx k ničemu, protože jediný způsob, jak to v prohlížeči dekomprimovat, je JavaScript, který by byl součástí té stránky.
-
- nenapsal jste, zda jste schopen ovlivnit hlavičky toho HTML souboru. Pokud ano, mohl byste ho tam uložit už komprimovaný a adekvátně nastavit ty hlavičky
Jaké přesně myslíte hlavičky? Něco jako tohle při komunikaci se serverem "Content-Encoding: gzip", to neovlivním. Nebo něco jiného? Mám k dispozici jen ten jeden html soubor.
-
"načítá dynamicky pomocí ajaxu data..."
Takže jste schopen na serveru generovat nějaká data dynamicky... Šlo by stejnou cestou generovat i to samotné html, při každém požadavku ho na serveru dekomprimovat z uloženého .gz a poslat ven? (Když už tedy není možné fidlat s tou hlavičkou content-encoding...)
Obrázky taky můžete udělat v svg, to je přímo v html.
-
To právě nemohu. Jde jenom o pár dat z měření. Zkouším teď výrobce, jestli nezmění hlavičky ve firmwaru. V podstatě by se v něm změnila hlavička a možná přípona souboru, více práce by s tím neměli. Určitě by se to hodilo více lidem.
Obrázky do svg už mám částečně převedené.
-
Mozna off-topic, mozna ne:
Podle popisu vlastnosti mi to pripomina SDS Micro/Macro, se kterym jsem koketoval cca pred 2 roky.
http://www.onlinetechnology.cz/
Kdyz jsem porad objevoval nove a nov drobne zrady, tak jsem dal nakonec do kotelny normalni PLC a k nemu nejake OvocePi.
-
Ano, je to SDS, psal jsem to dříve. FW je už lepší než před dvěma roky. Pravda, má to svá omezení, ale pro tyhle účely to stačí.
-
Ano, je to SDS, psal jsem to dříve. FW je už lepší než před dvěma roky. Pravda, má to svá omezení, ale pro tyhle účely to stačí.
Tenkrat to ani neumelo v tom jejich klonu jazyka C poslat nebo prijmout UDP paket delsi nez cca 512 bajtu. Nemelo to baterku, takze si to nepamatovalo stav citacu po odpojeni napajeni. Jejich "cloud" pro archivaci hodnot byl tragickej. Pokud si chces usetrit starosti, tak kup jakykoliv nejlevnejsi CokolivPi a udelej si webovy nebo jakykoliv jiny server pro lidi na nem. Ten server v SDS byl tenkrat dobrej fakt jenom na cteni/ovladani vstupu/vystupu.
-
To C je tragické, ale mají novější jednotku BIG s lepším C (nemám odzkoušené). Baterku také mají už v jednom hw. Neměl jsem s tím větší problémy a sdsc program dělá co má a hlavně se neseká - mluvím o části PLC. Mám v tom napsanou docela velkou aplikaci. HTML je sice takové malé neštěstí, ale asi to stačí.
Mě to funguje, jenom jsem to chtěl rozšířit. Nedělám to pro sebe, proto tam nechci mít RPi (server, o který bych se musel starat). Mám sice další projekty s SDS, tam bude server nevyhnutelný.