LongWebBench: Evaluating Structural and Functional Webpage Generation in Long-Horizon Settings

# LongWebBench: Evaluating Structural and Functional Webpage Generation in Long-Horizon Settings
Source: [https://arxiv.org/html/2606.17727](https://arxiv.org/html/2606.17727)
Yi Zhao1\*,Zhen Yang1\*,Mengpan Chen2,Mingde Xu3,Shanghui Gong2, Xijun Liu4,Jibing Gong2†\\dagger,Jie Tang1†\\dagger, 1Tsinghua University,2Yanshan University,3University of Waterloo,4Beihang University

###### Abstract

Recent vision\-language models \(VLMs\) have shown promising progress in generating webpages from visual inputs, yet existing evaluations mainly focus on short, single\-screen, and largely static webpages\. We introduceLongWebBench, a benchmark for evaluating long\-horizon webpage generation from both structural and functional perspectives\. LongWebBench contains 490 real\-world long webpages for structural fidelity evaluation and 507 goal\-oriented interaction tasks over 129 webpages for functional evaluation\. It employs two complementary protocols: a multi\-dimensional VLM\-based metric for assessing long\-range structural coherence, and a DOM\-augmented agent\-based pipeline for end\-to\-end functional verification\. We further examine the automatic evaluation protocols through human agreement analysis\. Experiments with state\-of\-the\-art open\-source and proprietary VLMs under single\-image and multi\-image settings reveal that structural fidelity degrades as webpage length increases, while visually plausible generations often fail to support executable multi\-step interactions\. These results highlight the need to evaluate long webpage generation beyond visual similarity, with executable interaction as a core criterion\. Our code and data are available at[https://github\.com/zheny2751\-dotcom/LongWebBench](https://github.com/zheny2751-dotcom/LongWebBench)\.

LongWebBench: Evaluating Structural and Functional Webpage Generation in Long\-Horizon Settings

Yi Zhao1\*, Zhen Yang1\*, Mengpan Chen2, Mingde Xu3, Shanghui Gong2,Xijun Liu4,Jibing Gong2†\\dagger,Jie Tang1†\\dagger,1Tsinghua University,2Yanshan University,3University of Waterloo,4Beihang University

††footnotetext:∗Equal contributions††footnotetext:†Corresponding authors## 1Introduction

Recent vision\-language models \(VLMs\)Liuet al\.\([2023](https://arxiv.org/html/2606.17727#bib.bib40)\); Wanget al\.\([2024](https://arxiv.org/html/2606.17727#bib.bib29)\); Yanget al\.\([2025](https://arxiv.org/html/2606.17727#bib.bib19)\); Wanget al\.\([2025](https://arxiv.org/html/2606.17727#bib.bib3)\); Teamet al\.\([2025a](https://arxiv.org/html/2606.17727#bib.bib26)\)have shown promising progress in generating front\-end code from visual inputs such as webpage screenshots\. Given a rendered interface, these models can produce HTML, CSS, and JavaScript that visually resemble the target pageJianget al\.\([2025](https://arxiv.org/html/2606.17727#bib.bib49)\); Lianget al\.\([2025](https://arxiv.org/html/2606.17727#bib.bib50)\)\. However, existing effortsYunet al\.\([2024](https://arxiv.org/html/2606.17727#bib.bib37)\); Tanet al\.\([2025](https://arxiv.org/html/2606.17727#bib.bib7)\); Niuet al\.\([2025](https://arxiv.org/html/2606.17727#bib.bib41)\); Zhaoet al\.\([2025](https://arxiv.org/html/2606.17727#bib.bib2)\); Wuet al\.\([2025](https://arxiv.org/html/2606.17727#bib.bib48)\)largely focus on short, single\-screen, and mostly static webpages, where success is primarily measured by local visual similarity\. Such settings provide limited evidence about whether models can generate long webpages that preserve global structure and support executable user interactions\.

![Refer to caption](https://arxiv.org/html/2606.17727v1/x1.png)Figure 1:Motivation of LongWebBench\. Existing evaluations mainly consider limited\-view reconstruction or isolated interactions, while LongWebBench evaluates long webpages through both structural fidelity and task\-level functional verification\. Empirical results under the single\-image setting illustrate that current VLMs still face challenges in both long\-range visual reconstruction and executable task completion\.Table 1:Comparison with existing webpage\-to\-code benchmarks\. Existing benchmarks mainly focus on short\-page visual validation or isolated interaction validation, while LongWebBench supports long webpages, multi\-image inputs, and goal\-driven functional validation\.BenchmarkVisual ValidationSingle\-Interaction ValidationFunctional ValidationLong\-WebPage SupportMulti\-Image SupportWeb2CodeYunet al\.\([2024](https://arxiv.org/html/2606.17727#bib.bib37)\)✓××××Interaction2CodeXiaoet al\.\([2024](https://arxiv.org/html/2606.17727#bib.bib33)\)✓✓×××Webcode2MGuiet al\.\([2025](https://arxiv.org/html/2606.17727#bib.bib38)\)✓××××Design2CodeSiet al\.\([2025](https://arxiv.org/html/2606.17727#bib.bib36)\)✓××××WebGen\-BenchLuet al\.\([2025](https://arxiv.org/html/2606.17727#bib.bib39)\)✓✓✓××Sketch2CodeLiet al\.\([2025](https://arxiv.org/html/2606.17727#bib.bib46)\)✓××××\\rowcolorblue\!8 LongWebBench✓✓✓✓✓

As illustrated in Figure[1](https://arxiv.org/html/2606.17727#S1.F1), this results in an evaluation gap between limited\-view webpage reconstruction and long\-horizon webpage generation with executable interactions\. Real\-world webpages often span multiple screens, contain repeated components, require style consistency across distant sections, and support multi\-step user goals\. These properties introduce two challenges beyond short static reconstruction\. Structurally, models must preserve page scale, global layout, section hierarchy, visual styling, and information density across the full webpage\. Functionally, models must synthesize interaction logic that supports user goals under browser execution\. A page may look plausible while still failing to open menus, filter content, navigate across sections, or submit forms, suggesting that long\-horizon webpage generation should be evaluated beyond static visual similarity\.

Despite growing interest in webpage\-to\-code evaluation, existing benchmarks do not jointly cover these requirements\. As summarized in Table[1](https://arxiv.org/html/2606.17727#S1.T1), prior benchmarks mainly emphasize visual fidelity on short webpagesYunet al\.\([2024](https://arxiv.org/html/2606.17727#bib.bib37)\); Guiet al\.\([2025](https://arxiv.org/html/2606.17727#bib.bib38)\); Siet al\.\([2025](https://arxiv.org/html/2606.17727#bib.bib36)\); Liet al\.\([2025](https://arxiv.org/html/2606.17727#bib.bib46)\)or isolated interaction validationXiaoet al\.\([2024](https://arxiv.org/html/2606.17727#bib.bib33)\)\. Although WebGen\-BenchLuet al\.\([2025](https://arxiv.org/html/2606.17727#bib.bib39)\)evaluates goal\-driven functionality, it does not target screenshot\-driven long webpage generation or long\-scroll structural consistency\. Consequently, existing benchmarks do not jointly assess global structure across long webpages and executable multi\-step user interactions\.

To address this gap, we introduceLongWebBench, a benchmark for evaluating long\-horizon webpage generation from both structural and functional perspectives\. LongWebBench contains two complementary tasks\.Webpage Visual Fidelity Replication\(W\-VFR\) evaluates whether a model can reproduce the global structure and visual organization of long webpages, using 490 real\-world long webpages across diverse categories\.Webpage Functional Fidelity Realization\(W\-FFR\) evaluates whether a model can generate executable webpages that support goal\-oriented user interactions, using 507 interaction tasks over 129 webpages\. These two tasks separate visual fidelity from functional correctness, enabling a more diagnostic evaluation of webpage generation\.

LongWebBench further provides corresponding evaluation protocols: a multi\-dimensional VLM\-based metric for long\-range structural coherence, and a DOM\-augmented agent\-based pipeline that executes generated webpages in a browser environment to verify user\-goal completion\. For structural evaluation, we additionally incorporate DINO\-based feature similarity as an auxiliary signal for local visual styling consistency\. The benchmark supports both single\-image and multi\-image input settings, allowing us to analyze model behavior under different long\-page input constraints\.

We evaluate state\-of\-the\-art open\-source and proprietary VLMs on LongWebBench under both single\-image and multi\-image input settings\. Results show that long\-horizon webpage generation remains challenging: structural fidelity generally degrades as webpage length increases, while visually plausible generations often fail to support executable multi\-step interactions\. These findings highlight the need to evaluate webpage generation beyond static visual similarity, with executable interaction as a core criterion\.

Our contributions are summarized as follows:

- •We introduceLongWebBench, a benchmark for long\-horizon webpage generation with structural and functional evaluation\.
- •We construct two complementary tasks: W\-VFR with 490 real\-world long webpages and W\-FFR with 507 goal\-oriented tasks over 129 webpages\.
- •We design evaluation protocols for long\-range structural fidelity and end\-to\-end functional verification\.
- •We evaluate state\-of\-the\-art VLMs under single\-image and multi\-image settings, revealing challenges in structural consistency and executable functional interaction\.

## 2LongWebBench

We present the design ofLongWebBench, a benchmark for evaluating long\-horizon webpage generation from both structural and functional perspectives\. We first define long webpages and the two evaluation tasks, then describe the construction of W\-VFR and W\-FFR, and finally analyze the dataset coverage and complexity\.

### 2\.1Task Definition

#### Long Webpage\.

We define a long webpage as a webpage whose vertical length exceeds three viewport heights under a fixed1920×10801920\\times 1080browser resolution, requiring models to aggregate visual information across multiple screens\.

#### Webpage Visual Fidelity Replication \(W\-VFR\)\.

Given a target long webpage screenshot, W\-VFR evaluates whether a model can preserve the target visual structure, including page scale, global layout, section hierarchy, visual styling, and information density\. Functional correctness is not considered, and interactive elements are treated as static visual components\.

#### Webpage Functional Fidelity Realization \(W\-FFR\)\.

Given a target webpage screenshot and a set of user\-goal tasks, W\-FFR evaluates whether a model can generate an executable webpage that supports the specified user goals\. The screenshot provides component and state context, while evaluation focuses on whether prescribed actions lead to expected outcomes under browser execution\. Visual similarity is not required\.

### 2\.2Data Construction

W\-VFR: Long Webpage Collection\.We construct W\-VFR from real\-world webpages with diverse long\-form structures\. We define seven structural categories: informational articles, reference and documentation, product and service pages, community and discussion pages, multimedia and interactive pages, governmental and institutional pages, and data and resource aggregation pages\. For each category, annotators collect candidate URLs from representative public websites to cover diverse layout patterns, content densities, and section organizations\.

We then apply a multi\-stage curation pipeline to obtain high\-quality long\-webpage snapshots\. Candidate pages are rendered with Playwright under a fixed1920×10801920\\times 1080browser resolution, and pages are filtered out if they fail to render, do not satisfy the length requirement, require authentication or personalization, contain excessive overlays or sensitive personal content, or involve unbounded infinite scrolling\. We remove near\-duplicates using perceptual hashing over rendered screenshots and capture each remaining page as a stabilized rendered snapshot, isolating long\-page generation from external backend services and uncontrolled personalization\. All screenshots are manually verified to ensure correct rendering and absence of capture artifacts\. After filtering and verification, W\-VFR contains 490 long webpages, with 70 webpages in each category\. More details can be found in Appendix[A\.1](https://arxiv.org/html/2606.17727#A1.SS1)

![Refer to caption](https://arxiv.org/html/2606.17727v1/x2.png)Figure 2:Category distribution of LongWebBench\. W\-VFR is balanced across 7 structural webpage categories, while W\-FFR covers 13 user\-goal\-oriented functional categories\.#### W\-FFR: Functional Task Construction\.

While W\-VFR is organized around visual structure, W\-FFR is organized around user goals\. We first define 13 functional categories based on the primary services provided by modern webpages, including academic search, data visualization, education, travel, government services, news, finance, e\-commerce, community, jobs, developer documentation, real estate, and SaaS\. Candidate webpages are collected and curated using the same rendering and quality\-control pipeline as W\-VFR, ensuring that each selected page provides meaningful frontend\-observable interactions\.

For each selected webpage, we construct 3–4 user\-centered tasks that reflect realistic interaction goals on that page\. We follow a draft–review–rewrite–verify workflow: task drafts are first created following predefined task\-design guidelines, and annotators then rewrite, validate, and finalize them based on the rendered webpage\. During verification, annotators check whether each task is clear, feasible, non\-redundant, executable in the rendered webpage, and grounded in frontend\-observable state changes rather than external backend services\. Tasks that are ambiguous, backend\-dependent, redundant, or infeasible are removed or revised\. This process yields 129 webpages paired with 507 functional tasks, where each task serves as an independent evaluation instance\. More details can be found in Appendix[A\.2](https://arxiv.org/html/2606.17727#A1.SS2)

### 2\.3Data Analysis

Category Coverage\.LongWebBench covers diverse webpage structures and user goals\. For W\-VFR, the dataset is balanced across seven structural webpage categories, with 70 webpages per category\. For W\-FFR, webpages are organized into 13 user\-goal\-oriented functional categories, covering a broad range of real\-world service objectives\. As shown in Figure[2](https://arxiv.org/html/2606.17727#S2.F2), LongWebBench provides broad coverage across both visual structures and functional scenarios\.

Long\-Webpage Complexity\.To characterize the long\-horizon nature of W\-VFR, we measure the number of vertical viewports required to cover each webpage under the fixed1920×10801920\\times 1080resolution\. As shown in Figure[3\(a\)](https://arxiv.org/html/2606.17727#S2.F3.sf1), webpages exhibit a long\-tailed distribution\. Most webpages span 3–10 viewports, while pages exceeding 10 viewports account for about 31% of the dataset, with some extending up to 30 viewports\. This distribution supports evaluation across different degrees of long\-range visual structure and layout complexity\.

Interaction Complexity\.For W\-FFR, we report the number of explicit user actions required to complete each task\. As shown in Figure[3\(b\)](https://arxiv.org/html/2606.17727#S2.F3.sf2), most tasks require medium\-to\-long interaction sequences: 52\.27% require 4–6 steps, 20\.71% require at least 7 steps, and 27\.02% require 1–3 steps\. This distribution reflects the benchmark’s emphasis on coordinated, multi\-step interactions rather than isolated UI actions\.

![Refer to caption](https://arxiv.org/html/2606.17727v1/x3.png)\(a\)Distribution of vertical viewport counts in W\-VFR\.
![Refer to caption](https://arxiv.org/html/2606.17727v1/x4.png)\(b\)Distribution of interaction steps in W\-FFR\.

Figure 3:Analysis of dataset complexity\.
### 2\.4Benchmark Design Principles

LongWebBench is designed to disentangle two capabilities that are often conflated in webpage\-to\-code evaluation: long\-range visual\-structural reconstruction and executable interaction realization\. W\-VFR evaluates whether models can maintain coherent structure across extended page contexts, including repeated sections, cross\-section consistency, and long\-range layout organization, among others\. W\-FFR evaluates whether generated webpages can support user\-goal completion under browser execution, rather than merely rendering visually plausible interactive elements\. We evaluate stabilized rendered snapshots and frontend\-observable interactions, avoiding dependence on external backends while preserving the long\-page structure and multi\-step interaction patterns needed for reproducible evaluation\.

## 3Evaluation Protocols

We design two evaluation protocols for LongWebBench, as illustrated in Figure[4](https://arxiv.org/html/2606.17727#S3.F4)\. W\-VFR evaluates long\-range structural fidelity by comparing generated renderings with reference long webpages, while W\-FFR verifies whether generated webpages support executable user goals under browser execution\.

![Refer to caption](https://arxiv.org/html/2606.17727v1/x5.png)Figure 4:Overview of LongWebBench evaluation\. W\-VFR evaluates structural fidelity across five dimensions: page scale, global layout, section hierarchy, visual styling, and information density\. W\-FFR evaluates functional fidelity by executing goal\-oriented interaction tasks in a browser environment and reporting step\-, task\-, and page\-level success rates\.### 3\.1Evaluation Settings

LongWebBench supports two input settings\. In thesingle\-imagesetting, the full webpage screenshot is provided as one long image, testing whether models can process long visual contexts under their native image\-input constraints\. In themulti\-imagesetting, the screenshot is split into consecutive viewport\-sized tiles and provided in top\-to\-bottom order, reducing resolution constraints while requiring cross\-image integration\. These settings help separate input\-size limitations from long\-context structural reasoning challenges\.

### 3\.2Structural Fidelity Validation

To evaluate W\-VFR, we use a VLM\-based relative evaluator that compares a generated full\-page rendering with the reference long webpage screenshot\. The evaluator scores the generated page based only on visually observable evidence, explicitly excluding interactive behavior\. We useGPT\-4oas the primary structural evaluator with deterministic decoding, and provide the full prompt, model version, and scoring rubric in Appendix[B\.1](https://arxiv.org/html/2606.17727#A2.SS1)\.

The evaluator assigns scores on a 0–10 scale across five dimensions:page scale and scroll consistency,global layout consistency,section\-level structure and hierarchy,local visual styling consistency, andinformation density\. The overall W\-VFR score is the average of the five dimension scores\. To better capture low\-level appearance consistency, the local visual styling dimension combines VLM\-based scoring with DINO\-based feature similarity\.

We also report three availability metrics to separate input\-side constraints from generation quality\.Input Support Rate\(ISR\) measures the fraction of test cases accepted by the model or API before generation,HTML Validity Rate\(HVR\) measures, among supported cases, the proportion of outputs that contain a valid renderable HTML artifact, andCode Quality\(CQ\) measures the overall quality of the generated code\. Detailed definitions and scoring procedures are provided in Appendix[B\.2](https://arxiv.org/html/2606.17727#A2.SS2)\.

### 3\.3Functional Fidelity Validation

To evaluate W\-FFR, we use a task\-driven execution\-based protocol that verifies whether a generated webpage supports specified user goals under browser execution\. Unlike W\-VFR, functional fidelity does not evaluate visual similarity to the reference screenshot\. The screenshot and task descriptions provide component and state context, while evaluation focuses on whether prescribed interactions can be executed and lead to the expected outcomes\.

Each task is evaluated independently in a controlled browser environment\. A controller coordinates an actor agent, which executes the prescribed operations, and a critic agent, which checks whether the resulting DOM and rendered page state satisfy the task specification; both agents are powered byGemini\-3\-Pro\. A task is successful only if all required interaction steps are executable and collectively lead to the expected outcome\. Implementation details and prompts are provided in Appendix[B\.3](https://arxiv.org/html/2606.17727#A2.SS3)\.

We report three functional metrics\.Step Success Rate\(SSR\) measures the fraction of interaction steps that are executable and trigger the expected intermediate state change\.Task Success Rate\(TSR\) measures the fraction of tasks completed successfully and serves as the primary W\-FFR metric\.Page Success Rate\(PSR\) measures the fraction of webpages for which all associated tasks are completed successfully, providing a stricter estimate of page\-level functional robustness\.

## 4Experiments

Table 2:Performance comparison of VLMs on LongWebBench under single\-image and multi\-image input settings\. ISR, HVR, and CQ are reported as percentages \(%\); category\-wise and overall scores are on a 0–10 scale \(macro\-average\)\.Availability \(%\)Average Score \(0–10\)TypeModelISRHVRComm\.DataGov\.Info\.Prod\.Ref\.Trans\.OverallCQSingle\-Image InputOpen\-sourceKimi\-VL\-A3B\-Thinking100\.0078\.982\.692\.643\.362\.203\.022\.203\.952\.8792\.50Qwen3\-VL\-8B\-Instruct95\.7154\.373\.723\.643\.923\.173\.562\.024\.283\.4788\.38InternVL3\-78B100\.0081\.843\.483\.433\.853\.423\.352\.783\.503\.4094\.41GLM\-4\.1V\-9B\-Thinking\-Flash100\.0084\.905\.324\.275\.155\.325\.183\.345\.544\.8792\.95GLM\-4\.6V100\.0084\.295\.855\.556\.565\.645\.623\.936\.445\.6694\.06Qwen3\-VL\-235B\-A22B\-Instruct99\.8080\.785\.295\.196\.235\.724\.443\.405\.455\.1089\.20Closed\-sourceClaude\-Sonnet\-4\-5\-Thinking56\.1299\.645\.973\.494\.742\.583\.320\.296\.273\.8193\.75Claude\-Opus\-4\-5\-2025110156\.1299\.645\.953\.344\.702\.493\.400\.346\.673\.8493\.14GPT\-5\.295\.71100\.007\.076\.536\.576\.526\.075\.527\.206\.5094\.14GPT\-4o100\.0099\.393\.153\.123\.623\.053\.212\.603\.843\.2395\.59Gemini\-3\-Pro\-preview100\.00100\.007\.396\.896\.886\.886\.665\.836\.896\.7793\.00Gemini\-3\-Flash\-preview100\.00100\.006\.975\.956\.846\.776\.324\.876\.786\.3693\.31Doubao\-Seed\-1\-676\.3398\.934\.352\.894\.254\.514\.130\.455\.053\.6694\.58Multi\-Image InputOpen\-sourceKimi\-VL\-A3B\-Thinking100\.0080\.203\.003\.053\.522\.703\.332\.563\.633\.1289\.88Qwen3\-VL\-8B\-Instruct100\.0054\.694\.143\.814\.943\.314\.163\.234\.023\.9586\.72InternVL3\-78B99\.3977\.213\.533\.733\.513\.513\.653\.673\.723\.6294\.81GLM\-4\.1V\-9B\-Thinking\-Flash100\.0083\.061\.462\.711\.120\.390\.310\.310\.280\.9492\.59GLM\-4\.6V100\.0088\.165\.766\.166\.505\.625\.655\.796\.255\.9693\.54Qwen3\-VL\-235B\-A22B\-Instruct99\.8080\.576\.085\.686\.385\.985\.006\.035\.835\.8587\.43Closed\-sourceClaude\-Sonnet\-4\-5\-Thinking100\.0099\.396\.736\.617\.056\.977\.076\.046\.696\.7493\.79Claude\-Opus\-4\-5\-20251101100\.0097\.966\.836\.286\.516\.136\.516\.256\.496\.4393\.07GPT\-5\.2100\.0099\.596\.966\.245\.975\.855\.675\.926\.366\.1493\.95GPT\-4o100\.0099\.803\.393\.403\.913\.503\.443\.133\.923\.5394\.51Gemini\-3\-Pro\-preview100\.0099\.597\.517\.077\.437\.086\.997\.357\.087\.2292\.25Gemini\-3\-Flash\-preview100\.00100\.006\.836\.466\.886\.816\.575\.486\.706\.5392\.25Doubao\-Seed\-1\-6100\.0099\.394\.504\.575\.014\.964\.804\.395\.144\.7794\.59

### 4\.1Experimental Setup

#### Evaluated Models\.

We evaluate a broad set of state\-of\-the\-art VLMs, covering both proprietary models \(e\.g\., GPT\-5\.2Singhet al\.\([2025](https://arxiv.org/html/2606.17727#bib.bib35)\), GPT\-4oOpenAIet al\.\([2024](https://arxiv.org/html/2606.17727#bib.bib6)\), Claude\-Opus\-4\.5, Claude Sonnet\-4\-5\-Thinking, Gemini\-3\-ProComaniciet al\.\([2025](https://arxiv.org/html/2606.17727#bib.bib47)\), Gemini\-3\-Flash, and Doubao\-Seed\-1\-6\) and open\-source models \(e\.g\., GLM\-4\.6V , GLM\-4\.1V\-9B\-Thinking\-FlashTeamet al\.\([2025b](https://arxiv.org/html/2606.17727#bib.bib4)\), Qwen3\-VL\-235B\-A22B\-InstructYanget al\.\([2025](https://arxiv.org/html/2606.17727#bib.bib19)\), Qwen3\-VL\-8B\-Instruct, InternVL3\-78BWanget al\.\([2025](https://arxiv.org/html/2606.17727#bib.bib3)\), and Kimi\-VL\-A3B\-ThinkingTeamet al\.\([2025a](https://arxiv.org/html/2606.17727#bib.bib26)\)\)\. All models are evaluated with the same generation prompts\.

#### Evaluation Settings\.

We evaluate models under both single\-image and multi\-image settings\. W\-VFR is evaluated on the full model set when the input format is supported\. W\-FFR is evaluated on a representative subset due to the higher cost of browser\-based execution, covering both proprietary and open\-source models with different input capabilities and performance levels\. Additional implementation details are provided in Appendix[E\.2](https://arxiv.org/html/2606.17727#A5.SS2)\.

### 4\.2Structural Fidelity Results

Table[2](https://arxiv.org/html/2606.17727#S4.T2)reports W\-VFR results under both single\-image and multi\-image input settings\. Overall, current VLMs still achieve only moderate structural fidelity on long webpages, showing that long\-horizon webpage reconstruction remains challenging beyond local visual matching\. Under the single\-image setting, Gemini\-3\-Pro achieves the highest overall score, followed by GPT\-5\.2 and Gemini\-3\-Flash\. Strong open\-source models such as GLM\-4\.6V and Qwen3\-VL\-235B\-A22B\-Instruct are competitive, but still lag behind the best proprietary systems\. Multi\-image input improves input availability and often improves structural fidelity by reducing image\-size constraints, especially for Claude models\. However, the gains remain limited: even under the multi\-image setting, the best model still reaches only moderate fidelity\. This suggests that multi\-image input mainly alleviates input\-resolution constraints, but long\-webpage generation still requires robust cross\-image integration and global layout planning\.

### 4\.3Functional Fidelity Results

Table[3](https://arxiv.org/html/2606.17727#S4.T3)reports W\-FFR results under both input settings\. Due to the high cost of browser execution and agent\-based verification, we evaluate a representative subset covering strong closed\-source and competitive open\-source models from W\-VFR\. Functional fidelity is substantially more challenging than step\-level execution alone: models with high Step Success Rate \(SSR\) still show much lower Task Success Rate \(TSR\) and Page Success Rate \(PSR\), indicating error accumulation across multi\-step workflows and multiple tasks on the same page\. Claude\-Sonnet\-4\.5\-Thinking and Gemini\-3\-Pro perform best, reaching SSR above 86% and TSR around 58–59% under the single\-image setting, while their PSR remains below 22%\. Open\-source models such as GLM\-4\.6V and Qwen3\-VL\-235B\-A22B\-Instruct achieve much lower page\-level success, showing limited robustness in end\-to\-end functional realization\. Multi\-image input provides only limited and inconsistent gains, suggesting that executable interaction depends not only on input resolution, but also on correct interaction logic and state transitions\.

Table 3:W\-FFR results under single\-image and multi\-image input settings\. SSR, TSR, and PSR denote step, task, and page success rates, respectively\.ModelSSRTSRPSRSingle\-Image InputGLM\-4\.6V62\.5928\.395\.56Gemini\-3\-Pro\-preview87\.3058\.3817\.83Qwen3\-VL\-235B\-A22B\-Instruct60\.5223\.653\.13Claude\-Sonnet\-4\-5\-Thinking86\.9159\.4021\.78Multi\-Image InputGLM\-4\.6V64\.2030\.527\.03Gemini\-3\-Pro\-preview87\.9159\.2421\.09Qwen3\-VL\-235B\-A22B\-Instruct60\.3423\.276\.20Claude\-Sonnet\-4\-5\-Thinking86\.4655\.4717\.19
### 4\.4Effect of Length on Structural and Functional Fidelity

Webpage Length\.Figure[5](https://arxiv.org/html/2606.17727#S4.F5)shows W\-VFR performance across webpages with different numbers of vertical viewports\. Structural fidelity generally decreases as webpage length increases, indicating that long webpages require global layout planning, section ordering, and style consistency beyond local visual reconstruction\. Multi\-image input alleviates this degradation by preserving finer\-grained local details, but performance still drops on very long webpages, suggesting that robust cross\-segment integration remains challenging\.

![Refer to caption](https://arxiv.org/html/2606.17727v1/x6.png)

![Refer to caption](https://arxiv.org/html/2606.17727v1/x7.png)\(a\)Single\-image input\.
![Refer to caption](https://arxiv.org/html/2606.17727v1/x8.png)\(b\)Multi\-image input\.

Figure 5:W\-VFR performance across different webpage lengths\.![Refer to caption](https://arxiv.org/html/2606.17727v1/x9.png)

![Refer to caption](https://arxiv.org/html/2606.17727v1/x10.png)\(a\)Single\-image input\.
![Refer to caption](https://arxiv.org/html/2606.17727v1/x11.png)\(b\)Multi\-image input\.

Figure 6:W\-FFR success rate across different interaction lengths\.Interaction Length\.Figure[6](https://arxiv.org/html/2606.17727#S4.F6)shows W\-FFR success rates across tasks with different numbers of interaction steps\. Success rates generally decrease as interaction length increases, indicating that longer workflows amplify error accumulation and require more stable state tracking\. These results show that W\-FFR evaluates more than isolated clickability\. Generated webpages must maintain correct interaction logic and state transitions across multi\-step user goals, where early mistakes can propagate and prevent task completion\.

### 4\.5Robustness of Structural Evaluation

To examine whether W\-VFR scores depend on a single VLM evaluator, we conduct a cross\-judge robustness analysis\. We sample 100 test cases, each consisting of a reference screenshot and the corresponding generated rendering, from four representative models: GPT\-5\.2, Gemini\-3\-Pro, Qwen3\-VL\-235B\-A22B\-Instruct and InternVL3\-78B\. Using the same prompt and rubric, we score these samples with both GPT\-4o and Gemini\-3\-Flash\. As shown in Figure[7](https://arxiv.org/html/2606.17727#S4.F7), the two judges produce highly consistent results\. Their per\-model mean scores are nearly collinear, with Pearsonr=0\.992r=0\.992\. Pairwise ranking agreement is5/65/6\(83\.3%83\.3\\%\), with the only inversion occurring between GPT\-5\.2 and Gemini\-3\-Pro, whose scores differ by only0\.030\.03points\. These results indicate that our structural evaluation is robust to the choice of judge model\.

![Refer to caption](https://arxiv.org/html/2606.17727v1/figs/cross_evaluator_scatter.png)Figure 7:Per\-model mean fidelity scores from two independent judge models\. The near\-collinear arrangement \(r=0\.992r=0\.992\) indicates that the relative ranking is invariant to the choice of judge\.
### 4\.6Agreement with Human Evaluation

To assess the reliability of LongWebBench’s automatic evaluation protocols, we compare them with human judgments on sampled model outputs\. For W\-VFR, three annotators independently rate each generated webpage against the reference screenshot on the same 0–10 structural fidelity scale, and their average rating is used as the human score\. For W\-FFR, annotators manually inspect browser execution traces and assign binary success labels for executed interaction steps\. As shown in Figure[8](https://arxiv.org/html/2606.17727#S4.F8), the automatic protocols align well with human judgments\. On W\-VFR, automatic structural scores achieve strong agreement with human ratings over100100sampled outputs, with Pearsonr=0\.8335r=0\.8335and Spearmanρ=0\.87\\rho=0\.87\. On W\-FFR, the automatic verifier reaches an overall consistency of0\.89450\.8945over455455evaluated steps from9797tasks, and remains above0\.870\.87across different interaction\-length groups\. These results support the use of the automatic protocols for scalable evaluation of both long\-range structural fidelity and executable functional correctness\. Details of annotation and agreement analysis are provided in Appendix[D](https://arxiv.org/html/2606.17727#A4)\.

![Refer to caption](https://arxiv.org/html/2606.17727v1/figs/total_score_correlation.png)\(a\)Overall\-score correlation\.
![Refer to caption](https://arxiv.org/html/2606.17727v1/figs/dimension_and_wffr.png)\(b\)Per step\-range and overall W\-FFR accuracy\.

Figure 8:Agreement between automatic evaluation and human judgments\. \(a\) W\-VFR score\-level agreement on100100sampled outputs\. \(b\) W\-FFR task\-level consistency across interaction\-step lengths\.

## 5Related Works

### 5\.1Visual\-to\-Code Generation

Visual\-to\-code generation aims to convert visual interface inputs into executable code\. Early work such as pix2codeBeltramelli \([2018](https://arxiv.org/html/2606.17727#bib.bib32)\)studied GUI screenshot\-to\-code, while recent VLM\-based systems extend this paradigm to webpage and front\-end code generationWanget al\.\([2024](https://arxiv.org/html/2606.17727#bib.bib29),[2025](https://arxiv.org/html/2606.17727#bib.bib3)\); Jianget al\.\([2025](https://arxiv.org/html/2606.17727#bib.bib49)\)\. Since HTML/CSS implementations are non\-unique and original source code is often unavailable, existing benchmarks commonly adopt render\-based evaluation, including Web2CodeYunet al\.\([2024](https://arxiv.org/html/2606.17727#bib.bib37)\), Design2CodeSiet al\.\([2025](https://arxiv.org/html/2606.17727#bib.bib36)\), Sketch2CodeLiet al\.\([2025](https://arxiv.org/html/2606.17727#bib.bib46)\), and WebCode2MGuiet al\.\([2025](https://arxiv.org/html/2606.17727#bib.bib38)\)\. However, these benchmarks mainly focus on short, single\-screen, or mostly static pages\. Long webpages introduce additional challenges, including global layout consistency, section ordering, repeated modules, information density, and style coherence across multiple viewports\. LongWebBench complements existing benchmarks by treating long\-range structural fidelity as a central evaluation target and supporting both single\-image and multi\-image input settings\.

### 5\.2Functional Webpage Generation

Realistic webpage generation requires executable interaction behavior beyond visual reconstruction\. Recent benchmarks begin to evaluate interaction\-aware generation: Interaction2CodeXiaoet al\.\([2024](https://arxiv.org/html/2606.17727#bib.bib33)\)focuses on isolated interactions such as clicks, hovers, and toggles, FullFrontSunet al\.\([2025](https://arxiv.org/html/2606.17727#bib.bib43)\)uses DOM\-level signals to assess front\-end workflow components, and WebGen\-BenchLuet al\.\([2025](https://arxiv.org/html/2606.17727#bib.bib39)\)studies functional website generation beyond static appearance\. Related web\-agent benchmarks such as WebArenaZhouet al\.\([2023](https://arxiv.org/html/2606.17727#bib.bib34)\), Mind2WebDenget al\.\([2023](https://arxiv.org/html/2606.17727#bib.bib44)\), BrowserGymChezelleset al\.\([2024](https://arxiv.org/html/2606.17727#bib.bib45)\), and WebVIAXuet al\.\([2025](https://arxiv.org/html/2606.17727#bib.bib42)\)evaluate agents operating on existing webpages or browser environments\. In contrast, LongWebBench evaluates whether a generated webpage itself contains the interaction logic and state transitions needed to support executable multi\-step user goals\.

## 6Conclusion

In this paper, we introducedLongWebBench, a benchmark for evaluating long\-horizon webpage generation from structural and functional perspectives\. Unlike short, static visual reconstruction benchmarks, LongWebBench tests whether generated webpages preserve global structure across multiple viewports and support executable multi\-step user interactions\. Experiments with state\-of\-the\-art VLMs show that structural fidelity degrades as webpage length increases, while visually plausible generations often fail to complete functional user goals\. These findings highlight the need to evaluate webpage generation beyond static visual similarity and provide a diagnostic testbed for long\-context multimodal code generation\.

## Limitations

LongWebBench evaluates stabilized rendered webpages and frontend\-observable interactions\. This design makes the benchmark controllable and reproducible, but excludes authentication, personalization, live backend services, and unbounded infinite scrolling\. Therefore, the benchmark targets long\-page visual structure and executable frontend behavior rather than the full complexity of deployed web applications\. The functional tasks in W\-FFR are restricted to user goals whose success can be verified through browser execution, DOM states, and rendered page states\. Tasks requiring external databases, payment systems, account\-specific states, or hidden server\-side logic are outside the current scope\. In addition, although we validate the automatic evaluators through human agreement analysis and cross\-judge robustness checks, automatic evaluation may still miss subtle visual or behavioral errors\. Future work can extend LongWebBench toward controlled backend environments and broader real\-world interaction scenarios\.

## References

- Pix2code: generating code from a graphical user interface screenshot\.InProceedings of the ACM SIGCHI symposium on engineering interactive computing systems,pp\. 1–6\.Cited by:[§5\.1](https://arxiv.org/html/2606.17727#S5.SS1.p1.1)\.
- D\. Chezelles, T\. Le Sellier, S\. O\. Shayegan, L\. K\. Jang, X\. H\. Lù, O\. Yoran, D\. Kong, F\. F\. Xu, S\. Reddy, Q\. Cappart,et al\.\(2024\)The browsergym ecosystem for web agent research\.arXiv preprint arXiv:2412\.05467\.Cited by:[§5\.2](https://arxiv.org/html/2606.17727#S5.SS2.p1.1)\.
- G\. Comanici, E\. Bieber, M\. Schaekermann, I\. Pasupat, N\. Sachdeva, I\. Dhillon, M\. Blistein, O\. Ram, D\. Zhang, E\. Rosen,et al\.\(2025\)Gemini 2\.5: pushing the frontier with advanced reasoning, multimodality, long context, and next generation agentic capabilities\.arXiv preprint arXiv:2507\.06261\.Cited by:[§4\.1](https://arxiv.org/html/2606.17727#S4.SS1.SSS0.Px1.p1.1)\.
- X\. Deng, Y\. Gu, B\. Zheng, S\. Chen, S\. Stevens, B\. Wang, H\. Sun, and Y\. Su \(2023\)Mind2web: towards a generalist agent for the web\.Advances in Neural Information Processing Systems36,pp\. 28091–28114\.Cited by:[§5\.2](https://arxiv.org/html/2606.17727#S5.SS2.p1.1)\.
- Y\. Gui, Z\. Li, Y\. Wan, Y\. Shi, H\. Zhang, B\. Chen, Y\. Su, D\. Chen, S\. Wu, X\. Zhou,et al\.\(2025\)Webcode2m: a real\-world dataset for code generation from webpage designs\.InProceedings of the ACM on Web Conference 2025,pp\. 1834–1845\.Cited by:[Table 1](https://arxiv.org/html/2606.17727#S1.T1.1.1.4.1),[§1](https://arxiv.org/html/2606.17727#S1.p3.1),[§5\.1](https://arxiv.org/html/2606.17727#S5.SS1.p1.1)\.
- Y\. Jiang, Y\. Zheng, Y\. Wan, J\. Han, Q\. Wang, M\. R\. Lyu, and X\. Yue \(2025\)Screencoder: advancing visual\-to\-code generation for front\-end automation via modular multimodal agents\.arXiv preprint arXiv:2507\.22827\.Cited by:[§1](https://arxiv.org/html/2606.17727#S1.p1.1),[§5\.1](https://arxiv.org/html/2606.17727#S5.SS1.p1.1)\.
- R\. Li, Y\. Zhang, and D\. Yang \(2025\)Sketch2code: evaluating vision\-language models for interactive web design prototyping\.InProceedings of the 2025 Conference of the Nations of the Americas Chapter of the Association for Computational Linguistics: Human Language Technologies \(Volume 1: Long Papers\),pp\. 3921–3955\.Cited by:[Table 1](https://arxiv.org/html/2606.17727#S1.T1.1.1.7.1),[§1](https://arxiv.org/html/2606.17727#S1.p3.1),[§5\.1](https://arxiv.org/html/2606.17727#S5.SS1.p1.1)\.
- S\. Liang, N\. Jiang, S\. Qian, and L\. Tan \(2025\)WAFFLE: fine\-tuning multi\-modal model for automated front\-end development\.InProceedings of the 63rd Annual Meeting of the Association for Computational Linguistics \(Volume 1: Long Papers\),pp\. 24786–24802\.Cited by:[§1](https://arxiv.org/html/2606.17727#S1.p1.1)\.
- H\. Liu, C\. Li, Q\. Wu, and Y\. J\. Lee \(2023\)Visual instruction tuning\.Advances in neural information processing systems36,pp\. 34892–34916\.Cited by:[§1](https://arxiv.org/html/2606.17727#S1.p1.1)\.
- Z\. Lu, Y\. Yang, H\. Ren, H\. Hou, H\. Xiao, K\. Wang, W\. Shi, A\. Zhou, M\. Zhan, and H\. Li \(2025\)WebGen\-bench: evaluating llms on generating interactive and functional websites from scratch\.arXiv preprint arXiv:2505\.03733\.Cited by:[Table 1](https://arxiv.org/html/2606.17727#S1.T1.1.1.6.1),[§1](https://arxiv.org/html/2606.17727#S1.p3.1),[§5\.2](https://arxiv.org/html/2606.17727#S5.SS2.p1.1)\.
- T\. Niu, Y\. Cui, B\. Wang, X\. Xu, X\. Yao, Q\. Zhu, D\. Wu, S\. Wang, and W\. Che \(2025\)Chart2Code53: a large\-scale diverse and complex dataset for enhancing chart\-to\-code generation\.InProceedings of the 2025 Conference on Empirical Methods in Natural Language Processing,pp\. 15839–15855\.Cited by:[§1](https://arxiv.org/html/2606.17727#S1.p1.1)\.
- OpenAI, J\. Achiam, S\. Adler, S\. Agarwal, L\. Ahmad, I\. Akkaya, F\. L\. Aleman, D\. Almeida, J\. Altenschmidt, S\. Altman, S\. Anadkat, R\. Avila, I\. Babuschkin, S\. Balaji, V\. Balcom, P\. Baltescu, H\. Bao, M\. Bavarian, J\. Belgum, I\. Bello, J\. Berdine, G\. Bernadett\-Shapiro, C\. Berner, L\. Bogdonoff, O\. Boiko, M\. Boyd, A\. Brakman, G\. Brockman, T\. Brooks, M\. Brundage, K\. Button, T\. Cai, R\. Campbell, A\. Cann, B\. Carey, C\. Carlson, R\. Carmichael, B\. Chan, C\. Chang, F\. Chantzis, D\. Chen, S\. Chen, R\. Chen, J\. Chen, M\. Chen, B\. Chess, C\. Cho, C\. Chu, H\. W\. Chung, D\. Cummings, J\. Currier, Y\. Dai, C\. Decareaux, T\. Degry, N\. Deutsch, D\. Deville, A\. Dhar, D\. Dohan, S\. Dowling, S\. Dunning, A\. Ecoffet, A\. Eleti, T\. Eloundou, D\. Farhi, L\. Fedus, N\. Felix, S\. P\. Fishman, J\. Forte, I\. Fulford, L\. Gao, E\. Georges, C\. Gibson, V\. Goel, T\. Gogineni, G\. Goh, R\. Gontijo\-Lopes, J\. Gordon, M\. Grafstein, S\. Gray, R\. Greene, J\. Gross, S\. S\. Gu, Y\. Guo, C\. Hallacy, J\. Han, J\. Harris, Y\. He, M\. Heaton, J\. Heidecke, C\. Hesse, A\. Hickey, W\. Hickey, P\. Hoeschele, B\. Houghton, K\. Hsu, S\. Hu, X\. Hu, J\. Huizinga, S\. Jain, S\. Jain, J\. Jang, A\. Jiang, R\. Jiang, H\. Jin, D\. Jin, S\. Jomoto, B\. Jonn, H\. Jun, T\. Kaftan, Ł\. Kaiser, A\. Kamali, I\. Kanitscheider, N\. S\. Keskar, T\. Khan, L\. Kilpatrick, J\. W\. Kim, C\. Kim, Y\. Kim, J\. H\. Kirchner, J\. Kiros, M\. Knight, D\. Kokotajlo, Ł\. Kondraciuk, A\. Kondrich, A\. Konstantinidis, K\. Kosic, G\. Krueger, V\. Kuo, M\. Lampe, I\. Lan, T\. Lee, J\. Leike, J\. Leung, D\. Levy, C\. M\. Li, R\. Lim, M\. Lin, S\. Lin, M\. Litwin, T\. Lopez, R\. Lowe, P\. Lue, A\. Makanju, K\. Malfacini, S\. Manning, T\. Markov, Y\. Markovski, B\. Martin, K\. Mayer, A\. Mayne, B\. McGrew, S\. M\. McKinney, C\. McLeavey, P\. McMillan, J\. McNeil, D\. Medina, A\. Mehta, J\. Menick, L\. Metz, A\. Mishchenko, P\. Mishkin, V\. Monaco, E\. Morikawa, D\. Mossing, T\. Mu, M\. Murati, O\. Murk, D\. Mély, A\. Nair, R\. Nakano, R\. Nayak, A\. Neelakantan, R\. Ngo, H\. Noh, L\. Ouyang, C\. O’Keefe, J\. Pachocki, A\. Paino, J\. Palermo, A\. Pantuliano, G\. Parascandolo, J\. Parish, E\. Parparita, A\. Passos, M\. Pavlov, A\. Peng, A\. Perelman, F\. de Avila Belbute Peres, M\. Petrov, H\. P\. de Oliveira Pinto, Michael, Pokorny, M\. Pokrass, V\. H\. Pong, T\. Powell, A\. Power, B\. Power, E\. Proehl, R\. Puri, A\. Radford, J\. Rae, A\. Ramesh, C\. Raymond, F\. Real, K\. Rimbach, C\. Ross, B\. Rotsted, H\. Roussez, N\. Ryder, M\. Saltarelli, T\. Sanders, S\. Santurkar, G\. Sastry, H\. Schmidt, D\. Schnurr, J\. Schulman, D\. Selsam, K\. Sheppard, T\. Sherbakov, J\. Shieh, S\. Shoker, P\. Shyam, S\. Sidor, E\. Sigler, M\. Simens, J\. Sitkin, K\. Slama, I\. Sohl, B\. Sokolowsky, Y\. Song, N\. Staudacher, F\. P\. Such, N\. Summers, I\. Sutskever, J\. Tang, N\. Tezak, M\. B\. Thompson, P\. Tillet, A\. Tootoonchian, E\. Tseng, P\. Tuggle, N\. Turley, J\. Tworek, J\. F\. C\. Uribe, A\. Vallone, A\. Vijayvergiya, C\. Voss, C\. Wainwright, J\. J\. Wang, A\. Wang, B\. Wang, J\. Ward, J\. Wei, C\. Weinmann, A\. Welihinda, P\. Welinder, J\. Weng, L\. Weng, M\. Wiethoff, D\. Willner, C\. Winter, S\. Wolrich, H\. Wong, L\. Workman, S\. Wu, J\. Wu, M\. Wu, K\. Xiao, T\. Xu, S\. Yoo, K\. Yu, Q\. Yuan, W\. Zaremba, R\. Zellers, C\. Zhang, M\. Zhang, S\. Zhao, T\. Zheng, J\. Zhuang, W\. Zhuk, and B\. Zoph \(2024\)GPT\-4 technical report\.External Links:2303\.08774,[Link](https://arxiv.org/abs/2303.08774)Cited by:[§4\.1](https://arxiv.org/html/2606.17727#S4.SS1.SSS0.Px1.p1.1)\.
- C\. Si, Y\. Zhang, R\. Li, Z\. Yang, R\. Liu, and D\. Yang \(2025\)Design2code: benchmarking multimodal code generation for automated front\-end engineering\.InProceedings of the 2025 Conference of the Nations of the Americas Chapter of the Association for Computational Linguistics: Human Language Technologies \(Volume 1: Long Papers\),pp\. 3956–3974\.Cited by:[Table 1](https://arxiv.org/html/2606.17727#S1.T1.1.1.5.1),[§1](https://arxiv.org/html/2606.17727#S1.p3.1),[§5\.1](https://arxiv.org/html/2606.17727#S5.SS1.p1.1)\.
- A\. Singh, A\. Fry, A\. Perelman, A\. Tart, A\. Ganesh, A\. El\-Kishky, A\. McLaughlin, A\. Low, A\. Ostrow, A\. Ananthram,et al\.\(2025\)OpenAI gpt\-5 system card\.arXiv preprint arXiv:2601\.03267\.Cited by:[§4\.1](https://arxiv.org/html/2606.17727#S4.SS1.SSS0.Px1.p1.1)\.
- H\. Sun, H\. W\. Wang, J\. Gu, L\. Li, and Y\. Cheng \(2025\)FullFront: benchmarking mllms across the full front\-end engineering workflow\.arXiv preprint arXiv:2505\.17399\.Cited by:[§5\.2](https://arxiv.org/html/2606.17727#S5.SS2.p1.1)\.
- W\. Tan, Q\. Cao, C\. Xue, Y\. Zhan, C\. Ding, and X\. He \(2025\)Chartmaster: advancing chart\-to\-code generation with real\-world charts and chart similarity reinforcement learning\.arXiv preprint arXiv:2508\.17608\.Cited by:[§1](https://arxiv.org/html/2606.17727#S1.p1.1)\.
- K\. Team, A\. Du, B\. Yin, B\. Xing, B\. Qu, B\. Wang, C\. Chen, C\. Zhang, C\. Du, C\. Wei,et al\.\(2025a\)Kimi\-vl technical report\.arXiv preprint arXiv:2504\.07491\.Cited by:[§1](https://arxiv.org/html/2606.17727#S1.p1.1),[§4\.1](https://arxiv.org/html/2606.17727#S4.SS1.SSS0.Px1.p1.1)\.
- V\. Team, W\. Hong, W\. Yu, X\. Gu, G\. Wang, G\. Gan, H\. Tang, J\. Cheng, J\. Qi, J\. Ji, L\. Pan, S\. Duan, W\. Wang, Y\. Wang, Y\. Cheng, Z\. He, Z\. Su, Z\. Yang, Z\. Pan, A\. Zeng, B\. Wang, B\. Chen, B\. Shi, C\. Pang, C\. Zhang, D\. Yin, F\. Yang, G\. Chen, J\. Xu, J\. Zhu, J\. Chen, J\. Chen, J\. Chen, J\. Lin, J\. Wang, J\. Chen, L\. Lei, L\. Gong, L\. Pan, M\. Liu, M\. Xu, M\. Zhang, Q\. Zheng, S\. Yang, S\. Zhong, S\. Huang, S\. Zhao, S\. Xue, S\. Tu, S\. Meng, T\. Zhang, T\. Luo, T\. Hao, T\. Tong, W\. Li, W\. Jia, X\. Liu, X\. Zhang, X\. Lyu, X\. Fan, X\. Huang, Y\. Wang, Y\. Xue, Y\. Wang, Y\. Wang, Y\. An, Y\. Du, Y\. Shi, Y\. Huang, Y\. Niu, Y\. Wang, Y\. Yue, Y\. Li, Y\. Zhang, Y\. Wang, Y\. Wang, Y\. Zhang, Z\. Xue, Z\. Hou, Z\. Du, Z\. Wang, P\. Zhang, D\. Liu, B\. Xu, J\. Li, M\. Huang, Y\. Dong, and J\. Tang \(2025b\)GLM\-4\.5v and glm\-4\.1v\-thinking: towards versatile multimodal reasoning with scalable reinforcement learning\.External Links:2507\.01006,[Link](https://arxiv.org/abs/2507.01006)Cited by:[§4\.1](https://arxiv.org/html/2606.17727#S4.SS1.SSS0.Px1.p1.1)\.
- W\. Wang, Q\. Lv, W\. Yu, W\. Hong, J\. Qi, Y\. Wang, J\. Ji, Z\. Yang, L\. Zhao, S\. XiXuan,et al\.\(2024\)Cogvlm: visual expert for pretrained language models\.Advances in Neural Information Processing Systems37,pp\. 121475–121499\.Cited by:[§1](https://arxiv.org/html/2606.17727#S1.p1.1),[§5\.1](https://arxiv.org/html/2606.17727#S5.SS1.p1.1)\.
- W\. Wang, Z\. Gao, L\. Gu, H\. Pu, L\. Cui, X\. Wei, Z\. Liu, L\. Jing, S\. Ye, J\. Shao,et al\.\(2025\)Internvl3\. 5: advancing open\-source multimodal models in versatility, reasoning, and efficiency\.arXiv preprint arXiv:2508\.18265\.Cited by:[§1](https://arxiv.org/html/2606.17727#S1.p1.1),[§4\.1](https://arxiv.org/html/2606.17727#S4.SS1.SSS0.Px1.p1.1),[§5\.1](https://arxiv.org/html/2606.17727#S5.SS1.p1.1)\.
- F\. Wu, C\. Gao, S\. Li, X\. Wen, and Q\. Liao \(2025\)MLLM\-based ui2code automation guided by ui layout information\.Proceedings of the ACM on Software Engineering2\(ISSTA\),pp\. 1123–1145\.Cited by:[§1](https://arxiv.org/html/2606.17727#S1.p1.1)\.
- J\. Xiao, Y\. Wan, Y\. Huo, Z\. Wang, X\. Xu, W\. Wang, Z\. Xu, Y\. Wang, and M\. R\. Lyu \(2024\)Interaction2Code: benchmarking mllm\-based interactive webpage code generation from interactive prototyping\.arXiv preprint arXiv:2411\.03292\.Cited by:[Table 1](https://arxiv.org/html/2606.17727#S1.T1.1.1.3.1),[§1](https://arxiv.org/html/2606.17727#S1.p3.1),[§5\.2](https://arxiv.org/html/2606.17727#S5.SS2.p1.1)\.
- M\. Xu, Z\. Yang, W\. Hong, L\. Pan, X\. Fan, Y\. Wang, X\. Gu, B\. Xu, and J\. Tang \(2025\)Webvia: a web\-based vision\-language agentic framework for interactive and verifiable ui\-to\-code generation\.arXiv preprint arXiv:2511\.06251\.Cited by:[§5\.2](https://arxiv.org/html/2606.17727#S5.SS2.p1.1)\.
- A\. Yang, A\. Li, B\. Yang, B\. Zhang, B\. Hui, B\. Zheng, B\. Yu, C\. Gao, C\. Huang, C\. Lv,et al\.\(2025\)Qwen3 technical report\.arXiv preprint arXiv:2505\.09388\.Cited by:[§1](https://arxiv.org/html/2606.17727#S1.p1.1),[§4\.1](https://arxiv.org/html/2606.17727#S4.SS1.SSS0.Px1.p1.1)\.
- S\. Yun, R\. Thushara, M\. Bhat, Y\. Wang, M\. Deng, J\. Wang, T\. Tao, J\. Li, H\. Li, P\. Nakov,et al\.\(2024\)Web2code: a large\-scale webpage\-to\-code dataset and evaluation framework for multimodal llms\.Advances in neural information processing systems37,pp\. 112134–112157\.Cited by:[Table 1](https://arxiv.org/html/2606.17727#S1.T1.1.1.2.1),[§1](https://arxiv.org/html/2606.17727#S1.p1.1),[§1](https://arxiv.org/html/2606.17727#S1.p3.1),[§5\.1](https://arxiv.org/html/2606.17727#S5.SS1.p1.1)\.
- X\. Zhao, X\. Luo, Q\. Shi, C\. Chen, S\. Wang, Z\. Liu, and M\. Sun \(2025\)Chartcoder: advancing multimodal large language model for chart\-to\-code generation\.arXiv preprint arXiv:2501\.06598\.Cited by:[§1](https://arxiv.org/html/2606.17727#S1.p1.1)\.
- S\. Zhou, F\. F\. Xu, H\. Zhu, X\. Zhou, R\. Lo, A\. Sridhar, X\. Cheng, T\. Ou, Y\. Bisk, D\. Fried,et al\.\(2023\)Webarena: a realistic web environment for building autonomous agents\.arXiv preprint arXiv:2307\.13854\.Cited by:[§5\.2](https://arxiv.org/html/2606.17727#S5.SS2.p1.1)\.

## Appendix

## Appendix AData Annotation

Table 4:The descriptions of W\-VFR dataset categories\.\#CategoryContent DriverComment1Informational ArticlesNarrative\-drivenUsers primarily gain information by reading a continuous textual narrative\.2Reference & DocumentationLookup\-drivenUsers search with a clear goal to find and locate specific entries or instructions\.3Product & Service PagesOffering\-drivenThe page aims to present and drive the selection of a specific product or service\.4Community & DiscussionUGC\-drivenThe main information comes from user\-generated content and interaction structures\.5Governmental / InstitutionalAuthority\-drivenThe page centers on information published by official or authoritative institutions\.6Data & Resource AggregationListing\-drivenThe core is a systematic listing of large amounts of data, resources, or items for retrieval\.7Transportation & Travel ServicesDecision \+ Transaction\-drivenUsers search, compare, and book travel options under multiple constraints\.### A\.1More details about W\-VFR categories

W\-VFR CategoriesTable[4](https://arxiv.org/html/2606.17727#A1.T4)provides a taxonomy of page types\. We define categories using two complementary criteria: \(1\) the page’s primary functional role in the information ecosystem \(e\.g\., explaining, lookup, offering/transaction, or interaction\), and \(2\) the dominant mechanism by which users obtain content on the page \(“content driver”\), such as narrative reading, goal\-directed lookup, offering\-driven choice, or UGC\-mediated discussion\. This scheme has three main advantages: it is explicit and operational, enabling consistent labeling across domains and websites; it aligns naturally with user intent and page structure, making it easy to map categories to observable features \(e\.g\., navigation depth, modular layout, interaction density, and conversion components\) for downstream detection, evaluation, and stratified experimentation; and it is extensible—new page forms can be incorporated by adding categories or drivers without undermining comparability with the existing taxonomy\.

### A\.2More details about W\-FFR categories

W\-FFR CategoriesTable[5](https://arxiv.org/html/2606.17727#A1.T5)summarizes the category taxonomy of the W\-VFR dataset, covering a diverse range of real\-world web scenarios\. Each category is characterized by its dominant content driver, reflecting the primary user intent and interaction pattern, such as information retrieval, decision making, learning, or user\-generated interaction\. This categorization highlights the heterogeneity of web pages in terms of content structure and functional objectives, providing a structured foundation for analyzing model performance across different webpage types\.

Table 5:The descriptions of W\-VFR dataset categories\.\#CategoryContent DriverComment1Academic SearchRetrieval\-drivenUsers search for academic papers, authors, or citations with precise information needs, emphasizing accurate retrieval and relevance ranking\.2Community & DiscussionUGC\-drivenThe primary content is generated by users through questions, answers, and discussions, where information emerges from collective interaction\.3Data Visualization & AnalyticsInsight\-drivenPages focus on presenting data through visual or analytical forms to support interpretation, comparison, and exploratory analysis\.4Developer Docs & Cloud ConsoleLookup\-drivenUsers seek technical documentation, APIs, or configuration instructions to support development and system operation tasks\.5E\-commerce Product SelectionDecision\-drivenThe page assists users in comparing products, prices, and attributes to facilitate informed purchasing decisions\.6Education & CourseLearning\-drivenContent is structured to support systematic learning, including tutorials, courses, and educational materials\.7Finance & Market AnalysisAnalysis\-drivenPages provide financial data, trends, and analytical insights to support investment, risk assessment, and market understanding\.8Government & Open DataAuthority\-drivenInformation is published by official institutions, focusing on policies, regulations, and publicly released datasets\.9Jobs & RecruitmentMatching\-drivenUsers search and compare job opportunities or candidates based on structured requirements and qualifications\.10News & Interactive MediaNarrative\-drivenContent delivers timely information through news reporting or interactive storytelling, emphasizing readability and engagement\.11Real Estate SearchDecision\-drivenPages support searching, filtering, and comparing properties under multiple constraints such as price, location, and amenities\.12SaaS PricingComparison\-drivenThe focus is on pricing structures, feature tiers, and cost comparison to support service selection decisions\.13Travel & TransportationPlanning\-drivenPages support users in searching, comparing, and booking travel options such as flights, hotels, and transit routes, emphasizing multi\-constraint filtering and itinerary planning\.
### A\.3Distribution of webpage lengths across categories

Figure[9](https://arxiv.org/html/2606.17727#A1.F9)illustrates the distribution of webpage lengths, measured by the number of viewports, across different webpage categories\. Overall, the distribution exhibits clear category\-dependent patterns, indicating substantial structural diversity among real\-world webpages\.

Short webpages \(≤\\leq5 screens\) are predominant in categories such asTransportation,Community, andGovernmental\. In particular, Transportation pages are heavily concentrated in this range, suggesting that such webpages are often designed for rapid access and concise presentation\. Community and Governmental pages also tend to be relatively short, reflecting task\-oriented or modular layouts\.

Medium\-length webpages \(6–10 screens\) are most common in theInformationandProductcategories\. Information pages show a pronounced peak in this range, indicating that explanatory or editorial\-style content typically spans multiple sections while remaining within a moderate overall length\. Product pages exhibit a similar pattern, consistent with layouts that combine descriptions, specifications, and auxiliary content\.

In contrast, long and very long webpages \(≥\\geq16 screens\) are predominantly observed in theReferencecategory\. Reference pages display a clear long\-tail distribution, with a substantial number of instances extending beyond 16 screens and a notable portion exceeding 21 screens\. This reflects the encyclopedic and documentation\-oriented nature of reference webpages, which often contain dense and hierarchically structured content\.

TheDatacategory exhibits a more balanced distribution across screen ranges, spanning from short to long webpages\. This variability suggests that data\-centric webpages differ widely in presentation style, ranging from compact dashboards to extensive analytical or tabular pages\.

Overall, these category\-specific length distributions highlight the heterogeneity of webpage structures captured in the benchmark and motivate the need for evaluation protocols and model designs that can robustly handle diverse page lengths in long\-webpage understanding and generation tasks\.

![Refer to caption](https://arxiv.org/html/2606.17727v1/figs/screen_dist_by_category.png)Figure 9:Distribution of Webpage Screenshot Lengths across Categories

## Appendix BDetails of Evaluation Process

### B\.1More details about our validation process on W\-VFR task

The prompt for Structural Fidelity Validation is provided in Figure[25](https://arxiv.org/html/2606.17727#A5.F25)\-[26](https://arxiv.org/html/2606.17727#A5.F26)\. We employgpt\-4o\-2024\-11\-20as the judge model for automated evaluation\. For models that do not support input settings, we assign a default score of 0\. The final score is computed as a weighted sum of scores across all evaluation dimensions\. Specifically, for theVisual Styledimension, the score is computed as a weighted combination of0\.8×VLM score\+0\.2×normalized DINO score0\.8\\times\\text\{VLM score\}\+0\.2\\times\\text\{normalized DINO score\}, a weighting scheme we empirically validated to achieve the highest agreement with human judgments\.

### B\.2More metric details about W\-VFR

#### Input Support Rate \(ISR\)\.

ISR measures the fraction of test cases that a model or its serving API accepts for generation, isolating input\-side constraints \(e\.g\., image\-size limits or resolution\-size limits\) from downstream generation quality\. Let𝒯\\mathcal\{T\}denote the full test set and𝒮m⊆𝒯\\mathcal\{S\}\_\{m\}\\subseteq\\mathcal\{T\}the subset that modelmmaccepts and proceeds to generate for\. ISR is defined as

ISR​\(m\)=\|𝒮m\|\|𝒯\|\.\\textsc\{ISR\}\(m\)\\;=\\;\\frac\{\|\\mathcal\{S\}\_\{m\}\|\}\{\|\\mathcal\{T\}\|\}\.\(1\)A low ISR reflects upstream limitations that prevent the model from being applied to certain inputs at all\.

#### HTML Validity Rate \(HVR\)\.

Given the supported subset𝒮m\\mathcal\{S\}\_\{m\}, HVR measures the proportion of generations that yield a valid, renderable HTML artifact\. An output is counted as valid if it is non\-empty and contains a well\-formed<html\>document parseable by a standard HTML parser \(with no truncation or non\-HTML content\)\. Let𝒱m⊆𝒮m\\mathcal\{V\}\_\{m\}\\subseteq\\mathcal\{S\}\_\{m\}denote the valid outputs from modelmm\. HVR is defined as

HVR​\(m\)=\|𝒱m\|\|𝒮m\|\.\\textsc\{HVR\}\(m\)\\;=\\;\\frac\{\|\\mathcal\{V\}\_\{m\}\|\}\{\|\\mathcal\{S\}\_\{m\}\|\}\.\(2\)HVR is defined as the model’s ability to reliably emit a renderable artifact on supported inputs\.

Code Quality \(CQ\)We assess the engineering quality of model\-generated HTML usingGoogle Lighthouse\(v12\), a widely adopted, fully automated, and reproducible web auditing tool that scores a page on a\[0,100\]\[0,100\]scale across multiple categories\.

#### Evaluation dimensions\.

We adopt Lighthouse’s four default categories:

- •Performance: page load efficiency measured by core Web Vitals\.
- •Accessibility: powered by theaxe\-corerule set, covering imagealtattributes, form<label\>associations, color contrast, the<html lang\>declaration, ARIA landmark usage, and so on\.
- •Best Practices: HTML document conventions \(<\!DOCTYPE\>,<meta charset\>,<meta viewport\>\), absence of console errors, deprecated APIs, CSP declaration, and image aspect\-ratio consistency\.
- •SEO: presence of<title\>,<meta description\>, crawler\-friendly links, androbots\.txtcompliance\.

#### Audit pipeline\.

Each HTML file is served via a local static HTTP server bound to127\.0\.0\.1and audited through the Lighthouse Node API driving a headless Chromium instance launched by Puppeteer\.

#### Input normalization\.

To prevent surface artifacts from affecting Lighthouse parsing, we apply a lightweight normalization step on raw outputs: residual Markdown code fences \(e\.g\., leading/trailing\`\`\`html\) are stripped, and missing<\!DOCTYPE html\>declarations are restored for files whose HTML body is otherwise complete\. Outputs that already failed at the generation stage \(empty files, OOM placeholders, or streaming truncations yielding non\-HTML content\) are*left untouched*so that they are scored as genuine failures by Lighthouse, contributing to the model’s robustness profile\.

#### Final score\.

For each file, we average the four Lighthouse category scores to obtain a single overall scoreSm,f∈\[0,100\]S\_\{m,f\}\\in\[0,100\]\. The code\-quality score of modelmmis the mean ofSm,fS\_\{m,f\}over the common subset:

CodeQuality​\(m\)=1N​∑f∈ℱcommonSm,f\.\\textsc\{CodeQuality\}\(m\)\\;=\\;\\frac\{1\}\{N\}\\sum\_\{f\\in\\mathcal\{F\}\_\{\\text\{common\}\}\}S\_\{m,f\}\.\(3\)whereN=\|ℱcommon\|N=\|\\mathcal\{F\}\_\{\\text\{common\}\}\|\.

### B\.3More details about W\-FFR process

W\-FFR Evaluation PipelineTo assess whether a model\-generated HTML page supports correct user interactions, we design an automated GUI evaluation pipeline that combines a browser\-based environment with an LLM\-as\-judge agent\.

#### Environment\.

Each HTML file is served by a dedicated environment process, which launches a headless Chromium browser via Playwright and exposes a local HTTP API\. All operations are addressed by numeric element IDs assigned at runtime: a JavaScript traversal of the DOM identifies interactive elements \(standard form controls, elements withrole=button, elements styled withcursor:pointer, etc\.\) and builds anid→XPath\\text\{id\}\\to\\text\{XPath\}mapping used to locate and manipulate elements\.

#### Tasks\.

Each HTML file is paired with a JSON task file specifying one or more tasks, each decomposed into a sequence of atomic steps\. Each step has a type, a natural\-language description of the intended interaction, and an optional value \(for input/select steps\)\.

#### Evaluation Loop\.

For each task, the page is reset to its initial state before execution begins\. Steps are executed sequentially\. Each step proceeds in three stages:

1. 1\.Predict\.A screenshot and the serialized DOM tree \(with numeric IDs\) are passed to an LLM\. The model is prompted to identify the target element and output a structured action command in\\boxed\{\}format \(e\.g\.,\\boxed\{click\[42\]\}or\\boxed\{enter\[7\]\[hello\]\}\)\. The command is parsed via regex to extract the action type, element ID, and value\.
2. 2\.Execute\.The parsed action is dispatched to the browser environment via the corresponding HTTP endpoint\. The environment resolves the element by XPath and performs the operation\.
3. 3\.Verify\.Screenshots captured before and after execution are passed to a second LLM call\. The model compares the two images and judges whether the intended change occurred \(e\.g\., a field was filled, a dropdown changed, a new element appeared\), outputting\\boxed\{success\}or\\boxed\{fail\}\.

The prompts used in this process are provided in Appendix[E\.1](https://arxiv.org/html/2606.17727#A5.SS1)\.

## Appendix CDetails about Evaluation Performance

Tables[6](https://arxiv.org/html/2606.17727#A3.T6)and[7](https://arxiv.org/html/2606.17727#A3.T7)summarize model performance across different evaluation dimensions under the single\-image and multi\-image input settings, respectively\. Overall, the results show that the multi\-image setting consistently improves model performance across most dimensions and models, particularly for long and structurally complex webpages\.

Table 6:The evaluation result of each dimension under single\-image input settingModelPage Scaleand LengthGlobalLayoutSectionHierarchyVisualStylingInformationDensityOverallScoreOpen\-source VLMKimi\-VL\-A3B\-Thinking2\.063\.402\.673\.862\.342\.87Qwen3\-VL\-8B\-Instruct3\.324\.023\.363\.752\.913\.47InternVL3\-78B2\.414\.253\.304\.222\.823\.40GLM\-4\.1V\-9B\-Thinking\-Flash5\.045\.624\.674\.924\.114\.87GLM\-4\.6V5\.546\.585\.635\.594\.945\.66Qwen3\-VL\-235B\-A22B\-Instruct5\.295\.755\.084\.954\.445\.10Closed\-source VLMClaude\-Sonnet\-4\-5\-Thinking3\.854\.393\.913\.493\.393\.81Claude\-Opus\-4\-5\-202511013\.954\.383\.923\.523\.433\.84GPT\-5\.27\.027\.336\.376\.005\.776\.50GPT\-4o1\.924\.163\.014\.602\.453\.23Gemini\-3\-Pro\-preview6\.657\.876\.956\.385\.996\.77Gemini\-3\-Flash\-preview6\.287\.436\.446\.055\.586\.36Doubao\-Seed\-1\-62\.974\.603\.624\.023\.103\.66Table 7:The evaluation result of each dimension under multi\-image input settingModelPage Scaleand LengthGlobalLayoutSectionHierarchyVisualStylingInformationDensityOverallScoreOpen\-source VLMKimi\-VL\-A3B\-Thinking2\.453\.712\.874\.032\.523\.12Qwen3\-VL\-8B\-Instruct3\.694\.563\.894\.243\.353\.95InternVL3\-78B2\.624\.513\.514\.403\.053\.62GLM\-4\.1V\-9B\-Thinking\-Flash0\.560\.930\.651\.970\.580\.94GLM\-4\.6V5\.657\.076\.035\.895\.185\.96Qwen3\-VL\-235B\-A22B\-Instruct5\.506\.905\.935\.795\.135\.85Closed\-source VLMClaude\-Sonnet\-4\-5\-Thinking6\.567\.836\.906\.415\.976\.74Claude\-Opus\-4\-5\-202511016\.147\.596\.586\.205\.636\.43GPT\-5\.25\.337\.466\.186\.455\.286\.14GPT\-4o2\.024\.583\.304\.932\.793\.53Gemini\-3\-Pro\-preview7\.128\.267\.486\.726\.507\.22Gemini\-3\-Flash\-preview6\.157\.686\.586\.535\.716\.53Doubao\-Seed\-1\-63\.586\.054\.695\.484\.034\.77### C\.1Overall trends

From the Overall Score, most models benefit substantially from the multi\-image setting\. By segmenting long webpage screenshots into multiple images, models are able to perceive finer\-grained visual details and reduce information loss caused by resolution compression in single\-image inputs\. This improvement is especially pronounced for strong closed\-source models, such as the Gemini and Claude families, whose overall scores increase consistently across settings\.

### C\.2Page scale and length

Page Scale and Length results show different trends across models\. Under roughly comparable image processing conditions, the GPT\-5\.2 model actually experiences a performance drop under multi\-image input settings, whereas Gemini\-3\-Pro shows some improvement\. In contrast, the Claude model exhibits a significant performance increase, as the number of successfully processed images is greatly enhanced under the multi\-image input setting\.

### C\.3Global layout and section hierarchy

Performance on Global Layout and Section Hierarchy also improves noticeably in the multi\-image setting in most cases\. These gains indicate that access to multiple localized views helps models better infer high\-level structural organization, including module ordering and hierarchical relationships between sections\. The effect is particularly evident for the Claude and Gemini models, which show substantial improvements on these structure\-oriented dimensions\.

### C\.4Visual styling

In contrast, improvements on Visual Styling are still evident\. Multi\-image inputs provide additional visual details, which help models better capture fine\-grained stylistic attributes—such as font choices, color schemes, and spacing—even though these aspects remain challenging to infer from screenshots alone\. Consequently, this dimension also shows positive performance gains\.

### C\.5Information density

Information Density lies between structural and stylistic dimensions in terms of evaluation complexity\. Most models achieve modest but consistent improvements in the multi\-image setting, reflecting the combined influence of enhanced structural perception and the inherent ambiguity of density judgments from visual inputs\.

### C\.6Open\-source vs\. Closed\-source models\.

Almost all Closed\-source models consistently outperform open\-source models under both settings, and their advantage becomes more pronounced in the multi\-image scenario\. Notably, Gemini\-3\-Pro\-preview achieves the highest overall performance and demonstrates strong, balanced improvements across all dimensions\.

### C\.7Anomalous behavior\.

An exception is observed for GLM\-4\.1V\-9B\-Thinking\-Flash, which exhibits a sharp performance degradation under the multi\-image setting\. Manual inspection reveals that, when presented with multiple images, this model tends to misinterpret the task as site\-level webpage generation rather than long\-page reconstruction, resulting in severely degraded outputs\. This highlights that effective utilization of multi\-image inputs requires robust cross\-image integration and task alignment, which are not uniformly supported across models\.

### C\.8Summary

In summary, these results demonstrate that multi\-image input is a critical design choice for evaluating and generating long webpages, offering substantial benefits for scale\- and structure\-related dimensions\. While stylistic fidelity remains challenging due to limited design\-level information, the overall performance gains underscore the importance of segmented visual inputs for long\-context webpage understanding and generation\.

## Appendix DHuman Evaluation

### D\.1The score of each dimension on human relevance

Table[8](https://arxiv.org/html/2606.17727#A4.T8)reports the correlation between the automatic evaluation scores and human judgments averaged across annotators\. Overall, the automatic scores exhibit a strong correlation with human assessments, achieving a Pearson correlation coefficient of 0\.8335, which indicates a high degree of alignment between the proposed evaluation protocol and human perception\.

Among the individual dimensions, Page Scale and Length show a very strong correlation \(0\.9150\), suggesting that both humans and models consistently assess page completeness and overall length\. Global Layout \(0\.7706\) and Chapter Hierarchy \(0\.7393\) also demonstrate strong correlations, reflecting reliable agreement on the structural organization and hierarchical arrangement of webpage content\. Information Density achieves a moderately high correlation \(0\.6807\), indicating that the automatic metric can reasonably capture the perceived amount and distribution of information on long webpages\. Visual Style achieves a correlation of 0\.6035, reflecting a moderately strong agreement between automatic scores and human judgments\. This is expected given the screenshot\-only input setting adopted in our experiments, as fine\-grained stylistic attributes—such as font families, color schemes, spacing, and design system constraints—are not explicitly accessible without the original HTML or CSS sources, making stylistic fidelity inherently more challenging to assess from rendered images alone\. Nevertheless, the correlation remains meaningful, suggesting that the automatic metric can capture overall visual style consistency to a reasonable degree\.

Overall, these results indicate that the proposed automatic evaluation aligns well with human judgments, while the reduced correlation on visual style reflects the intrinsic subjectivity of aesthetic assessment and the limited availability of design\-level information in the current task setting\.

Table 8:Correlation between person\_average and AI ModelsMetricCoefficientp\-valueOverall Score0\.8335<<0\.0001Page Scale and Length0\.9150<<0\.0001Global Layout0\.7706<<0\.0001Chapter Hierarchy0\.7393<<0\.0001Visual Style0\.6035<<0\.0001Information Density0\.6807<<0\.0001
### D\.2Inter\-annotator agreement analysis

Figure[10](https://arxiv.org/html/2606.17727#A4.F10)presents pairwise comparisons of total scores assigned by three human annotators, as well as comparisons between each annotator and the averaged score across annotators\. Each point corresponds to one webpage instance, the black diagonal line indicates perfect agreement \(y=xy=x\), and the red dashed line denotes the fitted linear regression\.

Overall, the results demonstrate a high level of inter\-annotator consistency\. Pairwise correlations between individual annotators are strong, with Pearson correlation coefficients ofr=0\.793r=0\.793\(Annotator 1 vs\. Annotator 2\),r=0\.779r=0\.779\(Annotator 1 vs\. Annotator 3\), andr=0\.849r=0\.849\(Annotator 2 vs\. Annotator 3\), all with statistically significantpp\-values \(p<10−20p<10^\{\-20\}\)\. The corresponding RMSE and MAE values indicate moderate absolute disagreement, reflecting the inherent subjectivity of fine\-grained visual fidelity assessment\.

Comparisons between individual annotators and the averaged score further reveal substantially higher agreement\. Annotator 1, Annotator 2, and Annotator 3 achieve Pearson correlations ofr=0\.920r=0\.920,r=0\.945r=0\.945, andr=0\.935r=0\.935with the average score, respectively\. In addition, both RMSE and MAE are markedly reduced in these comparisons, suggesting that score averaging effectively suppresses individual annotation noise and yields a more stable reference signal\.

The regression lines across all plots exhibit slopes slightly below unity and small intercept offsets, indicating mild systematic differences in score calibration among annotators\. Nevertheless, the bias values remain close to zero, suggesting no severe over\- or under\-estimation tendencies for any individual annotator\.

Taken together, these results confirm that the proposed evaluation protocol yields reliable and reproducible human judgments\. The strong inter\-annotator agreement and the improved consistency obtained through averaging support the use of the averaged human score as the ground\-truth reference in subsequent correlation analyses with model predictions\.

![Refer to caption](https://arxiv.org/html/2606.17727v1/figs/annotators/1vs2.png)\(a\)Annotator 1 vs Annotator 2
![Refer to caption](https://arxiv.org/html/2606.17727v1/figs/annotators/1vs3.png)\(b\)Annotator 1 vs Annotator 3
![Refer to caption](https://arxiv.org/html/2606.17727v1/figs/annotators/2vs3.png)\(c\)Annotator 2 vs Annotator 3
![Refer to caption](https://arxiv.org/html/2606.17727v1/figs/annotators/1vsavg.png)\(d\)Annotator 1 vs Avg Score
![Refer to caption](https://arxiv.org/html/2606.17727v1/figs/annotators/2vsavg.png)\(e\)Annotator 2 vs Avg Score
![Refer to caption](https://arxiv.org/html/2606.17727v1/figs/annotators/3vsavg.png)\(f\)Annotator 3 vs Avg Score

Figure 10:Inter\-Annotator Agreement Analysis\.

## Appendix EPrompts and Model Settings

### E\.1Prompts

Task Generation PromptsWe present the prompts used for long webpage generation and verification, as shown in Figures[11](https://arxiv.org/html/2606.17727#A5.F11)–[13](https://arxiv.org/html/2606.17727#A5.F13)\.

W\-VFR Generation PromptsGeneration prompts for W\-VFR under single\-image input setting and multi\-image input setting are shown in Figures[14](https://arxiv.org/html/2606.17727#A5.F14)–[15](https://arxiv.org/html/2606.17727#A5.F15)and Figures[16](https://arxiv.org/html/2606.17727#A5.F16)–[17](https://arxiv.org/html/2606.17727#A5.F17), respectively\.

W\-VFR Evaluation PromptsEvaluation prompts for W\-VFR are shown in Figures[18](https://arxiv.org/html/2606.17727#A5.F18)–[20](https://arxiv.org/html/2606.17727#A5.F20)\.

W\-FFR Generation PromptsGeneration prompts for W\-FFR under single\-image input setting and multi\-image input setting are shown in Figures[21](https://arxiv.org/html/2606.17727#A5.F21)–[22](https://arxiv.org/html/2606.17727#A5.F22)and Figures[23](https://arxiv.org/html/2606.17727#A5.F23)–[24](https://arxiv.org/html/2606.17727#A5.F24), respectively\.

W\-FFR Evaluation PromptsEvaluation prompts for W\-VFR are shown in Figures[25](https://arxiv.org/html/2606.17727#A5.F25)–[26](https://arxiv.org/html/2606.17727#A5.F26)\.

Prompt for HTML webpage Task generation for W\-FFR\. \(Part 1\)You are an expert in designing Goal\-Oriented Web Task Benchmarks for long webpages with complex interactions\. Your focus is on modeling realistic, end\-to\-end user goals rather than atomic navigation actions\.Inputs:\- A full\-length webpage screenshot \(the page may require vertical scrolling to be fully visible\)\.\- \(Optional\) A virtual account credential, which may only be used if login\-related UI elements are explicitly visible in the screenshot:``` { "benchmark_account": { "username": "test_user_001", "email": "[email protected]", "password": "P@ssw0rd!001" } } ``` Critical clarifications \(must be followed\):\- The tasks you design are not atomic UI navigation steps, but complex, real\-world user goals\.\- Each task must include:\- A clearly defined final goal\- Multi\-step interactions \(e\.g\., filtering, configuration, comparison, decision\-making, submission\)\- Interactions spanning multiple page regions or modules\- A final goal with explicit and verifiable success signalsExamples \(for style reference only; do not replicate\):\- Selecting the cheapest direct flight among all available options\- Configuring a computer with 16GB RAM and 2TB storage and adding it to the cart\- Finding the hotel with the highest rating and lowest price in the current city\- Locating and confirming the default value of a key parameter in documentationObjective:Based on the screenshot, infer a plausible interactive webpage and design 3–4 complex interaction tasks\.Task design requirements:\- Each task represents a realistic user goal rather than a single\-button action\- Each task contains at least three semantically meaningful interaction steps\- Tasks are completable within a long webpage \(scrolling, filtering, tab switching allowed\)\- Filtering, comparison, or decision\-making tasks must include explicit numeric or discrete outcomes \- Key success values must be derived from task execution through calculation or extraction\- All tasks must be automatically verifiable via observable success signals defined in the schemaAuthentication task rules:\- Authentication\-related tasks are allowed only if the screenshot explicitly shows one of the following:\- Login / Log in / Sign in\- Register / Sign up\- Logout / Log out\- User avatar / Account menu / Profile center\- If none of the above are visible:\- Do not design any login, registration, or logout tasks\- All tasks must be executable in a logged\-out stateOutput requirements:\- Output only one JSON object\- Do not include Markdown

Figure 11:This prompt is designed for HTML webpage Task generation for W\-FFR \(Part 1\)\.
Prompt for HTML webpage Task generation for W\-FFR\. \(Part 2\)\- Do not include explanatory text\- The output must strictly conform to the schema belowSchema \(complex goal\-oriented task version\):``` { "page_summary": { "site_or_product": "...", "page_type": "e-commerce | ticketing | travel | documentation | SaaS | news | comparison | other", "primary_modules": [ "Clearly visible main modules in the screenshot" ], "notable_interactives": [ "Key interactive controls enabling complex goals" ], "auth_visible": true | false, "auth_evidence": [ "Visible evidence proving authentication presence, if any" ] }, "benchmark_account": { "username": "test_user_001", "email": "[email protected]", "password": "P@ssw0rd!001" }, "tasks": [ { "task_id": "T1", "task_type": "purchase | configuration | comparison | selection | information_verification | auth_dependent | mixed", "task_name": "Concise summary of the task objective", "user_goal": "One-sentence description of the real user’s final goal", "instruction": "Goal-oriented instruction to the agent (in English)", "constraints": [ "Mandatory business or logical constraints" ], "preconditions": [ "e.g., logged-out state, filter panel expanded, city selected" ], "steps": [ { "action": "click | type | select | scroll | compare", "target_description": "UI target described by location and semantic meaning", "value": "Specific input or selection value, or null" } ], ```

Figure 12:This prompt is designed for HTML webpage Task generation for W\-FFR \(Part 2\)\.
Prompt for HTML webpage Task generation for W\-FFR\. \(Part 3\)``` "success_criteria": [ "At least two observable, automatically verifiable success signals with explicit quantitative or discrete values" ], "verification_hints": { "text_assertions": [ "Key texts or values expected after successful completion" ], "layout_assertions": [ "Observable layout or state changes" ], "selector_strategy": [ "Prefer semantic regions for configuration or pricing", "Fallback to aria/role", "Lastly, structured XPath" ], "suggested_selectors": [ { "purpose": "Core element for final verification", "css": null, "xpath": null, "aria": null } ] }, "difficulty": "medium | hard | very_hard", "coverage_tags": [ "filtering", "decision_making", "multi_step", "long_page_navigation" ] } ] } ```

Figure 13:This prompt is designed for HTML webpage Task generation for W\-FFR \(Part 3\)\.
Prompt for HTML webpage generation under the single\-image input setting for W\-VFR\. \(Part 1\)You are a Web Visual Replication Specialist\.Your task is: given a full long webpage screenshot, generate a standalone HTML file that can be opened directly in a browser, reproducing the screenshot’s visual appearance, page structure, and page scale as accurately as possible\.This is a Visual Fidelity task\. Real business interaction logic is not evaluated at this stage\.——————————–Input:——————————–\- One full long webpage screenshot \(a vertical long image containing the entire page\)\- The real pixel dimensions of the screenshot: \- Target page width \(pixels\): \{TARGET\_PAGE\_WIDTH\_PX\}\- Target page height \(pixels\): \{TARGET\_PAGE\_HEIGHT\_PX\} ——————————– Output Requirements \(must strictly follow\) ——————————– \- You must output one and only one complete HTML file content \- The output must start with<\!doctypehtml\><\!doctypehtml\> \- The output must end with</html\></html\> \- Do not output any explanatory text, comments, Markdown, or code fences \- The output must be directly savable as index\.html and open in a desktop browser ——————————– Implementation Constraints ——————————– \- Use native HTML / CSS / JavaScript only \- All styles must be defined inline within a <style\> block \- Do not use any third\-party libraries, frameworks, CDNs, or build tools \- Do not reference any external images, fonts, or resources \- For images / avatars / logos in the screenshot: \- Recreate them using SVG or CSS placeholder blocks \- Keep their visual size and position \- Keep semantics as close as possible to the original content ——————————– Core Visual Replication Requirements ——————————– 1\) Page Structure and Layout \- Strictly replicate the information architecture and module order shown in the screenshot, such as: \- Top navigation / secondary navigation \- Sidebar \(if present\) \- Main content area \- Card lists / tables / section modules \- Footer \(if present\) \- The relative positions, width proportions, and layering relationships of modules must match the screenshot2\) Style and Visual Elements\- Reproduce the overall color scheme \(background, primary, secondary colors\)

Figure 14:This prompt is designed for the single\-image input setting, where a single full\-page webpage screenshot is provided as input and the model is required to generate a complete HTML webpage that visually replicates the input screenshot\.
Prompt for HTML webpage generation under the single\-image input setting for W\-VFR\. \(Part 2\)\- Reproduce font hierarchy \(title/body/note sizing and weight relationships\)\- Reproduce spacing system \(padding / margin\)\- Reproduce borders, corner radius, shadows, and divider line styles\- The visual density of cards, lists, and tables must match the screenshot3\) Page Scale and Dimension Alignment \(Critical\)\- The generated page must cover all content visible in the screenshot\- The total scroll height should align as closely as possible to \{TARGET\_PAGE\_HEIGHT\_PX\} pixels\- Do not inflate height by meaningless repetition\- If extension beyond the screenshot is necessary to keep the structure complete:\- Only extend using module types and visual styles already present in the screenshot \- Extensions must be reasonable and restrained, and must not break overall proportions \- The overall layout proportions must match the screenshot corresponding to the target width \{TARGET\_PAGE\_WIDTH\_PX\} pixels ——————————– Content and Placeholder Rules ——————————– \- Replicate text content and typographic layout as faithfully as possible \- Preserve the original page language whenever possible \- If text is illegible, use reasonable placeholder text while keeping the same line count, paragraph structure, and text width \- Lists / tables / cards may use mock data, but quantity and density must match the screenshot ——————————– Interaction Constraints \(Intentionally Weakened\) ——————————– \- No real interaction logic is required \- Hover / focus visual states are allowed \- All buttons or controls may be empty or placeholder on click ——————————–Now Begin——————————–Based on the provided long webpage screenshot and the given target page dimensions, output the complete HTML code for visual replication evaluation\.

Figure 15:This prompt is designed for the single\-image input setting, where a single full\-page webpage screenshot is provided as input and the model is required to generate a complete HTML webpage that visually replicates the input screenshot\.
Prompt for HTML webpage generation under the multi\-image input setting for W\-VFR\. \(Part 1\)You are a Web Visual Replication Specialist\. Your task is: given multiple screenshot segments \(all of which come from the same single long webpage\), generate one standalone HTML file that can be opened directly in a desktop browser, reproducing the webpage’s visual appearance, page structure, and page scale as accurately as possible\. This is a visual fidelity task\. Real business interaction logic is not evaluated at this stage\.Input Description1\. Webpage Screenshot Segments\- The input consists of multiple screenshot segments from the same single long webpage\.\- All segments originate from one webpage, not multiple webpages or paginated pages\.\- The segments are provided in top\-to\-bottom order\.\- Each segment covers a continuous vertical region of the webpage\.\- Adjacent segments may partially overlap\.\- Overlapping regions are provided only to help infer alignment and continuity\.2\. Original Webpage Dimensions\- The real pixel dimensions of the original complete webpage are:\- Target page width \(pixels\): TARGET\_PAGE\_WIDTH\_PX \- Target page height \(pixels\): TARGET\_PAGE\_HEIGHT\_PX Critical Interpretation Rules \(Must Be Strictly Followed\)1\. Single\-Webpage Constraint\- All screenshot segments must be treated as parts of one single continuous webpage\.\- Conceptually stitch all segments into one complete vertical page\.\- Do not interpret different segments as different webpages or separate pages\.2\. Overlap Handling\- Overlapping regions may only be used for alignment and continuity reasoning\.\- Any content appearing in overlapping regions must be generated only once in the final HTML\.\- Do not duplicate global elements such as headers, navigation bars, or footers due to segmentation\.3\. Allowed Repetition\- Repetition is allowed only if the raw webpage itself visually contains repeated elements, such as:\- Long lists with repeated items \- Repeated cards \- Multiple rows in a table \- Do not repeat content due to screenshot overlap\. Output Requirements \(Strict\) \- Output one and only one complete HTML file\. \- The output must start with <\!doctype html\> and end with </html\>\. \- Output HTML only\. Do not include any explanations, comments, Markdown, or code block markers\. \- The output must be directly savable as index\.html and openable in a desktop browser\. Implementation Constraints\- Use native HTML, CSS, and JavaScript only\.\- All CSS must be placed inside a single <style\> block\.\- Do not use any third\-party libraries, frameworks, CDNs, or build tools\.\- Do not reference any external resources, including images, fonts, or scripts\.\- For images, avatars, or logos appearing in the screenshots:\- Recreate them using SVG shapes or CSS placeholder blocks\.\- Preserve their visual size, aspect ratio, and position\.Core Visual Replication Requirements

Figure 16:This prompt is designed for the multi\-image input setting, where multi full\-page webpage screenshots are provided as input and the model is required to generate a complete HTML webpage that visually replicates the input screenshot\.
Prompt for HTML webpage generation under the multi\-image input setting for W\-VFR\. \(Part 2\)1\. Page Structure and Layout\- Replicate the information architecture of a single webpage, including but not limited to:\- A global header or navigation bar \(if present, only once\)\- A sidebar \(if present\)\- A continuous main content flow\- A footer \(if present, only once\)\- The page content must form one continuous vertical information flow\.\- The vertical ordering of all modules \(sections, cards, tables, lists, etc\.\) must follow the top\-to\-bottom order implied by all segments combined\.\- Any region that appears in multiple segments due to overlap must appear only once on the page\.2\. Styling and Visual Elements\- Match the following visual characteristics as closely as possible:\- Backgrounds, text colors, borders, and highlights\- Font hierarchy \(titles, subtitles, body text, auxiliary text\)\- Spacing relationships \(padding, margins, gaps between modules\)\- Dividers, corner radii, shadows, and other visual details\- If textual content is not legible, placeholder text may be used, but block dimensions and line counts must be preserved\.3\. Page Scale and Dimension Alignment \(Critical\)\- The generated page must cover all content visible across all screenshot segments\.\- The page should be designed against a viewport width of TARGET\_PAGE\_WIDTH\_PX pixels\.\- The total scroll height should be determined naturally by faithful replication of the content and should be as close as possible to TARGET\_PAGE\_HEIGHT\_PX\.\- Do not artificially increase page height by duplicating overlapping content, adding meaningless modules, or inserting empty space\.\- If the page content has been fully replicated but the final page height differs from TARGET\_PAGE\_HEIGHT\_PX, this difference must be preserved as\-is\.Do not compensate for the difference by adding empty space, spacers, placeholder regions, or by artificially increasing padding or margin values\.\- Minimal extension is allowed only if structural completeness requires it:\- Only when screenshots clearly indicate truncated modules or when layout semantics require closure \(for example, an unfinished container or an obviously incomplete table\)\.\- Only module types already present in the screenshots may be used\.\- Extensions must be restrained, proportional, and visually consistent\.\- Extensions must not be performed for the purpose of matching the target page height\.Content and Placeholder Rules\- Preserve the original language of the webpage\.\- Accurately replicate all clearly legible text whenever possible\.\- For illegible text, placeholders may be used, but layout geometry must remain consistent\.\- For lists, tables, or cards with mock data:\- Quantity, density, alignment, and rhythm must match the screenshots\. Interaction Constraints \- No real interaction logic is required\. \- Buttons and controls may have placeholder behavior only\. Begin Execution Based on the provided webpage screenshot segments \(with possible overlap\) and the target page dimensions, output the complete HTML code for visual replication evaluation\.

Figure 17:This prompt is designed for the multi\-image input setting, where multi full\-page webpage screenshots are provided as input and the model is required to generate a complete HTML webpage that visually replicates the input screenshot\.
Prompt for Evaluating Similarity for W\-VFR \(Part 1\)\.You are a Web Visual Fidelity Evaluator\.Your task is to compare two full\-length vertical webpage screenshots and assess how well an AI\-generated webpage \(Image B\) matches the original webpage \(Image A\) in terms of visual appearance, page layout structure, and page scale consistency\.This is a relative consistency comparison task\. All judgments must be made strictly based on the comparison of Image B against Image A\.You only evaluate visual and layout fidelity\. Do not evaluate usability, readability quality, aesthetic preference, business logic, or any interactive behavior\.\[Input\]\- Image A: Original full\-length webpage screenshot \(reference page / Ground Truth\) \- Page height \(pixels\): \_\_REF\_PAGE\_HEIGHT\_PX\_\_\- Image B: Webpage screenshot rendered from AI\-generated code \(prediction page\) \- Page height \(pixels\): \_\_PRED\_PAGE\_HEIGHT\_PX\_\_\[General Evaluation Principles\]\- All judgments must be strictly based on visually observable information in the screenshots\- All scores must reflect the degree of consistency between Image B and Image A, not the standalone quality of Image B\- Differences in textual content or the use of placeholder text are acceptable as long as the overall layout and structure are preserved\- Ignore hover, focus, animation, or other interactive states not visible in static screenshots\- Do not subjectively balance, normalize, or adjust scores; scoring must strictly follow the criteria\[Special Rules for Images and Icons — MUST FOLLOW\]\- Image and icon assets from the original webpage were not provided to the model\- Do not evaluate the semantic content, design style, or visual details of images or icons\- Do not penalize differences in icon style or image content\- Only evaluate the structural role of images and icons, including: \- Whether they appear in the correct locations\- Whether placeholder size and aspect ratio are reasonable\- Whether their layout relationship with surrounding text, cards, or sections matches the reference page\- If images or icons are missing, misplaced, or have severely incorrect size or aspect ratio, penalties should still apply\[Scoring Requirements\]You must assign an integer score from 0 to 10 \(integers only, no decimals\) for each of the following five dimensions\.Scoring must be: \- Strict \- Stable \- ReproducibleEach score must be accompanied by a clear, concrete, and verifiable rationale that directly justifies the assigned value\. Vague explanations are not allowed\.Dimension 1: Page Scale and Scroll Consistency\(page\_scale\_and\_length, 0–10\)Evaluation criteria:\- Use the provided page heights as the primary quantitative reference to judge whether overall page height is similar \- Whether there is obvious truncation, repetition, missing content, or abnormal vertical stretching \- Whether the vertical ordering of major content blocks matches the reference page \- Whether large content blocks are missing or unnecessarily added, resulting in significant height deviationScoring reference:10 = Page height and vertical structure almost perfectly match \(height deviation≤\\leq5%\)

Figure 18:This prompt is designed for evaluating similarity for W\-VFR\.
Prompt for Evaluating Similarity for W\-VFR \(Part 2\)\.9 = Page height and content ordering are highly consistent, with only negligible proportional differences8 = Overall page length matches the reference, with only minor local compression or stretching7 = Overall length is similar, but multiple local proportions appear unnatural6 = Page height broadly matches the reference, but some sections are clearly mis\-scaled5 = Main page framework matches the reference, but noticeable missing or extra content blocks exist4 = Scroll length differs clearly, but overall page structure remains recognizable3 = Multiple section ordering or height errors relative to the reference2 = Severe page length mismatch; only a rough structural outline remains1 = Long\-page characteristics relative to the reference are largely lost0 = Not meaningfully comparable as the same pageDimension 2: Global Layout Structure Consistency\(global\_layout, 0–10\)Evaluation criteria:\- Whether single\-column or multi\-column layout structure matches the reference page \- Whether top navigation, sidebars, main content area, and footer exist and are placed reasonably \- Whether left\-right and top\-bottom spatial relationships are consistent with the reference pageScoring reference:10 = Global layout structure almost perfectly matches the reference page9 = Layout matches with only pixel\-level width differences8 = Column structure matches with minor alignment deviations7 = Layout is mostly correct with small positional offsets6 = Core layout is preserved, but secondary regions deviate5 = Layout intent is similar to the reference, but column or region logic is loose4 = Clear layout errors relative to the reference \(e\.g\., misplaced sidebar\)3 = Weak structural correspondence2 = Layout structure severely deviates from the reference1 = Layout is almost entirely different0 = No comparable layout structure existsDimension 3: Section\-Level Structure and Hierarchy\(section\_hierarchy, 0–10\)Evaluation criteria:\- Whether the number of sections and their grouping correspond to the reference page \- Whether hierarchical relationships \(title→\\rightarrowsubtitle→\\rightarrowlist/card\) are preserved \- Whether section boundaries, separators, and grouping logic match the reference pageScoring reference:10 = All sections and their hierarchical relationships closely match the reference page9 = Nearly all sections are correct with very clear hierarchy8 = Sections are complete with only minor hierarchy deviations7 = Most sections are correct, with small merges or splits6 = Major sections are present, but hierarchy is unstable5 = Moderate section completeness; structure is partially blurred4 = Multiple sections are missing or newly added relative to the reference3 = Hierarchy is confused but still recognizable2 = Only fragmentary section structure remains1 = Section hierarchy is largely collapsed0 = Section structure is unrecognizableDimension 4: Local Visual Styling Consistency\(visual\_styling, 0–10\)Evaluation criteria:\- Whether font hierarchy and relative font sizes match the reference page \- Whether spacing, alignment, padding, and margins match the reference page \- Whether visual elements such as cards, background blocks, dividers, colors, and shadows match the reference pageScoring reference:10 = Local visual styling matches the reference page at a high level across all aspects

Figure 19:This prompt is designed for evaluating similarity for W\-VFR\.
Prompt for Evaluating Similarity for W\-VFR \(Part 3\)\.9 = Visual styling is highly consistent, with only detail\-level differences8 = Overall visual styling matches the reference; differences do not affect stylistic alignment7 = Visual styling is generally close, but spacing or alignment appears simplified or rigid6 = Visual styling broadly follows the reference, but multiple styling details deviate5 = Core visual styling elements are present, but consistency with the reference is noticeably reduced4 = Obvious visual styling deviations relative to the reference page3 = Large visual styling differences relative to the reference, though layout remains interpretable2 = Severe visual styling mismatch relative to the reference page1 = Minimal visual styling correspondence with the reference page0 = Visual styling is entirely inconsistent with the reference pageDimension 5: Information Density and Section Pacing Consistency\(information\_density, 0–10\)Evaluation criteria:\- Whether overall information density matches the reference page \- Whether the density and spacing of lists, cards, and paragraphs match the reference page \- Whether long\-page section pacing and vertical rhythm match the reference pageScoring reference:10 = Information density and section pacing closely match the reference page9 = Information density is highly consistent, with only very minor local differences8 = Overall information density matches the reference; small differences do not affect pacing alignment7 = Information density is generally similar, but section pacing is slightly altered6 = Noticeable local information density differences relative to the reference5 = Information density alignment is unstable, reducing overall pacing consistency4 = Clear information density mismatch relative to the reference, disrupting pacing correspondence3 = Information density differences fragment pacing correspondence2 = Severe information density mismatch relative to the reference1 = Information density and pacing correspondence with the reference are largely lost0 = Information density and section pacing are entirely inconsistent with the reference page————————————————–\[Diagnostic Requirements\]Identify up to five of the most critical sources of inconsistency, prioritizing: \- Page scale and scroll issues \- Layout or structural inconsistencies \- Missing, extra, or clearly misaligned sectionsIf important sections are missing or newly added, they must be explicitly listed\.\[Output Requirements — MUST BE STRICTLY FOLLOWED\]You must output one and only one JSON object\. Do not include any additional explanations, comments, Markdown, or natural language text\.Output format:\{ "dimension\_scores": \{ "page\_scale\_and\_length": \{ "score": 0, "rationale": "Concrete justification based on page height deviation, scroll length, and vertical structural alignment with the reference page" \}, "global\_layout": \{ "score": 0, "rationale": "Concrete justification based on global layout structure and spatial correspondence with the reference page" \}, "section\_hierarchy": \{ "score": 0, "rationale": "Concrete justification based on section count, hierarchy, and grouping consistency relative to the reference page" \}, "visual\_styling": \{ "score": 0, "rationale": "Concrete justification based on local visual styling consistency relative to the reference page" \}, "information\_density": \{ "score": 0, "rationale": "Concrete justification based on information density and section pacing consistency relative to the reference page" \} \}, "major\_mismatches": \[ "…" \], "missing\_or\_extra\_sections": \[ "…" \], "brief\_judgement": "One\-sentence summary of overall visual fidelity of the generated page relative to the reference page" \}

Figure 20:This prompt is designed for evaluating similarity for W\-VFR\.
Prompt for Generate Code for W\-FFR Task under Single\-image Input Setting \(Part 1\)\.You are a senior frontend engineer tasked with building high\-fidelity, fully interactive mock pages for Goal\-Oriented Long Web Tasks\.Inputs1\. A full\-page long webpage screenshot \- The total page length must be consistent with the reference\.2\. A task specification JSON \- Contains descriptions of all tasks that must be supported by the webpage\.3\. \(Optional\) benchmar\_account \- May be present in the task JSON\.4\. \(Required\) Original long webpage height under a 1920×1080 viewport, in pixels: FINAL\_TARGET\_SCROLL\_HEIGHT\_PXYour Objective\- Generate a single HTML file \(inline CSS \+ inline JavaScript\)\.\- Reproduce the structure, modules, and visual layout of the screenshot as faithfully as possible\.\- The page must be a long, vertically scrollable webpage\.\- All tasks defined in the task JSON must be fully implemented, including their interactions and verifiable success signals\.\- No external resources or network requests are allowed:\- No CDN \- No third\-party libraries \- The initial page render must be deterministic and reproducible\. Auth Logic Rules \(Mandatory\) When to implement auth \- Only implement authentication logic if and only if the task JSON includes auth\-related tasks\. \- If auth tasks are not present: \- Do not implement any login / registration UI \- Do not implement any auth state logic If auth is required, all conditions below must be satisfied\- All accounts and passwords must be hard\-coded in the HTML source\- Do not use localStorage or any external storage for credential validationRegistration\- Check for duplicate usernames and emails\- Both success and failure must provide clear, observable UI feedback\- e\.g\., inline messages or toast notificationsLogin \- Validate \(username or email — one is sufficient\) \+ password\- After successful login:\- Display the username \- Hide login / register buttons \- Show a logout button Logout \- Clear the session \- Restore the unauthenticated UI state Selectors \- All critical buttons and input fields must have stable selectors \- id or data\-testid Page Structure & Layout Fidelity \(Mandatory\)\- Reconstruct all major structural modules visible in the screenshot, including but not limited to:\- Header / navigation bar\- Sidebar \(if present\)\- Main content area\- Right sidebar \(if present\)

Figure 21:This prompt is designed for generating Code for W\-FFR Task under single\-image input setting\.
Prompt for Generate Code for W\-FFR Task under Single\-image Input Settings \(Part 2\)\.\- Footer \(if present\) \- Module order, information density, and hierarchy should closely match the screenshot\.\- Page height must be achieved through real structural content, such as:\- Lists\- Cards\- Text blocks\- Tables\- Recommendation sections\- Do not artificially pad height using large empty div elements\.\- Large image\-like regions in the screenshot may be implemented as fixed\-size placeholders, but:\- They must correspond to real business modules \(e\.g\., banner, featured section, chart area\)\.\- For dropdowns / selectors, default value must be empty\- Provide reasonable selectable optionsLength Constraint \(Strict\)\- FINAL\_TARGET\_SCROLL\_HEIGHT\_PX is the reference height\.\- The generated page must satisfy:0\.9 × FINAL\_TARGET\_SCROLL\_HEIGHT\_PX≤\\leqdocument\.body\.scrollHeight≤\\leq1\.1 × FINAL\_TARGET\_SCROLL\_HEIGHT\_PX\- Do not approximate length by “number of screens” or viewport multiples\.\- Page height must already satisfy the constraint on initial render\.\- Do not dynamically add or remove content at runtime to adjust height\.Interaction Implementation \(Mandatory\)\- Fully implement all interaction types required by the task JSON, including but not limited to:\- Sorting / filtering / searching\- Pagination / load more\- Expand / collapse\- Clicking list items to enter detail views\- Every task’s success\_criteria must correspond to a clear, observable signal, such as:\- Text changes\- Counter or state changes\- Module visibility changes\- Explicit feedback messages \(toast or inline\)Stable Selectors \(Mandatory\)\- All task\-related interactive elements must have stable selectors:\- id or data\-testid\- For repeatable items \(lists, cards\):\- Use attributes such as data\-item\-id, data\-qid, etc\.\- This must support stable targeting for detail navigation or state changesDefault Value Rules\- All components must start with empty or unselected default values\- For dropdowns, checkboxes, or similar inputs:\- Provide options defined in the task JSON\- Task\-related options should not be the default\- Prefer not to place task options as the first selectable itemOutput Requirements \(Strict\)\- Output only the complete HTML source code\- No Markdown; No explanations or comments outside the code\- No randomness, All data must be embedded directly in JavaScript arrays or objects within the HTML

Figure 22:This prompt is designed for generating Code for W\-FFR Task under single\-image input setting\.
Prompt for Generate Code for W\-FFR Task under Multi\-image Input Setting \(Part 1\)\.You are a senior frontend engineer tasked with building high\-fidelity, fully interactive mock pages for Goal\-Oriented Web Tasks\.Inputs:1\) Webpage screenshot segments:\- The input consists of multiple screenshot segments, all taken from the same long webpage\.\- These segments are provided in top\-to\-bottom order\.\- Each segment covers a continuous vertical region of the webpage\.\- Adjacent segments may partially overlap; overlapping regions are provided only to help infer alignment and continuity\.2\) A task specification JSON:\- Describes all tasks that must be supported on the webpage\.3\) \(Optional\) benchmark\_account:\- May be present in the task JSON\.4\) \(Mandatory\) The pixel height of the original long webpage screenshot under a 1920×1080 viewport, in pixels, denoted as: FINAL\_TARGET\_SCROLL\_HEIGHT\_PXYour Objective:\- Generate a single HTML file \(inline CSS \+ inline JavaScript\) that reproduces the structure, modules, and visual layout of the webpage shown in the screenshots as faithfully as possible, and that forms a long, vertically scrollable page\.\- All tasks defined in the task JSON must be fully implemented, including their interactions and verifiable success signals\. \- No external resources or network requests are allowed \(no CDN, no third\-party libraries\)\.\- The initial page render must be deterministic and reproducible\.Auth Logic Conditional Rules \(Mandatory\):\- Only if the task JSON contains authentication\-related tasks:\- Implement local simulated authentication: registration / login / logout\.\- Otherwise, do not implement any authentication logic \(no login/register UI, no auth state machine\), to avoid deviating from the screenshot content\.If authentication is required \(local simulated auth\), all of the following conditions must be met:\- All accounts and password validation must be hard\-coded in the HTML source\.\- Do not use localStorage or any other storage mechanism to validate credentials\.Registration flow:\- Check for duplicate usernames and emails\.\- Both success and failure cases must provide clear, observable UI feedback \(text or toast\)\.Login flow:\- Validate username or email \(either one is sufficient\) plus password\.\- After successful login:\- Display the username; Hide login and registration buttons; Show a logout button\.Logout flow:\- Clear the session; Restore the unauthenticated UI state\.Selectors:\- All critical buttons and input fields must have stable selectors \(id or data\-testid\)\.Long Webpage Structure and Layout Reconstruction \(Mandatory\):\- Single\-page constraint:\- All screenshot segments must be treated as parts of one single continuous webpage\.\- Conceptually stitch all segments together into one complete vertical page\.\- Do not interpret different segments as different webpages or independent pages\.\- Overlap handling:\- Use overlapping regions only for alignment and continuity inference\.

Figure 23:This prompt is designed for generating Code for W\-FFR Task under multi\-image input setting\.
Prompt for Generate Code for W\-FFR Task under Multi\-image Input Setting \(Part 2\)\.\- Any content appearing in overlapping regions must be generated only once in the final HTML\.\- Do not duplicate global elements \(such as header, navigation bar, or footer\) due to segmentation\.\- Reconstruct all major structural modules visible in the screenshots, including but not limited to:\- Top navigation \(header / nav\), Sidebar \(if present\)\- Main content area\- Right sidebar \(if present\)\- Footer \(if present\)\- The order of modules, information density, and overall layout should closely match the screenshots\.\- Page height must be formed naturally through real structural content \(lists, cards, paragraphs, recommendation sections, tables, etc\.\):\- Do not artificially increase height using large empty divs\.\- Large image\-like areas in the screenshots may be implemented as fixed\-size placeholder containers matching the screenshot dimensions, but such placeholders must correspond to explicit business modules \(e\.g\., banner, image\-text card section, recommendation slot, chart area\)\.\- If dropdowns or selectors are present:\- The default value must be empty\.\- A reasonable set of selectable options must be provided\.Length Constraint \(Strict, based on original screenshot height\):\- FINAL\_TARGET\_SCROLL\_HEIGHT\_PX = FINAL\_TARGET\_SCROLL\_HEIGHT\_PX\- The generated page’s document\.body\.scrollHeight must satisfy:0\.9 × FINAL\_TARGET\_SCROLL\_HEIGHT\_PX≤\\leqscrollHeight≤\\leq1\.1 × FINAL\_TARGET\_SCROLL\_HEIGHT\_PX \- Do not approximate length using “number of screens” or viewport multiples\.\- The page height must satisfy the constraint at initial HTML render time\.\- Do not rely on runtime logic to dynamically add or remove content to adjust height\.Interaction Implementation \(Must cover all tasks\):\- Fully implement all interaction types involved in the tasks, including but not limited to:\- Sorting / filtering / searching\- Pagination / load more; Expand / collapse\- Clicking list items to enter detail views\- Each task’s success\_criteria must correspond to a clear, observable feedback signal, such as:\- Text content changes \- Count or state changes\- Module visibility changes \- Explicit feedback messages \(toast or inline text\)Stable Selectors \(Mandatory\):\- All task\-related interactive elements must have stable selectors:\- Use id or data\-testid\.\- For repeatable list items or cards:\- Use attributes such as data\-item\-id, data\-qid, etc\.\- These must support stable targeting for entering detail views or triggering state changes\.Default Value Constraints:\- All components must start with empty or unselected default values\.\- For dropdowns, checkboxes, or other inputs requiring options:\- Provide options as defined in the task JSON\.\- Task\-related options should not be selected by default\.\- Prefer not to place task options as the first selectable option, to allow explicit user selection\.Output Requirements \(Strict\):\- Output only the complete HTML source code\. \- Do not use Markdown\.\- Do not include any explanatory text outside the code\. \- Do not include any random logic\.\- All data must be embedded directly within JavaScript arrays or objects inside the HTML\.

Figure 24:This prompt is designed for generating Code for W\-FFR Task under multi\-image input setting\.
Prompt for ActorAgent\.You are a GUI testing agent\. Your goal is to verify whether a webpage can execute a given operation sequence\. The current task is to perform a specific operation sequence, which may consist of one or more action steps\.\[Target Step\]Type: \{action\_type\}Description: desc\{f"Input value / option: \{val\}" if val else ""\}Important notice:If the description requires completing a full login or registration process but does not provide default username and password, please use the following credentials:\{ "username": "test\_user\_001", "email": "test\_user\_001@example\.com", "password": "P@ssw0rd\!001" \}Please carefully observe the screenshot and the DOM Tree to locate the corresponding element’s numeric ID\. Many described actions may not be obvious from the DOM Tree alone, so you must combine visual information from the screenshot to make a judgment\. However, if you are confident that the element described in the instruction does not exist on the page, directly outputboxedFAIL and explain the reason\. You are not required to forcibly execute any action in such cases\.``` Output format: You must use LaTeX \boxed{} to wrap each instruction. - Click: \boxed{click[id]} - Input: \boxed{enter[id][{val if val else ’content’}]} - Select: \boxed{select[id][{val if val else ’option’}]} - Scroll: \boxed{scroll[id]} (Note: scroll the page to bring the target element into view) If multiple instructions are required, output multiple \boxed{} commands in sequence. If the element cannot be found or the action cannot be performed, output \boxed{FAIL} and explain the reason. DOM information: {domtree} ```

Figure 25:This prompt is designed for evaluating accuracy for W\-FFR\.
Prompt for CriticAgent\.You are a verification agent\. I have just attempted to execute an operation sequence\. Your task is to determine whether the webpage has undergone the expected change\.\[Attempted Operation\] Description: desc Type: step\_info\[’action’\] Value: step\_info\.get\(’value’, ’N/A’\)Please compare the screenshots before and after the operation\. If the operation is successful \(e\.g\., text appears in an input field, the page navigates, a dropdown selection changes, or a new element appears\), outputs​u​c​e​s​s​s\. If there is no change or the change does not match the description, outputf​a​i​l​e​d\. For example, if the description says to click the right\-side button but the left\-side button was clicked, or if the page shows no response\.Pay special attention: If the operation type is “scroll”, even if the page appears unchanged, carefully read the operation description and observe whether the page has been scrolled to the required position\. It is possible that the required scroll position is the current position, resulting in no visible change; in such cases, the operation should still be judged as successful\.Briefly explain the reason\.``` messages = [ { "role": "user", "content": [ {"type": "text", "text": prompt}, {"type": "text", "text": "[Screenshot Before Operation]:"}, {"type": "image_url", "image_url": {"url": f"data:image/png; base64,{before_img}"}}, {"type": "text", "text": "[Screenshot After Operation]:"}, {"type": "image_url", "image_url": {"url": f"data:image/png; base64,{after_img}"}} ] } ] ```

Figure 26:This prompt is designed for evaluating accuracy for W\-FFR

### E\.2Model settings

To ensure fair comparison and reproducibility, we adopt deterministic decoding whenever supported by the model APIs\. Specifically, for models that expose sampling parameters, we set the temperature to 0 and the top\-ppvalue to 1, which minimizes randomness in the generated code\. For models that do not support explicit sampling control \(e\.g\., GPT\-5\.2\), we use the default decoding behavior provided by the API\.

Regarding generation length, long webpage replication requires producing a substantial amount of HTML, CSS, and JavaScript code, resulting in a high token demand\. Therefore, instead of using a fixed token budget, we configure themax\_completion\_tokensparameter to the maximum value supported by each model\. This design choice avoids premature truncation and allows each model to generate outputs under its own architectural constraints\. The specificmax\_completion\_tokenssettings for different models are summarized in Table[9](https://arxiv.org/html/2606.17727#A5.T9)\.

Table 9:Maximum completion token limits used for different models\.ModelMax CompletionTokensGPT\-5\.264000GPT\-4o16384Claude\-Sonnet\-4\-5\-Thinking64000Claude\-Opus\-4\-5\-2025110164000Gemini\-3\-Pro\-preview64000Gemini\-3\-Flash\-preview64000Doubao\-Seed\-1\-632000GLM\-4\.6V32000GLM\-4\.1V\-9B\-Thinking\-Flash32000Qwen3\-VL\-235B\-A22B\-Instruct64000Qwen3\-VL\-8B\-Instruct64000InternVL3\-78B32000Kimi\-VL\-A3B\-Thinking32000Table 10:Performance analysis of correctness under different dimensions under single\-image input settingModelPage Scaleand LengthGlobalLayoutSectionHierarchyVisualStylingInformationDensityOpen\-source VLMKimi\-VL\-A3B\-Thinking92\.6573\.0686\.9491\.8492\.24Qwen3\-VL\-8B\-Instruct61\.8448\.5758\.9864\.4963\.47InternVL3\-78B88\.7852\.6575\.7179\.8084\.90GLM\-4\.1V\-9B\-Thinking\-Flash51\.6328\.1646\.5357\.5555\.51GLM\-4\.6V36\.9413\.4727\.1431\.0236\.94Qwen3\-VL\-235B\-A22B\-Instruct42\.6526\.5333\.2742\.0444\.08Closed\-source VLMClaude\-Sonnet\-Thinking46\.1243\.8844\.6947\.5546\.94Claude\-Opus\-4\-5\-2025110147\.5544\.0844\.4947\.3548\.57GPT\-5\.218\.165\.9213\.6714\.4921\.43GPT\-4o97\.5568\.3791\.8473\.4797\.14Gemini\-3\-Pro\-preview11\.631\.844\.698\.9813\.88Gemini\-3\-Flash\-preview18\.783\.6713\.2715\.3121\.84Doubao\-Seed\-1\-680\.8230\.8255\.9258\.9876\.12Table 11:Performance analysis of correctness under different dimensions under multi\-image input settingModelPage Scaleand LengthGlobalLayoutSectionHierarchyVisualStylingInformationDensityOpen\-source VLMKimi\-VL\-A3B\-Thinking87\.1470\.6185\.9286\.9490\.82Qwen3\-VL\-8B\-Instruct59\.5942\.2447\.9657\.1458\.37InternVL3\-78B89\.1845\.5172\.8678\.3786\.53GLM\-4\.1V\-9B\-Thinking\-Flash95\.1088\.7891\.8493\.2793\.47GLM\-4\.6V25\.515\.3112\.8621\.2225\.31Qwen3\-VL\-235B\-A22B\-Instruct31\.029\.3918\.5721\.0230\.61Closed\-source VLMClaude\-Sonnet\-Thinking12\.450\.824\.084\.6910\.61Claude\-Opus\-4\-5\-2025110115\.310\.412\.2410\.6114\.69GPT\-5\.241\.221\.228\.375\.7128\.98GPT\-4o98\.3752\.4591\.2260\.8297\.14Gemini\-3\-Pro\-preview5\.310\.001\.022\.454\.90Gemini\-3\-Flash\-preview25\.511\.2215\.314\.6925\.71Doubao\-Seed\-1\-678\.988\.7847\.9641\.0271\.22

## Appendix FError Type and Cases Analysis

### F\.1Distribution of each dimension error rates for W\-VFR

Tables[10](https://arxiv.org/html/2606.17727#A5.T10)and[11](https://arxiv.org/html/2606.17727#A5.T11)report failure rates of various open\-source and closed\-source VLMs under single\-image and multi\-image input settings, where higher values indicate worse performance\. Overall, providing multiple images generally reduces failure rates across most models and dimensions, demonstrating that additional visual context helps models generate more correct webpage representations\. The improvement is particularly evident forPage Scale and Length,Global Layout, andSection Hierarchy, where multi\-image inputs allow better capture of the overall page structure\. Open\-source models show moderate gains on these structural dimensions, while closed\-source models, such as Claude and Gemini\-3\-Pro, achieve near\-zero failure rates under multi\-image settings, reflecting strong structural robustness\.

ForVisual StylingandInformation Density, failure rates also decrease with multi\-image inputs, but improvements are more moderate, indicating the inherent difficulty of accurately capturing fine\-grained style and dense content from screenshots alone\. Some models exhibit unique trends; for instance, GPT\-5\.2’sPage Scale and Lengthfailure rate increases under multi\-image inputs, suggesting sensitivity in integrating multiple images for certain structural aspects\. Overall, multi\-image inputs consistently enhance performance across nearly all dimensions, with the largest gains in structural correctness and smaller but positive gains in stylistic and content density attributes\.

### F\.2Error case analysis for W\-VFR

We analyze nine representative failure cases observed in our benchmark, which can be broadly categorized into four aspects: \(1\) HTML generation stability, \(2\) failures in the rendering stage, \(3\) scale and visual consistency, and \(4\) structural and semantic errors\.

Case 1As shown in Figure[27](https://arxiv.org/html/2606.17727#A6.F27), this example illustrates a failure case where the generated HTML is incomplete due to token length constraints\. In this case, the model exhausts the token budget during HTML generation, leading to a truncated output\. We observe several common patterns contributing to this issue, including excessively long style sections, repetitive generation of redundant content, and the emission of meaningless URLs followed by unbounded character sequences\. These behaviors prevent the model from properly terminating the HTML structure, resulting in an incomplete document that cannot be reliably rendered or evaluated in subsequent stages\.

![Refer to caption](https://arxiv.org/html/2606.17727v1/figs/error_case/1_Incomplete_html.png)Figure 27:Example of Incomplete HTML Generation due to Token ExhaustionCase 2As shown in Figure[28](https://arxiv.org/html/2606.17727#A6.F28), this example presents a failure case in the HTML\-to\-image rendering stage of our benchmark pipeline\. Although the generated HTML can be rendered by a standard web browser, the conversion from HTML to image fails\. Further inspection shows that the model repeatedly outputs redundant text until the token budget is exhausted, resulting in an incomplete HTML document\. On the rendered webpage, this repetitive content manifests as an abnormally large page width, which eventually causes the HTML\-to\-image engine to fail and produce an invalid image\.

![Refer to caption](https://arxiv.org/html/2606.17727v1/figs/error_case/2_Rendering_Breakdown.png)Figure 28:Example of HTML\-to\-Image Rendering FailureCase 3As shown in Figure[29](https://arxiv.org/html/2606.17727#A6.F29), this example illustrates a failure case where a large blank region appears at the bottom of the generated webpage\. Compared with the original image, the generated result contains an extended empty area with no meaningful content\. We find that this issue may stem from the prompt configuration, in which the original image size is provided as a reference\. During HTML generation, the model attempts to align with the given page height and fills the remaining space with blank regions, even though padding the layout with empty space or repetitive content is explicitly discouraged and considered invalid in our benchmark setting\.

![Refer to caption](https://arxiv.org/html/2606.17727v1/figs/error_case/3_Empty_Region_Artifacts.png)Figure 29:Example of Large Blank Region in Generated WebpageCase 4As shown in Figure[30](https://arxiv.org/html/2606.17727#A6.F30), this example illustrates a failure case where the generated webpage is significantly longer than the original one\. The excessive page length is primarily caused by repeated content blocks or redundant character sequences, resulting in unintended page expansion during HTML generation\.

![Refer to caption](https://arxiv.org/html/2606.17727v1/figs/error_case/4_long_page.png)Figure 30:Example of Excessive Page Length in Generated WebpageCase 5As shown in Figure[31](https://arxiv.org/html/2606.17727#A6.F31), this example illustrates a failure case where the generated webpage is complete in structure but shorter than the original one due to missing content \. Compared with the original image, the generated result omits part of the page content, leading to a reduced overall page length\. This issue may be attributed to the excessive length of the original webpage, which poses challenges for the model to capture and preserve all intermediate information during HTML generation\.

![Refer to caption](https://arxiv.org/html/2606.17727v1/figs/error_case/5_short_page.png)Figure 31:Example of Incomplete Content Coverage in Generated WebpageCase 6As shown in Figure[32](https://arxiv.org/html/2606.17727#A6.F32), this example illustrates a failure case where the generated webpage exhibits noticeable visual style inconsistencies compared with the original page\. While the overall page structure and content coverage are largely preserved, discrepancies can be observed in visual attributes such as color scheme, typography, spacing, and layout density across different regions of the page\. These inconsistencies indicate that the model fails to maintain a coherent global visual style during HTML generation, leading to mismatched visual appearance between different sections\.

![Refer to caption](https://arxiv.org/html/2606.17727v1/figs/error_case/6_Visual_Style_Deviation.png)Figure 32:Example of Visual Style Inconsistency in Generated WebpageCase 7As shown in Figure[33](https://arxiv.org/html/2606.17727#A6.F33), this example illustrates a failure case where the hierarchical structure of the generated webpage deviates from that of the original page\. Although most content elements are present, their organizational hierarchy is incorrectly constructed, leading to misplaced or flattened sections in the generated result\. In particular, items that should be nested under specific categories are rendered at the same level, resulting in a distorted structural layout\.

![Refer to caption](https://arxiv.org/html/2606.17727v1/figs/error_case/7_Hierarchy_Misalignment.png)Figure 33:Example of Hierarchical Structure Mismatch in Generated WebpageCase 8As shown in Figure[34](https://arxiv.org/html/2606.17727#A6.F34), this example illustrates a failure case where the information density of the generated webpage is diluted compared with the original page\. While the original image maintains compact content organization with preserved blank regions, the generated result spreads information elements across the page, leading to reduced content concentration and degraded readability\.

![Refer to caption](https://arxiv.org/html/2606.17727v1/figs/error_case/8_Information_Density_Mismatch.png)Figure 34:Example of Information Density Imbalance in Generated WebpageCase 9As shown in Figure[35](https://arxiv.org/html/2606.17727#A6.F35), this example illustrates a failure case where the global layout of the generated webpage deviates from the original design\. The original page follows a three\-column structure consisting of left, center, and right regions, whereas in the generated result, the right\-side navigation panel is missing\. This omission alters the overall page balance and structural organization, despite the main content being preserved\.

![Refer to caption](https://arxiv.org/html/2606.17727v1/figs/error_case/9_Global_Layout_Drift.png)Figure 35:Example of Global Layout Deviation in Generated Webpage
### F\.3Case analysis for W\-FFR

We further provide three illustrative examples for the W\-FFR task\. Figure[36](https://arxiv.org/html/2606.17727#A6.F36)presents a case that is regarded as successful, while Figure[37](https://arxiv.org/html/2606.17727#A6.F37),[38](https://arxiv.org/html/2606.17727#A6.F38)illustrate two failure cases\.

![Refer to caption](https://arxiv.org/html/2606.17727v1/figs/success.png)Figure 36:Success Case 1 for W\-FFR![Refer to caption](https://arxiv.org/html/2606.17727v1/figs/failed.png)Figure 37:Failed Case 1 for W\-FFR![Refer to caption](https://arxiv.org/html/2606.17727v1/figs/failed_2.png)Figure 38:Failed Case 2 for W\-FFR