Hi Ignacio, This is not only about loading time over the network, but also about script parsing by the web browser. In 98% of the case this is not an issue, but I have a very specific use case were the code is directly embedded on a special device which doesn't even have a real CPU but an ASIC emulating one. This device is really really not powerful and GWT is the only framework providing decent speed. I noticed significant differences in the script parsing delay as js sources are getting bigger.
In my case 100KB are a huge deal. Le samedi 26 novembre 2016 09:56:27 UTC+1, Ignacio Baca Moreno-Torres a écrit : > > But IMO if you really care user experience you have other places to > improve your page. I thinks updating to the last version is always a good > idea, if any security or compatibility blocker problem is detected in your > version you will need to update, and having a old version won't help. Also > this helps move forward the community and the lib (GWT), because everyone > focused in the last version, also focus the issues and improvements in that > version. > > The small step back eliminating the closure compiler just increase a bit > the code size of your app. But 100k?! did you see the trends and the > average code size of webs? > http://httparchive.org/trends.php?s=All&minlabel=Nov+15+2014&maxlabel=Nov+1+2016, > > you should note that even google.com uses 500k in 13request to load, and > it's ""just"" a text inbox in the center of your window ( > http://httparchive.org/viewsite.php?pageid=70036564). > > I might be wrong, but probably trying to embed the app.nocache.js in your > index.html will gain some milliseconds, probably just that dummy change > will get more ms than the cache-ables 100k you have lose without the > closure pass. If your app is quite big, various MBs, you should take care > than the first split point load a minimum as possible to show something to > the user. But, in your case, less than a 1M, I think that using split point > is not a good idea. Your code will get cached, and most of static apps > already has more than 500k of JS, so your single page app having a 500k-1M > of JS is pretty reasonable. > > You can go forward and apply the progressive web concepts ( > https://developers.google.com/web/progressive-web-apps/checklist). Pretty > sure you get there without the closure compiler ;). Service workers will > allow maximum control to preload other split point or resources, and to > absolutely control how your app caches, so you can use previous version, > load the next one and in the next page reload the new app version will be > used. This is not easy at all, but... some time we focus on the > optimization we have no control of (like the closure pass) and we don't > apply other we have control of, but that requires our effort. > > So, 😀 update to GWT 2.8! it's awesome!, try other solutions to improve > page loads and share how you do it! > > On Friday, November 25, 2016 at 10:39:44 PM UTC+1, Slava Pankov wrote: >> >> @Jens >> >> I've tried WITHOUT any success to use closure compiler externally with >> GWT 2.8 >> See my question here: >> https://groups.google.com/forum/#!searchin/google-web-toolkit/closure$20compiler%7Csort:date/google-web-toolkit/k_kjIv9Klsg/LZAZiUf9BAAJ >> Still want to find out exact steps to get it working :-( >> >> >> On Friday, November 25, 2016 at 2:43:11 AM UTC-8, Kirill Prazdnikov wrote: >>> >>> Hi Jens, >>> >>> What if we have SSO linker ? >>> Then no hacks is needed, right ? >>> Then just run the Google Closure Compiler on the output. >>> >> -- You received this message because you are subscribed to the Google Groups "GWT Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/d/optout.
