Why your proxy bill spikes on video heavy pages
Every month I get the same message from someone running a scraping job through our farm. “My bandwidth usage tripled overnight, did something break?” Nine times out of ten, nothing broke. They pointed a scraper or a browser automation script at a page with video on it, and the SIM did exactly what it was supposed to do: pull down every byte the page asked for.
This isn’t a mobile proxy bug. It’s how video actually moves over a network, and it hits mobile data differently than it hits a home broadband connection you don’t think twice about. Here’s what’s actually happening.
Video isn’t one download, it’s a stream of them
A static webpage is basically a one time cost. The browser fetches the HTML, the CSS, a handful of images and scripts, and then it’s done until you click something else. Video doesn’t work like that.
Almost every video heavy site today uses adaptive bitrate streaming, either HLS or DASH. Instead of sending you one video file, the server chops the video into small segments, usually a few seconds each, and the player requests them one after another in a loop for as long as the video is on screen or buffering ahead. Each segment is its own HTTP request. Each one counts as data through your proxy.
So a page that “just has a video on it” isn’t a single request. It’s a continuous drip of segment requests that keeps going as long as the tab is open and the video element is active, whether or not anyone is actually watching it play.
Autoplay is the part nobody accounts for
The bigger issue for anyone running headless browsers is autoplay. A huge number of video heavy pages, product listings with hover previews, social feeds, news sites with embedded clips, are built to start pulling video the moment the element scrolls into view or the page loads, no click required.
When you’re scraping or automating, your session is often doing exactly the things that trigger this: loading the full page, scrolling to trigger lazy loaded content, waiting for the DOM to settle. Every one of those actions can wake up an autoplay video you never intended to watch. Multiply that by however many browser profiles you’re running in parallel, and you’ve got a dozen or more sessions each quietly streaming video segments in the background while your script is trying to grab a price or a headline.
Preload settings make this worse. A <video> tag with preload="auto" starts fetching data as soon as it’s in the DOM, before autoplay even kicks in and sometimes before the video is visible at all. It’s a page author’s choice, not something you control from the proxy side, and it’s on by default on a lot of e-commerce and media sites.
Headless browsers load everything unless you tell them not to
This is the part that actually costs people money. Puppeteer, Playwright, and Selenium all default to acting like a real browser, which means they fetch every resource a page requests: images, fonts, video segments, ad creatives, all of it. Nothing is stripped out automatically. If your automation script doesn’t explicitly intercept and block certain request types, it’s downloading the full experience every single time, video included.
Video ads compound this. A lot of video heavy pages run pre-roll or mid-roll ads that are entirely separate video streams layered on top of the content you actually wanted. Your script never asked for the ad, but the page did, and the browser dutifully fetches it.
Why this hits harder on mobile data specifically
Here’s the part that’s specific to mobile proxies and not proxies in general. The SIMs we run, real SingTel, M1, and StarHub SIMs sitting in physical modems, are on actual mobile data plans. That data has a real cost to the carrier and to us the moment it crosses the SIM, regardless of what kind of traffic it is. A video segment and an HTML file cost the same per byte to move, but video is just a lot more bytes, over and over, for as long as the session stays open.
On a fixed line connection this is easy to ignore because bandwidth feels abundant. On mobile data it’s metered in a way that’s much closer to what you’d notice on your own phone plan if you left a video autoplaying on the train. The mechanism is identical, just running inside a script instead of your hand.
This is why “mobile proxy bandwidth cost” and “video heavy page” show up together so often. It’s not that mobile proxies are inefficient. It’s that video traffic is heavy by nature, and mobile data is where that weight actually gets felt on the bill.
What actually reduces the spend
None of this means video heavy pages are impossible to work with. It means you have to be deliberate about what your session is allowed to fetch.
Intercept requests by resource type. Both Puppeteer and Playwright let you hook into the request pipeline and abort anything typed as media, and often image too if you don’t need visuals. This is the single biggest lever. If the browser never requests the segment, it never gets billed.
Block known video domains and file patterns. Segment requests usually hit predictable hosts and extensions, things like .m3u8, .ts, .mp4, or CDN subdomains dedicated to video delivery. Blocking these at the request level stops the stream before it starts, even on pages where you can’t disable the player through the DOM.
Turn off autoplay where you can control it. Some sites respect a muted or autoplay policy set at the browser context level. It’s not universal, but on pages that check for it, disabling autoplay in your browser context config stops the video from firing before your scraper even needs to interact with the page.
Watch data usage per session, not just per account. Because our modems are physical hardware with real SIMs behind them, we can see data draw per port in something close to real time. If you’re running your own farm or watching your usage dashboard, the same principle applies: catch the one session that’s pulling ten times the data of the others and kill it before it runs for hours unattended.
Cap concurrency on video heavy targets. Running twenty parallel sessions against a page that autoplays video means twenty parallel video streams. Dropping concurrency on those specific targets, even if you run high concurrency everywhere else, keeps the spike contained to the pages that actually need it.
None of this is exotic. It’s request filtering and paying attention to what your automation is actually asking the page to do. The bill spikes when video is set to load by default and nothing in your stack tells it not to. Turn that default off, and the spike goes away.
If you’re running scraping or browser automation on real Singapore mobile SIMs and want to talk through how your sessions are configured, get in touch through Singapore Mobile Proxy.
Get new guides and videos first — join the Telegram channel.