 And welcome to a very virtual Chrome Dev Summit 2021. I'm Ben, and in the next few minutes, my colleagues and I, along with a few guests, will share some of the highlights of our work over the past year to improve the web. In 2008, Chrome launched with a vision that the web could be more than just rich documents, that I could enable fast, safe, and powerful applications across devices available instantly with just the click of a link. This vision of the web has become more relevant than ever during the pandemic, as people around the world realize how powerful the web platform has become and look increasingly to the web and their browser to get things done every day. And the web's continued success is only possible because it's continued to evolve through the years, adapting as technology advances and as people's expectations shift. As we at Google help evolve the web, we strive for transparency and openness in all that we do, collaborating closely with developers, users, and the rest of the ecosystem. Now, this theme of web evolution is the central one for this video. And we're gonna highlight a number of examples that represent the web's continual progress. One of the most important of these themes comes from feedback that we consistently receive from web developers, both via surveys and individual conversations. And this theme is the importance of cross browser compatibility. Now, of course, this theme isn't new. And through the years, the Chrome team has joined with others on various initiatives to help. Recent examples include the web platform test project, which is a comprehensive cross browser test suite for new web platform features hosted on GitHub and the open web docs initiative that brings together a large coalition to collaboratively contribute to the web platform documentation that's hosted on Mozilla's developer network. This year, we've added a new initiative to the list, a cross browser effort called Compat 2021 that's focused on improving compatibility in five key areas of the web, all related shockingly to CSS. To measure our progress, the Compat 2021 team was able to use the aforementioned web platform test project to quantify compatibility scores for these areas across the latest development builds of Chrome, Edge, Firefox, and Safari. Now, while we're not done yet, we've already seen significant improvements since March and we'll keep pushing to make the web much more compatible in these and other critical areas. Another area in which the web is evolving is privacy, as we seek to curtail third-party tracking practices while preserving important and critical capabilities that enable a vibrant global web ecosystem. To tell us more, I'd like to introduce my colleague, Barb. Thank you, Ben. We believe it's important for people to be in control of their information, including their online activity. Most users believe it's important too with privacy concerns increasingly driving choices about what people do online. We also see regulations around the world stepping up privacy requirements at a rapid pace. And yet, it's difficult for developers to meet growing expectations for privacy when so many capabilities rely on third-party cookies and other cross-site tracking mechanisms that weren't designed with privacy in mind. We need new technologies for a modern privacy-focused web, and that's what the Privacy Sandbox is about. We're working with the web community and industry stakeholders to develop new privacy-preserving technologies that can support a healthy, sustainable ecosystem. This includes purpose-built APIs to support advertising, which is a critical part of the ecosystem and funds much of the web's content, as well as many other capabilities that modern sites need, like fraud detection, identity, or content that's customized to a user's device. Now, let's take a minute to clarify what we mean by purpose-built APIs. Many of the use cases that I just mentioned were never really built into the web platform but layered over it using general-purpose technologies like third-party cookies. The browser has no way to tell whether you're using third-party cookies for something helpful, like providing a customized experience or keeping a user logged in or for cross-site tracking. By designing APIs for each specific use case, we can ensure appropriate privacy protections, give people more useful controls, and ideally make each API better at what it does over time. Once these new APIs are in place, we'll make sure that developers have time to adopt them so that we can safely phase out support for third-party cookies in Chrome. While continuing our work to mitigate other types of tracking, so that cross-site tracking doesn't simply shift from third-party cookies to more covert methods. To make this complex project easier to follow, we're sharing progress in two places. PrivacySandbox.com explains the vision, goals, and concepts behind this initiative. It also includes a high-level timeline that we're updating every month. The timeline links to each of the technologies we're working to test and launch, and lays out a stage plan for phasing out third-party cookies in Chrome. The second resource is the PrivacySandbox section at developer.chrome.com. Here you'll find more technical detail and implementation guidance, including a blog with the latest updates for developers. We've just added a post with all the links and updates from this session. Now, we talk a lot about the importance of collaboration in this project, and I'd like to show you what that looks like at each stage of development. I'll mention some APIs as examples, but the broader idea is to illustrate how ecosystem involvement is shaping this work. This process will be familiar to many of you in the web development community, but the PrivacySandbox is bringing a lot of newcomers to this process, including industry stakeholders who will use these purpose-built APIs and whose expertise is critical in their development. The first stage of the process is discussion, where anyone can propose and weigh in on ideas for new technologies. There have been dozens of privacy-preserving proposals offered by Chrome and others over the last couple of years. They're all online, so you can read them, ask questions, offer ideas to improve them, and see what others are saying. To find live conversations where all of the proposed solutions are being discussed and debated together, there are a number of W3C groups that you can join or monitor depending on the types of use cases you're interested in. Here's one example to illustrate how involved this discussion stage can get. Fledge is a proposal to support interest-based advertising without cross-site tracking. With valuable input from privacy advocates and many industry stakeholders, Fledge has evolved from two previous proposals with more than 100 organizations joining W3C meetings to help refine the current version and over 200 online discussion threads. There've also been more than half a dozen other proposals in the same solution space. Through continued incubation, we hope we'll reach consensus on a path forward. And at the same time, we're starting developer testing for the initial version of Fledge behind a flag in Chrome so that developers can get their hands on it. Not all of these proposals will go through such an intense incubation period. Some will move much more quickly, but there's a lot of innovation happening here. These are new ideas and it can take a lot of work to get them right. The next stage is testing. There are already a handful of proposals ready for developer testing today and you can expect more as we head into 2022. And don't be surprised to see some iterative cycles of discussion and testing. Testing is important precisely because it surfaces issues or gaps that may require more work. Testing in Chrome usually starts with a feature behind a flag for developers to test locally. This means you need to turn it on in your browser to try it out. This code is often very fresh so you can expect to find some issues. And then origin trials, each running for a limited time with a limited population of Chrome users. Origin trials are public and open to all developers. You just need to register to opt in your site or service. This is when we get actionable feedback from developers on what works, what doesn't, and where those gaps are. Success at this stage depends not only on developers doing hands-on testing, but on their being willing to share what they learn. For example, Yahoo! Japan recently published a detailed analysis of their test of the Attribution Reporting API, highlighting areas for improvement, like the need for a better way to deliver conversion reports, which has now been added. These are the sorts of things that turn up once developers can get their hands on an API. We also hope to see companies talking about their approach to testing and how they expect to use an API. During the origin trial for the first version of Flock, a proposal to support interest-based advertising and content, we were pleased to see companies like Cafe Media publishing their analysis and insights so that others could see what they'd learned. And Chrome tests aren't the only way to explore how new technologies might work. Some companies are also building simulations based on Privacy Sandbox concepts. Advertising platform Crudio recently ran a competition with more than 150 teams, testing different machine learning models to evaluate how differential privacy concepts, such as noise insertion and aggregation, might impact advertising performance. It's helpful to examine these concepts since they underlie several of the Privacy Sandbox APIs. We are truly appreciative of the companies investing their time to test these new technologies and of their being willing to share their perspectives and learnings publicly. Now, once an API is tested and ready for general use in Chrome, we'll announce the launch and make sure public documentation is ready for scaled adoption. User Agent Client Hints, or UACH, launched in Chrome earlier this year and is now ready to scale. It's part of the Privacy Sandbox work stream to reduce covert tracking, such as browser fingerprinting. But first, let's back up and take a look at the legacy mechanism it's replacing. Like cookies, the user agent string is an early web feature. By default, it provides a lot of information about the user's browser and device, making it a readily available surface for fingerprinting. It also has a format that can be a headache to parse. We recently announced plans to start reducing the granularity of information available in Chrome's user agent string, starting in April of 2022. To get that information in the future, you'll need to transition to User Agent Client Hints. It'll give you some information by default, which may cover most of your use cases with more detailed information on request in a straightforward format. We were happy to make this ergonomic improvement for developers while at the same time moving the majority of user agent information from an available by default model to an on request model. That way, you can request only the information you need, which is good practice today and the pattern we want to set for the future. So let's go back to the timeline I showed you a moment ago. Gradual UA string reduction starts in April of 2022. The replacement solution, User Agent Client Hints, has been launched and ready for scaled adoption since March. So you can begin testing and migrating to it anytime now. To help with that, there's an origin trial to opt in to the reduced UA string early so that you can see what that future state will look like. And if it turns out that you need more time, you'll be able to opt in to keep using the user agent string as is through March 2023. The details of this plan are all online. And while the scaled adoption stage might not look exactly like this for other APIs, you can expect to see consistency in the overall approach. We'll continue to explain what's happening, provide as much visibility as we can, encourage your involvement and hear your input. We appreciate all contributions to this complex and vitally important project. As we seek to create durable web features with broad utility and strong privacy protections for users, it's worth this effort to get the foundations right. And Ben, I will hand it back to you. Thanks, Barb. The Privacy Sandbox is one of the largest efforts we've seen to evolve the web. We believe that it's critically important to help ensure the web's continued health and success for decades to come. The next theme we'll highlight is web capabilities. Over the past several years, the web's gained a number of powerful new integrations that enable web apps to do more. We've been heavily involved in this with the Fugu project, collaborating with others in the ecosystem to unlock things like secure file system access and rich integration with operating system launchers. And as the web has gained these new capabilities, developers have embraced them in compelling ways. To tell us more, I'd like to introduce my colleague, Anshil. Thanks, Ben. Before we dive in, take a couple of seconds to look around you. No, really. Look closely at your surroundings. Most of you are probably at home right now, a place that in the last couple of years has transformed into a bussing, tech-driven hub. Our kids have turned the dining room into a virtual classroom, we've turned the kitchen into our office, and we're all connecting with family and friends in living rooms around the world. The pivot to virtual has had a profound impact on how we live and work. In particular, it's the world of video and creation that has seen a powerful shift in norms. From casual creators to professional designers, there's real-time editing, sharing and collaboration, but it's entirely virtual. Hosting and attending video conference calls from some part of the house is now a regular part of our day. And let's be honest, we've been streaming and binge-watching more content than we ever thought possible. Our team has worked hard to unlock new paths for the web, whether you're taking your existing experience to the next level or building something that's cutting edge and never been done before. We're inspired and grateful to see how our partners around the world are building web experiences that enable creativity, expression, communication, entertainment, and so much more. One example is Kapwing. Kapwing is a collaborative video editor with more than 3 million monthly active users processing 100,000 videos a day. To tell you more, I'd like to invite a special guest, Josh Grosper. Hi, I'm Josh, CTO at Kapwing. Kapwing is a web-based collaborative video editor designed mainly for casual creatives like game streamers, musicians, YouTube creators, and memers. We're also a go-to resource for business owners who need an easy way to produce their own social content, like Facebook and Instagram ads. People usually discover us by searching for a specific task like how to trim a video, add music to my video, or resize a video. Kapwing lets users instantly do what they search for with one click. There's no added friction by making them navigate to an app store to download an app. The web makes it so much simpler for people to search for precisely what they need help with and then do it. The fact that we pay $0 in paid acquisition is a testament to how well this strategy has worked. And after that first click, they can do a whole lot more. They can explore free templates, add new layers of free stock videos, insert subtitles and transcribe videos, and upload background music. The web also makes it easy for users to collaborate on Kapwing with friends and colleagues, regardless of their device or operating system. Just click share, get a share link, and send it to your collaborator. All they have to do is click the link and they are editing with you. And because supporting different devices and OSs takes minimal work on the web, it's the ideal environment to enable this level of collaboration. Editing videos in Kapwing works easily and seamlessly in all modern browsers. High performance editing requires all of our users' content to live on the client, avoiding the network whenever possible. For that, we use index DB. Web sockets enable the real-time collaboration that users expect in modern web apps. To generate waveforms and allow users to spice together audio in exactly the right place, we use the Web Audio API. The Media Recorder API allows users to simultaneously record their webcam and screen, perfect for catching facial expressions when creating screencasts. Web workers allow us to offload computationally-intensive work, removing the background from videos without affecting the performance of the main thread. And of course, we've built Kapwing as a PWA, so once users have found it from search, it's installable, and coming back to it is as easy as launching it from their desktop. In the future, we're excited to use web codecs to accelerate our frame drawings, use WebGL to enable more sophisticated animations, and use media source extensions to have more seamless transitions from clip to clip. None of these APIs are brand new, but when combined together, they make it a lot easier for our users to collaborate with each other and quickly bring their ideas to life. And for us, the web gives us a streamlined way to reach and engage more users. Back to you, Anchal. Thanks, Josh. So if you're looking to create a CDS meme, you know where to go. I highly recommend trying out Kapwing. It's really easy to use. And now, onto a web feature we're all more than familiar with, video conferencing. It'll be hard to find someone who hasn't clicked on a Zoom meeting in the last two years. In 2020, Zoom saw huge influx of people using its web app to chat and connect online. For virtual happy hours, group workshops, online webinars, you name it. Zoom took this opportunity to improve their web experience with a PWA and to provide a more comparable experience to their native apps. It was also a chance for Zoom to offer its millions of Chrome OS users a powerful alternative to their Chrome app. They're using the new Web Codex API for video encoding and decoding, which improves the performance and enhances the user experience with fast, clean video. Link capturing ensures that when a user clicks on a link to a Zoom meeting in their email, it opens in the PWA and not in the browser tab. And for Chrome OS users, managed configurations allow enterprises to easily install the PWA across the workforce. Just one month after launching the PWA, Zoom saw 16.9 million new users join web meetings, which amounts to an increase of 7 million euro per year. With developments in WebRTC and Fugu APIs, audio and video call experiences that were previously not possible are now available. Apple has brought FaceTime links to the web for Android and Windows users so people can join a FaceTime call from their web browser. And we have the Google Meet PWA to thank for this keynote. We collaborated and created everything you see today on several Google Meet web calls. And I mean several. Then produced it remotely in a studio and you're most likely watching it on YouTube at home. The Meet team shipped custom backgrounds and light adjustments in their PWA using Wasm SIMD and WebGL. This has drastically improved the speed as well as the video and audio quality. And better video and audio aren't all work and no play. The world of entertainment and social media is thriving on the web. YouTube Premium is a paid subscription which enables members to watch YouTube ad-free, play videos in the background and download videos to watch offline. Watching videos offline on laptops and hybrid devices was one of the top requested features from YouTube Premium users. To make this possible, they added everything necessary to turn their site into an installable PWA. For the offline experience, they use a combination of service workers, cash storage and index DB. Of course, the team focused on more than just the offline experience. For example, they use the WebShare APIs so users can share links to videos with other installed apps on the device and navigation preload to increase service worker performance. They're running an experiment to enable YouTube Premium users to download videos that can be watched offline on Chrome, Edge or Opera. They're looking forward to delighting Premium users with the new features soon. I can't talk about social and entertainment without mentioning short-form videos. That's where TikTok is leading the way. TikTok views the Web as a channel to acquire more users, keep them happy and they focused on creating a multi-form factor, frictionless experience. They've optimized the performance of their Web app, using Workbox to prefetch videos to reduce any lag as users transition between videos. They've also expanded the PWA to desktop, leaning in on the web superpower of building just once and making TikTok available and accessible on any device. With these improvements across mobile and desktop, TikTok's seen the traffic from search has improved by 10x. So as you can see, Web on desktop has seen path-breaking innovation in the last few years. Users now have access to complex creativity and productivity tools that are enabling instant expression and collaboration. There's a powerful Web app for every use case, whether you're learning something new, talking to your boss, or simply creating something beautiful. And that brings us to some exciting news that I'm thrilled to share with you. After nearly three years of an ongoing strong partnership with Adobe, many flagship apps in the Adobe Creative Cloud Suite are soon coming to the Web. Bringing advanced features and capabilities to the platform would be incomplete without real use by companies like Adobe that are pushing the edge of what's possible. And we believe these collaborations benefit all developers, opening up new opportunities to create incredible experiences for their users. And now I'd like to welcome another special guest, Pam Clark, VP of Product Management and Strategy for Adobe Photoshop to tell us more about these launches. Hello, everyone. I'm excited to be here with you at Chrome Dev Summit. At Adobe, we believe creativity and collaboration go hand in hand. And over the past year, we've made lots of advancements to products like Photoshop to support the kinds of mobile and collaborative workflows our customers want. For instance, you can now store PSDs in the cloud so you can work on a single document across all of your devices. You can also create and share links to those PSDs in the cloud. You can co-edit them with your collaborators and share them on the Web for review and comment. We are committed to helping people create and work together no matter how they want to work, which is why at Adobe Max last week, we shared a vision for the next evolution of Creative Cloud, one that is as much about connecting with each other as it is about creative tools. For decades, you could only use Photoshop on a computer, a powerful computer at that. Then Photoshop went mobile on the iPad, and now we're making Photoshop accessible in a web browser via a public beta. Thanks to the close collaboration with the Chrome and web platform team at Google, Adobe is able to bring Photoshop magic to millions more people around the globe. The Photoshop on Web beta allows you to access, review and comment workflows and test out some Photoshop editing features we are piloting. Your collaborators will also be able to open and view your work in the browser, provide feedback and make basic edits all in one place without having to download or launch the Photoshop application on the desktop or iPad. The collaboration between Adobe, Google and within the standards bodies helped bring the functionality needed for Photoshop into the browser. WebAssembly allowed us to bring large portions of our code base to the web. Some of that code relies on exceptions for flow control. The addition of zero cost exception handling means there's no performance penalties. For high fidelity work, Canvas 2D is now color managed and supports sRGB and the P3 color space. Reading and writing your files to disk had to feel natural, and the storage foundation API ensures that you can work on your PSDs no matter how big or how many layers they have. We're still at the beginning of exploring Photoshop editing features on the web and we are looking forward to the feedback from the Adobe community, which will help us grow the capabilities and functionality of the browser experience. In addition to Photoshop on Web beta, last week we also announced Creative Cloud Spaces and Creative Cloud Canvas, both in private beta. Spaces are a shared place that allows teams to access and organize all their creative project files. Canvas is a new surface where teams can display, visualize and review creative work together. We are excited by the idea of giving everyone more ways to access our tools. By bringing them to the web, we are helping to create a more fluid, more connected, more collaborative environment for your projects. This is just the beginning of a broader evolution of Creative Cloud. Thanks so much for your time. And now, Ben will pick things back up to talk some more about user experiences. Thanks Pam, Josh and Anchil for walking us through these highlights. You know, progress on the web generally comes in iterations, year over year, step by step. And so it's amazing to me when we can take a step back and reflect on what's become possible on the platform over time. As these examples have shown and as the web gains new features and capabilities, another theme we hear is the importance of helping developers get the best results they can out of the modern web platform. Now one way we're doing this is the web vitals program, which is the result of years of research to understand what makes a web experience great. With core web vitals, we closely examined many factors that lead to high quality user experiences and we identified three quantifiable measures that have a big impact. Now these are, one, how quickly a user can see a site's most important content. Two, how quickly a user can start to interact with that site. And three, the stability of the site's layout over time. And we found that websites which optimize these measures are consistently more successful. To tell us more, I'd like to introduce Hussein. Thanks Ben. So, if you want to build a great website, you need to understand how it performs from a real user's point of view. That's what the web vitals initiative is all about. Giving developers and site orders the metrics, tools, and guidance they need to deliver a great experience for every user. Last year we announced that the core vitals, a set of three metrics that covers loading performance, input responsiveness during load, and the visual stability of content will begin to be serviced across tools provided by Google to help developers build great user experience. So what's happened in the past year? Thanks to developers around the world working hard in improving their sites, the ecosystem as a whole is steadily improving. 20% more page visits in Chrome now fully meet the recommended core vital thresholds compared to a year ago. And the total percentage of page visits in Chrome that meet these thresholds is now 60%, which is a big deal. Much of these advancements are a direct result of the work being done by developer communities, including the improvements that many content management systems, website builders, and e-commerce platforms have made. This past spring, we launched a new core vitals technology report to show how sites built on these platforms perform. You can see that many are sharply up and to the right, with some showing more than 200% improvement year on year. And leaders like Duda and Jimdo surpassing 50% of origins with good core vital scores. We've also worked with some popular JavaScript frameworks, including Next.js and Angular, to deliver the best user experience as possible without sacrificing developer experience. We're calling the initiative Aurora. And thanks to the work we've done to land strong defaults and optimized performance, in less than a year we've seen 91% and 111% increases in the number of mobile Next.js and Angular origins respectively, that have good core vital scores. That's incredible progress in a short time span. And we can't wait to see similar growth in other framework ecosystems in the near future, like Nuxt. We know that optimizing for core vitals could still be challenging for the everyday developer. So we've got a couple of new updates to our performance tooling that make the process a lot easier. First, we've started with a complete revamp of the PageSpeed Insights UI. PageSpeed Insights is a great tool because it'll show you real user data from the Chrome UX report and it'll also run a Lighthouse report and show suggestions and opportunities to improve based on a synthetic load of the page in a lab environment. The new UI makes it much clearer which data is field data coming from real user experiences and which data is lab data coming from the Lighthouse report. If you want to check a core vital score, you should always look at real user field data. For anyone who wants specific actionable suggestions for how to improve performance, the Lighthouse report is a great place to start. Next up, we've worked on addressing a blind spot that our tooling hasn't been able to capture yet. User flows. Some of our tools have been limited by only assessing your pages during load. They wouldn't scroll down the page, click around or do anything else that users typically do as they browse the web. For example, consider a typical checkout flow where someone needs to perform a number of different actions to order some coffee like navigating through several pages, adding items to a cart and confirming their payment details. In the past, we could only measure the performance of each page separately but think about how much more we could learn about the overall user experience by measuring every action and navigation in between. We're glad to announce that we rolled out support for user flows in Lighthouse, which will only make it easier to diagnose performance issues within a user journey and get suggestions for how to improve. Lighthouse will be able to distinguish and provide separate reports for page navigations, any user interactions that occurred during a given time span and snapshots to represent a captured state of a page. And it's not just the Lighthouse where we're introducing support to analyzing user flows. We launched a completely new recorder panel in DevTools that will also let you record an entire user journey on your website and easily view all the actions taken by the user directly in the panel, such as navigations, key presses, link clicks, and so on. You can download the user flow and export it as a puppeteer script for testing, replay it, and even click and easily measure the performance trace in the performance panel. Not only will this make the process of understanding and debugging interactions easier, it will also help you better identify performance opportunities throughout the user journey. The recorder panel is currently in the preview stage and the team is working on it actively, so stay tuned for more features. All of our tooling has been instrumental to how the core volumetrics have helped developers succeed in improving the user experiences of millions of sites around the world. And all these brand new changes will go a long way to help you understand precisely where and how you can keep getting better. Now, what's next for the core volumetrics themselves? Well, there's more to great user experiences than just three areas, and we're working hard to fill the gaps that the current set of metrics don't address just yet. We're excited to introduce two new metrics we've been experimenting with that we think will improve how user experience is measured on the web, and we'd love to get your feedback on. The first is a metric to measure overall input responsiveness. Today, we measure the responsiveness of the first user input, but ideally, we want to extend that to capture every user input from the moment they land in your site to the moment they leave. We've also made improvements to the APIs that capture event timing, so we can better monitor the full event lifecycle and better handle complex user inputs that trigger more than one event. The second metric measures scrolling and animation smoothness. I'm sure we've all had experiences where a page will stutter or freeze during scrolling or animations. We want to better understand how often this happens and how severe it is. We're still working on both of these metrics, and we'd love to hear your feedback. These articles explain our current thinking in detail, so give them a read and think about how using them can help improve the user experience of your site. Feel free to send us an email if you have any thoughts or suggestions. We're excited about all the advancements that have been made to help developers succeed in building fast, delightful experiences for their users, in the metrics themselves, from the community, and directly in many tools and platforms. If you haven't already, go to PageMe Insights to see how your site scores on the core of Vital's metrics. We also have a number of other great tools that you can also use to continuously monitor and optimize your site's performance. So be sure to check them out to see which one works best for you. Now I'll pass it back to Ben before we share some exciting updates about UX design. Thanks, Usain. I'm really excited to see how core of Vital's evolves in the coming years. Of course, quality web experiences are about more than just measurement and optimization. They require the efforts of passionate designers and developers who work behind the scenes to create delightful digital interfaces and need to be armed with the right tools and capabilities to do that. A few years ago, a group of engineers set about rethinking Chromium support for HTML, CSS, and graphics, which led to an effort called Rendering NG, an ambitious refactoring of Chromium's rendering engine. This work has now largely landed and it's enabling a major evolution in web user experience design. To tell us more, I'll hand things over to Yuna. Thank you. Everything we've talked about today comes back to the user experience. Privacy, measurement, next-gen web capabilities, they all work together to create better experiences that align with our vision for the web while giving developers the tools and capabilities they need to build them. So today, I'm excited to share a ton of updates and changes coming down the pipeline for UI styling and dev tools. First, let's talk about responsive design and how it's evolving. Responsive design is no longer just about making sure an interface looks good on both desktop and mobile devices. Developers now have the tools to really create customized user experiences based on personalized user preferences in a component-driven architecture model. Recalling this, the new responsive, and it includes being responsive to the user with user preference queries and modalities like dark mode and prefers reduced motion, being responsive to new form factors like foldable devices, which allow for multi-display functionality, and being responsive to other components on the page with container queries. This is a feature that's been highly requested by developers. We've been working with the CSS Working Group to spec this feature and have been able to unlock the implementation through recent changes in the Chrome rendering engine. The new container query spec lets you access a parent elements width to make styling decisions for its children. You can even nest container queries and create named queries for easier access in organization. Let's take a look at an example. Here I have a responsive add to cart button that I can place anywhere in the container. Then when I put it inside of this product card, which is also a container, I can query the product card itself to restyle the already responsive button and shift it from being center aligned to left aligned. This might look simple on the surface, but it's something that wasn't previously possible without a lot of heavy scripting, which would significantly slow down your page. We're working with the open source community to provide a polyfill for container queries as we build the feature into the platform. Using container queries makes your interfaces much more flexible. Components own all of their individual responsive styles right where they are and don't rely on the global viewport to adjust styles. This is a huge paradigm shift for component based developments and we're excited to see how you make the most of this new feature. If you wanna try it out, container queries are now available for testing behind a flag in Chrome Canary. And because of this big shift, we've been working hard to support you by providing DevTools that allow you to debug in style with container queries as the feature launches. Here you can see that DevTools is pointing out where the container for the child is and highlighting the styles that are being applied by it. Speaking of responsive DevTools, we released several new tools this year for better layout debugging. Layout tooling for Grid now allows you to add names to specific grid lines and also shows you the size of your grid areas. I also love the dynamic new tools for Flexbox and Grid. These let you actually see what different property values do on the page and give you the ability to easily change layout rules with the click of a button. These new DevTools are designed to make CSS layout easier to visualize and understand which frees up more time to build new features for your users and less time looking up the differences between justify and align. Another way we're helping simplify the process is by launching web.dev patterns, a collection of off-the-shelf UI patterns you can use in your web projects. To help you quickly get started with building the base of your UI, we've added layout patterns for everything from large, full-page spreads and card sets to smaller layouts that can live within those larger layouts such as the cards themselves. All of these patterns use CSS Grid, Flexbox or container queries to showcase how quickly you can pick up these tools and build interfaces from the ground up. We're also partnering with Jeremy Keith of Clear Left to launch Learn Responsive Design on web.dev. This is a free online course with everything you need to know about designing for the new responsive web of today. You'll learn about theming, art direction, logical properties for internationalization, utilizing preference queries and so much more. Today we're launching the first few course modules at web.dev slash learn slash design with more to come in the following weeks. We're also updating our Learn CSS course with six new modules. Learn CSS is another free evergreen course in reference on web.dev where you can level up your CSS knowledge and test your skills. We launched the first 24 modules at Google I.O. this year and now we're introducing lists, backgrounds, transitions, text and typography, media queries and more. Be sure to check out those new modules and dive in whenever you're ready. We're also working on rolling out some new features in CSS. In addition to container queries, our team has been thinking about how to introduce scope styles and cascade layers. They're not ready just yet and we look forward to working with you and the web community over the next few months to push them forward. We do have a particularly fun new API that's ready for exploration and that's scroll timeline. Previously you could create CSS animations that had a time basis and moved over a length of time. Scroll timeline lets you set scroll-based offsets and timings for animations instead. That means you can set an element to animate as you scroll down or across a page. Pretty neat. You can explore scroll timeline using the experimental web platform features flag in Canary. We have another exciting addition that recently reached its first public working draft and that's CSS nesting. Nesting is a syntactic sugar that brings one of the most popular features of CSS preprocessors to the web, stacking your styles for a cleaner developer experience. While the nesting spec will let you keep your styles tidier and more encapsulated, we recommend that you don't go more than three layers deep to ensure the best performance. We've also launched the size-adjust property for typography. This is particularly useful for preventing cumulative layout shift for core web vitals as you can adjust the default font to better match your web font. This causes less jank as the web font loads in. And last but not least, accent color just landed in Chromium and Firefox stable. Accent color is a one-line CSS superpower that gives your form controls like checkboxes and radios a theme color to match your brand. We get a lot of feature requests from developers and users alike, but one is a clear favorite, especially for those of you who love to browse the web at night. Dark mode is a popular feature we're really excited to build on and not just because you asked for it, but because its impact extends beyond the user interface. Dark themes have shown measurable battery life savings over their light theme counterparts on OLED devices. In our lab study with a single Pixel 6 device, we found an indication that at 60% brightness, dark themes used 11% less power than light themes for OLED screens. And it's a feature that users love too. When Twitter released the first preview version of their new Twitter progressive web app, everyone said, wow, it's new and fast, but where is dark mode? So they surveyed users on what they needed to add and user said three things, dark mode, an emoji picker and more dark mode. So it's kind of a big deal to a lot of very vocal users. To create a dark theme, we recommend using CSS custom properties and the prefers color scheme media feature, which is supported in all evergreen browsers. This lets you swap theme colors in and out based on what your users prefer, a core part of our new responsive framework and set of goals. If you need help getting dark mode set up the way you like it, there's some excellent new guidance from the material design team by their research on building beautiful dark themes. This includes how to adjust depth by using lightness instead of shadows, how to adjust color vibrancy to reduce visual vibration and more. But to make it even easier for your team, Chrome is working on a machine learning aided auto dark algorithm feature. This feature will include auto dark and websites along with a few affordances to opt out of the auto dark functionality on a more granular level. We're still in the early stages of feature developments and we need your help to get it right. To try it out now, you can open the DevTools rendering panel in Chrome Canary and enable auto dark mode emulation. Check out the link to learn more and to give us your thoughts. Now I'll pass it back to Ben one last time. Thanks, Yuna. You know, we've seen a lot of change in the web over the past year and we're still more optimistic than ever about the future of the platform, across the areas we just talked about and more. In the years ahead, you can expect to see us continue to push hard to make the web more private and powerful and to provide developers with better tools and guidance to create top quality experiences for people all over the world. And a part of what makes the web so special is that it's an open, decentralized ecosystem which presents lots of ways for anyone to get involved in helping to shape its future. So we invite you to participate with this effort, whether that's through the Chromium Open Source Project, the W3C and other standards bodies or simply following along with us on web.dev and our Chromium Dev Twitter account. And over the next couple of weeks as part of this virtual CDS 2021, we're hosting a number of workshops, group learning lounges and one-on-one office hours where you can engage directly with the Chrome team, audit your own sites with expert guidance, give us feedback and share your ideas for the future of the web. And with that, thank you for watching. And I hope to see you again in person sometime soon at a future Chrome Dev Summit event. Until then. Thank you, Google Chrome leadership team, where we're answering your questions about troubleshooting, building great web experiences and the future of Chrome and the web platform. And some of these questions are spicy, so definitely stay tuned. We're also taking live questions on Twitter, Discord and Slido. You can find the links to Discord and Slido on the CDS website. And if you'd like to ask your question on Twitter, tweet at Chromium Dev. That's at Chromium Dev, in one word. We have Jake Archibald looking out for your questions live, so if your question doesn't get asked, just blame him. I'm Una Kraviz, a developer advocate on the Chrome web platform team. And here with me, we have directors and leads from Product Management, Engineering, Privacy, Capabilities, Rendering and Graphics all across Chrome gathered here today in a meeting at the same time. And I've seen how packed their schedules are. It's so nice to have you all here with me today. So to get started, I'd love for you all to introduce yourselves and tell everyone watching a little bit about what you do and the areas your teams cover. Maybe we can go in order starting from Ben Galbraith and then we can go to Ben Goodger, Parisa and Chris. Great, hey everyone, Ben Galbraith. I lead Product Management for Chrome's web platform team. And I've been working on the web platform or building on top of the web platform as a web developer since, I guess 1995 or so in various industry roles. And I've been at Google since 2015 with a one year intermission. Happy to be here. Hey, I'm Ben Goodger and I lead Engineering, Product and Developer Relations for web platform in Chrome. I've been working on the web since the mid 1990s, initially as a developer and then I got involved in building browsers. And it's just, it's always been so incredible what people can do with the platform. And as the platform has gotten more powerful, we really see what the future of computing looks like. So I'm excited to be along for that, right? Hi, everyone, my name is Parisa Tabriz and I'm currently responsible for the Chrome browser product, engineering and design team. I've worked on Chrome for about eight years and first joins to head up the Chrome security team. And so care really deeply about security, privacy and in general building great experiences for users and developers on the open web. And I'm Chris Harrelson. I'm a software engineer on the Chrome team. I've been here on the team for about eight years. I lead the rendering team, which is the team that does how you turn HTML into pixels and that the rendering NG effort is one of the things that I was helping to lead. I'm also a Blink API owner and I think I haven't been working on the web since as long as the two bends, but I've been using the web since the beginning and I love it. And I hope that it gets better over time. Thanks. Thank you all for those intros and for being here. As I mentioned earlier, some of these questions are pretty spicy. So I think it'll be fun to just dive in and get started with some of the spiciest ones. So our first question is around privacy initiatives and some recent news headlines. And this comes from Jeremy Keith who asks, given the core proceedings against AMP, why should anyone trust Flock or any other Google initiative ostensibly focused on privacy? And for those who aren't aware, Flock is Google solution for ads without third party cookies and individual tracking. Yeah, you and I can take this. So first off, can't comment on the AMP legal proceedings of course, but yeah, speaking about Flock, Flock as you probably know is part of this broader initiative that we call the Privacy Sandbox. And I think it's important to note that we're not asking for blind trust with the sandbox effort. Instead, we're working in the open, which means that we're sharing our ideas while they're in an early phase. We're sharing specific API proposals and then we're sharing our code out in the open and running experiments in the open. And in this process, we're also working really closely with industry regulators. You may have seen the agreement that we announced earlier this year, jointly with the UK's competitions market authority regulator, the CMA. And we have a bunch of other industry collaborators that are working with us. So we'll continue to be very transparent moving forward, both in terms of how the sandbox works and it's resulting privacy properties. And we expect the effort will be judged on that basis. Thanks. Yeah, thank you. So we also had a lot of questions around AMP and Chrome's plans for it. And these were some of the top voted questions that we got on the slide though. So could you also speak a little bit about what the feature status of AMP looks like? I think I could take this one too, Yuna. From the Chrome team's perspective, we view AMP as an important part of the web framework ecosystem as a peer to other popular web frameworks and we'll continue to support the developers that choose to use it. I also wanna highlight though, one of our goals with the web vitals initiative is to make it easier for developers to understand how to achieve things like fast perceived page load times and stable page layouts regardless of the web framework that they choose to use and to align Google search with those guidelines. And this was based on feedback from developers based on AMP and the role that it plays in the ecosystem. Yeah, so another thing that we've seen headlines about recently is Photoshop, another Adobe design programs in the browser. And as somebody who works in UI, this has been so cool to see all these integrations. But we have an anonymous question here. It says, it's great to see Photoshop on the web, but isn't this just another example of a Chrome only web? Why doesn't this work in Firefox and other browsers? Maybe you could speak to this? Yeah, I'd love to speak to this one. And I think this is an important question. So thanks for asking it. But as we look at the way that the web evolves and the way the web has evolved over the course of history, it's actually relatively rare for APIs to emerge simultaneously in old browsers. And so part of the process that we undergo as we work forward on building the future of the web with the community is to try things out, to experiment, understand that we will iterate. Ben mentioned this before when talking about the Sandbox APIs. But we do all of this very much in open. And we wanna just get out there with some ideas. And with the Photoshop launch, you can really see what's possible when we build together a more powerful web. And so I'm fully anticipating that we will continue to iterate on these APIs. We really welcome cross browser dialogue on the shape of those APIs. We anticipate making changes to them as you figure out ways to make them a durable part and ultimately for them to become standards. So yeah, that's our view, a very open process, a very collaborative process, but it starts here. I also just wanna jump in and add that Adobe has publicly shared their intent to bring Photoshop to more browsers and is working hard with other browser vendors. And also note that a recent tech preview of a future Safari release included support for the File System Access API, which is one of the APIs that Adobe needs. That's great to hear. So just in general, is browser diversity important to you all? I think I can take that one. This is a topic that is near and dear to my heart, so I appreciate the question. The short answer is that browser diversity is actually quite important because the web is an open, interoperable and universal platform. And browser diversity is part of what makes that stay the way it is going forward. Competition paired with a commitment to interop is also a good thing. As it helps to make sure that the web stays and keeps getting better over time through those operations. And this is actually one reason we also have efforts like the one that Compat 2021, which was mentioned earlier, in order to increase the interoperability of browsers going forward. And actually, I have even more good news to share, which is that the score for Safari on Compat 2021 has increased since we created the slides for the keynote from 85 to 92. So progress is really fast. Wow, that's awesome to hear. As somebody who builds the web and runs into interop issues, it's been great to see browsers working together to get some of these key APIs normalized so developers can use them faster. Yeah, I was just gonna add to what Chris said or maybe emphasize it because he said it, but I also feel like competition is just so important for innovation. And so even though most of my time is very much thinking about how we can build the best Chrome browser and Chrome browser experience, I really think that it's exciting to see how many browsers are sort of emerging and what innovation comes from that. And so I'll chime in as well to say, I think it's pretty important. Yeah, I love that sentiment about innovating and also working together to bring a better web to everyone, that's definitely key. So, Carissa, I have a question for you here. This is just around the review process for extensions in the Chrome web app store. There are some complaints, but it's rather long, it takes a week or more. What steps are you implementing to reduce the review time? Good question and feedback. Thank you for the feedback on that. So the whole developer experience for extensions is super top of mind for us and for sure the review process is one piece of that. We continue to invest in it and try to improve our policies, clarify those policies and also make our review process more efficient. And something me and my team look at are kind of mean and median review time and sort of what's happening at sort of the exceptional spaces. So I know over the past year, we've actually been able to review the average review time for submitted extensions to where now even pretty complex extensions are reviewed and approved in a couple of business days. And I think we're always trying to improve that. And at the same time, make sure that we are really keeping the quality bar and the safety bar and the privacy bar really high for extensions so that end users can have confidence that something they get from the web store is really high quality. And so thanks for the feedback. We continue to work on it. Proud of the team's progress in making things more efficient, but of course there's always constantly trying to improve that experience. Yeah, thanks, Marisa. So we saw on the keynote that there are a lot of awesome features launching and we got a live question in from Ronier on Slido with all of these awesome features, the future of web browsers will be, will the future web browsers be in a place or a place IDEs? Could we develop our apps maybe 80 or 90% entirely in the browser? Is that something that you see? Happy to take this. I've been enthusiastic about the web IDE space for a long time. I worked on a project doing this in the late 2000s at Mozilla. I think we're seeing the capabilities of the web expand dramatically. And moments like the Photoshop preview we talked about and so many of the other powerful apps that are on the platform showcase what's possible. I don't know that it's about replacing conventional desktop IDEs. I think there's room for a lot of different approaches but I would expect in the coming years to see more and more people able to do their full development cycles using the pure web-based IDE. And I'm really excited about that and I can't wait to see it. Yeah, I could definitely see that future becoming more and more of a reality as well. So speaking about browser diversity which is what we talked about a few questions ago, another popular question that we had was around mobile browsers. Remember, here's the question that comes from anonymous. Were iOS comprises more than 50% of devices? What's the future of the mobile web without real engine choice? How does one, how does the web stay competitive without Apple on board? Yeah, I can jump in and start to take this one. So on the Chrome team we think it's super important that browsers are responsive to the needs of their users and their developer community. And so that, for example, drives the investments that we make as a team. We work on performance because users tell us they want the browser, they want the web to be faster. Developers tell us that they want new APIs, new features, they want us to fix certain bugs and so we prioritize that. If you've been around for a while you'll remember an era on the web where innovation slowed down and even stopped. When there wasn't enough development on the browser, on the platform. And what got us out of that funk really was the ability for users to make choices about the experience that they wanna have. And so that's super powerful. Parisa talked about competition and why that's so important. We believe that super strongly. It's important that users have the choice and then across browsers we can think about how to make a better product for users and how to respond to our developer community effectively. So those are the principles that guide us. Yeah, I totally agree with what Ben had to say. I just wanted to add a couple more points. One is that I don't think iOS is 50% of devices worldwide. There's actually, I'm always surprised at the diversity of devices and platforms out there. But regardless, it's totally true that the Chrome team supports an open web and that's why we work extensively in the open to support the web success. And an important part of that is a diverse set of browsers across all platforms, including iOS. Definitely. So we also had a few questions about Manifest v3. And is Manifest v3 compatible with all versions of Chrome or at least which versions are covered? I can take this one. So Manifest v3 was available to use since Chrome 88. And so it should be compatible, all versions after that. We just shared an update on our timeline for deprecation away from Manifest v2 a month ago. And that's kind of gonna be a progress as we evolve the ecosystem, extension ecosystem, to Manifest v3, which has lots of security, privacy, performance updates. The faster people can move to Manifest v3, the better and so please do that at work where possible. And on all questions related to sort of extensions in Manifest v3, we have chromium-extensions at chromium.org as a really good place to engage with kind of all specifics. A follow up to that question, why is Manifest v3 taking so long? Yeah, so I touched on it just like a little bit, but it's been important for us as always when you make these big changes to really listen to the developer community and get their feedback on improvements, get their feedback on what's working or what they need. And so part of the reason this transition has taken a while is really to make sure that we're hearing all those voices acting on that feedback and giving developers time to make these updates because we don't want to break a ton of extensions who are on Stull v2. And so I would love to go faster but also because there's just a ton of improvements in Manifest v3 and at the same time recognize we have to be thoughtful, especially in sort of complex times to make sure that people have the time and space to make the updates they need to their extensions. And so I'm also eager, thank you for the question. And one of the things we're committed to doing is to just really keep providing updates on timelines because we will deprecate v2 and want to just make sure we can do it in a minimally breaking way. Yeah, thanks Parisa. I really like this next question, it's a little bit more general. What are some examples of proposed web platform features that the Chrome team has declined to implement and what went into that decision? I think I can take this one and apologies in advance that my answer is a little bit long but I think it's because it's a complicated question. So as I mentioned in the beginning, I'm one of the, I'm the lead Blink API owner which means that I work to help approve shipping new features in Chromium. So let me tell you about how that works and how it differs from Chrome. So Chromium and Chrome are not the same thing. Chromium is an open source project with contributors from many companies such, you know, across the board such as Microsoft, Igalia, Opera, Samsung and so on. Chrome is Google's product that is built mostly on Chromium and the distinction is important for questions like this because when we implement a feature, the feature goes into the open source project whereas Chrome is like a shift product that builds upon that code base but could potentially have differences where we flagged features on and off. So let me give you a couple of examples of features where Chrome decided at the moment at the time or at the moment that it wasn't the top priority to implement a feature but it was implemented anyway because someone else contributed it. One example is MathML which will when it ships hopefully sometime soon will allow all websites to have easy to express mathematics and that one was actually contributed by Igalia. So while Chrome didn't feel like it was a top priority to implement that relative to other features at the moment the code was reviewed and it was added to Chrome. Another example is the request storage API a recent one that Microsoft is implementing. Again, that's being implemented in Chromium and there are also a few cases where the Chromium owners meaning like the code owners, the people who try to make sure that the code base is high quality and sustainable over time have decided that there's too much complexity and that it would be too much of a difficult feature to implement at this time or as designed. And one of those examples is CSS regions which is one that was proposed a number of years ago and was ultimately removed from Chromium. So after features implemented it may be shipped in Chromium which means that we go through this Blink API owner process and then we turn it on by default as long and that is done as long as it meets the requirements of building towards a standard based open interoperable web platform via consensus specifications. And that process as I mentioned is mediated by the Blink intent process and the API owners. However, Chromium based browsers like Chrome, Edge, Opera, Samsung internet and so on can and do actually flag features on and off which are in Chromium by default. So hopefully all of that long-winded explanation helped explain our point of view towards Chromium and Chrome. Thank you. Anyone else want to talk about features? Residentship? All right, well, we have a live question actually that builds on to this from the other side of the coin about specific features that maybe you can also answer from Chris. Are you planning to implement CSS subgrid? Firefox is currently the only browser that supports it. Aha, this is another good one. So subgrid was, so originally the grid implementation was contributed by Igalia also. As you can see Igalia is actually a really important contributor to Chromium and that was added to Chromium because we just didn't have the staffing to implement ourselves but now we've actually re-implemented it as part of the LayoutNG project which is part of rendering ng. And this new implementation is actually a much higher quality basis that we believe will be straightforward to add subgrid to. So that is actually starting implementation right now and it's being implemented by Microsoft contributors. Thank you. I'm very excited for that feature as well. So I have a question for you, Vengager. Is a place for an Android app compatibility still a priority for the Chrome OS team? Development seems to have slowed right down and the API level lags on phones. Or lags phones, sorry. This is from random Android dev. Yeah, no, it's still very much top of mind. Playlisting, for example, recently have improved support for billing with entrusted web activities. Trusted web activities also provide a really convenient way to encapsulate your PWA in an Android environment. So yeah, that has been and continues to be very much top of mind for the Chrome OS team. As a platform team, we are very much focused on trying to build a more powerful platform that enables cutting edge app experiences, especially on Chromebooks. Sometimes that has us working on the Android integrations, the playlisting components. Sometimes that's us working on advanced runtime technology or new web APIs, like some of the stuff that we've talked about with Adobe and so on. And so really, if there's something that you feel that we're missing, we encourage you to just reach out and let us know. Right. So we also got a few questions about Lighthouse and how benchmarking is handled inside it upon. This one comes from Adriano S. What's the plan with Lighthouse and the Moto G4 slash 3G connection benchmark? Is this device network combo still the global average after so many years? That's a good question. I can take that one. So yes, it actually is. And this is related to my kind of caveat point I added to a previous question about iOS, where actually there really is a really wide variety of devices and it is true as far as we can tell that a device similar to Moto G4 3G in its capabilities is representative of the global average. So that's why we have it in Lighthouse. And if we see that change through our analytic data, we will definitely update Lighthouse accordingly. And just this is a good reminder that there is a tremendous amount of diversity of devices and network speeds out there. So it's really important to make sure your site performs well on as many as you can. Thank you. Another benchmarking question is about time to first site. This one comes from Walter Lee. How do you count time to first site in crux? For example, if the site has many elements inside of it, you just count the first HTML time to first site or average it all out. Yeah, the core web vitals are quite complicated and subtle areas. So this is a really good question to dig into. So time to first byte, sometimes called TDFB, means the time from when the user requested navigation to a site until we get the first bytes off the network. So it's actually even before we parse the HTML. It's when they get the first bytes back into the Chrome browser. And another point to make is that this covers just the main page resource and not sub-resources such as images. Okay, thank you. So we had another popular question that's a bit more broad, but this question is, how deeply will Chrome be integrated with other Google projects? I can talk about this one a little bit. It's a great question. It is hard to add in the abstract, but when we think about Chrome, it's Google's browser, Chromium browser. And we try to bring the best browser by Google as sort of like a high level of what we think we're trying to achieve. For me, it always goes back to like, what are the key user jobs or user journeys or developer jobs that we're trying to serve with a browser? Search is a huge one for a web browser, doing complex work, whether that's research or learning or kind of, in my case, doing work across many different tabs with collaborative docs and email. So complex journeys, shopping, we think about seeking out information and consuming it and that can be like entertainment or kind of long form reading. And so we always go back to like, what are the user journeys? We are trying to solve and then we have this amazing Chromium project to build a browser on and a lot of other things at Google. Search is the one that usually comes to mind and like as search is innovating and continuing to evolve how that technology and those products can work, we think about like, how can we really bring that to Chrome? So earlier this year, we announced that we're bringing Lens, which is a visual way of doing search into Chrome and we think that that can actually be really useful for shopping or other user journeys where visual search as a new input modality than just sort of text input can be important. And so there's not like a specific number or proportion I can talk about, like where we think about bringing Google innovation and technology to Chrome, but it's something we're constantly thinking about related to search and shopping. For me, security is also on top of mind and safe browsing is a Google security technology that we integrate deeply into Chrome to protect people from going to sites that will fish their data or install malware and integrating with the Google password manager so that we can actually make it easier to generate strong passwords and manage them and remove just some of the hard edges and insecure properties of passwords today is something we're working on. And so, other security and privacy features as well as just kind of a whole host of things, but always rooted in how we think we can improve the user experience and with an eye towards kind of other great things that are happening in Google that we can bring to the product more so than any specific number or metric. Yeah, I love that. So, on that thread, speaking of user journeys and user requests, we got a question from EmTom. Is anyone on the Chrome team looking at building and implementing a Web SQL 2 spec? If not, can we formally request or get involved? You and I can take this. So we've learned a lot over the years through Web SQL and IndexedDB and just in general, our efforts to build and structured storage into the browser. We're investing our efforts now into something called the Storage Foundation API and this enables JavaScript developers or of assembly developers to implement high performance file IO directly on the Web platform itself. And when you look at the challenges involved in having a browser own and maintain a sophisticated storage system like a SQL engine and to keep it optimized and bug-free over time, we think enabling this at the library level makes a lot of sense. And I'm really excited to see what the ecosystem builds on this. Yeah, cool. So this is another live question. This one comes from Stacey via Slido. Stacey says, hi, I made my own website through WordPress. Awesome. What are the most important things I need to do to make user experience the best it can be? Actually, I have just one thing to say on this. First of all, we love WordPress. We have a WordPress plugin that we create called SiteKit and SiteKit has our best guidance and utilities baked right into it. So all you have to do is search for Google SiteKit and take a look. Nice. Any other tips on UX? Don't have a huge number of UX tips. I do think Core Web Vitals is a huge part of our guidance here and SiteKit makes it really easy to measure your site on Core Web Vitals and to get concrete tips on how you can improve Core Web Vitals scores. That's a great starting point. Yeah, data-driven UX right there. So here's another question from Nicholas Mendiz. I haven't heard about the Portals API for a while. Is it being abandoned in favor of the Web Transitions API? Maybe, Chris, you have the answer for this one. Sure, yeah. Actually, do you have a lot of context on that because I'm one of the people who's helping to develop this shared element transitions API that I think is what the question is referring to. So Portals is not abandoned. We actually prototyped it in Chrome, yum. And we discovered that actually, while it's a great feature and it has a lot of promise, in order to implement it in a secure, private and reliable way, we actually needed to invest a bit more in the underlying technology. Basically, by underlying technology, I just mean like the code in Chromium needed to be refactored in a lot of ways so that we could support showing render processes and web tabs in this new mode that is different from Portals to other things. So actually, it turns out that same underlying technology will power not just this feature, but things like pre-rendering, another feature that we're working on, Back Forward Cache and Privacy Sandbox Features. So we're doing all that investment right now, but it's gonna take a while to complete. In the meantime, we're investing in approaches that improve the user experience over time, but are like a little bit simpler and like perhaps easier to, or hopefully very easy to adopt in shared element transitions, which if you don't know of it is about like allowing nice animations to occur automatically during page transitions for MPAs and SPAs. So we're doing that and we think that it will pair well in the future with Portals when we're done with that infrastructure upgrade. Thank you, Chris. So this next question is a little bit meta, but we've been talking about this idea, the web platform. This question asks, how do you define the web platform and how has that definition evolved over time? Okay, I could start with an attempted answer. First of all, it's a bit tricky to define because the web is not just APIs and it's not just browsers because like if you just have a browser, but there are no websites and there are no servers to serve content, what's the point of the browser? So if there's an ecosystem here of like there's interdependent websites, their ecosystem affecting products of many kinds like frameworks and the search engines themselves. So all of this together is like what we think of as the web platform overall. However, at its core, of course, there is a system of open and interoperable browser and client-side APIs that the whole thing is built on and allows different parties and companies to interoperate smoothly with each other. And so I don't think that particular definition has changed over time, which by the way, I would say is an amazing testament to the quality of the original idea of the web. Pretty amazing idea. But it is true that these APIs are constantly improving and increasing and the capabilities of websites are increasing over time. So in that sense, the web ecosystem is growing and defining its new roles in many new ways. For example, the IDE question, like 20 years ago, it was like web IDE, okay, maybe in the future, but now it's a reality. So that's my answer. Yeah, I just want to build on that if that's all right. I agree with Chris's definition. I think it's similar to how, believe it or not, how we think about the body in a sense because when you experience life, like where do your sort of cells and your DNA end and where does the role of bacteria that you're a host for begin? And I kind of think of the web platform similarly because it's emergent based on all the browsers that are available and that people are using and the libraries that they're using on top of it and the frameworks that are used on top of that and the third-party services that are incorporated into the web experience and all of this goes into what I really think is meant by the web platform and how users experience the web platform. It's a fantastic, open, organic and constantly evolving platform. And I'll just, oh, sorry, I just thought I'd add one really quick point, which is that, like Ben, but something you said triggered something in my mind that I think is important to mention that on the Chrome web platform team, we really think beyond just Chrome, which is why we're talking about core web vitals for sites generally, which is why we're talking about compact 21 scores across browsers. Because while the main thing we're doing is building and shipping a browser, the whole ecosystem is much larger than that. I'll add on, I've used the term beautiful chaos to describe all of the innovation and activity that started in the 1990s and has been exploding since. And I think Chris is right. There's some things that are static. There's some fundamental principles, properties that were baked into the platform from the beginning. Things like openness, things like low friction discovery, things like reach, when you have multiple user agents implementing that set of open standards, those are all really powerful things. As we look at the platform, we're trying to find ways to understand those, reveal them more, to emphasize them more and help developers build amazing experiences. And so I would really say, as we look forward, understand what those fundamentals of the web are and then like, where do you want the web to go? Like, this is for the developer community. This is for the community around the web to decide and chart that course. You know, I have a sort of reaction. Sometimes I see these people pontificating along the lines of, oh, hey, the web should only be about this one thing. Maybe it's only a document viewer. It shouldn't be about apps. Well, you know, ever since the advent of web mail and search, you know, we've had services and application experiences on the web. So I don't think you can really say it's not about those things because it is. And so like, as developers, just like continue to step forward, contribute, share your ideas, share your experiences, let's continue to make this a super awesome platform. Yeah, it's been amazing to see how far the web has evolved while staying true to its principles. I thank you all for your answers. This is great. We got a question from Simon Bloom. Are there plans to reduce the numerous and repeated permission prompts for PWAs and progressive web apps? Permissions should be grouped and remembered for installed PWAs. Question and feedback. Yeah, sure, I can jump in on this one as well. I know that, you know, we're still, you know, as we've added like a number of really exciting, powerful capabilities to the web, we do feel a bit of attention around both the demand to add those capabilities and like how do we explain these reasonably to the people that are using the software? And how do we make sure that we don't overwhelm them with too many requests and so on? The challenge here is really finding the right settings on the dial of like how much to show. You know, we could say, well, just ask when it's appropriate. Well, what does that mean? Like this is something where we are actively studying like what for certain capabilities, when is the right time to ask, what does that look like? And so we're doing, you know, like instrumentation analysis and study. It's a journey. It's something where I feel like we will make progress, you know, over the next, you know, year or so. But it's definitely a hard problem, but something that's top of mind for us. Thank you. There's also a few questions coming in asking around, you know, why can't we put PWAs in a Play Store similar to what we see Microsoft doing with Windows? And here's a question that says a couple of years ago, Jake asked this very panel, when are PWAs going to be listed in the Play Store? When are PWAs going to be listed in the Play Store? I'll take this. Benji spoke to this a little bit earlier but the other Benji, you know, this is a complex space in my view because you've got the stores which are owned and operated distribution channels with policies that they have for the content that's in them. And then you've got the open web, which is open and available to all. And so marrying those two is tricky. And we have technology, we call trusted web activities or TWA, which enables developers to distribute their web content in the Google Play Store on Android and also on Chrome OS. And we have tools like Bubblewrap that make that process streamlined and relatively simple. And this is currently our approach. Appreciate feedback. And we're constantly listening to developers and looking at ecosystem developments and evaluating our stance. Nothing new to add. Thank you. We got a live question here about CSSFooding APIs. When will the CSSFooding APIs for layout, parser and font metrics be ready to use in Chrome? Chris? Sure, I can answer that question. For layout, we actually decided that we could not properly implement and ship the layout API until layout ng was done. So as I mentioned in my rendering ng blog post, layout ng is coming to a close now-ish. It's actually probably going to take until a little bit next year. And after that, we're going to come back to the layout API. And the other two were font and, what was the other one, Yuna? The other one was parser and font metrics. Okay. Layout parser font metrics. So for font metrics, we've been gradually introducing additional font metrics directly into the platform. And I'm not, I don't think there's a particular plan for a parser or DD API. Okay, great. We had another question about cross-browser capabilities. Firefox and Safari are implementing privacy features like cross-site isolation. Why isn't Chrome doing the same? Maybe Parisa, you can have some insight on this. Sure. So let's see, digging into this question. Well, first, Chrome is super committed to advancing security and privacy on the open web. It's a personal area of commitment and something I'm really proud of. The work Chrome has done over the past decade plus and certainly there's lots more work to continue to do here. Both in the product and the platform. When it comes to site isolation, so Chrome launched site isolation which is a security feature a couple of years ago. And that advances protections via sandboxing at the site level. I'm not sure if that question is referring to that, but that's something that we're seeing other browsers actually pick up. Now in the privacy space, and perhaps this question was talking about privacy and anti-tracking, we're seeing also innovation and different approaches to combating this problem. Chrome has a privacy sandbox effort. And what this is is a collection of APIs and features that are all intended to advance privacy on the open web, but also ensure that we're supporting really vital use cases for developers in particular. And a bunch of features, you can read more about it at privacysandbox.com and I know we have some sessions on that at Chrome Dev Summit. Just one feature that I know is an active development is called fenced frames. And what that is is it's a type of eye frame that is more privacy protected from the actual containing page. So that's just one example, but broadly we invest a ton in this space and very much depend on kind of feedback from developers to make sure that we're advancing things in the right way. And also your support in deprecating APIs and technologies that we think have been replaced by improved APIs too. And so thanks for the question and look forward to kind of continuing to work together on improving privacy on the open web. Thank you. Our next question comes from Lauren. Do you feel the move from web fundamentals like vanilla development towards external ecosystems as React is concerning? How many turtles must we stack? I can start with trying to give an answer. It's a good question because there are so many frameworks, so many libraries out there. And then as we've mentioned throughout CDS this year, there are tons of new web APIs too. So from my point of view, if you're using a library or framework and it helps your web app perform well and succeed, that's great, like success and a useful website is really the most important thing. That being said, the more turtles there are, the more complicated it is to make all the turtles not fall off of each other. And there are definitely performance challenges that are inherent to loading and executing more scripts because the more bytes that you download, the more JavaScript you're running, the more that VA has to figure out how to run it quickly. So less is better, all things being equal. That's a key point, all things being equal. The library adds a lot of value, that's great. So however, we're undergoing a continuous process of identifying the common things that a ton of sites wanna do. And if a lot of sites wanna do a thing, then we should consider adding it as a web API or whatever that thing might be. And so over time, we might add more web APIs and then that would reduce the need to download additional JavaScript to do that same thing. So I just wanna pick up and add to what Chris was saying because I think it's a really fundamental strength of the web platform and the web ecosystem that we have this constant innovation in the frameworks and libraries that are available to build. And it can seem a little exhausting sometimes because every time I turn it around, there's like some new approach. But at the same time, I think this pushes the platform forward in a powerful way. And Chris was talking about what I think is the spectrum that we've been facing in computer science and software development from the very beginning, which is developer ergonomics on one side and runtime efficiency or performance on the other. And it's not really clear to me that there's an objectively right place to be in that spectrum. I think it's a very individual decision based on the teams and their goals. But what we are trying to do with the web vitals program is provide objective guidance to the ecosystem on what makes a really high quality web experience for users and to let developers measure their experience regardless of the framework they use and then make their own decisions. Yeah, thank you. So we are coming to the end of our session and I want to make sure that everyone who's watching this session leaves with some next step. So I wanna ask all of you, maybe we can go in order starting from Ben Galbraith over to Chris. If developers have a spare hour after the session, what should they go and look at whether it's a feature API or article or even something else? Yeah, thanks, Yuna. And this has come up a bunch, but I'm a big UI geek. I've been building user interfaces with a variety of stacks for most of my career. And so I am beyond enthusiastic about the Rendering NG project and everything that's been unlocked through it. So I'd encourage you to look at a series of blog posts that our own Chris on this panel made about Rendering NG. And also Yuna did a great job of talking about what she and others call this new responsive, which is rethinking how we build web UIs based on these new primitives. And I encourage you to study both her remarks earlier this morning and also broader videos and talks that she's done and others have done because there's so much that's possible in the web now from a UI perspective. And it's really exciting to see. Yeah, thank you. Yeah, and plus one to all of that, that's super exciting. I would say that, across the content that you see here with Chrome Dev Summit, as well as everything else that you can read about the powerful capabilities that the platform has grown over the years, what I would say is like, as you reflect on, for example, the Photoshop demo that you saw before, the Kapoing demo that was in the keynote, there's this really powerful thing that comes when we take our conventional idea of what an app is, and then we marry that to this idea of frictionless discovery and distribution through the web, through links, through URLs. And so I would, without saying like a specific API, I would just say like, think about the where the web is now, all of the amazing capabilities that it has across UI, across runtime performance and APIs and so on. How can we make truly special experiences that are easily shareable that bring people together? That is, I think the thing that I am most excited about. Right now it's a unique strength of the web. And so I'd encourage you to think about that. Yeah. Oh, lots of things. So hard to pick one. I think if BGulbs or Ben Galbraith is a UI geek, I'm probably a security geek. And so maybe really tactical would be to check out the issues tab on Chrome Dev Tools in the security panel. And it's so important to fix these issues because I think, you know, Ben Goodger talked about like evolving the platform and pushing it forward. And part of that is really making sure that we can not get kind of held back by legacy. And part of that is really like graceful deprecation and pushing things forward. And so it's been amazing to see, for example, the push towards HTTPS adoption. And we have like an HTTPS first mode and more tools for developers to like fix those issues. But I would say check out the issues tab in DevTools security panel. And you know, if you have no issues, then that's a very quick call to action. And if you do have issues, then maybe that gives you some things to focus on fixing and addressing. Thank you. Cool. And if you don't mind a self plug, the feature I'd like you to go check out is called content visibility. And I'm actually the one who kind of came up with and led this project. So I might be a little bit biased, but I think it's a super cool and very powerful CSS property that allows you to make it easy to help the browser only spend time rendering what's on the screen, not the size of the document. So please try it out and let me know what you think. Yeah, content visibility is definitely very cool. There's a web.dev post that I may or may not have written about it. So thank you so much everyone. Thank you so much our leadership panel here of Ben Govres, Ben Goodger, Prisa and Chris. This is definitely a very fun discussion with some of those spicy questions mixed in. And thank you everyone who submitted questions. We have a lot of great content for you throughout this week and the coming weeks in our virtual 2021 Chrome Dev Summit. So if your question didn't get answered, definitely sign up for some learning lounges workshops and office hours for more one-on-one time. I'll be hosting office hours and learning lounges too. The schedule is live at developer.com.com. So thank you again everyone who joined me today and we'll see you online.