A video studio sitting second in Google for the Persian query "advertising teaser" serves a home page that makes 144 network requests and moves 18,918 KB of data. Sixteen megabytes of that is the page's own video. Our home page, measured the same way in the same session, came in at 10 requests and 286 KB.
Then the part we did not expect. The LCP on that eighteen-megabyte page measured 360 milliseconds. The heavy video had not damaged Google's speed metric at all.

So what does the video actually cost
Your visitor's money. LCP measures the largest visible element, and that element is normally an image or a headline rather than a video loading behind it. A video can therefore consume sixteen megabytes quietly while all three Core Web Vitals stay green.
On a mobile connection that figure is roughly sixteen megabytes out of the data allowance of somebody who arrived to find out what you do. At ten thousand mobile visits a month you are spending 160 GB of your audience's money so that an autoplaying teaser can run, and most of them never hear the audio.
That is not a speed argument. It is a courtesy argument, and it was missing from every page in those results.
Thirteen pages, measured
We opened thirteen URLs in headless Chrome with an empty cache and recorded requests, bytes and LCP for each. The results did not line up neatly, which is what makes them worth publishing:
- the teaser studio with a self-hosted hero video: 144 requests, 18,918 KB, LCP 360 ms
- a plain blog page in the same industry: 10 requests, 488 KB, LCP 3,236 ms
- an agency with an image gallery: 79 requests, 2,246 KB, 14 requests to other domains
- rgb.ir's home page: 10 requests, 286 KB, LCP 248 ms, CLS zero
Read the second row again. A 488 KB page produced an LCP nine times worse than the eighteen-megabyte one. Weight and speed are not the same quantity, and this small table is the proof: LCP is decided by loading order, not by the sum of the bytes.
Why embedding is usually right, and where it is not
Across the eleven pages we read in full we counted 48 video tags and 28 embeds from the local video platform. The dominant pattern in that market is not self-hosting; it is embedding. On weight alone that is the correct call, because the embedded player fetches nothing until somebody presses play.
Three costs come with it, and they should be accepted deliberately. The request goes to a domain whose speed you do not control. Your teaser lives on someone else's platform, and so do its view statistics. And on the day that service is unreachable, your page has an empty rectangle in it.
The middle path we use on projects is unremarkable. A poster image with declared dimensions sits in the layout, and the video loads only after a click. The visitor still sees the opening frame, the page fetches no video bytes at all, and CLS stays at zero because the space was reserved in advance.
Where a teaser earns its place
On a campaign landing page it works, because the visitor came from an ad and wants to understand in thirty seconds what you sell. On a product page it works, if the product is something that has to be seen moving. The place it almost never works is the home page of a services company: somebody who searched for "advertising teaser" wants portfolio and pricing, not a corporate introduction film.
One limit we should state plainly. We make motion graphics and we still think that if your budget covers only one of the two, fix the page first. An excellent teaser on a page that takes four seconds to appear is a teaser nobody watches.
Settle four things before you commission it
Decide the output quality and the aspect ratio at the start, because re-rendering always costs something. Set a realistic duration; sixty seconds is almost always too long for a landing page. State whether a clean version without text is part of the delivery, since that version makes the same teaser reusable for another language or another campaign. And ask what the final file size will be, exactly as you would ask about dimensions.
That last one gets asked least and matters most. The gap between a 2 MB teaser and a 16 MB teaser is usually compression, not anything the eye can see.
Put it in the brief from the beginning and nobody has to recompress the file afterwards. A design team that knows the target weight before it starts rendering will hit it without an argument about quality.
How long should a teaser be?
For a landing page, fifteen to thirty seconds. For social, usually shorter, because the first three seconds decide everything. Longer is only justified when the product genuinely has stages that are worth watching.
What separates a teaser from motion graphics?
A teaser is a purpose; motion graphics is a technique. A teaser can be live action, animated, or a mix. What makes it a teaser is that it exists to introduce or announce, and that it is short.
Does video hurt SEO?
The video itself does not. Our measurement showed a page carrying sixteen megabytes of video with a perfectly good LCP. Harm arrives when the video is inserted without declared dimensions and shifts the layout, or when it autoplays and takes bandwidth from elements that matter more.
Self-host or embed?
For a short teaser on a landing page, self-hosting with a poster and click-to-load gives you more control. For long video or a large simultaneous audience, a streaming service is the right answer. Duration and concurrency decide it, not preference.
If the teaser is meant to be part of a selling page rather than a file on its own, that decision belongs to the moment the page is built. Building a page where video has a job is not the same as attaching an embed to a page that already exists, and it leaves far less speed work to do afterwards.
Method: thirteen URLs opened on 16 August 2026 in headless Chrome, 1366 by 900 viewport, empty cache, from a server in Helsinki; requests, response bytes, LCP and CLS were recorded in that session. Two URLs did not complete their load event within thirty seconds and carry no LCP figure. This server is not in Iran, so the timings are not what an Iranian visitor experiences; byte and request counts are location-independent. Tag counting was done on the served HTML of eleven pages.
Metric definitions from the LCP page on web.dev, video loading behaviour from its guide to the video tag.
Comments & Questions
Have a question about this article? Ask, we'll answer.
No comments yet; be the first.