Frontend Development 7 min read

Debugging Vue2 Memory Leaks on an Industrial IoT Control Machine

This article walks through a real‑world Vue2 memory‑leak case on a 1 GB industrial control device, showing how DOM nodes balloon during tab switches, how Chrome DevTools can pinpoint the leaking components, and which three code changes finally eliminate the leak.

Rare Earth Juejin Tech Community
Rare Earth Juejin Tech Community
Rare Earth Juejin Tech Community
Debugging Vue2 Memory Leaks on an Industrial IoT Control Machine

Introduction

Memory leaks are a frequent topic in frontend interviews, but developers often lack practical examples. This article presents a genuine Vue2 memory‑leak case encountered while developing an industrial IoT application that runs on a 1 GB control machine.

Scenario

The UI consists of two tabs: a site group page and a single device page. Users switch between them on a low‑memory ( 1g ) industrial PC, which leads to noticeable stuttering.

Reproducing the Issue

Each time the single device tab is opened, the number of DOM nodes increases dramatically. After several switches the node count grows from a few hundred to over five thousand, as shown in the screenshots below.

Investigation with Chrome DevTools

We opened Chrome DevTools, switched to the Memory tab, and recorded an allocation timeline while repeatedly toggling the tabs. After each recording we clicked “Collect garbage” to ensure accurate data.

Start recording on the single device page.

Stop recording and examine the histogram, which shows blue (still‑alive) and gray (collected) memory.

Filter the snapshot by Vue to locate components that remain allocated after navigation.

We discovered that a component named .alter-message persisted only on the single device page and was never reclaimed, despite Vue reporting that the component was destroyed.

Root Causes Identified

Three typical leak patterns were found:

Event listeners that were not removed.

Timers (e.g., setInterval ) that were never cleared.

ECharts instances that were not disposed.

Additionally, a stray console.log(this) call on the Vue instance kept a reference to the component, preventing garbage collection.

Fix Implemented

We added the following three lines to the component:

window.removeEventListener('closeException', this.xxx)
clearInterval(this.timeInterval)
this.myChart.dispose()

After redeploying, a new memory snapshot showed no lingering Vue components and the DOM node count stabilized around 870 instead of continuously rising.

Key Takeaways

When suspecting a memory leak in a Vue page, follow these steps:

Open the Memory monitor in Chrome DevTools.

Switch between the pages (A → B → A → B) several times.

End the session on page B, then stop the monitor to capture the final snapshot.

Remember to remove global listeners, clear timers, dispose third‑party chart instances, and avoid logging whole Vue instances during debugging.

Conclusion

Only three small code changes resolved a severe memory‑leak problem, demonstrating that complex issues often have simple fixes. The debugging process itself, however, requires careful analysis and familiarity with DevTools.

frontendJavaScriptMemory LeakVueChrome DevToolsindustrial IoT
Rare Earth Juejin Tech Community
Written by

Rare Earth Juejin Tech Community

Juejin, a tech community that helps developers grow.

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.