Purpose-Built Templates

ZU2B Blueprints

Business in a Box

  • Purpose-built launch kits for local service businesses — website, copy, prompts, SEO, and more.
  • Local Launch Kits →

Website Widgets

  • Working features you install once and own outright — no plugin, no subscription.
  • Chat Widget — Coming Soon

Reference

ZU2B Pulse™

See what visitors experience before they leave — paste any public URL and get a plain-English performance report in seconds.

Scan Your URL Free

Why a Sound Effect Works When You Test It, But Never for Real Visitors

Field Note #136
🔬 Generalized 🟡 Intermediate ⏱ 30 Minutes ✓ Observation from Experience
You add a little audio cue to your site — a chime on page load, a sound when a score reveals. You test it yourself and it plays perfectly. You publish it, and it turns out real visitors never hear it at all. Nothing crashes, no error shows up anywhere. It just silently doesn’t happen.

What’s actually happening
Every modern browser enforces an autoplay policy: audio can only start playing as the direct result of a user gesture — a click, a tap, a keypress. It cannot be triggered by a page load, a setTimeout, or anything that isn’t happening inside a real click/tap handler. This isn’t a bug to work around; it’s an intentional, unbypassable restriction.
Here’s the part that makes it deceptive to test: Chrome (and other browsers) track something called a Media Engagement Index — a per-site score based on how much you’ve previously interacted with audio/video on that domain. If you’re the developer who’s been on your own site dozens of times, your own browser may have quietly whitelisted it, letting audio autoplay for you specifically even though the code is doing something the policy is supposed to block. A brand-new visitor’s browser has no such history, and gets blocked every time.

How to tell the difference
Test in an Incognito/Private window, or in a browser profile that’s never visited the site before. If the sound plays for you in your normal browser but not in a fresh private window, that’s the Media Engagement Index masking the real behavior — not evidence the code is working.

The fix
Attach the sound-playing function to an actual click/tap/keypress event listener, rather than calling it directly on page load. If you want something that feels like “plays when the page opens,” the closest honest equivalent is firing it on the first interaction anywhere on the page (first click, tap, or keypress), removing the listener after it fires once so it doesn’t repeat.
One more wrinkle: if that first interaction happens to be a link or button that navigates away immediately, the sound can get cut off mid-play before it finishes. A small delay (100–250ms) on that specific navigation gives the sound a moment to register before the page unloads.

How to avoid it next time
Never test autoplay-dependent behavior in your own regular browser and call it done — always verify in a private window or a browser that’s never touched the domain before. Your own browser is the one visitor whose behavior you can’t trust as representative.

Tagged in :

More from the field