HTTP/2, HTTP/3 & Web Performance

Modern web protocols, Core Web Vitals, and frontend optimisation

IT & Tech Reports | Class IM24A | 2026

1. Evolution of HTTP
HTTP (HyperText Transfer Protocol) is the foundation of the web. Each version has addressed
limitations of the previous one, dramatically improving performance for modern web applications.

Version Year Transport Key improvement Current share

HTTP/0.9 1991 TCP Single-line GET only 0%

HTTP/1.0 1996 TCP Headers, methods, status codes < 1%

HTTP/1.1 1997 TCP Keep-alive, chunked transfer, Host header

~20%

HTTP/2 2015 TCP+TLS Multiplexing, header compression, server

~65%
push

HTTP/3 2022 QUIC/UDP No HOL blocking, 0-RTT, connection migration

~30%

2. HTTP/1.1 Limitations
Despite being 25+ years old, HTTP/1.1 is still widely used. Its fundamental limitations motivated
HTTP/2:

• Head-of-line blocking — requests in a pipeline are processed in order; slow response blocks all
following ones

• No multiplexing — browsers open 6-8 parallel TCP connections per domain to work around this
• Verbose headers — no compression; cookies and user-agent repeated with every request (often
1-3 KB overhead)

• No server push — server can only respond to explicit client requests

• Connection setup overhead — each new TCP connection requires a 3-way handshake (~100ms
round trip)

3. HTTP/2 — How It Works

HTTP/2 introduces a new binary framing layer below the familiar HTTP methods and headers. All
communication happens over a single TCP connection using streams — independently multiplexed
request/response pairs.

Feature HTTP/1.1 HTTP/2

Protocol format Text Binary frames

Connections 6-8 per domain 1 per domain

 Feature HTTP/1.1 HTTP/2

Multiplexing No (pipeline = ordered) Yes — many streams in one connection

Header compression None — repeated verbatim HPACK — delta encoding + Huffman

Server push No Yes — push resources before requested

Stream priority No Yes — weights and dependencies

Requires TLS Optional Required in practice (browsers enforce)

# Enable HTTP/2 in Nginx (just add http2 to listen directive)

server {
listen 443 ssl http2; # HTTP/2 enabled
server_name [Link];
# ... rest of config
}

# Check if HTTP/2 is active

curl -I --http2 [Link] 2>&1 | grep "HTTP/"
# Expected: HTTP/2 200

# HTTP/2 server push (push CSS alongside the HTML)

location = /[Link] {
http2_push /[Link];
http2_push /[Link];
}

# Check HTTP/2 push headers

curl -I --http2 [Link] | grep Link
# Link: ; rel=preload; as=style

4. HTTP/3 and QUIC

HTTP/3 replaces TCP with QUIC (Quick UDP Internet Connections), a transport protocol built on UDP
and developed by Google. QUIC integrates TLS 1.3 at the transport layer, eliminating the separate TLS
handshake.

Problem HTTP/2 (TCP) HTTP/3 (QUIC)

Transport layer HOL blocking TCP packet loss stalls all streams
Each QUIC stream is independent

Connection setup TCP(1 RTT) + TLS(1-2 RTT) = 2-3

QUIC
RTT
+ TLS = 1 RTT; 0 RTT resumption

Connection migration IP change = reconnect QUIC connection ID — survives IP change

Congestion control Kernel TCP stack QUIC in userspace — faster iteration

Middlebox issues Many firewalls handle TCP well UDP port 443 sometimes blocked

# Enable HTTP/3 in Nginx (requires nginx compiled with QUIC support)

server {
listen 443 quic reuseport; # HTTP/3 over QUIC
listen 443 ssl http2; # HTTP/2 fallback
 ssl_certificate /etc/letsencrypt/live/[Link]/[Link];
ssl_certificate_key /etc/letsencrypt/live/[Link]/[Link];
quic_retry on;

# Tell browser HTTP/3 is available

add_header Alt-Svc 'h3=":443"; ma=86400';
}

# Test HTTP/3 with curl (requires curl with HTTP/3 support)

curl --http3 [Link] -I

# Check what version a site uses

curl -sI [Link] | grep -i "HTTP/"
# HTTP/3 200 (or HTTP/2 200 if HTTP/3 not supported by your curl)

5. Core Web Vitals — Google's Performance Metrics

Core Web Vitals (CWV) are Google's set of metrics that measure real user experience. They directly
affect Google search rankings. Measuring and improving CWV is one of the highest-ROI performance
tasks for web developers.

Metric Measures Good Needs work Poor

LCP — Largest Contentful Paint Time to render the largest visible

< 2.5selement 2.5–4s > 4s

FID — First Input Delay (legacy) Time from first interaction to <
browser
100ms response
100–300ms > 300ms

INP — Interaction to Next Paint (new)

Worst interaction delay across
< 200ms
page lifetime200–500ms > 500ms

CLS — Cumulative Layout Shift Visual stability — unexpected< layout

0.1 shifts 0.1–0.25 > 0.25

FCP — First Contentful Paint When first content appears (not

< 1.8s
a CWV but1.8–3s
important) > 3s

TTFB — Time to First Byte Server response speed < 800ms 800ms–1.8s > 1.8s

6. Web Performance Optimisation Techniques

6.1 Network and Server
• Use a CDN (Cloudflare, CloudFront, Fastly) — serve static assets from edge nodes closest to
users

• Enable HTTP/2 (or HTTP/3) — eliminates multiple TCP connections and head-of-line blocking

• Enable gzip/Brotli compression — Brotli achieves 15-25% better compression than gzip

• Set long cache headers for static assets (1 year) and use content hashes in filenames

• Use early hints (103 status) to preload critical resources while HTML is generated

• Reduce TTFB: optimise database queries, add Redis caching, use edge functions

6.2 Images
 • Use modern formats: WebP (30% smaller than JPEG), AVIF (50% smaller) with JPEG/PNG
fallback

• Always specify width and height attributes on images to prevent CLS

• Lazy load off-screen images: loading='lazy' attribute

• Serve responsive images with srcset: different sizes for different screen widths

• Use CSS sprites or icon fonts for small UI icons to reduce HTTP requests

• Compress images: ImageOptim (Mac), Squoosh (web), imagemin (CI pipeline)

6.3 JavaScript and CSS

• Code splitting ([Link] / dynamic import) — only load JS needed for the current page

• Tree shaking — remove unused code; requires ES modules (import/export)

• Minify JS and CSS — Terser for JS, cssnano for CSS; removes whitespace and renames
variables

• Defer non-critical JS: use the defer or async attribute on script tags

• Inline critical CSS (above-the-fold styles) to eliminate render-blocking stylesheet

• Avoid render-blocking resources — move script tags to end of body or use async/defer

7. Measuring Performance
# Lighthouse CLI — automated performance audit
npm install -g lighthouse
lighthouse [Link] --view
lighthouse [Link] --output json --output-path [Link]

# WebPageTest — real browser test from multiple locations

# [Link] — free, detailed waterfall chart

# Chrome DevTools — built-in profiling

# Network tab: see request timing, waterfall, transfer sizes
# Performance tab: flame chart of JS execution
# Coverage tab: see unused CSS and JS

# curl timing breakdown

curl -o /dev/null -s -w "
DNS lookup: %{time_namelookup}s
TCP connect: %{time_connect}s
TLS handshake:%{time_appconnect}s
TTFB: %{time_starttransfer}s
Total: %{time_total}s
Size: %{size_download} bytes
" [Link]

# Google PageSpeed Insights API

curl "[Link]
gy;=mobile&key;=YOUR_API_KEY" | jq '.[Link]'

# Real User Monitoring (RUM) with web-vitals library

 # import {getCLS, getFID, getLCP} from 'web-vitals';
# getCLS([Link]); getFID([Link]); getLCP([Link]);

8. Resource Hints and Preloading

9. Performance Budget
A performance budget is a set of limits on metrics that affect page load performance. Setting a budget
and enforcing it in CI prevents performance regressions.

Metric Budget Tool to enforce

Total JS (compressed) < 150 KB bundlesize, webpack-bundle-analyzer

Total CSS < 30 KB bundlesize, PurgeCSS report

Total images (per page) < 500 KB imagemin CI check

LCP < 2.5s Lighthouse CI, web-vitals

CLS < 0.1 Lighthouse CI

Number of requests < 50 Lighthouse CI

TTFB < 500ms Synthetic monitoring (Datadog, Pingdom)

10. HTTP Headers Reference — Performance and Security

Header Value example Purpose

Cache-Control max-age=31536000, immutableCache static assets 1 year

Cache-Control no-store Never cache sensitive data

Vary Accept-Encoding Cache separate versions per encoding

ETag "abc123" Conditional GET — 304 Not Modified

Content-Encoding br Brotli compressed response

Strict-Transport-Security max-age=63072000; includeSubDomains

Force HTTPS for 2 years

Content-Security-Policy default-src 'self' Prevent XSS

X-Content-Type-Options nosniff Prevent MIME type sniffing

Permissions-Policy camera=(), microphone=() Restrict browser features

Alt-Svc h3=":443"; ma=86400 Advertise HTTP/3 availability

Server-Timing db;dur=32, render;dur=18 Expose timing to DevTools