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 ]
