What Happens When You Hit Enter? Episode 1 – Websites

What Happens When You Hit Enter? Episode 1 – Websites


– A tech recruiter calls outta nowhere, and they say, “Hey, do you wanna interview “at this big, famous software company?” And you go, “Yeah, that’s kinda cool.” And they would ask you
this crazy question. They would say, “Okay, so
imagine you’re at a browser “and you type in www.redhat.com,
and you hit enter. What happens?” And you’re now left to
kind of try to answer this really tough open-ended question, not really ever knowing whether
you’re answering it right. And so, we’re gonna explain
what actually happens. (techno music) – Yeah, okay so, soon as
you hit that enter button and you begin your journey
to developers.redhat.com, there’s a lot that’s gonna happen. The browser has to make a
DNS request to figure out– – Whoa, not so fast. First you have to
establish you’re an actual network connection to that DNS server. – Oh man, yeah. – When you first establish your connection with your ISP or your router, you will have likely established
a resolver IP address. That’s gonna initiate your
entrance into the internet. – So once you’re connected to
the internet, what happens? The first thing that happens before you can ever start to
get assets from the server and start to build the web
page in your browser is, you have to use DNS. – DNS stands for domain name system. And it is basically a registry of names and IP addresses or numbers. I mean, it’s really one of the main things of how the internet works. You’d think about it how now
we have our phone, right? And you have a name, say, Mom. And you just say, “Call mom,” right? And it knows that mom is
associated with this number. That’s DNS in a nutshell. – So you’d think once
you have the DNS name, you can just go right to the server. But actually you go to a CDN. – Why do we need a content
delivery network, or a CDN? And the answer is for three reasons. And that’s scalability,
performance, and security. – They’re co-located all over the world, in many different points of presence. – And you get like thousands
of people coming to your site in a short period of
time, all of that traffic will be offloaded onto the CDN. – Once that goes down, you got another one to back things up. – So it doesn’t bring
down your origin servers. – One of the things that the CDN gives us, a lot of other computers that are actually servicing our site. So, for example, someone in
America and someone in Asia and someone in Europe will
all get the same website. But they’re actually served from different physical
boxes from the CDN. – [Scott] So you’d think
the CDN would just go back to the origin server every time. But it doesn’t do that. Because if it did, it would
slow the entire website down. What is actually does is it
caches those files locally, which then makes it
faster for the end user to get it in that geography. – Anytime that you encounter
something that has been cached, you’re saving yourself a lot of trouble. You don’t have to do a lot of processing to build up those connections
and break them back down. The content’s right there. – Another benefit of
caching is site failovers and outages in your origin. If you have something
that’s cached on the edge and that copy is still on the
edge if the origin is down, then it can still continue to serve it. – And that’s governed by
something called a TTL. – Time to life? – Time to live. – We just, we never,
we always call it TTL. – The time to live determines how long that caching server
will keep that content. So if the TTL’s set to 60
minutes or 60 seconds or 60 days, it will hold that content
for that amount of time. So you might think there’s
a single origin server and it serves the entire CDN. But that might not be the case. In a very large website, you’ll often need multiple origin servers. And they’re often
front-ended with something called a load balancer. – What the load balancer does,
is it distributes traffic across multiple servers. It’s a way of spreading
out the amount of requests. – So it’s not all running
off of one server. – So if you get one or a hundred
or a thousand CDN servers all talking to your origin
server at the same time, you can handle it. So the origin server has to
get its content from somewhere. It goes to a CMS: The
content management system. – Drupal is our content
management system, or our CMS. Basically, it is a repository
of all the different webpages that are served up on
developers.redhat.com. But mostly things like text and images are served from Drupal. And that’s just a
repository where the editors and the authors for the content can go and they can do any kind of tagging. – So a lot of times when you go and look at a piece of content, it will be tagged with a subject or a label. And that label helps determine what things you’re interested in, and helps recommend other things you’d probably like to read. – So once the request has been sent, there’s all sorts of things
that go on in the back. There’s ways of treating the content and the assets that are sent back. You can tweak, I guess,
is that a technical term? – Yeah, there’s another
technical term, tune. – Oh, okay. (laughs) It’s a whole ‘nother world
beyond the back end services and things that you may be, if you’re coming from
a back end perspective, the front end seems like
a really simple thing, but it actually can go very, very deep. – But there’s a lot more
happening in the front end before the page completely renders and a user can actually
interact with the webpage. – As soon as we’ve actually
got a response back from the server, which will
include any http headers, and then also the actual
HTML for the webpage, the browser will take it, and it’ll do, as sequentially as possible, it’ll go through and
actually parse that HTML. It’ll go and look for and
flag things like images, JavaScript, CSS, additional
resources that it will need to go fetch to actually show
you the completed website. And it’ll go do all that
as quickly as it can. – There’s two sets of speeds. There’s how fast is the asset
loaded in time, in physics. – Ideally, a hundred or so milliseconds. – 200 milliseconds is
actually the magical number. – Right.
– I’m not gonna say that all of our pages load that fast. Some of them do not, especially
if you’re downloading REL. – (laughs) – On the other side though,
it’s how fast is it perceived. – You have literal milliseconds
to display the page before a user may lose interest. – People strive to get
that instant response, instant page load, and it’s
very hard to do and do it right. – So when a page loads really quickly, it feels like black magic. But there’s actually a lot
of art that goes into it. – There’s definitely something to be said about tricks of the trade,
little slight of hand kinds of things that you
do to make your website look like it’s faster
than it might actually be. – How to handle those assets,
how to present the content in a way that displays
properly across devices. – Make sure you compress
everything that’s compressible. – Assets like style sheets and JavaScript, obviously the big thing
for them is to minify those so that they’re as small
a package as possible, so that the browser doesn’t need to wait for them to download, it can
start parsing them immediately. – There’s a lotta skill in
how that page is rendered. – And it’s something that
changes as technology changes. – [Narrator] Once developers.redhat.com
is fully rendered, a developer gets to
participate in the community that we’ve created, and also
participate in the content that we’ve created. Things like videos, blogs,
cheat sheets, and courses, to learn things like
OpenShift, REL, and Knative, in a way that’s best suited
to their learning experience. – When you ask this question, you’re gonna get a
lotta different answers. There’s nothing wrong with that. Everybody has their own expertise. So how would you answer what
happens when you hit enter? (mellow music)

Comments

  1. Post
    Author

Leave a Reply

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