Library size.. 470KB?

[customlogic]

Why is the final js file 470KB? That seems super huge

[mflux]

Hmm.. not sure. It's always been floating at about 380kb, it's expanded recently because we're also adding the fonts. I'll try to figure this out.

[customlogic]

The module source directory is 120K all up (including fonts)... what are other code are we pulling in that's so huge?

[mflux]

I've no idea.

[mflux]

I minified it and got us to 108kb.

[customlogic]

The size has jumped to 467KB minified (1.3MB js un-minified). Is something going on with the new fonts?

[mflux]

I trimmed the font size back down. The heiro generated font with incorrect kerning was 72.2kb. The bmfont version is now 89.4kb (I'm not sure what it was before I fixed it but it was way bigger). I think I might be able to shrink it down some more by trimming more off the borders but we'll leave it for the time being.

The .fnt file inflated by 40kb... there's not much we can do about that I think. The new fnt file has actual kerning information whereas the old one (hiero) didn't. We might be able to trim it smaller by converting it to binary later.

[mflux]

So the fixed font has increased about 60kb giving us a minified build size of 283kb. I'm not actually sure where the remaining minified 120kb of stuff is coming from :/ I don't think it's the font.

[mflux]

Alright I've investigated supporting binary. I'm currently stuck at trying to embed a binary file directly in JS.

It doesn't look like we can embed binary directly in JS without converting it to some other format first (hexadecimal). This gives us a bit of a size saving, but we'd have to write the decoding and I don't really know how to write that at the moment.

The real way to fix the filesize problem is load binaries (image and fnt) from directories. Sans that, we have to live with the filesizes.

[customlogic]

Is there any way to find out what libraries are contributing to the file size? I'm curious what's in that 120kb

On Monday, 17 October 2016, Michael Chang notifications@github.com wrote:

Alright I've investigated supporting binary. I'm currently stuck at trying to embed a binary file directly in JS.

It doesn't look like we can embed binary directly in JS without converting it to some other format first (hexadecimal). This gives us a bit of a size saving, but we'd have to write the decoding and I don't really know how to write that at the moment.

The real way to fix the filesize problem is load binaries (image and fnt) from directories. Sans that, we have to live with the filesizes.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/dataarts/dat.guiVR/issues/38#issuecomment-254371646, or mute the thread https://github.com/notifications/unsubscribe-auth/ABHLpJCPNarv9POZbJWATFCyELCnLp_tks5q1BAbgaJpZM4KIEqU .

[mflux]

Without the font files we're actually only at 90kb minified.

I haven't found a way to find out how much a lib contributes to filesize. If you find that let me know... I'm really curious about that.

[mflux]

We're only really using two dependencies, parse-bmt-font-ascii and three-bmfont-text, both are extremely small.

[mflux]

So according to 'kit deps' tool: https://github.com/mikermcneil/kit#kit-deps

So that's only 24kb worth of dependencies. The rest is our code + the font asset. Like I said though... the font asset is not optimized to be loaded this way. The FNT format itself as ascii is 20.3kb, the image as base64 is 120kb (even though the image is 89.4kb).

[mflux]

I just checked out the XML fnt format and it's way worse: 111kb.

We could probably save a whole bunch of memory if we only included the basic set of characters (no ligatures, accents etc).

[customlogic]

Strange, I ran that same 'kit deps' tool, and got quite different sizes. I think mine are more accurate, because 'three-bmfont-text' has lots of node_modules it requires.

[customlogic]

I compressed the font PNG file with http://compresspng.com/, taking the size from 90KB to 37KB. That gives us a total minified size of 213KB.

The quality of the type is slightly effected, but you can only notice up very close. (We can use a less aggressive compression if you think it's too chunky)

[customlogic]

If we need to crunch further, another place to get some savings is the FNT string. If we replace the "kerning first=" string in the file (about 1600 occurrences) with a shorter token, then find/replace with regex at run-time, we can save about 20KB of minified size. But that feels unnecessary now, but i'm writing the idea here in case we decide we need it later.