Edge Conf 2: Third Party Scripts

STEVE THAIR: Thank you. Thank you. [APPLAUSE] STEVE THAIR: Hi, my name’s
Steve Thair. I run the London Web Performance
User Group, and I run WebPerfDays 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
Disqus, whose discussions and comments you’ll have seen
on our many websites. We’ve got Stoyan Stefanov from
Facebook, whose Like buttons and all those kind of Facebook
widgets that you like to put on your page. And over here, we’ve got Guy
Podjarny from Akamai, who’s sort of like the middle man, the
distribution network for the stuff that they’re
dealing. And then we’ve got– well, I was going to say
addict, but that’s probably not right. We’ve got Barbara Bermes 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 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 Stoyan just to set
the scene on what third-party stuff means. Just remember, obviously we’ve
got the [? on-slide ?] stuff. So try and use that as
much as you can. Come in, give positive and
negative feedback. And obviously, put your hand
up via [? on-slide ?] if you want to talk. Thank you. Over to Stoyan. STOYAN STEFANOV: Thank
you, Stephen. 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 how to bring this party to today
and tomorrow. Slide, please. So Stephen 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 Stephen
is also on the ops side. He’s also on Barbara’s
side, protecting– STEVE THAIR: Impartial
moderator. STOYAN STEFANOV: 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. Or 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’s what we want to talk
more about how we deal with scripts and iframes. And you’re including JavaScript
on the page coming from somewhere. You don’t know, you have no
control over coming in 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 third-party recommendation engine. So it was attacked by Syrian
army folks who were able to mess with our 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 widget
provider and have control over so many websites? So security’s obviously
a big one. And then you have the single
point of failure where if a page includes a script
synchronously, they add single point of failure. And despite the fact that we
have now good tools from Pat Meenan’s SPOF-O-Matic extension
for Chrome, and also you’re able to find SPOF using
WebPagetest, but it 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 holed. And then there’s all the
performance issues. Anything you add on the page
will add to the rendering time and loading time and all that. All right, so what does
the state of the art of script include? So despite all the evangelism
for using asynchronous scripts, people are 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 is currently some things
on the crazier side, like using frame in frame,
loading 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
unload event. So this is for people who still
care about window.unload and whenever it happens. Not as easy or friendly to copy
and 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. And the reason is so that the
third-party provider can push fixes in security updates
very quickly. But that’s bad for performance
because we cannot use far future Expires 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 far future Expires header. I don’t know if anyone’s
doing it currently. AUDIENCE: [INAUDIBLE]. STOYAN STEFANOV: [INAUDIBLE]. All right. And then there’s stuff that’s
coming up from the web-perf W3C group, which I was hoping
someone can enlighten us what’s going on there
with the progress. All right. Next. Oh yeah, there’s this idea about
what I call C3PO, or Common 3rd-Party Objects. 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 it 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 Like button
in German, which is longer word. So you have to resize the iframe
not to take more space than needed. And a lot of widget providers
are doing the same thing. So what if we can have one
script that is open source 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. Or we download five, six
scripts, 100k, 200k instead of having just zero requests. So that is the idea. Meanwhile, what we have in
nearer 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. Then I’m thinking, is it any
easier on the publisher’s side to include a web component
instead of the current state where you include a diff class, something, and the script? There’s the iframe sandbox. It’s really cool. Should we encourage people
to use it or not? What would this allow in
a third-party widget? So there was the idea
of seamless iframes. It seems like it’s not going
anywhere, going away. The same with the
frame srcdoc. What’s the state of that? Is it dying as well? We can talk about it. STEVE THAIR: It just got
a negative vote. [LAUGHTER] AUDIENCE: It’s dying. STOYAN STEFANOV: 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? 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 she was also, like Stephen
said, challenging anyone to stand between the marketing
people and their widgets. So how do we monitor third-party
widgets? Do people set up budgets
and say, OK, you have this amount of time? 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. So how do people deal with the
scripts that have to do document write and so on? Guy brought a good
question about– according to the HTTP Archive,
the number of domains every website is using 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 may be more manageable,
like what if we used the same domain name for all the static
resources, scripts and styles and 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. STEVE THAIR: I think it
would c3po.akamai.com. STOYAN STEFANOV: Oh, mobile. It’s finally here. What does it mean for widgets? Is it only just making
performance issues even more visible? Should we do something
about it? Are people using that many
widgets on mobile websites? I’m curious to know. Yeah, I think that’s
all I had. And let’s talk about
all this stuff. [APPLAUSE] STEVE THAIR: Well, thanks
very much, Stoyan. I’m just going to do a quick
poll of the panel. Guy, any quick comments from
Stoyan’s opening talk? GUY PODJARNY: Sure. Maybe I’ll add a couple. One is in general, third
party is a little bit broader than that. I think there’s some bias
to think about– every person has a bias, but
there’s also tracking beacons, which for some websites are
plentiful and actually coming off in the form of an image. And there are also, actually,
third-party components that are more in line to your page. Also, some shopping cart
personalization components and such that I guess kind of
start to tread the line because while they’re third
party, they’re not extraneous to the core flow or requirement
of the product. But they’re still a concern in
all sorts of things, like number of domains and
reliability concerns. Security concerns is still
very much valid for them. So that’s one point. And then the second one is just
to 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 keeping them reasonably fast. And there’s also things that
are just trends, like the number of domains or 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. STEVE THAIR: Barbara? BARBARA BERMES: So 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
side, to tell them what to look out for when asking
third-party providers to provide their code. STEVE THAIR: 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? BARBARA BERMES: Exactly. You’ve got to explain to them
what the impact actually is, and they don’t always
understand that. STEVE THAIR: Ben, as a provider,
what would you say about Stoyan’s opening marks? BEN VINEGAR: I mean, they’re
really good comments. 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, Stoyan. But I want to flip this around,
like 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– [LAUGHTER] STEVE THAIR: Yes. BEN VINEGAR: And I mean that
partially as a joke, but there is definitely– 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 possibly
worth discussing. STEVE THAIR: Cool. I think we’ve actually got a
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. Oh, you’re down there. AUDIENCE: 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? STEVE THAIR: 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? AUDIENCE: 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? STEVE THAIR: Do you want to
start taking that one? STOYAN STEFANOV: I’m not aware
of any development. Are you? Is there a proposal going on? AUDIENCE: I started playing
around with the idea. It’s kind of hard to define what
happens when the media query changes. That’s where 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? STOYAN STEFANOV: It definitely
sounds interesting. GUY PODJARNY: 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 with them. So institutionalizing or
standardizing conditional loading makes perfect
sense to me. And using media queries seems
like one way to do it. I’m not sure if there’s any
active conversation about it, so I guess we’ll probably need
to figure out all the different options of it. But I do think that’s a good
path that we need to go down. BARBARA BERMES: I think also,
the idea is interesting, but I’m also wondering, what
are the use cases? So you would not load, for
example, a Facebook button for mobile versus desktop,
or whatever? AUDIENCE: 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 jQuery mobile here and jQuery UI there. These are the use cases
I have in mind. GUY PODJARNY: And Twitter
streams are a common one in responsive design. BARBARA BERMES: Or even we’re
doing different ad surverying for desktop versus mobile,
for example. STEVE THAIR: We’ve
got a couple of comments from the floor. Kyle Simpson from Getify, did
you have something to say on this topic? AUDIENCE: I didn’t actually
intend to click that, but I’ll just say something as I do have
a question, since they gave me the mic. STEVE THAIR: OK. BARBARA BERMES: It’s
your time. AUDIENCE: But on that topic
though, so there’s 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. 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 on
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’m a little biased, but I feel
that’s the JavaScript loaders rather than markup. GUY PODJARNY: 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%. 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. STEVE THAIR: We got David
[? Stigman ?] from Akamai wants to make a comment. Feel free to disagree with
briefly. AUDIENCE: Hi. One of the most common use cases
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 domain 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. STEVE THAIR: Anyone? GUY PODJARNY: I can take that. STEVE THAIR: Yeah. GUY PODJARNY: So I think the
number of domains, as kind of pointed out before– this has not been coordinated,
just to kind of make sure– is a real problem. It comes into play in DNS. It comes into play with the fact
that SPDY 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 deprioritization,
as far as I know, of third-party content. You can’t kind of mark things
beyond the async or the kind of processing aspects
in the browser. You can’t mark something
as slower or faster. I think they contend for
resources today. A part of it is about
how do we optimize the number of domains? And yeah, today the only tools
you have for deprioritizing them is the things like
async and such. STEVE THAIR: We’re going to come
on to a later question where we’re going to talk more
about dependencies and execution time. But just to sort of stick what
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 got two votes, three
votes, four votes, five votes. So people do think this
is a problem. And that’s not just Yoav hitting
the button five times. AUDIENCE: I have several
accounts. BARBARA BERMES: And friends. STEVE THAIR: OK. BEN VINEGAR: I would just say
that we experience that people are conditionally loading our
application, usually doing templates or JavaScript
or whatever, already. So if that can just be a really
nice declarative way of doing that as opposed to setting
up JavaScript code, I don’t see the problem
with that. People are doing already,
I guess, is what I’m trying to say. BARBARA BERMES: 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. GUY PODJARNY: 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. STEVE THAIR: OK. So let’s go on to the
second question. We’ve got Tom [? Buchok. ?] AUDIENCE: So this one came in
an 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. STEVE THAIR: As I understand,
it’s related. There are a lot of hacky ways
people download scripts as comments and then add them
dynamically to the page when they need them. There’s a lot of hacks out there
that people are doing to get around the async
and the blocking nature of the scripts. So what’s happening with the
working groups, and what’s the best solution for this? BEN VINEGAR: I am not familiar
with this topic. STOYAN STEFANOV: Anyone
from the audience who wants to take it? Kyle or– GUY PODJARNY: I can give a
starting, and then maybe we’ll switch to Kyle. So I think there’s a
few things there. There’s one kind of called
resource priorities that has to do with enabling 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 is 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 this script needs to run after the other
but both of them combined should be asynchronous? There’s things around
association of unload, triggering the unload event. And an async script because an
async script today will still delay the unload. 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. AUDIENCE: So since my name was
brought up, I will speak up. Yeah, so two or three years ago,
there was some proposals. Nicholas Zakas and I kind of
joined together and made some proposals on [INAUDIBLE] about what we call script
preloading. 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. STEVE THAIR: OK. Jake, did you want to
say anything, since you got called out? AUDIENCE: 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 other 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– you can boost getting to DOM
content loaded by 20%. So we want something in the
markup that can dictate which order that scripts will be
executed and then load them asynchronously. GUY PODJARNY: 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 muck
up 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 is something
a little bit more elaborate than that can, after
the fact, write content in those sections. STEVE THAIR: OK. So Wilson Page from FT Labs has
got his hand up to comment on this topic, hopefully. AUDIENCE: Hello. As a web app developer,
I like to have control over my resources. So will it be possible that
third parties like Disqus 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’d want control. I mean, you want the control to
be able to update when you want to update it. But I also don’t want a hundred
HTTP requests going off on my page. BEN VINEGAR: Yeah. Oh man, all eyes on me here. I’m a web developer, too. I hope so. And I totally– I would like to do that. It sort of makes sense. But you basically just hit be
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. The idea is 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– 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 you to have the next version of Disqus. And it’s just such a ridiculous pain point to go to– the way that that scales is
there’s one of me and there’s thousands– or I think there’s basically
millions of websites with Disqus. And to go and get all them to
upgrade all of their bundles or whatever would be brutal. So that’s just why
we don’t explore. STEVE THAIR: So no. BARBARA BERMES: As a publisher,
what we do we, we have our libraries, like jQuery
and all that stuff, we know will not change
that often. So we compile them or bundle
them up in one request. But then of course, the widgets
that change, that could change any minute,
you got to find a solution for that. GUY PODJARNY: We do some
proxying of third-party content, sometimes. There’s a different
flavor of it. So on the good side, if you
proxy third-party content through your servers, your CDN,
then you regain control over some availability
tests, over the performance delivery of it. They may not be delivering it
as kind of high quality, or 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 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 that requires some
special cookies. And once you moved it off to
a different domain, those cookies no longer get sent. 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, was that that
really qualifies a lot. In order to move something to
a different domain, you need to be absolutely sure 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 on that domain. And that’s just a very
tough restriction. So we would need to standardize
how that is being handled if we wanted to
go down that path. STEVE THAIR: I think we’ll
come back to that 3PO and shared cookie 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. Sorry, Calvin. AUDIENCE: The problem with
document write was mentioned earlier, and the need to make
sure your async-loaded scripts don’t have document.write
tags. I work with an environment
where I have hundreds of unknown vendors, including
third-party scripts, at any time. And I have no way to ever vet
them all because they come from 150 different properties. And we currently use a tool
called Write Capture to override what document.write
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 document.write because the surprise is awful
if it ever happens? STEVE THAIR: So you want, like,
a flag on the browser or something to say this page
doesn’t support document.write or something? AUDIENCE: We add APIs
all the time. Can we do the opposite
just once? [LAUGHTER] STEVE THAIR: OK. So you’re going to start
to sound like that kill IE6 campaign. You’re just going to start a
website, kill document.write? AUDIENCE: I would be very
happy with that. STEVE THAIR: Sorry? Who here would vote
for that one? BEN VINEGAR: What
am I voting on? STEVE THAIR: Kill
document.write. Just get rid of it? BEN VINEGAR: Sure, yeah. 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. GUY PODJARNY: So we do the
same thing on the Write Capture as part of the kind of
optimizations we do in Akamai, and I kind of share your pain. And 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
the spot where that script would have been after
the fact. Because oftentimes, just killing
document.write or trying to muck it up in
JavaScript, it’s the best we have, so we use that
where needed. But it’s extremely
far from ideal. STEVE THAIR: We’ve got to move
on to the next question. So next question is
actually from Wes. AUDIENCE: OK. 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, is the Web Intent specification our only hope to
kind of conquer app linking and embedding these scripts? Is Web Intents kind of our
hope for not having these types of share buttons
and scripts that are included with those? STEVE THAIR: Well, I might
throw this question to Barbara, actually,
as a consumer. I mean, do you do performance
testing? If 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? BARBARA BERMES: I’m big
on performance. And obviously, I have issues
when 50% of our CBC desktop side is serving third-party
scripts, and the rest we are serving to the customers
is just all on content. So I do try to do that. It is very difficult for us to
make sure that all the content areas at CBC know about it
and how to include it. So in terms of performance,
I do performance tests, especially the AP– what happens before putting the
script in versus after. And we’ve seen some really bad
incidents where ads or scripts like that slowed
down our site. So to track those kind of things
and give them to a business and say, see, this is
what could happen, yeah. STEVE THAIR: What about from
your side, Stoyan? What do you do to make sure
yours is not so slow? STOYAN STEFANOV: Well, when
optimizing the Like button, then the only thing you can do
is write a block post and see– oh, see how the waterfall
is so nice now. BARBARA BERMES: But it was. It is. That was good. STOYAN STEFANOV: Yeah. I don’t think we’re doing
anything to prove, OK, this is how much it reduces the average
website and so on. Just trying to do the best thing
and let other people measure and see how it affects
their websites. STEVE THAIR: Ben, you said
earlier that you do a lot of debugging of the customers’
websites because they always blame you for the performance
issue. So are there tools? Are there techniques? Are there tips? Is there a methodology that you
follow to prove that it’s the sucky customer website and
not your awesome script? BEN VINEGAR: 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’m probably using. I don’t even know why I’m
saying “we” there. 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. Something we do is we render
in chunks now. So we release to the browser. We’ll render five comments,
release to the browser. Render five comments, release
to the browser. We’re very cognizant of 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 third-party application developer, they all sort
of have to do that. And 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 ca bring me back. STEVE THAIR: Well, I guess
the question– so 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 something that the
customer was doing that was impacting your script in a
negative way, and how did you prove that? BEN VINEGAR: Well, actually,
the last time I was debugging a site– I think this was just
me, myself. I brought this on myself in the
sense that I was observing that Disqus was slow
when scrolling through it on a blog. And actually, I think today
that’s actually a lot of CSS performance, which is another
topic that I will address. 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 Disqus. 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. BARBARA BERMES: It might be
also nice to automate that somewhere on your side, or on
your end that you can say, OK, publisher A is not using
it properly. Or, don’t blame us if
the site is slow. STEVE THAIR: We’ve got
Matt May from Adobe. Do you have a comment on how
you measure the impact of these scripts? AUDIENCE: Actually, my
question’s a different thing. STEVE THAIR: Oh, well, we’ll
hold that question. We’ll try and stick
with the topic. GUY PODJARNY: I’ve got one
comment on it, maybe to throw in, which is that resource
timing is kind of, hopefully, going to help us identify
in real users where to lay the blame. 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 sort of show that
it’s actually the third party that’s on your page
that’s the cause. At least we kind of put a lot of
hope on that front to give us clarity about who
is sort of truly to blame for the problem. And therefore, where should
the solution lie? STEVE THAIR: Sergei, did you
want to make a comment. AUDIENCE: 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 that
we use document.write. And the question is, can we
create or promote kind of this contract between widget
providers of different kinds, 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? BARBARA BERMES: I
would love that. 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 and say,
OK, if you followed those steps, we would consider
you using. And I think it is important
to make that point. GUY PODJARNY: Maybe be able to
copy some of the security policies we’re doing. We’re talking about sandboxing
from that perspective. Sort of say, well, I’m only
giving you a constrained access to certain APIs. You’re not allowed to
use document.write. It’s just going to break. STOYAN STEFANOV: There’s this
organization called– I forgot what the name was. Interactive Advertising Bureau,
something like this. STEVE THAIR: The IAB. STOYAN STEFANOV: IAB. They’ve released a document
related to ads saying these are the best practices for
ads, that kind of stuff. So do we need something
similar for– GUY PODJARNY: What is
the enforcement of it in the browser? STOYAN STEFANOV: But I don’t
think there is any, OK, this is the checklist that
you have follow. Otherwise, you’re
not given an A. STEVE THAIR: OK. So we’ll switch onto
the next topic. Matt [? Marquis? ?] Stand up. AUDIENCE: 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. SPDY and HTTP2 work per
domain and don’t help. Can we share connections or
delivery across third parties? STEVE THAIR: So I guess
this is the point to discuss the 3PO idea. Particularly one of the areas
I deal with a lot is like affiliate tracking, and you’re
trying to attribute the affiliate referral
fee to somebody. And 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? STOYAN STEFANOV: 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 as packaged
together with the publisher’s script sounds great. We have to make sure that it’s
absolutely future proof because people might not upgrade
it once they get it off of GitHub. And then, the other thing about
the common domain, after you have already written the
iframe, all the static resources on that iframe,
could they be sharing the same domain? That would be cool. So you still have to make a
request to the third-party provider to get the HTML,
any log-ins, and that kind of stuff. But when it comes to static
resources, why not? STEVE THAIR: Ben? BEN VINEGAR: So would
the idea– maybe we have, like,
[? 3pjscdn.com, ?] and everybody has–
like, we have [? 3pjs/facebook/disqus ?] and that’s where we put
our static stuff. And then we benefit from
having a single domain. Is that basically the idea? Try and help me understand
here. GUY PODJARNY: I think there’s
two aspects of it. There’s the standardizing of how
something gets included on the page, which would help
alleviate some of the concern with nascent third parties or
third parties that don’t put as much effort into it. And then there’s the delivery
aspect, which was around having some shared– 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, it
is shared connections for those components to deliver them
where possible through the same entity. STEVE THAIR: 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 of the scripts
off my page? Is that feasible? What would we need to be able
to move some of this stuff server-side? GUY PODJARNY: For the server to
be able to pull in content from multiple domains, for
starters, you would probably need for many of these
third-parties services, you would need some cookie syncing
capability because they track different IDs. 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
a solved problem. So we would need, basically
a commitment from anybody participating in this, from the
Facebooks the Disqus of the world, to say, I will keep
everything server-side. Maybe even provide some
supporting mechanisms for that and work fully on
a session ID. And then of course, then the
politics kick in about who owns that ID, but 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. So you’d need to somehow
have the browsers play ball on that front. BARBARA BERMES: 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. GUY PODJARNY: I would say there
is a lower bar, around sharing at least, sort of
delivering them from a standard component
for providers. So if providers had an easy way
to know which resources of their third parties are things
that they could pull in to their content, then
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 third-party
vendors. STEVE THAIR: No questions
from the– no comments? OK, we’ll move straight
on to the next one. Andre Behrens? AUDIENCE: 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? STEVE THAIR: I guess
I’ll go to Barbara. Single points of failure, is
this a real problem that affects your website? BARBARA BERMES: Yeah,
I would say. And I see, sometimes, even
script being not properly included on the CBC domain. Literally, ad hoc you could
use Pat’s SPOF-O-Matic to check how your site is behaving with third-party scripts. I also like SPOFCheck by, I
think, the eBay team did that so you can pull that into your
continuous integration. So right away, when somebody
develops something, we could right away figure out that
they’re including scripts not properly, and then avoid that,
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. STOYAN STEFANOV: So you were
able to check during the build process that somebody
somewhere included a [INAUDIBLE]? BARBARA BERMES: Yeah, 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 Grunt plug-in as well that you can use. 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. You just don’t have
to think about it. And we catch that, and we’re
not able to deploy stuff. GUY PODJARNY: It’s important
to clarify that the SPOF 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. So sometimes the conversation
goes into, no, Facebook’s not going to go down, which is
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. STOYAN STEFANOV: And what I was
saying is it may not be down, but may be blocked
and 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. STEVE THAIR: Kyle [INAUDIBLE],
you had a– AUDIENCE: It’s been answered. STEVE THAIR: It’s
been answered? OK. BEN VINEGAR: I was just going
to add really quickly that other than 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 Disqus goes down, we
at least want you to see static comments that are
basically not dynamic. The server’s not going to listen
to you because maybe it’s blowing up, but at least
you can read comments. And for all intents and
purposes, that’s just static. It’s from a CDN, and
things look OK. But it’s like 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. GUY PODJARNY: If everybody did
that, we would be definitely better off. BARBARA BERMES: Yeah. And I mean, of course, I
appreciate those things that providers do. One of the other challenges we
have is when editors, like editors [? writing news ?] be able to include widgets. And they literally take them
from a website not thinking how to properly include it. So those are the challenges for
us also to sandbox that. STOYAN STEFANOV: Something
I wanted to add from your comment. I would really love to ask
people to write blog posts and do research and put
us to shame. And just to keep the third-party
providers in check and say, oh, this is horrible. So if you see some third-party
provider that doesn’t provide asynchronous [INAUDIBLE], yeah,
make noise about it. STEVE THAIR: I think that’s
probably an important thing to mention, is that you’re
not necessarily always criticizing them. What you’re actually doing is
giving them the opportunity to go to their boss and saying,
look, all these people are complaining about it. 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’re only 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 ?] [? Chowdary. ?] AUDIENCE: So 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. [LAUGHTER] STEVE THAIR: So I guess
the question– we’ve got people from
the Chrome team. We’ve got people from Mozilla. I’d be very interested
to hear from those. But if you could have one thing
from a browser vendor, Guy, to help address this
problem, what would it be? GUY PODJARNY: My number one
would probably be the script dependencies, document.write a
close second with the ability to group to async. STEVE THAIR: Barbara? BARBARA BERMES: Actually,
same. The document write, actually. STOYAN STEFANOV: I like
the browsers. They’re my favorite. BEN VINEGAR: I could
probably go off on this for a long time. STEVE THAIR: Please do. BEN VINEGAR: So Stoyan 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 Disqus 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 nonexistent. There are tons of– I don’t want to say tons. But there are things that are
being developed right now for further isolating iframes. There is the sandbox
attribute. Let’s really 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’s
scrolling the page. Let we know that somebody’s
clicking so that I can close a menu that I happened to
open in my iframe. There’s 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 we have to 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. STOYAN STEFANOV: Would
the web components be an answer to that? BEN VINEGAR: I’ve only looked
a little bit, perhaps this morning, to research a little
bit more about web components. I look like a complete fool. But from what I’ve seen is that
they’re accessible by the parent page, even if they’re
kind of hidden. Is there a web components
person? Like you create– STEVE THAIR: The delegate put
their hand up [INAUDIBLE]. If anybody’s an expert
on web components. Anyone? BEN VINEGAR: Somebody
over there, yeah. STEVE THAIR: Alex. Alex to the rescue. AUDIENCE: Hi. Yeah, Alex Russell
from Google. So the way web components
work are it’s a bunch of related specs. We designed it that way 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. BEN VINEGAR: So I think a lot of
this new stuff [INAUDIBLE] thing 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 the security things
aren’t addressed. Or, there was the seamless spec
that came out, but it still let 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, got that sheet
that says shut up. STEVE THAIR: Time to go. All right, so basically
we go one minute left. We’re going to wrap up. I think immediately after this,
we’re staying here for lunch, is that right? AUDIENCE: [INAUDIBLE]. STEVE THAIR: Yep. Well, thank you very much to
the people on the party– people on the party. People on the panel. [APPLAUSE]

Leave a Reply

Your email address will not be published. Required fields are marked *