You chose Webflow or Framer partly because the output is fast and looks designed. Then video arrives, you paste in the embed code your hosting platform gave you, and the page loads a vendor script that pulls analytics, a consent banner and two font files before the first frame paints. The Lighthouse score you were proud of drops fifteen points and it isn’t obvious why.
That’s the actual problem with video on site builders, and it’s not the one the comparison posts talk about. The platforms all work. The embeds are what cost you.
For Webflow and Framer, the constraint isn’t features — both give you an embed field, not a video pipeline, so almost any host works. The deciding variable is page weight. A plain iframe or a lightweight HLS player keeps the site fast; a full vendor player script often adds hundreds of kilobytes before the first frame. Pick on embed weight first, then on cost.
What these builders actually give you
Webflow and Framer both ship a native video component, and both have the same two limits.
They cap asset upload size, so a long video either won’t upload or has to be compressed until it looks bad. And they don’t transcode — whatever single file you upload is what every visitor downloads, at one fixed quality. Someone on hotel wifi gets the same 1080p file as someone on fibre, so one of them buffers and the other could have had better. That’s the problem adaptive bitrate streaming exists to solve, and no site builder does it for you.
For a short muted background loop, none of this matters and the native component is the right answer. For anything a visitor is meant to sit and watch, you want a real host. Exact size caps change, so check each builder’s current docs rather than trusting a number in a blog post.
The embed weight problem
This is the part worth measuring before you commit, because it’s the difference these builders’ users actually feel.
There are three ways to get video onto the page, in ascending order of cost to your performance:
A plain <iframe> pointing at the host’s player page. Lightest option that still gives you a real player. The iframe is isolated from your page, so the vendor’s scripts don’t execute in your document or block your render. This is what most infrastructure platforms hand you.
A lightweight HLS player you control. A small player library plus the HLS URL your host returns. More setup — you’re adding a custom code embed — but you decide exactly what loads. Best result if you’re comfortable with a code block in the builder.
The vendor’s full JavaScript embed. Heaviest. You get their analytics, their consent handling, their fonts and their branding, and all of it runs in your document. Sometimes that’s exactly what you want, because those analytics are the reason you bought the platform. But it should be a decision, not a default you inherited from a copy-paste.
If you switched to Webflow or Framer for the performance, don’t hand it back at the embed step. Test the page before and after — the difference is usually visible in the first paint.
Which platform fits
| Situation | Best fit | Embed |
|---|---|---|
| A few short marketing videos, no dev | Native component or Vimeo | Built-in / iframe |
| Video is a lead-gen channel | Wistia | Vendor script, on purpose |
| Larger library, cost matters | Bunny Stream or rehelios | iframe or HLS URL |
| Content behind a login or paywall | rehelios or Cloudflare Stream | HLS + signed token |
| Uploads happen from code or automation | rehelios | API, then iframe |
If you have five videos and no developer, use Vimeo or the native component and stop here. Genuinely. An infrastructure platform is more control than the situation calls for, and the setup time isn’t repaid at that scale. This is the case where we’re not the answer and it’s a common one — see the Vimeo comparison if you want the detail.
If video is doing marketing work, Wistia’s player script earns its weight, because the heatmaps and lead capture are the product. Accept the kilobytes knowingly. See the Wistia comparison.
If the library is big enough that cost registers, you want per-GB billing and a clean iframe. Bunny Stream and rehelios both fit; both bill per gigabyte with free encoding.
If the content is gated — a members area, a paid resource, a client portal — you need playback that can be revoked, which the native component can’t do at all. Signed tokens or a domain allowlist are the mechanisms; how signed playback tokens actually work covers both.
If videos arrive from a pipeline rather than a person — generated, imported from a client’s Drive, published on a schedule — that’s the case an API earns its place. npx @rehelios/cli import <url> --wait --json returns an embed URL you can drop straight into the builder, no dashboard step. More at /cli.
The Framer-specific bit
Framer’s code components make the lightweight-player route noticeably easier than it is in Webflow. If you’re comfortable writing a small component, you can wrap an HLS player once, take an ID as a prop, and reuse it across the site with essentially no per-video weight. That’s the best-performing setup available on either builder, and it’s a couple of hours of work.
Webflow’s equivalent is an embed element with a custom code block, which works the same way but is fiddlier to reuse across many pages.
What to actually do
Start by asking whether a person or a program uploads the video. If it’s a person, and there are few enough videos that they’d notice if one broke, use a hosted embed and spend your effort elsewhere.
If it’s a program, or the library is large, or access has to be controlled, use an infrastructure platform and embed with an iframe rather than a vendor script. Then measure the page before and after — that’s the number that tells you whether you kept what you came to these builders for.
Broader context on picking by why you’re leaving your current setup is in best video hosting for your website. If there’s a developer on the project and you want the API-level criteria, that’s best video hosting for developers. Our rates are on the pricing page and at /pricing.md.