Společný slovník

Editor řekne „nasaď to" a myslí publikování článku. Vývojář slyší deploy celé aplikace. Marketér řekne „cache" a myslí problém s přihlášením, vývojář zkoumá edge cache v CDN a editor jen vidí, že na webu pořád visí stará verze a nikdo mu s tím nechce pomoct. Jedno slovo, víc významů. Všichni mají pocit, že se domluvili, jenže každý odchází s jiným úkolem.

Falešné porozumění je jeden z největších skrytých zdrojů tření kolem webu. Typicky se projeví až pár dní potom, kdy je něco „hotovo" (ale úplně jinak, než někdo čekal).

Eric Evans tenhle problém v Domain-Driven Design (2003) popsal jako ubiquitous language: společný jazyk, kterým mluví byznys, obsah i kód.

Tohle není kapitola ke čtení od první definice k poslední. Je to společný slovník, ke kterému se vracíš ve chvíli, kdy si nejsi jistý, že stejným slovem myslíme totéž. Zbytek knihy se na něj odkazuje. Klidně ho přeskoč a vrať se, až narazíš na pojem, který chceš mít přesně.

Patří k němu i to, která část k čemu patří. Když není jasné, kdo o čem rozhoduje, často to nakonec nevyřeší nikdo. Napříč příručkou proto rozlišuju tři role:

• Obsah — co se říká, komu a proč. Spadá pod něj obsahový model a informační architektura.
• Technika — jak se obsah dostane od změny v repozitáři k uživateli. Spadá pod ní build a deploy, hosting, DNS.
• Provoz — aby web byl dostupný, bezpečný a v souladu s pravidly. Spadná pod něj souhlas, správa a údržba.

Klíčové pojmy

Doména, DNS, hosting

• Doména je textové jméno (firma.cz). Pronajímáte si ho u registrátora, tedy firmy oprávněné doménová jména registrovat. Samotné jméno ještě neznamená, že na něm něco běží.
• DNS (Domain Name System) překládá doménu na IP adresu serveru. Nameserver drží DNS záznamy pro vaši doménu a odpovídá na dotazy. Detail řeší DNS a domény.
• Hosting je místo, kde leží obsah nebo aplikace webu. Praktické rozdíly rozebírá Hosting a CDN.

Registrace jména, překlad jména a uložení webu jsou tři různé služby. Můžete je mít u jednoho dodavatele, ale nemusíte. U větších webů bývá oddělení výhoda: když „web nejde", první otázka zní, která z vrstev selhala. Doména? DNS? Hosting? Celou cestu od adresy k vykreslené stránce projde vyprávěním kapitola jak web technicky funguje.

Build, deploy, rendering

• Repozitář je verzovaný zdroj obsahu a kódu, typicky v Gitu. Drží historii: kdo co změnil a kdy.
• Build je krok, který ze zdrojů vyrobí hotový web. Deploy je vystavení výsledku na hosting. Preview je dočasná verze změny před vydáním, aby ji šlo zkontrolovat. Celou cestu od nápadu po vydání popisuje Git a CI/CD.
• Rendering je okamžik, kdy vznikne výsledné HTML. Může vzniknout předem při buildu, na serveru při požadavku, nebo přímo v prohlížeči uživatele. Rozdíl vysvětluje kapitola Statické, dynamické, hybridní.

Pozor na mýtus „statický web = bez CMS". Statické znamená jen to, že se HTML vyrobí předem při buildu. CMS pro editaci obsahu může běžet normálně, jen se z něj obsah bere dřív než při každém požadavku návštěvníka.

CDN, origin, edge, cache

• Origin je centrální zdroj původních dat. V praxi váš hosting nebo server aplikace.
• CDN je síť serverů, která drží kopie obsahu blíž k návštěvníkům a snižuje latenci. Cloudflare provozuje přes 330 takových míst (337 měst k roku 2026).
• Edge server je první kontaktní bod mezi návštěvníkem a originem. Když má uloženou kopii, vrátí ji rovnou a nemusí se ptát originu.
• Cache je dočasná kopie. Zrychluje web, ale taky vysvětluje, proč po změně někdy chvíli vidíte starou verzi. Celé téma je v Hosting a CDN, konkrétní nástroj v Cloudflare.

CMS a obsahový model

CMS je systém pro správu obsahu. Obsahový model říká, jaké typy obsahu web má a jaká pole k nim patří: „článek", „produkt", „autor", ne jen obecná „stránka".

Typy obsahu se vyplatí pojmenovat jazykem týmu, ne technickými termíny. Obsah pak může procházet stavem draft → review → publish a všichni vědí, co se s ním má stát. Detail je v obsahovém modelu.

Canonical, redirect, sitemapa

Tyhle tři pojmy ovlivňují, jak web čte vyhledávač. Cestu crawl → index → render rozebírá kapitola SEO.

• Canonical (rel="canonical") je značka v <head>, která říká, která URL je hlavní, když má stejný nebo velmi podobný obsah víc adres. Je to nápověda, ne příkaz. Vyhledávač si může vybrat jinou variantu, zvlášť když signály na webu nejsou konzistentní.
• Redirect (301) trvale přesměruje starou URL na novou. Je zásadní při redesignu, kde se mění struktura adres. Někdy je lepší použít 302 (temporary redirect), protože 301 si prohlížeče mohou pamatovat a později se hůř odvolává.
• Sitemapa je XML seznam URL pro vyhledávač. Jeden soubor pojme nejvýš 50 000 URL nebo 50 MB; větší weby se dělí a spojují přes sitemap index.

Core Web Vitals

Core Web Vitals jsou tři metriky, kterými Google sleduje uživatelský zážitek. „Dobrá" hodnota se posuzuje na 75. percentilu reálných návštěv, typicky v datech CrUX:

• LCP (Largest Contentful Paint) — jak rychle se načte hlavní obsah. Dobré pod 2,5 s.
• INP (Interaction to Next Paint) — jak rychle web reaguje na akci. Pod 200 ms.
• CLS (Cumulative Layout Shift) — jak moc layout poskakuje při načítání. Pod 0,1.

Detailně to popisuje Výkon a Core Web Vitals. Velkou roli hrají i média a podklady.

Událost, KPI

Událost je v analytice konkrétní interakce: klik, zhlédnutí videa, odeslání formuláře. Měří se nezávisle na načtení stránky. GA4 na událostech stojí celý a ke každé události lze připojit až 25 vlastních parametrů.

KPI je metrika, kterou jste si vybrali jako měřítko úspěchu. Není to každé číslo v analytice, ale číslo, podle kterého se rozhoduje. Měřicí plán řeší Analytika, výchozí KPI Discovery.

Souhlas

Souhlas znamená souhlas návštěvníka. U webu se často pletou dva rámce, které platí současně:

• ePrivacy řeší ukládání a čtení informací v zařízení: cookies, pixely, local storage. Pro všechno, co není nezbytně nutné, typicky vyžaduje souhlas.
• GDPR řeší zpracování osobních údajů, které z toho může vzniknout.

Legitimní zájem podle GDPR sám o sobě nepřebije souhlas, který vyžaduje ePrivacy. Opatrný výklad a postup je v právu, soukromí a souhlasu. Berte to jako pracovní rámec, ne právní stanovisko. Když zákazník řeší konkrétní riziko, má rozhodnout jeho právník a tým se má držet jeho výkladu.