How Well Do You Know the Web? (Google I/O ’17)

How Well Do You Know the Web? (Google I/O ’17)

[MUSIC PLAYING] PAUL LEWIS: Hello, everyone! JAKE ARCHIBALD: Hi, ya! PAUL LEWIS: How is it going? JAKE ARCHIBALD: Oh! OK, so this session is
going to be a little bit different, right? PAUL LEWIS: Yeah, but we should
actually introduce ourselves. I’m Paul. He’s Jake. We work in Dev Rel. JAKE ARCHIBALD: Yes. PAUL LEWIS: Now we’ve been
doing web stuff for a while, and it still manages
to surprise us. So we’ve written a
quiz that explores the weird and wonderful
corners of the web. JAKE ARCHIBALD: But we’re also
going to dig into the answers and hopefully explain
parts of the web platform in a way that will help
you with your projects and let you build faster, more
reliable, progressive web apps. PAUL LEWIS: And of course,
the quiz itself is a PWA. So prepare yourselves, Get
your smartphones, tablets, or laptops at the
ready, because we’re going to play the Big Web Quiz. JAKE ARCHIBALD: Oh, yes. Paul did spend
three hours making that one intro in After
Effects, by the way. PAUL LEWIS: More
like six, whatever. Worth every minute. JAKE ARCHIBALD: So if
you want to play along, and you should,
because it’s basically the whole point of this
session, get yourself down to and log in
with your Google accounts. PAUL LEWIS: And
of course, this is the part where we panic about
the server falling down. JAKE ARCHIBALD: It’s OK
though, we did test it at Chrome Dev Summit. PAUL LEWIS: Yes, and
the server fell down! JAKE ARCHIBALD: Yes, it did. But I think we fixed that. And with a little bit of
luck, it should be OK. Yeah, it should be fine. PAUL LEWIS: But then your
laptop screwed up on this stage last year. JAKE ARCHIBALD: Last
year, my laptop broke. But that’s a new laptop now. In fact, it’s the first time
I’ve ever presented from it. So it probably– PAUL LEWIS: An untested laptop
is what you’re telling me. JAKE ARCHIBALD:
–going to be fine. They weren’t being
able to get logged in? Is that sort of thing working? Yes, thumbs up! Oh, we’re winning from
Chrome Dev Summit. That’s just so unreal. PAUL LEWIS: I mean, obviously. JAKE ARCHIBALD: Yeah,
last time we did it, people were just
shaking their heads, and we were like,
what do we do now? Do we just have a– PAUL LEWIS: Panic, blind panic. JAKE ARCHIBALD: OK. PAUL LEWIS: Anyway, we’re
going to show the top players at the end of the game and
at some points throughout. But we only want to do
that with your permission. So if you want to appear
on the leaderboard, click on your avatar and
click up here on Leaderboard. JAKE ARCHIBALD: Yeah,
so if you phoned in sick so you could come
here instead, don’t opt-in. Because your massive face
appearing on this screen might give things away
a little bit, you know. Oh, of course, no quiz is
complete without a grand prize. PAUL LEWIS: Yes, unfortunately,
unfortunately the organizers of Google I/O told
us we weren’t allowed to have our own giveaway. But we came up
with a compromise. JAKE ARCHIBALD: Yeah, we
said, what if our prize was of such low quality
that winning it would kind of feel like losing? PAUL LEWIS: Yes, so if
you play the Big Web Quiz, opt-in to the leaderboard,
and use your esoteric web knowledge to make it
into the top three, you will become the proud owner
of the official Big Web Quiz mousepad. [CHEERING] JAKE ARCHIBALD: Oh, yeah. PAUL LEWIS: I think we all
know he’s enjoying that. JAKE ARCHIBALD: We’ve been
asked to make it clear. You only get the mousepad. Paul Irish is sold separately. So if you are watching this
on the live stream, hello. And feel free to
play along as well. You can’t win the
mousepad, unfortunately. And there’s a delay, right? PAUL LEWIS: There is. JAKE ARCHIBALD: The live stream. PAUL LEWIS: Yeah, about
30 seconds behind reality. So you need to watch for
the questions appearing on your device as the question
may end before the video makes its way to you. JAKE ARCHIBALD:
Yeah, so in fact, if you’re watching this
in the live stream now, we’ve probably started the
first question already. Because we’re going to be
doing that in 30 seconds. And you are living in
the future right now. PAUL LEWIS: Ooh. JAKE ARCHIBALD: Paul,
this is hurting my head. PAUL LEWIS: The evidence in
which to confuse you, really. Shall we do a practice question? Make sure everything is working? JAKE ARCHIBALD: Yes,
let’s see if this works. Let’s give it a go. So devices at the ready. Here comes the first question. PAUL LEWIS: What
does PWA stand for? Is it progressive
web app, produced with angular, partially wheeled
automobile, or perfectly waterproofed anorak? JAKE ARCHIBALD: Anorak,
is that a word that’s– PAUL LEWIS: It’s a coat. It’s a coat. JAKE ARCHIBALD: It obviously
makes for the right answer. PAUL LEWIS: Yeah. JAKE ARCHIBALD: The
question should, if everything’s working, be
appearing on your phones now. So pick the answer that
you think is correct, and hit Submit. Very important that
you hit Submit. PAUL LEWIS: And while
you are doing that, let’s see how the
results are looking. JAKE ARCHIBALD: So
what we’re seeing here is the percentage of
you picking each answer. However, the order
is randomized. PAUL LEWIS: The
order is randomized compared to your devices. It may not be in the same order. JAKE ARCHIBALD: Yes, but can
see that you’re all converging on one particular answer. Wonder which one that might be. PAUL LEWIS: Should we
close the question? JAKE ARCHIBALD: We’re closing
the question in 3, 2, 1. And there it is. PAUL LEWIS: There it is. JAKE ARCHIBALD: Oh, OK. Some of you think it’s
produced with angular. That’s interesting, OK. PAUL LEWIS: Perfectly
waterproofed anorak. JAKE ARCHIBALD:
Obviously, somebody hasn’t really thought about it. Been to a session yet. The correct answer is, of
course, progressive web app. PAUL LEWIS: Yes. JAKE ARCHIBALD: So we
didn’t award points for that question, since it’s
just for a bit of a practice. But one thing we
do want to stress is that you have to hit that
Submit button once you’ve pick your answer, else we
don’t find out about it. PAUL LEWIS: Yeah. It turned out that
during the rehearsal, some of our colleagues
didn’t realize that and they scored zero points. JAKE ARCHIBALD: Yes. And in true web fashion,
like rather than fix the problem
properly, we thought we’d just sort of gaffer
tape over it with this slide and just tell you, just make
sure you press that button. PAUL LEWIS: Read
the instructions. So everybody knows
what they’re doing? Let’s get serious now, I think. JAKE ARCHIBALD: Yes. From now on, each question will
award a maximum of four points. PAUL LEWIS: Yes, indeed. That’s a nice round
number, isn’t it? Power of two. Very happy with that. JAKE ARCHIBALD: Right. OK. So we’re going to kick
everything off with a deep dive into loading stuff. Because if you want to build a
successful progressive web app, you need to minimize the time
from the user clicking a link, and then actually having
your app on the screen and being able to use it. PAUL LEWIS: Yeah. No, this is the difference
between a fast app and a slow app, of course. JAKE ARCHIBALD: Yes. So ideally, progressive web
app should load bit by bit. Some might say progressively. However, some loading
techniques get in the way of parsing and painting. And that can result
in the browser, like downloading loads of
stuff, but being unable to show any of it to the user. And then once everything
is downloaded, ta-da. There’s this big reveal. PAUL LEWIS: Absolutely. And that’s bad for the
user because they’re left staring at a
white screen, wondering if stuff’s downloading, whether
their connection is hung. Whereas, a progressive render
improves the perception of performance
because things can start appearing much sooner. JAKE ARCHIBALD: Yeah. And internally,
this is good as well because the browser can
create these elements as the HTML downloads, which
is much faster than doing all of the download
as one step, then doing all of the parsing as
a completely separate step. And that brings us
to our next question. PAUL LEWIS: Yes. JAKE ARCHIBALD: So
devices at the ready. Here it comes. Which of the following
script elements blocks the parser while
the script downloads? So we have a normal
script tag there. We’ve got a script with
defer, a script with async, and a script with
async equals false. PAUL LEWIS: Now,
this is a little different to the
last one because you can select all answers
that you think are true. And you’re gonna get to
get points for the answers that you select that turn
out to be true and points for not selecting the
ones that are false. JAKE ARCHIBALD: Yeah,
it’s actually simpler that it sounds on this. You get 4 points for
getting it fully right. You get 2 points if
you get it half right. PAUL LEWIS: Yeah. And it might be all of them. It might be none of them. It might be somewhere
in the middle. JAKE ARCHIBALD: Also, you
can submit as many times as you want. So if you change your
mind at the last second, you can do that. Just make sure you
hit the Submit button. PAUL LEWIS: OK. Let’s look at the voting. Don’t worry, you’ll get
[? faxed on ?] this. JAKE ARCHIBALD: Let’s
see how things are going. OK. So already, we got a kind
of spread of answers. We got two that you’re
pretty confident on, two that you’re less confident on. You’ve had enough time to guess. So if you haven’t
guessed already, guess. But we’re gonna
lock the question. Close it. 3, 2, 1. Lock it. There you go. OK. So what we’re seeing here,
we’re thinking a normal script element blocks the parser. And we’re also
thinking that async equals false one is
going to do the same. PAUL LEWIS: Interesting. JAKE ARCHIBALD:
The correct answer? It’s just that one. Just the normal script. PAUL LEWIS: There’s
some happy people. There’s some less happy people. JAKE ARCHIBALD: Yes. Although it was a
multi-select, it was only one of them that
was actually correct. PAUL LEWIS: Cheeky. JAKE ARCHIBALD: Scripts
are awful by default. They block parsing while
they download and execute. Deferred and async
scripts, on the other hand, they do not block the
parser while they download. The difference between the
two is when they execute. Deferred scripts execute
once parsing is complete. And they always
execute in the order that the HTML parser
discovers them. Async scripts, on
the other hand, they execute as soon
as they download. And that means they can
run in a different order. PAUL LEWIS: And you
may have noticed, async equals false was
in the list of options for that last question. JAKE ARCHIBALD: Yeah. It doesn’t do anything. The browser ignores the
attribute value completely. PAUL LEWIS: Yeah. So what you’re basically saying
is async equals false is true, which I absolutely
Yes, that is true. And that’s true of most HTML
stuff, like Boolean attributes. They’re either there
or they’re not. The exception is ARIA,
where you can actually set things to be false. PAUL LEWIS: True story. JAKE ARCHIBALD: So let’s talk
about which one of these– when to use the right
one, which one is best. PAUL LEWIS: OK. So having the script execute
in any order is probably risky. Because if you’ve got,
say, five async scripts, you’ve got 120
different permutations of execution order. And so if your scripts rely
on one another, one of them causes failure, then you
don’t know where you’re at. That’s a tricky bug to
reproduce and to solve. JAKE ARCHIBALD: Yeah. Deferred scripts are
better in this regard because they run at
a predictable time and in a predictable order. But if you’ve got this kind of– a really long article
and your script is to enhance a button that’s
at the very top of the page, it’s a big waste of time to
be waiting for the whole page to download just to enhance that
little button at the top there. PAUL LEWIS: Absolutely. So JavaScript
execution is always going to block the parser
and other JavaScript. So async scripts could actually
cause jank during the page load if they’re big or
complex and they just arrived during the
middle of your page load. JAKE ARCHIBALD: So the
answer really is it depends. Really, it depends. Test it and do whatever gives
the best user experience for users. PAUL LEWIS: It turns out,
tools, not rules is probably a good guiding principle here. JAKE ARCHIBALD: Tools not rules. PAUL LEWIS: Oh, we
should have said. At the end of this
session, will show a set of links to
resources and documentation for the things that
we’ve been talking about, in case you don’t
believe us or you want to learn more
about a particular area. JAKE ARCHIBALD: OK. So we’ve been discussing these
scripts here, but they’re old. They’ve been around for
years, but there is a new way to load JavaScript. Ooh. Scripts can be loaded
as ECMAScript modules. And it’s this type
equals module thing that makes it a bit different. Module scripts can be external
resources using the source attribute like this, or they can
be in line like normal scripts. The exciting thing you
can do with modules is use these import statements
to dynamically load scripts. And this is actually
supported in Safari, in the stable version right now. But it’s also behind the flag
in Chrome, Firefox, and Edge. But once it lands in
all of our browsers, I think it’s definitely the
best way to load scripts. PAUL LEWIS: Yeah. JAKE ARCHIBALD: It’s
good [? recall. ?] So on that note, here comes
a really cruel question. PAUL LEWIS: Devices
at the ready. Here we go. According to the specification,
which of the following scripts executes first? JAKE ARCHIBALD: That’s
a good quiz voice. PAUL LEWIS: Thank you. I’ve been practicing it– backstage, in my hotel room. It’s been very awkward. JAKE ARCHIBALD: So
what have we got here? PAUL LEWIS: So we got
type equals module, type equals module
with something inline, defer with something
inline, and then standard issue script there
but with defer on it as well. JAKE ARCHIBALD: Which
one executes first? Let’s see what
you’re saying so far. OK. So it’s kind of– there’s a
bit of a debate around two of the answers. [INTERPOSING VOICES] JAKE ARCHIBALD:
But it’s fairly– if you haven’t guessed
already, get a guess in. There’s no harm in
guessing because we are going to close the question. 3, 2, 1, and it’s closed. So what we’re seeing here? Some people think
script 1 is going to execute first, which makes
sense in terms of numbers. It’s the first number. I like that. That’s probably how we
actually write our questions. Some people thinking script 2,
which isn’t the first number. PAUL LEWIS: No, there you go. Thank you for that, Jake. JAKE ARCHIBALD: The answer
though, it is script 3. Ooh. Oh, yes. Someone is very happy
at the front there. OK. Here’s why that is. Like I said before, the
way scripts block execution by default while they download,
that was a bad design. A real design mistake. So module scripts have
a different default. They are deferred. But the same also goes
for inline module scripts. And this is actually pretty new
because regular inline scripts cannot be deferred. So in this case, the
attribute is totally ignored, making it just a normal script,
which executes immediately. So it’s first. You can also use async as
well on module scripts. And this causes it to execute
as soon as all of its imports have downloaded. PAUL LEWIS: Now, fetching
stuff from the network quickly is important, but
not having to fetch it at all is even better. So we’re going to take ourselves
a dive into some caching stuff. And there are two basic
types of cache usage that we’re interested in here. When the page fetches
something, it’s going to start by looking for
a match in the HTTP cache. Sometimes, the thing it finds
needs validating with a server. So it makes a connection
and says, hey, I’ve got this thing already. It’s this old and
it’s this shaped. And the server can
either say, no. Don’t use that. Here’s a newer version. Or, it sends back a tiny
message saying, yeah, you’re good to use
what you’ve got. Now, if that happens,
the cache sends what it has back to the page. Sometimes, however, the
browser makes a fetch. It finds a result
in the HTTP cache. But this time, it doesn’t need
validating with a service, so it just goes
ahead and uses it. It doesn’t even ask
the server at all. JAKE ARCHIBALD: And
that is faster, right? Especially for small assets
where just making the request, making that connection is
the majority of the work. PAUL LEWIS: The primary
way to tell the browser how it should use the cache
is the cache control response header, which takes
a variety of values. JAKE ARCHIBALD: A variety. But do you know what they
are and what they do? PAUL LEWIS: Because we didn’t. JAKE ARCHIBALD: No, we did not. But let’s find out if you do. Devices at the ready. Here comes the next question. So this one, what
does that header– what does that header
as a response header tell the browser to do? Does it say, don’t
put this in the cache? Does it mean, cache
it, but you can only use it after server validation? Or does it mean cache
it, and you can use it without server validation
for 31,536,000 seconds, which is a year? PAUL LEWIS: Yeah. So let’s have a
look at the voting. See how we’re doing. JAKE ARCHIBALD: Oh, I
love it when this happens. 50/50 on two of them. That’s exciting. PAUL LEWIS: Some happy,
some sad, some confused. JAKE ARCHIBALD:
There’s definitely one answer people are
thinking it’s definitely not. PAUL LEWIS: Should
we lock it in? JAKE ARCHIBALD: Yes. Get a guess in if
you haven’t already. PAUL LEWIS: 2. 3. 3, 2. JAKE ARCHIBALD: 8. PAUL LEWIS: 17. JAKE ARCHIBALD: 28. 42. Lock it. Lock it in. OK. So you’re saying cache
it, but you can use it after server validation. Or you cache it and use it
without server validation, some of you saying. The answer? Of course it is. You can use it without
server validation. I don’t know what
made some of you think must revalidate
means it must revalidate. That would be weird. In fact, it does mean that
the browser must be revalidate once the max age expires. If the browser has a copy of the
resource that’s under that age, it can feel free to use
it without checking in with the server. PAUL LEWIS: OK. What about this one? What does same caching
header as last time, except that the no cache– we’re using no cache
instead of must revalidate. JAKE ARCHIBALD: Same answers. Same question, just
must revalidate has been replaced with no cache. PAUL LEWIS: OK. Let’s have a look at the voting. JAKE ARCHIBALD:
It’s easy, right? Obviously. Also, once again, we’ve got
a sort of 50/50 situation between two of them. Oh, but one of them is winning. That’s good. PAUL LEWIS: I’m seeing a
lot of concentrating faces in the audience, which makes
me very happy on the inside. JAKE ARCHIBALD: Get a guess
in if you haven’t already. We are closing the
question in 3, 2, 1. And it’s closed. Right. OK. So we’re saying no
cache would mean do not put this in the cache. The answer is cache
it, but you can only use it after server validation. PAUL LEWIS: I don’t know
what made some of you think no cache means no cache. JAKE ARCHIBALD: Yeah. No cache is shorthand for
must revalidate, max age zero. So the additional max age we
have there is just ignored. No cache means the
browser may use the cache, but it must check
with the server first. We do not know why they
are named like this. It’s like they had a load of
features and some good names for them, and then
they put them in a bag and picked them out at random. PAUL LEWIS: They do say the
hardest problems in computer science are caching
validation and naming things. And this happens to
involve naming things to do with caching validation. JAKE ARCHIBALD: They
were destined to fail. PAUL LEWIS: So let’s have a chat
about what we should typically do here then. JAKE ARCHIBALD: Yeah. Well, like we said, it’s best
to avoid a request, if possible. So for sub resources, treat
your content as immutable. Give it a unique URL that never
changes, like we have here, cat.4e22 whatever. And let that cache for as long
as you can, which is a year. So if you wanted to
update this resource, you would need to
change its URL. There are lots of build system
tools that can help with this. One of which is webpack. But you know, Rails and
Python, Django, they all have their own. PAUL LEWIS: They
have plenty of them. But not all of your content
is going to be immutable. For example, a
page like about-us, or pretty much anything that the
user’s going to visit directly. In this case, it’s usually
best to use no-cache. And that means that
the browser will always check-in with the server first. However, if the page contains,
like, really private data. You can tell the
browser not to store it at all using no-store, which
is actually named quite well. JAKE ARCHIBALD: Yeah. Kind of came out of the
bag at the right time. [INTERPOSING VOICES] JAKE ARCHIBALD: Although, if
you’ve given an untrustworthy person or a piece of
software the access they need to read
your browser cache, then you kind of
have bigger problems. Some people will say it’s
just paranoia doing no-store. PAUL LEWIS: But there is another
caching pattern that we do see quite a lot around the web. And it does lead to some
pretty weird behaviors. Because sometimes,
want the benefit of avoiding going
to the network, but they haven’t set
up their build system to generate unique URLs. So they go with regular
URLs, like script JS. And they expect the content
to change over time, meaning they don’t want
to cache it for a year, but they take a guess. And they kind of go, oh, how
does a couple of hours sound? JAKE ARCHIBALD: Two hours. It sounds like a
good compromise. But it really isn’t. It’s a really bad compromise. And we see this everywhere,
like on a lot of static services as well. Don’t do this. Here’s why. Let’s say you’re serving some
HTML, CSS, and JavaScript. And you’re telling it
to cache for two hours. A user visits your
site and that means they download a lot, right? And they end up with those
resources in their cache and on their page. So far, so good. It’s all working. But let’s say an hour later,
you update your HTML, CSS, and JavaScript. So they have Version 2 now,
but you don’t change the URLs. Meanwhile, user’s browsing
around the web and the browser just decides ah, I’ve
had enough of those, too. And it’s going to remove
the HTML and the JavaScript from the cache. PAUL LEWIS: And maybe
you’re thinking, why would the browser ever do that? But the browser
can remove whatever it wants from the cache
whenever it wants to. Maybe it just wanted
some space back. JAKE ARCHIBALD: Yeah, and also
because these assets have a max age, and that’s from the
point they’re downloaded, you can get them out of sync. They can expire at
different points. So now the user
returns to the site. They’ll get the
CSS from the cache, because it’s still
within the two hours. But the other assets, they are
going to come from the network. PAUL LEWIS: Yeah,
so now you’ve got Version 2 of your HTML
and your JavaScript. But you’re still on
Version 1 of your CSS. JAKE ARCHIBALD: Yeah,
and the result of that– PAUL LEWIS: Eh, uh. JAKE ARCHIBALD:
It could be fine. You could get away
with it, maybe. Or you could end up with a
lot of broken, unstyled stuff appearing on the page. PAUL LEWIS: Basically,
it’s a big gamble. And it’s going to be very,
very hard to figure out why if it breaks. So don’t do that if
you can avoid it. Instead, either use no-cache
or immutable resources with a year of caching. So, so far, we’ve covered
parser blocking and caching. But another part of
page load is timing. Now some resources start
downloading pretty late, and the performance
can suffer as a result. The most common one that we
see is web fonts, I would say. JAKE ARCHIBALD: Yeah. PAUL LEWIS: And
fonts are defined in your CSS, including
how to download them and where to use them. So once the browser has
downloaded your CSS, it performs a recalc to apply
all those styles to the page. And at this point,
it discovers that it needs a web font for one
or more of those paragraphs on your page. So it begins fetching it. Meanwhile, the browser lays
out the page and paints it. But this paint is going
to be missing the text. That needs the web font. Oh, yeah. We’ve all seen this. And we’ve all sat
there going, really? Really, really? I just wanted to read it. And it’s pretty
frustrating, right? But once the font
has downloaded, the browser performs
layout again and paints the page, this time
with the text using the web font. JAKE ARCHIBALD: So
as you can tell, this isn’t really optimal. The font starts downloading
so late, and the result of it is, the user is left
without content. Well, they actually have
the content on their device. It’s just the browser is
refusing to download it. PAUL LEWIS: Absolutely. JAKE ARCHIBALD: And
refusing to paint it, right? PAUL LEWIS: Now you can
improve things a lot using link rel preload. With this in the head
of your document, you’re telling the browser
that you need the resource as part of loading the page. So that means the download
can happen in parallel– ooh– with the CSS. JAKE ARCHIBALD: Right,
so now you can see here, the time between the CSS
download and the font download is massively reduced. And that means the user
gets content quicker, which is great. PAUL LEWIS: Now, when
you use link rel preload, the response is actually stored
in a special preload cache until the browser needs it. JAKE ARCHIBALD: So yeah,
we’ve got this preload cache. We’ve got the HTTP cache. But there is another. In HTTP/2, the browser can
ask the server for something, and the server can say,
yeah, sure, here it is. But also, here’s
some other stuff that I think you might need. This is called HTTP/2 push. The server sends down
an additional response and the information
the browser needs to know for when it can
use those responses. PAUL LEWIS: Thing
is, this cache, they end up– it’s a
completely different cache from the other two. Which brings us to
our next question. Devices at the ready. JAKE ARCHIBALD: Which cache
does the browser check first? Is it the HTTP/2 push
cache, the preload cache, or the HTTP cache? PAUL LEWIS: This is a cruel one. It’s not one I knew until
talking to the networking team [INAUDIBLE]. JAKE ARCHIBALD: I think
this is bearing out what we’re seeing here, which is– PAUL LEWIS: Well, there’s one
answer people are kind of– JAKE ARCHIBALD: Oh,
yeah, actually– PAUL LEWIS: –others. JAKE ARCHIBALD: Oh, they’re
getting less sure now. PAUL LEWIS: Now you see,
there’s– confidence is waning, Jake. JAKE ARCHIBALD: Oh, OK. PAUL LEWIS: It’s going– definitely take a guess
if you haven’t already. Make sure you hit
that submit button. JAKE ARCHIBALD: We’re
going to close it. PAUL LEWIS: We are
closing the question. ALL: 3, 2, 1. PAUL LEWIS: It’s closed. JAKE ARCHIBALD: We’re out. PAUL LEWIS: Ooh, the HTTP
cache was winning that one. It’s a popular answer. It’s a popular answer
among Googlers, I seem to remember
when we did rehearsal. And just like the
Googlers, wrong, wrong. The correct answer
is the preload cache. JAKE ARCHIBALD: Absolutely. As you can see, some
of these questions are deliberately obscure. So really, do not feel bad
if you’re getting them wrong. Like we said– PAUL LEWIS: Unless
you’re a Googler who was in one of our
rehearsals, in which case you should feel pretty bad. JAKE ARCHIBALD:
All those Googlers were fired, by the way. So they don’t work here anymore. [LAUGHTER] In fact, if you do end
up with a top score, it probably means you didn’t
learn a lot from this talk, so you’ve kind of wasted your
time being here, to be honest. PAUL LEWIS: Unless
you win the mouse pad. JAKE ARCHIBALD: Unless
you win the mouse pad. That’s a desirable prize. PAUL LEWIS: I’m glad they didn’t
applaud that because that would have been– good, good, fine. JAKE ARCHIBALD: So yeah. Free cache is in play here. And it is pretty complicated. But knowing this stuff can help
prevent loads of kind of weird, [INAUDIBLE] bugs. So when your page contains
a preload element, the browser fetches it as
normal through the HTTP cache, potentially to the
server, and it ends up in this memory cache that
sits alongside the page. So the things to note from this
is that your preloaded stuff may come from the HTTP cache. But also, since the preload
cache sits with the page, other pages will not use it. They may have their
own preload caches. But one page won’t use
another page’s preload cache. PAUL LEWIS: Yeah,
so that means it’s pointless to use link
rel preload to try and preload things
for another page, maybe the next page,
because that page is going to have its own preload cache. JAKE ARCHIBALD: The HTTP/2
cache, on the other hand, it sits with the connection. And that makes it pretty
different to preload. Because two pages can
share an HTTP connection, so they can share
the same push cache. Things you push
intended for one page may end up being
consumed by another. PAUL LEWIS: Yeah, that’s
pretty complicated, isn’t it? JAKE ARCHIBALD: And also,
because the server initiates the push, you could be pushing
something the user already has in their cache. The spec does say
that browsers can send a message to
their server saying, no, stop that, I’ve
already got it. But no browser does this yet. PAUL LEWIS: So the answer
to the actual question, the question that we
asked, the browser checks the preload cache first,
then the HTTP cache, and then the push cache. JAKE ARCHIBALD: Yes. Yes, that’s it. PAUL LEWIS: Yeah, [INAUDIBLE]. So like you said, it is a
good thing to keep in mind. It is a bit out there. But at the same
time, if you do find you’ve got weird
behaviors, then it’s good to know where
to start looking. JAKE ARCHIBALD: Yeah, I think
HTTP/2 push is dead powerful. But it’s pretty low-level. And in many cases,
link rel preload is a simpler, more
reliable solution. And it definitely seems
to catch people out less. And DevTools are
much more helpful when things are going wrong. PAUL LEWIS: Absolutely. So that’s the networking
round, if you like, complete. Should we take a look
at our leader board? JAKE ARCHIBALD: Yes, we shall. Let’s see how you’re doing. PAUL LEWIS: Mm. JAKE ARCHIBALD: Oh, oh. PAUL LEWIS: [LAUGHS] [INTERPOSING VOICES] PAUL LEWIS: Here we are. We have one person in
the lead at the moment. JAKE ARCHIBALD: Andrei,
in first with 20 points. That’s pretty good. But we’re only halfway through. PAUL LEWIS: Absolutely. JAKE ARCHIBALD:
Less than half way. PAUL LEWIS: So if you’ve
been playing this quiz, and you’re competing
with colleagues, and you’re thinking, well, they
know plenty of network stuff, they’ve got an unfair
advantage, well, hold on. Because the thing is,
CSS and rendering, that might be your thing, and
that’s your time to shine. JAKE ARCHIBALD: Mm. PAUL LEWIS: Because
indeed, let’s talk a little bit about rendering. JAKE ARCHIBALD:
Yeah, animations are important in communicating
parts of your UI to the user. And they also just
look really cool. We’ve had a lot of fun with
animation so far here, right? But a badly performing animation
can be really jarring, often worse than no animation at all. PAUL LEWIS: Yeah, and
our modern browsers have an animation fast-path
known as compositing. And this means that the browser
takes a particular element and it temporarily isolates
it into its own layer. Now if the conditions
are correct, the browser does this
automatically for an animation. Now this minimizes the
impact of the animation as the browser
doesn’t have to keep repainting the thing behind
the element that’s actually doing the animation. And at the end of
the animation, it can merge down or
flatten that content back with the other
content on the page. JAKE ARCHIBALD:
But as Paul said, the conditions need to be
correct for this to happen. So devices at the ready. Here comes a question. We’re animating a
circle in an SVG. Which of the
following animations will be automatically
composited in Chrome 57? PAUL LEWIS: So it’s the center
x, center x and transform, transform, or opacity. And you can select, I
believe, all that apply. I need to get in on the– JAKE ARCHIBALD: [INAUDIBLE]
quiz voice again. PAUL LEWIS: I like
your quiz voice. I’ll give it a go on
the next question. JAKE ARCHIBALD: All right. PAUL LEWIS: How
are you voting now? OK, so strong feelings
about kind of three of them. Less confident with one of them. Ooh, get a guess in if
you haven’t already. We’re going to close
the question in– ALL: 3, 2, 1. PAUL LEWIS: Don’t
forget to submit. JAKE ARCHIBALD: And it’s closed. PAUL LEWIS: There you go. OK, so we’re sort of saying– we’ve got transform there. So yeah, the opacity
and transform. The correct answer– JAKE ARCHIBALD: Ooh– PAUL LEWIS: It’s none of them. JAKE ARCHIBALD: None of them. [LAUGHTER] Cruel, isn’t it? PAUL LEWIS: Yeah, I know. I know. Yeah, for implementation
and legacy reasons, in Chrome today– and I
think it’s fair to say, we’d love to see this change– compositing never
happens for elements inside of an SVG element. JAKE ARCHIBALD: You used an
out-of-date emoji there, Paul. That’s not on-brand. PAUL LEWIS: Awkward. JAKE ARCHIBALD: This
means your animations are going to paint as a flat,
single layer every frame. PAUL LEWIS: Yeah, and in
case you were wondering, Edge and Firefox do currently
support composite SVGs, but Safari 10.1, like
Chrome, does not. But the good news
is it’s something that we are looking at. And we’ll post a link
to the Chromebook at the end of the quiz. So you’ll see it in the
resources on your devices. OK. So that’s SVG. Let’s talk about your
standard issue DOM. You know, your non-SVG DOM. JAKE ARCHIBALD: We
are animating a div. Which of the
following animations can be automatically
composited in Chrome 57? Is it margin-left, width
and transform, transform, or opacity? PAUL LEWIS: Can I commend
you on your quiz voice? JAKE ARCHIBALD: I
really like that one. It’s based on the guy from
the “Weakest Link” in the UK. Let’s take a look at the voting. PAUL LEWIS: Similar kind of feel
to last time, I’d say, this. JAKE ARCHIBALD:
People are holding onto their previous
answers, it seems. PAUL LEWIS: Perhaps. JAKE ARCHIBALD: But will
that pay off for them? It’s a bold play. Should we play it? 3, 2, 1, and we’re closing. PAUL LEWIS: There we are. Tricky, tricky. JAKE ARCHIBALD: So
we’ve got the width and transform, opacity and
transform, the margin-left, less confident on. The correct
answer’s, of course– ooh. PAUL LEWIS: Pretty
right as a room. JAKE ARCHIBALD: Well done. PAUL LEWIS: That
was a good show. JAKE ARCHIBALD: Good job. PAUL LEWIS: Yeah, the answer is,
any animation that transitions on opacity or transform. Yeah. And if you declare the
animation up front using CSS and transitions, or
keyframed animations, the browser can probably
move the whole thing away from the main thread. JAKE ARCHIBALD: Yeah and
if it happens the animation can continue jank-free, even
if the main thread is busy. However, an element that’s
composited and declaratively animated may still have a
frame-by-frame dependency on the main thread. PAUL LEWIS: Absolutely. Now that correct answer, of
width 2 seconds, transform 2 seconds, is one of these. Now sure, the element is
going to get its own layer if you animate transform. That is absolutely true. But if you animate
width, even if you make something
have its own layer, you will trigger recalc styles,
layout, and paint per frame. And these are all
main-thread-bound pieces of work. JAKE ARCHIBALD: Mm. Yeah, and it’s true that
things are getting faster in terms of layout and paint– or at least phones
are getting faster. Trying to do layout
and paint per frame is not normally 60 frames a
second fast on a smartphone. In fact, layout is scoped to the
DOM, so the bigger the document you have, the longer it tends
to take in most situations. PAUL LEWIS: That’s not the
kind of thing you typically want from an animation. JAKE ARCHIBALD: No. So the most performance
solution here is to stick to
transforms and opacity and animate only
those properties. PAUL LEWIS: Yeah, so just
because an element has its own layer doesn’t
mean that it’s safe to start animating
properties like left or margin or something like that. JAKE ARCHIBALD: OK. Let’s switch this
up a little bit. Let’s switch to some
event-based animation. Let’s get some JavaScript
in there as well. Devices at the ready. Is this your favorite? PAUL LEWIS: Yeah, I
really enjoy this one. JAKE ARCHIBALD: Here
comes the next question. You have an element with no
transform and the following code. According to the
HTML specification, what happens next? All right, talk me through the
code here, what’s going on? PAUL LEWIS: So
we’ve got on click. There’s a transform, which
translate X 200 pixels. Switch on. A transition on transform. And then we set the
transform to 100 pixels. Does it slide to the right,
does it slide to the left? Does it do the “Macarena,” or
does it snap to 100 pixels? JAKE ARCHIBALD: Let’s see
how people are voting. PAUL LEWIS: Oh, we’ve
got some strong opinions. There’s one answer
there that people– what’s interesting
here is there’s two answers that are unpopular. And I thought one would
have been significantly less popular than any of them. JAKE ARCHIBALD: [LAUGHS] PAUL LEWIS: Turns out not. OK. Get a guess in if
you haven’t already. Hit Submit. We are closing the question in– ALL: 3, 2, 1. PAUL LEWIS: It’s locked in. JAKE ARCHIBALD: Interesting. Some people do you think
it does the “Macarena.” PAUL LEWIS: Snapping. And right. So 30– JAKE ARCHIBALD: That’s 30%. That’s a lot of people who
have clearly just given up on the quiz. [LAUGHTER] I don’t know what to say, folks. Put it this way, one
of the highest scores we got when we did
this in rehearsal was our design advocate. And he was just like, oh, I’m
just making random guesses– PAUL LEWIS: Guessing. JAKE ARCHIBALD: –and he
got one of the top scores. PAUL LEWIS: I don’t
even know anymore. JAKE ARCHIBALD: So
that’s pretty good. The correct answer, of course– when it appears on the screen– it slides to the right. Now, Paul, I did
maths at school. And I was led to
believe that 200 is a bigger number than 100. Therefore, moving from 200
to 100 would be to the left. PAUL LEWIS: And while
I agree with you, you did just say maths. And I think here it
would probably be math. JAKE ARCHIBALD: I don’t know. It’s mathematics–
so the abbreviation is maths is my strong opinion. But you know what, America,
I could live with it– I could live with it. But then you took
that s that you saved, and you put it on
the end of Lego. [AMERICAN ACCENT] Ooh, Legos. The toy is Lego. Legos is an island off the
coast of Spain, probably. I don’t know. I’m not a geographist. PAUL LEWIS: Shall we– let’s move on before we trigger
an international incident. JAKE ARCHIBALD: The
group doesn’t like that. [LAUGHS] OK. So why does it slide
to the right then? What’s going on? PAUL LEWIS: It’s because
browsers try and reduce their workload. And the HTML spec
accounts for this by saying that a task is
queued to run event callbacks. And at the end of
the current task, the rendering path begins. And this is where
the browser takes stock of any style changes. Now by that point, that
translate X 200 pixels has been overwritten by
the translate X 100 pixels. So as far as the
browser is concerned, the animation should be from no
transform at all to 100 pixels. And that means when
the frame is shipped, it’s going to
slide to the right. JAKE ARCHIBALD: So although
the DOM layer sees– has set the transform
to 200 pixels, we overwrite that value before
the style system in the browser takes any note of it. PAUL LEWIS: Yeah, exactly. So what we need to do, if we
want it to slide from the right to the left, is to make sure
that 200 pixel transform takes hold before we overwrite
it to 100 pixels. So with that in mind, here
comes the next question. You have an element with no
transform in the following– it’s the same question, really. Same question. But the difference is we have
that final transform wrapped inside a request
animation frame. Does it slide to the right? Does it slide to the left? Does it snap to 100 pixels? Or does it gain sentience
and feel only sadness? Basically, a web developer. Let’s see how you are voting. Less sure this time,
dividing the room. Except for one
particular answer. Wonder which one that is. Get a guess in, if
you haven’t already. We are closing the question. 3, 2, 1. It’s locked in. So what are we seeing here? Kind of, pretty much
equal guessing among– that tends to happen with
this quiz about this point. It all just spreads out evenly
among the non-ridiculous answers, shall we say. The correct answer
though, is, once again, it slides to the right. JAKE ARCHIBALD: What? PAUL LEWIS: Dun-dun! JAKE ARCHIBALD: What? PAUL LEWIS: Yes. JAKE ARCHIBALD: Why? PAUL LEWIS: Yes. JAKE ARCHIBALD: Tell me. PAUL LEWIS: Because
maybe you’re thinking– JAKE ARCHIBALD: Why? PAUL LEWIS: OK. Because– you said the
transforms are 200 pixels. And you maybe thought,
eh, we waited a frame, and then we set
it to 100 pixels. Surely it took hold. We got the 200
pixels to take hold. And then we animated. Like that’s what you’d expect. But no, the HTML spec
says, once again, things should be a little
bit different to that. JAKE ARCHIBALD: Yeah,
it’s the same as before. Our event call back
runs as part of a task. And then we get to the rendering
bits of the event loop. And that involves running any
requested animation callbacks, and then the browser thinks
about styles and such, and doing the actual painting. Because animation
callbacks happen before style recalculation,
the net result, it’s exactly the same before. We overwrite the value before
the style system sees it. PAUL LEWIS: OK. So let’s talk about
what we could do then if we wanted to solve this. Now, one fix that
we could apply here would be to not call
request animation frame one. So no, but in fact,
call it twice. Just take that in. Enjoy that. Now, if you request an animation
callback while the browser is running an animation
callback, then those will run in the next turn
around the event loop. After style recall, which would
mean that you’ve definitely got something at 200 pixels
before transferring it to 100 pixels. The downside here is that you
got ridiculous looking code, and that it would
be an extra frame before the animation starts. And in fact, in
Safari, you’d actually wait two frames, because
they don’t follow the spec. Though they do follow what,
I think, was our expectation. JAKE ARCHIBALD: Yeah. Initially we thought Chrome
was buggy, in this case. Until we actually
hooked up a spec. PAUL LEWIS: We were all ready. JAKE ARCHIBALD: I was like
see, CR bug and everything. PAUL LEWIS: Ready. And then, oh, no. But perhaps you don’t
want to do this, kind of, ridiculous double graphing. And instead you want to force
that style recalculation to happen synchronously
so the style system sees that 200 pixel transform before
you change it to 100 pixels. Shall we have a
question on that? JAKE ARCHIBALD: Yes. PAUL LEWIS: Here we go. What could go in here? And by here we mean where
it says, answer goes here. To force a synchronous
update in Chrome 57. getBoundingClientRect,
offsetWidth, getComputedStyle, innerText. Select all that apply. JAKE ARCHIBALD: Ah,
multi-select one. Let’s see how people are voting. OK. So we’re confident
on one of them, unsure about to two of them. Pretty certain
one of them isn’t. Seems to be what the
room is saying so far. Though it’s kind of rising. We are going to
close the question in a couple of seconds. So take a guess, if
you haven’t already. Make sure you hit
the submit button. Closed in 3, 2,
1, and it’s done. PAUL LEWIS: getComputedStyle
there being the most popular of all the answers. JAKE ARCHIBALD: Interesting. But also the correct answer. What is it? It is– PAUL LEWIS: Everything
but getComputedStyle. [LAUGHTER] Who knew? We didn’t. Well, I didn’t. You did. Here’s why. So the browser starts off
knowing the styles and layout for every element,
because it needed to know all of that stuff
in order to draw what you saw there, the frame before. But then we set
translateX to 200 pixels, meaning the browser’s
calculations are no longer valid, no longer up to date. And that isn’t a problem,
because the browser will just, like, recompute
everything once it needs to update the actual rendering. However, if we call
getBoundingClientRect, offsetWidth, or
innerText, the browser has to recalculate the style
and the layout synchronously in order to give you
the correct answer. Yeah. So if you’re asking for,
say, the width of an element, the browser has to figure
out what you changed, what the impact
of that change is. And then and only then can
it give you the answer. JAKE ARCHIBALD: Right. And all of the correct
answers cause that to happen. Probably the most
surprising one is innerText. And innerText actually
has a layout dependency, because it won’t give you the
text of the inner elements that are display-none. And it also has some
dependencies on line layout, as well. PAUL LEWIS: The
problem here is mostly that these are all fairly
heavyweight options. They trigger both style
calculations and layout synchronously. Not per frame, like in the
previous example, admittedly. JAKE ARCHIBALD: Yeah. And since layout calculations,
they scale with the DOM size, you risk pushing the start
of your animation back, which may make your app feel laggy. You press a button. You have to wait
a few milliseconds before it starts up. PAUL LEWIS: Now, what
we’d probably like to do is avoid calculating
layout, if at all possible, which we can do with
getComputedStyle. And you might have
noticed that wasn’t one of the correct answers. And that’s because things are
ever so slightly nuanced here. Because you might
think getComputedStyle captures the styles, but no. When it’s cold, you might think
that, but not, in fact, it’s not. No, because if you
update the styles before checking a property of
the computed styles object, you’ll get the second
value and not the first. JAKE ARCHIBALD: And
this blew my mind when you first showed me it. The styles aren’t
computed when you call the big
getComputedStyles function. No, they are computed
when you access one of the properties of
the object it returns. So to work around this weirdness
you call getComputedStyle, but also access one of the
properties, such as transform. PAUL LEWIS: And in the question,
technically, we didn’t actually access the transform property. So I wouldn’t do it. JAKE ARCHIBALD: All that said,
we overlooked one option, which is using web animations. And this is a nice
imperative API. Kind of jQuery like. And it will do these
kind of animations. And will make use of
compositing and everything. The problem is, web animations,
not great support out there. It’s basically just partial
support in Chrome and Firefox. And because it’s
in Chrome, it means you get it in, like, Opera, or
in Samsung Internet, et cetera. But not in Edge or Safari. PAUL LEWIS: Yeah. So while it is an
option, for compat, you’re probably going to use
getComputedStyle for the time being. OK, so with both network
and rendering people, hopefully, fairly happy. But it isn’t over yet. JAKE ARCHIBALD: Oh, no. PAUL LEWIS: Let’s bring
on the quick fire round. JAKE ARCHIBALD: By which we
mean the silly questions that didn’t really fit into
the narrative of the talk. PAUL LEWIS: Pretty much. JAKE ARCHIBALD: We just
wanted to ask them. OK. So our first one of these. Ready? Let’s go. When we say quick
fire, we mean quick. PAUL LEWIS: What happens with
.foo min height 300 pixels, max height 200 pixels? Will it be 200 pixels tall? Will it be 300 pixels tall? Will it be 0 pixels tall? Will it crash all browsers
in a three mile radius? JAKE ARCHIBALD: Get
an answer in quickly. Well, let’s see how
people are voting. So we’ve got one answer’s
particularly popular. Hit submit, take a guess,
because we are closing the question in 3, 2, 1. PAUL LEWIS: It is called
quick fire for a reason. JAKE ARCHIBALD: And we are out. OK. 200 pixels tall is the
most popular answer there. PAUL LEWIS: Now, according
to the CSS spec, Here we go– ding. JAKE ARCHIBALD: 300. PAUL LEWIS: The
algorithm for height is figure out the
tentative height. And then if it’s bigger
than max height, reduce it. And if it’s smaller than
min height, grow it. JAKE ARCHIBALD: Literally
no idea what you just said. PAUL LEWIS: Yeah, I
didn’t think you did. It basically means min
height always wins. JAKE ARCHIBALD: OK. Fair enough. PAUL LEWIS: Here we go. JAKE ARCHIBALD: Let’s move on
to another quick fire question. This is my favorite. PAUL LEWIS: After running this
code, which of the following is set to 1? And you can see we’ve
got an Int8Array. And we’re setting a bunch
of items there to 1. So the suggestion here is that,
possibly, maybe, one or more of them is not going to work. So select all that apply,
and get an answer in quickly. Big thanks to the VA team
who showed us this one. We didn’t know
anything about it. JAKE ARCHIBALD: No,
they were wonderful. PAUL LEWIS: Judging by the
spread of answers there, you know nothing about it. It’s fine. We’re all friends here. That’s great. But we’re locking it in, in– JAKE ARCHIBALD: 3, 2, 1. There we go. OK. So bleh, who knows the
correct answers though? Here they come, from the
server, which is getting slow. OK There we go. Yeah. Correct answer, 0.9, and 1.0. Why? PAUL LEWIS: Yeah, the
reason is pretty weird. So when you do this kind of
thing, when you assign, like, this with a string,
JavaScript needs to decide if you’re assigning
to a property of the object or if you’re assigning
to an index of the array. Now, numbers are treated
as array index assignments, but so are strings, if the
string is a canonical string representation of a number. JAKE ARCHIBALD: And when I first
heard that I had no idea what it meant. PAUL LEWIS: I still don’t. But I can follow along. JAKE ARCHIBALD: So for
example, what’s this about? PAUL LEWIS: OK. 0.9 is not a canonical
representation, because the canonical
representation is not 0.9. JAKE ARCHIBALD: Yeah. This means the browser’s
going to treat it as a property assignment. And that works fine. PAUL LEWIS: Same
goes for 1.0, because the canonical
representation is just 1. However, 1.1 is the canonical
representation of 1.1, so JS treats it as a number. JAKE ARCHIBALD: And this means
it tries to assign to the 1.1th item of the array. But array indexes
need to be integers. So it’s just silently ignored. PAUL LEWIS: Yeah. Why would it throw an error? So the same goes for
1.2, same kind of deal. JAKE ARCHIBALD: Right. Second to last question. So we are going to move on, if
my clicker continues to work. There we go. That makes me happier. Devices at the ready. Here we go. PAUL LEWIS: How many
elements are created? JAKE ARCHIBALD: Oh. OK so we’re assigning to
innerHTML, then plus equals, plus equals, plus equals, how
many elements does it create? PAUL LEWIS: One,
four, 10, or 16. Let’s see how they’re voting. JAKE ARCHIBALD: Quick fire. So get your answer in quickly. We’ve got two strong
answers, and two people who we’re pretty dismissive of. Guess if you haven’t
guessed already. We are closing in 3, 2, 1. And we are closed. So we’re saying four and
one, the most popular answers of the room. PAUL LEWIS: OK. JAKE ARCHIBALD: The correct
answer, of course, is 10. Eh! PAUL LEWIS: Yay! JAKE ARCHIBALD: So
why is this then? OK. So when you use plus
equals, it is equivalent, it’s just shorthand
for reading the value, and adding more to it. It’s a read and a write. So if we expand this out further
we create 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 elements. There you go. PAUL LEWIS: So there you go. If you really want to append
a string to an element you can use insertAdjacentHTML,
which is ancient, and apparently brilliant. I get BoundingClientRect. JAKE ARCHIBALD: Thank you,
Internet Explorer 4 for that API. PAUL LEWIS: This will
actually create four elements. JAKE ARCHIBALD: So we’re
going to do the final question of the whole quiz now. This might be my
favorite, this one. PAUL LEWIS: Given
this string of HTML, which resources are requested? JAKE ARCHIBALD: So
what have we got here? We’ve got an image of a source. Excellent. We’ve got a script of a source. You know, the link
roll style sheets. Linkroll preload. OK. So it’s a select many. So select all that
you think apply. PAUL LEWIS: Yep. One, two, three, or four. Ah. JAKE ARCHIBALD: Let’s see how
the answers are coming in. Interesting. A real spread here. PAUL LEWIS: So it’s
kind of confident. I guess. JAKE ARCHIBALD: Wow. PAUL LEWIS: Did
anyone else see that? JAKE ARCHIBALD: I think there
is a large amount of bird mess has just landed
right in front of us. That is incredible. PAUL LEWIS: The birds are
not happy with the quiz. JAKE ARCHIBALD: Yeah. Someone didn’t pick the right
answer in the last round. Fair enough. OK. I’m going to step
back a little bit. We are going to close
the question in 3, 2, 1. There it goes. PAUL LEWIS: OK. So sort of spread
there of the answers. JAKE ARCHIBALD: But which
ones actually are meant to be requested? It is one. Just one. And this question
is really evil. And I don’t know how
many people might have spotted what was going on here. PAUL LEWIS: Yeah. So even though this
is an I-M-A-G-E image, the browser does treat
it as an I-M-G image. So yes, that one’s
going to download. This script uses
source, S-O-U-R-C-E, rather than S-R-C . So the browser just ignores it. Just ignores it. Doesn’t download. Don’t like that one. These use the
correct attributes. But have you noticed that,
ooh yeah, that code highlight, well it’s basically
all but gone. Why has it changed? JAKE ARCHIBALD: Well, in HTML,
script elements cannot be self-closing. That doesn’t work. You have to close scripts with
a proper closing script tag. PAUL LEWIS: [LAUGHS] So if the
browser parses those two link elements as JavaScript, and now
it’s going to throw an error. They definitely don’t download. JAKE ARCHIBALD: Sorry. That was horrible. PAUL LEWIS: Sorry. Not sorry. Completely not sorry. JAKE ARCHIBALD: Well,
so this is it’s. The moment we’ve been waiting
almost 45 minutes for. Who are the winners
of the mouse pad? Let’s find out. Oh. Ivan. Andrei. PAUL LEWIS: Andrew Betts! JAKE ARCHIBALD: Andrew Betts. There he is there. PAUL LEWIS: Congratulations. JAKE ARCHIBALD: Excellent
But all three of you have won mouse pads. A big round of applause
to our three winners. PAUL LEWIS: So after the
session, come find us. Come to the front
with your phone and prove that you did
actually get that score. JAKE ARCHIBALD: Yes. And
now shows a set of links describing the detail
behind some of the questions that we’ve asked today. And with that, it’s
seen a pleasure. It’s been a blast. Thank you so much
for playing along. Thank you, guys. Cheers. Bye. [MUSIC PLAYING]


  1. Some links for the various things we talked about: – A deep dive into script loading – ES6 modules in depth – ES6 modules – the browser-specific stuff – Using link rel=preload – The order of caches – Chrome bug: Compositing within SVG – Anatomy of a frame – The browser's event loop: Tasks vs microtasks – visibility: visible undoes visibility: hidden – The code behind Big Web Quiz – How the Big Web Quiz music was scheduled

  2. Hey, great talk, no hard feelings but considering people answers to the quiz feels like its either freshers sitting there or below average developers.

    Once again great show guys.

  3. Great session, very educational and entertaining and luckily not "cringe worthy" like other talks where hosts try to be funny. I'm really interested on the app architecture, could you guys do a Supercharged episode on that?.

Leave a Reply

Your email address will not be published.