YourAppURL

Replace the value you are getting underneath the app above.

The ultimate guide to web development interviews. Developed by FAANG engineers, practice with real-world interview questions covering network security, system design, SEO, APIs, and more.

oct6.tar.gz

server

JavaScript

Grunt

webpack

webpack-loaders

Grunt-eslint

ProgressiveRendering

webpack-code-splitting

This course compiles a comprehensive range of questions that are most likely to be asked during the frontend interview. Where many interview prep courses focus on data structures and algorithms, this course focuses on a variety of topics from network security to system design.

In this course, you will solve interview questions that cover general aspects of web development. You’ll start by going over network security and optimization techniques for load balancing and browser rendering. After that, you’ll move on to interview questions around SEO, APIs, and system design.

Overall, these are questions that are often overlooked, but they can really make you stand out from your peers. By the end of this course, you will have the confidence and ability to go in and ace that interview.

Web Development Interview Handbook

# TCP connections
For a host to request a website, it first needs to establish a connection with the server called a ‘TCP connection.’ This TCP connection requires a ‘handshake,’ much like the [TLS handshake](https://www.educative.io/courses/web-development-interview-handbook/https#how-tls-works) we studied that requires at least three back and forth messages between the client and the server. Once a connection is established, the TLS handshake can occur if the connection is to be encrypted, which requires two messages for TLS 1.3.


So, a total of at least five messages need to be exchanged before any requests can be made. This is a considerable overhead, and optimizing it deserves attention. In this lesson, we will study common measures to address this issue.


# One connection per request
If one connection is established per request, we'll end up having to do multiple handshakes per request. This will take too much overhead and is not feasible. 

# One connection per host
If one connection is established per host for the entirety of the exchange, we would completely avoid the overhead of multiple handshakes. This can be achieved with the `connection keep-alive header` in HTTP/1.1, which instructs browsers to keep a connection open.

Here’s the catch though: the requests go out in order on a single connection. This means that the first request that is made goes out first, while the rest are held back in a queue until the first request’s response is received fully.

Multiple requests are often fired more or less simultaneously in the browser. So, if ten requests are fired at once, we’ll have to wait for a response to the first one to come in before we can even send the second one. Hence, requests would be held back, resulting in a delay if one connection is used per host.


## HTTP pipelining
HTTP/1.1 has another feature called ‘HTTP pipelining,’ which enables the browser to send multiple requests in quick succession without waiting for their responses on a single TCP connection. That fixes our problem. Right?

Actually, no. This feature has a catch, too. The server, in this case, has to respond to the requests in the same order that it has received them.

So, if the server ends up calculating a response for the fifteenth request it receives, it won’t be able to send that response until it has a response for the first one, which again introduces a delay. So, this approach is generally avoided.


# Solution HTTP/1.1: fixed number of parallel connections

A good compromise is to use a fixed number of connections per host. So, if you have six connections for your browser, six requests can be fired off simultaneously, but the seventh will be queued until a connection frees up.

These connections may be kept open for a while in case more requests come in, and can be closed after not being used for a certain period of time to free up memory.


# Solution HTTP/2: multiplexing
With HTTP/2, the constraint that the server needs to send the responses in the order it got the requests is gone. _Multiplexing_  enables mapping the requests and responses.

So, the server can immediately respond with whichever request is processed first, and HTTP/2 will map each response to the original request. Generally, all of this is done through one TCP connection. We’ll study HTTP/2 in a bit more detail in an upcoming lesson.

# Looking at real requests

1. Open up your favorite browser.
2. Right-click anywhere and choose 'inspect element' from the drop-down menu.
3. Open up the network tab that you will find on the top bar.
4. Go to your favorite website and see how the requests are made. Try to figure out what approach is being used, and if it can be optimized.



We went to Educative.io. Look at how the Connection ID for all the requests is the same, and how h2, or HTTP/2, is being used. Our website is using multiplexing!


How HTTP requests are made impacts performance. Let's study how this process can be optimized.

Introduction

Network

Security

Optimizing Loading Performance

Optimizing Browser Rendering Performance

Search Engine Optimization

System Design

APIs

Testing

Version Control

Task Runners & Bundlers

Conclusion

Optimizing Requests

TCP connections

One connection per request