Stirling PDF · Viewer · Help

Stirling PDF: zooming dense vector PDFs is very slow

Measure opening, navigation and server processing separately when technical drawings become difficult to use in the viewer.

Source date: 5 November 2026Editorial team: KAN KAI WORKSEditorially updated:

Quick answer

Slow zooming in a complex vector PDF does not automatically indicate a slow upload or server conversion. Measure opening, zooming and page navigation separately, then compare the same file on the same device in another viewer. The reported delay is not a general performance benchmark. A simplified preview needs legibility and scale checks, while the unchanged vector original remains preserved.

Source basis: Q1 · Q2 · Q3

Applies to
The archived report concerns Stirling PDF 3.2.0 and a dense CAD vector PDF. Its measured delay does not generalize to other documents or hardware.
How to verify the result
Repeated comparisons show that required navigation is usable, with legibility, required scale and content preserved; the original vector document remains available and unchanged.
Your first check

Does the delay occur while loading or only during navigation?

Open the same file and measure one fixed zoom operation in two viewers. Observe client and server before planning extra server capacity.

A technical drawing opens, but every zoom or pan takes unusually long. An archived Stirling PDF 3.2.0 report describes this with a dense vector drawing. Its timings are individual observations, not a general performance benchmark for Stirling or current releases. The precise renderer-level explanation was not independently established. Q1

Separate loading, viewing and processing

A slow upload, sluggish navigation and a server-side conversion job are different operations. The manufacturer documentation treats viewer functions and server processing separately. Q2 Q3 More server memory is not automatically a remedy for every delay visible in a browser.

Build a small measurement record

  1. Record the file and environment. Note page count, file size, drawing source, desktop or server version and browser version. File size alone does not fully describe how complex a vector page is to display.
  2. Measure three stages separately. Time loading to the first usable view, a fixed zoom step and navigation to a specified page. Repeat those actions under comparable conditions. This turns “everything is slow” into an operation that can actually be investigated.
  3. Compare an independent viewer. Use the same local file on the same computer. Smooth navigation there makes a fundamentally unreadable file less likely, but does not prove a particular defect in one rendering library.
  4. Correlate resource use with the action. Observe client CPU, memory and browser responsiveness alongside available server metrics during the exact slow step. An idle server with a busy client suggests a different investigation from an active server conversion process.
  5. Create a minimal comparison. Where possible, use an anonymised page or synthetic drawing with similar structure. Compare simple and dense pages. Ensure that reducing the example does not remove the property that triggers the delay.

Choose a bounded interim workflow

For review-only work, an appropriate alternative viewer may keep the task moving. A raster preview can change navigation behaviour but may sacrifice vector detail and searchable text. Keep the technical master and verify scale and legibility before using a converted copy for further work. Evaluate any software update against the same sample and operations.

For handoff, provide the three timings, version details, resource observations and a non-confidential sample. A screenshot alone does not show the delay; a concise description of the exact repeatable action is often more useful. Record whether the file was already local so that transfer speed is not confused with display speed.

Frequently asked questions

Is a 30 MB PDF automatically too large?

No. Page content, rendering behaviour and the environment also matter. Compare the specific operation.

Should I simply increase server capacity?

First establish whether server resources are actually limiting the operation during the observed delay.

Describe your case

Support with this issue

We can investigate document structure, viewer behaviour and resource demand with a reproducible sample.

Describe your case →Related service: Data & improvements

Sources