In the world of front‑end, where every millisecond reduction in load time can translate into user loss, developers seek solutions that not only speed up component rendering but also optimize the network layer. One such solution is the HTTP/2 protocol. In this article we’ll examine how HTTP/2 works, why it’s better than HTTP/1.1, and how to leverage its features in React and Next.js projects.
Basics: how the HTTP/2 protocol works
HTTP/2, published in 2015 as RFC 7540, retains the semantics of HTTP/1.1 (methods, status codes) but introduces an entirely new transport layer based on a binary frame format. This enables multiplexing—simultaneous transmission of multiple requests and responses over a single TCP connection. In practice, it eliminates the so‑called “head‑of‑line blocking” problem that forced HTTP/1.1 to open many parallel connections.
Key advantages of HTTP/2 for web applications
The most important benefits that HTTP/2 brings are:
- Multiplexing – multiple resources (HTML, CSS, JS, images) are fetched concurrently, reducing latency.
- Header compression (HPACK) – reduces header size, which is especially noticeable with frequent API requests.
- Server Push – the server can “push” resources it predicts the browser will need before they are requested.
- Prioritization – the client can indicate which streams are more important, and the server adjusts their delivery order.
Combined with a modern JavaScript stack, these mechanisms significantly cut round‑trips and speed up the first page render.
HTTP/1.1 vs. HTTP/2 in practice
In HTTP/1.1 each request required a separate TCP connection or at least a queue within a single connection, leading to a maximum of six concurrent connections per domain in browsers. As a result, developers used techniques like spriting or inlining to limit request counts. HTTP/2 removes this need—thanks to multiplexing, all resources can be fetched simultaneously, and the browser manages their ordering itself.
“In the era of HTTP/2, the number of requests no longer matters; it’s the efficiency of their transmission that counts.”
Implementing HTTP/2 in Node.js – what you need to know
Node.js has native HTTP/2 support in the http2 module since version 8.4.0. Configuration is simple: just create a server with http2.createSecureServer and provide a TLS certificate, because browsers require encrypted connections for HTTP/2.
const http2 = require('http2');
const fs = require('fs');
const server = http2.createSecureServer({
key: fs.readFileSync('key.pem'),
cert: fs.readFileSync('cert.pem')
});
server.on('stream', (stream, headers) => {
// simple HTTP/2 response
stream.respond({ ':status': 200, 'content-type': 'text/html' });
stream.end('<h1>Hello HTTP/2</h1>');
});
server.listen(8443);
Keep in mind that not all middleware libraries (e.g., some versions of Express) work directly with the http2 object. Therefore, in Next.js projects the common approach is to use an intermediate server—e.g., next start run via node-http2 or a reverse proxy like Nginx that converts HTTP/1.1 connections to HTTP/2.
Using multiplexing and server push in Next.js
Since version 9.5, Next.js supports server push together with Node.js. With the res.push function we can push critical assets (CSS, JS) alongside HTML, shortening time‑to‑first‑byte (TTFB). Example in pages/_document.js:
import Document, { Html, Head, Main, NextScript } from 'next/document';
export default class MyDocument extends Document {
static async getInitialProps(ctx) {
const originalRenderPage = ctx.renderPage;
ctx.renderPage = () => originalRenderPage({
// custom logic if needed
});
const initialProps = await Document.getInitialProps(ctx);
return initialProps;
}
render() {
return (
<Html>
<Head>
{this.props.__NEXT_DATA__.assetPrefix && (
this.props.__NEXT_DATA__.assetPrefix && this.props.res &&
this.props.res.push('/_next/static/css/style.css', {
request: { accept: '*/*' },
response: { 'content-type': 'text/css' }
})
)}
</Head>
<body>
<Main />
<NextScript />
</body>
</Html>
);
}
}
In practice we most often recommend using next-optimized-images and next-fonts, which automatically generate resource versions ready for push, and the server (e.g., Nginx) configures http2_push_preload rules based on the Link: header in the response.
Practical checklist: HTTP/2 in a React/Next.js project
- Make sure the server supports TLS – browsers require HTTPS for HTTP/2.
- Enable HTTP/2 support in the reverse proxy (Nginx:
listen 443 ssl http2;). - Configure header compression (HPACK is built into the protocol by default).
- Use
res.pushorLink:headers for server push of critical resources. - Use
next/imageandnext/font– they automatically generate smaller images and fonts, reducing the number of round‑trips. - Monitor metrics: TTFB, LCP, number of HTTP/2 streams (e.g., in Chrome DevTools → Network → Protocol).
Common mistakes and trade‑offs when implementing HTTP/2
Although HTTP/2 brings many benefits, it isn’t free of pitfalls. The most frequent issues are:
- Incorrect TLS configuration – weak cipher suites or missing ALPN can cause the browser to fall back to HTTP/1.1.
- Excessive server push – pushing too many resources consumes bandwidth and can slow down other connections.
- Lack of support in some CDNs – not all CDN providers fully support HTTP/2 push, so you need to check their documentation.
- Multiplexing and rendering order – stream prioritization requires deliberate setting of
:priorityheaders, which isn’t always automatic in libraries.
A sensible approach is to introduce features gradually: first enable the protocol itself, then test push on the most important assets, and finally fine‑tune priorities.
In summary, HTTP/2 is not just a technical upgrade of the network layer but also a tool that, combined with React and Next.js, enables building fast, responsive applications. If you want your projects to fully leverage this protocol—from server configuration to front‑end code optimization—contact us at Coderia.it. Together we’ll create solid, scalable solutions that will delight your users.



