HTTP 103 Early Hints 2026: LCP gyorsítás preload és preconnect headerekkel

Frissítve: 2026. augusztus 30.

A HTTP 103 Early Hints egy informatív státuszkód, amellyel az origin szerver már azelőtt elküldheti a böngészőnek a kritikus erőforrások (LCP kép, CSS, hero font) Link: rel=preload és rel=preconnect headereit, mielőtt a végleges 200-as HTML válasz elkészülne. A böngésző így a szerver „gondolkodási idejét" (TTFB) hasznos preload és preconnect műveletekre fordítja, és a mért LCP javulás a Cloudflare, Shopify és Akamai adatai szerint p75-ön 300 és 500 ms között mozog. Az RFC 8297-es szabvány 2017 óta létezik, de 2026-ra végre teljes CDN- és böngészőtámogatással üzemi szintre érett.

Mi az a HTTP 103 Early Hints?

A HTTP 103 Early Hints egy „informational" (1xx) státuszkód, amelyet az RFC 8297 definiál 2017 decembere óta. A lényeg röviden: az origin szerver kettéválasztja a választ. Először kiküld egy 103-as fejlécet a legfontosabb Link hintekkel, és csak utána, 200 vagy 500 ms múlva, a végleges 200-as HTTP választ a HTML törzzsel. A böngésző a 103 vétele után azonnal elindítja a hintelt preconnect és preload kéréseket, tehát a szerver gondolkodási ideje (adatbázis-lekérés, template renderelés, third-party API hívás) alatt már tölti a hero képet és a kritikus CSS-t.

Ez különösen fontos az e-commerce oldalakon, ahol egy termékoldal HTML-jének generálása gyakran 300 és 800 ms között tart. Ezalatt a böngésző korábban tétlenül várt. Early Hints-szel viszont pont a legdrágább erőforrás, az LCP kép már ott van a browser cache-ben, mire a HTML megérkezik és a preloader szkennel. A mechanizmus a szabvány szerint bármennyi 1xx választ engedélyez a végleges válasz előtt, de a gyakorlatban egyet küldünk, 3 vagy 8 Link headerrel.

Hogyan működnek az Early Hints a gyakorlatban?

A folyamat három lépésből áll. Először a böngésző elindít egy navigációs kérést az oldalra. Másodszor, az origin szerver (vagy egy CDN köztes csomópont, amely eltárolta a hint készletet) azonnal, még a HTML generálása előtt kiküldi a 103-as választ. Harmadszor pedig jön a végleges 200-as válasz HTML törzzsel. A protokoll szintjén ez így néz ki:

HTTP/2 103 Early Hints
Link: </static/hero-desktop.avif>; rel=preload; as=image; fetchpriority=high
Link: </static/critical.css>; rel=preload; as=style
Link: <https://cdn.shopify.com>; rel=preconnect; crossorigin
Link: <https://analytics.example.com>; rel=preconnect

HTTP/2 200 OK
Content-Type: text/html; charset=utf-8
Cache-Control: private, max-age=0
Link: </static/hero-desktop.avif>; rel=preload; as=image
...

<!DOCTYPE html>
<html>...

Fontos: a végleges válaszban is ismételd meg a Link headereket, mert azok a böngészők, amelyek nem támogatják a 103-at (pl. Safari < 17), csak a végleges választ látják. Ez nem duplikálja a letöltést, mivel a preloader észreveszi, hogy a kérés már folyamatban van, vagy már a cache-ben lakik.

Early Hints vs klasszikus preload: mi a különbség?

Ez a leggyakoribb kérdés, amit fejlesztőktől kapok. A rövid válasz: a klasszikus <link rel="preload"> tag a HTML törzsében akkor kezd hatni, amikor a böngésző már megkapta a HTML első bájtjait és a preloader elkezdi szkennelni. Az Early Hints ezt kb. 200 vagy 500 ms-mal korábban, még a HTML megérkezése előtt indítja el. A hosszú válasz az alábbi tábla:

Az én ökölszabályom: ha az origin HTML generálás 200 ms-nál lassabb és van CDN-ed, ami támogatja a 103-at, akkor mindig érdemes bevetni. Viszont ha statikus HTML-t szolgálsz ki edge cache-ből 20 ms TTFB-vel, a klasszikus <link rel="preload"> is elegendő, mert nincs mit „elrejteni" a felhasználó előtt.

Böngésző támogatás 2026-ban

A helyzet 2026 augusztusában a következő. A Chrome 103+ hivatalosan támogatja a 103-at mind preload, mind preconnect hintekre, és mivel az Edge is Chromium alapú, ott ugyanez igaz. A Firefox 123 (2024. február) óta szintén teljes körű támogatással érkezett. A Firefox ESR csatorna is naprakész.

A Safari a kakukktojás: a Safari 17-ben debütált a támogatás, de kizárólag preconnect hintekre. A Safari 18.4-ben (2025 tavasz) továbbra sem került be a preload, és a WebKit blogon nincs publikus roadmap. Ez a gyakorlatban azt jelenti, hogy az iOS és macOS felhasználók a hero kép preloadból nem profitálnak, de a preconnect (pl. CDN, third-party domain) számukra is működik. Globálisan a Chrome/Edge/Firefox arány ~93%, tehát a felhasználók túlnyomó többsége részesül az előnyökből.

CDN támogatás: Cloudflare, Fastly, Vercel, Netlify, Akamai

A CDN oldali támogatás 2026-ra kiforrott. A Cloudflare vezet: a Smart Hints funkció automatikusan generálja a hinteket a korábbi kérések letöltési grafikonjából, tehát nem kell semmit sem az origin oldalon módosítani. A Cloudflare 2026 májusi jelentése szerint már több mint 2 billió hintet szolgált ki, 150 000+ oldalon. A Cloudflare Pages platformon (pages.dev és custom domainek) alapból be van kapcsolva.

A Fastly a VCL és a Compute@Edge környezetben támogatja a 103-at, de explicit konfigurációt igényel, tehát nincs automatikus generálás. A Vercel az Edge Network HTTP/2 és HTTP/3 útvonalain támogatja; a régi HTTP/1.1 fallback nem küld 103-at. A Netlify egyelőre limitált, mert a statikus fájl architektúra és a 60 másodperces function cap miatt a dinamikus hint generálás nehézkes. Az Akamai Property Manager beépített „Early Hints" behavior-t kínál, aktív ügyfél-esettanulmányokkal.

Bevezetés Cloudflare Smart Hints-tel

Őszintén, a legegyszerűbb út a Cloudflare Smart Hints, mert nem kell hozzányúlni sem az origin szerverhez, sem a HTML-hez. A dashboardon menj a Speed → Optimization → Content Optimization → Smart Hints menübe, és kapcsold be. Ezután várni kell 24 vagy 48 órát, amíg a Cloudflare gépi tanulási modellje elég letöltési grafikont gyűjt össze az adott oldalról ahhoz, hogy megbízható hinteket generáljon.

Ha kézzel akarod meghatározni a hinteket (pl. dinamikus termékoldal esetén), akkor a klasszikus Early Hints funkciót használd. Ez a HTML válasz Link headereit másolja át 103-ba, tehát az origined kell hogy küldje a Link headert:

// Cloudflare Worker példa: Link header injektálása termékoldalhoz
export default {
  async fetch(request, env) {
    const url = new URL(request.url);
    const response = await fetch(request);

    // Csak termékoldalra tegyünk hint-et
    if (url.pathname.startsWith('/products/')) {
      const newHeaders = new Headers(response.headers);
      // A Cloudflare 103-ba fogja átfordítani
      newHeaders.append('Link',
        '</static/product-hero-fallback.avif>; rel=preload; as=image; fetchpriority=high');
      newHeaders.append('Link',
        '<https://cdn.shopify.com>; rel=preconnect; crossorigin');

      return new Response(response.body, {
        status: response.status,
        headers: newHeaders,
      });
    }
    return response;
  },
};

Node.js origin: writeEarlyHints() a gyakorlatban

Ha saját origin szervert futtatsz Node.js-en, a natív response.writeEarlyHints() API-t használhatod, ami Node.js 18.11 óta stabil. A hint-et azonnal kiküldjük, amint tudjuk, hogy milyen erőforrások kellenek, jellemzően a route feloldása után, de még az adatbázis-lekérés előtt:

// Node.js natív http szerver, writeEarlyHints() példa
import { createServer } from 'node:http';
import { getProductBySlug } from './db.js';

createServer(async (req, res) => {
  if (req.url?.startsWith('/products/')) {
    // 1. Early Hints azonnal, még adatbázis-lekérés előtt
    res.writeEarlyHints({
      link: [
        '</static/critical.css>; rel=preload; as=style',
        '</static/hero-placeholder.avif>; rel=preload; as=image; fetchpriority=high',
        '<https://cdn.example.com>; rel=preconnect; crossorigin',
        '<https://analytics.example.com>; rel=preconnect',
      ],
    });

    // 2. A lassú munka: adatbázis, template
    const slug = req.url.split('/products/')[1];
    const product = await getProductBySlug(slug); // ~250 ms
    const html = renderProductTemplate(product);  // ~50 ms

    // 3. Végleges válasz
    res.writeHead(200, {
      'Content-Type': 'text/html; charset=utf-8',
      'Link': '</static/critical.css>; rel=preload; as=style',
    });
    res.end(html);
  } else {
    res.writeHead(404).end();
  }
}).listen(3000);

Fontos: a writeEarlyHints() hívást akkor tedd, amikor tudod, hogy milyen erőforrások kellenek. Ha még a route feloldás előtt hívnád, akkor sok esetben rossz hinteket küldenél. Például a hero képet a homepage-ről akkor is preloadolnád, ha a /kosar oldalra megy a user. Az én rendszerünkben egy egyszerű route-alapú lookup tábla van, ami eldönti, hogy melyik path milyen hinteket kap.

nginx 1.29 és Fastify konfiguráció

Az nginx 1.29.0 (2025. június) hozott natív early_hints direktívát. Fontos részlet: az nginx nem generálja a 103 választ, csak továbbítja a backend által küldött 103-at a kliens felé. Tehát a Node.js/Go/Rust origined kell hogy küldje a 103-at, az nginx pedig helyesen továbbadja HTTP/2 vagy HTTP/3 downstream-en:

# nginx.conf részlet, 1.29+ szükséges
http {
  early_hints on;

  upstream backend {
    server 127.0.0.1:3000;
  }

  server {
    listen 443 ssl http2;
    listen 443 quic reuseport;

    location / {
      proxy_pass http://backend;
      proxy_http_version 1.1;
      # A backend 103 válaszát az nginx átalakítja HTTP/2 informatív frame-mé
    }
  }
}

Fastify oldalon a @fastify/early-hints plugint használjuk, amely szintaktikai cukorral becsomagolja a natív Node.js API-t:

// Fastify + @fastify/early-hints
import Fastify from 'fastify';
import earlyHints from '@fastify/early-hints';

const app = Fastify();
await app.register(earlyHints);

app.get('/products/:slug', async (request, reply) => {
  await reply.writeEarlyHints([
    { href: '/static/critical.css', rel: 'preload', as: 'style' },
    { href: '/static/hero.avif', rel: 'preload', as: 'image', fetchpriority: 'high' },
  ]);

  const product = await getProduct(request.params.slug);
  return reply.type('text/html').send(renderTemplate(product));
});

await app.listen({ port: 3000 });

Mennyivel gyorsítják az Early Hints az LCP-t?

Konkrét, mért adatokat mutatok. Nem szintetikus lab számokat, hanem valós RUM méréseket. A Cloudflare Smart Hints jelentése több mint 100 000 ügyfélről 6%-os LCP javulást mért a p50-en, és 16%-ot a p75-ön desktop kliensen. Mobilon szerényebb, mert a lassú hálózat amúgy is dominál. A Shopify a Black Friday időszakában kb. 500 ms LCP nyereséget mért p50-en, ami e-commerce konverzióban 2 vagy 3% árbevétel-növekedést jelent.

Az Akamai ügyfelek RUM adatai szerint p75-ön ~300 ms nyereség tipikus, néhány kiugró esetben 30% javulás. Egy 2025-ös hospitality esettanulmányban a „good LCP" (2,5 mp alatti) sávba 20 százalékponttal több felhasználó került. Ezek a számok különösen dinamikus HTML-en jelentkeznek, ahol a TTFB 400 és 800 ms között van. Statikus, edge-cache-elt oldalakon az Early Hints marginális.

Gyakori buktatók és mikor NE használjuk

Van néhány éles helyzet, ahol az Early Hints kifejezetten kárt okozhat. Az első és leggyakoribb: rossz hint-et küldeni. Ha egy admin oldalra 103-ban preload-olunk egy termékkép URL-t, akkor sávszélességet és CPU-t pazarlunk semmiért. Ebbe pontosan én is belefutottam egy ügyfelemnél, ezért kell útvonal-specifikus hint konfiguráció.

A második: iframe és subresource kérések. A 103 spec szerint csak top-level navigációra vonatkozik. Ha egy iframe HTML-hez 103-at küldesz, a Chrome egyszerűen figyelmen kívül hagyja. A harmadik: caching intermediary-k. Az RFC 8297 §2 kifejezetten tiltja a 103 tárolását végleges válaszként, de néhány régi corporate proxy még mindig hibázik.

Negyedik: Chrome 133+ TTFB mérési artifact. A Chrome 133 óta a responseStart a 103 válasz idejét is tartalmazza, tehát a mért TTFB a bekapcsolás után dramatikusan lecsökken, de ez mérési változás, nem valódi backend javulás. Ne dőlj be a saját statisztikáidnak, mérd az LCP-t is.

Ötödik: túl sok hint. Ha 15 Link headert nyomsz be, a böngésző mindet elindítja párhuzamosan, és megfojtod vele a HTML letöltését. Max 3 vagy 5 kritikus erőforrást hintelj: LCP kép, kritikus CSS, hero font, esetleg 1-2 preconnect.

Mérés Chrome DevToolsban és WebPageTestben

A Chrome DevTools Network panel „Timing" fülén a „Waiting for server response" alatt látod, hogy jött-e 103. Kapcsold be a „Show 103 Early Hints" opciót a jobb felső fogaskerék alatt (Chrome 118+), és a Network listában külön sorként jelenik meg a 103. Ezután az adott navigációs kérésre kattintva a „Preview" tab megmutatja a hintelt erőforrásokat és azok időzítését.

A WebPageTest a waterfall diagramon zöld nyilakkal jelzi az Early Hints által kiváltott korai kéréseket. Konkrétabb, számszerű összehasonlításhoz futtass A/B tesztet: 50% forgalom 103-mal, 50% nélküle, és nézd a p75 LCP különbséget CrUX-ban 28 nap után. A MDN 103 dokumentáció részletes protokoll példákat is ad. Lighthouse audit szempontból figyeld a „Preload Largest Contentful Paint image" és a „Largest Contentful Paint request discovered late" audit-okat, ezek zölddé válnak, ha helyesen hintelsz.

E-commerce esettanulmány: 380 ms LCP a termékoldalon

Az egyik korábbi projektemben, egy közepes méretű DIY szerszám webshop (~2 millió unique/hó), a termékoldal p75 LCP 3,2 másodperc volt. A TTFB 620 ms, mert az árazási motor real-time hívta a warehouse API-t. A hero kép egy 180 KB-os AVIF, ami 350 ms-ig töltődött a HTML megérkezése után.

Így vezettük be: Cloudflare előtt Fastify origin, ahol a route matcher azonnal írt egy writeEarlyHints()-et a hero képre és a kritikus CSS-re, még azelőtt, hogy az árazási motor válaszolt volna. Két hét múlva a p75 LCP 2,82 mp-re esett, ami 380 ms nyereség. A konverziós A/B teszt +1,7% checkout arányt hozott. A CLS és INP nem változott. A legnagyobb tanulság számomra: nem elég a technológia, tudni kell, hogy melyik route melyik erőforrást hinteli. Egy naiv „mindenhova ugyanaz a hint" konfiguráció fél százalékkal rontotta volna a homepage LCP-t, mert felesleges kép preloadot indított.

Ha a JavaScript bundle méret és a third-party szkript optimalizálás után kifutottál a lehetőségekből az LCP-n, akkor az Early Hints a következő logikus lépés. Kombináld a Speculation Rules API-val a navigáció még korábbi elindítására, akkor a felhasználó tényleg úgy érzi, hogy „azonnal betölt".