A performance workflow for generated website artwork

Budget by page, not by asset

A file can look small in isolation while a page quietly requests dozens of similar files. Inventory every artwork request on the route and separate first-screen, below-fold, interaction-triggered, and unused variants. The first-screen composition deserves the strictest attention because its download, decode, and paint can delay the page users see first.

Do not load a complete pack merely because it was delivered as a set. A case-study page may need many assets eventually, while the homepage only needs one representative scene and a few previews. Route-level selection is often a larger win than squeezing a few more bytes from every file.

Encode for the actual visual job

Choose a format after identifying whether the asset needs transparency, sharp graphic edges, photographic texture, or animation. Compare encodes at the displayed size, not only at full resolution. An oversized source scaled down by CSS still transfers and decodes the oversized source unless responsive variants are provided.

Preserve clean alpha edges when comparing formats. Aggressive compression can create color contamination around a transparent silhouette or blur the paper, ink, and material cues that make a visual direction coherent. The smallest file is not useful if the defining medium disappears.

Reserve space before the image arrives

Store correct intrinsic dimensions with every asset and render them in the markup. The browser can then calculate the aspect ratio before the bytes arrive. This avoids a common failure in artwork-heavy pages: headings and calls to action move because a late image claims space that was not reserved.

Use responsive sizing information so the image pipeline can choose a candidate close to the rendered width. A large desktop hero and a small mobile feature illustration should not receive the same raster by default. Keep the full silhouette when meaning depends on the whole object; use intentional art-directed crops only when a second composition has been reviewed.

Load in reading order

Give priority to the single image that is expected to define the first screen. Lazy-load artwork lower on the page and avoid preloading whole galleries. If a case study contains many transparent components, show a representative composition first and let the remaining implementation detail load as the reader reaches it.

For motion, prefer a static fallback plus lightweight transforms of purposeful layers when that explains the idea. Do not replace a simple two-layer movement with a full video by default. Pause nonessential motion outside the viewport and respect the user's reduced-motion setting without removing information.

Measure the final route

Test the production build, not only the asset directory. Inspect the network waterfall, decoded dimensions, first-screen paint, layout movement, and the route's total image transfer on a representative mobile viewport. Confirm that caching behaves as expected when an asset appears on more than one page.

Keep the review focused: homepage, the workflow page, and one image-heavy case study usually expose the important patterns. When a regression appears, fix the route-level cause—an eager gallery, wrong dimensions, an oversized source, or duplicated assets—before creating a new delivery system.

See the system in context

Its larger family spans research, scheduling, avatars, distribution, and plan scenes, making it a useful example of choosing which assets each route should actually load. See the anonymous AI content infrastructure artwork case study.

Continue with Transparent web assets that belong in the layout, or apply the method to your own public page in the free art-direction preview.

Ready to produce a coordinated pack? Start free with three credits.