Aktualizace článku: 31. srpna 2026
Původní text z roku 2019 popisoval stav, kdy byl <link rel="prerender"> živou technologií a Core Web Vitals ještě neexistovaly. Od té doby se změnilo hodně: prerender byl označen za zastaralý a nahrazen Speculation Rules API, přibyl atribut fetchpriority, modulepreload se stal široce dostupným a jako metrika odezvy nastoupilo INP místo FID. Celý článek jsem proto přepsal podle stavu prohlížečů v roce 2026.
Existuje několik způsobů, jak zvýšit celkovou rychlost webu. Jedním z nich je připravit si zdroje dřív, než je budete potřebovat. Rychlost webu je důležitou metrikou nejen pro SEO, ale i pro ostatní online marketingové kanály - a má přímý vliv na konverzní poměr, tedy na plnění cílů webu.
Skvělé je, že prohlížeče mají pro všechny tyto věci jednoduchý vestavěný (nativní) způsob. Nechci fušovat do řemesla specialistům na rychlost webu, ale potřeboval jsem mít zdroj informací, na který se mohu odkazovat a který si mohu sám aktualizovat. Pokud řešíte rychlost jako součást širší optimalizace, navazuje na tento text moje služba technického SEO auditu a prakticky totéž se probírá na školení technického SEO.
Začnu spoilerem :-) Optimální použití v roce 2026:
rel="preload" - když budete zdroj potřebovat hned na aktuální stránce (font, LCP obrázek, kritický skript)
rel="modulepreload" - totéž pro ES moduly, včetně jejich závislostí
rel="preconnect" - když víte, že si z cizí domény brzy něco stáhnete, ale ještě neznáte přesnou URL
rel="dns-prefetch" - levnější varianta preconnectu pro domény, které přijdou na řadu později, a záloha pro prohlížeče bez podpory preconnectu
rel="prefetch" - když budete potřebovat konkrétní soubor na další stránce (pozor: Safari nepodporuje)
Speculation Rules API - když chcete předem načíst nebo rovnou vykreslit celou další stránku. Nahrazuje zastaralý rel="prerender".
<link rel="preload" href="/fonts/inter-latin.woff2" as="font" type="font/woff2" crossorigin>
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
<link rel="dns-prefetch" href="https://www.googletagmanager.com">
<link rel="prefetch" href="/js/detail-produktu.js">
<!-- rel="prerender" je zastaralý, náhradou je Speculation Rules API -->
Přehled podpory v prohlížečích (srpen 2026)
Tohle je hlavní důvod, proč jsem článek přepisoval. Rozdíly mezi prohlížeči jsou u těchto technik zásadní a rozhodují o tom, jestli má smysl je vůbec nasazovat:
| Technika | Chrome / Edge | Safari | Firefox |
|---|---|---|---|
preload |
Ano | Ano | Ano |
preconnect |
Ano | Ano | Ano |
dns-prefetch |
Ano | Ano (nově i na iOS a iPadOS) | Ano |
modulepreload |
Ano | Ano (od Safari 17) | Ano (od Firefoxu 115) |
fetchpriority |
Ano | Ano (od Safari 17.2) | Ano (od Firefoxu 132) |
prefetch |
Ano | Ne | Ano |
| Speculation Rules API | Ano | Zatím jen za experimentálním přepínačem | Ne (deklarován kladný postoj k prefetchi) |
prerender (link tag) |
Zastaralé | Ne | Ne |
Aktuální stav si vždy ověřte v tabulkách Can I use a v dokumentaci MDN. Ke každé technice níže odkazuji konkrétní tabulku.
Preload
Link rel="preload" říká prohlížeči, aby co nejdříve stáhl a uložil do mezipaměti zdroj (například skript, šablonu stylů nebo font) a měl ho rychle k dispozici. Je užitečný, když tento zdroj potřebujete brzy během načítání stránky.
Prohlížeč se stahovaným zdrojem nic sám neudělá. Skripty se nespustí, styly se nepoužijí. Zdroj je jen v mezipaměti, takže když ho něco jiného potřebuje, je okamžitě k dispozici.
<link rel="preload" href="/images/hero.webp" as="image">
<link rel="preload" href="/css/kriticke.css" as="style">
href ukazuje na URL zdroje, který chcete stáhnout. Atribut as říká, o jaký typ zdroje jde:
- style - šablony stylů
- script - skripty
- font - písma (vyžaduje navíc atribut
crossorigin) - image - obrázky, typicky LCP obrázek
- fetch - zdroje stahované pomocí
fetch()neboXMLHttpRequest - a další hodnoty - viz úplný seznam na MDN
Pro různé druhy zdrojů prohlížeče obvykle přiřazují různé priority, aby stáhly nejdůležitější věci jako první. U zdroje načteného pomocí rel="preload" prohlížeče určují prioritu právě podle atributu as.
Novinka: fetchpriority
Od roku 2019 přibyl atribut fetchpriority s hodnotami high, low a auto, kterým můžete prohlížeči prioritu ručně přepsat. Dnes ho podporují všechny hlavní prohlížeče (Firefox jako poslední na podzim 2024). Je to jen nápověda - v prohlížeči, který ho nezná, se nic nerozbije.
Praktický důsledek: pro LCP obrázek, který je už v HTML, dnes nepotřebujete preload. Stačí atribut přímo na elementu:
<img src="hero.webp" fetchpriority="high" alt="...">
Preload obrázku má smysl hlavně tehdy, když se jeho URL objevuje až v CSS (pozadí), v srcset generovaném skriptem nebo v carouselu. Více v dokumentaci fetchpriority na MDN.
Kdy preload použít
Link rel="preload" pomůže, pokud potřebujete zdroj na aktuální stránce co nejdříve.
Například ve svém CSS souboru načítáte konkrétní fonty. Než ale prohlížeč CSS stáhne a rozparsuje, o existenci těch fontů neví. Pomocí preloadu mu můžete říct, ať je začne stahovat hned.
Preload je pro aktuální stránku, proto s ním neplýtvejte. Načítejte předem jen ty zdroje, které jsou skutečně důležité pro počáteční vykreslení. Když preloadnete deset věcí, prohlížeč nemá jak poznat, která z nich je opravdu ta hlavní - a výsledkem bývá pomalejší LCP, ne rychlejší.
Modulepreload pro ES moduly
Pokud váš web staví na ES modulech (typicky moderní frontendové frameworky), používejte místo obyčejného preloadu variantu <link rel="modulepreload">. Rozdíl je zásadní: prohlížeč modul nejen stáhne, ale i rozparsuje a rekurzivně dotáhne jeho závislosti. Od září 2023 je tato technika široce dostupná ve všech hlavních prohlížečích, takže ji už není nutné obcházet. Detaily najdete v dokumentaci modulepreload na MDN.
Preconnect
Než prohlížeč požádá o zdroj z cizí domény (typicky skripty typu GTM, Analytics, chat, fonty), musí nejdřív navázat spojení - DNS překlad, TCP handshake a TLS handshake. Link rel="preconnect" ho požádá, aby to udělal předem. Šetří to čas, protože ve chvíli, kdy prohlížeč zdroj skutečně potřebuje, je spojení už hotové.
<link rel="preconnect" href="https://www.googletagmanager.com">
Kdy preconnect použít
Preconnect dává smysl, pokud víte, že si ze serveru brzy něco stáhnete, ale ještě neznáte přesnou URL zdroje.
Klasickým příkladem jsou Google Fonts. Vaše CSS načítá písma z fonts.gstatic.com, ale přesnou URL souboru dopředu neznáte. Pomocí rel="preconnect" můžete prohlížeči říct, ať se k této doméně připojí předem. U fontů nezapomeňte na atribut crossorigin - bez něj se naváže jiné, anonymní spojení a celá optimalizace přijde vniveč.
Preconnect používejte střídmě - ideálně pro dvě až čtyři nejdůležitější domény. Otevřené spojení stojí prohlížeč i server prostředky, a pokud se do deseti sekund nevyužije, prohlížeč ho zase zavře. Deset preconnectů na deset marketingových skriptů web nezrychlí, jen mu vezme kapacitu.
Ještě lepší je se cizím doménám v kritické cestě vyhnout úplně - typicky hostovat fonty na vlastní doméně. Pak nepotřebujete ani preconnect, ani DNS překlad navíc.
Early Hints (HTTP 103)
Preconnect a preload dnes nemusíte posílat jen v HTML. Server může ještě před finální odpovědí poslat průběžnou odpověď HTTP 103 Early Hints s hinty preload a preconnect. Prohlížeč tak začne pracovat v okamžiku, kdy váš backend teprve sestavuje HTML - využije se takzvaný server think-time.
Early Hints podporuje Chromium (Chrome, Edge) pro navigaci hlavního rámce a nasadit je umí Nginx, Apache, Node.js i CDN jako Cloudflare nebo Fastly. Vyžadují HTTP/2 nebo HTTP/3 a fungují jen pro preload a preconnect, nikoli pro prefetch. Podrobnosti popisuje dokumentace Chrome k Early Hints a MDN ke stavovému kódu 103.
DNS-prefetch
Link rel="dns-prefetch" funguje podobně jako preconnect, jen provede pouze překlad DNS pro danou doménu - bez TCP a TLS handshaku.
<link rel="dns-prefetch" href="https://www.clarity.ms">
Kdy dns-prefetch použít
Dns-prefetch je levnější a lehčí varianta preconnectu. Nechte si ho jako zálohu a hlavně ho použijte pro domény, které přijdou na řadu později v načítání - u nich by plné spojení bylo plýtvání.
Praktické rozdělení: dvě až čtyři nejkritičtější domény dostanou preconnect, zbytek třetích stran dns-prefetch.
Prefetch
Link rel="prefetch" požádá prohlížeč, aby na pozadí stáhl a uložil do mezipaměti zdroj (například skript nebo šablonu stylů). Stahování probíhá s nízkou prioritou, takže nezasahuje do důležitějších zdrojů. Je užitečný, když víte, že daný zdroj budete potřebovat na následující stránce.
<link rel="prefetch" href="/css/detail-produktu.css">
<link rel="prefetch" href="/js/detail-produktu.js">
Kdy prefetch použít
Link rel="prefetch" pomůže, pokud potřebujete konkrétní soubor na jiné stránce a chcete urychlit její vykreslení.
Například máte e-shop a 40 % uživatelů přejde z homepage na detail produktu. Pomocí rel="prefetch" stáhnete předem CSS a JS soubory odpovědné za vykreslení produktových stránek.
Prohlížeč není povinen pokyn rel="prefetch" uposlechnout. Může se rozhodnout zdroj nestáhnout, například při pomalém připojení nebo v režimu úspory dat. Prefetch také spotřebovává data uživatele navíc, takže „pro jistotu“ předstahovat desítky souborů není zadarmo.
Nepoužívejte prefetch pro urgentní zdroje. Pokud zdroj potřebujete k vykreslení aktuální stránky, patří tam rel="preload".
Co se u prefetche od roku 2019 změnilo
Safari prefetch nepodporuje a nic nenaznačuje, že by to mělo přijít. Pro iOS a macOS tedy s touto technikou nepočítejte.
HTTP cache je dnes rozdělená podle top-level domény. Prefetchovat zdroje z cizích webů „do zásoby“ kvůli sdílené cache už tedy nedává smysl - každý web má svou vlastní přihrádku.
Prefetchované požadavky nesou hlavičku Sec-Purpose: prefetch. Na to pozor při měření: pokud si tyto požadavky nevyfiltrujete, budete si kazit serverové logy i analytiku. Podobný typ zkreslení řeším i u provozu od AI botů.
Pro předběžné načtení celé další stránky dnes používejte Speculation Rules API, ne <link rel="prefetch">. Ten má smysl už jen pro jednotlivé soubory.
Prerender je zastaralý - nastupuje Speculation Rules API
Původní <link rel="prerender"> požádal prohlížeč, aby na pozadí stáhl a vykreslil celou stránku, a ta se pak po kliknutí zobrazila okamžitě. Tato značka je dnes na MDN označená jako zastaralá a nestandardní, není definovaná v žádné specifikaci a je nahrazena Speculation Rules API. Nikdy ji nepodporoval Safari ani Firefox. Pokud ji máte v kódu, nic tím nezískáváte - viz poznámka o zastarání na MDN.
<link rel="prerender" href="/detail-produktu">
Náhradou je Speculation Rules API - blok JSON přímo v HTML (nebo v samostatném souboru), kterým prohlížeči popíšete, které stránky má předem načíst (prefetch) nebo rovnou vykreslit (prerender) a jak agresivně:
Ukázka pravidel
<script type="speculationrules">
{ "prerender": [{ "where": { "href_matches": "/*" }, "eagerness": "moderate" }] }
</script>
Klíč where vybírá odkazy podle URL nebo CSS selektoru, eagerness říká, kdy má prohlížeč zasáhnout: immediate, eager, moderate (při najetí myší) a conservative (až při stisku tlačítka).
Podpora podle dokumentace Speculation Rules API na MDN vypadá v roce 2026 takto: Chrome a Edge mají klíč prerender od verze 105, prefetch od verze 110 a klíče eagerness a where od verze 121. Safari má implementaci hotovou, ale zatím jen za experimentálním přepínačem. Firefox zaujal kladné stanovisko k části prefetch, ale podporu zatím nevydal. MDN celé API stále označuje jako omezeně dostupné, takže s ním počítejte jako s vylepšením pro část publika, ne jako s plošným řešením.
Na co si dát pozor při prerenderu
Vykreslení stránky na pozadí spotřebovává CPU i paměť. Používejte ho tam, kde si jste opravdu jistí záměrem uživatele - typicky tlačítko „Do košíku“ nebo „Zaplatit“. Pro plošné nasazení volte eagerness: "moderate", ne immediate.
Prerenderovaná stránka se počítá do analytiky až v okamžiku aktivace. Ověřte si, že vaše měření pracuje s událostí prerenderingchange, jinak si nafouknete zobrazení stránek. Podobné chyby v měření řeším i na školení GA4.
Neprerenderujte akce s vedlejšími efekty - odhlášení, mazání, odeslání objednávky. Vyloučit je můžete přes selektor v klíči where.
Nejčastější chyby, které v praxi vidím
- Preload bez atributu
crossoriginu fontů. Font se stáhne dvakrát - jednou zbytečně. Nejčastější chyba vůbec. - Preload zdroje, který se na stránce nakonec nepoužije. Chrome to hlásí v konzoli jako varování o nevyužitém preloadu. Typicky zůstane po redesignu.
- Preload deseti souborů najednou. Když je prioritní všechno, není prioritní nic.
- Preconnect na každou třetí stranu. Nekritické domény patří pod
dns-prefetch. - Zbytky
rel="prerender"v šabloně. Mrtvý kód, který jen mate. - Resource hinty místo řešení příčiny. Když máte 4 MB nekomprimovaných obrázků nebo blokující skripty ve
<head>, žádný preload to nezachrání.
Jak dopad změřit
Resource hinty nasazujte vždy proti měření, ne od oka. Prakticky se osvědčuje tento postup:
- Chrome DevTools, panel Network - sloupec Priority ukáže, jestli prohlížeč vaše hinty skutečně respektuje.
- PageSpeed Insights a laboratorní data z Lighthouse pro rychlou zpětnou vazbu při vývoji.
- Reálná data z CrUX (Chrome User Experience Report) a report Core Web Vitals v Search Console - jediné, co se počítá pro hodnocení Googlem.
- Sledujte správné metriky: dnes je to LCP, CLS a INP. Metrika FID, která platila v době vzniku původního článku, byla v březnu 2024 nahrazena právě metrikou INP.
Rychlost je jen jedním z technických faktorů. Pokud řešíte výkon webu komplexně, navazují na tento text i moje články o indexaci filtrační navigace a o prioritizaci obnovy obsahu. Kompletní technickou revizi řeším v rámci SEO analýzy, u e-shopů pak specificky v SEO pro e-shopy. Provozujete-li Shoptet, řadu těchto věcí za vás platforma řeší sama - co jde a co ne, popisuji v SEO pro Shoptet.
Shrnutí pro rok 2026
Používejte bez obav: preload (střídmě, s crossorigin u fontů), preconnect (2-4 domény), dns-prefetch (zbytek třetích stran), modulepreload a fetchpriority. Vše je plně podporované ve všech hlavních prohlížečích.
Používejte s rozmyslem: prefetch pro jednotlivé soubory (v Safari nefunguje) a Speculation Rules API pro celé stránky (zatím prakticky jen Chromium).
Odstraňte z kódu: <link rel="prerender">.
Rychlost webu není jednorázová věc: každý nový tag, plugin nebo nasazení ji může posunout zpět. Proto ji hlídám jako součást měsíční SEO správy, vedle indexace, obsahu a odkazů.
Největší rychlostní regrese vídám po redesignu: nová šablona přinese fonty, slidery a skripty, které nikdo nezměřil. Proto je kontrola testovacího prostředí součástí dohledu nad migrací a redesignem webu.
Jestli se pomalé načítání projeví i na chování lidí, se dá ověřit v nahrávkách: zuřivé kliky do tlačítka, které nereaguje, jsou typický příznak. Postup popisuji na stránce analýza dat z Clarity.