DEV Community: Parth Rana

Smash Story: How I Hunted Down a 45% Idle CPU Leak in an Interactive Retro Music App

Parth Rana — Fri, 21 Aug 2026 05:05:39 +0000

This is a submission for DEV's Summer Bug Smash: Smash Stories powered by Sentry.

The Scene of the Crime

I was testing my retro music web app on my laptop when suddenly the fans started spinning up like a jet engine.

The app is an interactive experience with cassette decks, MP3 players, and canvas-based visual effects (floating dust particles, CRT scanlines, and an audio visualizer).

Visually, everything looked great. But when I opened Chrome DevTools, I saw:

CPU Usage: Stuck at 45% on an idle tab.
Memory: Steadily climbing by ~15MB every minute.
Even when I switched to another browser tab, the CPU was still maxed out.
🔗 GitHub Repository: github.com/8bitparth/english-music-nostalgia

Hunting Down the Leak

Step 1: Checking React Rerenders

At first, I thought it was a React re-render loop. I opened React DevTools Profiler, but components were only re-rendering once every 500ms for the progress bar. That accounted for less than 2% of the CPU.

Step 2: Isolating the Canvas Layers

I started turning off canvas effects one by one:

Disabled the CRT filter → CPU dropped to ~38%.
Disabled the dust particles → CPU dropped to ~25%.
Disabled the audio visualizer → CPU immediately dropped to 1.2%.

The problem was clear: Uncontrolled requestAnimationFrame loops running continuously, even when music was paused or the tab was hidden.

What Was Going Wrong?

No Tab Visibility Checks: The animation loops were firing 60 times a second even when the user switched tabs or paused the song.
Object Allocations Inside 60 FPS Loops: The particles loop was generating new color strings (rgba(...)) on every single frame, creating constant garbage collection overhead.
Stacked Animation Frames: Resizing the window or toggling modes started new requestAnimationFrame loops without cancelling the old ones.

The Fix

I refactored the canvas loops to pause whenever the tab is hidden or music is paused:

useEffect(() => {
  let animationId: number;
  let isRunning = true;

  const render = () => {
    // Only run if tab is visible and audio is actively playing
    if (!isRunning || document.hidden || !isPlaying) return;

    // Draw frame...
    animationId = requestAnimationFrame(render);
  };

  const handleVisibilityChange = () => {
    if (!document.hidden && isPlaying) {
      cancelAnimationFrame(animationId);
      animationId = requestAnimationFrame(render);
    }
  };

  document.addEventListener("visibilitychange", handleVisibilityChange);
  if (isPlaying) animationId = requestAnimationFrame(render);

  return () => {
    isRunning = false;
    cancelAnimationFrame(animationId);
    document.removeEventListener("visibilitychange", handleVisibilityChange);
  };
}, [isPlaying]);

The Results

Idle CPU: Dropped from 45% down to 0.8%.
Background Tab CPU: Completely suspended (0%).
Battery & Memory: Memory stays flat, and no more runaway fan noise.

What I Learned

Always hook canvas animations to visibilitychange.
Avoid string concatenations or object creation inside 60 FPS render loops.
Monitor performance regressions early so your users don't suffer from silent battery drain.

Best Use of Google AI

I used Google AI (Gemini) during performance profiling and optimization:

I fed the flame chart profiles and canvas animation loops into Gemini to analyze why the render thread wasn't yielding.
It pointed out that creating temporary color strings and array allocations inside a 60 FPS animation loop was causing aggressive V8 garbage collection cycles.
It recommended binding a centralized document.addEventListener("visibilitychange") handler to gracefully freeze background animation frames when switching browser tabs.

Smashed: Eliminating Ghost Audio & YouTube IFrame Lifecycle Race Conditions in a Next.js Retro Web App

Parth Rana — Fri, 21 Aug 2026 04:50:07 +0000

This is a submission for DEV's Summer Bug Smash: Clear the Lineup powered by Sentry.

Project Overview

I've been working on English Music Nostalgia, a fun side project built with Next.js (App Router), React 19, TypeScript, and Tailwind CSS.

The goal was to recreate the physical feeling of listening to music in the past. It features an interactive 90s Cassette Deck (with rotating reels), a 2000s MP3 Player (with a classic click wheel), and ambient scenes like a rainy bedroom and cyber desk.

To play the songs, I integrated the YouTube IFrame API in a global React context (PlaybackContext) so the audio stays synchronized with the retro UI controls and visualizers.

🔗 GitHub Repository: github.com/8bitparth/english-music-nostalgia

Bug Fix or Performance Improvement

The Glitch: Ghost Audio & Random Player Crashes

While testing the player, I noticed two really frustrating bugs when clicking around quickly:

Ghost Audio: When skipping songs rapidly or switching between the 90s and 2000s modes, the previous song wouldn't always stop. The new song would start playing while the previous one continued in the background, creating a messy overlap of two songs playing at once.
Sudden Crashes (TypeError: loadVideoById is not a function): If a user clicked "Play" or "Next" right after the page loaded before the YouTube IFrame API script had finished mounting, the app would crash with an unhandled TypeError.

Code

The Problem in the Old Code:

The original code assumed playerRef.current was always ready and didn't guard against async race conditions or unmounted components:

// ❌ Problem: Calling methods on playerRef before it was ready or without stopping previous stream
const playSong = (song: Song) => {
  setCurrentSong(song);
  setElapsedTime(0);
  setIsPlaying(true);

  if (playerRef.current?.loadVideoById) {
    playerRef.current.loadVideoById(song.youtubeId);
    playerRef.current.playVideo();
  }
};

window.onYouTubeIframeAPIReady = () => {
  playerRef.current = new window.YT.Player("youtube-player", {
    events: {
      onStateChange: (event: { data: number }) => {
        if (event.data === 0) {
          nextSongRef.current?.();
        }
      },
    },
  });
};

The Fix:

I refactored the playback lifecycle with a queue system and safe teardown:

// ✅ Fix: Pending action queue, explicit video stop, and mounted checks
const isPlayerReadyRef = useRef<boolean>(false);
const pendingSongRef = useRef<Song | null>(null);

const playSong = useCallback((song: Song) => {
  setCurrentSong(song);
  setElapsedTime(0);
  setIsPlaying(true);

  // If the YouTube player isn't fully ready yet, queue the song
  if (!isPlayerReadyRef.current || !playerRef.current?.loadVideoById) {
    pendingSongRef.current = song;
    return;
  }

  try {
    // Explicitly stop previous stream to eliminate ghost audio
    if (typeof playerRef.current.stopVideo === "function") {
      playerRef.current.stopVideo();
    }
    playerRef.current.loadVideoById({
      videoId: song.youtubeId,
      startSeconds: 0,
    });
  } catch (err) {
    console.error("Playback error:", err);
  }
}, []);

useEffect(() => {
  let isMounted = true;

  const initPlayer = () => {
    if (!window.YT || !window.YT.Player) return;

    playerRef.current = new window.YT.Player("youtube-player", {
      height: "1",
      width: "1",
      playerVars: { autoplay: 0, controls: 0, disablekb: 1, fs: 0 },
      events: {
        onReady: () => {
          if (!isMounted) return;
          isPlayerReadyRef.current = true;
          setIsPlayerReady(true);

          // Play queued song if user clicked play before API was ready
          if (pendingSongRef.current) {
            playSong(pendingSongRef.current);
            pendingSongRef.current = null;
          }
        },
        onStateChange: (event: { data: number }) => {
          if (!isMounted) return;
          if (event.data === 1) setIsPlaying(true);
          else if (event.data === 2) setIsPlaying(false);
          else if (event.data === 0) {
            setIsPlaying(false);
            nextSongRef.current?.();
          }
        },
      },
    });
  };

  if (window.YT && window.YT.Player) {
    initPlayer();
  } else {
    window.onYouTubeIframeAPIReady = initPlayer;
  }

  return () => {
    isMounted = false;
    if (playerRef.current?.destroy) {
      playerRef.current.destroy();
    }
  };
}, [playSong]);

My Improvements

Song Queueing (pendingSongRef): Instead of dropping user clicks or throwing errors on fast page interactions, clicks are queued and automatically played as soon as the YouTube API signals onReady.
Flushing Previous Audio: Calling stopVideo() before loadVideoById() completely stopped the overlapping ghost audio.
Cleanup & Mounting Guards: Added isMounted checks and clean player.destroy() on unmount to prevent memory leaks and zombie event listeners.

Best Use of Sentry

I used Sentry to catch and diagnose the issue:

Error Monitoring: Sentry flagged TypeError: playerRef.current.loadVideoById is not a function, pointing directly to the line in PlaybackContext.tsx.
Session Replay: Watching the session replays helped me see what users were actually doing—clicking "Next Track" multiple times within the first second of landing on the page.
Breadcrumbs: The breadcrumbs showed the exact timeline: the user's click event was firing ~300ms before the YouTube API script finished loading.

Best Use of Google AI

I used Google AI (Gemini) as a debugging partner to work through this race condition:

I shared my React 19 component structure and the Sentry error trace with Gemini.
It suggested using a ref-based pending queue (pendingSongRef) combined with an isMounted guard so that user clicks wouldn't get lost during the iframe handshake.
It also helped review the useEffect cleanup logic to make sure the interval timers and player instances wouldn't leak memory.