 So I'm Felix. I'm a WordPress core committer and I'm a developer programs engineer at the content experience team at Google where we collaborate with content management systems like WordPress to improve user experience on the web and advance and advocate for modern web technologies We are also essentially the WordPress team at Google, which you might have heard about before and In this session, we will look at two rather new browser APIs that grant you more control over how certain features Act on your site to enforce solid user experience and best practices so The web has obviously been constantly evolving over all these years We've seen great features being introduced like responsive images age X requests Yeah, I know these two have been long around But imagine at some point they were really big features that were introduced We have location access you can now add your sites to home screen, especially on your phones We have web payments, which are a standardized way to process payments on the web and there are Probably hundreds more of new features of features that are constantly being introduced to the web and these features all of them are certainly great and powerful but when used Incorrectly or when used over aggressively or when completely abused they can seriously harm user experience So Well web features being used in the wild. You might have seen something like this Maybe here. There's a slow loading image Coming up coming up There's oh, you can add this to your home screen Nice. Well, it also wants your location access And it also wants to access your cameras because why not? So I'm sure you've seen examples of these sites around I made this up. It's not actually my website is not that bad So as you can see this can happen if you just randomly use all features that are available without actually Thinking about how they impact user experience and whether this would provide enough benefit to do that So we have all these cool new features But how do we use them responsibly and this can especially become a problem in WordPress where you deal with so much third party code and Think about it further you yourself. You might be responsible citizen of the web You might know what you're doing But all the third party code that you use might not it might have flaws It might misuse features in ways that you aren't even aware of and This is where a new API a new browser standard feature policy comes into place So this is a proposed web standard on you can see you can read more about it on W3C website and This standard it grants you control of our certain features behave on your site So that you can so in so that you can enforce solid standards throughout As an example Imagine you installed a Google Maps plugin on your website just to display a map Maybe but then the plug-in suddenly asks the user for their location Which is something you didn't you weren't even aware of when installing the plug-in. You just wanted to display a map So by default if that happens in the third party code that pop-up it would just show possibly possibly Make the user experience worse because maybe the user doesn't get any anything real out of it. That's valuable to them so By default it shows up, but with feature policy you can send a Response header like this which would completely disable the feature on your entire website ensuring that this cannot happen Basically, it would just say the gearchs location service failed Which isn't maybe that great either but generally it would it's a good start to enforce Best practices for this of course sometimes you would want to want this to actually show up So then don't use it But this is for controlling third party code to do things in the way you want them to For every feature you can control basically how and where it is allowed For example, if you specified any here instead of none, which is the default it would be allowed everywhere You can define self which about means it will only allow it on your own site But not on other sites sites for example in iframes from third parties Or you use none, which is just a super aggressive. No, don't use this ever And even you can specify specific origins like specific domains. You want to allow this on or not Another example is This we are nice image Imagine you look at this image in a mobile phone, but it's actually sized for a large desktop You can over you can disallow using over sized images in this case This would show up so it wouldn't so the image wouldn't load and this is especially useful for development Of course on a production site, it would be still better to show this image than showing this But for development, this will easily allow you to spot weaknesses where you accidentally maybe forgot to optimize an image Feature policy can be used in production and development and it totally makes sense to apply different policies in the different environments And in production for example, you probably don't wouldn't want to do this But in production you can also set up the policy for over sized images to be in report only mode So it would allow it to be notified about the about the Violation of the policy, but it will not actually just disabled image So that leads us to the next big thing which is yes, I said It's also possible to monitor violations of feature policy, which I will get to in just a bit There are many many more features Supported by the feature policy specification You can control media so that it doesn't just autoplay when this user access your site You can enforce lazy loading across your entire website. Yes lazy loading is actually a standard That's coming natively to the web at some point You can disable synchronous Ajax requests, which we shouldn't be doing Camera access full screen and many many more there currently 11 features supported and 17 more come in So think about this further again feature policy is a very powerful ally, especially in WordPress where you deal with so much third-party code So looking at browser support the API is quite new And it's also still in draft is a proposed standard But it's already supported by a couple browsers as you can see here You can see the full stats on can I use comm? So as I mentioned before you can get you can get Reports of feature policy violations and this takes us to another new web standard, which is called the reporting API that standard allows you to receive reports about client-side errors or policy violations on your entire website and they will be automatically sent by the browser So several types of reports are reported here and feature policy violations are one of them as Well, this API relies on a new HTTP response order that you can send and we will look at what this looks like under the hood now So you can basically specify in this example You specify Did you tell the browser to send the To send reports to this URL which should then that that URL should host an endpoint of that follows the specification of the reporting API standard and Then all reports are going to be sent there as you can see This is an object and it's actually possible to specify multiple different groups with different endpoints And then you can allow different report types For example feature policy violation is just one of the possible report types to be sent to different groups depending So you can really granularly go with it But this basic example will make sure that every everything is sent to this one endpoint So there are a couple report types supported here as well. So we have content security policy You get crash and deprecation reports Which basically allow you to be notified when doing something wrong in JavaScript or when something wrong happens You're not even involved is right now Another super powerful feature is network error logging which it basically allows you to receive reports About network request failures. So if your site is down, for example So that is something you would previously needed to rely on an uptime service for but it's becoming possible With native web features and that native web APIs Well, I talked about feature policy right now. This is actually not supported yet, but it will be very soon So feature policy feature policy itself is reported is supported reporting API supported But they don't work together just yet, but that will be that will be introduced very soon Yeah, looking at browser support here. It's even more limited because the reporting API is even more bleeding edge. So It's only supported in Chrome right now, but given the Given the distribution of browsers and how much they used this still means 60% of about a little more than 60% of browsers throughout Are prepared for this and can use the reporting API standard Actually, this API is so bleeding edge that it doesn't even have stats on can I use comm yet? So I don't have a link here So, yeah, WordPress surely I wouldn't leave you here without looking at WordPress specifically so but it's probably better because that if you do it because We we built we have built as part of our as part of our goals to improve the user experience We have built plugins to introduce these new API APIs and bring them to the WordPress platform and The fragmentation of the WordPress ecosystem is provides a perfect scenario for using and applying feature policy and using the reporting API with it So you can start using these new API today and you don't need to even need to be a coder for that You don't need to write code. You can just manage all of this from your WP admin So this is the first one of them So the future policy plug-in it lets you control feature policy headers and it will take care of sending them in the front end and Yeah, that's basically all that this does for now and you can start using it It's now available in an early version 0.1 on wordpress.org and That plug-in is complemented by the reporting API plug-in Which you can also install they work without each other, but they also integrate with each other if you have both of them So the reporting API it provides an endpoint with using the WordPress REST API an Endpoint according to the reporting API standard and it also sends a header in the front end to make sure that all Headers that that all reports are sent to this API endpoint and as you can see here You can browse the received reports from your admin back in Yeah, and as with the feature policy plug-in this plug-in is now available in an early version on WordPress.org So wrapping up in addition to all the other links so far here's some further resources to learn more about these new APIs For real deep dive. I recommend looking at the actual w3c draft documents, but those are very very detailed so The first is especially the first three links here There are very great resources to get a quick understanding and an easy to understand way to learn about how these policies how these APIs work and And last but not least please make sure to use the plugins There as the APIs are in an early state the plugins are in an early state, but we wanted to get them out there early So we because we're closing we're working closely together with the w3c team That have been drafting these specifications and we would like to get your feedback. So and we can actually all Influence how these specifications come out when they're actually made completely a standard So let's join forces to make it easier to come back to create a compelling user experiences on the web That's it. Thank you