Custom build size?

Submitted by bornmw on Fri, 11/16/2007 - 17:19.

Hi!

The only thing I need for my current site is AccordionContainer.
I'm making a custom build with profile:

dependencies ={
    layers:  [
        {
        name: "my.js",
        layerDependencies: [
            "dojo.js"
        ],
        dependencies: [
            "dijit.layout.AccordionContainer"
        ]
        }
    ],
    prefixes: [
        [ "dijit", "../dijit" ]
    ]
};

issuing

./build.sh profile=my action=release optimize=shrinksafe layerOptimize=shrinksafe localeList="en-us"

On my page I'm importing tundra.css, my.js and dojo.js
(actually dojo book custom build section doesn't give any
clue about the requirement to import css and dojo.js).

This results in 220Kb traffic for a simple page.
Is this the way it is supposed to be or am I doing something wrong?

Login or register to post comments
Subscribe post

well, just using accordion

Submitted by dante on Fri, 11/16/2007 - 18:56.

well, just using accordion you could probably safely strip about 40k of CSS away from tundra.css / tundra-rtl.css and dijit.css, but you'll have to add some back if you decided you want more.

you would need a dojo.js which clocks in now about 25k gzipd?

i've done custom builds for dojo + dijit._base + dijit._Widget + dijit._Templated which came to about 100k uncompressed, and about 50k gzipped. Adding accordion to that mix would be minimal I suspect.

So, i guess the answer is: yes. Unless you go in and gut the css for unused classes.

One option (if you aren't using custom code at all and not trunk) you can use the AOL CDN version of the release.

Or, you can just use AOL's CDN version of the CSS, which (in theory) might already be cached in the client browser by the time they even first visit your page. 'pawning' the load of images + css to AOL's CDN (only safe if you are using a release version of dojo), and just take the initial hit of the 100k of js or so.

Thanks for your

Submitted by bornmw on Fri, 11/16/2007 - 22:22.

Thanks for your answer.
Actually, doing build with optimize=packer layerOptimize=packer produced 160Kb of traffic.
Which, given the mentioned extra 40Kb css gain is ok.
Unfortunately, the 'packer' option results in runtime exception:

inClass is not defined
http://localhost:8080/my/dojo/dojo/dojo.js
Line 20

Is packer option tested and workable?

The build system is using

Submitted by jburke on Sat, 11/17/2007 - 00:45.

The build system is using packer version 3 (or something like that, not sure the exact version number), but we have seen some issues with it. I suggest just using shrinksafe and then gzipping the content after that. The size difference between the shrinksafe and the packer files are negligible after gzipping.

Ok Also, did I get it right

Submitted by bornmw on Sat, 11/17/2007 - 08:24.

Ok
Also, did I get it right that I need to load both
my.js and dojo.js on my pages?

yes. dojo.js is always at

Submitted by dante on Sat, 11/17/2007 - 14:59.

yes. dojo.js is always at least base, and unless you put extra dependencies in the dojo.js [implied] layer, the second additional file is "the rest of the layer"

Search