Video is the best sales tool an industrial repair product has. Watching a two-part polymer get mixed, applied, and cured answers questions a spec sheet cannot. So when we built the site for IMS, an authorized Belzona distributor covering Virginia, Maryland, DC, and West Virginia, video belonged everywhere: product pages, how-to guides, a dedicated library.
The problem is what a normal embed does to a page. Drop in a standard YouTube iframe and every visitor pays for it whether they ever press play or not: the player's scripts, frames, and cookies arrive before the visitor has expressed any interest at all. Multiply that by a library of 88 videos and you are shipping a video platform to people who came to read.
There is a privacy angle too. Standard embeds can set cookies from a page view alone, which drags an otherwise clean page into tracking disclosures the client never wanted. Performance and privacy fail together here, which is a hint that they can be fixed together too.
The facade pattern
Our answer is a facade. Every player on the site renders as a thumbnail and a play button. That is the entire cost of the page: an image and a button. None of YouTube's code loads with it. No script, no iframe, no cookie.
When a visitor clicks, and only then, the real player loads, and it loads from youtube-nocookie.com, YouTube's reduced-tracking embed domain. The visitor who wants the video gets it in one click. The visitor who does not never pays for it.
Nothing about the experience feels stripped down, either. The thumbnail is the video's real poster image, the play button sits exactly where a visitor expects it, and a click starts playback the way a standard embed would. The visitor cannot tell the page was protecting them unless they open the network tab.
The pattern also matches the site's wider privacy posture. IMS runs an opt-in consent manager, where analytics and marketing tags stay off until a visitor accepts them. Embeds that pull in third-party code on page view would sit awkwardly next to that promise. A player that waits for a deliberate click fits it.
One library, not 88 scattered embeds
The second discipline is treating video as data. Every YouTube video referenced anywhere on the site is aggregated into a single catalog, deduplicated, categorized, and linked back to the product page it belongs to. The result is an 88 video library that behaves like a curated collection instead of a pile of embeds.
Curation was real work, not a query. Videos scattered across 112 product pages, industry pages, and guides had to be gathered, deduplicated, and sorted into categories a maintenance engineer would recognize:
- Product line overviews
- Industry-specific videos
- How-to-mix walkthroughs
- General how-to guides
- Application demonstrations
- Product spotlights tied to individual product pages
Because the library is data, the numbers on the page are computed rather than typed. The videos page derives its count from the deduplicated catalog itself and renders it into the page title, so the total can never silently drift from the truth as videos get added or retired.
Ranking without the weight
The usual objection to click-to-play facades is search. If the player is not really on the page until someone clicks, how do search engines know the videos are there? The answer is structured data.
The site emits VideoObject markup, the schema.org vocabulary for video, describing the content to crawlers directly. The mixing page alone carries structured data for all 31 of its mixing videos. A search engine reading the page gets a complete, machine-readable description of every video on it, without a single player loading.
This is the part most facade implementations skip. It is easy to make embeds light and invisible to crawlers at the same time. Carrying each video's identity in structured data while deferring its weight to a click is what lets the library be fast and findable at once.
That is the whole trade, and it barely qualifies as one. Visitors get pages that carry almost no third-party weight until they choose otherwise. Search engines get a richer description of the video content than a bare iframe would ever give them. The client gets an 88 video library that works as a feature of the site instead of a tax on it.
The rule underneath
Third-party code is a cost somebody always pays, and the web's default is to make every visitor pay it up front, on every page, forever. We flip the default: a visitor pays for exactly what they use, at the moment they choose to use it.
On this build the rule shows up as video facades. On others it shows up as a search index that loads only when someone opens the search, or a 3D scene that stays undownloaded until a visitor scrolls near it. Same principle every time: nothing heavy earns a place on the page until a human asks for it.
