As I understand it, the status code would improve performance in situations like the following:

1. Client requests X.html (which requires Y.css and Z.js) from Proxy.

2. Proxy forwards client's X.html request to Server.

3. [Server takes a long time to respond]

4. Server sends a 200 response to Proxy with X.html.

5. Proxy, per some configuration, adds Preload headers to this response indicating that Y.css and Z.js should be immediately loaded once this response is received, and sends it to Client.

6. Client requests Y.css and Z.js.

With the 103 status code, this would look like:

1. Client requests X.html (which requires Y.css and Z.js) from Proxy.

2. Proxy forwards client's X.html request to server and, per some configuration, immediately sends a 103 response with Preload headers for Y.css and Z.js to Client.

3. [Server takes a long time to respond]

4. In parallel, Client requests Y.css and Z.js.

5. Server sends a 200 response to Proxy with X.html.

6. Proxy sends this response to Client.

Note that since Y.css and Z.js are requested sooner, the final load time should be less.

The proxy could also read preload headers from the Server, and start preemptively fetching Y.css and Z.js from the Server at the same time (step 2) it forwards the preload headers back to Client.

Yeah, the actual name is "103 Early Hints" not "103 Approved".

I guess the title was meant as "… Approved as new status code", not "HTTP 103 Approved …". A bit unfortunate wording (and that capital A).

Someone only read the headline.

I read the headline and it colored my reading of the linked article. Bad headlines set up bad context. Someone also lowercased the "a" in approved in the headline since I saw it.

Someone else suggested https://tools.ietf.org/html/draft-ietf-httpbis-early-hints-0..., which has more context without a need for a second click.

You linked to revision 00; revision 05, https://tools.ietf.org/html/draft-ietf-httpbis-early-hints-0..., is the version of the spec that has just been approved.