SVG motor and pump graphics remain 200-300 kB after compression, raising concern about Perspective page performance. That size alone is not a failure threshold. With the stated maximum of four or five graphics on one page, the raw SVG volume is 0.8-1.5 MB; the number that matters is measured loading and animation timing on the intended client, together with the complexity inside each SVG. This is graphics workload, not an arbitrary 100 kB rule.
Symptom and loading envelope
The project contains 15-20 SVG assets, but page-level demand is the useful quantity because only four or five will appear together. Loading every asset simultaneously would represent 3-6 MB at 200-300 kB each, while the stated page design represents a much smaller 0.8-1.5 MB range.
The 100 kB figure is a design target, not a demonstrated Perspective cutoff. A 250 kB SVG with simple geometry can behave better than a smaller file containing thousands of short segments, transforms, and separately styled objects.
| Quantity | Observed value or limit | Where to read it |
|---|---|---|
| Individual optimized SVG | About 200-300 kB; examples reached 250 kB and 292 kB | File properties and the browser network record |
| Original CAD export | Examples of about 700 kB and 975 kB | Source-file properties |
| Graphics on one page | Maximum four or five | Perspective view design |
| Raw SVG volume per representative page | 0.8-1.5 MB, derived from four or five files at 200-300 kB | Calculated from actual page membership |
| Acceptable response time | Project-specific; no value was stated | Client performance requirement and measured page trace |
SVG workload mechanism
File size primarily affects transfer time and parsing. The transfer relationship is transfer time = bytes / measured byte rate, before accounting for the other resources required by the page. Measure cold and repeat navigation separately because the browser and delivery path determine whether a resource is reused or transferred again.
Rendering cost follows geometry more closely than file size. CAD exporters commonly represent visible text as many small line segments rather than compact <text> elements. They may also export shadow lines, borders, title blocks, hidden detail, repeated strokes, and simple rectangular areas as collections of individual paths. The client must parse those objects, construct the vector scene, calculate transformed geometry, and paint it.
Animation increases the importance of scene complexity. A static graphic pays much of its cost during load and initial paint; an animated target may trigger repeated style, geometry, or paint work. A compressor can shorten markup and numeric formatting, but it cannot recover semantic structure when the CAD export describes a rectangle or lettering as hundreds of unrelated segments.
Diagnostic measurements
Separate network delay from rendering delay before redrawing the artwork. A slow fetch points toward asset volume or the delivery path. A fast fetch followed by delayed display, poor interaction, or uneven animation points toward parsing, geometry, or paint cost.
- Choose one of the largest SVGs and place it in an otherwise minimal Perspective view.
- Record its transferred bytes and loading duration with the browser network tools. Repeat the test after revisiting the view to expose the actual reuse behavior.
- Record a performance trace while the SVG first appears and while its intended animation runs. Look for time concentrated after the resource finishes loading.
- Inspect the SVG in an editor. Check whether lettering consists of outlines or tiny lines, whether shadows and drafting details are present, and whether simple areas use many path segments.
- Build the representative maximum page with four or five graphics. Test it on the least capable supported client and across the intended network path.
- Compare the same test with one manually simplified graphic. A large improvement identifies SVG structure as the controlling variable.
Geometry reduction procedure
- Keep the original CAD export as a master and edit a copy. This preserves a reference for checking deleted detail.
- Remove title blocks, borders, shadow lines, duplicate strokes, construction geometry, and details that provide no operator information.
- Replace outlined lettering with actual SVG text where the required font and appearance can be controlled. Outlined text preserves shape but carries many more nodes and segments.
- Redraw simple areas with primitives such as
<rect>instead of long collections of straight path segments. The supplied example represented a colored area with one rectangle element rather than many lines. - Join compatible objects where they share the same visual treatment, but retain separate animation targets. Merging an element that must change color, visibility, or position later removes that independent control boundary.
- Use curve simplification on dense paths, then compare the result at the largest displayed scale. Reduce nodes only until the visible silhouette or process detail starts to change.
- For badly structured exports, trace the required motor or pump geometry with efficient primitives and paths. Manual tracing is slower but can remove the structural waste that compressors leave untouched.
- Save as optimized SVG and retest after each major reduction. Preserve any element identifiers or grouping structure used by the animation.
Resizing primitives can leave scale transforms that alter stroke behavior. When a resized rectangle must become a path, convert it after positioning and inspect the resulting stroke widths. Apply conversion selectively because turning every primitive into a path can increase markup and remove useful semantics.
Page-level verification
Verify the finished view under its real operating load, not in the drawing editor. Load four or five representative graphics, activate their normal animations, and exercise page navigation and operator interactions at the same time.
| Test | Measurement | Decision |
|---|---|---|
| Cold navigation | Transferred bytes and time until the graphics are usable | Reduce aggregate assets or investigate delivery when transfer dominates |
| Repeat navigation | Whether SVGs transfer again and the resulting load time | Base the design on observed reuse behavior, not a caching assumption |
| Static display | CPU activity and interaction delay after loading | Simplify geometry when rendering remains expensive without animation |
| Animated display | Visual smoothness and time spent updating or painting | Reduce animated geometry or split static detail from animated elements |
| Target client | Worst supported device and intended network performance | Accept only against the project's operating requirement |
A successful result is stable navigation, interaction, and animation on the target client. Passing below 100 kB does not prove that result, and remaining at 250 kB does not disprove it.
Recurring optimization pitfalls
Repeated compression of inefficient CAD geometry produces diminishing returns. The compressor sees valid SVG markup; it does not know that hundreds of lines represent removable shadows, lettering, or one rectangular region.
Converting the graphic to PNG reduces vector parsing but also removes independently addressable vector elements needed for the stated animation. Likewise, merging every object into one path may reduce bytes while preventing separate parts from being animated. Keep static detail compact and preserve only the animation boundaries the application uses.
Testing one graphic on a development workstation misses the page-level case. The meaningful test includes four or five assets, the normal animation state, the intended client hardware, and cold as well as repeat navigation. Also check every simplified drawing against the CAD reference; aggressive node deletion can remove process-significant details even when the thumbnail still looks correct.
FAQ
What happens if an Ignition Perspective SVG stays at 250 kB?
Keep it when the representative page meets its loading, interaction, and animation requirements. Treat 250 kB as one input to the test, not an automatic failure.
What happens if five 300 kB SVGs load on one page?
The raw SVG volume is 1.5 MB before the page's other resources. Measure cold transfer time and post-load rendering on the target client to determine whether network volume or geometry is limiting performance.
What happens if CAD text remains converted to paths?
The client processes the letters as vector geometry rather than compact text, often creating many nodes and small line segments. Recreate the labels as SVG text when font behavior permits, or simplify only the outlines that must retain their exact shape.
What happens if optimization still leaves slow animation?
Stop editing when a minimal view shows the delay after transfer, manual geometry reduction no longer changes the trace, or behavior differs across clients without an SVG-level cause. Capture the SVG size, representative view, client details, network record, and performance trace. Escalate that package through the product's official support channel so the runtime behavior can be examined without guessing.