The work before the AI request.

Ask AI to improve a page and the visible part looks simple: describe the change, review the result. Behind that interaction, the editor has to assemble the page, preserve its structure and prepare the content the model needs to work with.

That preparation deserves serious engineering. DXPR Builder uses a Rust-powered optimizer, compiled to WebAssembly, to accelerate page-content processing. It is the processing stage behind our 10× faster claim. Model response time also depends on the provider, the chosen model and the request.

Speed is one part of the story. The other is the material we send: compact markup, clear structure and the right existing content for the edit. An AI-assisted page builder needs all three.

1. AssembleHTML, styles and scripts from the DXPR Builder container.
2. CompactRust processes the markup through WebAssembly.
3. PrepareDXPR resolves saved HTML and selects editing context.
4. RequestThe AI receives the prepared content and instructions.

Rust, running where the editing happens.

The optimizer runs in the editor’s browser. JavaScript encodes the HTML as UTF-8 bytes, passes it to the compiled Rust module and decodes the result back into a string. This processing step needs no separate server request.

WebAssembly makes the Rust implementation available inside the existing JavaScript application. Drupal still provides the content platform, and AI requests still follow the configured provider connection. Rust handles a focused piece of work where fast, structured processing matters.

The module parses the markup into a structured representation, then writes the optimized output. It reserves an output buffer based on the input size. The release configuration uses link-time optimization and a small-code-size setting: the optimizer has to be practical to deliver to a browser as well as fast to run.

Inside the optimizer.

Our optimizer builds on Wilson Lin’s minify-html. Its syntax-aware foundation matters: HTML, CSS and JavaScript each have rules that a blanket whitespace replacement cannot understand.

Whitespace that understands its context.

Whitespace is processed according to the surrounding element and namespace. Repeated spaces and formatting can be collapsed where appropriate, while whitespace-sensitive contexts such as <pre> receive different treatment. Content inside a code sample must remain meaningful after processing.

Smaller attributes, explicit structure.

The engine checks whether an attribute is boolean, has a redundant default value or can use a shorter quoted or unquoted representation. It compares the encoded lengths and selects the smaller form. Attributes are sorted within their output groups for deterministic serialization.

DXPR’s configuration keeps closing tags and the opening <html> and <head> tags. It also leaves the engine’s deliberately noncompliant compression options disabled. We keep explicit document boundaries while removing unnecessary syntax around them.

Dedicated processing for CSS and JavaScript.

CSS is processed with Lightning CSS, including inline style attributes. JavaScript uses minify-js, with separate handling for classic scripts and modules. Data blocks are handled separately from executable JavaScript.

For style and script blocks, the optimizer adopts the minified result only when parsing succeeds and the result is shorter. Otherwise it keeps the trimmed original. Inline style attributes follow their own CSS parse-and-serialize path.

Byte-level work with reusable lookup machinery.

The Rust implementation works on byte slices and uses character lookup tables, entity lookups and reusable pattern matchers. Entity and attribute handling follows the surrounding syntax, including the characters that must remain escaped. This is structured processing rather than repeatedly treating the page as an undifferentiated text string.

The engine also supports preserving brace-based and chevron-percent template syntax when configured. Those switches are available to callers; DXPR’s standard browser configuration leaves them off.

What makes the integration distinctly DXPR.

The minifier supplies the compression machinery. DXPR supplies knowledge of its own document format and the edit being requested. These decisions sit around the Rust module in the DXPR Builder integration.

One authoritative copy of HTML for the AI.

A DXPR Builder HTML element can carry an encoded persistence copy in data-az-persist. If the AI copied that old value into its response, the parser could restore it and override the new edit.

Before using that content as AI context, DXPR restores the saved inner HTML and removes the persistence attribute from the prepared copy. The AI works with the actual markup, without the encoded duplicate competing with it. This improves the edit round trip as well as removing redundant context.

Predictions shaped by the requested edit.

Replacing an element’s contents and replacing the entire element are different operations. DXPR’s streaming request path can prepare the existing inner HTML for the first, or the complete element for the second, and compact that prediction content with the Rust optimizer.

For insertions and additions, this placement-aware path skips the prediction: existing content is not a reliable prediction of new material. A whole-container target can use the full existing content. These are prediction decisions; the broader prompt can still carry context. How a prediction is used depends on the provider and model.

Content budgets that respect the task.

In the surrounding prompt-preparation code, rewrite and translation tasks cap reference material and place it before the content being transformed. Whole-container replacements retain the full existing page rather than truncating content the model must return. Long prompts can repeat the task near the end to keep the instruction close to the content.

These are application-level decisions, separate from Rust minification. Together they make preparation aware of both the document and the job. The code uses a token estimate for budgeting; actual token counts depend on the model’s tokenizer. A smaller byte count is useful evidence of compaction, not a promise of an identical percentage reduction in AI tokens.

Real input. Real output.

This small fixture was processed by the shipped DXPR WebAssembly module using the browser adapter’s default configuration. The result goes from 205 to 142 UTF-8 bytes: about 31% smaller.

<section class="campaign" data-azb="az_section">
  <!-- Campaign introduction -->
  <h2>  Hello, world!  </h2>
  <p>Build  your next campaign.</p>
  <button disabled="disabled">Join now</button>
</section>

<section class=campaign data-azb=az_section><h2>Hello, world!</h2><p>Build your next campaign.</p><button disabled>Join now</button></section>

The comment and redundant formatting are removed. The boolean attribute becomes shorter, the DXPR Builder attribute remains, and closing tags stay explicit. The disabled button stays disabled.

An illustrative output example, measured on 27 September 2026. The byte reduction describes this fixture; it is separate from the page-processing speed benchmark.

An editor that keeps working.

The browser integration reuses its initialization promise, so callers can share the module’s loading process. If the optimizer is unavailable or the adapter encounters an error, the adapter returns the original HTML. Container serialization and prediction preparation also have fallback paths.

That behavior matters in an editor: an optional optimization should preserve the ability to continue with the original content. The optimizer is also separate from AI-output filtering. Compacting markup and checking whether generated markup is allowed are different responsibilities.

Open foundations. Product-specific engineering.

The DXPR optimizer identifies its foundation as minify-html 0.16.4, by Wilson Lin, under the MIT license. Its CSS and JavaScript engines are part of that open-source lineage. Our implementation adds the WebAssembly interface and connects that processing to DXPR Builder serialization, content preparation and editing-aware AI requests.

That combination is the story behind Rust in DXPR: fast processing, carefully prepared context and an integration designed for the realities of editing a Drupal page.

Explore DXPR Builder or see how AI page building works in Drupal.