 Hi, my name is Steve Thayer, I run the London Web Performance user group, and I run web perf days in London, so performance of third-party scripts is a really big area for us, and we debate it endlessly. I'll quickly introduce you to the people on our panel. On my right, I've got the, well, if we're going to do a drug dealer analogy, these are the guys who are actually producing the stuff. We've got Ben Vinegar from Discus who had discussions and comments, you'll have seen many websites. We've got Stefanov from Facebook who is like buttons and all those kind of Facebook widgets that you like to put on your page, and over here we've got Guy Pogiani from Akimai who's sort of like the middleman, the distribution network for the stuff that they're dealing, and then we've got, I was going to say addict, but that's probably not right, we've got Barbara Berms from the Canadian Broadcasting Corporation. She's the kind of end user, this poor person that's having all of these scripts. She has to sort of deal with her customers, the people in the marketing team who never met a third-party script they didn't like, and they just want to stick all this stuff on the page, and she's got to deal with all of those issues. So we're going to kick off with a presentation from Stefan just to sort of set the scene on what third-party stuff means. Just remember obviously we've got the on-slide stuff, so you know, try and use that as much as you can, come in, give positive and negative feedback, give, and obviously put your hand up via on-slide if you want to talk. Thank you. Over the slide. Thank you, Steven. All right, so welcome to the third-party party, where we party like it's 1995, because in many ways it is 1995 when it comes to third-party widgets. So I'm hoping we can have a nice discussion on how to bring this party to today and tomorrow. Slide please. So Steven now did the same thing that I was planning to, so he stole my thunder of presenting the widget makers versus the consumers. I can only add that Steven is also on the off-site, he's also on Barbara's side, right? Protecting all the publishers from all the extravagance we put out there. All right, so just a quick overview. Third-party content comes mostly in form of script that you include on the page. It may not do anything visible like it may be something like Google Analytics. However, you put an iframe on the page coming from a third-party, or the state of the art seems to be that you do both. You include a script that writes an iframe for you. So that we focus, we want to talk more about how we deal with scripts and iframes. And yeah, you're including a JavaScript on the page coming from somewhere you don't know, you have no control over coming over the network. So what could possibly go wrong with that? Well, obviously, there's a security issue and Ben wanted to bring up a recent attack on OutBrain, which is a producer of the third-party recommendation engine. So it was attacked by Syrian Army folks who were able to mess with their JavaScript and in this way affect all the pages that use their service. So let's say, for example, they could redirect all the visitors to Washington Post to some other page. So I think if you're an attacker, if you're a malicious person, why would you try to break into all these websites where you can do your one-stop shopping and break into a third-party, which you'd provide and have control over so many websites, right? So security is obviously a big one. And then you have the spot for single point of failure where if a page includes a script synchronously, they add a single point of failure. And despite the fact that we have no good tools from Pat Menon's Pathomatic extension for Chrome, and also you were able to find spot in using web page test, but seems like that still tends to be an issue, which is pretty silly because if the third-party provider is blocked in a country or an enterprise, that means your site is effectively blocked as well, or black hole. And then there's all the performance issues, right? Anything you add on the page will add to the rendering time and loading time and all that. All right, so what is the state of the art of script includes? So despite all the evangelism for using asynchronous scripts, people still using script tags, and sometimes the widget providers on the marketing side will prefer that because it's easier. You just have one script tag instead of a little bit of code, so that's pretty bad. There's currently some things on the crazier side, like using frame-in-frame, loading a JavaScript inside of an iframe, or when you write an iframe, write it inside of another iframe. So the first iframe container is blank, so it's not in the way of the window-onload event. So this is for people who still care about the window-onload and whatever it happens. Not as easy or friendly to copy-paste, but it exists. Something else, so the thing about third-party JavaScript is they're notoriously being very short-lived, 10, 15 minutes, half an hour. The reason is so that the third-party provider can push fixes and security updates very quickly. But that's bad for performers, because we cannot use FFAR future Xpires header. So there's this technique of, again, using an iframe and reloading that iframe that causes the script to be refreshed. So you can have a third-party JavaScript with a FFAR future Xpires header. I don't know if anyone's doing it currently. SOSTA, all right. And then there's stuff that's coming up from the WebPerf W3C group, which I was hoping someone can enlighten us what's going on there with the progress, right? Next. Oh, yeah, there's this idea about what I call C3PO, or common third-party object. The thing is, so this is something I put up some time ago, and then Ben said that he's been thinking about the same thing, but we never really got to talk, so I think that's as good time as any. So the idea is that those scripts that are included from third parties usually do the same thing. They hunt the page for any hints where the iframe should go. So they look at the DOM, and then write an iframe, and then resize the iframe, because the content doesn't fit, let's say you have a light button in German, which is longer word, so you have to resize the iframe not to take more space than needed. And every, or a lot of widget providers are doing the same thing. So what if we can have one script that is open source and that handles this for most of the widgets? So this means that the publisher can include the script and package it however they want with their scripts and handle all the widgets, so we already downloaded five, six scripts with 100, 200K instead of having just zero requests. So that is the idea. Meanwhile, in what we have in near future coming up, so we have now web components. I don't know if anyone's using web components. If not, why not? It seems like the widgets are the best use case for web components. And I'm thinking is it an easier on the publisher side to include a web component instead of the current state where you include a div class, something in the script. There's the iframe sandbox. It's really cool. Should we encourage people to use it or not? What would you disallow in a third-party widget? So there was the idea of seamless iframes. Seems like it's not going anywhere or going away. The same with the frameSRC talk. I don't know what's the state of that. Is it dying as well? Paul, can you talk about this? It's just got a negative vote. Content security policy, it exists. It's out there. What should we do about it? Should we encourage people to use it? Providers as well as publishers. I'm curious to hear your thoughts. But meanwhile, what happens now, and Barbara can talk about this from the publisher's perspective. So she said that sites are now bombarded by scripts. There's too much stuff going on. And also, like Stephen said, challenging anyone to stand between the marketing people and their widgets. All right. So how do you monitor third-party widgets? Do people set up budgets and say, okay, you have this amount of time or K or, um, how do we keep the third parties in track? Also, how do we deal with some... Because not all the third-party code is very well written, right? So how do people deal with the scripts that have to do document right and so on? Guy brought a good question about the... According to the HTTP archive, the number of the main savery website is going up, is increasing. And it can be largely attributed to third parties. So what can we do to fix this? And he has some ideas, some borderline crazy, like copying cookies from one domain to the other, some maybe more manageable, like what if we use the same domain name for all the static resources as scripts and styles and the sprites and shared between all the third parties? So instead of loading something from Facebook, something, akamai.net, whatever, why don't we use something else, like common domain name, C3PO, comes to mind? I think it would be C3PO.akamai.com. Oh, mobile, right? It's finally here. What does it mean for widgets and to... Is it only just making performance issues even more visible, should we do something about it? Using mobile, using that many widgets on mobile websites? Are you curious to know? Yeah, I think that's all I had, and let's talk about all this stuff. Thanks very much, John. I'm just going to do a quick poll of the panel. Guy, any quick comments from the students opening the talk? Sure. Maybe I'll add a couple. One is, in general, third parties are a little bit broader than that. I think there's some bias to think about that every person has a bias, but there's also tracking beacons, which for some websites are plentiful and actually come in often in the form of an image, and there are also actually third party components that are more in line in your page, a sort of shopping cart personalization components and such that are, I guess, kind of start to tread the line, because while they're third party, they're not extraneous to the sort of core flow or requirement of the product, but there's still a concern and all sorts of things like number of domains and reliability concern, security concern is still very much valid for them. So that's one point, and then the second one is just to sort of highlight the aspect of the number of domains. There's basically the problems with third parties that have to do with best practices around how to use them, how to write them if you're an author of them, to try and get them out of the way as much as possible while still kind of keeping them reasonably fast. And there's also things that are just trends, like the number of domains or like the existence of unoptimized third party scripts that use document.write, whether you like it or not. And those are just paths that to me are more interesting because there's no clear, as far as I know, there's no good set to advance us in the right direction, to fix those. OK. So yeah, for me, I'm basically really in the middle of both. So I want to make sure that the developers understand what third party scripts really could do to your page. And also, yeah, the business, the business side to tell them what to look out for when asking third party providers to provide their code. So you're saying it's not really possible to tell the marketing department, they can't have that piece of code because it has a document.write in it, because they just won't understand. Exactly. You get to explain to them what the impact actually is. Yeah. And they don't always understand that. Cool. So Ben, as a provider, what would you say about still ends opening marks? I mean, they're really good comments. I think that, well, basically it's been set up that this whole panel is sort of like, if you're a website publisher, then third party scripts are mean, and we're villains, also, so yeah. But I want to flip this around. Maybe people aren't thinking that as a third party developer that has a pretty complex application that I'm serving to publisher pages, there are publishers that are doing really bad things to me. And I would love to talk about some of those. And what could, you know, what could I do? Yes. So I don't even mean that partially as a joke, but there's definitely, you know, it can be subjects like people immediately attribute performance issues to a third party script. That's the first place that they go, where I'm debugging publishers' websites, and then I attribute basically the performance problems back to them. So I'm sort of in a hard spot as well. And I think that's, I don't know, possibly worth discussing. Cool. I think we've actually got some couple of questions about how we can find and identify those sort of performance bottlenecks. But first question we've got from the floor is actually from Yoav Weiss. Yoav, are you down there? Hi. What are the mechanisms for enabling script loading based on media queries? And is there a valid proposal and how can we get this pushed? So this is the idea of if I've got a script that's just not relevant for the device that I'm running on, why am I downloading it in the first place? Exactly. It relates to the mobile thing. I mean, if I don't show a like button on mobile, why am I downloading the script? Do you want to start taking that one? I don't know. I'm not aware of any development, are you? Is there a proposal going on? I started playing around with the idea. It's kind of hard to define what happens when the media query changes. That's where if things get complicated, do I want to run the script or not? But in general, do you guys think it's a good idea or is it something that should be pursued? It definitely sounds interesting. I'm kind of fond of it. So I think the notion of conditional loading, especially in responsive design website is a real issue. And in responsive design, we focus on images like we spoke earlier. But maybe the next looming problem, if not already here, is the notion of scripts. And I regularly see responsive websites download, execute scripts, and then hide them. Because the layout doesn't quite make sense for them. So institutionalizing or standardizing conditional loading makes perfect sense to me. And using media queries seems like one way to do it. Not sure if there's any active conversations about it. So I guess we're probably going to figure out all the different options of it. But I do think that's a good path that we need to take down. I think also the idea is interesting, but I'm also wondering, so what are the use cases? So you would not load, for example, a Facebook button for mobile versus desktop or whatever? The use cases I can think of are Facebook button or social buttons in general, maps that may or may not be displayed because you want to go to the native map. And UI frameworks, where you want to load a jQuery mobile here and a jQuery UI there. These are the use cases I have in Twitter streams, I think are a common one in responsive design. Or even we're doing different ads serving for desktop versus mobile, for example, yeah. I've got a couple of comments from the floor. Carl Simpson from Gettify, did you have something to say on this topic? I didn't actually intend to click that, but I'll just say something, because I didn't have a question since they gave me the mic. Okay. It's your time. And that topic, though, so there is definitely a strong push to create declarative solutions like markup-only stuff. I need to be able to express all of my intent through markup, but I do just want to point out that there's a vast array of complex situations that you make these decisions on. For instance, I've got a simple version of a calendar widget and a complex version of a calendar widget. And I make decisions based upon bandwidth and screen size and all those other things. So I think it's troublesome to say this is a one-size-fits-all solution to try to encode into my markup when a script should be loaded. I feel I'm a little biased, but I feel that's the job of script loaders rather than markup. I think that's a valid statement, but there's also the statement to say that especially in responsive design world, there are a lot of decisions that are made based on things that could have been determined through screen properties. So maybe it's not 100 percent. You don't take away the capability or the value of loading things through a more elaborate script-based loading condition, but if it's a common enough use case and you can make it faster and easier, then I still think it's a worthy proposition. We've got David Stickman from Akamai who wants to make a comment. Feel free to disagree with Guy from Akamai. Let's just briefly. Hi. One of the most common use case we see is actually tons of new domain and people tend to do domain sharing thinking that it's going to improve the performance of the website, but obviously with third party, we have 40, 50 different domains that are called by the browser. Is there any way we can give a hint of what kind of DNS resolution should be done for third party content before actually loading the third party itself? Because there is a lot of bottleneck with just DNS resolution itself. Anyone? I can take that because I know that. So I think the number of domains, as I pointed out before, this has not been coordinated just to make sure, is a real problem. It comes into play in DNS. It comes into play with the fact that speedy and HTTP2 and all sorts of pending solutions don't touch on it. They don't try to optimize across domains. So I think it's a real problem. There is no deep prioritization, as far as I know, of third party content. You can kind of mark things beyond the async or the kind of processing aspects in the browser. You can mark something as slower or faster. So I think they contend for resources today, a part of it is about how do we optimize the number of domains, and today the only tools you have for deep prioritizing them is do things like async and such. We're going to come on to a later question, we're going to talk more about dependencies and execution time, but just to sort of stick with this, the original intent of this question was, in the earlier session we talked a lot about how you were going to do media queries to decide what image you want to download. Do we need a similar mechanism for scripts or not? I mean, if you were to put it to the audience on a vote, you'd say, yes, we need this mechanism or we don't need a mechanism for this and we can just move on. Is this a problem that you think I'm sending way too many third party JavaScripts to my? So we've got two votes, three votes, four votes, five votes. So we do think this is a problem that's not just Yo-F hitting the button five times. I have a federal account. And friends. I would just say that, I mean, we experience that people are conditionally loading our application, usually doing templates or JavaScript or whatever already. So, I mean, if they're, if that can just be a really nice declarative way of doing that as opposed to setting up, you know, JavaScript code, I don't see the problem with that. People are doing it already, I guess is what I'm trying to say. But whatever the developer wants to do, if it's easier for them, and if media queries enhance the performance as well in loading things, I think, yeah, if you make it easy for them to use that as a publisher again, then that's cool. I will say it's not just third party though. So conditional loading of JavaScript on a responsive website is broader. Third parties are a specific case of it. Okay. So let's go on to the second question. We've got Tom Bouchoch. So this one came in anonymously as well. The WhatWG has proposed a solution for managing script dependencies and execution time. Will this solve the performance and blocking use cases? And Kyle, I believe, actually is part of that proposal, so maybe he'll have some helpful input as well. Okay. So this is sort of, as I understand it's related, there are a lot of hacky ways people download scripts as comments and then, you know, add them dynamically to the page when they need them. There's a lot of hacks out there that are people doing to get around the async and the blocking nature of the scripts. So, you know, what's happening with the working groups and what's the best solution for this? I am not familiar with this topic. Anyone from the audience who wants to take it? I can give a little starting and then maybe we'll switch to Kyle. So I think there's a few things there. There's one in kind of called resource priorities that has to do with enabling a lazy load and defer attributes and more objects. Those are actually probably further along on scripts than they are on some other components. But there's some promise there. I think there's still a lot of debates and I heard some comments in a previous conversation today on possible paths, but I think there's still a hole around how do you manage groups of dependencies so that you want to say the script needs to run after the other, but both of them combined should be asynchronous. There's things around association of on-load, triggering the on-load event, and an async script because an async script today will still delay the on-load. So I think on the loading process there are some good actions. On the grouping and such, I would find them very promising, but I don't know if they're very far along. So since my name was brought up, I will speak up. Yeah, so two or three years ago there was some proposals. Nicholas Zekis and I kind of joined together and made some proposals on what we call script pre-loading. So the idea of loading a script but it not automatically executing the way normal scripts do, and then being able to programmatically control when that script might load. And that has gone through a whole bunch of starts and stops and restarts over the last three years. Most recently, about a month ago, it started back up. It turns out there's several different things and maybe Jake Archibald can also chime in. So there's some stuff with navigation controller, and then there's discussions about other use cases that that might not handle. I don't think I would classify us as far along in terms of implementation, but there has been an enormous amount of discussion about it and developers do want, I think, more control over it. There's one side which is I want control in the markup, again, back to this declarative versus programmatic control, and I think that's really one of the big sticking points so far. Okay. Jake, did you want to say anything since you got called out? Yeah, I think the worst thing we've got with script loading at the moment is if you want to load a series of scripts without blocking rendering or blocking any of the computing, but maintain the order of execution, we don't have that unless you use JavaScript, and we don't want to use JavaScript for script loading because then you lose the preloader, and the preloader can, you know, you can boost getting to DOM content loaded by 20%. So we want something in the markup that can dictate which order that script will be executed and then load them asynchronously. Just specifically related to third-party, I do think there is another barrier which is document.write. So when you're using a third-party, when you're a publisher and you're using a third-party, you need to sort of be absolutely confident 100% that that script would never, ever use document.write if you're including them as an asynchronous component, otherwise that can markup your entire page. And as far as I know, there is no work going on right now, but there definitely should be on doing something like that, heck, even something like just ignoring the document.write in many cases would be better than blanking out the page and writing only that piece instead of the entire page. But ideally, there's something a little bit more elaborate than that after the fact, write content in those sections. Okay, so, let's see, Wilson's got his, Wilson Page from FT Labs has got his hand up to sort of comment on this topic. Hopefully. Hello. As a web app developer, I like to have control over my resources. So, wouldn't it be possible that third parties like Discuss might let me bundle those resources, their third-party scripts into my JS bundle or other assets like CSS? I mean, I can see why you wouldn't want that because you want control. I mean, you want the control to be able to update when you want it updated, but I also don't want 100 HTTP requests going off on my page. Yeah, oh, man, my eyes on me here. On some level, I mean, I'm a web developer too. Yeah, I hope so. And I totally, I would like to do that, sort of makes sense, but you basically just hit the other end of it, which is, we're just changing things at such a rapid pace that for somebody to bundle it and serve it from their own servers or whatever is just like, we can't do it. And this actually touches a little bit on some of the C3PO stuff, which is if there is just the idea that if we had like a common library that ran on your host page and then you could bundle that part and then the stuff inside of the frames could then do whatever they wanted and you at least got that much out of it. Even on that point, I could just, you know, inevitably I might want to do something different and now I have to go around to thousands of websites and say, please update this library in order for us to you to have the next version of Discuss. And that is just such a ridiculous pain point to go to, you know, the way that that scales is that there's one of me and there's thousands or I think there's basically millions of websites with Discuss and to go and get all of them to upgrade all of their bundles or whatever is it would be brutal. So that's just why we don't explore. So no. As a publisher, I mean you can, what we do, we have our libraries like jQuery and all that stuff we know will not change that often. We build them up in one request, right? But then, of course, the widgets that change that could change any minute you got to find a solution for that. Yeah. Okay. We do some proxying of third-party content sometimes and there's a different flavor of it. So, you know, on the good side, if you proxy third-party content through your servers, your CDN, then you kind of regain control over some availability tests over the performance delivery of it, or, you know, we're not willing to spend as much on the delivery controls as you might be. Where that really runs into an obstacle is with things like tracking. So like on Facebook, you could probably pull that off with a Facebook SDK which is generic and cacheable, but you wouldn't be able to do it with the iframe that figures out which of your friends recommended this because, you know, that requires some special cookies and once you moved it off to a different domain, so to me, if we are to do something like a C3PO or some equivalent of it, we should tackle that because our assessment, we've done some sort of kind of mass testing on it and was that that really qualifies a lot. In order to move something to a different domain, you need to be absolutely sure that there would be no cookies associated with that request or even if you're doing cookie syncing, there would be no cookies other than a session ID cookie so we would need to standardize how that is being handled if we wanted to go down to that path. I think we'll kind of come back to that C3PO and share cookies things in a later question, but I think there's an interesting question there for the browser vendors have we actually made this problem for ourselves because we can't share cookies and domains for security reasons, we've actually created this problem and there needs to be some way to address it because effectively, there's an ecosystem of people that want to share this data there is no effective mechanism that I'm aware of anyway that can do that but next question we've got is from Wes Oh, Calvin, Calvin sorry, Calvin The problem with document right was mentioned earlier and the need to make sure your async loaded scripts don't have a document array tags I work with an environment where I have hundreds of unknown vendors including third party scripts at any time they have no way to ever vet them all they come from 150 different properties and we we currently use a tool called write capture to override what document right does and force asynchronous loading of everything and it's awful and when it breaks it gives me headaches for months at a time we can never get rid of that or actually my question is can we get rid of that, is there anything we can do so that we can stop having to vet these and know that they're not going to do anything because the surprise is awful if it ever happens so you want like a flag on the browser or something to say this page doesn't support document.write or something we add APIs all the time can we do the opposite just once so you're going to start at kill.ie6 campaign you're just going to start a website kill.document.write I would be very happy with that sorry? who would vote for that one what am I voting on kill.document.write just get rid of it sure yeah I mean we could start a trade association too in which we vet scripts I don't know I'm not being serious this is a terrible joke we do the same thing of the write capture as part of the kind of optimizations we do in Akamai I kind of share your opinion and they think I'd like to believe that browser vendors should be able to tackle that and if any browser vendor in the crowd wants to chime in by doing some 90% accurate version of the document.write just kind of write that out in spot where that script would have been after the fact because oftentimes just killing document.write or trying to mock it up in JavaScript it's the best we have so we use that where we're needed but it's extremely far from ideal we've got to move on to the next question so next question is actually from Wes okay so Facebook has recently taken steps to optimize the scripts for its embeddable like button which I think you guys can speak to but how do we measure the impact of embedding these scripts and then a second part of this question is the web intent specification I only hope to kind of conquer app linking and embedding these scripts is web intent kind of our hope for not having these types of share buttons and scripts that are included with those we might throw this question to Barbara actually as a consumer do you do performance testing and somebody comes to you and says I want to add this new third party script what do you do to measure the impact of that I'm big on performance I have issues when 50% of our CBC the sub-site is serving third party scripts and the rest we're serving to the customers it's just our own content I do try to do that it is very difficult for us to make sure that all the content errors at CBC know about it again and how to include it so in terms of performance I do performance test especially what happens before putting the script in versus after and we've seen some really bad incidents where ads or scripts like that slow down our site to track those kind of things give them to business and say see this is what could happen what about from your side what do you do to make sure yours is not so slow when optimizing the like button the only thing you can do is write a blog post and see how the waterfall is so nice now but it was, it is that was good I don't think we're doing anything to prove this is I know how much it reduces the average website just trying to do the best thing and let other people measure and see how it affects their websites right Ben you said earlier that you do a lot of debugging of the customer's websites because they always blame you for the performance issues so what are their tools, their techniques or their tips, is there a methodology that you follow to prove that it's the sucky customer website and not your awesome script that is exactly how I phrase it it goes over really well I mean there's a ton of techniques that are pretty well published out there that I am using I don't even know what I was saying I don't know, in my mind a lot of these seem they're very tried and true performance things like not binding to debouncing, throttling scroll handlers and or some of what we do is we render in chunks now so we release to the browser we'll render five comments release to the browser we're very cognizant of it's just never tying up the UI thread I don't think that's something that I can it's just like an individual widget developer or through an application developer they all sort of have to do that I think the big issue is that they don't or it's just all over the place as to whether they do I might be rambling here you can bring me back I guess the question if we take an example of where you said that you've proved that it wasn't your script that was blocking the site was it a case of, was it something that the customer was doing that was impacting your script in a negative way and how did you prove that? the last time I was I think this was just me myself I brought this on myself in the sense that I was observing the disgust was slow when scrolling through it on a blog and actually I think today that's a lot of CSS performance on the other topic that I will address but so I was debugging our scroll handlers and figuring out that in this case the parent website was not throttling a scroll handler and they were activating it as you went over to discuss so you would scroll down and it would actually sort of chug a little bit I don't remember the purpose of it this is just a random anecdote of something might be also nice to automate that somewhere on your side that publisher A is not using it properly or don't blame us if the site is slow we've got Matt May from Adobe do you have a comment on how you measure the impact of these scripts we'll hold that question then we'll try and stick with the topic I've got one comment on maybe to throw in which is that resource timing is hopefully going to help us identify real users there are some security aspects to resource timing but from my perspective when somebody comes to Akamai and says you're not making my site faster sometimes the purpose is to show that it's actually the third party that's on your page that's the cause at least we have we kind of put a lot of hope in that front to give us clarity about who's truly to blame and therefore where should the solution lie Sega, did you want to make a comment? I've actually been working for a while with vendors that work with us on enforcing the contract between the groups and one of the lines was never use document that right and the question is can we create or promote this contract between widget providers in kind surely and publishers and kind of help emerging providers which I have to deal with a lot to follow that at the same time probably protect some widget providers needs as well I would love that and we talked about that some sort of a policy and I would love to create a policy that we could give to the widget creators to consider using and I think it is important to make that point maybe to copy some of the security policies we're talking about sandboxing from that perspective I'm only giving you a constrained access to certain APIs you're not allowed to use document that right it's just going to break there's this organization called I forgot what the name was Interactive Advertising Bureau IAB they've released the document to ads so these are the best practices for ads do we need something similar for enforcement topic in the browser but I don't think there's any okay this is the checklist that you have to follow otherwise you don't give an A or okay so we'll switch on to the next topic Marcus stand up so this is an anonymous question the growing use of third party services means web pages today consume content from over 16 domains on average creating performance and reliability problems speedy and HTTP2 work per domain and don't help can we share connections or delivery across third parties so I guess this is really this is the point to discuss the 3PO idea and you know particularly when the area is open with a lot with this is like affiliate tracking and you're trying to attribute the affiliate referral fee to somebody so all of these affiliates are coming from different domains and different affiliate tracking networks and I've got to have that script on my page it's part of the business model of the customer I'm working in but if all of these things were put into one centralized domain or there was an effective mechanism for sharing and synchronizing the cookies across the domains that would help me a lot is that something that we can do or do you think that's never going to happen I really like the idea so there's many things that we can optimize first is the script that writes whatever the widget is doing the iframe and so on so having this package together with the publishers script sounds great we have to make sure that it's absolutely future proof because people might not get it once they get it of GitHub and then the other thing about the common domains after you have already written the iframe all the static resources on that iframe could they be sharing the same domain that'll be cool so you still have to make a request to the third party provider to get the HTML any logins and that kind of stuff but when it comes to static resources why not okay so with the idea like maybe we have like 3PJSCDN.com and we just sort of everybody has like we have 3PJSCDN.com that's where we put our static stuff and then we benefit from having a single domain is that basically the idea is that trying to help me understand I think there's two aspects there's the standardizing of how something gets included on the page which would help alleviate some of the concern with nascent third parties that don't put as much effort into it and then there's the delivery aspect of which was around yeah having some shared I guess there's the ideal would be maybe a single domain there are all sorts of security aspects to putting content from multiple providers on the same domain so that might not be an option so maybe at the very least that they share connections for those components to sort of deliver them where possible through the same entity well so much of this has to be done client side because it inherently wants to read a cookie to find what other website that you went to so I can do my affiliate tracking and things like that if we had some kind of shared mechanism could we move a lot of this server side are there any effective server side solutions so I can just take all the scripts off my page is that feasible what would we need to be able to move some of this stuff server side I think you need for the server to be able to pull in content from multiple domains you need for starters you would probably need for many of these third-party services you'd need some cookie syncing capability because they track different ADs the cookie syncing is a solved problem in ads so that can be done but then the second problem is non-ID cookies and that's not at all solved problem so we would need basically an admin from anybody participating in this from the Facebook discuss on the world to say I will keep everything server side maybe even provide some supporting mechanisms for that and work fully on a session AD and then of course then the politics kick in about who owns that ID but that's a we'll leave that part for later and on top of all of those you would need the browser to share connections if you didn't literally land on the same domain you would need to somehow have the browsers play ball in that front and of course for a publisher it would be great to just include something or run a script somewhere and include all the things that you need so that would help for sure I would say there is a lower bar around sharing at least or delivering them from a standard component for providers providers had an easy way to know which resources of their third parties are things that they could pull into their content and I think that would be a big step forward we had to do conversations with Facebook with Google with various others to learn that I believe the Google Analytics JavaScript library the Facebook SDK those components are static but you basically don't know those without very explicit statement from the browser vendors sorry the third party vendors no questions no comments we'll move straight on to the next one Andre Barrens Hi and this is an anonymous question if a blocking script is loaded from a domain that goes down then this will cause my page to fail to load how can we test and or address the single point of failure issue I guess I'll go to Barbara I mean single points of failure is this a real problem that affects your website yeah I would say so and I see sometimes even script being not properly included on the CVC domain literally ad hoc you could use like pads spoofomatic to check how your site is behaving with third party scripts also like spoof check I think the eBay team did that so you can pull it into your continuous integration so we can right away when somebody develops something we could right away figure out that they're including scripts not properly and then avoid that potential failure and we've had that happening as well even I think last week with ads where something was not properly included and we got some bad hits for that you were able to check during the build process that somebody somewhere included exactly so it literally checks for script and if you just put it wherever it is it's a really cool tool and there's even I think a grant plugin as well that you can use so I would love to have those kind of things more integrated in our deployment so that basically as a developer you can almost be done so you just don't have to think about it and we catch that and you just don't we're not able to deploy stuff important to clarify that the spoof is the extreme scenario this website is down and maybe a slightly more rare one but a mini version of it happens every time the page is loaded like any one of these blockers is also some sort of delay some sort of resource contention for each one of those resources sometimes the conversation comes into Facebook's not going to go down it's a different conversation but there is always a little bit of a penalty even for the kind of most cutting edge third parties so getting them out of the line of fire is always a good idea what I was saying is it may not be down but it may be blocked in the company and you don't want people on Facebook during working hours and so on so you effectively destroy the website because Facebook is blocked for some reason Carl Kineman you had a it's been answered, okay I was just going to add really quickly that other than I guess the case where somebody just puts in a blocking script tag there's that problem I do think that third party applications and third party scripts we absolutely have to be good citizens and we have to work in situations where stuff is down or wherever I know that a big push that we're making in our company is that if disgust goes down we at least want you to see static comments that are basically not dynamic you can't the server is not going to listen to you because maybe it's blowing up but at least you can read comments for all intents and purposes that's just static it's from a CDN and things look okay but it's like I don't this is just stuff that we have to do and I don't know if there's just like a hammer that everybody can just use for that if everybody did that we would definitely better off yeah and of course I appreciate those things that providers do but one of the other challenges we have is when editors are actually publishers like editors finding news being able to include widgets and they literally take them from from a website not thinking how to properly include it so those are the challenges for us also to a sandbox that something I wanted to add from your comment I'd really love to ask people to write blog posts and do research and put us to shame so just to keep the third party providers in check and say oh this is the horrible this is if you see some third party provider that doesn't provide any synchronous snippet make noise about it I think that's probably an important thing to mention is that you're not necessarily always criticising them what you're actually doing is giving them the opportunities to go to their boss and saying look at all these people are complaining about it and that's a really effective mechanism for them to get the resources they need a lot of these guys are providers they want to fix the problem but they've got competing business priorities if you're out there making a lot of noise about it it suddenly becomes a business priority and you really help them to address we've got about four minutes left I'm actually going to skip one question which we'll come back to because I really want to get question number seven answered which from Rahul Chaudhary Chaudhary this is another anonymous question what could the browser vendors provide to eliminate third party scripts and the problems associated with them I don't really agree with this question so I guess the question that we've got people from the Chrome team we've got people from Mozilla I'd be very interested to hear from those but I mean if you could have one thing from a browser vendor guy to help address this problem what would it be my number one would probably be the script dependencies document.write close second group tasting actually same the document write like the browsers I could probably go off on this for a long time please do so Stion set up that basically the way that most complex widgets work today is there's a script that runs on the host page and it usually opens up an iframe that communicate with each other and in a perfect world I would love if Discuss was just an iframe and there was that separation everyone could feel confident about it and that would be the contract you know it's in the iframe you know it's not going to escape the iframe but the problem is that the tools for making that happen are just non-existent there are tons of things that are being developed right now for further isolating iframes there is the sandbox attribute to break down this iframe there are no tools that are being developed from the other perspective which are let me get access to some of the stuff that's happening on the parent page let me know that somebody is scrolling the page let me know that somebody is clicking so that I can close a menu that I have happened to open in my iframe there is none of those tools right now and because of that or even very simply I cannot resize the iframe today because there are none of those tools we have to have this sort of dual system where you put JavaScript on your page and that's unfortunate it would be terrific if we started looking at things from the other side and then maybe things could get better I think a lot better just by providing those tools would the web components be an answer to that? I haven't looked I've only looked a little bit perhaps this morning to research a little bit more of a web component so I didn't look like a complete fool but from what I've seen is that they're still accessible by the parent page right? even if they're kind of hidden is there a web component person like you create the delegate put the hand up thing is not so if anybody is an expert on web components anyone? there's somebody over there Alex Alex to the rescue yeah Alex Russell from Google so the way web components work are it's a bunch of related specs that I don't get for a reason that I won't go into but you can have something called a shadow DOM which sort of hides away the implementation of your UI from the normal iteration order through the document and you're entirely correct that that doesn't solve the problem for you because you can still reach into the shadow DOM it was explicitly designed not to be a security boundary today the answer is put an iframe in your shadow DOM and use it that way so it doesn't get you out of any of the sizing issues I'm afraid I think a lot of this new stuff is still being developed from this perspective of almost like widgets if I was Google and I had widgets that I want on all my other services and I trust those services I feel like a lot of it is being designed from that perspective somebody can shut me up if they want because of the security things aren't addressed or there was the seamless spec that came out but it still lets styles come in as if maybe for that kind of publisher they may be interested in that but I'm not interested in that anyways this is we've got that sheet that says shut up time to go so basically we've got one minute left we're going to wrap up I think immediately after this we're staying here for lunch is that right? thank you very much to the people on the party people on the party people on the panel thank you