Hello? Hello, everybody. How is the day going? HTTP we have to do that again. How is the day going? HTTP headers for the responsible developer. Let me tell you about my journey
on the web. I was one of these lucky people that had an Internet connection at home very
early because my father was a techsavvy person. But in the beginning, I had no idea what to
do with the Internet, I could Google or surf, that was it. I was whatever, 12 years old
and it was not that exciting. But then I discovered this website, woot.com. Any Germans around?
That was one of the first social networks in Germany. And there I was, 1999. This is
where I'm coming from, the middle of nowhere in Germany. And I found myself chatting to
people if Berlin. Mainly about music. This is when I found out for the first time that
the web actually connects people. It's not about Googling stuff, it's about connecting
people. Then I moved to Berlin and I had a different
job initially. In 2010 something interesting happened, I became a web developer. Which
was cool. But then the statement that the web connects people actually changed. We as
developers have a lot of power. And I 100% believe that we connect people. Because we
are building stuff for the Internet. We enable people. And we help people by the
stuff that we build. So, let me quickly introduce myself. Hey, I'm Stefan. I work for a company
called Twilio. We do communications as an API, S MS and phone calls, and check that
out. And the most important thing is, hey, I'm Stefan, and I want to be a responsible
developer. So, when we look at the global population,
you will find out that 1999, there I was in my little bubble north of Germany. Not much
going on. But where actually the most Internet users are coming from today? So, they're coming
from China, India and the United States. But this is just global statistics, right? But
I also do run a private blog. And only the last month I had 300 people from Brazil reading
articles. I had 100 people from Vietnam. And I had 80 people from South Africa. That gets
me really excited, right? Who am I? I'm writing stuff and people in Brazil are reading my
stuff. But in the end that really doesn't matter because we as web developers should
be building for everybody. And when responsive web design came up, I heard this sometime
way too often. We don't have users coming from a certain area. We don't have users that
use a certain device. When you say these kinds of statements, you're creating a chicken and
egg problem. When you don't build stuff that works for people under certain conditions,
these people won't use your stuff. But building a good website these days is
actually very, very hard. What do you have to do? You have to consider design. Colors
around the world are different. You have to bring up good content. You have to consider
web performance which is a big topic by itself. You have to make yourself accessible because
there maybe people that visit your sites with assistive technology. And you have to find,
what should I use, actually? Frameworks are a thing. You have to optimize the network
stack and you have to make it work on several devices. And there are many, many more factors
out there. And in the next 21 minutes I want to talk about the network stack. So, let's
talk about HTTP. So, basically when your browser makes a requests
for a resource, what it does, sends value pairs, these are called request headers. And
the server responds with another set of key value pairs and the actual resource that you're
asking for. So, we're dealing with responsive request headers.
And when I started preparation for this talk, it was trending, so I had to buy a dot Dev
domain. You can see the responsible dot div and the site, but it right now has JavaScript
disabled. You see when I refresh it, there is some stuff going on. First of all, the
script is hijacking, adding unicorns and stuff. But going to this, you can pretend to be my
site. You can track what I'm doing, pretending to be my unicorn, not responsible unicorn,
but my Dev site. I wanted to make it better just using headers.
And the web is scary place. A few months ago, this was in the news. Lots of websites were
mining cryptocurrency and the developers that built these sites didn't even know about this.
And the reason for that is when we're building for the web, we're relying on other people
building software. Open source is the thing and we're also thirdparties from different
domains. So, we always rely on others and our belief that the web has to be safe. The
biggest part of being safe is HTTPS. So, without HTTPS, what is possible is that
someone can Open up a public WiFi and you're browsing with HTTP, this person could pretend
to be the WiFi and get the requests and mess with you. Or get the passports that you're
sending over HTTP. HTTPS lets you use HTTP/2 and service workers and media. And in my bubble,
I think it's the standard. But there's a site out there called why no HTTPS and it is many,
many sites not enforcing HTTPS yet. When you go into the list, you find out that there's
a massive German media outlet not enforcing HTTPS which is surprising.
When you run on HTTPS, you want to ensure that it is always HTTPS and on a secure connection.
So, what you can do is you can set the strict transport security header which you can define
a max H property in seconds. This will tell the browser, hey, please only use this website
or these resources over HTTPS. You can define how wide it should range. And you can, if
you want to go the extra mile, you can define a preload director which basically allows
you to supplement your site to another site, which is called HTTPS preload. And the thing
about that is that browsers internally keep lists of websites that should only be on HTTPS.
This is the configuration profile in Chromium. It's thousands of sites that will never work
on HTTP. If you wonder why dot Dev domains are not over HTTP anymore, that's the reason.
They're in this file. But HTTPS is not only about security. What happens when you type
in the address of the browser? It the make an HTTPS request and could lead to a delay
of 35 seconds depending on the connection. And you can skip this request because the
browser knows we're going HTTPS. That's it. So, how is the support for HTTPS? We're pretty
green here. Pretty sweet. But enforcing HTTPS is not the easiest thing in the world when
dealing with big projects when a lot of people are putting a lot of source code in your codebase.
How do you tackle this approach to go over HTTPS? When you run your site over HTTPS and
you make a request to an HTTP, it may be blocked by the browser. You can set a content security
header with the directive and this magically updates all the requests to be HTTPS and secure.
That is supercool. But this is not the main purpose of CSP. The main purpose of CSP is
that you want to limit what is allowed inside of your websites. And you can configure a
lot of things. So, this is the complete list of what is possible
with CSP. You can define where should fonts be loaded from, where should images be loaded
from. And a few cutting-edge things in there like this opener. Navigate too. And you can
basically trim down what is allowed in your website and you can avoid mining cryptocurrency
in your website because a thirdparty got hacked. You can use CSP with a meta element in your
HTML or you set a header like this. This is the head their I ship for my private
website. And includes all the thirdparties that I have. And coming up with this is actually
very, very hard. I deployed CSP three times and broke my site and rolled back. So, what
you want to do is you want to set a different header which is report only which then allows
you to define an HTTP end point and then you get all the warnings of requests that would
be blocked if this would be active. And you can start monitoring what is going on.
When you watch this when you have a detailed look at this, you will find out there is something
not right. I have unsafe in line and unsafe evil right there and it bothers me. But I'm
using a JavaScript a that inlines JavaScript JSON in the body so that the JavaScript framework
end gets the state. And I'm working on fixing that. It's not the easiest when dealing with
a framework. The way this should work is that inline scripts, when you have CSP enabled,
you have two ways You can either define a hashed value in your
CSP directive so that you can say, hey, this hashed value should be allowed in my website.
This is a little bit brittle, though, because now when you update your contents of the script,
then you have to change this header or your meta element in the edge. What you can do
is you can define a nonce value. Giving an ID and say, hey, this part is cool. Please
allow this. So, also support for CSP. CSP is out there in two levels. Level one, all
green. Pretty cool. Cutting edge stuff and more fancy stuff is a little bit jumpy still.
And there might be things missing. But you can have a look at that. So, I think this
technology is very exciting because it makes the web a safer place. How many websites use
CSP, there is a website that crawls the Internet and you can write search queries. And when
you do that, you will see that only 6% of the crawled websites use CSP. This is surprisingly
low, and I think we can do better. So, when you want to start working with CSP, start
in report mode. Monitor what is coming in and out. Don't break your site. And then only
when you are safe and you know that all your request resources are white listed, then you
can turn it off. For my site, I added a new route,/safe. And
then see that the unicorns are gone. And Chrome is saying I'm not reported yet. But I go to
CodePen and go to the framing site, Chrome will say, hey this is not allowed for the
site. People cannot hijack my stuff which is pretty cool. This makes the website safer.
This is important, the web is important for people. I travel quite a bit a little bit.
I was in the Ukraine two months ago. I get off the plane and I get this message by my
mobile provider. It basically tells me this. And just because this is ridiculous, I get
six megabytes are for 2 Euros. But I have to use it in 24 hours. This didn't hold me
30 minutes. The web needs to be affordable. Don't request the same content over and over
and over again. You can set proper caching headers. Caching is very, very tricky.
And I'm only going briefly into it. I'm defining there in seconds a max H property and telling
it, this is how long this resource could be potentially cached. But this doesn't necessarily
mean that there are no requests flying because browser also revalidates if the resources
changed. So, what is cool, you can define an immutable directive, telling the browser,
hey, this is maybe a hashed style, hash. JSS or something. The browser will not revalidate
stuff. That's cool. You can save some requests. Unfortunately, the spot for immutable is not
that great anymore. It was supported in Edge, but now Edge switched to Chromium. If you
want to learn more about caching, highly recommend this article by Harry Roberts. It goes over
the directives and if you wanted to set proper caching control headers, check this out. It's
not only about requests, it's about sending the right data. What happens when your browser
requests HTML? It sends a header called accept encoding and tells the server, hey, this is
what I understand. Cool. And you see the DEFLATE and Boat LY. It's a different compression
algorithm. And I took a CSS file and compressed with two different compression algorithms.
You can see that by itself it's a little bit smaller than Gzip. But surprisingly, people
are not using that often because what the whole industry things is that Boat LY compression
is so slow. Hard encode. With Gzip, the server compresses and makes a Gzip. It might be a
little bit slow. But when you say this sentence, what you're basically doing is you're comparing
apples with oranges. Let's look at Gzip and Boat LY. Gzip has nine
modes, Boat LY has 11. When you use these in default mode, Gzip runs in level 6 and
Boat LY runs in level 11. Between those, level 6 in Gzip is optimized for speed and compression
ratio. The other default is there to save the file size. When you tweak a little bit
and go not with the default mode, but rather level 4, it compresses better with the same
speed on the fly. You can set this. Maybe you have a build process in place, and you
don't to want compress it on the fly because you have a build process in place. You could
compress all the files and serve them to save some kilobytes. If you want to learn about
this topic, there is extensive research about what that means.
What's the support? Pretty there. All the big sights like Facebook, Dropbox, they are
shipping Boat LY. And I would hope that we do more things with this. It's not only about
compression. It's about serving tailored media. They cost the mode amount of data on the web.
When you're doing frontend and you want to ship, for example, an image, a little bit
smaller than JPEG. You find yourself building things like this. This is a picture element.
Responsive images for several sizes and ships when the browser understands it. This is horrible,
right? You do feature detection, this will break when the next person comes in. But guess
what? The browser also tells the server what image formats they're going to send. So, what
you could do potentially for browsers that support WebP, is you could read this header
and serve a WebP image instead of a JPEG when the browser tells you that this works. But
you can go even further. When someone requests your website and you said, for example, the
accept CH header, this stands for client hint, you can tell the browser, hey, I would like
to know how wide your viewport is and please tell me for the next 100 seconds. What happens
then for the additional image requests is that the browse her tell you dimensions of
the images. How cool is that? This means that you can use normal images without all the
responsive images stuff. But you have to give it a size attribute.
So, that the browser up front knows how this image is laid out. And this is then the request
that goes out. It will tell viewport with Nth of their image. And guess what? When you're
on a high pixel resolution display it will tell you the real size of the image. You can
then serve proper images via server-side generation or service worker which is pretty cool. I'm
excited about this. This is a little bit cutting edge. If you want to learn about client hints,
check out this resource. He does a lot of cool things around this topic.
So, I tweaked another side of my responsible Dev site. You see there, slash affordable.
You see that I'm shipping and also the image element is a JPEG. But serving web P without
any markup changes and tells me how big the image is. And without changing the viewport,
the server knows who resources to ship and what image would be the perfect fit here.
The web has to be affordable because the web is with us every day. Unfortunately, we reached
this state in the web right now. It's not playing? Here we go. This is made
by a former colleague of mine. This is where we are, right? We are web developers. This
is what we build. I believe that the web has to be respectful. And one of the most things
that we should honor more is time. And we should get the stuff that we shipped down
more quickly. So, what you can do is you can optimize the loading process for certain things,
and you can use link preload in your HTML oar set a header which then gives information
to the browser telling, hey, you will need these resources. Please start loading it.
Because a person doesn't want to wait for a font to kick in and watch a blank screen.
When you use the HTTP header, you have to be a little bit careful though when you're
using certain proxy servers or CDNs. Think preload will lead to the server push command
which is then not taking the browser cache into consideration.
So, if you use this header, you have to use no push. This is great to speed up credit
calorie sources. How is the support today for link preload? It's pretty good. You can
add these things and optimize the loading process to get your fonts or header images
down quicker and optimize for the time of your visitors.
The next thing I want to talk about is the AMP reaction. So, two and a half years ago
I was giving a talk about AMP and how it works technically. Actually, versus very interesting
what they do. And when AMP was released, doing a lot of standard work and spec writing and
then the web ecosystem. What he did is when he saw that we need to come up with an alternative
very, very quickly because AMP is very JavaScriptdriven. And this is very cool because now two years
later what is slowly coming is the feature policy header. What you can do there is you
can define what should be allowed in your website. And there's a lot of cool stuff possible
that you can configure. It could be possible that a thirdparty script
coming from somewhere accesses wants to access my camera. I think this is cool that
you can block a lot of things that shouldn't be possible by default. Unfortunately, we're
now entering a little bit of cutting-edge technology here. But there are cool things
like unoptimized media and optimized images. You can limit yourself and tell the browser
I don't want to ship, even accidently, massive images. You can then also define this for
iFrames. And there will be a JavaScript it's already shipping in Chromium browsers
there's also a JavaScript API that lets you access these values that came in via header.
This JavaScript API is still under discussion, though, so, please use that carefully. If
you had to look at this list very carefully, you might have noticed that there was one
thing missing in this huge list of things that you don't want to allow on your site.
What's the most annoying one on websites these days? Push notifications, right? People working
on these kinds of things figured out handling push notifications and disallowing them are
trickier than first thoughts. If you want to know how we go with these kinds of things,
you can follow this issue. What's the support for feature policy? We're not that bad. Which
is prettying with pretty cool. So, with these kinds of headers, I set up
another site,/respectful. And what you see is the permission dialogue is gone because
I don't allow it. And also, the JSConf PNG in the bottom and defined in CSS, I pushed
that to be loaded quicker which makes make the experience a little bit better. So, building
for the web is very, very, very hard these days. There are so many things to consider.
You have to think about the design, the content, web performance, accessibility, frameworks,
network and devices. And there's surely more things that you have to consider when you're
building for the web. So, all things headers, this 20minute rundown is not a complete one.
If you want a complete overview, my friend Shepp maintains this slide deck. This is a
massive resource if you want to know what HTTP headers are out there and you can Google
headers for hackers. And Andrew Betz give this is fantastic talk if you want to know
more. I really believe that the web has to be safe.
My mother shouldn't browse the web and mine cryptocurrency. People pay a different amount
of money depend on which situation they are and where they are in the world. And it has
to be respectful because nobody likes a person that is asking random questions and permissions
all the time. So, the web has to be safe, affordable and respectful so that it really
is for everybody. Thank you very much.
[ Applause ]