You're In The Right Place If…
- Lighthouse Best Practices is capped below 100 and the only failing audit is "Issues were logged in the Issues panel in Chrome DevTools"
- The Issues panel (DevTools → three-dot menu → More tools → Issues) shows "Cookie" issues from a domain you do not own — play.hubspotvideo.com, youtube.com, vimeo.com, doubleclick.net
- The flagged request is a video player or preloader that loads automatically on page load, before anyone clicks anything
- You have checked every setting in HubSpot / YouTube and there is no option to change how their cookies are set
Why You Cannot Fix This With A Setting
Cookies are set by the server that serves the iframe — via Set-Cookie response headers from play.hubspotvideo.com or youtube.com. Your page merely embeds that iframe; nothing in your HTML, your CMS, or your HubSpot portal settings can rewrite another company's response headers. Until the provider ships SameSite=None; Secure partitioned cookies (CHIPS), Chrome will keep logging the issue every time their player loads.
The only lever you control is WHEN that player loads. Lighthouse audits the initial page load. If the player is not requested during load — because it waits for a click — its cookies never enter the picture. Bonus: a HubSpot or YouTube player is 500 KB–1.2 MB of JavaScript. Deferring it behind a click routinely lifts mobile Performance scores by 5–15 points on video-heavy pages.
The Fix: A Click-To-Play Facade (works For Any Provider)
A facade is a lightweight stand-in: a poster image, a play button, and a data attribute holding the real embed URL. A few lines of JavaScript swap in the real iframe on first click, with autoplay enabled so the visitor still gets one-click playback. The experience is identical for users — the difference is that robots (and Lighthouse) never trigger the load.
Here is the HubSpot video version. Replace the iframe HubSpot gave you with this markup. For the poster, take a screenshot of the video's first frame (or download the thumbnail from HubSpot's video manager) and host it on your own domain — that keeps the facade 100% first-party.
IMPORTANT — this is a template, not paste-as-is code. Before it will work you must replace four placeholder values: (1) PORTAL_ID and VIDEO_ID in data-embed — copy both numbers from the src of your existing HubSpot iframe; (2) /images/video-poster.jpg — the path to the poster image you host on your own site; (3) the alt text — describe your actual video; (4) the width/height attributes if your video is not 16:9. If you paste it unchanged, the play button will load a broken player.
If your video lives in a HUBSPOT CMS MODULE (a {% video_player %} tag in a custom module rather than a pasted iframe): after you edit the module's HTML or add a poster field to fields.json, go back into the PAGE EDITOR, click the module, and RE-SELECT THE VIDEO in its video field — module edits can leave the field empty, and an empty player_id makes the {% if %} render nothing at all. Blank section where the video should be? That is almost always why. Re-select the video, upload the poster image, then update the page.
<!-- BEFORE (sets the cookie on page load): -->
<iframe src="https://play.hubspotvideo.com/v/PORTAL_ID/id/VIDEO_ID" width="640" height="360" allowfullscreen></iframe>
<!-- AFTER — the facade. ⚠️ REPLACE BEFORE PASTING: PORTAL_ID + VIDEO_ID
(from your existing HubSpot iframe src), the poster image path, and the alt text. -->
<div class="video-facade"
data-embed="https://play.hubspotvideo.com/v/PORTAL_ID/id/VIDEO_ID?autoplay=1"
style="position:relative;aspect-ratio:16/9;max-width:640px;cursor:pointer;background:#000;border-radius:12px;overflow:hidden">
<img src="/images/video-poster.jpg" alt="Video: what the video is about" loading="lazy"
style="position:absolute;inset:0;width:100%;height:100%;object-fit:cover" width="640" height="360" />
<button type="button" aria-label="Play video"
style="position:absolute;top:50%;left:50%;transform:translate(-50%,-50%);width:68px;height:48px;border:0;border-radius:10px;background:rgba(0,0,0,.72);cursor:pointer">
<svg viewBox="0 0 24 24" width="26" height="26" fill="#fff" aria-hidden="true" style="display:block;margin:auto"><path d="M8 5v14l11-7z"/></svg>
</button>
</div>
<script>
document.querySelectorAll('.video-facade').forEach(function (el) {
el.addEventListener('click', function () {
var f = document.createElement('iframe');
f.src = el.dataset.embed;
f.allow = 'autoplay; fullscreen; picture-in-picture';
f.setAttribute('allowfullscreen', '');
f.title = el.querySelector('img').alt || 'Video player';
f.style.cssText = 'position:absolute;inset:0;width:100%;height:100%;border:0';
el.textContent = '';
el.appendChild(f);
el.style.cursor = 'default';
}, { once: true });
});
</script> The YouTube Version (plus The Nocookie Domain)
Identical pattern, two YouTube-specific upgrades. First, YouTube publishes every video's thumbnail on i.ytimg.com — a cookieless static CDN — so you do not even need to host a poster yourself. Second, when the iframe does load, point it at youtube-nocookie.com (YouTube's official privacy-enhanced domain) instead of youtube.com, so even after the click the player sets no advertising cookies until playback starts.
The same facade script from above handles both providers — the only thing that changes is the markup. Again, replace the placeholders before pasting: VIDEO_ID appears twice (once in data-embed, once in the thumbnail URL) — it is the 11-character ID from your video's watch URL (youtube.com/watch?v=THIS_PART) — and write real alt text describing the video.
<!-- YouTube facade. ⚠️ REPLACE BEFORE PASTING: VIDEO_ID in BOTH places below
(the 11-character ID from youtube.com/watch?v=VIDEO_ID) + the alt text: -->
<div class="video-facade"
data-embed="https://www.youtube-nocookie.com/embed/VIDEO_ID?autoplay=1"
style="position:relative;aspect-ratio:16/9;max-width:640px;cursor:pointer;background:#000;border-radius:12px;overflow:hidden">
<img src="https://i.ytimg.com/vi/VIDEO_ID/hqdefault.jpg" alt="Video: what the video is about" loading="lazy"
style="position:absolute;inset:0;width:100%;height:100%;object-fit:cover" width="480" height="360" />
<button type="button" aria-label="Play video"
style="position:absolute;top:50%;left:50%;transform:translate(-50%,-50%);width:68px;height:48px;border:0;border-radius:10px;background:rgba(0,0,0,.72);cursor:pointer">
<svg viewBox="0 0 24 24" width="26" height="26" fill="#fff" aria-hidden="true" style="display:block;margin:auto"><path d="M8 5v14l11-7z"/></svg>
</button>
</div>
<!-- Prefer a maintained component? lite-youtube-embed does the same thing: -->
<!-- https://github.com/paulirish/lite-youtube-embed --> Watch Out For The Preloader Script, Not Just The Iframe
On HubSpot-built pages the cookie often comes from a PRELOADER (the /video-preloader/... request), injected automatically by HubSpot's page templates or the tracking script — not from an iframe you pasted. If you see play.hubspotvideo.com requests on pages with no visible video, search your page source and template modules for "hubspotvideo" and remove the module or script include on pages that do not need it. If the video module is part of a global template, move it into the specific pages that use it.
If you cannot remove it (e.g. it ships inside HubSpot's CMS theme), the fallback is the same idea one level up: load HubSpot's script itself only after first user interaction (scroll, click, or touch). We covered that exact deferral pattern in our Facebook Pixel guide — the same 6-line snippet works for any injected third-party script.
What NOT To Do
- Do not block play.hubspotvideo.com in a CSP just to silence the issue — the player will break with a console error, which fails the same audit for a different reason
- Do not set loading="lazy" on the iframe and call it done — lazy iframes still load once scrolled into view, and Lighthouse scrolls; the cookie still gets set
- Do not hide the issue with the DevTools "third-party cookie issues" filter — that changes what YOU see, not what Lighthouse measures
- Do not remove the video to chase a score — the facade keeps the video AND the score
The Fix, Step By Step
- 1
Confirm the source in the Issues panel
DevTools → three-dot menu → More tools → Issues. Expand the Cookie issue and check Affected Resources — note the domain (play.hubspotvideo.com, youtube.com, etc.) and whether the request is an iframe you embedded or an auto-injected preloader script.
- 2
Replace the embed with a click-to-play facade
Swap the provider's iframe for a poster image + play button holding the embed URL in a data attribute (code above). Self-host the poster for HubSpot; use i.ytimg.com thumbnails for YouTube.
- 3
HubSpot CMS module? Re-select the video and poster in the page editor
If the embed comes from a custom module ({% video_player %} tag), editing the module HTML or fields.json can clear the module's saved field values. Open the page editor, click the module, re-select the video in its video field and upload the poster image — otherwise the {% if player_id %} guard renders an empty section and nothing shows at all.
- 4
Inject the real iframe on first click, with autoplay
Add the small script that creates the iframe from data-embed on click and appends ?autoplay=1 so the visitor still gets one-click playback. Use { once: true } so it runs a single time.
- 5
For YouTube, switch to youtube-nocookie.com
Point the embed at https://www.youtube-nocookie.com/embed/VIDEO_ID — YouTube's official privacy-enhanced mode — so the post-click player behaves better too.
- 6
Hunt down auto-injected preloaders
If the cookie fires on pages with no visible video, search your templates for the provider's script include and remove it from pages that do not use video — or defer the script until first user interaction.
- 7
Re-run Lighthouse in an incognito window
Extensions can log their own issues and pollute the audit. In a clean incognito run, the Cookie issue should be gone and Best Practices back at 100.
From the trenches
How we hit this on a real production site
This exact issue came out of a live audit this week: a B2B site scoring well everywhere except Best Practices, with a single flagged Cookie issue from play.hubspotvideo.com — a /video-preloader/ request injected by the HubSpot page template on page load. Nobody had ever clicked the video during a Lighthouse run, but the preloader alone was enough to set the cookie and fail the audit.
There was no HubSpot setting to change it, because there never is: the cookie comes from HubSpot's server headers. The fix was the facade above — a self-hosted poster frame, a play button, and eight lines of JavaScript. The HubSpot player now loads only on click.
Result: the Cookie issue vanished from the Issues panel, Best Practices returned to 100, and mobile Performance improved as a side effect because a megabyte of player JavaScript left the critical path. If your scores are stuck on audits caused by third-party embeds you cannot control, this is the pattern that fixes almost all of them — and it is the kind of thing we do for clients every week.
Frequently Asked Questions
Is the third-party cookie warning actually a privacy problem for my visitors?
Usually no. HubSpot states its cookies are functionally first-party to your site, and YouTube's embed cookies are standard player-state cookies. Chrome flags them because they are set cross-site without the newest cookie attributes — it is a browser-policy warning, not evidence of tracking abuse. But Lighthouse fails the audit either way, so the facade fix is still worth doing.
Will the facade hurt my video engagement or analytics?
Playback engagement is typically unchanged or better — visitors see the same poster and click the same play button, and the page loads faster. What you lose is pre-click impression data inside the video platform (it only counts loads after the click). Most teams consider that a fair trade for a faster page and a clean audit.
Why not just add loading="lazy" to the iframe?
Lazy-loaded iframes still load when scrolled into view, and Lighthouse scrolls the full page during the audit. The cookie still gets set and the issue still appears. Only a click-gated facade keeps the player out of the audit entirely.
Does youtube-nocookie.com alone fix the audit?
Not reliably. The privacy-enhanced domain delays advertising cookies until playback, but the embed can still write player-state storage that Chrome flags, and it still pulls the full player JavaScript on load. Combine it with the facade: facade for the audit and performance, nocookie domain for post-click privacy.
What if the issue comes from a chat widget or pixel instead of a video?
Same principle, different injection point: defer the widget's script until first user interaction (scroll, mousemove, touch) instead of loading it in the head. See our Facebook Pixel deferral guide for the copy-paste pattern — it works for any third-party script.
Still stuck? Send us the exact error.
Paste the exact error message you're seeing and where it happens. We'll take a look — if it's quick we'll point you at the fix, and if it's deeper we'll tell you honestly what it takes.