Why Huge Images Crash Your H5 App and How to Fix It with Chunked Lazy Loading

1. Background

On a regular workday, a bug‑feedback group sent a video showing that our H5 app entered an endless refresh loop while loading an image in a certain document, severely affecting user experience and prompting an investigation.

2. Problem Analysis

Testing the document in a browser revealed no infinite refresh, but the page loaded slowly and was very laggy. No console errors appeared, and other documents loaded normally, indicating the issue was specific to this document.

1. Performance Analysis

Using Safari’s timeline tool on a MacBook Pro M3 (16 GB RAM) showed an average CPU usage of 89.7 % with most of the main thread time spent on rendering, suggesting the bottleneck lay in the browser’s rendering process.

2. Root Cause

The document’s rich‑text configuration contained an image with an enormous resolution of 4505 px × 60615 px . Compared with other documents, this image was vastly larger, leading to a browser performance bottleneck and the endless refresh behavior.

Google Chrome: the browser reports a crash.

Safari: the browser reports repeated page errors.

DingTalk embedded browser: the page continuously refreshes in our reproduction scenario.

Testing different browsers can help understand how each handles such errors.

3. How a 200‑Million‑Pixel Image Is Rendered

The browser rendering pipeline consists of several stages:

DOM Construction: HTML is parsed into a DOM tree.

Style Calculation: CSS is processed into a styleSheets (or CSSOM tree).

Layout: Using the DOM tree and style information, the browser computes positions and sizes, creating a layout tree.

Layering: The layout tree is split into multiple layers for independent rendering.

Painting: Layers are broken into drawing commands.

Chunking: Layers are further divided into tiles to improve efficiency.

Rasterization: Vector graphics are converted into pixel bitmaps.

Compositing: Layers and tiles are combined using OpenGL to produce the final screen image.

1. First Paint

When the browser parses an <img> tag, it creates a DOM node and starts loading the image. HTML parsing and style calculation are synchronous, while image loading is asynchronous and low‑priority, so the browser initially reserves a placeholder size.

2. Painting

During painting, the rendering thread issues draw commands. In our case, drawing the massive image took about 78 ms, far longer than other commands (0.1 µs–2 ms).

3. Chunking

After the image loads, the compositing thread splits it into thousands of small chunks for rendering.

4. Rasterization

Each chunk is processed and scaled using interpolation algorithms (e.g., nearest‑neighbor, bilinear).

The raster data is uploaded to GPU texture memory for display.

Decoding a 200‑million‑pixel image demands heavy CPU/GPU resources and can cause severe lag or crashes on weaker devices.

5. Image Load Completion

When the image finishes loading, the page re‑flows. Because the <img> element lacked explicit width/height, the browser initially displayed the image at its original size for a few frames before resizing it to fit the 100 % width of its container.

4. Solutions

The root cause is the browser directly rendering an ultra‑large image, exhausting resources. The solutions focus on preventing such images from reaching the rendering stage.

1. Pre‑Upload Validation

Add size checks during image upload.

a. Frontend Validation

Using wangEditor5, customize the upload callback to read the file with FileReader and create an Image object to verify dimensions before uploading:

editorConfig.MENU_CONF['uploadImage'] = {
  async customUpload(file, insertFn) {
    try {
      const reader = new FileReader();
      const fileData = await new Promise((resolve, reject) => {
        reader.onload = e => resolve(e.target.result);
        reader.onerror = err => reject(err);
        reader.readAsDataURL(file);
      });
      const img = new Image();
      const imgLoad = await new Promise((resolve, reject) => {
        img.onload = () => {
          const { width, height } = img;
          if (width > 2000 || height > 2000) {
            reject(new Error('Image exceeds 2000x2000'));
          } else {
            resolve();
          }
        };
        img.onerror = err => reject(err);
        img.src = fileData;
      });
      await new Promise(r => setTimeout(r, 1000));
      insertFn(fileData, file.name, fileData);
      console.log('Upload succeeded');
    } catch (error) {
      console.error('Upload failed', error);
    }
  }
};
// Apply editorConfig to wangEditor instance

Reference: https://www.wangeditor.com/v5/menu-config.html#upload-image

b. Backend Validation

Validate image dimensions on the server after upload. This offloads processing from the browser but adds server load and may increase upload latency.

2. Online Image Processing with Alibaba Cloud OSS

Use the x-oss-process parameter to resize images on the fly, e.g., x-oss-process=image/resize, ensuring images are optimized before rendering.

3. Chunked Lazy Loading

Divide a huge image into many small chunks and load only those visible in the viewport.

Image Chunking: Split the image into rectangular chunks (called chunks ).

On‑Demand Loading: Load each chunk lazily with loading="lazy" as the user scrolls.

Implementation Steps

Obtain the original image width and height.

Define a chunk size (e.g., 500 px) and calculate the number of horizontal and vertical chunks.

Crop the image into chunks using OSS x-oss-process=image/crop with appropriate x, y, w, and h parameters.

Render each chunk with an <img> tag positioned absolutely, using loading="lazy".

Because the browser cannot obtain image dimensions before rendering, OSS processing is required to retrieve image info via x-oss-process=image/info, which returns JSON such as:

{
  "FileSize": {"value": "21839"},
  "Format": {"value": "jpg"},
  "ImageHeight": {"value": "267"},
  "ImageWidth": {"value": "400"}
}

OSS also supports custom cropping with x-oss-process=image/crop, where parameters w, h, x, and y define width, height, and the top‑left corner of the crop area.

import { useEffect, useState } from "react";
import axios from "axios";

function App() {
  const [imageInfo, setImageInfo] = useState({ width: 0, height: 0 });
  const [chunks, setChunks] = useState([]);
  const CHUNK_SIZE = 500;

  useEffect(() => {
    async function fetchImageInfo() {
      const res = (await axios.get(`xxxx.png?x-oss-process=image/info`))?.data;
      const info = { width: res.ImageWidth.value, height: res.ImageHeight.value };
      setImageInfo(info);
      const hChunks = Math.ceil(info.width / CHUNK_SIZE);
      const vChunks = Math.ceil(info.height / CHUNK_SIZE);
      const newChunks = [];
      for (let y = 0; y < vChunks; y++) {
        for (let x = 0; x < hChunks; x++) {
          newChunks.push({ x, y });
        }
      }
      setChunks(newChunks);
    }
    fetchImageInfo();
  }, []);

  return (
    <div className="app" style={{
      position: "relative",
      width: imageInfo.width || "100%",
      height: imageInfo.height || "100%",
      margin: "0 auto",
      overflow: "auto"
    }}>
      {chunks.map(({ x, y }) => {
        const actualWidth = Math.min(CHUNK_SIZE, imageInfo.width - x * CHUNK_SIZE);
        const actualHeight = Math.min(CHUNK_SIZE, imageInfo.height - y * CHUNK_SIZE);
        return (
          <img
            key={`${x}-${y}`}
            loading="lazy"
            src={`xxxx.png?x-oss-process=image/crop,x_${x * CHUNK_SIZE},y_${y * CHUNK_SIZE},w_${actualWidth},h_${actualHeight}`}
            style={{
              position: "absolute",
              left: x * CHUNK_SIZE,
              top: y * CHUNK_SIZE,
              width: actualWidth,
              height: actualHeight,
              border: "1px solid red"
            }}
            alt={`chunk-${x}-${y}`}
          />
        );
      })}
    </div>
  );
}
export default App;

This chunked lazy‑loading approach dramatically improves performance by rendering only the visible portions of a massive image, reducing initial load time and CPU/GPU load, especially on mobile devices.

5. Summary

The issue stemmed from the browser’s rendering mechanism struggling with an ultra‑large image that exceeded device capabilities, causing excessive computation during loading, layout, and rasterization, ultimately leading to crashes or infinite refresh loops. Analyzing the rendering pipeline highlighted the image loading, re‑flow, and rasterization stages as the main bottlenecks.

To prevent similar problems, developers should proactively validate image dimensions, employ server‑side checks, use cloud‑based image processing (e.g., Alibaba Cloud OSS), and adopt chunked lazy‑loading strategies. Regular performance profiling with browser tools and early detection of resource‑heavy assets are essential for delivering smooth user experiences across devices.