When you ask an AI to turn a webpage screenshot into code, what is it actually looking at? A typical webpage screenshot, processed by a vision-language model (VLM), is first split into many small patches, each becoming a "visual token". For UI screenshots, that's roughly 6,700 tokens.
To put that in perspective: if you ask a model to generate HTML/CSS based on these tokens, just "understanding the image" takes a long time. This is the familiar "time-to-first-token latency" problem — you send the request, the model silently loads the image, and only starts responding seconds later.
A new paper proposes UIPress, a method targeting visual token redundancy in UI-to-Code tasks.
Its core idea: don't let the model see all those tokens — let it see only the most important parts.
Specifically, UIPress inserts a lightweight "compression module" between the visual encoder (ViT) and the language decoder. Acting like an intelligent editor, it compresses the encoder's ~6,700 visual tokens into a fixed 256 tokens.
The compression itself is technically involved. It combines depthwise separable convolutions, element-guided spatial reweighting, and Transformer refinement. The compression module plus LoRA fine-tuning of the decoder adds only about 21.7 million trainable parameters — just 0.26% of the 8-billion-parameter base model.
Yet the results are striking:
- On the Design2Code benchmark, UIPress with 256 tokens achieves a CLIP score of 0.8127 — 7.5% higher than the uncompressed baseline and 4.6% higher than the strongest inference-time compression method.
- Time-to-first-token (TTFT) is accelerated 9.1x — from waiting several seconds to nearly instant.
- Title: UIPress: Optical Token Compression for UI-to-Code
- arXiv: 2604.09442
- Key finding: encoder-side learned visual token compression reduces ~6,700 tokens to 256, speeding up TTFT by 9.1x while improving accuracy
An important distinction: prior compression methods mostly "select" tokens to drop at inference time based on attention scores, or zero out low-attention features without actually shortening the sequence. Those approaches either fail to genuinely reduce computation or don't adapt well to UI screenshots, where information density is extremely uneven.
UIPress is different: it learns compression on the encoder side. Compression isn't based on generic heuristics but is trained specifically for UI-to-Code. The module learns which regions matter (buttons, input fields) and which can be ignored (backgrounds, whitespace).
The researchers note this is the first work applying "optical compression" (encoder-side learned compression) to the UI-to-Code task.
The bigger picture: AI-generated UI is essentially an extreme version of "image captioning" — the image is extremely information-dense while the code output is extremely structured. Processing six or seven thousand tokens every time is commercially impractical. UIPress pushes this from "impossible" toward "feasible".
Compute first, then render; look at what matters before writing code. This may become the standard workflow for AI front-end development.
---
Paper details