Third-Party Cookies: Why Embeds and Trackers Break
A third-party cookie is a cookie set by a site other than the one in the address bar. When your
page at example.com loads a widget, ad or tracker from widgets.example.net, and that response
sets a cookie, the browser stores it for widgets.example.net. Without restrictions, the same
cookie is sent every time any site loads that widget, which is how cross-site tracking works.
Where browsers stand
- Safari blocks third-party cookies by default (Intelligent Tracking Prevention).
- Firefox isolates them by default with Total Cookie Protection: each site gets its own separate cookie jar for a third party, so the cookie no longer follows visitors across sites. Stricter settings block known trackers outright.
- Chrome still allows them in normal browsing for most users, but blocks them in Incognito by default, lets users block them, and has changed its plans for them several times. Do not build anything new that depends on them.
So for a large share of your visitors, features that rely on third-party cookies already fail.
What breaks
- Embedded logins and comments. A comment widget or chat that keeps the visitor signed in through its own cookie inside an iframe forgets them on every page.
- Single sign-on across domains that relies on a hidden iframe to check the session.
- Payment and booking widgets that store state in their own iframe.
- Analytics and advertising that count the same visitor across sites. This is the intended effect of the restrictions.
The failures are often silent: the widget loads, but logs people out, loses a basket or shows a “please enable cookies” message only in some browsers.
How to fix
Find out who sets them. The report lists the cookie domains Lighthouse saw. In Chrome DevTools, the Application tab → Cookies shows cookies per domain, and the Issues tab flags cookies that were blocked or will be.
Remove what you do not need. Old social share buttons, abandoned A/B testing tools and retargeting pixels are common sources. Removing an unused script is the simplest fix and also speeds up the page.
Update embeds. Many vendors have moved to first-party or partitioned approaches; a current version of the embed code may already solve it.
Use first-party cookies for your own services. If your API runs on another domain, serve it
from a subdomain of your site (api.example.com instead of example-api.net). Cookies between
subdomains of the same site are first-party (SameSite=Lax or Strict work), as long as the
registrable domain is the same.
Partitioned cookies (CHIPS) for embeds you run yourself. If your widget genuinely needs state
inside an iframe on other sites, set the cookie with the Partitioned attribute. The browser then
keeps a separate cookie per top-level site, which is enough for most embeds and does not allow
cross-site tracking:
Set-Cookie: __Host-widget_session=abc123; Secure; Path=/; SameSite=None; Partitioned
Storage Access API for cross-site logins. An embed can ask the browser for access to its
unpartitioned cookies after a user interaction (document.requestStorageAccess()). Support and
prompts differ between browsers, so test in each one.
In WordPress, third-party cookies usually come from embeds (video players, social feeds, comment
systems) and marketing plugins. Privacy-enhanced embed modes, such as YouTube’s
youtube-nocookie.com domain, reduce what is set before the visitor presses play.
How PerfoMetrix checks this
We read Lighthouse’s third-party-cookies audit from the PageSpeed Insights run the scan already
makes. Google loads the page once in a mobile lab browser; we send no extra requests to your site.
The check needs attention when Lighthouse saw at least one third-party cookie, and the report lists
the first few. Cookies set only after consent, login or interaction will not appear in this run.
Further reading: MDN: third-party cookies and MDN: cookies having independent partitioned state (CHIPS).