 I was waiting a few extra minutes. It's the first session of the day. I'm sure people are just getting in. But we'll go ahead and get started. Welcome to day two of Workamp Birmingham. Ryan. You're good. I just didn't see anything on that screen. And I'm sorry to interrupt you. OK. Yes. There's stuff there. Awesome. Thanks, Ryan. So welcome to How Does the Web Work? So in this presentation, I'm going to give a little bit of an overview of the history of the internet, setting the ground of why some of the things exist the way they do. And then we're going to look at something specifically. My thing is not going. That's OK. Am I on the wrong? There we go. So I'll get back to that just a moment. But specifically, there's something called the cycle. It's the same thing I'm going to mostly focus on in this talk, explaining what exactly happens if you were to type something into your browser or someone were to type your URL into their browser. What happens to go around all of this cycle to end up viewing a web page in their browser? So I'm going to talk about lots of other things, slight tangents that help clarify some of this. But the main takeaway will be what exactly this is. So I am Frank Corso. I'm the head of engineering at PodChaser, where a podcast audience insights tool. Before that, I founded a tool called Site Alert, which allowed you to monitor your WordPress websites, check for uptime monitoring, broken links, that kind of stuff. But I sold that business in 2021 when I joined PodChaser. So that's a little bit about me. But we'll go ahead and jump right into the history of the web. So a lot of people don't realize just how long ago this process got started. So I'm going to start in the 1960s. But actually, by then, a lot of this was already started to being a motion. But this is where it really becomes the internet and the web as we know it today. So way back in the 1960s, there was a concept of packet switching, which when someone transfers files through the internet, whether you're downloading a file or someone's viewing a web page in their browser, there's something called packets, which is essentially breaking all the files and data down into little tiny packets of information. And all of the internet and all of the connectivity, all of your devices are built upon this concept of packet switching, where it makes sure the little bits of data is getting from where it's supposed to be to where it's going. And this started back in the 1960s. It was actually independently started being worked on. There's people at MIT who say, hey, we need this system. There's people over in RAND that were working on this. There were people in ARPA. And they all started working on this around the same time, going, hey, we need some way to transfer information to other computers. And so ARPA realized there was many people working on this at the same time. So they kind of brought it all together to lay the groundwork of something they called the ARPA net. And so that was the foundational piece of, hey, we have computers. We're going to send data to each other using this packet switching theory that several people are working on. And we're going to build it out into our ARPA net. And at the time, the ARPA net consisted of four main computers, or universities. It was University of California, the Sanford Research Institute, Santa Barbara, and University of Utah. And that was the foundational pieces of the ARPA net, were those four universities. Now, a fun random fact was the very first message was sent on October 29, 1969. So this was the first time they tried to send a message from one computer to another across universities. And they attempted to submit the word login. But after the letter L, the letter O, the system crashed. But it still counts as the first message. But they only get received two of the letters of the five. Now, around the same time, IBM created something called the generalized markup language, or GML. Now, if you've ever looked at HTML or your web page, or kind of see what it looks like, you might have seen an H1 tag, or an H2 tag, you might have heard like paragraphs and bullet points. Well, all of this is based on this language that IBM created in the 1960s, called the generalized markup language. It looks a little bit different than what we use today in HTML, but it still had the same concept of tags and attributes. Now, from there, as we started adding more and more universities and other companies started getting involved, they realized, hey, we're all doing this slightly differently. And that's not going to allow for an actual internet to evolve, and to become something useful for everyone. So this is where protocols started coming into play. So you might have heard of the FTP. It's not used as much today. It's a bad practice for using FTP in web development. But it is still fairly common. And what it basically is a file transfer protocol. So it is the standard way of sending a file from your computer to a server. So every now and then you might have to do something where, oh, this plug-in is no longer working, or it's crashing my site. And someone might say, oh, you have to FTP in to disable the plug-in. And essentially, all that is, is you going in and making file changes through this protocol that was created in the 1970s. Now, there's a slightly newer one these days. It's the SFTP, which is Secure File Transfer Protocol. But it works exactly the same, which is secure. This was also the same time when other protocols, such as the FTP mail protocol and the SMTP were created, which is how most of the emails were built off using those protocols for many of the following decades. And then at this point in the mid-1970s, 1977, according to that, there was a lot more universities in the force. So within a decade, there was dozens of different universities using this network now. So at that point, several different people, but most specifically, Robert and Vince here, they realized, hey, now the ARPANET's growing. There's going to be these subnetworks. So at some universities, they might have one computer that's connected out to the other network, the ARPANET. But then they might have their own little network going on within the university. And then some other just independent companies started having their own standalone networks. So these gentlemen said, hey, we need some way to standardize exactly how these computers are communicating on this network. And that way, we're all doing it the same way, and we end up with one main network. So they came up with something called the TCP and IP. So essentially, you might have heard of IP addresses. They're just a unique identifier for your computer, for your phone, for your Nest thermostat. Everything has a unique identifier. They've changed a lot over the years, but essentially they're still very much the same of IP addresses. They're the internet protocol. And then there's the TCP, which is the protocol of how these then communicate. At the time, like I said, there was many subnetworks and different things. And when they established this, the goal was to create a way to communicate across networks or internet. And that's where we came to the internet. And then from there, fast forward just a hair, maybe. There it goes. A few years later, so I think they proposed it 78, 79, a few years later, they realized, hey, now that there's lots of computers, at this point, there's dozens and dozens of universities participating, which is many, many, many computers. They realized, hey, right now, everyone's having to type in an IP address. So for me to go to someone's website, which loosely defined at this point, but if we use access website, I have to type in 1.637.89, and no one's going to remember all those once we start adding thousands. So a lot of people would propose, hey, we need some way that you can attach an address, an actual word or phrase that if you type it in, you will find the right server you're looking for. And that is where the domain name system came into play. Now, you might have come across domain names. Some of you, if you already have websites, or maybe you have lots of websites, maybe you're doing all kinds of things, you might have used domain names quite a bit. Maybe all slightly, but essentially, they still work the same way that they did back in the early 80s. And we'll dive more into those in just a moment. So after we have a growing network, and we have our domain name, we have our standardization around some of the protocols, now people actually need to be able to start using some of these things. And this is where the early browsers started coming out. So some of the early browsers were like, let's say, PC Hypertext and SilverSmith. The problem at the point, though, was that there still wasn't a standardized way of displaying this information. And also, how are you going to structure this? So far, HTML does not exist, HTTP does not exist, CSS doesn't exist, JavaScript, none of that exists yet at this point in time. So they end up having something basic like this, where you say, hey, here's a domain name, it'll just return a few paragraphs. Which was probably amazing at the time, which is, that's great, but it's probably not going to evolve into the internet that they want yet. There's even, so SilverSmith was actually using a different version, a different, a competing technology with HTML called SGML, which was pretty much that one that was invented in the 1960s from IBM. It was just slightly different and improved. But that one didn't allow for all the cool things. So even then, it was still kind of basic like this. And that is where HTML and HTTP came in. So Sir Tim's Burner League came in and said, okay, right now we've all these different ways of doing it, some of it's bad, and some of it's okay, and some of it's great, but we need one central way to do this. And so they propose, or he proposed, the Hypertext System and Protocol. And this is where everything, a lot of the things you've seen before, if you've gone ever into your theme or just playing around or just copying things and even some plugins, you've probably seen something like this where it's like H1 and P and H2. And this was what he proposed back in the 1990s, or late 80s, sorry. Now, depending on when you started with web, you might've come across something called Gofer. And that was essentially a competitor to HTTP. This was a, there was Gofer browsers at the time and they were doing a slightly different protocol. And so there was a brief period in time where depending on what you were trying to do, you either had to do HTTP, domain name, or Gofer, and you had to use different browsers and I can't imagine how chaotic that would be if that existed still today, but that's a fun little tidbit to remember. So that brings us to the 1990s where we actually start getting into what kind of looks like how the web works today. So after we, after Berners-Lee proposed the HTML and HTTP, that had got accepted, people started using that and that came with the first HTTP web browser called the World Wide Web. And this arrived in 1990 and then quickly other people started making them. There's Mosaic, Opera, Internet Explorer, Netscape Navigator, several of these other ones that all started coming around, around the early 90s, very much working the same way, but all built on this HTML, HTTP system. However, at the time, it was still just that paragraph of text. So we needed some way to style this. We looked at it and we said, okay, we'd love to be cool if we could change how the links look or maybe if add some spacing around the text or make our headings bigger, bolder, all these fun things. And at the time, there were actually several different systems for a brief moment of time, every browser had their own way to style. So if you were a web developer and if WordPress existed at the time, then when you created a heading, you would have to say, okay, in Mosaic, I want it to look this way. In Internet Explorer, I want it to look this way. And Netscape Navigator, I want it to look this way. You have to do that for everything on your entire website. That would be just terrible, but that's how it was. And there's even browsers were super customized about the time, which we have lost over the years, but you could also go in there as a user going, hey, I want most of my web pages to look this way. So then you could just standardize all how you were viewing it, which seems awesome, but that's something that's died down over the years. So then in 1994, someone proposed, hey, why don't we have a standardized system and they propose CSS, cascading style sheets. And that was eventually accepted in 1996. And interestingly enough, Internet Explorer 3 was the first commercial browser to use CSS, which was probably one of the few times Internet Explorer was ahead of the competition. Now from there, we started realizing, hey, we want to maybe do interactive things with the website. Maybe you want to have a pop-up up here. Maybe you want to have a form on your website. Maybe you want to do all kinds of animations and crazy effects on your website, or maybe you want to even have cool games running on your website. Well, you can't do that in just HTML and some paragraphs. That doesn't work. You need some sort of actual coding language. So around the mid-1990s, browsers starting building their own different systems. And again, this became a problem of, hey, now we're having to build it for all different types of browsers where all different directions, none of these were compatible. So again, someone came up and said, hey, why don't we propose a new language and that is where JavaScript comes in. It was originally called Mocha, then it became LiveScript and then it became JavaScript. And then it was, if I can scroll down just here, my notes here, oh, well, maybe. Sorry, my computer goes. Then, where was I? Sorry. So Internet Explorer then again, decided to do their own way to do things. So they actually used something called JS Script. So depending on when you started in the industry, you might remember a time where you had JavaScript running on everything else and then JS Script running in IE. And for the most part, they were the same, but there was just enough differences that it was extremely frustrating to build anything for Internet Explorer. Eventually, Microsoft caught on and standardized things, but it was several years that there was a distinct difference between the two. And then the code name for JavaScript in Netscape was SpiderMonkey. And if you were to look into Firefox today, they still use that same code name for JavaScript. Oh, one final point on that, this is probably something you'll never need to know, but the actual JavaScript, the organization is ECMA. They're the ones that actually put it together. So every now and then you'll hear JavaScript referred to as ECMA script. That's the actual name for JavaScript. I don't think I've ever heard anyone actually use that name in any real setting. Everyone uses JavaScript. That's technically the commercial name, but they're pretty much interchangeable. Everyone uses JavaScript, but that's just a random tidbit just in case you were to come across that. So I'm not gonna go through this entire thing, but this is essentially all of the web browsers that have existed between 1990 and 2018. I could not find one that's up to date, but 2018 is still close enough. There's been a lot of browsers and most people don't realize just how many different browsers there were and how many different versions and how many of them were connected to each other. An interesting one that I always like to point out is this one right here, this one is called Conqueror. And this one came out in 1999, 2000, somewhere in that period. And this one came out, they had this really cool engine, and I'll get into engines in just a moment, this engine called WebKit. And it was really revolutionary. It came in, it did things very nicely. It was really easy to work with, it had all these great systems that developers could build upon. And, but no one really used this browser that much. Some people kind of liked it, it was fun. There was a handful of volunteers that were running it, just wasn't enough people to really get it into something big. And at the same time, Apple was going, hey, Microsoft has Internet Explorer, we need our own browser. And since Conqueror was open source, Apple came along and said, hey, Conqueror is Safari. That's ours now. And so they forked it and built upon it to create Safari, which is the Safari that we use today on Apple devices. And then WebKit, that same engine that now Conqueror and Safari is using, became really popular. So then Google Chrome came out and they also use that same WebKit engine. And then Opera eventually switched to that WebKit engine. So most of the browsers today, even Edge, are built upon that WebKit engine that volunteers built at open source back in the original Conqueror browser. So random tidbit, again, something you may never need to know, but fun little tidbit. So let's get into the actual, what happens when a page loads? So if you go into a browser, you might type in some random domain name and you might hit Enter. And then it does a lot of different things. But it all starts with the browser. The browser is what handles the HTTP request. And I'll look at that in just a moment, a little bit more. But essentially when you type in your website or my favorite cat.com or something and you hit Enter, the browser is going to make that request to the server, to the domain name servers. It's going to handle all that piece. And then it's going to get stuff back and it's going to interpret that HTML, that CSS, that JavaScript, to figure out exactly what to show and what to do in the browser. Ooh, that one's, we'll cut off there, that's good. So when it comes to the parts of the URL, majority of the time, people are usually familiar with the domain. So if you have mycatsblog.com, my cat's blog will be your domain. But there's also all these other pieces that you might want to remember throughout as you work on things on your within your website. So the protocol almost always, that's HTTP or HTTPS. And that's pretty much a standard. The browsers usually handle that mostly for themselves these days. But theoretically that's also if you were to do an FTP, if you have to FTP into your website, it'll actually look almost identical to this except the protocol will be FTP or SFTP. Or if you're doing some other protocol, it'll be the same structure except with slightly different protocol. For most people every day using the web, you'll never need to do that. It's always going to be HTTP or HTTPS. But that is, they all work the same way. From there we have the subdomain. So depending on your structure, your website, you might have a something.something. So maybe you have mycatblog.com and you have a staging site set up at staging.mycatblog.com. Then the staging, that will be a subdomain on your website. And then again domain is just kind of the main address of your website. This is, if you're not too familiar with domain names, these are essentially like your mailing address. So think of the IP address as kind of like your, your physical geographical location for your house. Like, oh, latitude and longitude. People can't mail to your latitude, longitude. That just wouldn't work. So we have a mailing system. You have an actual address and a street name and all this. That is the same concept to the domain name system. So your IP address is like your physical location for your house, but then the domain name is the actual mailing address that people then remember. Then TLD, this is the top level domain. There are now over 1600 top level domains. Most people can think of like five. So it's always fascinating just how many there are, but the majority of them you might know like .com, .org, .edu, .io, .tv. Technically, .tot, .xyz, .app. There's several of them that you might be familiar with, but then there's also ones for almost every country kind of has their own. And there's also all these sub ones. There's lots of them out there, but for the most part, most people usually want to stick to something more familiar so people can actually remember your domain. And then after the .com, you might have a path to a specific page of your website. So if you have mycatblog.com slash aboutmycat, then the aboutmycat portion is usually the path of the URL. And that is how WordPress or other systems know what page specifically someone wants to be viewing on that domain. And then at the very end, there's parameters, query arguments, there's several terms for this, but essentially this is just extra data that we want to send to the server about something that might change within the website. So if you use the WordPress default, is it still default? I think it's still default. Default options where it's just, oh, all the different pages, instead of having a nice about us and contact page, sometimes it just goes to P equals, it's like P equals one and P equals three or P equals four. So instead of having, sending the path, we're sending this P equals five to the server and then the server knows, or in this case WordPress knows, oh, they want this specific page. So that's kind of how parameters work is that it's just sending some specific additional information and whatever's running on the server, in this case WordPress, kind of goes, oh, okay, this is some additional data you're sending and I'm going to do something with it. Now theoretically you can go to any website and type whatever parameter you want, but for the most part, unless they happen to be using the same exact parameter that you type in, it's not going to make a difference. But these are fairly arbitrary that you can type whatever you want in there. So that's just something to remember, but it's only whatever the server is looking for that'll actually be used. So this is an actual HTTP request. So your browser does all this kind of behind the scenes but you can do this manually if you ever want to. I don't know why you would want to. This would not be fun to look at HTML this way, but theoretically you can. And so this is a HTTP request that I did where I just go, hey, show me, what was I looking at this guy? I think it was example.com. So I said, okay, I want to look at example.com through a terminal. And so I did an HTTP request and this is the protocol that pretty much all of the web is built on and you just go, and again, you don't have to remember these details of the methods here, but essentially you, there's different ways. You can say, hey, give me information. You can say, oh, give me information. Or you can say, hey, I'm sending you information. Or you can say, oh, I want to delete this information. There's different, we call them verbs or methods, but essentially they all just say, hey, what am I doing on this domain? So in this case, I did a getrequesttoexample.com because I wanted to get the website and that's what most browsers use. So as you navigate the website and you navigate the web, go to google.com, go through your store, they're all making get HTTP requests because they're getting information. However, if you submit a contact form or you purchase something on the website, they might make a post request because that is sending them that you want to do something with information. So in this case here, I did a getrequesttoexample.com and then it returned, it returned all this HTML down here, which is what the browser receives to then do something with. Now it also receives, there's also a concept of headers. I'm not gonna get too far into those but essentially there's additional metadata or additional information that this protocol can use to communicate with. So in this case, we can specify like, hey, how long does a cache work? When was the last time this page was updated? What kind of content is it? There's all these extra things that the browser can use and the servers can use to say, hey, you might wanna do something different with this content that you're receiving or that you're sending. A lot of different servers and tools use these to add additional data and information. So if you are using, you're working with an API, some people, some APIs will add extra headers in there of like, oh, how many API credits you might have? If you only have a certain amount of credits per month or it might have a, if you get blocked by like Cloudflare, they'll include a header of like, oh, your block expires in 24 hours or you have 23 hours left that you're blocked or so they'll add additional metadata there that then browsers can use to do something with or tools or integrations or plugins can then use those headers in addition to the content themselves. And then the actual body is the content itself. There's not any need to remember the term body for the most part, unless you really are getting into development, which I don't know if anyone here is really getting into development, but the body is just the actual content of whatever's getting back or whatever's being sent. And then lastly, there's status codes built into the HTTP protocol. No, HTTP is the protocol. Into HTTP, there's status codes and you might have come across these already. You might go to a website and you get a 404 error. The 404 is the status code through this HTTP system. There's also 500. You might come across a 301 error, also something like 200 status. All these have different meanings, but essentially anything in the 200 range is usually everything's okay. Everything in the 300 range is usually like a temporary thing or some sort of like, hey, just to let you know kind of thing. 301 redirects are popular in SEO. Like if something gets redirected, you might have to set up a 301 redirect. Anything in the 400s is usually a client error, which would be something, the browser. Something happened in an error on the browser side or a user error. Maybe you're trying to access a page that doesn't exist. That would be a 404. Anything in the 500 range is usually errors on the server side. So 500 is usually a common error of, hey, you crashed your website. Now you're seeing 500 errors. So there's something wrong on the WordPress side of things. Does that make sense? Does that have any questions on that? I know I'm going through a lot of material very quickly, but feel free to like throw something at me or wave if you're lost on anything. So the domain name system itself, again, this is like the address to your website or address to any website. And how this works is you go to your browser and you type in mycatblog.com or example.com or WooCommerce.com, automatic.com, any of these, you type in that name. And then the browser goes, okay, I have to figure out where this exists because the browsers can't remember all of the IP addresses in the world. There's millions and hundreds of millions and billions of IP addresses. The browser's not going to remember all of those to make that connection of, okay, they want to look at mycatblog.com. That's at this IP address. The browser's not going to remember that. They look up something called a root server. So the organizations that run domain names and top level domains and .coms, they have this concept of called a root server. So the browser will reach out to the root server and say, hey, I'm looking for mycatblog.com. Can you tell me where I can find this? And the root server says, oh, I don't know, but I know that since it's a .com, you should talk to the .com name server. So then the browser goes, okay, so I need to look, so there's a TLD name server and that's the top level domain. And so .com.org.eu.io, all of these have different name servers. There's more than one. There's usually millions of these servers. It's not like just one kind of server in someone's closet or something. But they look for this top level domain name server. So the root server says, hey, it's a .com, look at the .com name server. So the browser says, okay, .com name server. Where's this IP address? And the .com name server goes, hey, I think you should look at the domain name server. So the domain name server is wherever you bought the domain from in most cases, they kind of have a set of servers then that say, hey, okay, we own all these, this set of domain names and we know what IP address is these point to. So the top level domain, top level name server, the .com name server in this case goes, okay, this domain is owned by Hover or this domain is owned by Psycround or this domain is owned by someone or they sold this, they manage this domain. They'll know where the IP address is. So the browser goes, okay, great. Now I can reach out to Psycround or Hover or whoever you bought the domain through, ask them and they'll say, okay, it is this IP address. It's this server here. The browser goes, yes, now I will connect to the server. So that is how that loop works. There's a lot of super technical details that I kind of glossed over there, but that's for the most part, that's kind of how the concept works. Now in DNS, if you've ever set up domain name system, your domain name before you might come across like A records and C records and text records and MX records, all these are just different things you can attach to your domain name that says, hey, if a browser is connecting this way or they're looking for this thing on the domain name, this is how I want you to interpret that. So if you bought your domain name through Hover or Bluehost, GoDaddy, any of these, you might have an A record and that's usually saying, hey, if they type in this, send them to this IP address and that's just like the basic, almost everything you do is relying on A records or C name records, technically, but I'll get to that in just a minute. So that is the actual record where it goes, okay, if I want to go to mycatblog.com, it's at this IP address, that A record is what says these two things go together. C name works pretty much the same way, except it uses just instead of saying, let me think of a good example here. Instead of pointing to an actual IP address, it points more to another domain or another system that says, hey, instead of getting this IP address, it's just this more generalized term will get you there. So you usually see this more on like a WWW or like a subdomain, those usually more use C names depending on how you set them up, but the A record is kind of the main standard that most people use. Then you have the MX record, if you set up your emails and then you use your domain name, you might use this record, you might have used this one before, essentially your email provider, whether you're using Zoho or Fastmail or Gmail or whoever you're connecting your domain through, they'll say, hey, I put this little snippet of text into your domain name server or into your domain name system and you'll copy that and you'll use the MX term and that's when email goes through, they look for MX records to know how the emails get sent through and so they look specifically for MX records instead of the A records. So that's just some, there's actually dozens of different types of records. I'm not gonna go through all of them because you'll never touch most of those. Those are the main ones, if you were to come across, if you're setting up a website, if you're setting up a server or a WordPress site, you'll usually use A records or C names, if you're setting up emails, you might use MX. If you're verifying you own a domain, like through the search console or through some other things, you might use a TXT record, but those are usually the main ones you'll ever touch and most places that are asking you to set those up, we'll explain those in super detail, but just in case they don't, you might wanna remember generally kind of what they're for. So once the browser says, okay, I know where this site is, I have the IP address, I'm going to connect to the server now. It then connects to a few different types of servers. Now, there it goes. Now there's a lot of different kinds of servers these days and a lot of these blend together. So before these used to be very separate things. Some of these kind of blend a little bit together, there's our thing, there's things, concepts that kind of exist between each of these and so it can get a little confusing, but mostly it can be bucketized into these four main types. So shared hosting is where you have a server running and it has your different sites or your sites or many of their customer sites. So you think I am going to create a fake hosting provider just so I don't say anything bad about any existing hosting provider. So let's say Frank's hosting owns, has shared hosting offers and I have a server and I say, oh okay, I want to make money so I'm going to rent out space on my server where you can run your WordPress site or you can run whatever other site you want to run. So I will share, I will sell different pieces of the server. So essentially if I sell some of it to my friend Joe, he might have access to this much CPU and this much bandwidth coming from the server and I might sell it to my friend Christine and she'll also own a little piece of it. But then I'll realize, hey, I want to make lots of money so I'm going to sell, I'm going to break this down into a really tiny piece. I'm going to cram thousands of sites into each of my servers and that is how shared hosting becomes super cheap then because each person only gets a really tiny sliver of the server. Now, some of that is good, like if you're just starting out, you don't want to spend hundreds of dollars a month on servers, you usually want to do something super cheap just so you can one, figure out what you're doing or maybe it's a site that will just never make money and that's fine, like that's entirely fine to start off in shared hosting. And, but it's just something to be aware of that technically most newer hosting providers these days do a better job of separating some of these sites a little bit so if one gets hacked they don't all get hacked but there are some that exist that since they blend them so much together on a single server, if one site gets hacked they can hack the server and then just hack all the sites. So that's the downside of shared is that you're using all the resources but you're also sharing the risks too. So, but again it's perfectly valid, most people start off on shared hosting so I don't want to say shared hosting is terrible but just be aware that there are the risks and there are also performance issues because you're sharing those resources with everyone that if you have an e-commerce site and you get, what's a popular show they say? Does Oprah still exist? Does she still, I don't know, if she has a show and she goes, oh hey, mycatblog.com is amazing and then everyone goes to your site if you're using a shared host that has thousands of other sites on that server and you're sharing this much and everyone starts going to your website that website's not going to stay up. Like it only gets a little bit of resources it's trying to share it with everyone else so then it just will not stay up with that amount of people coming to the website. So, that's kind of how shared works. Again, not bad and it works great for many sites just be aware of those kind of downsides there. The next step up is VPS, virtual private systems. These work very similarly to shared in that there's still a server that people are kind of sharing but in this case, they're one, the big factor is there's a lot less sites per server but they're also, I don't want to get super technical here but essentially they're virtualizing the environment. So, instead of having one shared server that runs Windows or Linux it has lots of fake computers essentially running on that server and each site has its own fake computer. So, that fake computer, if that gets hacked it's kind of its own computer so there's less risk of that site affecting other sites on the server because there are their own fake computers, virtualized systems. And they also have since their own fake computers they have a little bit more resources going on so they have a little bit more power and can absorb much more traffic or people or more intensive things going on on the website. The next step up, this is this that most people do not need but you could have a dedicated server just for your own site. So, you could go out and say, hey, I don't want to share this with anyone. I want my own server and I want only one site on it or maybe only my sites on it. You could go get that dedicated server. These cost quite a bit more and unless you are really big site or you have a lot of traffic this usually isn't needed to spend that much money for this something like this but that is also an option. Right. And then last there's cloud hosting. This is a kind of combined of shared in VPS in a way that essentially you still have your fake computers your virtualized systems but instead of them running on a single server they run across many servers. So, essentially there's like AWS out there there's Google has their platform, Google Cloud their Microsoft has their platform Azure. They might have a series of servers that they set aside for cloud hosting and if you run your site they will set up their fake computer and it will just use resources from whatever server is currently available. So, if you go to mycatblog.com and it's usually working with these two servers but for some reason they're busy it can use from these some servers or they can use from those servers and you aren't managing those servers you aren't aware of those servers they all kind of happen in the background on their own kind of on the side. So, this is great option for large sites or really dynamic sites or sites that have a lot of traffic coming to them or they have a lot of things going on. Again, this probably isn't a spot where you're starting your first site at but it isn't another option out there. Does that kind of make sense what the difference is between these? Does anyone have questions on that? Not really, it depends on once you get into cloud hosting there's all these kinds of configurations and different ways you can do it. There are ones that are cheaper than doing a VPS like theoretically you can go to digital ocean and get a VPS for like $5 a month. You probably won't find things much cheaper than that but you could go to a cloud hosting option that kind of spreads those out and you could find one comparable but it might not be kind of exactly one to one. Does that sort of answer your question? Yeah, so like for someone who is a little bit more intermediate and they're not wanting to do the share and then dedicated is obviously too much than our choices are VPS and cloud hosting. Is there a preferred one for the more intermediate with an average traffic? For most people usually VPS is a good option. Now technically something in VPS you might have come across managed WordPress hosting or managed hosting. Most of them are built upon VPS type systems. So all those would apply within there but usually the VPS approach is the easier approach if you're not technical quite yet or you just don't want to care about any of this stuff just because it's a single server and you have a digital ocean droplet or you have cloudways single server system or you have something like that where it's like oh this is your only thing you have to care about and that's usually what most people go to just because it's much simpler and you don't have to worry about once you get to cloud hosting you might have to think about load balancers. You might have to think about this stuff so it's a little bit more complicated and I'm not gonna go into any of that right now but so while it could be cheaper sometimes it could be more powerful or less powerful depending on it it's just a little bit more complex so most people don't usually go there unless it's needed. Thank you. You're welcome. Any other questions on this? How are we on time? I think we have a little bit left. So once the browser finds the server let's assume in this case we are still talking about mycatplog.com which I don't know if it's a real site or not so if it's there and it's a bad site please don't blame me I have no idea if that exists. So say it's maybe we'll use example.com because that is a good site. So if we go to example.com the browser found the domain name already it found the IP address and now it's connecting to the server directly the server then has to actually do something to return content and this is where you might come across server software so you might have heard of Apache or Nginx I'm not gonna get two into the weeds here the technicalities but essentially it's just software that runs on the server that then empowers other software to run. So WordPress can run within these environments and so these kind of kick off hey someone is asking about this webpage I'm going to send this to WordPress so WordPress can do something or I'm gonna send it to you might have heard of Node.js or Express or these other systems out there and so Apache and Nginx are kind of like the gatekeepers for the server so when the information comes in or there's a request coming in they kind of decide how to handle that and pass it off to whatever relevant software is needed which in most people's cases here that will be PHP which is a programming language that runs on the server and WordPress runs or WordPress uses PHP it's built in PHP so in this case if we type in example.com if they were to be using WordPress I have no idea if they are but if they were then they might be having Apache or Nginx it will get to there the gatekeeper gets hey okay this is a request for this particular page that's powered by WordPress so they'll send it to the PHP side PHP will run and WordPress will kind of run through all of its functions its themes its plugins to build out that page along the way connecting to the database now the database is super technical I'm not gonna get too far into it but essentially it is where all of your data is stored and all of your settings are stored all of your random bits of information stored if you have themes installed they might all the theme settings might be stored in your database you have plugins installed all the different configurations might be there if you have a form plugin or a pop-up plugin or any of those like what you've built there the titles and the fields and all that will be in the database usually so that has all of your actual content so the PHP will run it'll kind of parse through the plugin files and the themes to figure out what it needs to build pulling the data from the database to generate the HTML to send back to the browser random yeah I will try to stop with random facts cause I know we're almost out of time but last random fact the MySQL started way back in the 90s it was acquired by Oracle and some of the people that built MySQL didn't care for it being acquired by Oracle so they forked it and created MariaDB so these things are essentially the same thing there are minute differences but WordPress can actually run on both so just something to be aware of every now and then you might come across a site depending on exactly what you're doing but you might come across a site using one or the other or you might see a reference to one or the other in the WordPress documentation or in plugins they work the same way some people prefer different ones depending on the use case but most people end up on MySQL cause that's just standard and last interesting fact MySQL the My portion of MySQL and the Maria portion of MariaDB are both named after daughters of the same person who is the founder of both of those so once the browser gets that content back so we've got to the IP address we've gone to the server we went through Apache we went through the PHP WordPress we got on the data from the database it creates that HTML and it sends it back to the browser the browser gets that and then has to do something with it so first it parses through tries to figure out exactly what is going on here and then it has to build out the actual elements and the actual tags and how it's all structured the documents, the DOM, the tree all these are technical terms but essentially they're building out just what all the elements are on this page and kind of how they're laid out and then from there they do something called painting and this is where it oh we have our elements we know what the CSS is we have a general idea of what's going on so now we're going to start visualizing and adding the actual elements to the screen so it's adding your text it's starting to create the picture it's starting to create the content down the page and once that's all done it fires off something called onload and this is one of the last steps of the website being run and when it fires this off a lot of your JavaScript will be triggered based off this event so it's saying hey all the content is there if you have some cool things going on that's interactive start running them now so if you have a pop-up plugin you might say hey when the onload fires that's when we're going to start loading the pop-up content or we might start opening pop-ups you might start doing something like that you might have things like cool animations they might want to wait until everything's loaded to then start doing things so you don't confuse the users with stuff moving before the content's even there and then once everything's done that's called fully loaded now if you were to go to page speed insights or you might play around with speed tools or SEO tools or various things you might come across first paint first content full paint so that's all happens in this third stage here the first paint is where the very first start things actually start appearing first content full paint or there's another term for it first and I don't remember the other top but most of its first content full paint that's where something's useful is actually showing up so the first step is oh there might be some random background color there like that's great but no users getting value from that first content full paint might be the heading and the first few paragraphs are there now or the header image and your title is there now like something that's actually meaningful for the content so there's a distinction there and when it comes to SEO and page speed insights a lot of them look at the first content full paint step and not that initial painting step so that's just a distinction there you might want to remember does that make sense that I confuse anyone with that yes I confuse you or yes it makes it well so essentially yeah so on this let's see if it shows it here eeeeeeeeee not too well but essentially when I've loaded this page I don't think this page on my site even exists anymore so if you try to find that I might not you might not find that exact thing but essentially if you were to type this website in and it starts loading it starts loading in all the content the CSS the the JavaScript the HTML and at some point around here it starts painting the page so to visualize what's going on and so the first part of that is starting to paint various layers of it so it might start with like the background image it might start with some placeholder image it might start with some things that are happening kind of in the background as it's painting all the content so that's the first part of painting and so that's when you see the term just painting like a speed test or something it might refer to that first step and then as it continues to show up and things such as the title here starts coming in or this might start being viewed that's when people start calling that the first contentful paint is that first contentful paint sorry sorry I'm talking way too fast to try to wrap this up so I'm sorry about that but if you go into if you search if you do a speed test on your website or page speed insights or you do some some speed test or you even go in the browser and there's something called your developer tools within most browsers and you were to refresh your page you end up with something like this called the waterfall and it just kind of shows you all the different files that your site's loading so over here like my actual domain and then my CSS and some more CSS and some Elementor CSS and some more plugins CSS lots and lots and lots of files but all these every single one of these go through that cycle that I've been describing so every single one so it goes oh hey the html links to some CSS file I don't know where that is so I have to then go to the domain name server the top level domain server the the root server the domain name find the IP address pull it from the Apache server go through this whole process then it goes oh hey now there's an image I don't know where that image is so it's going to go back all of these go through that same process now over the years there's newer things HTTP2 and parallelization all these things I've made this process better so it's not quite as every single one has this entire loop but for the most part most of these still go through a process that looks similar to kind of what we're describing today so that's where you might if you do a page speed test it might say oh you have too many files loading it's because of that having to run that cycle for all those that it might advise you to have less files this is kind of what we've been talking about this is going super slow sorry now that we've gone through this cycle does this cycle kind of make sense to everyone and is there any piece that's super confusing to anyone yet do I have a slide after if you were looking for these slides I do have a domain called frankslides.com if you missed the second s it'll still take you to the same place because I missed the second s a million times so I bought both domains but they just go to a slide share page that has all my presentations on it this one should be somewhere near the top theoretically but I know we have like negative two minutes for questions but does anyone have any questions that I can answer yes oh microphone sorry yeah that's all right does caching either local or server side affect any of that cycle yes so caching it could be its own talk because there's actually like 12 different forms of caching but essentially at every step of that cycle you can use caching to help speed up that piece of the cycle so for those that aren't familiar caching essentially creates a for lack of going into all the technicals essentially creates a copy of some step and so whenever it tries to load it up again it just reads in the copy instead of actually running the step so like server caching when it got to that server part of the cycle instead of having to load all through the database and bring all the content and kind of build all the thing again it'll just look at the copy and when it gets to the browser there's browser caching there's so if it tries to look for the css files or javascript files doesn't have to do that set because there's browser caching that then it just looks at the local copies so each piece of that cycle can have caching applied so you might have a caching plugin you might use cloudflare for their cdn and caching you might also have uh... use different plugins that help with the browser caching so all those combined would speed up the process does that answer your question? does anyone else have any questions that I can answer? yes, oh microphone sorry when you're doing that initial diagram of servers you go to the first one was a root server yes everywhere so it depends on what domain you're typing in so there's gonna be some different things but there's like the ican organization ican? ican? there's like the main the main organizations and then the hosting providers and people there's all different versions of that so you probably don't want to remember like root server and tld server you probably don't need to know that technical detail just being aware that it has to go through a few different processes to find the right IP address that's probably the big takeaway but if you want to hunt down the root server for your particular one it's usually like the organization that owns domain names and the people who kind of manage those is where that initial step is I think we're about to get kicked out but we might have time for one final question does anyone have any other question that I can answer? alright well thank you so much I hope you have a great day