Put six films on a page with six embedded players and you have shipped six third party scripts, six iframes, six network waterfalls, and a page that stutters on a mid range phone. The visitor has watched nothing yet.
On the film pages we build, the page holds no player until somebody presses play.
What is actually on the page
What looks like a player is not one. It is:
- an image, which is our own poster frame, and
- a button, which is our own play control.
That is it. An image and a button. No iframe, no player script, no third party connection, nothing initialised.
What happens on click
When somebody presses play, the player is created at that moment. It goes inside a dialog element sized to that film’s exact aspect ratio, it plays, and when the dialog closes the player is destroyed rather than hidden.
Destroyed matters. A hidden iframe is still a running iframe. It keeps its connections, keeps its timers, and keeps its memory. If a visitor opens four films in a session, hiding gives you four live players competing for the same phone.
What it saves
The cost is a small amount of code: create the dialog, size it, mount the player, tear it down. Perhaps sixty lines, written once.
The savings show up on every page that lists more than one film:
- The largest contentful paint is an image you control and can serve in a modern format, not something a third party decides to render.
- Nothing third party runs until a person opts in, so there is no tracking before consent and no layout shift from an embed resizing itself.
- The page works with scripting unavailable up to the moment somebody wants video, which is the moment it needs to work.
When you can skip it
If the page is a single video and watching it is why people arrive, we embed it. The pattern here is for lists: grids, archives, portfolios, anywhere the visitor will watch at most one of the things on screen.
We load the capability when somebody asks for it. A poster and a button is a cheap promise that it exists.