DEV Community: Hui

The unglamorous reality of maintaining a streaming extension as a solo dev

Hui — Thu, 09 Jul 2026 06:47:31 +0000

Tuesday, 8:15 AM. I was waiting for the kettle to boil when the email notification popped up on my phone.

Chrome Web Store Developer Support: Action Required for StreamEnhancer.

My stomach did that familiar little drop. It wasn’t a malware flag, and it wasn’t a copyright strike. It was a policy rejection under the "Interfering with third-party website functionality" clause.

Building StreamEnhancer—the extension that lets you fine-tune playback speed on YouTube, Netflix, Disney+, Prime, and Max—was the fun part. Figuring out how to inject UI overlays into wildly different video players and keeping the audio pitch intact at 2.5x speed? That was a great puzzle.

But nobody warns you about the administrative and emotional overhead of keeping a media-manipulation extension alive in the wild.

Here is what actually takes up my time these days.

The CWS Review Tug-of-War

When you build an extension that touches major streaming platforms, you are automatically flagged for deeper manual review by the Chrome Web Store team. And honestly? I get it. The web is full of malicious extensions trying to intercept video streams or inject ads into Netflix.

But StreamEnhancer doesn't touch DRM. It doesn't decrypt Widevine. It literally just finds the HTML5 <video> element and tweaks the playbackRate property.

Explaining this to a reviewer who is processing hundreds of extensions a day is a diplomatic exercise, not a technical one.

When I got that Tuesday morning rejection, the reviewer cited a policy about modifying the core experience of a third-party service. I couldn't just reply with "but it's just the standard HTML5 API." I had to build a case.

What actually works with CWS reviewers:

A short, unlisted YouTube video (or Loom) showing the extension in action.

A screen recording of the Chrome DevTools Network tab, proving no encrypted media streams are being intercepted or modified.

A written breakdown mapping your extension's features directly to standard, documented browser APIs.

I spent two hours recording a video, pausing to explicitly point out that the video source URLs were untouched, and writing a polite, overly detailed explanation of how HTMLMediaElement.playbackRate is a native browser feature, not a hack.

It took four days to get approved. Four days where my existing users were stuck on the old version, and new users couldn't install it. You just have to sit with that anxiety and keep checking your email.

The "Is Netflix Broken or Is It You?" Support Queue

The other massive time sink is user support. And with streaming extensions, support is deeply psychological.

Streaming platforms update their DOM structures and player wrappers constantly. Disney+ is particularly notorious for tweaking their web player on random Thursday nights. When they change the class names on their player controls, my injected speed buttons might misalign or disappear entirely.

When that happens, my inbox fills up.

But here’s the thing: users don't email me saying, "Hey, the DOM structure on the Disney+ web player changed, causing your overlay to fail."

They email me saying:

"Did Netflix ban my account?"
"Why is my TV freezing?"
"Your extension broke my streaming, I want a refund."

When you're a solo dev, you aren't just fixing code. You are de-escalating panic. People pay $15 to $25 a month for these streaming services. They feel entitled to a flawless experience. If my $3 extension accidentally covers up the "Skip Intro" button because of a z-index miscalculation, they are going to be annoyed.

I had to learn to separate my ego from their frustration.

Early on, I would get defensive. I’d write back long explanations about how Netflix changed their code, not me. It didn't help. It just made them angrier.

Now, my support process is entirely about speed and validation.

Acknowledge immediately. "You're right, the player updated and the controls are hidden. I'm working on the fix right now."
Provide a temporary workaround. "In the meantime, you can use the keyboard shortcuts (Shift + >) to change speed without the UI."
Ship the fix and follow up.

I also set up a very specific FAQ page. The very first question is: "Is my streaming service broken, or is it StreamEnhancer?" I included a quick guide on how to disable the extension to test if the native player works. It cut my "my TV is broken" support tickets by about 60%.

The reality of the solo dev maintenance loop

Look, building the thing is maybe 20% of the job.

The other 80% is monitoring the Chrome Web Store policy updates, keeping an eye on streaming platform changelogs (or just waiting for users to tell me they changed something), and managing the expectations of people who just want to watch The Bear at 1.25x speed without the audio sounding like chipmunks.

It’s unglamorous. It’s a lot of email writing and policy reading. But when I get a random five-star review from a med student who says StreamEnhancer saved them hundreds of hours of lecture watching?

Yeah. I'll happily deal with the CWS review queue for that.

Stop relying on `timeupdate`: Building battery-efficient video analytics in the browser

Hui — Thu, 09 Jul 2026 06:45:20 +0000

Sunday mornings are for pour-over coffee and catching up on tech courses. A few months ago, I was working through an advanced Rust module on one of the big e-learning platforms. I paused, scrubbed back to re-watch a tricky section on lifetimes, and then skipped ahead.

When I checked my dashboard later, the platform told me I was 85% done with the course.

I wasn't. I was maybe 40% done. The platform's progress tracking was essentially just looking at the highest timestamp I'd reached, completely ignoring the scrubbing and re-watching. It was garbage data.

That specific frustration is what pushed me to build CourseSpeed. I wanted actual, granular learning analytics and better playback speed controls across Udemy, Coursera, and the rest. But building a browser extension that tracks video engagement accurately without turning the user's laptop into a space heater taught me a hard lesson about how we traditionally handle video events in the DOM.

If you're building anything that interacts with HTML5 video—whether it's a custom player, an analytics script, or a browser extension—you need to stop using the timeupdate event.

Here is what you should be doing instead.

The `timeupdate` trap

If you open the dev tools on almost any video player and attach a listener to timeupdate, you'll see it firing constantly.

// The old, bad way
videoElement.addEventListener('timeupdate', (e) => {
    logAnalytics(e.target.currentTime);
});

The problem? The HTML5 spec doesn't dictate exactly how often timeupdate should fire. It just says it should fire when the playback position changes. In practice, browsers fire it anywhere from 4 to 60 times a second.

If you're just updating a UI progress bar, that's fine. But if you're doing what I do in CourseSpeed—calculating watch-time density, tracking playback speed changes, and syncing local analytics to a backend—that unpredictable firing rate is a nightmare. You end up doing heavy computations on the main thread at random intervals, causing micro-stutters in the video playback and draining battery life on mobile.

Enter `requestVideoFrameCallback`

Chrome 83 introduced requestVideoFrameCallback (often abbreviated as rVFC), and it's now supported in all major Chromium-based browsers and Safari. Firefox is still dragging its feet on it, but for extension development and modern web apps, it's a game changer.

Instead of relying on a time-based event, rVFC hooks directly into the browser's rendering pipeline. It fires exactly once per rendered video frame.

const video = document.querySelector('video');

function trackFrame(now, metadata) {
    // metadata.mediaTime gives you the exact presentation timestamp
    // metadata.presentedFrames tells you how many frames have been shown

    const currentTime = metadata.mediaTime;

    // Do your analytics math here
    calculateEngagement(currentTime);

    // Queue the next frame
    video.requestVideoFrameCallback(trackFrame);
}

// Kick it off
video.requestVideoFrameCallback(trackFrame);

Why is this better?

It's battery efficient. It aligns with the display's refresh rate and the video's actual frame rate. If the video is 30fps, it fires 30 times a second. If the user pauses, it stops firing completely. No wasted cycles.
You get metadata. The callback passes a metadata object that includes mediaTime, presentedFrames, and expectedDisplayTime. This lets you detect if the video is actually dropping frames or buffering, which is incredible for diagnosing playback quality issues.

When I migrated CourseSpeed's core tracking loop from timeupdate to requestVideoFrameCallback, CPU usage during a 2-hour course dropped by about 14% on my M1 MacBook. That's not a marginal gain. That's the difference between a user keeping your extension enabled and uninstalling it because it's "slowing down their browser."

Finding the video tag in the wild

Of course, getting the analytics loop right is only half the battle. The other half is actually finding the <video> element.

E-learning platforms don't just hand you a clean <video src="..."> tag. They bury it. Udemy uses nested iframes. Coursera wraps things in complex React trees. Skillshare sometimes throws shadow DOMs into the mix.

If you're writing a content script, document.querySelector('video') is going to fail you 90% of the time.

I ended up writing a recursive walker that pierces same-origin iframes and open shadow roots. It's a bit brute-force, but it works reliably across the platforms I support.

function findVideoElements(root = document, results = []) {
    // Check current root
    const videos = root.querySelectorAll('video');
    videos.forEach(v => results.push(v));

    // Pierce open shadow DOMs
    const shadowHosts = root.querySelectorAll('*');
    shadowHosts.forEach(el => {
        if (el.shadowRoot) {
            findVideoElements(el.shadowRoot, results);
        }
    });

    // Pierce same-origin iframes
    const iframes = root.querySelectorAll('iframe');
    iframes.forEach(iframe => {
        try {
            // This will throw if cross-origin, which is fine, we just catch it
            const iframeDoc = iframe.contentDocument || iframe.contentWindow.document;
            findVideoElements(iframeDoc, results);
        } catch (e) {
            // Cross-origin iframe. 
            // If the platform uses postMessage for player control, 
            // you have to hook into that instead.
        }
    });

    return results;
}

You don't want to run this on every DOM mutation. Run it once on page load, and then set up a highly specific MutationObserver that only watches for the insertion of new iframe or video nodes.

A quick note on Firefox

Since Firefox doesn't support requestVideoFrameCallback yet, you need a fallback. Don't just revert to timeupdate blindly.

Use requestAnimationFrame combined with checking video.currentTime. It's not as perfectly synced to the video decoder as rVFC, but it ties your logic to the browser's paint cycle rather than the video element's internal clock, which is still vastly superior to the random firing of timeupdate.

function fallbackLoop() {
    if (!video.paused) {
        calculateEngagement(video.currentTime);
        requestAnimationFrame(fallbackLoop);
    }
}

Building tools that sit on top of other people's web apps is always a bit of a cat-and-mouse game. The platforms change their DOM structures, they update their player APIs, and things break. But by relying on low-level browser APIs like requestVideoFrameCallback instead of high-level DOM events, you anchor your code to the rendering engine itself.

It makes your analytics smoother, your extension lighter, and your Sunday morning coffee breaks a lot less frustrating.

4.2 million hours of video later: What StreamEnhancer telemetry taught me about human impatience

Hui — Thu, 09 Jul 2026 06:32:15 +0000

1.14x.

That was the exact median playback speed across all StreamEnhancer users last month.

I was sitting in a coffee shop on a Tuesday morning, running the monthly aggregation script against our anonymized telemetry database. I honestly expected the number to be higher. If you spend any time on tech Twitter or Reddit, you’d think everyone is watching tutorials at 2.5x speed. The internet loves to brag about media speedrunning. "I watch lectures at 3x, I'm basically a cyborg."

But the aggregate data told a completely different story. The reality of how people actually consume media is a lot more nuanced, and honestly, a lot more interesting than the hustle-culture speedrun narrative suggests.

When you build a tool like StreamEnhancer, you start with assumptions. I assumed people just wanted to go fast. The data proved me wrong. People don't just want to go fast; they want to go exactly as fast as their brain can process without feeling stressed.

Here is what 4.2 million hours of streaming telemetry actually looks like.

The Platform Personality Split

The 1.14x median is basically a useless number on its own because it mashes together completely different behaviors. When I broke the data down by platform, the variance was wild. It turns out, the platform dictates the psychology.

Netflix and Max users are "Set and Forgetters."
The median speed on Netflix is 1.25x. But more importantly, the average number of speed changes per session is just 0.8. People find a comfortable cruising speed for a narrative show, set it, and leave it alone. They are optimizing for a steady state.

YouTube users are "Active Pilots."
The median speed on YouTube is actually lower (1.10x), but the average number of speed changes per video is 4.6.

YouTube is a chaotic mix of content. A single 20-minute video might have a slow-talking intro, a dense technical explanation, a 60-second sponsor read, and a rapid-fire conclusion. Users are constantly riding the speed slider like a clutch pedal. They drop to 1.0x when the creator is showing complex code on screen, bump it to 2.0x for the sponsor pitch, and settle at 1.25x for the talking-head segments.

I thought I was building a tool for speedrunners. I actually built a pacing tool for people trying to manage their cognitive load.

The 0.05x Obsession

This was the biggest surprise in the dataset, and it completely changed my product roadmap.

When I first shipped StreamEnhancer, the speed controls jumped in 0.25x increments. 1.0 → 1.25 → 1.5. Standard stuff. That's how the native HTML5 <video> element usually handles it if you just hook into playbackRate.

In version 2.4, I added fine-grained control, allowing 0.05x steps. I figured maybe 10% of power users would care.

Instead, 71% of all speed changes became micro-adjustments.

People weren't jumping from 1.0 to 1.5. They were nudging.
1.10 → 1.15 → 1.20 → 1.15.

They were hunting for the exact threshold where the video felt fast, but the audio didn't start sounding artificial. Even with the preservesPitch property updates in recent Chrome versions (which does a great job preventing the "chipmunk" effect), pushing past 1.3x on certain audio tracks introduces weird phasing artifacts.

Users are highly sensitive to this. They will spend 15 seconds nudging the speed up and down by 0.05x just to find the "sweet spot" for a specific video's audio mix.

Here’s what a typical telemetry payload looks like for a YouTube session:

{
  "event": "speed_change",
  "platform": "youtube",
  "session_id_hash": "a8f9c2e...",
  "previous_rate": 1.10,
  "new_rate": 1.15,
  "delta": 0.05,
  "session_total_changes": 4,
  "time_in_video_sec": 342
}

Because of this data, I completely ripped out the "preset speed" buttons in the UI overlay. Presets are useless to an Active Pilot. I replaced them with a drag-slider that has subtle haptic-style snapping at 1.0x and 1.25x, but allows free-floating micro-adjustments everywhere else. Usage satisfaction scores jumped 22% in the next update.

The Rewind Paradox

Here's a weird correlation I found while digging through the event logs.

I track (anonymously) when the playback speed is increased, and when the user triggers a "rewind 10 seconds" event via our custom hotkeys.

If a user is watching at 1.5x or higher, the likelihood of them hitting "rewind 10s" within the next 30 seconds is 340% higher than if they are watching at 1.0x.

Obvious, right? You go too fast, you miss a detail, you rewind.

But here's the kicker that made me stop and think: they rarely drop the speed back down after rewinding.

They miss a concept at 1.5x. They rewind 10 seconds. They watch it again at 1.5x. If they miss it again, they rewind again at 1.5x.

Human attention is a funny thing. We would rather rewind three times at 1.5x speed (taking 20 seconds total) than just watch it once at 1.0x speed (taking 10 seconds). The math doesn't make sense for actual time saved, but it makes perfect sense psychologically.

The perception of moving fast matters more than the actual time saved. Dropping the speed to 1.0x feels like a penalty. It feels like you're "losing" the speedrun. Rewinding at 1.5x feels like you're just buffering your brain while maintaining your momentum.

What the numbers actually mean

Looking at analytics for a browser extension is different from looking at SaaS dashboard metrics. You aren't tracking churn or MRR. You're tracking human impatience, attention spans, and the subtle ways people try to hack their own biology to consume more information.

The data from StreamEnhancer taught me that when you build consumer tools, you shouldn't build for the extreme edge cases (the 3.0x speedrunners). You should build for the messy, nuanced middle. The people who just want to watch a Netflix show at 1.25x so they can go to sleep 12 minutes earlier, or the developer who wants to nudge a tutorial to 1.15x so it matches their reading speed.

Next time you watch a video and feel the urge to speed it up, pay attention to the exact number you choose. You're probably not just trying to save time. You're just trying to sync the internet to your own internal clock.

Bypassing the 2x speed limit on stubborn video players (and why `playbackRate` lies to you)

Hui — Thu, 09 Jul 2026 06:29:40 +0000

I was riding the train back from a conference last month, trying to finish a Coursera module on my laptop. The instructor was speaking at roughly the speed of a melting glacier. I hit the 2x button in the custom UI. It wasn't enough.

I opened dev tools, typed document.querySelector('video').playbackRate = 3.5, and watched the playback instantly snap back to 2.0.

If you've ever written a browser extension, a userscript, or just tried to hack your way through a mandatory compliance training video, you've probably hit this exact wall. The HTML5 video API makes speed control look trivial. But modern learning platforms don't just use raw <video> tags. They wrap them in heavy state managers.

Here is what's actually happening under the hood, and the DOM trick you need to bypass it.

The Synthetic Event Trap

Platforms like Udemy, LinkedIn Learning, and Coursera usually build their players in React or Vue. When you manually set video.playbackRate = 3.5 in the console, the browser does its job and fires a ratechange event.

The framework's synthetic event system catches that event, checks its internal state, realizes 3.5 is outside the bounds of their custom UI slider (which usually maxes out at 2.0), and forcefully clamps it back down by re-assigning the property.

You aren't fighting the browser. You're fighting the framework's reconciliation loop.

The Fix: Prototype Descriptor Hijacking

You can't just stop the ratechange event propagation reliably without breaking the player's internal analytics or UI updates. Instead, you need to intercept the property setter itself.

By overriding the property descriptor on the HTMLMediaElement prototype, you can silently ignore the framework's attempts to clamp the speed.

const targetSpeed = 3.5;
const proto = HTMLMediaElement.prototype;

// Grab the browser's native descriptor
const originalDescriptor = Object.getOwnPropertyDescriptor(proto, 'playbackRate');

Object.defineProperty(proto, 'playbackRate', {
    get() {
        return originalDescriptor.get.call(this);
    },
    set(value) {
        // If the platform tries to clamp it to their UI max (usually <= 2.5), 
        // and we've flagged this video for override, just ignore the set.
        if (value <= 2.5 && this.__speedOverrideActive) {
            return; 
        }
        originalDescriptor.set.call(this, value);
    },
    configurable: true
});

// Apply the override to the specific video instance
const video = document.querySelector('video');
video.__speedOverrideActive = true;

// Now set the speed. The framework's subsequent attempts to reset it to 2.0 will fail silently.
video.playbackRate = targetSpeed;

A quick heads up if you're building an extension: a lot of these platforms render their video player inside an iframe. document.querySelector('video') will return null on the top-level window. You'll need to target the iframe's contentDocument first, assuming it's not blocked by cross-origin restrictions.

Don't forget the Chipmunk effect

There's a secondary issue when you push past 2.0x or 2.5x.

To save CPU cycles, some platforms explicitly disable audio pitch correction when the playback rate changes. In Chrome 130+, the standard property is preservesPitch, but older WebKit/Blink implementations still rely on vendor prefixes. If your instructor suddenly sounds like an angry chipmunk at 3x speed, force the pitch preservation:

video.preservesPitch = true;
video.webkitPreservesPitch = true; // Safari/older Chrome
video.mozPreservesPitch = true;    // Firefox

It’s a tiny detail, but it makes the difference between a usable 3x speed and an unlistenable one.

Tracking the "Rewind Density"

Getting the video to play at high speeds is only half the battle if you actually want to learn something.

When I was wiring up the core logic for CourseSpeed, I realized that just forcing a 3x playback rate was useless if the user had to constantly pause or rewind. I needed to know if the speed was actually sustainable for the content being watched.

I ended up implementing a metric I call "rewind density."

Instead of just logging the current playback speed, the analytics hook tracks the delta between high-speed playback and rewind events (specifically, dropping the speed back to 1.0x or hitting the left-arrow key to jump back 10 seconds).

If you're building your own learning tools or analytics dashboards, don't just track average watch speed. Track how often the user is forced to abandon that speed. A video watched at 2.5x with zero rewinds is a great fit. A video watched at 2.5x with a rewind every 40 seconds means the content is too dense, and the user is just creating an illusion of productivity.

The DOM hacks get the video to play fast. But paying attention to how the user interacts with the player is what actually makes the speed useful.

The 1x1 Pixel That Broke My Streaming Extension

Hui — Thu, 09 Jul 2026 04:17:02 +0000

Saturday morning, 9 AM. I was at the kitchen island, making a pour-over coffee and testing StreamEnhancer on my MacBook while chopping onions for a frittata.

I had the extension running, playing an episode of The Mandalorian on Disney+ at 1.5x speed. Everything was smooth. The audio pitch correction was holding up, the custom UI overlay was tracking the progress bar perfectly. Feeling confident, I hit my hotkey to bump the speed to 2.0x.

Fourteen minutes later, the video froze. The audio cut out with a harsh digital stutter, and a generic "Something went wrong" error replaced the player.

I figured it was a memory leak. StreamEnhancer injects a fairly heavy UI overlay and listens to a lot of media events to sync the speed indicators across YouTube, Netflix, Prime, Max, and Disney+. I restarted Chrome 128, loaded the page, and tried again.

Exact same thing. 14 minutes at 2.0x, then death.

I dropped the speed back to 1.5x. The episode finished without a hitch.

The naive assumption

My initial code for applying the playback speed was, frankly, lazy. When you're building a cross-platform tool, you want to write the least amount of platform-specific code possible.

// The "please just work" approach
const videos = document.querySelectorAll('video');
videos.forEach(v => {
    v.playbackRate = targetSpeed;
});

I assumed a streaming page would only have one active <video> element. Or at least, only one that actually mattered. YouTube behaves exactly like this. Netflix is a bit more complex with its canvas rendering for certain UI elements, but the core media tag is straightforward.

But Disney+ and Max? They are a different beast.

I opened DevTools, cleared the console, and just searched the DOM for <video>.

There were three of them.

The main player. videoWidth was 1920.
A hidden element used for ad-tracking and analytics beacons.
A 1x1 pixel video, positioned absolutely off-screen, with no audio.

The accidental discovery

I paused the main movie. The 1x1 pixel video kept playing. I muted the tab. It kept playing.

I dug into the network tab and watched the requests. That tiny, invisible video tag was streaming a continuous, low-bitrate media chunk. It turns out, this is a DRM heartbeat.

When you stream protected content, the browser uses Encrypted Media Extensions (EME) to talk to a Content Decryption Module (CDM) like Widevine or PlayReady. The platform needs to verify the session is still valid and the environment hasn't been tampered with. Instead of relying purely on standard XHR/Fetch network requests—which can be easily intercepted, mocked, or blocked by ad-blockers—some platforms tie the license renewal to the playback lifecycle of a secondary, heavily monitored media element.

The heartbeat video plays silently in the background. When it hits a certain timestamp, it triggers a license renewal.

Here is where my extension broke everything.

When I forced playbackRate = 2.0 on every video tag in the DOM, I sped up the DRM heartbeat.

The heartbeat video reached its renewal checkpoint twice as fast. The CDM fired a license renewal request to the server. But the server-side logic expects these renewals at specific real-world intervals. When it started receiving them at 2x speed, the platform's sanity check flagged the client as anomalous. It assumed the environment was tampered with, or the license simply burned through its validity window too fast.

Result: Session revoked. Black screen.

Isolating the primary media

I didn't want to mess with the DRM heartbeat. I just wanted to speed up the movie. I needed a reliable way to identify the actual primary video tag across five different streaming platforms, ignoring the ghosts in the DOM.

Checking videoWidth > 0 wasn't enough. Ad trackers can have dimensions. Checking if the element is visible in the viewport wasn't enough either, because picture-in-picture modes and minimized players change the bounding client rect.

I ended up writing a scoring function for StreamEnhancer that runs every time the URL changes or the player initializes.

function findPrimaryMediaElement() {
    const candidates = Array.from(document.querySelectorAll('video'));
    let primary = null;
    let maxScore = -Infinity;

    for (const video of candidates) {
        let score = 0;

        // 1. Dimension check (The most reliable filter)
        // Heartbeats and trackers are usually tiny
        if (video.videoWidth >= 800 && video.videoHeight >= 400) {
            score += 50; 
        } else if (video.videoWidth < 100) {
            score -= 100; // Heavily penalize the 1x1 pixels
        }

        // 2. Rendered area check
        const rect = video.getBoundingClientRect();
        const area = rect.width * rect.height;
        score += (area / 10000); 

        // 3. DOM hierarchy check
        // Primary players are usually nested deep in specific player containers
        // while trackers are often injected at the root body level
        let depth = 0;
        let node = video;
        while (node.parentElement) {
            depth++;
            node = node.parentElement;
        }
        score += depth;

        if (score > maxScore) {
            maxScore = score;
            primary = video;
        }
    }

    return primary;
}

It’s not perfect. Every time Netflix or Prime updates their player architecture, I have to tweak the weights. Prime Video, for instance, sometimes wraps their main video in a shadow DOM during initial load before hydrating it into the main document, which required adding a MutationObserver just to catch the element when it finally surfaces.

But the scoring system solved the DRM crash. By only applying playbackRate to the highest-scoring element, the 1x1 pixel heartbeat continues to play at 1.0x, the server stays happy, and the user gets to watch their show at 2.5x without getting kicked out.

The web is a battlefield

Before building StreamEnhancer, I thought of the DOM as a document. A tree of elements that represent what the user sees.

Working across Netflix, Max, Disney+, and the others taught me that on modern streaming sites, the DOM is a battlefield. There are decoys, trackers, heartbeats, and hidden state machines all fighting for resources and verifying each other.

When you build tools that interact with these platforms, you aren't just manipulating a video tag. You're stepping into a highly paranoid ecosystem. Sometimes, the most important part of your code isn't the feature you're building, but the invisible things you've learned to leave alone.

I thought building a video speed controller would take a weekend. The analytics nearly broke me.

Hui — Thu, 09 Jul 2026 03:10:27 +0000

It was 2 AM on a Tuesday, and I was staring at my CourseSpeed dashboard looking at a graph that claimed I had just finished a 14-hour AWS certification course in 47 minutes.

I hadn't. I was just testing the 16x speed toggle. But my analytics engine thought I was a god.

When I started building CourseSpeed—a browser extension to inject custom playback speeds and track learning analytics across Udemy, Coursera, LinkedIn Learning, and Skillshare—I thought the hard part would be the UI. It wasn't. Injecting a floating control panel and setting document.querySelector('video').playbackRate = 2.5 takes about ten lines of JavaScript.

The actual nightmare was the learning analytics. Specifically, accurately tracking effective watch time versus wall-clock time across wildly different Single Page Applications (SPAs).

The naive approach that burned me

My first pass at the analytics tracker was straight out of MDN. I listened to the standard HTML5 video events.

// The approach that worked perfectly in my head
const video = document.querySelector('video');

video.addEventListener('ratechange', (e) => {
  sendAnalytics({ type: 'speed_change', rate: e.target.playbackRate });
});

video.addEventListener('timeupdate', () => {
  logWatchTime(video.currentTime, video.playbackRate);
});

This worked flawlessly on Udemy. Then I opened LinkedIn Learning. The dashboard flatlined. Then I tried Coursera. The time spent was wildly inaccurate, drifting by minutes over an hour.

I spent three days debugging this, tearing my hair out over console logs.

Here is what I missed: modern learning platforms don't just drop a raw <video> tag on the page and leave it alone. They wrap it in custom players, throttle events to save CPU, and dynamically destroy and recreate the DOM node when you skip chapters or when the SPA router transitions.

My event listeners were getting orphaned. Or worse, they were firing with stale data because the platform's custom wrapper was dispatching synthetic timeupdate events that didn't reflect the underlying HTML5 video element's true state when the playback rate was manipulated.

Stop trusting the DOM events

I had to rip out the event listeners. If I wanted reliable analytics, I needed to observe the DOM for element swaps and poll the video state myself.

I built a VideoTracker class. Instead of waiting for the platform to tell me the video changed, I used a MutationObserver to watch the specific player wrapper containers.

const observer = new MutationObserver((mutations) => {
  for (const mutation of mutations) {
    if (mutation.type === 'childList') {
      const newVideo = mutation.target.querySelector('video');
      if (newVideo && newVideo !== this.currentVideo) {
        this.attachToVideo(newVideo);
      }
    }
  }
});

// We observe the highest stable container, not the whole document body
const playerRoot = document.querySelector('[data-player-root]') || document.body;
observer.observe(playerRoot, { childList: true, subtree: true });

This solved the orphaned listener problem. When Coursera swapped the video node during a module transition, my tracker caught it, detached the old state, and latched onto the new <video> element within milliseconds.

But then I hit the background tab wall.

The background tab throttling trap

Here’s the real kicker. When you switch tabs to read documentation while a course plays in the background, Chrome (specifically around version 120 and later) aggressively throttles setInterval and setTimeout in background tabs to save battery and CPU.

My analytics pings were getting delayed. The browser would batch them up and send massive, inaccurate chunks of "watch time" when the tab regained focus. If a user left a 2x speed video running in the background for an hour, my extension might only log 15 minutes of actual progress because the setInterval ticking my internal clock was being put to sleep.

I tried switching the internal clock to requestAnimationFrame. That paused entirely in background tabs.

The fix was moving the ticking clock to a Web Worker. Web Workers run on a separate thread and aren't subjected to the same aggressive throttling as the main thread's timers.

The architecture ended up looking like this:

The Web Worker ticks every 1000ms and posts a message to the main thread.
The main thread receives the tick, reads video.currentTime and video.playbackRate directly from the DOM.
The main thread calculates the delta and updates the local analytics state.

// worker.js
let intervalId;

self.onmessage = function(e) {
  if (e.data === 'start') {
    intervalId = setInterval(() => {
      self.postMessage('tick');
    }, 1000);
  } else if (e.data === 'stop') {
    clearInterval(intervalId);
  }
};

It feels like overkill for a browser extension, but it completely eliminated the background-tab drift. The analytics dashboard finally matched reality. A 14-hour course watched at 2x speed now correctly logged as 7 hours of effective learning time, regardless of whether the user was actively staring at the tab or reading MDN docs in another window.

Building tools that live on top of other people's SPAs means you are constantly at the mercy of their DOM updates and browser performance optimizations. You can't just assume the standard APIs will behave the way the spec says they should in a vacuum. You have to build defensively, assume the DOM will mutate out from under you, and never trust a setInterval in a background tab.