LLM Web Animation Replication Test: From Visual Fidelity to Technical Breakdown

1. Test Background: When LLMs Meet Complex Front-End Effects

As large language models (LLMs) iterate rapidly, their applications have expanded from pure text processing to code generation, interface reproduction, and multimedia interaction design. Among these, replicating a web page’s dynamic effect is a particularly difficult task. The model must understand visual descriptions and interaction semantics, reverse-parse compressed front-end code, and rebuild consistent visual and behavioral logic in a new environment.

This test was inspired by a dynamic effect in the first screen of a well-known AI product’s website. When the page first loads, a very large digit appears. As the user scrolls, the digit breaks apart into many small particles that resemble a nebula or a spiral galaxy. Continued scrolling causes the particles to regroup into an icon or brand logo. Mouse movement over the particles also triggers local interactive feedback. The effect combines scroll listening, particle systems, Canvas rendering, and animation interpolation, which makes it a useful sample for evaluating a model’s code generation and visual understanding.

For a fair evaluation, we selected three mainstream LLMs from different vendors available at the time. We refer to them as Model A, Model B, and Model C. The goal was clear: replicate the effect as closely as possible without adding any innovation, and produce a standalone, runnable demo page.

2. Test Design: Prompt and Evaluation Criteria

2.1 Prompt Design

We gave each model a neutral instruction. It included no technical preferences or implementation hints and only described the user’s needs:

“Please check this web page (URL provided). The page has a very cool dynamic effect in the first screen and the middle section. When the mouse scrolls, particles gather and disperse. After gathering, they form specific shapes such as numbers or logos. When dispersed, they become scattered dots, similar to a starry sky. Mouse movement on the screen also produces interactive feedback. Please replicate this effect as completely as possible. You may use source code analysis, screenshots, or any other technical means. Finally, create a standalone demo page.”

The prompt deliberately did not restrict the implementation method. Models could use browser developer tools, screenshot recognition, code reverse engineering, and similar techniques. The purpose was to assess autonomous tool use and the ability to break down a problem.

2.2 Evaluation Dimensions

We scored each model’s output on four dimensions:

• Visual fidelity: How closely the final result matches the original page in shape, color, and animation timing.
• Interaction consistency: Whether the scroll-triggered logic and mouse hover feedback match the original behavior.
• Code maintainability: Whether the code has a clear structure, sensible comments, and is easy to modify.
• Engineering completeness: Whether the output is a standalone, runnable HTML file, and whether it depends on extra resources or complex configuration.

3. Test Process and Results

3.1 Model A (about 4 minutes): Basic Form, Distorted Details

Model A first opened the target page in a built-in browser and obtained some key styles through screenshots and DOM parsing. It then generated a Canvas-based particle animation. In the first version, the particle system responded to scrolling, but the assembled shape was only a blurry circle, which differed clearly from the original digit. The number of dispersed particles was far lower than in the original, and the particles lacked the starlight-like twinkling effect.

Further analysis showed that when parsing the compressed code, Model A recognized only some CSS transforms and requestAnimationFrame calls. It did not extract the core particle motion algorithm. It replaced the original non-linear elastic animation with a simplified physics model based on linear interpolation, which made the gathering and dispersing transitions abrupt. Its mouse interaction also implemented only simple particle repulsion. It did not reproduce the original effect, in which particles subtly follow mouse movement.

3.2 Model B (about 8 minutes): Complete Features, Poor Performance

Model B took a different approach. Instead of reading the source code, it repeatedly recorded the screen and analyzed pixel changes, trying to reconstruct the animation logic through visual reasoning. This worked well for macro shapes. The generated particles gathered into a clear “6.” However, Model B defined the mouse hover effect as a “particle explosion,” which differed greatly from the original page’s slight particle displacement.

Model B’s code also had serious performance problems. In a regular browser, the frame rate dropped below 20 FPS during scrolling. The code used nested loops to compute distances between particles and did not apply spatial hashing. This shows that the model understood the concept of particle count but overlooked the performance cost, a basic engineering consideration.

3.3 Model C (about 12 minutes): Close to Perfect, but Relied on Manual Fixes

Model C first tried to use local browser developer tools to fetch JavaScript files from network requests. It found that the files were obfuscated and loaded in segments. It then switched to code reverse engineering combined with visual cross-validation. It identified key frames from screenshots and wrote an initial version based on common particle animation patterns, such as sine functions for wave motion. It then compared the result frame by frame with the original page and adjusted parameters automatically.

The final version reached more than 90% visual fidelity. The gathering and dispersing effects, digit shapes, particle density, and twinkling frequency all closely matched the original. For interaction, the model implemented scroll-driven gathering and dispersing. It also listened for mousemove events so that particles smoothly followed the mouse position. One flaw remained. On the original page, particles show slight random Brownian motion when the mouse is still. Model C’s particles stayed completely static, so the effect lacked a sense of “breathing.” We fixed this manually by adding a random perturbation function.

4. Technical Challenges and Model Capability Boundaries

4.1 Challenge 1: Reverse Engineering Compressed and Obfuscated Code

Modern front-end build tools compress code, obfuscate variable names, and sometimes split animation logic into multiple modules that load asynchronously. The model must identify which code relates to the target effect and extract the core algorithm. In this test, none of the three models could read the compressed code directly. Each model rebuilt the logic through black-box observation and guesswork. This requires strong pattern recognition, so that the model can infer the underlying mathematical model from the animation’s behavior, such as the formula for updating particle positions.

4.2 Challenge 2: Dual Verification Through Visuals and Code

The most effective strategy closes a loop between screenshots and code generation. First, the model estimates the particles’ initial positions and the coordinate mapping for the target shape from screenshots. Then it generates code, runs it, captures a screenshot, compares the differences, and adjusts the parameters. Most current mainstream models accept visual input. However, turning visual feedback into code changes in a self-correction loop is still imperfect. In this test, only Model C partly implemented this loop. The other models generated code once and did not verify the result.

4.3 Challenge 3: Awareness of Performance Optimization

Particle counts often reach into the thousands. If each particle computes its distance to every other particle (O(n²) complexity), low-end devices will stutter noticeably. Well-designed front-end implementations use spatial grids or quadtrees to reduce the cost of collision detection. In this test, Model B’s error showed that LLMs often focus on functional correctness when generating code and neglect performance constraints. Model A used about 300 particles. It happened to meet performance requirements but did not achieve the intended visual effect. Models need to balance visual richness against rendering performance. LLMs generally lack this engineering intuition today.

5. In-Depth Summary: Current State and Trends in LLM Animation Replication

5.1 Capability Analysis

The test produced the following findings:

• Visual understanding: All models could identify the gathering and dispersing shapes from screenshots or video, but the level of detail varied. Model C recognized a 24×24 dot-matrix density, while Model A could only distinguish between the “gathered” and “dispersed” states.
• Code generation: All models generated runnable