Optimizing Rich Media Transmission in Customer Service IM with Web Workers and Object URLs

Rich media (images, audio, video, files) is widely used in instant‑messaging (IM) for customer service. Large files cause high memory consumption and long upload times, which blocks the front‑end UI and reduces agent efficiency.

Background : The one‑stop service platform for customer‑service agents in the DeWu ecosystem needs to send rich media quickly. The traditional flow uploads the file to a CDN, returns the CDN URL, and then the front‑end renders the media only after the upload succeeds.

Challenges : Uploading big videos (e.g., >70 MB) can take 2–3 seconds for the first frame, and longer under poor network conditions. Rendering the whole file or a base64 data URL in the chat window can crash the browser because the data URL size may exceed the original file size.

Solution Overview :

1. Use FileReader to obtain a data URL (initial attempt)

The initial approach read the file with FileReader.readAsDataURL and tried to render the video directly from the data URL:

export function getFileInfo(file: File): Promise
{
  return new Promise((resolve, reject) => {
    try {
      const reader = new FileReader();
      reader.readAsDataURL(file);
      reader.onload = (event: ProgressEvent
) => {
        resolve(event);
      };
    } catch (e) {
      reject(e);
    }
  });
}

This caused severe performance issues because the base64 string inflates the memory footprint.

2. Switch to URL.createObjectURL

Instead of a data URL, the file is turned into a temporary object URL, which the browser can stream without loading the entire content into memory:

if (/*******/) {
    // ...
    //. blob as preview video URL
    state.previewVideoSrc = URL.createObjectURL(file);
    state.previewVideo = true;
    state.cachePreviewVideoFile = file;
    nextTick(() => {
      focus();
    });
  } else {
    // ...
  }

This dramatically reduced the time to display the video preview.

3. Offload file processing to a Web Worker

Reading file metadata on the main thread still blocks UI. A Web Worker runs the heavy file‑reading logic in a background thread and posts the result back:

// Worker task
export function subWork() {
  self.onmessage = ({ data: { file } }) => {
    try {
      // read file information
      // ...
      self.postMessage({ fileReader: **** });
    } catch (e) {
      self.postMessage({ fileReader: undefined });
    }
  };
}

// Create and communicate with the worker
export const createWorker = (subWorker, file, resolve, reject) => {
  const worker = new Worker(URL.createObjectURL(new Blob([`(${subWorker.toString()})()`])));
  worker.postMessage({ file });
  worker.onmessage = ({ data: { fileReader } }) => {
    resolve(fileReader);
    worker.terminate();
  };
  worker.onmessageerror = () => worker.terminate();
};

// Helper to use the worker from the main thread
export const getFileInfoFromSubWorker = files => {
  return new Promise((resolve, reject) => {
    createWorker(subWork, files, resolve, reject);
  });
};

After obtaining the video Blob URL, the main thread can quickly render the preview while the worker continues processing metadata (duration, dimensions, first‑frame thumbnail).

Result : Combining URL.createObjectURL with a Web Worker enables “instant‑send” of rich media—agents see a placeholder immediately, and the upload progress is shown without blocking other operations.

Conclusion : The described technique solves the performance bottleneck of rich‑media transmission in IM, improves agent efficiency, and provides a smoother user experience.

Knowledge Expansion :

• URL.createObjectURL creates a temporary URL that streams the file directly, using far less memory than a base64 data URL. • FileReader.readAsDataURL returns a large base64 string and is asynchronous, which can cause higher memory usage. • Web Workers allow heavy file processing to run off the main thread, preventing UI blockage.