Ah, thank you - I hadn't come across the yuicompressor before. A quick comparison of some of the core feature is giving me a massive reduction if file size using it.
I completely agree that you can't rely on java being available - we don't run java on our servers for example. As far as my use case is concerned, I have to focus on displaying as quickly as possible from an empty cache, so I'm avoiding external scripts as our major speed problem is the number of requests required, and file size is only the secondary issue at the moment. I guess I will pre-run this over the most important features before rolling out updates - a quick test shows that this does not always work if you use php-shindig's compression, is this expected? Thanks again, Tim On Thu, 2009-01-22 at 16:32 +0100, Chris Chabot wrote: > On the php side of shindig it's using a php port of jsMin > (http://code.google.com/p/jsmin-php/), which as you noticed does a > 'decent job' at compressing javascript, but also isn't the best > compressor available. > > The huge upside of using a native JsMin implementation is that there's > no need to have a build process and external binaries and/or runtimes. > On shared hosts you can't count on 'java' being available through the > command line (and if it is, if it's a version that's able to run > things like the yuicompressor), nor can you count on make being > available since a lot of people run php-shindig on windows machines, > etc .. > > I've spend quite a few brain cycles on pondering the situation, I > would also prefer using yuicompressor for instance (which does a > better job of compressing and gets you much closer to iGoogle's > javascript size), but can't think of a reliable way of doing so that > would work for everyone, the only assumption we're able to make about > the target deployment platform is 'it runs php', which really limits > the options. > > One way to limit the impact though is by using the 'forcedJsLibs' > option, it forces the configured features to be included through an > external script tag, which means it's cachable by the browser, which > saves you most of the overhead. On production systems I find that > 'focedJsLibs' => 'dynamic-height:opensocial-0.8:views' works pretty > well. > > Alternatively you could make a shell script that runs something like > yuicompressor on every .js file in the features folder, and turn of > php-shindig's javascript compression. That would save you the initial > request overhead, and give you the best results... but you would have > to make sure to re-run this every time you update the feature files > > -- Chris > > On Thu, Jan 22, 2009 at 3:46 PM, Tim Wintle > <[email protected]> wrote: > I don't want to start a huge debate with this, but I have > noticed that > the (minified) javascript feature code that gets inserted into > gadgets > generated by shindig is significantly larger than the > javascript that > gets inserted by the iGoogle gadget server. > > The iGoogle feature code (which I am using as a baseline for > size since > I assume they have spent a long time optimising it) is often > 30% smaller > than the Shindig feature code. > > I'm using PHP, but I'm fairly sure it's similar for Java - > unless it > uses a much better minification algorithm that I haven't seen > elsewhere > online. > > For example, I haven't found an algorithm that automatically > converts to > use one character local variable names. If there is such an > algorithm > available to run the javascript through, can somebody point me > to it? > > I'm normally more or less in the the "optimise late" group of > people, > but this does seem important given the volume of gadgets that > are likely > to be served from Shindig. > > > > Possibilities: > > There seem to be a number of types of improvements that can be > made to > the code, some of them more obscurificating than others. > > At one end, there are changes such as: > > """ > var someVar = 1; > var anotherVar = 0; > """ > > becoming > > """ > var someVar = 1, > anotherVar = 0; > """ > > but the effect of these is minimal. > > Somewhere in the middle are changes to use one-character local > variable > names such as: > > """ > function parseUrlParams() { > var query, > l = document.location.href; > queryIdx = l.indexOf("?"); > hashIdx = l.indexOf("#"); > if (hashIdx === -1) { > query = l.substr(queryIdx + 1); > } else { > query = [l.substr(queryIdx + 1, hashIdx - queryIdx - 1), "&", > l.substr(hashIdx + 1)].join(""); > } > return query.split("&"); > } > """ > > becoming: > > """ > function parseUrlParams() { > var q, > l = document.location.href; > r = l.indexOf("?"); > h = l.indexOf("#"); > if (h === -1) { > query = l.substr(r + 1); > } else { > query = [l.substr(r + 1, h -r - 1), "&", > l.substr(h + 1)].join(""); > } > return query.split("&"); > } > """ > (saves about 60 bytes in the above example - bytes that > wouldn't have > been saved through the PHP minification algorithm ) > > > And at the really tough to read end are major re-factors of > the code, > which generally don't save that much space anyway. > > > Personally, I would like to suggest that features are patched > in the > first manner, and possibly in the second manner for tight > loops (where > the scope of a variable is less than, say, 6 lines - so you > can always > see where the variable was defined when you're looking through > the code) > > > I would also like to suggest that this is especially relevant > for the > most common features - which in our case are "core" and > "flash" - but I > assume that most Shindig users will find the opensocial core > features > just as important. > > > Tim Wintle > >
