Add glossary term 'head-of-line blocking'

files/en-us/glossary/head_of_line_blocking/index.md

@@ -0,0 +1,19 @@
+---
+title: Head-of-line blocking
+slug: Glossary/Head_of_line_blocking
+page-type: glossary-definition
+---
+
+{{GlossarySidebar}}
+
+In computer networking, **head-of-line blocking** (_HOL blocking_) refers to a performance bottleneck that occurs when a queue of packets is held up by the first packet in the queue, even though other packets in the queue could be processed.
+
+In HTTP/1.1, HOL blocking can occur when a client sends multiple requests to a {{glossary("server")}} without waiting for the responses. The server processes the requests in order, but if the response to the first request is delayed, the responses to subsequent requests are also delayed. HTTP/2 addresses this issue through request multiplexing, eliminating HOL blocking in the application layer, but it still exists at the transport ({{glossary("TCP")}}) layer.
+
+## See also
+
+- Related glossary terms
+  - {{glossary("HTTP")}}, {{glossary("HTTP 2", "HTTP/2")}}
+  - {{glossary("TCP")}}
+- [Populating the page: how browsers work](/en-US/docs/Web/Performance/How_browsers_work)
+- [Head-of-line blocking](https://en.wikipedia.org/wiki/Head-of-line_blocking) on Wikipedia

files/en-us/glossary/http_2/index.md

@@ -8,7 +8,7 @@ page-type: glossary-definition
 
 **HTTP/2** is a major revision of the [HTTP network protocol](/en-US/docs/Web/HTTP).
 
-The primary goals for HTTP/2 are to reduce {{glossary("latency")}} and head-of-line blocking by enabling full request and response multiplexing, minimize protocol overhead via efficient compression of HTTP header fields (HPACK), and support for request prioritization.
+The primary goals for HTTP/2 are to reduce {{glossary("latency")}} and {{glossary("head of line blocking", "head-of-line blocking")}} by enabling full request and response multiplexing, minimize protocol overhead via efficient compression of HTTP header fields (HPACK), and support for request prioritization.
 
 HTTP/2 also introduced a mechanism called Server Push, which allowed a server to send resources to a client in anticipation that the client would need them very soon.
 Server Push proved tricky to implement in practice, and has been removed from most major browser engines.

files/en-us/web/api/webtransport_api/index.md

@@ -15,7 +15,7 @@ The **WebTransport API** provides a modern update to {{domxref("WebSockets API",
 
 These include:
 
-- **Head-of-line blocking**
+- **{{glossary("head of line blocking", "Head-of-line blocking")}}**
   - : HTTP/2 allows multiplexing, so a single connection can stream multiple resources simultaneously. However, if a single resource fails, all other resources on that connection are held up until any missing packets are retransmitted. With QUIC, only the failing resource is affected.
 - **Faster performance**
   - : QUIC is more performant than TCP in many ways. QUIC can handle security features by itself, rather than handing responsibility off to other protocols like TLS — meaning fewer round trips. And streams provide better transport efficiency than the older packet mechanism. That can make a significant difference, especially on high-latency networks.

files/en-us/web/http/connection_management_in_http_1.x/index.md

@@ -53,7 +53,7 @@ In HTTP/1.1, persistence is the default, and the header is no longer needed (but
 >
 > - Buggy [proxies](https://en.wikipedia.org/wiki/Proxy_server) are still common and these lead to strange and erratic behaviors that Web developers cannot foresee and diagnose easily.
 > - Pipelining is complex to implement correctly: the size of the resource being transferred, the effective [RTT](https://en.wikipedia.org/wiki/Round-trip_delay_time) that will be used, as well as the effective bandwidth, have a direct incidence on the improvement provided by the pipeline. Without knowing these, important messages may be delayed behind unimportant ones. The notion of important even evolves during page layout! HTTP pipelining therefore brings a marginal improvement in most cases only.
-> - Pipelining is subject to the [HOL](https://en.wikipedia.org/wiki/Head-of-line_blocking) problem.
+> - Pipelining is subject to the {{glossary("head of line blocking", "head-of-line blocking")}}.
 >
 > For these reasons, pipelining has been superseded by a better algorithm, _multiplexing_, that is used by HTTP/2.
 

files/en-us/web/http/messages/index.md

@@ -329,7 +329,7 @@ Digging further into message frames, stream IDs and how the connection is manage
 
 This guide provides a general overview of the anatomy of HTTP messages, using the HTTP/1.1 format for illustration.
 We also explored HTTP/2 message framing, which introduces a layer between the HTTP/1.x syntax and the underlying transport protocol without fundamentally modifying HTTP's semantics.
-HTTP/2 was introduced to solve the head-of-line blocking issues present in HTTP/1.x by enabling multiplexing of requests.
+HTTP/2 was introduced to solve the {{glossary("head of line blocking", "head-of-line blocking")}} issues present in HTTP/1.x by enabling multiplexing of requests.
 
 One issue that remained in HTTP/2 is that even though head-of-line blocking was fixed in the protocol level, there is still a performance bottleneck due to head-of-line blocking within TCP (at the transport level).
 HTTP/3 addresses this limitation by using QUIC, a protocol built on UDP, instead of TCP.