- 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)