With 100 MB in Novelez, Which Files Should You Shrink First?

You upload the opening background, a few character poses, and several music tracks to a Novelez project. The story is still short, yet the storage meter has moved much farther than expected. The usual reaction is to compress everything at once. That saves space, but it can also damage the character art players stare at for minutes while leaving an unused music file untouched.

Novelez currently presents 100 MB of storage in its free beta and accepts PNG, JPG, WebP, and MP3 among its asset formats. Treat that capacity as a release budget, not as a target to fill. The useful question is not how many pictures or songs fit. It is which files appear in the section you plan to share, how large they actually are, and how much room the next revision will need.

Measure the project you have, not an imaginary average

Make a delivery folder outside Novelez before changing any files. Copy only the assets used by the current public section, then sort the folder by file size. Keep the original paintings, layered character files, and lossless audio masters somewhere else. The delivery copy can be compressed again; the master should not be rebuilt from a reduced file.

Record four totals: backgrounds, character images, music, and sound effects plus interface art. Also mark files that are not referenced by any current scene. This first inventory often changes the plan. Ten small expression files may occupy less space than one oversized background, while one long music track may outweigh an entire set of interface buttons.

Do not estimate from file names or canvas dimensions alone. Two images with the same width and height can have very different sizes because their formats, transparency, detail, and compression settings differ. Audio length matters, but bitrate and channel count also affect the encoded result. The bytes on disk are the baseline.

Leave revision room before you optimize

A project that reaches the limit on its first public version has no comfortable place for a corrected background, another expression, or a replacement track. Set aside revision room first. Twenty megabytes is a useful planning example for a 100 MB workspace, not a Novelez requirement. Your reserve may be larger if the opening is still changing or smaller if the project is nearly locked.

Now build a working allocation from measured files. One example might keep 7.2 MB for six delivery backgrounds, 7.2 MB for twelve character images, 28 MB for the music actually heard in the opening, and 4 MB for effects and interface art. Together with a 20 MB reserve, that uses 66.4 MB and leaves 33.6 MB unassigned. Those numbers are not a recommended asset count. They show why a budget should be made from real exports: you can see which category deserves attention without spending every remaining byte in advance.

A budget is a stop rule. When a new asset enters, decide whether it uses the unassigned space, replaces another file, or belongs in a later section. Quietly adding files until upload fails is not a plan.

Remove work the player cannot encounter

The safest byte is the one you never upload. Start with unused alternates, duplicate exports, old color tests, and assets for chapters outside the section being shared. Deleting them from the delivery set does not mean deleting the masters. It means separating today's playable promise from tomorrow's production archive.

This is also the right moment to question near-duplicates. If two backgrounds differ only because one contains baked-in dialogue or a tiny UI mark, move that text or interface element out of the image where possible. A separate story block is easier to edit and localize than another full-frame picture. Do not merge distinct expressions or story moments merely to hit a number, but do not keep a full duplicate for a detail the editor can handle separately.

Give backgrounds, sprites, and audio different treatment

Do not apply one compression preset to the whole folder. A painted background without transparency can often use lossy WebP or JPEG. A character image that needs transparent edges requires a format and setting that preserve its alpha channel. Novelez accepts WebP, and MDN describes WebP as supporting both lossy and lossless compression as well as transparency. web.dev reports that WebP files are often smaller than comparable JPEG or PNG files, but the exact saving depends on the source.

Resize to the largest dimensions the player actually sees before adjusting quality. Exporting a very large canvas and asking compression to solve the rest wastes bytes. Inspect faces, line art, gradients, and dark scenes at the displayed size after each export. If ringing around hair or banding in a night sky becomes visible, raise the quality or keep the better source format for that asset.

Transparency deserves a separate check. A background normally does not need it. A character sprite often does. Converting a transparent sprite to JPEG can replace the empty area with a solid box, so a small file is not automatically a usable file. Compare WebP and PNG versions in the player rather than accepting the smallest result in a file browser.

Music usually deserves an early look because duration accumulates quickly. MDN notes that a higher audio bitrate generally produces a larger encoded file and that additional channels can also increase size. Re-encode from a lossless master once, listen through headphones and ordinary speakers, and keep the smallest MP3 that still preserves the intended music. Repeatedly compressing an already compressed MP3 compounds artifacts.

Trim accidental silence at the beginning or end, but do not cut a loop point that the scene needs. A shorter file that clicks every time it repeats is not an optimization. For sound effects, remove unused long tails and duplicates, then test quiet details against the actual background music.

Optimize by player impact, not by percentage

After the first pass, sort the delivery folder by size again. Work from the largest file downward, but weigh each saving against what the player sees or hears.

A large background shown for five seconds may tolerate more reduction than a character face present through an entire conversation. A title image is encountered by everyone and deserves careful inspection. A music cue heard only in an unreleased branch should leave the delivery set entirely. This gives you a better order than asking every category to shrink by the same percentage.

Keep a small record beside the masters: delivery filename, source filename, output dimensions, format, compression setting, and final size. When an asset changes later, regenerate it from the same source with the same rule. Otherwise the project slowly fills with files made by settings nobody remembers.

Test the shared experience, not only the folder total

Upload the optimized delivery files to the appropriate Novelez project, reconnect any replaced assets, and play the opening from the title screen. Watch the first appearance of every background and character. Listen through transitions and loops. Follow each choice in the section, because an asset used only on the less obvious branch can be missed during a straight playthrough.

Then open the shared web experience on an ordinary laptop or phone rather than only the machine that exported the files. The storage total tells you whether the files fit. It does not tell you whether a face became muddy, a transparent edge gained a halo, or a music loop now clicks.

Novelez gives you the project workspace and browser preview. It does not decide which master can be discarded or which loss is acceptable for your story. Keep the archive outside the delivery set, measure before changing, remove assets outside the current promise, and spend the remaining bytes where players will notice them.

Which three files are largest in the section you plan to share, and would a player notice more if you reduced them, replaced them, or removed them from this release?