Keep Large JSON Previews Responsive in WordPress

An import can support a large JSON file while its preview still freezes the WordPress admin. That happened when a preview tried to turn too much of a package into an expandable tree during one request. The upload and import paths were separate from the failure. To fix it, I limited how much the preview displayed while preserving the complete file for validation and processing. Operators could still see the package structure, counts, representative values, and errors. The preview also stated when it had shortened a value or omitted items, so its display limits could not be mistaken for missing data.

Locate the stage that runs out of resources

I separated upload, preview, validation, and import instead of treating them as one action. The package reached the server and basic file checks passed. Failure appeared while building the human-readable tree. That distinction kept me from “fixing” the importer with larger memory limits.

Increasing limits would only move the threshold. A production tool needs behavior for files larger than its comfortable preview budget.

Show a useful sample of the package

The operator needs structure, representative values, item counts, warnings, and confidence that the selected package is the intended one. They do not need every character of every post body expanded in the browser.

I limited traversal depth, collection size, and displayed string length. Long strings show a safe excerpt with their original length. Large arrays show a sample and total count. Deep structures stop at a documented depth. The raw file remains untouched for validation and import.

Label shortened values and omitted items

Silent truncation is dangerous because a preview can appear to prove that omitted content does not exist. Every shortened value and collection is marked. The interface tells the operator that the preview is partial and keeps validation results separate from presentation limits.

A preview is trustworthy when it is honest about what it did not show.

Escape preview values as text

Large data often contains HTML, scripts, unusual Unicode, and malformed fragments. Rendering fewer bytes does not make those bytes safe. Preview values are escaped as text, keys are treated as data, and error messages do not echo arbitrary raw payloads into the admin page.

This also reduced browser work. A syntax-highlighted megabyte of HTML-like text can be expensive even when the server survives.

Return structured validation results

Instead of relying on the preview tree to communicate correctness, validation produces structured outcomes: manifest found, item count, required fields, unsupported types, checksum issues, media references, and parse errors with bounded context. The interface summarizes those outcomes and lets the import use the same validation service.

That prevents a familiar divergence where the preview accepts one interpretation and the import uses another.

Test large, deep, and malformed files

Tiny fixtures proved formatting, not the incident. I added tests with long content fields, wide arrays, deep nesting, hostile markup, invalid JSON near the end, and valid packages large enough to trigger the old behavior. Assertions covered memory-safe preview limits and preservation of the complete input for the importer.

I also checked an ordinary small file. Resource protection should not make the common case feel degraded.

The browser side needed limits as well. Even a safely truncated server response can create thousands of expandable nodes and expensive syntax highlighting. I render summaries lazily, cap initial expansion, and avoid binding an event listener to every value. The preview remains responsive enough to answer its real question: is this the package and structure the operator expected?

I included timing and limit information in diagnostics so a future failure is not mysterious. The result can say that parsing succeeded, validation examined all items, and presentation showed only the first limited sample. That distinction prevents support staff from interpreting an interface limit as lost data.

There is a business tradeoff in refusing an unlimited preview. Some users equate “show me everything” with safety. In practice, a frozen admin tab is less useful than a concise report with counts, hashes, and explicit omissions. Designing the explanation was therefore part of the performance fix.

I kept download access to the original package separate from the HTML preview. Authorized operators can retain or inspect the source through the documented data workflow, while the browser view stays bounded. That avoids sneaking a large unescaped payload back into the page under the label of “show raw.”

Because preview and validation are now separate, the interface can evolve without changing import rules. A future paginated tree, search box, or downloadable report remains a view over the same structured result. That separation lowers the risk of improving the admin experience later.

Give diagnostic screens explicit limits

Set separate limits for parsing, validation, and display. A preview should identify the package and help the operator inspect it without rendering every byte. Mark samples and shortened fields clearly, validate the full input through the actual import rules, and preserve access to the source through the authorized data workflow. Test an ordinary file alongside a large one and malformed input. Confirm that server memory stays within its budget and that the browser remains usable after the preview arrives.

Photo by Nemuel Sereti on Pexels.