I know there has been some discussions about this in the past, but I wasn’t able to find any recent posts.
I’m using OpenFL to create many native mobile games, and would like to use the HTML5 target to create playable ads for various networks. That is all fine, however, the main pain point here is the output size of the js file.
According to most general guidelines, the total size of a playable ad should be ~1MB or less. I tested a build file with a simple
trace("hello world") using latest openfl+lime and compiled with
-final -Ddce=full , which came up with a 718KB (!) file, not including any images of course. Older discussions (e.g Empty OpenFL HTML5 export big size!) mention 240KB output file.
Did OpenFL become x3 massive in recent versions? Is there any way to reduce that file size further?
Some more flags you could add:
I doubt they will have a big impact though.
Adding these flags reduced the size to 705KB, so no big impact indeed.
Just as a comparison/rolemodel
Pixi.min.js (pixi 5) 342kb
Pixi.min.js (pixi 4) 427kb
Phaser.min.js (phaser 3) 864kb
Phaser.min.js (phaser 2) 813kb
Can somebody test the npm version of openfl? I have no idea how to get it running
Note : enabling DEFLATE/GZIP compression on the server allows to greatly reduce the size of content to download, since it’s supported by the majority of web browsers.
Example for Apache servers : put a file named
.htaccess in your game folder, with this content :
Here’s the full package size (which includes all OpenFL classes) in my “dist” directory for the dev version of OpenFL:
You can see the OpenFL library gzipped is 239KB, minified is 1.1MB and uncompressed 2.5MB.
If your server supports Brotli, the compressed size goes down to 178KB, and if you use the Haxelib release, we don’t compile all of the OpenFL library – just what you need.
The gzipped size is what the user will actually download. The nature of Haxe can lend itself to a larger file size before compressing.
Here are the GZIP sizes:
Pixi 5 - 92KB
Pixi 4 - 105KB
Phaser 3 - 234KB
Phaser 2 - 198KB
EDIT: Oh, and https://openfl.org/download has NPM instructions – pretty easy
Our NPM releases uses a modular approach, so tree-shaking is supported for reducing the required size for OpenFL.
So you can see that Pixi and Phaser have about a 140KB size difference between the two. Pixi is kind of like a Sprite and a Bitmap class, while Phaser is more full-featured. We are comparable to Phaser in size, today, when comparing the entire libraries.
Size for OpenFL has not been tested a lot – I can imagine reducing the size by allowing it to shed unused renderers or other codepaths, happy to work with anyone interested in pushing this farther.
A quick (but probably not the best) solution could be to add some
#if/#end blocks around renderer code, for example, like
#if openfl_disable_renderer_cairo. Same logic for audio, assets, fonts, etc…