Uno strumento che sembra fare parte di ciò che ti serve, almeno per le applicazioni web Java, è Strumento per ottimizzare le risorse Web per Java (wro4j).

Free and Open Source Java project which brings together almost all the modern web tools: JsHint, CssLint, JsMin, Google Closure compressor, YUI Compressor, UglifyJs, Dojo Shrinksafe, Css Variables Support, JSON Compression, Less, Sass, CoffeeScript and much more. In the same time, the aim is to keep it as simple as possible and as extensible as possible in order to be easily adapted to application specific needs.

Easily improve your web application loading time. Keep project web resources (js & css) well organized, merge & minify them at run-time (using a simple filter) or build-time (using maven plugin) and has a dozen of features you may find useful when dealing with web resources.

Potresti anche controllare in RequireJS per vedere se questo ti aiuterà a definire quali file js il client dovrebbe scaricare in un particolare ambiente.

RequireJS is a JavaScript file and module loader. It is optimized for in-browser use, but it can be used in other JavaScript environments, like Rhino and Node. Using a modular script loader like RequireJS will improve the speed and quality of your code.

Se, come specificato, non è rilevante in questo caso particolare supportare gli utenti con JavaScript disabilitato, così come i motori di ricerca, quindi l'unico inconveniente che posso vedere potrebbe essere la performance .

Uso deliberatamente potrebbe .

In teoria:

• I server sono molto più potenti dei client e

• Le lingue sul lato server sono più veloci di JavaScript,

In pratica, d'altra parte:

• La maggior parte delle credenze degli sviluppatori che una cosa dovrebbe essere più veloce di un'altra è sbagliata. Solo un profiler sa la verità.

• Sono abbastanza sicuro che ci siano molte persone che hanno computer molto più velocemente di quelli che alcuni provider di hosting usano per tutti tranne le offerte più care,

• Se JavaScript era lento dieci anni fa, non è più il caso delle versioni recenti dei normali browser. Anche in IE, JavaScript è piuttosto veloce nelle ultime versioni.

• Inviando solo il JSON anziché l'HTML, puoi ridurre l'utilizzo della larghezza di banda (anche se questo dipende strongmente dal tuo caso particolare, dalle tecniche di memorizzazione nella cache che usi, ecc.)

Per quanto riguarda la tua domanda su minification e il fatto che non puoi farlo in runtime, fallo quando si distribuisce l'applicazione sul server. Ad esempio, prima di testare la tua app nell'ambiente di staging o di distribuirla in produzione, trasforma il codice JavaScript con Closure Compiler , riduci il tuo CSS con strumenti simili (o trasforma il tuo MENO in un CSS minificato, se questo è il caso), ecc.

Puoi facilmente automatizzare anche questo processo.

La parte difficile sarebbe trasformare anche il codice HTML per sostituire le chiamate a più file CSS o JavaScript tramite le chiamate a un CSS minificato e a un JavaScript minifatto. Dato che non vuoi usare i template (ad esempio potresti usare SSI , ma poi, non potresti usare il tuo app localmente senza un server locale), un trucco sporco sarebbe modificare il codice HTML stesso prima di distribuirlo.

Avviso: dirty hack.

Diciamo che hai:

<!--Start calls to JavaScript-->
<script src="js/vendors/jquery.js"></script>
<script src="js/class_a.js"></script>
<script src="js/class_b.js"></script>
<script src="js/main.js"></script>
<!--End calls to JavaScript-->

nel codice HTML sorgente e:

<script src="http://ajax.googleapis.com/ajax/libs/jquery/1.8.2/jquery.min.js"></script><scriptsrc="js/entire_app.min.js"></script>

in js-compact.txt .

Il tuo strumento automatico potrebbe cercare <!--Start calls to JavaScript--> e <!--End calls to JavaScript--> , rimuovere l'intero blocco, inclusi i commenti, e quindi sostituirlo con il contenuto di js-compact.txt .

In una versione più elaborata, puoi analizzare il tuo codice HTML, trovare e rimuovere tutte le chiamate su JavaScript e sostituirle con le chiamate al codice miniato.

È una buona idea spostare il codice dal web server al browser?

Smallish web application that uses a little bit of static HTML and relies on JavaScript to load the application data as JSON and dynamically create the web page elements from that.

Non vedo nulla di sbagliato in questo. La maggior parte di gmail funziona in questo modo. Creo deliberatamente pagine da JavaScript come tecnica di ottimizzazione quando c'è un sacco di HTML attorno a un po 'di dati.

Sicurezza

Una cosa da tenere a mente è che non è possibile implementare alcuna sicurezza sul lato client. Tutta la sicurezza deve essere eseguita sul lato server, anche se alcuni di questi (come la convalida dell'input e i messaggi di errore) sono duplicati sul lato client.

Anche Wikipedia che consente a chiunque di modificare qualsiasi cosa, di tenere traccia di tutte le attività e di effettuare i backup in modo che le modifiche siano facili da annullare. Ora impediscono anche agli utenti anonimi di creare nuovi articoli. Se l'applicazione esegue degli aggiornamenti, è necessario un componente lato server che controlli le autorizzazioni. Questo componente ha quasi certamente bisogno di un modo per tenere traccia di chi sta usando il sistema per qualsiasi richiesta. Questo non è qualcosa su cui puoi fidarti del lato client perché chiunque potrebbe creare un client che ha fatto qualcosa di malvagio (diamine, hanno il tuo codice sul proprio computer).

Compression

"Waste Not Want Not" sarebbe il mio primo approccio alla compressione CSS e JavaScript. La prima immagine scaricata potrebbe essere più grande di tutti i tuoi CSS e JavaScript messi insieme. Se si utilizza HTTPS, trovo che sia più veloce creare CSS e JavaScript in ogni pagina perché HTTPS disabilita il caching del browser e salva una richiesta sul server. Anche in questo caso, puoi inserire routine comuni in una cornice e chiamarle da ogni pagina come parent.myMethod(x) . Per HTTP, puoi inserire JavaScript e CSS comuni in file separati che verranno memorizzati nella cache del browser. Userei solo gli strumenti di compressione per ottimizzare quando tutto il resto è al limite, e poi farei in modo che la creazione della tua pagina sia certa che sta facendo la differenza.

Un ritorno dopo ogni% di co_de rende i CSS compressi abbastanza leggibili. A volte il finale finale facoltativo } previene i bug quando aggiungi un attributo aggiuntivo. Per gli stili che richiedono molti attributi è possibile aggiungere interruzioni di riga, ma senza spazi inutili. Questo ti dà il 95-98% della compressione massima possibile senza usare un'utilità di compressione.

Se fai attenzione con il tuo JavaScript, dovrebbe essere più piccolo dell'HTML che verrebbe utilizzato per costruire la stessa pagina. Lo lascerei leggibile. Usa le schede al posto degli spazi o indenta 2 spazi alla volta. Whitespace non rappresenterà più del 20% del tuo codice. Forse i nomi delle variabili leggibili aggiungono un altro 5%. Quando hai un bug, sarà molto più facile essere in grado di vedere quello che stai facendo, che probabilmente valga la pena di una dimensione extra.

I motivi più comuni della lentezza sono i problemi lato server e il download delle immagini. L'ottimizzazione delle query dovrebbe comportare il caricamento di pagine da oltre 30 secondi a meno di 1 secondo. A meno che non si tratti di un gioco, le persone non sono molto sensibili ai tempi di risposta totali inferiori a un secondo. Inoltre, la connessione Internet della maggior parte delle persone non è affidabile per i tempi di risposta < 1/2 secondo, quindi c'è sicuramente un punto di rendimenti decrescenti. Non vale la pena di cancellare 0,01 secondi di tempo di elaborazione rendendo il codice completamente illeggibile. Inoltre, il tuo server potrebbe impiegare 0,005 secondi per eseguire la compressione, quindi pre-comprimere o fare in modo che l'azione di comprimere il tuo CSS e JavaScript al volo non diventi più utile in termini di prestazioni.