Why Rend is fast
When a video is slow to start, it's rarely raw server speed. It's the round trips before the first frame. Rend cuts those trips down with generated HLS and a server-controlled Tigris origin path that keeps private storage URLs out of the browser.
The bare-metal edge code remains available for a future regional fleet, but it is not the active production path today. Current playback works without edge warmers or edge cache fanout.
Few trips, all short
Every hop a request makes across the internet adds time before playback can begin. Rend cuts the path down. The first bytes are already sitting at an edge node near your viewer, so there are fewer trips to make and each one is shorter.
Tigris-backed HLS by default
Rend Cloud serves generated HLS directly from Tigris-backed origin today. The bare-metal edge path stays available in the repo, but it is dormant in production until regional coverage makes it worthwhile.
No edge dependency
Uploads, readiness, watch pages and embeds do not require active edge nodes. Playback stays behind Rend-controlled URLs without exposing private object-store links.
Ready before anyone presses play
Rend builds HLS artifacts during media processing so the player can start from real media as soon as the asset reaches hls_ready.
The number that matters
Time to first frame is the gap between pressing play and seeing the picture. It is what viewers notice, and it is hardest on a cold request, the first time a video is opened.
A lot of speed claims are measured on the easy case, a video that has been watched many times and cached everywhere. The honest figure is the cold start, when nothing is primed and the bytes have the furthest to travel.
That is the case Rend is built for. Rend generates the HLS artifacts during processing and serves them through Rend-controlled URLs, so the first request can return real media while private object-store URLs stay out of the browser.
- Cold start
- The first request for a video nobody has watched yet, with nothing primed in any cache.
- HLS ready
- The state where Rend-generated HLS manifests and segments are available for playback from origin.
- Dormant edge node
- A bare-metal playback cache service kept in the repo for future reactivation, not required for current production playback.
Measure it yourself
Upload a video, press play from wherever you are, and time the first frame. That is the only benchmark worth trusting.
Frequently asked questions
A few questions we get about how Rend keeps playback fast.
- Why does video usually feel slow to start?
- It is rarely the server working hard. The wait comes from the round trips across the internet before the first frame can show. The further the first bytes have to travel, the longer playback takes to begin.
- What is active today?
- When you upload, Rend generates the HLS master playlist, rendition playlists, and media segments during processing. Production playback serves those artifacts from Tigris-backed origin through Rend-controlled URLs.
- Do you run on serverless functions?
- Current production playback does not depend on edge functions or active edge nodes; it uses Rend API-origin streaming from Tigris. The optional bare-metal edge service remains available behind REND_PLAYBACK_MODE=edge.
- What is time to first frame?
- It is the gap between pressing play and seeing the first frame. It is the part viewers actually feel, and the part Rend is built to keep short, especially the first time a video is requested.
- Can I check the speed myself?
- Yes, and we would rather you did. Upload a video, press play from wherever you are, and time the first frame. That is the only number that counts.