 Third-party cookies are just browser cookies like any other but they're set by a site that's different from the current top-level page. For example your site might include a third-party widget in an iFrame that sets a cookie to save preferences or maybe your site includes images from an image server you know it's run by your own company but it's on its own domain and even though you run both the website and the image server cookies from the image server across sites so they're still treated like third-party cookies. Chrome is planning to deprecate third-party cookies so you need to act now to ensure a smooth transition. I'm Sam Dutton a developer advocate with the Chrome team and in the previous video in this series I showed you how to audit your site for third-party cookie usage. In this video I'll show you how to test your site how it will perform without third-party cookies. You'll learn how to configure your browser to emulate third-party cookie deprecation and learn strategies to help you test for breakage. Now the traditional way to test how a site works without third-party cookies is simply to use browser settings to block third-party cookies. Without third-party cookies disabled you can see cross-site cookies being set for the web.dev homepage. From the network panel you'll see request cookies for cross-site assets in this case from Google.com You'll also notice warnings in the DevTools issues tab. Now I'll go to Chrome settings cookies and select block third-party cookies. So let's see what happens when I go back to the web.dev homepage and hard refresh. You'll see an eye at the right of the omnibox and when you click that you'll see if sites were blocked. From the application panel you'll still see cross-site cookies because these haven't been deleted and by the way to delete the cookies for an origin right click on the origin and select clear. If you go to the network panel now with third-party cookies blocked you won't see any cookies for cross-site requests and if you check the issues tab you won't see cross-site cookie warnings. Now just bear in mind that this is only true if the site is not attempting to set any cookies on that request. And by the way a quick and simple way to check how a site works without third-party cookies is to open it in incognito mode. As you can see here when I open web.dev in incognito mode there aren't any cookies set in the request. Now the trouble is incognito mode has a number of side effects. It doesn't just block third-party cookies. So all-in-all incognito mode can be useful but it doesn't give you a realistic site experience. Now a new way to test your site for third-party cookie breakage is to use the third-party cookie phase-out flag. And this makes Chrome behave as it will after third-party cookie deprecation. So it's ideal for testing the user experience without cross-site cookies. You set the phase-out flag from the Chrome flags page set enabled and click relaunched. And with the flag set you'll see an eye icon at the right of the omni box just like when you block third-party cookies from Chrome settings. When you click the eye icon you'll see if sites were blocked and in the network panel with the flag set you won't see any request cookies. With the third-party cookie phase-out flag you'll see an error for cross-site cookies. Cookie is blocked when set in cross-site context and that's what you'll see in the DevTools issues tab once Chrome has deprecated third-party cookies. Clicking the eye icon in the omni box allows users to temporarily re-enable third-party cookies for a site. Now let's see how that works. Click the eye icon and then click the slider to allow third-party cookies. You'll see the third-party cookies allowed message temporarily in the omni box and now if you go to the DevTools network panel you'll see cross-site cookies. Turn off third-party cookies again from the omni box and you'll see that there are no request cookies from the network panel in DevTools. Now as with other Chrome flags you can also set the phase-out flag if you run Chrome from the command line. Here I'm opening Chrome Canary with the test third-party cookie phase-out flag and just be aware that you won't see this command line flag reflected in the Chrome flags page. Now one thing you'll notice if you set the phase-out flag is that you'll still see the Chrome settings page for cookies. As the warning bar says third-party cookie blocking cannot be overridden via the settings page. As you can see even if I select allow third-party cookies from Chrome settings third-party cookies are still blocked and the DevTools network panel shows that no request cookies are sent. Once third-party cookies have been deprecated Chrome settings will no longer have a page to block third-party cookies since yeah that just wouldn't make sense. Instead of a Chrome settings cookie page there will be a new tracking protection page and you can try this out by enabling tracking protection from Chrome flags. With the tracking protection flag set you get a Chrome settings page for tracking protection instead of a page for cookies. So you've learned how to test web pages without third-party cookies. Now you need to develop a strategy to minimize site breakage once Chrome deprecates third-party cookies. Now a good first step is to understand cross-site interactions across your own sites and with third parties. You need to audit your sites to clarify what first and third-party services you're using. So now is a really good time to reduce technical debt and improve page load performance by getting rid of unnecessary tags and embeds. Next you might want to compile a list of critical user journeys and use cases across your sites. For example does embedded content such as a store finder or video widget still work on your site? Our site features such as rating or bookmarking affected to sign up and checkout flows work as expected. From this checklist of user journeys and use cases you can build a to-do list of things to fix. You could also consider working with internal teams or even trusted external testers to test your sites without third-party cookies. Ask your developer team to use your sites in Chrome with third-party cookies blocked. And once you've tested internally within your developer team you might even want to test across your entire company. To collect feedback about breakage you can provide a simple form for your staff or even install a Chrome extension to collect information. Now make sure that your deprecation experiments are integrated with test suites and QA processes and of course talk to account managers for ads and other third-party content and services. Ask third-party providers how they're planning for third-party cookie deprecation in Chrome. You can also report breakage of your own or other sites by creating an issue on the third-party cookie deprecation breakage repository. And this repository will help developers understand where users are experiencing problems and how breakage is being fixed. Once you've identified potential breakage on your sites you can begin to plan for transitioning from third-party cookies to alternative technologies. For example, for requests across your sites and services you should consider whether you can begin to use partition cookies known as chips. If you add the partitioned attribute to a cookie it will be double keyed by the origin that sets it as well as the origin of the top-level page. And partition cookies will not be blocked by third-party cookie deprecation. So you can find out more about chips from our article on developer.chrome.com. And you might also want to consider related website sets. Related website sets is a platform mechanism to help browsers understand the relationships between a collection of domains. For example, you might have sites across different country domains with multiple different brands using app service or sandbox domains. And related website sets allows you to declare domains as belonging to the same set in order to allow some limited cross-site cookie access for specific use cases. To set up a related website set you first need to provide a JSON file in the well-known directory on your websites that specifies the structure of your set. Next, you submit your set to the related website sets repo on GitHub and that repo maintains the canonical related website sets list as a publicly viewable JSON file. You can find out more about related website sets again from our guidance on developer.chrome.com. So that's how you can test for breakage on your sites once Chrome has deprecated third-party cookies. And to find out more about testing for third-party cookie breakage, take a look at the guide that accompanies this video. Our article preparing for the end of third-party cookies has everything you need to know about testing and deprecation timeframes, as well as strategies to help you transition smoothly from third-party cookies to other technologies. To understand more about cookie usage and learn how to identify third-party cookies on your site, take a look at the previous video in this series, check your site for third party cookies. So thanks for watching. And be sure to catch the other videos in our third party cookie deprecation series.