103 Early Hints
Allows the server to send Link headers before the main response, prompting the browser to preload assets.
Meaning & Description
While the server is busy doing heavy work—like querying a database or rendering an HTML page—it can immediately fire off a `103 Early Hints` response. This tells the browser to start downloading critical assets (like CSS, JavaScript, or fonts) in the background. By the time the server finishes generating the `200 OK` HTML response, the browser has already downloaded the necessary assets, significantly reducing page load time and improving Core Web Vitals (specifically LCP).
Common Causes
- A CDN (like Cloudflare or Fastly) is configured to parse `Link` headers from a previous cached response and emit them as a 103 Early Hint for the current request.
- A Node.js or Ruby on Rails server explicitly emits a 103 response before executing the main business logic.
How to fix a 103 error
- Ensure your server or CDN is actually emitting the `103 Early Hints` response (use `curl -v` as browser dev tools often hide 1xx responses).
- Verify the `Link` headers in the 103 response use the correct `rel=preload` or `rel=preconnect` attributes.
- Check that the final 200 OK response also includes the same `Link` headers (as required by the specification).
- Ensure your site is served over HTTPS/HTTP2+, as browsers generally only support Early Hints over secure, multiplexed connections.
Browser & SEO Behaviour
Browser Behavior
When Chrome or Firefox receives a 103 Early Hints response, it immediately begins preloading the resources specified in the `Link` headers while continuing to wait for the main HTML document.
SEO Impact
Highly positive. Early Hints directly improve Largest Contentful Paint (LCP) and First Contentful Paint (FCP) metrics by parallelizing asset downloads with server processing time. Faster Core Web Vitals heavily influence Google search rankings.
CDN Behavior
Modern CDNs (like Cloudflare and Fastly) have advanced support for Early Hints. Cloudflare can cache the `Link` headers from previous 200 OK responses and proactively send a 103 Early Hint to the next client while it fetches the HTML from your origin server.
Code Examples
GET /article/123 HTTP/1.1
Host: example.com
HTTP/1.1 103 Early Hints
Link: </styles.css>; rel=preload; as=style
Link: </app.js>; rel=preload; as=script
[... Server spends 500ms querying the database ...]
HTTP/1.1 200 OK
Content-Type: text/html
Link: </styles.css>; rel=preload; as=style
Link: </app.js>; rel=preload; as=script
<!DOCTYPE html>
<html>...</html>const http = require('http');
const server = http.createServer((req, res) => {
// Send the 103 Early Hints response
res.writeEarlyHints({
'Link': [
'</styles.css>; rel=preload; as=style',
'</script.js>; rel=preload; as=script'
]
});
// Simulate 500ms of database/rendering work
setTimeout(() => {
res.writeHead(200, { 'Content-Type': 'text/html' });
res.end('<html><head><link rel="stylesheet" href="/styles.css"></head><body>Hello</body></html>');
}, 500);
});# Standard Python WSGI (PEP 3333) does not support 1xx interim responses natively.
# Support for Early Hints requires an ASGI server (like Uvicorn/Daphne)
# and a framework that explicitly implements HTTP/2 and ASGI early hints extensions.
# Most developers rely on CDNs (Cloudflare) to generate the 103 Early Hint
# automatically based on the Link headers in the final 200 OK response.package main
import (
"net/http"
"time"
)
func handler(w http.ResponseWriter, r *http.Request) {
// Go 1.10+ supports HTTP/2 Server Push, but Early Hints (103) is the modern replacement.
// Go currently requires Hijacking or specific middleware to send 103 natively,
// but you can set Link headers for CDNs to convert into 103s:
w.Header().Add("Link", "</style.css>; rel=preload; as=style")
// Simulate work
time.Sleep(500 * time.Millisecond)
w.WriteHeader(http.StatusOK)
w.Write([]byte("<html>...</html>"))
}# curl will display the 103 Early Hints response before the 200 OK
curl -v https://example.com/Raw HTTP Response Example
HTTP/2 103 Early Hints
link: </main.css>; rel=preload; as=style
link: <https://fonts.gstatic.com>; rel=preconnect
HTTP/2 200 OK
content-type: text/html; charset=utf-8
link: </main.css>; rel=preload; as=style
<!DOCTYPE html>...Real-world Examples
Frequently Asked Questions
Is 103 Early Hints better than HTTP/2 Server Push?
Yes. HTTP/2 Server Push was deprecated by Chrome because it often sent assets the browser already had in its cache, wasting bandwidth. Early Hints (103) just sends the *hint* (the URL), allowing the browser to check its cache before deciding whether to download the asset.
Does my backend server need to support 103 Early Hints?
Not necessarily. If you use a CDN like Cloudflare, you can just include `Link` headers in your standard 200 OK response. The CDN will remember them and automatically send a 103 Early Hint for subsequent visitors.
Can I put HTML content in a 103 response?
No. The 103 Early Hints response is strictly informational and contains only headers. The actual content must be delivered in the final response (e.g., 200 OK).
Which browsers support 103 Early Hints?
Chromium-based browsers (Chrome, Edge) and Firefox support Early Hints. Safari support is actively being developed. Browsers that do not support it will simply ignore the 103 response and wait for the 200 OK.
Did You Know?
103 Early Hints is the first new HTTP status code to achieve widespread adoption on the web in nearly a decade.
It replaced HTTP/2 Server Push as the industry-standard way to solve the "server think time" problem.
If your server is incredibly fast (e.g., rendering HTML in 10ms), Early Hints might actually slightly degrade performance due to the overhead of sending an extra TCP frame.
Developer Tips
- Only preload critical, render-blocking assets (like the main CSS file or the primary web font). Preloading too many assets will cause bandwidth contention and slow down the page load.
- If you are using a CDN to generate Early Hints, ensure your `Link` headers are consistent. If a user logs in and gets different CSS files, the CDN might send the wrong hints.
- Use the `as` attribute in your Link headers (`as=style`, `as=script`, `as=font`). Browsers need this to prioritize the download queue correctly.
Interview Questions
These are questions you might face in a backend or API design interview that touch on HTTP 103.
Explain the difference between 103 Early Hints and HTTP/2 Server Push.
Server Push actively forced the asset down the connection to the client, which often wasted bandwidth if the client already had the asset cached. 103 Early Hints just sends the URL via a header, allowing the browser to check its local cache first and only download the asset if necessary.
How does 103 Early Hints improve Core Web Vitals?
It utilizes the "dead time" while the server is rendering HTML (server think time) to instruct the browser to start downloading critical assets like CSS and LCP images. This parallelization directly improves First Contentful Paint (FCP) and Largest Contentful Paint (LCP).
What happens if a browser doesn't understand the 103 status code?
By standard HTTP design, clients that receive an unrecognized 1xx informational response will simply ignore it and continue waiting for the final response. It is a completely safe, progressively enhanced optimization.
Common Interview Mistakes
- Saying that 103 Early Hints pushes the actual files to the browser. It only pushes the headers (hints).
- Assuming Early Hints is a replacement for caching. It is an optimization for dynamic, uncacheable HTML documents that take time to generate.
- Thinking Early Hints works on HTTP/1.1. While technically possible, major browsers only process Early Hints over HTTP/2 or HTTP/3.