A self-hosted video may play perfectly on office Wi-Fi and pause every few seconds on mobile data. That does not prove the phone is at fault or that the hosting plan is too small. The encoded bitrate, MP4 structure, server range support and page’s competing requests all influence playback.
Use one controlled sequence to determine where the bottleneck sits.
Compare direct playback with the complete page
Open the MP4 URL directly on the affected mobile connection, then play it inside the WordPress page. If direct playback is smooth but the page version buffers, other assets, JavaScript or player settings are competing.
If both buffer, inspect the file and its delivery. Repeat with a known small MP4 from the same server. This comparison avoids blaming a large source file and the server at the same time.
Record the device, browser, connection type and approximate time where playback pauses.
Measure bitrate, dimensions and codec
File size alone is incomplete. A short file can require a high sustained bitrate, while a longer well-encoded file may stream reliably.
Use ffprobe on a file you control:
ffprobe -v error
-show_entries format=duration,size,bit_rate
-show_entries stream=codec_name,width,height,r_frame_rate
-of default=noprint_wrappers=1 video.mp4
Compare bitrate with realistic mobile throughput, leaving headroom for variation and other page traffic. Check that the codec and profile are supported by target devices. H.264 in MP4 remains a practical compatibility baseline.
Do not transcode the only master. Work from a backup and create a named web derivative.
Check fast-start placement
An MP4 can store essential metadata at the end of the file. The browser may need a large download before it knows how to begin playback.
Create a fast-start copy without changing the visual stream when possible:
ffmpeg -i input.mp4 -c copy -movflags +faststart output-faststart.mp4
Verify the new file rather than overwriting the live one. If it starts sooner but later buffers at the same points, bitrate or delivery capacity still needs attention.
Verify byte-range responses
Browsers use range requests to fetch portions of media. Check public response headers and then request a small byte range:
curl -I https://example.com/uploads/video.mp4
curl -r 0-1023 -I https://example.com/uploads/video.mp4
The range request should normally produce 206 Partial Content with a valid Content-Range. Exact headers vary, but a server, CDN or security layer that ignores ranges can make seeking and recovery inefficient.
Use these commands only for media you are authorised to test. Inspect both CDN and origin behaviour if they differ.
Inspect HTML loading choices
For a user-controlled content video, preload="metadata" is usually a sensible starting point:
<video controls preload="metadata" poster="/uploads/tutorial-poster.webp">
<source src="/uploads/tutorial.mp4" type="video/mp4">
<p><a href="/uploads/tutorial.mp4">Download the video</a>.</p>
</video>
preload="auto" may transfer substantial media before a click and compete with other videos on the same page. preload="none" saves more initially but can make playback feel less immediate. Compare them in the real context.
Do not autoplay instructional video with sound. Provide controls and captions when spoken content is necessary to understand it.
Look for server and CDN constraints
Review response time, cache status, transfer rate and error logs during a controlled playback. A CDN miss, rate limit, hotlink rule or overloaded origin can interrupt delivery.
Make sure the MP4 is cached as media and not passed through PHP. WordPress access-control plugins sometimes proxy protected videos through an application request, which can increase load and disable efficient ranges.
One test from a fast monitoring location does not represent the affected mobile region. Compare public delivery from relevant geography where possible.
Decide whether progressive MP4 is still suitable
A short background or demonstration can work as one progressive MP4. Long lessons, multiple quality levels or a geographically distributed audience may need adaptive streaming through a video platform.
Adaptive streaming lets the player switch quality as bandwidth changes. Building and operating it on ordinary shared hosting is usually not the simplest repair.
Verify after the smallest change
Retest the same connection after changing one factor: fast-start structure, lower bitrate, range delivery or preload behaviour. Confirm startup time, number of stalls, seeking, captions and visual quality.
If buffering remains inconsistent, request a performance assessment with the public page, MP4 duration, file size, affected device and test time. Do not send server passwords initially. A proper diagnosis should distinguish encoding, markup and delivery before recommending new hosting or a streaming platform.