← Referenční architektury / reference-architecture / diagrams / content-delivery

Návrh distribuované architektury pro výkon webu

Tento průvodce popisuje komplexní strategii výkonu aplikací na vrstvě 7 (L7) určenou architektům a vývojářům. V dnešním konkurenčním digitálním prostředí výkon aplikací je zásadním prvkem, který odlišuje firmy od konkurence. Konečným cílem je však najít rovnováhu mezi výkonem a zabezpečením.

Tento průvodce se sice zaměřuje na maximalizaci rychlosti a uživatelského zážitku (UX), výkon ale nesmí jít na úkor zabezpečení. Architekti musí vyvažovat snížení latence s nezbytnou režií na zpracování při důsledných bezpečnostních kontrolách, jako jsou ochrana proti DDoS, WAF a Bot Management.

Ve vysoce rizikových scénářích musí mít přednost bezpečnost: „rozpočet na latenci“ získaný díky těmto výkonnostním optimalizacím se strategicky reinvestuje do zásadní ochrany, aby aplikace zůstala dostatečně rychlá pro konverzi uživatelů a zároveň dostatečně zabezpečená pro ochranu firmy.

Měření dopadu: Zatímco marketingové dashboardy (například Google Analytics) sledovat obchodní výsledky, Cloudflare Web Analytics a Observatory měří hybatele výkonu. Pomocí nich lze v reálném čase propojit zlepšení Core Web Vitals (CWV) a Real User Monitoring (RUM) přímo se snížením míry okamžitého opuštění a vyššími konverzemi, aniž by to bylo na úkor soukromí nebo vyžadovalo náročné klientské skripty.

Díky této architektuře mohou organizace očekávat:

• Zlepšování Core Web Vitals (CWV) jako LCP a INP, které mohou pomoci snížit míru okamžitého opuštění a zvýšit prodeje.
• Maximalizace poměru zásahů v cache (Cache Hit Ratio), která odlehčuje provoz od originu, snižuje náklady na infrastrukturu a celkově snížení provozních nákladů.
• Zajištění vysoké dostupnosti/uptime a odolnost podnikání i během špiček v provozu.

Měření výkonu je ošemetné ↗, a zapadá do širšího obchodního kontextu, v němž se zabezpečení a Dodržování předpisů ↗ bývají často nepodkročitelnou podmínkou. Organizace si běžně ověřují, že jejich architektura splňuje regulační normy (například rezidence dat ↗ nebo šifrovací protokoly, včetně Postkvantová kryptografie (PQC)) před odemknutím výkonnostních funkcí.

Jakmile jsou tyto bezpečnostní a compliance základy zajištěny, efektivní optimalizace začíná měřením „správných“ věcí, což je zajímavé, protože se to pro každého mírně liší. Většina lidí by se však shodla na tom, že je třeba se zaměřit na metriky výkonu webu orientované na uživatele pomocí TTFB jako diagnostický nástroj ↗ pro odezvu serveru, ale upřednostnění Core Web Vitals (CWV) ↗ pro měření uživatelské zkušenosti.

Úspěšnost implementace se měří pomocí těchto metrik:

Cíl 75. percentilu je na základě předchozí analýzy ↗ kvůli rozumné rovnováze.

Tento diagram znázorňuje životní cyklus požadavku a ukazuje, jak vrstvy Cloudflare/fáze - Síť, optimalizace, ukládání do mezipaměti a připojení k origin serveru společně minimalizují latenci.

Pro ilustrační účely je architektura rozdělena do čtyř logických vrstev a řídí se konkrétními fáze. Pro dosažení co nejlepšího celkového výkonu je nutné optimalizovat každý krok tohoto řetězce.

Cesta výkonu začíná na zařízení klienta. Hardware zařízení, prohlížeč ↗, kvalita sítě a topologie určují počáteční odezvu. Cílem je navázat co nejrychlejší připojení k síti Cloudflare.

• Překlad DNS: Klientské zařízení odesílá dotaz na doménu, který prochází přes veřejný DNS resolver a nakonec se dostane až k autoritativnímu DNS serveru. Cloudflare globální anycast síť ↗ směruje požadavky do nejbližšího Point of Presence (PoP), přičemž globální DNS ↗ překlad zajišťující minimální latenci vyhledávání, včetně možnosti rozšíření na pevninská Čína.
• Navázání připojení: Klient naváže připojení přes IPv4/IPv6 pomocí HTTP/3 (QUIC) a TLS 1.3 - to také umožňuje Postkvantová kryptografie (PQC). Pokud klient web navštívil již dříve, Obnovení připojení 0-RTT eliminuje zpáteční cesty (round trips) během handshaku. Kromě toho HTTP Strict Transport Security (HSTS) prosazuje přesměrování na HTTPS na straně prohlížeče, čímž odstraňuje zbytečné zpáteční cesty na server. Obecně se doporučuje vynucení připojení přes HTTPS. Kromě toho lze díky využití příslušných Pole TCP, můžete zavést adaptivní strategie výkonu.
• Optimalizace prohlížeče: Funkce jako Speed Brain (Speculation Rules API) prostředky proaktivně předběžně načítají, zatímco Early Hints odesílají prohlížeči hlavičky link během takzvané „server think time“, čímž urychlují vykreslování stránky.
• Odlehčení pomocí třetích stran: Zaraz přesouvá nástroje třetích stran (například Google Analytics 4 nebo Mixpanel) do cloudu. To snižuje blokování hlavního vlákna na zařízení a výrazně zlepšuje INP.
• Web Analytics (RUM): Využijte Cloudflare Web Analytics ke sběru výkonnostních dat přímo z prohlížeče uživatele, a to způsobem šetrným k soukromí a bez použití cookies. Tento odlehčený JavaScriptový beacon poskytuje reálný přehled o metrikách Core Web Vitals (LCP, INP, CLS), aniž by sledoval uživatele nebo ukládal stav na straně klienta.

Jakmile požadavek dorazí na okraj sítě, Cloudflare obsah zpracuje a optimalizuje, než ho poskytne nebo načte z mezipaměti.

• Správa provozu: Požadavek se zkontroluje. Normalizace URL zajišťuje konzistenci, zatímco Redirect Rules nebo Transform Rules efektivně zajišťují úpravy cesty. Waiting Room chrání backend během masivní nárůsty provozu, a zachovat tak dostupnost.
• Programové přizpůsobení: Pro pokročilé případy použití, kdy standardní pravidla nestačí, Snippets a Workers umožňují programové přizpůsobení. Díky tomu lze spouštět vlastní logiku kódu pro úpravu hlaviček, přepisování URL adres, optimalizace obrázků, nebo implementovat vlastní logiku ukládání do mezipaměti přímo na okraji sítě. Využijte Service Bindings k zajištění komunikace mezi těmito Workers s nízkou latencí a nulovou režií.
• Optimalizace obsahu: Textové soubory jsou komprimovány pomocí Compression Rules (Brotli/Gzip). Obrázky se zpracovávají za běhu pomocí Image Transformations nebo Polish aby byly danému zařízení podávány v optimálním formátu (AVIF/WebP) a velikosti, což výrazně zlepšuje hodnoty LCP a CLS.
• Optimalizace fontů a značek: Cloudflare Fonts eliminuje vyhledávání DNS a připojení TLS ke Google Fonts tím, že je poskytuje přímo (inline) z dané domény. Google Tag Gateway zlepšuje měření reklamních signálů a soukromí.
• Směrování, dostupnost a analýza protokolů: Cloudflare provozuje jednu z nejvíce propojené sítě ↗ ve světě, propojenou (peering) s více než 13 000 sítěmi, provozující globální páteřní síť ↗, a účastí na velkém počtu Internetové výměnné uzly (IXP) ↗ globálně. Využíváme přitom jedinečné poznatky ↗ odvozených z tohoto obrovského souboru dat k dynamické optimalizaci řízení přetížení (Congestion Control, CC) na úrovni protokolu: automaticky vybírá optimální algoritmus a ladí příslušné parametry pro každé připojení podle aktuálních podmínek v síti. U dynamických požadavků, které nelze ukládat do mezipaměti, Argo Smart Routing nachází nejrychlejší cestu sítí k origin serveru. Vlastní chyby zajišťují konzistentní zkušenost se značkou i v případě výpadků.

Cloudflare lze uspořádat do konkrétní topologie. Tato vrstva se stará o uchovávání a načítání obsahu. Funguje jako štít pro origin a zároveň jako vysokorychlostní úložiště pro klienta.

• Logika cache: Hlavičky Cache-Control originu, Cache Rules a Úrovně cache umožňují přesně řídit TTL a zpracování query stringů. Pomocí strategií Cache Normalization můžete sloučit požadavky s proměnlivými URL adresami, například s odlišnými marketingovými nebo SEO parametry, do jediné Cache Key, čímž se výrazně zlepšuje poměr úspěšných zásahů do mezipaměti. Adresy URL pro Prefetch může předem naplnit mezipaměť klíčovými aktivy prostřednictvím manifest souborů a dále tak snížit latenci. Všimněte si výchozí chování a limity ukládání do mezipaměti.
• Tiered Caching: Pokud obsah není na lokálním PoP, Cloudflare zkontroluje topologii mezipaměti vyšší úrovně. Smart Tiered Caching a Regional Tiered Cache centralizují připojení, čímž zvyšují poměr zásahů do mezipaměti (cache hit) a snižují zátěž origin serveru v globálním měřítku. Pro individuálnější přístup si zákazníci Enterprise mohou zvolit Custom Tiered Cache topologie.
• Vyhrazená dlouhodobá cache: Cache Reserve prodlužuje životnost velkých, málo přistupovaných assetů (například obrázků, archivovaného videa, aktualizací softwaru nebo statických AI modelů) tím, že málo využívaný obsah přesouvá do trvalého objektového úložiště (na bázi R2). Tím se zabraňuje jeho vyřazení kvůli Least Recently Used (LRU) algoritmy a zabraňuje dotazům na origin, které zvyšují latenci, a zároveň splňuje požadavky na redundanci a odolnost úložiště.
• Instant Purge: Využijte Cloudflare decentralizovaná architektura purgování mezipaměti ↗ ke globální invalidaci obsahu přibližně za 150 ms. Toto Instant Purge podporuje různé podrobné přístupy, včetně Purge by URL, Tag, Prefix nebo Hostname, díky čemuž uživatelé okamžitě dostávají aktuální obsah, aniž by museli čekat na vypršení TTL.
• Konektivita v cloudu: Cloud Connector Rules zjednodušují směrování provozu k poskytovatelům veřejného cloudu (AWS, Azure, GCP) pro konkrétní požadavky na objektové úložiště nebo origin server. Pro privátní infrastrukturu Workers VPC umožňuje přímé připojení k soukromým koncovým bodům úložišť nebo databázím ve veřejných cloudech (například AWS, Azure), aniž by je bylo nutné vystavit veřejnému internetu.
• Hostování statického obsahu: Celé části aplikace (frontendové zdroje, obrázky včetně velkých mediálních souborů, softwarové balíčky) lze uložit přímo v R2 Object Storage nebo Workers Static Assets, a obsluhovat je přímo z okraje sítě, aniž by kdy zasáhly tradiční origin server. Další možnosti úložiště jsou k dispozici.

U požadavků, které musí projít celou cestou (tedy dynamický obsah nebo cache miss), určuje výslednou latenci konfigurace originu. Architekti zde mají dvě hlavní možnosti: přijmout výkonný a odolný serverless model (známý také jako originless), nebo optimalizovat konektivitu a zabezpečení pro tradiční Origin Server.

Serverless: Cloudflare Developer Platform dosahuje optimální úrovně výkonu díky zapnutí modelu „bez originu“. Fullstack aplikace se vytvářejí a nasazují přímo na globální edge síti po celém světě, čímž odpadá nutnost směrovat provoz až ke vzdálenému origin serveru. Dynamické požadavky se zpracovávají v nejbližším PoP Cloudflare a poskytují plynulý přístup k integrovaným řešení pro ukládání dat na okraji sítě jako R2 Object Storage a D1 Serverless SQLite Database. To výrazně snižuje TTFB a významně přispívá k náročným cílům CWV. Tento model bez originu, využívající Workers a R2, je navíc optimálním řešením pro vysoce výkonnou distribuci souborů, protože odstraňuje potřebu tradičního backendového serveru pro doručování rozsáhlých datových sad a médií.

Tradiční optimalizace původního serveru: Pro aplikace, které nelze refaktorovány nebo modernizovány ↗ na model bez origin serveru je nutné provést následující optimalizace, aby se minimalizoval dopad latence tradiční infrastruktury:

• Konektivita: Cloudflare se připojuje pomocí HTTP/2 to Origin, pomocí Opakované použití připojení k multiplexování požadavků přes jediné trvalé připojení, čímž se snižuje režie TCP/TLS. Pro vyšší spolehlivost a zabezpečení Cloudflare Network Interconnect (CNI) umožňuje připojit síťovou infrastrukturu přímo k Cloudflare, mimo veřejný internet, pro výkonnější a bezpečnější řešení. Kromě toho díky využití Bandwidth Alliance ↗ (včetně partnerů jako Microsoft Azure Routing Preference ↗) může výrazně snížit nebo zcela odstranit poplatky za odchozí přenos dat.
• Privátní infrastruktura: Workers VPC a Cloudflare Tunnel umožňují přímé připojení k soukromým koncovým bodům úložišť nebo databázím ve veřejných cloudech, aniž by je bylo nutné vystavit veřejnému internetu.
• Load balancing: Provoz je rozdělován mezi funkční servery pomocí Cloudflare Load Balancing. Pokud origin server selže, provoz se okamžitě přesměruje na funkční pooly serverů. Alternativně Round-Robin DNS lze použít pro jednodušší distribuční strategie.

Každou optimalizaci ověřuje průběžné monitorování a testování. Měření a logování potvrzují skutečné přínosy, včas odhalují regrese a odkrývají okrajové případy dávno předtím, než ovlivní klienty.

Při analýze těchto dat je důležité vzít v úvahu limity připojení a Chování TCP připojení, a zároveň zohledňuje prohledávače Cloudflare a koncový bod /cdn-cgi/, a také případné nesrovnalosti v datech mezi Cloudflare a Google Analytics.

• Cloudflare Observatory ↗: Hlavní dashboard pro výkon. Kombinuje syntetické testy (Google Lighthouse) pro standardizované výchozí hodnoty se službou Real User Monitoring (RUM), která zaznamenává skutečné zkušenosti uživatelů na různých zařízeních a v různých regionech.
• GraphQL Analytics API: Použijte toto pro Trends a Timing Insights ↗. Dotazujte se na konkrétní metriky, jako je edgeDnsResponseTimeMs oproti originResponseDurationMs k přesnému zjištění, kde vzniká latence.
• Web Analytics: Určeno speciálně pro RUM analytiku postavenou na edge s důrazem na soukromí.
• Cache Analytics: Zásadní pro analýzu Cache Hit Ratio (CHR) a "Requests by Cache Status" při hledání nekešovaného obsahu, který zatěžuje origin server.
• Ruleset Engine: Prohlédněte si a využijte rozsáhlou knihovnu pole, včetně síťových metrik, jako jsou TCP RTT a pole TCP, a implementovat tak přesnou vlastní logiku pro směrování, ukládání do mezipaměti a zabezpečení na základě vlastností připojení v reálném čase.
• Logování a forenzní analýza:
  • Log Explorer: Pro ad hoc dotazování na logy požadavků přímo v dashboardu. Použijte Custom Log Fields k zaznamenávání dalších hlaviček požadavků, hlaviček odpovědí a souborů cookie.
  • Logpush: Pro export logů do SIEM třetích stran s volitelným Možnosti výstupu protokolu, s podporou formátů jako CSV nebo JSON. Nezbytné pro analýzu vlastních polí a dlouhodobých trendů, ale i pro výpočet úspěšnosti stahování (Download Success Rate) a analýzu propustnosti stahování (Download Throughput) u velkých souborů.
  • Instant Logs: Kontrola provozu v reálném čase pro okamžité ladění.
  • Network Error Logging (NEL): Zachycuje problémy s konektivitou na straně klienta, které server nemusí nikdy zaznamenat.

• Cloudflare Telescope ↗: Open-source testovací agent pro frontend fungující napříč prohlížeči, který dokáže spouštět testy ve všech hlavních prohlížečích. Použijte ho k automatizaci regresního testování výkonu ve svém CI/CD pipeline.
• Cloudflare Speed Test ↗: Měří reálnou kvalitu internetového připojení (včetně zátěžové latence, jitteru a ztrátovosti paketů) simulací skutečného provozu v globální síti Cloudflare pomocí předdefinovaných datových bloků, místo pouhého testování špičkové propustnosti.
• Cloudflare Prometheus Exporter ↗: Získává metriky z GraphQL Analytics API a zpřístupňuje je ve formátu kompatibilním s Prometheus, díky čemuž můžete výkonnostní data Cloudflare zobrazovat společně s metrikami vaší infrastruktury v Grafaně nebo podobných nástrojích.

Cloudflare sice poskytuje interní metriky, externí nástroje třetích stran jsou ale nezbytné pro nezávislé ověření a podrobnou analýzu kritické vykreslovací cesty.

• WebPageTest ↗: Podrobné waterfall grafy a hloubková analýza chování při načítání.
• Google PageSpeed Insights ↗: Standard pro hodnocení metrik Core Web Vitals (terénní a laboratorní data).
• DebugBear ↗: Ideální pro průběžné sledování a historii rychlosti.
• Pingdom ↗: Vhodné pro jednoduché testování dostupnosti a rychlosti podle geografické oblasti.
• Treo.sh ↗: Rychlá historická vizualizace dat Chrome User Experience Report (CrUX).