How to low poly svg quality and performance reference
- Step 1Pick a target file size — Decide your KB budget for the background. Use the density table below to choose a point count that lands under it — output size scales roughly linearly with triangle count.
- Step 2Set density accordingly — Lower density means fewer, larger triangles and a smaller file; higher density means finer texture and a larger file. Remember the 300-point cap when targeting very fine looks.
- Step 3Generate and read the metrics — Click Generate and check the metrics panel for the actual Points and Triangles. Use that to confirm your size estimate before committing.
- Step 4Minify the output — Run the SVG through /svg-tools/svg-pro-minifier to strip whitespace, drop the XML declaration, and shorten numbers. This typically trims a meaningful slice with no visual change.
- Step 5Decide placement strategy — For static backgrounds, inline the SVG or use it as a CSS background. To avoid scroll repaint on heavier meshes, promote the element to its own compositor layer with will-change: transform.
- Step 6Verify on a slow device — Test initial paint on a low-end device. If a dense mesh paints slowly, drop the density rather than reaching for a raster — there is no PNG export, so density is your main lever.
Point density to triangles, file size, and use
Triangle counts are measured averages from the real output (eight anchors plus N random interior points). Sizes are uncompressed for a 1200×600 canvas and gzip to roughly a third. The 300-point row is the hard maximum.
| Density (points) | Approx triangles | Uncompressed SVG | ~gzip | Best for |
|---|---|---|---|---|
| 8 (min) | ~22 | 3–5 KB | 1–2 KB | Minimal angular graphic |
| 30 | ~66 | 8–12 KB | 3–5 KB | Clean low-poly hero |
| 50 (default) | ~106 | 12–20 KB | 5–8 KB | Balanced general use |
| 100 | ~205 | 22–40 KB | 9–15 KB | Fine texture background |
| 200 | ~404 | 45–80 KB | 18–30 KB | Dense texture (watch paint) |
| 300 (max) | ~604 | 70–120 KB | 28–45 KB | Finest possible; near-grain |
Safe vs risky minifier passes for low-poly output
This output is many independent <polygon> fills plus one gradient-backed <rect>. Passes that merge shapes or strip attributes can break the per-triangle colouring. Run minification via svg-pro-minifier.
| Pass | Safe? | Why |
|---|---|---|
| Collapse whitespace / newlines | Safe | No structural change; biggest easy win on this output |
| Remove XML declaration / comments | Safe | The generator's output has no comments to keep |
| Shorten coordinate decimals | Safe | Points already use 1 decimal; further trimming is harmless |
| Convert colours to short hex | Safe | Per-triangle fills stay distinct |
| Merge paths / shapes | Risky | Would fuse separately-coloured triangles, destroying the look |
| Remove 'redundant' attributes | Risky | Could strip per-polygon fill or opacity |
Browser vs engine rendering of the same settings
Same geometry, different colouring. Measure in the browser, but ship-via-runner output will look slightly more banded. Plan palettes that read well either way.
| Aspect | Browser tool | Engine / runner |
|---|---|---|
| Triangle fill | Blended toward next swatch (smooth) | Flat palette-band colour |
| Opacity | Varies by Y (0.85 top → 1.0 bottom) | Fixed 0.92 |
| Backing rect | Smooth-stop gradient | Hard-stop banded gradient |
| File size | Comparable | Comparable (geometry identical) |
Cookbook
Sizing decisions and the markup characteristics that drive performance, with the safe minify and compositor-layer recipes.
Estimate size from density before generating
Output size tracks triangle count, which tracks point count. A quick back-of-envelope before you commit.
triangles ≈ 2 * (points + 8) uncompressed ≈ triangles * ~0.20 KB (1200x600, 4-colour palette) gzip ≈ uncompressed / 3 Example: 100 points -> ~205 tris -> ~40 KB -> ~13 KB gzip
Safe minify with svg-pro-minifier
Run the generated file through the server-safe minifier. Whitespace collapse and number shortening are the big wins; shape-merging is correctly avoided.
Before: <polygon points="412.3,118.7 740.0,0.0 600.0,300.0" fill="#8a93fa" opacity="0.95"/>
(pretty-printed, one per line, ~120 KB at 300 pts)
After: collapsed whitespace + short hex
(~30% smaller, identical render)
# Do NOT enable merge-paths: it would fuse coloured triangles.Promote to a compositor layer for smooth scroll
A dense mesh can trigger repaints during scroll. Promote the background SVG to its own GPU layer so the browser composites it instead of repainting.
.hero > svg {
will-change: transform; /* hints a separate layer */
transform: translateZ(0); /* forces compositing */
}
/* The pre-painted mesh now scrolls without repaint */When fineness costs too much, lower density
There is no PNG export, so if a 300-point mesh paints slowly on weak hardware, the fix is fewer triangles plus CSS blur to fake fineness — not rasterisation.
Slow on a low-end phone at 300 pts (~604 tris)? -> drop to 120 pts (~250 tris), add filter: blur(2px) = similar perceived smoothness, half the polygons
Inline vs external trade-off
Inlining avoids a request but adds bytes to the HTML; an external file caches separately. Choose by how the background is reused.
Inline <svg>...</svg> : no extra request, bytes in HTML,
best for a single critical hero
External url('bg.svg') : cacheable, reusable across pages,
best when many pages share itEdge cases and what actually happens
Wanting more than ~600 triangles
Not possibleDensity is capped at 300 points in both the UI slider and the schema, which yields about 604 triangles. The 1000–2000 triangle meshes seen elsewhere cannot be produced here; plan around the ~600 ceiling.
Expecting a PNG export for smaller files
Not availableOutput is SVG only. To reduce bytes, lower the density and run svg-pro-minifier. If you genuinely need a raster, rasterise the SVG yourself in a browser or editor afterward.
Dense mesh paints slowly on a low-end device
MitigateEach triangle is a separate DOM element, so a 600-polygon mesh has real initial-paint cost on weak hardware. Reduce density, add a small CSS blur to keep perceived smoothness, and promote the element to a compositor layer for scroll.
Running merge-paths in a minifier
Breaks outputMerging shapes fuses the independently-coloured triangles into one path and destroys the low-poly look. Avoid merge/collapse passes; svg-pro-minifier's safe defaults already steer clear of them.
Engine output looks more banded than the browser preview
ExpectedThe browser blends fills and varies opacity by Y; the engine paints flat band colours at fixed 0.92 opacity. Same file size, slightly different look — measure size in either, but preview colour in the path you will ship.
Gzip savings smaller than hoped
ExpectedMany distinct hex fills and coordinates limit redundancy, so gzip lands around a third rather than a tenth. Lowering density (fewer polygons) saves more than relying on compression alone.
Very large canvas with high density
SupportedA 3840-wide canvas at 300 points is allowed and still produces ~604 triangles (coordinates are larger, not more numerous). File size grows modestly from longer coordinate strings, not from more polygons.
Comparing file size to a raster hero
Context-dependentAt low-to-mid density the SVG is far smaller than an equivalent PNG and scales freely. At the 300-point max a heavy SVG can approach a small PNG's size — but it still scales without a second asset, which the PNG cannot.
Frequently asked questions
How many triangles do I get per density setting?
Roughly twice the point count plus the eight anchors: about 22 at 8 points, 106 at the default 50, and 604 at the 300-point maximum. The metrics panel reports the exact Triangles for each generated result.
What is the maximum triangle count?
About 604, from the 300-point cap. There is no way to exceed it — 300 is the hard limit in both the UI slider and the option schema. Galleries showing 1000-plus-triangle low-poly used a different tool.
How big is the file at each density?
Roughly 3–5 KB at 8 points, 12–20 KB at the default 50, and 70–120 KB at 300 points (uncompressed, 1200×600). Gzip brings each down to about a third. Size scales nearly linearly with triangle count.
Does a high-density SVG hurt rendering performance?
It can. Each triangle is its own DOM element, so a ~600-polygon mesh has noticeable initial paint on slow devices. Mitigate with lower density, a CSS blur, and promoting the element to a compositor layer.
Can I export a PNG to save bytes?
No — the only output is SVG. To shrink it, reduce density and run the minifier. If you must have a raster, export the SVG to PNG yourself in a browser or vector editor.
Which minifier passes are safe for this output?
Whitespace collapse, removing the XML declaration and comments, shortening decimals, and short-hex colours are all safe. Avoid merge-paths and aggressive attribute removal — they fuse or strip the per-triangle fills.
How should I minify it?
Run the file through /svg-tools/svg-pro-minifier, which applies the safe passes and leaves the per-polygon fills intact. It is server-safe, so you can also include it in an automated pipeline.
Why doesn't gzip shrink it more?
The output is full of distinct hex fills and unique coordinates, which limits the redundancy gzip exploits. You get roughly a third reduction; the bigger lever is generating fewer triangles in the first place.
Will the API output match what I see in the browser?
The geometry and file size will, but the colouring differs: the engine paints flat palette bands at fixed 0.92 opacity, while the browser blends fills and varies opacity by Y. Plan palettes that look good banded if you ship via the runner.
Can I use will-change to smooth scrolling?
Yes. Applying will-change: transform (and a translateZ(0)) to the background SVG promotes it to a GPU layer, so the browser composites the pre-painted mesh during scroll instead of repainting hundreds of polygons.
Does canvas size affect file size much?
Only modestly. A larger canvas lengthens coordinate strings but does not add polygons — triangle count depends on point density, not dimensions — so a 3840-wide mesh at a given density is only slightly larger than a 1200-wide one.
When is SVG worse than a raster here?
Rarely. Only at the 300-point maximum does a heavy SVG approach a small PNG in bytes, and even then it scales to any size without a second asset. For most densities the SVG is both smaller and infinitely scalable.
Privacy first
Every JAD SVG tool runs entirely in your browser using the DOM API and Canvas. Your SVG files never leave your device — verified by zero outbound network requests during processing.