Last issue was about the spam quietly training you to ignore your own enquiries. This one is about a file quietly training your mobile visitors to leave: the video someone dropped straight into the Media Library.

Nobody uploads a 200MB video on purpose. What happens is that a phone shoots 4K at a huge bitrate, someone drags the file into WordPress, WordPress says yes without comment, and now every mobile visitor to that page is asked to download it. On a phone, on real-world data, it stalls. Your Largest Contentful Paint goes with it, and so does the impression that this is a serious business.

The reason it stays broken is that the obvious fix isn't available to most people. Optimising video properly means ffmpeg, and on managed hosting — Kinsta, WP Engine, most of the good ones — there's no shell access and no ffmpeg to call. So the options collapse to "pay a transcoding service per minute forever" or "leave it".

What "web-ready" actually means

Worth knowing regardless of how you get there. A video that behaves well on the web is:

H.264, capped at 1080p. Nobody needs 4K in a 700px-wide content column.
CRF 23-ish. Quality-targeted compression rather than a fixed bitrate — visually indistinguishable at a fraction of the size.
AAC audio — or no audio track at all, if it's a background loop.
Faststart. This is the one people miss. It moves the file's index to the front so playback can begin while the rest downloads. Without it, the browser waits for the whole file. Same bytes, completely different experience.

A typical raw phone clip drops by 80–95% under those settings with no visible difference at web sizes.

This week's fix: audit, then transcode in the browser

Start with the audit — go and look at what's actually in your Media Library, sorted by size. On most sites there are two or three videos doing all the damage, and they're usually on the pages you care about most.

For the fixing part I built Nomad Video Optimizer — £39, one-time, no licence keys, use it on as many sites as you like.

The trick is where the work happens: the editor's own browser, via ffmpeg compiled to WebAssembly. That means it works on locked-down managed hosting with no shell access at all, and the raw file never leaves the machine it's on — no third-party transcoding service, no per-minute fees, nothing uploaded until the optimised file is finished.

Open Media → Optimize Video and drop in a raw MP4 or MOV.
It transcodes in-browser with a live progress bar.
The optimised faststart MP4 — plus an optional VP9 WebM rendition for modern browsers — saves straight into your Media Library.
A "Web-ready" column in the Media Library flags every other video that's oversized, high-bitrate or missing faststart, with the exact reasons and a one-click fix link.

Requirements: WordPress 6.0+, a modern desktop browser, and an editor with the usual upload_files capability. First run downloads a ~31MB encoding engine into the browser and reuses it after that. The in-browser encoder has a memory ceiling around 2GB, so it's built for normal clips rather than hour-long recordings — the readme covers a desktop ffmpeg fallback for bulk jobs. 14-day no-questions refund.

The part that matters long-term

The audit column is honestly the bigger win. One-off cleanups don't hold, because the next editor will drag in the next phone clip next month. A permanent "web-ready / not web-ready" flag in the Media Library means the problem gets caught the day it's created, by the person who created it. [FILL: one line on a real before/after — e.g. a client homepage video that went from X MB to Y MB and what it did to LCP.]

This issue lives in the archive, organised by topic. And the plugins page shows the repeatable workflows alongside the service work.

How we can work together

Reply with the page that has your heaviest video on it and I'll tell you what it's actually costing you on mobile.